Despre salarii si angajari in programare

VladBtz, on 21 martie 2017 - 19:04, said:

Pai castig cel care termina inainte de dead-line.
Sa stii ca cei care lucreaza pe backend stiu sa lucreze si pe frontend si viceversa.De obicei se cauta full-stack developeri.

Apoi sa stii ca in cadrul unei companii s-ar putea sa-ti schimbi platforma de full stack, sa lucrezi hibrid.Asta inseamna ca trebuie sa-ti dezvolti capacitatea de invata limbaje de scripting/programare noi si frameworkuri noi cat mai repede.
De exemplu; daca lucrezi pe front-end in spring mvc (java) s-ar putea in viitor sa te ruteze pe alt proiect in php laravel mvc framework. Sa treci de pe Oracle pe MySQL sau pe SQL Server.
S-ar putea ca dupa ce termini  un proiect de pe frontend sa fii mutat  pe alt proiect dar in backend sa lucrezi cu serviciile de integrare SQL Server .
Apoi s-ar putea sa treci pe proiect unde efectiv lucrezi doar in layerul de business logic ( EJB bean-urile  de exemplu ) si cu interfata spre baza de date pe entitati JPA implementate Hibernate sau poti sa lucrezi in business logic direct din spring (via spring beans  de exemplu ) si sa-ti accesezi acelasi modul JPA prin Spring Data JPA, sau
poti sa-ti creezi tu spring beanuri care sa interogheze baza de date via Spring JDBC, sau poti sa ai un proiect prin care sa face "rapid development" folosind Spring Roo
sau te poate sa asiguri securitatea aplicatiei via Spring Security la care se poate adauga un modul custom de securitate interfatandu-te cu Oauth (Spring Security OAuth).
Apoi pe alt proiect sa te mute pe php zend/Symphony/Laravel.
Apoi pe alt proiect s-ar putea sa te mute sa lucrezi pe front-end pe JQuery , CSS, Javascript, JSON pana iti vine boala , apoi pe alt proiect sa lucrezi pe Servicii Web si tot asa.
Desigur compania iti va oferi training insa trebuie sa fii asa cum zic ei in cerintele jobului   "fast learner"  si "team player".Adica sa inveti fara sa faci mutre daca te  muta.

jegmihai, on 21 martie 2017 - 19:19, said:

Nope.Atat backendul cat si frontendul sunt parti importante.In general nu exista o regula.

Edited by lightpoint, 21 March 2017 - 19:35.

VladBtz, on 21 martie 2017 - 19:04, said:

Cel care aduce plus valoare mai mare.

Logic.

lightpoint, on 21 martie 2017 - 19:22, said:

Pai full-stack inseamna sa stii vreo 5-6 limbaje nu ? (php, js, css, mysql, .net etc ) Merita sa fii full-stack developer la noi ? sunt si joburi unde te axezi doar pe o parte ? In stainatate am vazut ca se cauta si axare pe un singur limbaj, gen js Developer sau .Net developer.

VladBtz, on 21 martie 2017 - 21:02, said:

Atentie .NET este un framework enterprise asemanator JAVA EE, insa pe tehnologiile Microsoft;
Developerii .NET cam rar schimba tot tehnology-stackul  si viceversa.
php/js/css/ aceste sunt limbaje de scripting nu de programare.
mysql este o platforma RDBMS open source de la  Oracle , pe care se ruleaza scripturile SQL.

FullStack inseamna sa fii capabil sa lucrezi pe un proiect atat in front-end cat si in backend , pe anumite seturi de tehnologii similare in urmatoarele
layere:
BACKEND: Server hosting/networking layer &&  Data Modelling layer &&  Business-Logic layer,
FRONTEND: Api Layer (MVC layer) /front controller layer &&  User Interface Layer && User Experience Layer(OOAD-Object Oriented  Analysis & Design)
+
Unit-Testing(basic QA level)

