Programmører elsker å snakke mot moteverdenen der trender blåser gjennom som bris. Skjørtelengder stiger og faller, pigmenter kommer og går, bånd blir fetere, så tynnere. Men i teknologiens verden hersker strenghet, vitenskap, matematikk og presisjon over kjepphest.
Det er ikke å si at programmering er et yrke uten tendenser. Forskjellen er at programmeringstrender drives av større effektivitet, økt tilpasning og brukervennlighet. De nye teknologiene som leverer en eller flere av disse, formørker den forrige generasjonen. Det er et meritokrati, ikke et innfall.
Det som følger er en liste over hva som er varmt og hva som ikke er blant dagens programmerere. Ikke alle er enige i hva som er A-oppført, hva som er D-oppført og hva som er utelatt. Det er det som gjør programmering til et uendelig fascinerende yrke: rask forandring, lidenskapelig debatt, plutselige comebacks.
Hot: Preprocessors
Ikke: Full språkstabler
Det var ikke lenge siden folk som opprettet et nytt programmeringsspråk, måtte bygge alt som gjorde kode til biter som ble matet til silisiumet. Så fant noen ut at de kunne komme på banen med arbeidet som kom før. Nå skriver folk med en smart idé ganske enkelt en forprosessor som oversetter den nye koden til noe gammelt med et rikt sett med biblioteker og API-er.
Skriptspråk som Python eller JavaScript var en gang begrenset til små prosjekter, men nå er de grunnlaget for seriøst arbeid. Og de som ikke likte JavaScript, opprettet CoffeeScript, en forprosessor som lar dem kode, igjen uten den belastende tegnsettingen. Det er dusinvis av varianter som forutsetter og prediker syntaksen på en annen måte.
Folkene som elsket dynamisk skriving, skapte Groovy, en enklere versjon av Java uten altfor insisterende tegnsetting. Det ser ut til å være dusinvis av språk - Groovy, Scala, Clojure, Kotlin osv. - som kjører på JVM, men det er bare en JVM. Du kan også kjøre mange språk på .Net's VM. Hvorfor gjenoppfinne hjulet?
Hot: Serverless
Ikke: Docker
Dette stemmer ikke akkurat. Docker-containere er overalt. Servere snurrer opp og stenger containere hele tiden. Imidlertid er Docker-containere såååå mye større enn de trenger å være.
Hvis du tenker på det, kan du bare skrive noen titalls linjer med ekte beslutningskode for den mikroservicen du distribuerer, men du må kaste inn en bazillion linjer med konfigurasjon for å lage Node.js og hva som helst annet opp riktig med Docker. Ja, alt er kokeplate, men det mangler poenget.
De nye serverløse arkitekturer lar oss distribuere bare de få hvis-så-annet uttalelsene som tar de virkelige beslutningene. Alt annet overlates til folk som leier oss den serverløse plattformen.
Ja, vi vil klage på innlåsing og mangel på tilpasning om noen år, men foreløpig ser de serverløse alternativene ut som en lettelse fra alle devops og konfigurasjoner.
Hot: JavaScript MV * rammer
Ikke: JavaScript-filer
For lenge siden lærte alle å skrive JavaScript for å vise en varslingsboks eller sjekke at e-postadressen i skjemaet inneholdt et @ -tegn. Nå er HTML AJAX-apper så sofistikerte at få mennesker begynner fra bunnen av. Det er enklere å vedta et forseggjort rammeverk og skrive litt limkode for å implementere forretningslogikken din.
Det er nå dusinvis av rammer som Kendo, Sencha, jQuery Mobile, AngularJS, Ember, Backbone, Meteor JS og mange flere, alle klare til å håndtere hendelsene og innholdet til webappene og sidene dine.
Dette er bare nettappene. Det er også et nummer innstilt på å tilby plattformutvikling for smarttelefon- / nettbrettverdenen. Teknologier som NativeScript, PhoneGap, Apache Cordova og React Native er noen av alternativene for å lage apper ut av HTML5-teknologi.
Hot: CSS-rammer
Ikke: Generisk CSS
Det var en gang å legge til litt pizzazz på en webside betydde å åpne CSS-filen og inkludere en ny kommando som skriftstil: kursiv. Så lagret du filen og gikk til lunsj etter en hard morgenarbeid. Nå er nettsider så sofistikerte at det er umulig å fylle en fil med så enkle kommandoer. En finjustering til en farge, og alt går ut av veien. Det er som det de sier om konspirasjoner og økologier: Alt er sammenkoblet.
Det er der CSS-rammer som SASS og fettere som Compass har funnet solid fotfeste. De oppmuntrer literate, stabil koding ved å tilby programmeringskonstruksjoner som virkelige variabler, hekkende blokker og innblandinger. Det høres kanskje ikke ut som mye nyhet i programmeringslaget, men det er et stort sprang fremover for designlaget.
Varmt: SVG på lerretIkke: Flash
Flash har gjort folk gal i årevis, men artistene har alltid elsket resultatene. Den utjevnende gjengivelsen ser flott ut, og mange talentfulle artister har bygget en dyp bunke med Flash-kode for å tilby sofistikerte overganger og animasjoner. De uformelle spillene fortsetter å være veldig populære. Så Flash fester seg til livet på nettet.
Nå som JavaScript-laget har muligheten til å gjøre mye av det samme, heier nettleserprodusenter og utviklere på slutten av Flash. De ser bedre integrering med DOM-laget fra nye formater som SVG (Scalable Vector Graphics). SVG og HTML består av en stor haug med koder som ofte er enklere for nettutviklere å bruke. Deretter er det store API-er som tilbyr forseggjort tegning på Canvas-objektet, ofte ved hjelp av skjermkort. Sett dem sammen, og du har få grunner til å bruke Flash lenger.
Hot: nesten store data (analyse uten Hadoop)
Ikke: Big data (med Hadoop)
Alle liker å føle seg som Big Man on Campus, og hvis de ikke er det, leter de etter en campus av passende størrelse der de kan skille seg ut. Det er ingen overraskelse da at når ordene "big data" begynte å strømme gjennom executive-suiten, begynte dressene å be om de største, kraftigste big data-systemene som om de kjøpte en yacht eller en skyskraper.
Det morsomme er at mange problemer ikke er store nok til å bruke de mest fantasifulle big data-løsningene. Visst, selskaper som Google eller Yahoo sporer hele nettlesingen vår; de har datafiler målt i petabyte eller yottabyte. Men de fleste selskaper har datasett som lett kan passe inn i RAM på en grunnleggende PC. Jeg skriver dette på en PC med 16 GB RAM - nok til en milliard hendelser med en håndfull byte. I de fleste algoritmer trenger ikke data å bli lest i minnet fordi det er greit å streame det fra en SSD.
Det vil være tilfeller som krever raske responstider på dusinvis av maskiner i en Hadoop-sky som går parallelt, men mange vil gjøre det bra å plugge sammen på en enkelt maskin uten problemer med koordinering eller kommunikasjon.
Varmt: Gnist
Ikke: Hadoop
Det er ikke så mye at Hadoop avkjøles. Det er mer at Apache Spark er rødglødende, noe som får Hadoop-modellen til å se litt gammel ut. Spark låner noen av de beste ideene til Hadoops tilnærming til å hente mening fra store datamengder og oppdaterer dem med noen få solide forbedringer som gjør at koden går mye, mye raskere. Den største kan være måten Spark holder data i raskt minne i stedet for å kreve at alt skrives til og leses fra det distribuerte filsystemet.
Selvfølgelig slår mange sammen de to ved å bruke Sparks prosesseringshastighet på data lagret i Hadoops distribuerte filsystem. Hadoop og Spark er oftere partnere enn konkurrenter.
Hot: Databasekonfigurasjon
Ikke: Programvareprogrammering
For lenge siden pleide programmerere å tulle med at de ikke visste hvordan programmering ville se ut i neste århundre, men de visste at det ville bli kalt Fortran. Denne vitsen var så morsom at de ville falle av dinosaurene og knuse treundertøyet. Så ville de gå tilbake til å konfigurere en database.
Og vi bygger fremdeles databaser i dag, men det vi tenker på som en "database" er nå mange ganger mer sofistikert og kraftig. Off-the-shelf databaser vil synkronisere seg på tvers av kontinenter og samtidig tilby en fleksibel kompromiss mellom konsistens og hastighet. Noen skytjenester som Firebase vil skyve nye data helt ut til webapper som kjører på mobile klienter.
Mye av den serverløse revolusjonen er basert på erkjennelsen av at mange av skydatalagrene nå er så kraftige at vi bare trenger å skrive noen få hvis-da-andre klausuler for å bygge en ganske kul webapp.
Hot: Game rammer
Ikke: Innfødt spillutvikling
En gang i tiden betydde spillutvikling å ansette mange utviklere som skrev alt i C fra bunnen av. Visst, det kostet bazillion dollar, men det så bra ut og det løp som vinden. Nå har ingen råd til luksusen med tilpasset kode. De fleste spillutviklere ga opp sin stolthet for mange år siden og bruker biblioteker som Unity, Corona eller LibGDX for å bygge systemene sine. De skriver ikke C-kode så mye som instruksjoner til bibliotekene.
Er det synd at spillene våre ikke er håndlagde med stolthet, men utelukket med samme motor? Nei. De fleste av utviklerne er lettet. Fordi de ikke trenger å forholde seg til detaljene, kan de konsentrere seg om spill, fortellende lysbue, karakterer og kunst.
Hot: Statisk nettstedsgenerator
Ikke: Enkeltsides webapper
Husker du når nettadresser pekte på nettsider fylt med statisk tekst og bilder? Så kom de dynamiske, ensidige webappene og erstattet dem alle med en smart webapp som ville hente de aktuelle dataene. Gjett hva? Pendelen svinger tilbake, og alle barna bygger statiske generatorer. Det er dusinvis av dem. Det er som en hybrid. Du legger alle dataene i en haug, og deretter skriver du kode som stikker dataene inn i noen maler, slik at det er en HTML-fil for hver statiske URL, og denne kom fra hver rad i datatabellen.
Barna synes disse statiske nettstedene er superraske, og de er det. Bare ikke fortell dem at de gamle dynamiske systemene som WordPress og Drupal fungerte omtrent på samme måte, ved å holde cacher som var ganske mye fylt med statiske sider generert med de nyeste dataene.
Hot: GraphQL
Ikke: HVIL
Det er ikke som om REST er død. Det er bare det at vi vil gjøre mer med API, og GraphQL er en måte å gjøre det på. GraphQL returnerer dataene i JSON, akkurat som REST. GraphQL starter med en HTTP POST, akkurat som mange REST-samtaler. Det er bare det at GraphQL-syntaksen lar deg spesifisere svært komplekse spørsmål med bare noen få tastetrykk. Dette gjør det enklere for programmerere å be om akkurat hva de vil ha, og det reduserer mengden arbeid på serversiden som må gjøres når noen vil ha en litt annen API.
Hot: Cloud IDEs
Ikke: Lokale IDEer
For lenge siden brukte folk en kommandolinjekompilator. Så integrerte noen det med en redaktør og andre verktøy for å lage IDE. Nå er det på tide at IDE blir formørket (ha) av nettleserbaserte verktøy som lar deg redigere koden, til og med koden til et fungerende system. Hvis du ikke liker hvordan WordPress fungerer, kommer den med en innebygd editor som lar deg endre koden der og da. Microsofts Azure lar deg skrive JavaScript-limkode rett i portalen. Disse systemene tilbyr ikke de beste feilsøkingsmiljøene, og det er noe farlig med å redigere produksjonskode, men ideen har bein.
Du kan starte med AWS Cloud9, Codenvy og Mozillas WebIDE, men fortsett å utforske. De nettbaserte verktøyene blir stadig kraftigere. Det er for eksempel mulig å bygge et helt stort dataanalyseprosjekt på Microsofts Azure-nettsted. Og hvis du begynner å utforske serverløse alternativer, vil du raskt finne ut at du kan skrive all koden din i et skjemaelement på en webside. En som ikke er mye større enn skjemaet du bruker til å oppdatere vennene dine på Facebook.
Varmt: GPU
Ikke: CPU
Når programvaren var enkel og instruksjonene ble ordnet i en fin linje, var CPU-en kongen av datamaskinen fordi den gjorde alt det tunge løftet. Nå som videospill er fylt med omfattende grafiske rutiner som kan kjøres parallelt, kjører skjermkortet showet. Det er enkelt å bruke $ 500, $ 600 eller mer på et fancy skjermkort, og noen seriøse spillere bruker mer enn ett. Det er mer enn det dobbelte av prisen på mange grunnleggende skrivebord.
I tillegg er ikke spillere de eneste som skryter av GPU-kortene sine. Dataforskere konverterer nå mange parallelle applikasjoner for å kjøre hundrevis av ganger raskere på GPU. Og dataforskere bruker servere fullpakket med GPUer for å øke hastigheten på utviklingen av maskinlæringsmodellene sine.
Hot: GitHub
Ikke: CV
Visst, du kan lære om en kandidat ved å lese en oppblåst liste over prestasjoner som inkluderer visepresident for sjakkklubben junior. Men å lese noens faktiske kode er så mye rikere og mer lærerikt. Skriver de gode kommentarer? Kaster de bort for mye tid på å dele ting i små klasser som gjør lite? Er det en ekte arkitektur med rom for utvidelse? Alle disse spørsmålene kan besvares med et glimt av koden.
Dette blir grunnen til at deltakelse i open source-prosjekter blir viktigere og viktigere for å finne en jobb. Det er vanskelig å dele koden fra et eget prosjekt, men åpen kildekode kan gå overalt.
