Hva må man kunne for å få foten i døra og få jobb som Java-konsulent?

[nightowl]

Jeg er i den posisjonen at jeg snart skal søke jobb igjen. Dessverre er det ikke noe å oppdrive på det (sære) feltet jeg (litt ubevisst) har spesialisert meg på. Jeg tenker derfor å studere Java fremover så jeg en dag kan jobbe som systemarkitekt et sted de benytter Java.

 

Jeg hadde Java når jeg ble utdannet som dataingeniør, men det var mye ekstra som foregikk likt i studiet så det ble lite tid til å sette seg inn i dette stoffet. Interessen var heller ikke til stede p.g.a. stadige problemer med å få ting til å fungere i NetBeans og GlassFish. Likevel syns jeg Java har mer sjarm og er 'kulere' enn .NET, så da blir valget enkelt.

 

Jeg mener å huske at jeg var innom JSF med PrimeFaces, JPA og JMS. Men med den knappe tiden skrapet jeg sikkert bare i overflaten.

 

Spørsmålet blir derfor: Hva er det mest nødvendige man trenger å lære seg for å ha en real sjanse på jobbintervjuet?

 

(Jeg vet selvsagt at det er andre krav også til en sånn jobb, men det er ikke tema for denne tråden)

 

EDIT: Oppdatert arbeidsliste

 

1. Komme inn i Java igjen, JUnit, +++

2. Spring

3. ...

Endret 12. september 2015 av nightowl

[Matsemann]

Kjenner ikke til noen nyere prosjekter som bruker JSF, eller som bryr seg mye om glassfish og jms.

 

Spring brukes mange plasser, sammen med JPA/Spring Data, og ting testes med JUnit eller AssertJ, ofte brukes Mockito i tillegg. Maven brukes stort sett for å bygge prosjektene, og de fleste bruker IntelliJ som IDE. Jenkins som byggserver og Git som versjonskontroll.

 

Men jeg vil påstå spesifike rammeverk/teknologier ikke er det viktigste. Å kjenne konseptene er det du bør gå etter. F. eks. er det ikke viktig om du spesifikt kan JUnit, det viktige er om du forstår prinsippene bak testing, hvordan skrive gode tester, testbar kode osv.

 

Om du ser etter designprinsipper er "Clean Code" bibelen innenfor hvordan designe kode. Mer teknisk er "Effective Java" en velkjent bok mtp hvordan gjøre ting i Java.

[nightowl]

Ikke lest så ofte om JSF, GlassFish og JMS heller i jobbannonser, men tenkte først jeg kunne begynne i denne enden og ta det som repetisjon. Nå derimot er jeg ikke så sikker.

 

Maven har jeg hørt om ja.

Samme med IntelliJ selv om jeg ikke har brukt denne før. Det har gått i NetBeans og Eclipse.

Jenkins er nytt.

Git er såvidt prøvd.

TDD har jeg også vært del av.

Clean code har vært vane lenge, da jeg har litt OCD-tendenser.

Effective Java står allerede i bokhyllen, jeg mener å ha leste gjennom den en gang.

 

Ser ut som jeg har nok å ta tak i.

 

Kan jeg spørre hva du jobber med Matsemann, så jeg vet at jeg kan ta deg seriøst? 

[Matsemann]

Jeg er relativt fersk, men jobber som konsulent og det er java jeg kan best. Nå er jeg heldig så langt og har bare vært borti prosjekter der man bruker omtrent bare det mest moderne innenfor java-stacken. Så de tingene jeg sier er utdatert er nok fortsatt i bruk mange plasser, og kan sikkert være nyttig å kunne noe om, litt avhengig av bedrift/prosjekt.

 

Det er ikke vits i å bruke mye tid på å sette seg inn i Jenkins spesifikt tror jeg, men om du ikke har vært borti continuous integration bør du se på det.

 

Kom på en ting! Det var JavaZone denne uken. Kjempestor Java-konferanse i Norge. Om du leser over programmet kan du se hva som er inn for tiden i java-miljøet: http://2015.javazone.no/program.htmlog de legger ut de aller fleste talene på vimeo her: https://vimeo.com/album/3556815 kan være smart og sjekke ut!

[LordjOX]

Synes Matsemann har dekket det man finner overalt i grove trekk.

 

Kort fortalt så finner man følgende i mange organisasjoner som bruker Java som teknisk platform:

• En eller flere applikasjonstjenere (Glassfish, Jboss, Websphere, Jetty, ...)
• En eller flere relasjonsdatabaser (Oracle, Postgres, Mysql, DB2, ...) eller ikke (mongo, elasticsearch, couchdb, ...)
• Noe ORM mapping (JPA/Hibernate, Spring Data, ...) eller ikke (jooq, jdbc, ...)
• Noe som holder applikasjonen sammen (Spring, Camel, Akka, ...)
• En eller flere integrasjonsprotokoller (SOAP, REST, JMS, Thrift, ...)
• Trelagsarkitektur (datalag, forretningslag, presentasjonslag) eller noe annet

Kildekoden bor som regel i et Git eller Subversion repository.

jUnit, AssertJ/Hamcrest, Mockito er testteknologien som enhetstester, integrasjonstester kode hver gang det bygges. Så har man tester på høyere nivå som kanskje eies av kunde eller forretning.

Bygg gjøres av Maven eller Gradle.

Continuos integration gjøres av Jenkins.

 

Måten man gjorde dette tidligere på var å lage én stor app som gjorde alt, gjerne på Java EE. Noe man for tiden kaller en monolitt.

 

Nå for tiden ønsker man flere mindre applikasjoner med egne domener, som snakker sammen med en felles integrasjonsmekanisme. Dette kalles microservices.

 

Kan man det meste av det ovennevnte og har en bachelor/master så kan man få jobb som seniorkonsulent ved hvilket som helst konsulentfirma i Norge.

Kan man bare litt av teknologien nevnt men kan Java, er sånn passe ung med bachelor/mastergrad, så kan man få jobb som juniorkonsulent ved hvilket som helst konsulentfirma i Norge.

Kan man ingen av delene.... vel... ingen har lyst til å være din kollega.

Endret 13. september 2015 av LordjOX

[nightowl]

Wow, nå fikk jeg mye å se over! Tusen takk for hjelpen, begge to!

[siDDis]

Å kunne Java er meir viktig enn å kunne Spring.

 

Maven er vell det einaste eg vil kalle obligatorisk å lære seg til Java utvikling, resten tar du som det passer. Eg er forresten ikkje einige om at Clean Code er nokon god bok angåande god ryddig gode. Det er meir basert på ein persons synspunkt på kva som er god ryddig kode, også har du dei som ikkje evne å tenkja sjølv og er automatisk einige. Min anbefaling er heller å setja inn inn i Google/Sun guidelines for korleis du strukturer kode, det er sånn dei fleste skriver Java kode.

[LordjOX]

Ingen her som sier at Javakunnskap ikke er viktig. Uansett så er det en forutsetning for å lære andre bibliotek og rammeverk.

 

Er mange gode poenger i Clean Code så ville ikke avskrevet den fullstendig. Hovedpoenget er at det å skrive kode er noe man må gjøre mye for å bli god og man burde gå flere runder med koden.