Quote

Depinde unde te angajezi.

Quote

Bineinteles.Sunt firme care lucreaza numai pe Front-End sau firme care lucreaza numai pe back-end

Quote

Depinde de firme.Nu neaparat.Dar orice firma de obicei in contract stipuleaza faptul ca trebuie sa fii pregatit sa inveti si alte limbaje/frameworkuri in functie de clientii pe care ii are firma.
Este trecuta clauza in contractul de munca.SI firma este obligata sa asigure training.

Edited by lightpoint, 21 March 2017 - 22:13.

lightpoint, on 21 martie 2017 - 22:10, said:

Clauza aia este irelevanta si nu e generala. In primul rind, pentru ca e de la sine inteles si in al doilea rind, pentru ca daca cuiva i se spune sa faca ceva ce nu-i place, o sa plece pur si simplu.

VladBtz, on 21 martie 2017 - 21:02, said:

Cand te angajezi sofer, treci in anunt ca esti sofer de Dacie sau BMW?

korn, on 15 martie 2017 - 10:42, said:

Poate in Romania...te asigur ca in afara nu asa sta treaba. Pur si simplu te intreaba motivele pentru care ai plecat si pot exista multe..

Clau_UK, on 07 aprilie 2017 - 08:39, said:

Nici macar in Romania nu cred e asa, eu sunt hopper profesionist aka 5 jobs in 4 ani. Nu am avut niciodata problema cu asta la interviuri, mai sunt unii care se uita putin mai dubios si pun mai multe intrebari. Este intradevar un mic dezavantaj, dar nicidecum un blocker.

Plus ca nu sunt singur, stiu mai multe persoane in situatii similare cu a mea.

lightpoint, on 21 martie 2017 - 19:22, said:

Eu am scris vreo 100 de linii de Javascript în viața mea, la două ore de laborator în facultate.

Dacă lucrezi pe proiecte mari, nu prea ai cum să știi bine și back-end și front-end.
Dacă lucrezi pe proiecte mici unde back-endul e un server care face CRUD pe o baza de date și expune o interfață REST, poți lucra full stack; poți de fapt folosi doar Javascript.

Vezi de exemplu la Google câți full-stack developeri caută.

m3th0dman, on 27 aprilie 2017 - 23:33, said:

Ce vorbesti domne tu acolo ? Pa langa faptul ca poti sa stii foarte bine absolut si front-endul si back-end mai poti face training la cei noi veniti fie pe backend sau pe frontend si apoi
poti sa ai sedinte de cod review sau pair programming si pe front-end si pe back-end.

Quote

Mey asta e tema de trimestru la liceu. Ce spui de un ecosistem de aplicatii cu conectori catre SAP/ERP/SSIS cu propriul DWH pe arhitectura proprie ETL  ?

Quote

Nu conteaza cate linii scrii.Conteaza calitatea codului si asta pt ca majoritatea incepatorilor scriu bloatware.

Edited by lightpoint, 28 April 2017 - 00:03.

Aveam in plan sa scriu o poveste mare cu ce este acum pe front-end ca sa stii bine absolut, dar poza din link-ul asta face 1000 de cuvinte

Nu e posibil sa stii foarte bine back-end + front-end, d-aia se si zice ca cel mai bine e sa ai o specialitate pe una din ele si pe restul sa nu te implici in detaliu, dar sa ai putina xp cu toate.
Spunea cineva o comparatie foarte buna, de ex daca ai un proces de judecata cu cineva pe baza penala o sa angajezi un avocat generalist sau unul care e specializat in penal ? la fel si cu doctorii, nu cred ca vrei sa te duci la un medic generalist sa te opereze pe creier.

PS : nici daca esti doar pe una din ele nu poti tine pasul cu absolut tot ce se intampla, sunt prea multe schimbari, dar da mereu e bine sa stii cate putin din toate.

