Snart ferdig med en bachelor, anbefalte kunnskaper?

[Nublet]

Siste semester før bachelor innen IT. Føler jeg ikke kan så mye enda.

Har lært grunnleggende java/database/modellering.

Har lyst å få jobb som webutvikler eller driftkonsulent, noen som har anbefalinger til

noe man kan bli noelunde god på?. Har 5 måneder igjen og lyst å fokusere på et

par språk/teknologier/ for å bli mer rustet til overgangen til jobb.

Livredd for å måtte jobbe i butikk/barnehage fortsatt etter endt utdannelse.

[Faller]

Når du skriver webutvikler, tenker du da front-end, back-end eller fullstack? Ganske vesentlig forskjell. 

[Nublet]

Når du skriver webutvikler, tenker du da front-end, back-end eller fullstack? Ganske vesentlig forskjell. 

 

Front-end nå, muligens back-end etter jeg får mer kunnskap.

[ITOslo]

Da bør du fokusere på back-end, java, C# el (+ database). Lite arbeidsmarked hvis du bare søker på front-end koding, da konkurrerer du med en haug web-designere i tillegg som kan skrive front-end i tillegg til å gjøre designarbeidet. 

[siDDis]

Teknologier som jeg anbefaler alle nye backend-utviklere å sette seg inn i er:

 

Mer databaser, innsamling av data, indeksering av data, spesielt funksjonelle indekser, tablespaces, full-tekst søk osv. En moderne SQL database i dag skal greie å returnere/kverne 10 millioner rader på under sekundet, men jeg opplever altfor ofte at det tar timer pågrunn av flere håpløse valg/mangel på gode indekser. F.eks en vanlig gjenganger idag er UUID, som vil bruke 4 bytes per record istedenfor integer som bruker 1 byte. Det betyr at indeksen din blir 4x større og trenger 4x mer RAM for å ha tilsvarende ytelse om det er knapt med RAM. NoSQL er sjelden en erstatter for tradisjonell SQL. Så ikke bruk tid på det.

 

Konsensusalgoritmer, du kan ikke distrubuerte systemer om du ikke vet hva en konsensusalgoritme er. Du har Paxos, Zab, Raft. Jeg anbefaler sterkt å bruke tid på ZooKeeper + Apache Curator. Tar du dette på strak arm, så står arkitektjobbene i kø. Bra lesestoff om dette finner du her: https://aphyr.com/tags/Jepsen

 

Meldingskøer, her finnes det mange, ingen fasitsvar. Apache ActiveMQ er et veldig bra alternativ. Her hjelper også god kjennskap til konsensusalgoritmer for å lage en god meldingskø arkitektur som er skalerbar.

 

Linux/FreeBSD. Jeg blir statig forbauset over hvor mange som ikke kjenner til deres økesystem. Spesielt ille er det blant Mikkesoft fanatikere. Lager du en venn diagram av teknologi, så blir Microsoft en liten dott. Jeg anbefaler spesielt å ta en titt på Varnish, som også er et norsk/dansk produkt. Varnish er en HTTP aksellerator, som er så rask at CPU omtrent idler selv om ditt dual 100 Gigabit nettverkskort pusher ut så mye trafikk som den klarer. Med smart bruk av Varnish, så er web-scale ala Wikipedia ingen problem. Varnish vil også lære deg en vesentlig forskjell om hva som skiller Linux og FreeBSD mest på ytelse.

 

Containersystemer. Docker eller Kubernetes, det vil forenkle deployment og vedlikehold av infrastruktur. Samtidig så har du konfigurasjonsverktøy som Puppet, Chef osv. Anbefaler også en titt på Ubuntu MAAS som forenkler oppsett av bare metal. Virtualisering er på vei ut og brukes idag bare av de som ikke har følgt med i timen. Virtualisering har altfor stor CPU overhead, og sløser bøttevis med RAM. Et operativsystem sin oppgave er å fordele ressurser, virtualisering viser at en gang i tiden så var dette ikke bra nok. Dagens operativsystem er mye bedre lagt til rette for god fordeling av ressurser.

 

Hva som ikke er nyttig å lære seg er "bra kode", det er altfor mye synsing og vås. De fleste finner sin egen middelvei etterhvert med erfaring. Det viktigste å levere noe som fungerer, helst på færrest mulig antall timer. Prøv også å bruke tid på teknologi som er allerede godt etablert, har mye god dokumentasjon og som ser ut til å ha levetid de neste 10 årene. Hold deg borte fra Node.js, som bare er griseri, tull og fjas akkurat som PHP var i sin barndom.

 

Av programmeringsspråk så er Java, Python, C (ikke C++) veldig trygge valg for backend som vil være relevante i mange år fremover. De har også veldig gode økosystemer. Av nyere språk så synes jeg Rust virker mest spennende, men det er fremdeles for ungt til at det er noe jeg ville satset for mye på. Resten er mer unødvendige språk som bringer veldig lite innovasjon og er mer et eksempel av at noen nerder har hatt det gøy med å lage et programmeringsspråk. Du finner kanskje noe du liker og synes er eksotisk. Jeg bruker f.eks Groovy sammen med Java, men de fleste Javautviklere bruker bare Java.

 

For front-end så mener jeg at HTML, CSS og Javascript er mer enn nok. React og Angular er bare overkompliserte tullete rammeverk som gjør webutvikling ekstra tregt og kjedelig. Sluttresultatet blir nesten alltid også en nettside som får vifte på laptopper til å bråke.

[LordjOX]

Er mye bra anbefalinger i denne tråden.

 

Hvis jeg skulle legge til noe så er det ett eller flere byggsystemer som maven, Gradle, CMake, make man finner overalt.

 

Så hjelper det alltid å ha myke ting på plass som en ydmyk holdning til faget, evne til å lære og kommunisere godt både skriftlig og muntlig til kunde og kolleager. I tillegg til å vite når noe er godt nok og ikke forsøke gjøre noe "perfekt".

 

For front-end så mener jeg at HTML, CSS og Javascript er mer enn nok. React og Angular er bare overkompliserte tullete rammeverk som gjør webutvikling ekstra tregt og kjedelig. Sluttresultatet blir nesten alltid også en nettside som får vifte på laptopper til å bråke.

 

Morsomt at du argumenterer for å kunne konsensusalgoritmer, containere og MQ som kompliserer systemer og/eller forenkler arbeidsrutiner. Så avfeie solide webrammeverk fullstendig. Man behøver ikke gå inn i noen debatt mellom hva som er best, for det er ikke viktig. Det er i hvertfall ingen tvil at det sparer mye tid. Og da kommer man tilbake til poenget ditt med at man burde levere noe som fungerer til færrest mulig timer. Hvorfor si nei takk til masse gratis kode som gjør grensesnitt enklere å lage?

[Nublet]

Har tuklet med linux/vmware/windows server 2008/AD osv før. Synes det er spennende.

Bestilt litt praktisk linux/SQL/javascript bøker, begynner der. Er en del som tror IT er bare å flyte seg igjennom og får automatisk jobb,

tror man må legge litt ekstra innsats for å få jobb. Skal nok ha en grei kode portefølje til des.

[Occi]

Noe er allerede tatt opp, i varierende hell, men hvis det er en ting du absolutt må få med deg om utvikling er veien du ønsker å gå så er det kjennskap til hvordan det er å jobbe med andre.

 

Dette innebærer alt fra planlegging og arbeidsmetodikk (velg ditt favorittsystem av buzzwords; agile, scrum, kanban, ..) til tekniske hjelpemidler som versjonskontrollsystem. Det er deprimerende mange som går ut etter endt utdannelse uten å kunne en eneste ting om git eller dens konkurrenter. Alt dette er viktig for at du finner deg lettere på plass hos din første arbeidsgiver.

 

Kort liste med stikkord:

- version control system (vcs): git, mercurial, ..