Edited by Tibus, 28 April 2017 - 00:30.

lightpoint, on 27 aprilie 2017 - 23:58, said:

Poți dacă e aplicația simplă (sau posibil dacă încă folosești tehnologii de pe vremuri).

Să le luăm pe rând; care-s tehnologiile care cred eu c-ar trebui să știe unul de front-end: Javascript, HTML, CSS, ceva framework-uri de JS (Ember, React, Angular), build tool precum grunt, JQuerry, Backbone, Foundation sau Bootstrap. Dacă e full-stack să știe și Node.JS, SQL și ceva NoSQL. Probabil sunt mai multe, dar nu am eu habar despre subiect să le enumăr pe toate.

Să vedem ce-ar trebui să știe cineva specializat pe back-end Java: Java (eventual Scala, Groovy), concurrency (threads, actors), messaging (JMS, Rabbit, Kafka etc), full frameworks precum JavaEE (JPA, JTA, JMX etc + server WildFly/JBoss, WebLogic/Sphere etc.) sau Spring (DI, Batch, Data, MVC, Test, Transaction etc.) , DB (SQL + ceva NoSQL), Build tool (Maven, Gradle, Ant), ORM (JPA/Hibernate/EclipseLink, (Spring)JDbC), Big Data (Hadoop, Spark), WS (REST JAX-RS/WS, Spring MVC), Websockets, sisteme distribuite (zookeeper), chestii legate de deploy/configuration management (puppet/chef, docker, vagrant, ansible), cloud (AWS, Azure etc), testare (JUnit, RESTAssured etc.), CI (Jenkins), Linux + Bash. Mai sunt altele despre care nu știu sau am uitat.

Sunt destul de convins că dacă știi bine Ember/React/Angular te-am pierdut la partea cu actorii; sau invers. Sau zi-mi că tu știi cu ce se mănâncă tot ce-am enumerat mai sus?

Și asta ignorând cea mai importantă parte - business-ul în sine. Inginerii foarte buni, sunt specializați pe o anumită arie de business.

lightpoint, on 27 aprilie 2017 - 23:58, said:

Eu dădeam ca exemplu că am scris destul cod back-end dar n-am habar cu ce se mănâncă front-end; nu știu Javascript, HTML, CSS decât conceptual (și restul tehnologiilor).

Quote

Si Jquery Framework

Quote

Depinde de proiect.

Quote

Quote

De fapt este JAVA SE , iar pt Scala doar daca ai pe  mana un proiect BigData-Hadoop-Spark Cluster

Quote

YES

Quote

YES, YES

Quote

Spring JDBC, Spring MVC si Spring security ajung.

Quote

+ T-SQL si MSSQL si SSIS

Quote

YES

Quote

YEEEEES

Quote

YEEEES , vezi mai sus

Quote

Valabil pt QA team

Quote

YEEEEES

Quote

Da, PHP framework: Laravel.

Quote

YEP

Quote

Inginerii foarte buni sunt specializati pe ceea ce li se da de catre Team Manager si sunt capabil la cerere( nevoie) sa invete rapid orice tehnologie si limbaj de programare

Toate cele enumerate de tin mai sus devin simplu de invatat daca iti dezvolti doua capacitati; capacitatea de a fi autoditact si capacitatea de invata rapid limbaje de programare la care se adauga faptul ca este un mare avantaj isa-ti fii modelat gandirea in limbajul C , disciplinele ASDN  + Teoria Sistemelor.

Edited by lightpoint, 28 April 2017 - 07:53.

lightpoint, on 28 aprilie 2017 - 07:50, said:

Eu unul impart asa programatorii in nivele:

* incepator: stie 1-2 limbaje, si le iubeste
* mediu: stie 3+ limbaje si cateva tehnologii, si le iubeste
* avansat: a trecut printr-o duzina de limbaje si tehnologii, si stie care sunt punctele forte si punctele slabe ale fiecaruia, stie cand si ce sa foloseasca sau unde sa sape pentru mai multe informatii, si, asa cum ai zis si tu, sa invete orice alta tehnologie/limbaj din mers

lightpoint, on 28 aprilie 2017 - 07:50, said:

De curiozitate ce librărie pentru concurență prin actori ai folosit? Și prin ce e superior și inferior față de alternativa clasică cu thread-uri?
Și în ce cazuri e mai bun Ember decât Angular?

lightpoint, on 28 aprilie 2017 - 07:50, said:

De fapt proiectele Hadoop sau Spark au librărie de conectare foarte bune pentru Java; nu e nevoie de Scala pentru asta.

lightpoint, on 28 aprilie 2017 - 07:50, said:

Este Spring Data cu multe module înspre baze de date NoSQL; sau Spring Data JPA. Este Spring Batch (din care s-a inspirat și Batch din Java EE). Este Spring JMS, Spring AMQP sau Spring Kafka, pentru conectare la message broker. Spring Transaction e esențial dacă lucrezi cu o bază de date relațională. Spring Test iar e de bază, dacă vrei să scrii teste.
Spring Boot duce experiența spring la un alt nivel prin convention over configuration, el însuși venind cu multe sub-module.

lightpoint, on 28 aprilie 2017 - 07:50, said:

Inginerii foarte buni își aleg ei pe ce să lucreze.

lightpoint, on 28 aprilie 2017 - 07:50, said:

C e limbaj super simplist; e un assembly mai fancy.
Iar ASDN (presupun că e ceva curs de electronică digitală elementară) și Teoria Sistemelor nu prea au nici o legătură cu software engineering sau cu programarea în general. Dacă tot te-ai legat de cursuri îți modelezi gândirea în matematică; sau cursuri esențiale sunt arhitectura calculatoarelor, tehnici de programare, sisteme de operare s.a. ce au legătură cu software engineering.

Edited by m3th0dman, 28 April 2017 - 13:39.

m3th0dman, on 28 aprilie 2017 - 13:38, said:

Scala.Actors

Quote

Actorii (adica de fapt procesele) transmit informatia prin mesaje asincrone
izolate ,astfel incat se evita situatia atunci cand un thread incearca sa modifice datele din zona de memorie pe care un alt thread la randul sau o acceseaza.(concurenta threadurilor) evitandu-se astfel scenariul pentru a creea deadlock-uri.
In realitate nimeni  nu-ti garanteaza daca folosesti modelul de actor nu sa ai deadlock-uri.La nivel, de management al stivelor de mesaje , tot ai nevoie sa faci locking.
Ideea e ca poti construi un model de actor pe baza modelului de thread (thread-based).Practic modelul de actor te obliga cumva sa pui in aplicare cele mai bune practici pt a evita deadlock-urile.
Adica ne permite sa modelam si sa executam un  management eficient al threadurilor.
Deoarece  fiecare actor bazat pe threaduri isi rezerva o zona de memorie, daca folosim multi actori de acest tip putem sa ramanem fara memorie
imediat si sa supraincarcam la si schedulerul de actori.
Daca business-ul ne obliga sa folosim multi actori care se intampla s consume memorie foarte multa  pe server, atunci inlocuim actorii bazati pe threaduri
cu actori bazati pe eventuri.

Quote

Ember este foarte bun la crearea de  SPA-uri, in proiecte mari cu volum de date mare de procesat si de migrat si ofera un boot-time considerabil mai mic decat alte frameworkuri
In plus Ember are cel mai peformant rendering Engine: Glimmer

Quote

Pentru arhitecturi  ETL se trag datele din clusterul Hadoop cu Scala ca sa-ti faci viata mai usoara.

Quote

Dar tranzactiile EJB via EJB-Stateless bean-uri ce au minus? dar MDB beanurile ce au  minus? dar entitatile  JPA (POJO) ce au in minus ?