- continous integration/deployment/delivery: jenkins, travis, gitlab ci, ..

- code review: gerrit, gitlab

- populært integrert med alle over: github.com (også fin måte for å vise frem egne prosjekter)

 

NoSQL er sjelden en erstatter for tradisjonell SQL. Så ikke bruk tid på det.

Enig i at enkelte NoSQL-teknologier har en tendens til å bli hypet opp mer enn de fortjener, men selv om man ikke nødvendigvis liker alt innen denne kategorien tør jeg påstå at det er å skyte seg selv i foten å ikke ha noen relevante erfaringer når man er på vei ut i arbeidslivet.

 

Paraplybegrepet NoSQL er forøvrig notorisk håpløst.

Husk, "Not only SQL", ikke nødvendigvis "No SQL".

 

Virtualisering er på vei ut og brukes idag bare av de som ikke har følgt med i timen.

Bombastisk som alltid. Ikke noe grått eller gradient her nei, alt er svart eller hvitt.

 

Virtualisering handler om mer enn hypervisors for kjøring av virtuelle maskiner.

At det derimot ikke er den ubestridte kongen på haugen lenger er derimot korrekt.

Endret 26. juli 2016 av Occi

[Lycantrophe]

>this is what webdevs actually believe

[siDDis]

 

For front-end så mener jeg at HTML, CSS og Javascript er mer enn nok. React og Angular er bare overkompliserte tullete rammeverk som gjør webutvikling ekstra tregt og kjedelig. Sluttresultatet blir nesten alltid også en nettside som får vifte på laptopper til å bråke.

 

Morsomt at du argumenterer for å kunne konsensusalgoritmer, containere og MQ som kompliserer systemer og/eller forenkler arbeidsrutiner. Så avfeie solide webrammeverk fullstendig. Man behøver ikke gå inn i noen debatt mellom hva som er best, for det er ikke viktig. Det er i hvertfall ingen tvil at det sparer mye tid. Og da kommer man tilbake til poenget ditt med at man burde levere noe som fungerer til færrest mulig timer. Hvorfor si nei takk til masse gratis kode som gjør grensesnitt enklere å lage?

 

Fordi jeg mener at noen har lagd en illusjon at en er mindre produktiv uten disse rammeverkene. La oss ta React som et eksempel, de påstår det er vanskelig å holde styr på "komponenter" på en webside og at DOM manipulasjoner er tungt. Faktumet er at det er ikke helt sant, men når en blir Facebook så har en jo mange ting som skal dynamisk oppdateres på samme side. De aller aller fleste er ikke Facebook i størrelse eller kompleksitet så der er første grunnen til å droppe det.

 

Det andre er all biolerplatekoden som skal på plass for å aktivere en komponent, også når du endrer state(s) så skal dette automatisk reflekteres i hele komponenten, og dens sub-komponenter. Og det er faktisk ganske så flott, problemet er at det er totalt overkill. Det er en unødvendig abstraksjon for de fleste. For hvor holdes state på tradisjonelt vis? Jo i DOM elementet. Ta f.eks totalprisen i en handlekurv, som regel wrappet inn i en div eller span, da er det mye enklere å endre det med document.getElementById('shopping-cart').textContent = "2000kr" enn måtte skriv det om til en hel React komponent.

 

Jamenn andre komponenter skal da kunne oppdatere handlekurven? Vi må ha React-Flux?

Nei! Bruk heller element.addEventListener(eventType, function(e){ addToShoppingCart(e.target.getAttribute('data-price') )})

 

Det er mye enklere å følge for nye utviklere, koden vil fungere i 20 år uten endringer(eller måtte trenge oppgraderinger). Samt det blir færre linjer koder totalt.

 

Er en single page application raskere på rendering enn å vise en helt ny side? Som regel like raskt, kommer mer an på mengden. Men med single page applications, så må du skrive opp dobbel kodelogikk for å håndtere worksflows for både klient og server side. Dette er mye enklere å bare håndtere serverside heller.

 

En annen ting, rammeverktrøbbel er ofte hovedgrunnen til at produkter sliter med teknisk gjeld. Og da er det synd Front-End utviklere drar inn samme skitet som flere serverside prosjekter har slitt med tidligere. Bruk biblioteker, men ikke la et verktøy får styre prosjektet ditt alene. Hva skjer om W3C lager et nytt konsept som erstatter Angular og React, men som ikke er kodekompatibel?

[siDDis]

 

Virtualisering er på vei ut og brukes idag bare av de som ikke har følgt med i timen.

Bombastisk som alltid. Ikke noe grått eller gradient her nei, alt er svart eller hvitt.

 

Virtualisering handler om mer enn hypervisors for kjøring av virtuelle maskiner.

At det derimot ikke er den ubestridte kongen på haugen lenger er derimot korrekt.

 

 

Virtualisering handler om ressursfordeling, ikke noe mer. Flere operativsystemer var altfor dårlige på dette i mange år, dll-helvete, shared libs, security policies, cpu-tid, maks-minne for brukere osv. osv. frem til slutten av 90-tallet. Virtualisering kom først, og rett etterpå kom containere. Solaris hadde fantastisk container-system allerede i 2005.

[Lycantrophe]

Steike så interessante problemstillinger man har i web front-end-land.

 

document.getElementById('shopping-cart').textContent = "2000kr"

husk på algoritmene her folkens better hide yo kids & wife cuz they be katana'ing peepl round here Endret 26. juli 2016 av Lycantrophe

[siDDis]

Du skulle sett React versjonen med Flux for det!

[Tastaturskriver]

Når rådene spriker i alle retninger er nok det beste rådet å være forsiktig med å hva en definerer som sannheter. Hvis du virkelig ønsker å øke sjansene for jobb etter studie er mitt beskjedne råd å ta kontakt med bedrifter så tidlig som mulig og høre om de ikke har noen oppgaver som kan være relevant som tema for en bacheloroppgave. Vet ikke hvordan det er på høyskoler, men på NTNU var det i alle fall et bedriftsnettverk en kunne ta kontakt med. Å sitte å jobbe et helt semester sammen med både en veileder fra utdannelsessystemet samt en veileder fra bedriften er utrolig lærerikt. Og gjør du et godt inntrykk er du nærmest garantert jobb.

 

Likte også rådet til han som skrev om samarbeidsevner, evnen til å mestre det å jobbe i team, planlegging, gjennomføring og avslutning av et prosjekt. I tillegg til gode basisferdigheter er det omtrent noe av det viktigste man ser etter i potensielle ansatte.

[Matsemann]

document.getElementById('shopping-cart').textContent = "2000kr"

husk på algoritmene her folkens better hide yo kids & wife cuz they be katana'ing peepl round here

Du skulle sett React versjonen med Flux for det!

const cart = ({price}) => <b>{price}kr</b>

Evt. pluss 1 linje boilerplate for å connecte den opp mot en store. Og vipps har man vedlikeholdbar kode, og ikke en spaghettisuppe som prøver å lagre state i DOMen og som ytelsesmessig knekker når du skal gjøre noe mer avansert.

 

Uavhengig av hva siDDis mener om frontend-rammeverk (om det er en god ide eller ikke), så er faktum at de brukes i stor grad i dag. Så vil du bli webutvikler bør du absolutt ta en titt på React, Angular eller tilsvarende. Men så klart også kunne de underliggende konseptene.

[siDDis]

Du har gøymd vekk 99% av koden, så det teller ikkje.

[elfim]

 F.eks en vanlig gjenganger idag er UUID, som vil bruke 4 bytes per record istedenfor integer som bruker 1 byte

 

>1 byte

Da kan du jo bare lagre 256 records ?!

[siDDis]

Du har helt rett, jeg som roter med tallene

 

Du har

 

short 2 bytes

integer 4 bytes

bigint 8 bytes

uuid 16 bytes