Quote

Nu este indicat sa-ti legi tot proiectul de un ANUMIT VENDOR.

Quote

Inginerii foarte buni nu i-au niciodata decizi cu impact mare cum vor muschii lor. Inginerii buni fac sedinte in metodologie AGILE pentru
a stabili ce este cel mai bun pentru PROIECT, nu PENTRU EI, ca  virgula corporatia nu este tarlaua lor personala.
Inginerii buni masoara de N ori si executa o singura data. Pana cand nu se lamuresc ABSOLUT toate problemele legate de proiect nu se trece la programare.
Inginerii buni intotdeauna masoara impactul tehnologiilor folosite  asupra proiectului si asupra viitorul acestuia(menentenanta, etc)

Spuneai undeva de tehnologii vechi.Dragul meu nu exista acest concept.Faptul ca daca tie ti se pare "vechi" asta este o parere subiectiva.
Limbajul C poate fi socotita dupa analiza ta, drept un limbaj "vechi" insa te asiguri ca desi a fost inventat in ani 70 inca este folosit
si este in crestere.

Quote

iar java este un C mai fancy... iar Scala este un java may fancy....
C-ul te invata cu adevarat sa gandesti. Este un adevarat sport de performanta al gandirii. C este pentru gandirea unui ingner software ce
este culturimsul pentru un sportiv de peformanta.

Quote

ASDN-ul te invata sa gandesti si proiectezi UAL-uri si CPU-uri si orice alt device de electronica, pe care le controlezi prin C.

Quote

Software-ul este tot un sistem de alte subsisteme. Iar Teoria Sistemelor este materia care te invata managementul sistemelor.
Mai mult in ingineria software avem de-a face cu ECOSISTEME de sisteme( vezi frameworkurile).
Probabil ai auzit de entropia software, acest termen vin din analiza software-ului dpdv al unui sistem cu fluxuri de date, cu perturbati, cu stari finite definite
de un delta al functiilor de transfer pentru fiecare subsistem in parte, care alcatuieste sistemul software

Quote

Asa se vede la nivel de programator.
Insa de la etajele superioare lucrurile se vad altfel(adica cum sunt ele de fapt)

PS: Atunci cand ai spus Inginerie ai spus Sistem.Ingineria inseamna studiul si comportamentul sistemelor (de oricare ar fi ele).Acum intelegi
cam pe unde te afli ?

Edited by lightpoint, 28 April 2017 - 16:03.

Ember este ultima alegere pentru SPA-uri, de ex daca ne uitam acum pe stackoverflow sa comparam numarul discutiilor :
Angular - 215 asked Today
React - 108 asked Today
Ember - 6 asked Today

Ember nu are cel mai mic boot time, nici macar nu se compara cu react/redux, dar oricum nu ia nimeni asta in considerare pentru ca nu face o diferenta asa mare.
La un proiect mare peste tot se considera Angular peste Ember, React/Redux la fel este cu mult preferat peste Ember, Ember e aproape mort, nici macar nu este luat in considerare.
Ember nu are cel mai performant rendering engine, noua versiune de Angular este mai performant si la capitolu asta decat Ember.
jQuery nu este un framework, este o biblioteca pentru manipularea DOM-ului + cativa helpers.

PS: Ember este pe cale de disparitie, peste tot se discuta Angular vs React/Redux, la proiecte foarte mici se ia in considerare si Vue pentru ca este foarte mic si simplu.
PS2: La intrebarea "în ce cazuri e mai bun Ember decât Angular?" raspunsul este la nici unul.  (se putea discuta inainte fata de versiunea veche de AngularJS, dar nu mai este cazul)

Tibus, on 28 aprilie 2017 - 16:04, said:

Cand am spus jquery framework m-am referit implicit la frameworkuri bazate pe JQuery:
http://www.jqwidgets.com/
http://www.fromdev.c...frameworks.html