torbjørn marø

Blant anna så har Java fått ein vanvittig boost dei siste åra, og har blitt veldig moderne igjen. Det vises igjen i fleire av dei største selskapa i Silicon Valley som har måtte skifta teknologi etterkvart som dei har vakse.

 

Facebook, Twitter, Netflix, Google, Yahoo, Oracle osv... er satser for fullt på Java. Til og med C#/Microsoft stacken til Stack Overflow har begynt å fått litt Java her og der. Så å lære seg Java, er ein god trygg lansiktig investering. Fleire og fleire selskaper vil etterspør kompetanse innanfor ZooKeeper, Elasticsearch, Hadoop, Netty osv dei neste åra.

Det er ikke meningen å skape en lang diskusjon om dette her, men jeg kjenner meg ikke helt igjen i den vikreligheten du beskriver.

Java har lenge ligget på topp på popularitetsstigen, men denne populariteten har de siste årene vært synkende. Sjekk her: http://www.tiobe.com/index.php/content/paperinfo/tpci/Java.html

Og selskapene du nevner er jo så store at de bruker veldig mye rart, men få av dem er kjent for Java.

• Facebook: Opprinnelig utviklet i PHP, og har nå introdusert HACK, som er en slags PHP med valgfri statisk typing. Såvidt jeg vet har de også satset endel på programmeirngsspråket D.
• Twitter: Er kjent for å bruke Scala (som kjører på JVM ja, men det er ikke Java). Brukte tidligere Ruby.
• Netflix: Holder på å gå bort fra Java til fordel for Python. Kilde: http://www.javaworld.com/article/2078738/java-se/why-netflix-is-embracing-python-over-java.html
• Github: Bruker Ruby og Erlang. (ser nå at du ikke nevnte dem )
• Google: Java har lenge vært viktig hos dem, sammen med Python. Derimot satses det nå stort på deres eget språk Go, og store deler av infrastrukturen skrives om.
• Yahoo: Er mest kjent for å bruke PHP og C++ mener jeg, og går nå over til node.js.
• Oracle: Har kjøpt Java, men er mest opptatt av å saksøke folk for å bruke det (vant akkurat over Google i andre runde i Android-saken)

Missforstå meg rett - Java er svært, og det kommer ikke til å dø ut på lenge ennå. Personlig tror jeg derimot at JVM'en kommer til å leve lengre enn språket, og Java kommer aldri til å bli så populært som det var for 10 år siden.

Sammenlig med kurven til C#. Den er mye mer positiv, selv om den også har fått seg en knekk de siste par årene. http://www.tiobe.com/index.php/content/paperinfo/tpci/C_.html

informasjonssystemer og IT-ledelse

 

Såvidt jeg kan se er dette en veldig bred studieretning, ikke en programmeringsutdanning. Inneholder IT-drift og programmering, lære om organisasjon, økonomi og strategi i IT-prosjekter, brukerstøtte, og mulig fordypning i for eksempel markedsføring eller juridiske fag. Det virker spennende - men altså ikke den typiske veien for en utvikler.

... hvordan en utviklers arbeidsdag er? Det er flere som har advart meg om at det kan bli veldig kjedelig og ensformig etterhvert. Er det tilfellet?

 

Programmering er spennende - for dem som liker det. Vi føler oss heldige fordi noen faktisk er villige til å betale oss for å drive på med hobbien vår på fulltid. Liker du det ikke vil det være pyton, og sansynligvis vil du ikke klare det særlig bra heller.

Er det mye forskjell på en .net eller javautvikler som en webutvikler eller webdesigner?

Husker vi lærte litt HTML og CCS osv når jeg gikk IKT på vgs og det syntes jeg var veldig spennende, men kan det sammenlignes?

 

De som kaller seg webdesignere er typisk ikke programmerere. De kan alt om brukeropplevelse, og hvordan websider ser og fungerer bra. Men de kan stort sett bare tegne dem, og trenger en programmerer til å fullføre jobben.

Derimot er 90% av alle utviklere også webutviklere i dag (jeg trodde vi hadde sluttet å bruke det uttrykket nå faktisk, fordi utvikling så ofte er det samme som webutvikling).

Webutvikling betyr som regel at du må ha god forståelse/kunnskap om HTML og CSS ja, samt JavaScript. I tillegg vil du nok måtte lære/bruke en teknologi for det som skal kjøre på serveren (f.eks. .NET).

Og .NET og Java er ikke så veldig forskjellig nei. Men av de to miljøene ville jeg satset på .NET om jeg var deg (men jeg er partisk).

Er det vanskelig å lære seg ett nytt språk? Mye teori osv som må pugges?

 

Til å begynne med er det krevende å lære språk. Lesingen du må gjøre er ikke først å fremst for å lære språk, men for å lære programmering (uavhengig av det valgte språket). Etterhvert går det enklere - kan du to språk går det tredje bedre, kan du 10 kan du ta i bruk nye språk uten å blunke.

Jeg ville ikke sammenlignet det å lære et språk med å pugge. Mer som å lære å sykle/svømme. Eller kanskje mer som å lære seg et nytt dataspill. Man kunne lest en bok som beskrev alle mulighetene i et spill og alle reglene som gjaldt (hvis en slik bok hadde eksistert), men det man gjør er å spille spillet og lære seg tingene etterhvert.

Hva ligger lønna på ca. når man er nyutdannet utvikler og får seg jobb?

 

Lønnsforskjellen mellom bachelor og master er ikke stor i IT-bransjen.

Statistikken viser at systemutviklere og programmerere som har mer enn fire års utdanning tjener 4300 kroner mer enn dataingeniører som har studert fra ett til tre år. Det gjelder avtalt månedslønn.

Ser man på den avtalte månedslønnen og utdanningsnivå i andre næringer, så tjener de med akademiske yrker mellom 9000-10.000 kroner mer enn de med høgskoleyrker.

 

Klide: http://www.tu.no/karriere/2014/01/27/sa-lite-ekstra-lonn-gir-en-mastergrad-i-it-bransjen

Snittlønnen for en utvikler med 1 til 3 års utdanning i Norge i dag er 45.700,-. En faktor av en viss betydning er hvor i landet du bor. Jeg er veldig usikker i forhold til startlønn - det kan nok variere mye. Kommer også veldig ann på hvor flink du er til å selge deg inn / finne den riktige jobben.

En interessant mulighet er å bruke et biblotek for syntax highlighting. De mest kjente er vel http://pygments.org/, http://prismjs.com/ og http://highlightjs.org/. Den siste bruker jeg selv når jeg genererer bloggartiklene mine.

Tenkte å kansje skaffe noe slikt.

Hva er formålet? Hva er det for en side du skal lage? Hva skal innlogging gi tilgang til?

Fikk lyst å dele et sitat jeg kom over for litt siden med dere:

People who use assembly code are - if not in an actual minority - considered somewhat archaic or old-fashioned.

Det morsomme er at jeg fant dette i en bok som ble skrevet i 1967. Selv om assembly ble brukt så var det allerede den gang gammeldags.

Du må finne og bruke (minst) en kilde til kunnskap. Det kan være:

• En bok for nybegynnere, f.eks. Head First Java
• Tutorials online (du finner dem med google vet du)
• En kompis som allerede kan litt

Så raskt som mulig må du få lastet ned JDK på maksinen din, skrevet litt kode, kompilert den og kjørt den. Dette kan være en "hurdle" for å komme i gang, så få det unnagjort så du kan komme deg videre.

Og så blir det viktig at du øver, øver og øver. Skriv skriv og skriv kode så mye du orker. Små filleprogrammer som bare gjør en liten ting og som du kan kaste etterpå om du vil. Du trenger erfaringen dette gir deg, og må regne med å gjøre mye av det for å bli god. Heldigvis er det ganske gøy, så kjør på!

Sjekk gjerne ut bloggen min, og spesielt da kata-taggen, for litt inspirasjon til de små filleprogrammene om du behøver det.

Det som jeg synes er størst problem med bruk av { } er at de i mange skrifttyper er vanskelig å skille fra ( ). I C/C#/Java osv er det til å leve med, men så fort en begynner å rote i TCL, så blir koden tungvindt å lese.

Hvorfor er det et større problem i TCL? Jeg har ikke gjort så mye TCL selv, men har forstått at { og } egentlig definerer strenger som går over flere linjer.

Et eksempel:

proc sreverse {str} {
  join [loop i 0 [string length $str] {
    string index $str end-$i
  }] ""
}

Koden over er et kall til prosedyren som heter "proc". Den tar tre argumenter, strengen "sreverse", strengen "str", og en lengre streng som starter på første linje og slutter på siste. Når man senere kaller prosedyren man har fått laget (sreverse) så tolkes den siste strengen (som også inneholder flere strenger).

Jeg synes dette er ganske så kult - få en skikkelig Lisp-følelse av det.

PS: Luke 12 i julekalenderen min i fjor handlet om TCL.

forresten hvorfor bruker du trippel '/' for å markere kommentarer i koden din ?

 

/// er spesielle kommentarer som du kan bruke verktøy for å generere dokumentasjon fra. Visual Studio bruker dem også til å gi popup-tips til brukeren av klassene og metodene.

 

 

hvorfor er { lettere å lese / skille ut fra mengden en Begin ?

hvorfor er } lettere å skille fra mengden enn End ?

Fordi det er ett symbol istedet for 5 og 3. Jeg får ihvertfall heller ikke den indre stemmen som sier "Begin" når jeg ser { noe jeg gjør med "Begin" og "End" så det går litt fortere å lese.

 

...

Er det lettest å finne begin og end her:

Bacon ipsum dolor sit amet meatball short ribs venison frankfurter. Meatball shank pork chop flank. Pastrami t-bone salami begin shoulder ham hock, tail chicken kevin prosciutto. Tri-tip chicken turducken ground round, prosciutto swine ham hock flank ribeye leberkas beef end pork loin drumstick turkey biltong. Kevin pork loin beef ribs leberkas, swine flank fatback porchetta filet mignon strip steak.

eller { og } her:

Bacon ipsum dolor sit amet meatball short ribs venison frankfurter. Meatball shank pork chop flank. Pastrami t-bone salami { shoulder ham hock, tail chicken kevin prosciutto. Tri-tip chicken turducken ground round, prosciutto swine ham hock flank ribeye leberkas beef pork loin } drumstick turkey biltong. Kevin pork loin beef ribs leberkas, swine flank fatback porchetta filet mignon strip steak.

Jeg antar du er enig i at { og } var lettest. Ikke mye lettere, men nok til at det gir en verdi. Med begin og end må hjernen din tolke ordene, mens hjernen mye raskere klare å finne en krøllklamme.

I praksis hjelper det det selvsagt at man strukturerer koden sin på en bestemt måte, sånn at topologien gir deg et hint om hvor blokker starter og stopper. Hvis jeg byttet ut en Begin med en Begjn et sted i Pascal-koden din så hadde det nok tatt litt tid før du oppdaget det, men strukturen hadde du sett like bra likevel.

...

scrpting eller kommandolinje parameter er jo så 80 talle det går an å komme.

rart at så mange driver med det enda

 

hvis man er så avhengig av kommandolinje parameter så har man et dårlig tilnærmet bruker grensesnitt.

...

jeg kjenner meng rett og slett ikke igjen der dere trehoder a 90% eller noe der omkring av alle programmer er uten GUI.

 

kommandolinje parameter er forøvrig ikke noen ( ekte ) brukergrensesnitt

For å gi et litt annet perspektiv på "diskusjonen":

Har du tenkt gjennom det faktum at det ultimate, kraftigste brukergrensesnittet du har mot datamaskinen din er .... trommevirvel .... programmeringsspråket ditt!

Et GUI er - fordi det er så lite fleksibelt / så ressurskrevende å lage - det mest spesialisterte og derfor enten "lite kraftig" eller enormt dyrt. Nyttig for "casual users". Et programmeringsspråk er det minst spesialiserte brukergrensesnittet, og derfor enormt kraftig - du kan gjøre alt - men det krever også mye kunnskap. Kommandolinja befinner seg et sted i mellom disse to ytterpunktene.

diverse om GUI kontra kommandlinja

Det kan virke som om du ikke er så komfortabel med kommandolinja, Elgen?! Da vil jeg anbefale deg i å gjøre et forsøk på å bli det. Det gir normalt følgende fordeler:

1. At man får en bedre forståelse for hvordan verktøyene en bruker egentlig fungerer
2. At man blir mere produktiv! Det oppnår man fordi man finner en rekke små verktøy som gjør ting mere effektivt enn man kan klare det i et GUI, og fordi man lærer seg å scripte kommandolinjeverktøyene (kombinere verktøy og logikk) for å automatisere tidkrevende oppgaver.

Den tredje effekten vil så kunne bli en litt mere interessant diskusjon her på forumet

nettopp. Jeg vet ikke nok til å ta avgjørelsen alene. Hack vekker nysgjerrigheten min. Når det gjelder hva jeg velger å bruke kommer jeg nok fortsatt til å gå for de største språkene, eventuelt de som er mest i vinden der og da

Personlig har jeg valgt Scheme de siste par dagene. Spåket er i alle fall med på listen over de 100 mest populære språkene

Hva synes folk? Har lest litt diskusjoner om det, og må innrømme at jeg synes det virker spennende. Det at facebook kjører dette selv må jo være et kvalitetstegn.

Er ikke Hack bare et plaster Facebook har puttet på et brukket bein (PHP) ? Interessant for PHP-utviklere, men det finnes da mye bedre alternativer...

DISCLAMER: Uttaler meg uten å ha satt meg særlig inn i det

Jeg vil på det varmeste anbefale deg å kjøpe boken Seven Databases in Seven Weeks for å få en god oversikt over hvordan databaseverden ser ut i dag.

De mest populære databasene for tiden slik jeg oppfatter det...

RDBMS: MSSQL, Oracle, PostgreSQL, DB2

Merk at det at det er gratis ikke er eneste grunnen for å velge PostgreSQL - den har blitt skikkelig voksen de siste årene, og har i tillegg til å overtal rollen MySQL hadde også fått en rekke kule funksjoner som MSSQL og Oracle bare kan drømme om.

For mindre ting: SQLite

Dokumentdatabaser: MongoDB, CouchDB, Couchbase, RavenDB (for .NET)

Key-value stores etc: Riak, Redis, Memcached, Amazon SimpleDB, Berkeley DB (fra Oracle), etc..

Column oriented: HBase, Cassandra

Graph: Neo4j

Andre som begynner å få endel omtale: RethinkDB, Datomic...

Det gikk litt fort, mulig listen har feil, og garanterer at jeg har glemt at par viktige

La nå merke til at prosjektet heter Ruby CMS. Et litt uheldig navn kanskje ettersom det finnes et meget populært programmeringsspråk (hovedsakelig for webutvikling) som heter Ruby?!

Det var en veldig solid beskrivelse, og sikkert interesant for noen. Jeg savner bare to ting:

1. Litt mer av hva du ønsker å få ut av personen som blir med deg. Er det for at han skal bidra med noe du kan lære av (en slags mentor)? Eller ønsker du å dele av hva du har lært (du blir mentor)? Eller er backloggen rett og slett så lang at du trenger mer arbeidskraft?
2. Hva er målet med prosjektet. Du sier det kun er en hobby, men så snakker du både om å fjerne prosjektet fra github og å release det. Skal du tjene penger på dette på sikt?

Og når det gjelder abstraksjoner, så er ofte duplisering av kode betre enn disse dårlege abstraksjonene ein ofte kjem over.

Flere som mener det: https://twitter.com/BonzoESC/status/442003113910603776/photo/1

Eller så er du for dårlig til å abstrahere. Gi helperne dine bedre navn, så løser problemet seg.

Å lage gode abstraksjonsnivåer er vel kanskje det vanskeligste problemet man har som utvikler (av lesbar kode), og det kan ta mange år å bli god på dette. Mange blir det aldri. Navngivning er kanskje den nest største utfordringen. Hvis du har en mirakelformel for hvordan man lager gode navn så er jeg veldig interessert i å høre den

Gir mening her. Det er jo også et av poengene til Bob, i samme kapittel til og med tror jeg, at abstraksjonsnivået bør være likt i en metode. Og nettopp derfor splitte ut detaljene i mindre metoder.

 

Det var det jeg mente å huske - at Bob sier akkurat det. Men det folk husker er "extract 'til you drop", og resultatet blir kode som blir som Da Vinci-koden; man må grave og grave for å finne ut hva som skjer.

Forsøker å skrive en blogpost som snakker om dette og illustrerer hvordan man bør gjøre det....

 

Jeg gjør det hele tiden. Når man refaktorerer kode, så gjør man samtidig koden mye mer lesbar, ved å gi så beskrivende metodenavn som mulig.

Jeg er enig i at en metode skal ha et beskrivende navn, men executeProcedureIfPersonLikeCookies() er ikke det. Det ser heller ut som dårlig programmering.

 

Istedet for:

 

    executeProcedureIfPersonLikeCookies();

ville jeg skrevet noe slik:

 

    if (personLikeCookies()) {
        BakeCookies();
    }

Her måtte jeg gjette hva slag prosedyre som skal utføres hvis man liker Cookies ...

 

Du kan ha rett. Eller du kan ha feil. Det kommer helt an på. Sånn er det alltid. Det beste vi kan gjøre er å lytte til folk som har programmert lenge (som forfatterne av bøkene jeg nevnte), og så forsøke å erfare selv hva som fungerer i ulike situasjoner. Etter å ha programmert daglig i 30 år - og hele tiden ha forsøkt å reflektere over hva du gjør og hvorfor du gjør det - så velger du forhåpentligvis det beste 9 av 10 ganger

Poenget er: Det er sjelden en fasit på hva som er god kode, og jeg synes ikke man fremstår så veldig bra om man påstår at man vet hva som er best.

Min erfaring med kodebaser hvor man har fulgt det Uncle Bob sier om veldig små metoder er derimot at det etterhvert blir veldig vanskelig å følge logikken. Min tommelfingerregel - som er enklere å si enn å forklare og å forstå - er at all kode som man må forstå samtidig bør befinne seg på samme sted. En annen måte å si det på er at en metode (eller prosedyre eller funksjon) bør inneholde all koden som har samme abstraksjonsnivå, men skjule all kode som er på et lavere abstraksjonsnivå.

Gir det mening for noen?

Usikker på om dette er bøker for nybegynnere, men.

For alle disse tre bøkene så følte jeg når jeg leste dem at jeg burde ha lest dem tidligere i karriæren. Kanskje de ikke er for folk som akkurat har begynt å lukte på programmering (som i for et par uker siden), men den dagen du begynner å gjøre det på orntlig (som at du får deg en programmeringsjobb) så bør disse bøkene eller noe tilsvarende ligge på nattbordet.

...etter min mening

Kontrollspørsmål: Har du konstanter at de ulike trådene eksekveres på ulike kjerner?

Det gikk akkurat opp for meg at dere har kalt tjenesten for iSocial. Dere vet kanskje at det allerede er flere ting som heter det fra før?

http://www.isocial.no/ - jeg går ut fra at dette ikke er dere?!

http://isocial-itn.eu/

Forsøk også http://www.isocial.com - ser ut som om den redirecter til ulike ting, noen av dem not safe for work

Oy, var ikke klar over at en youtube-lenke ble gjort om til en embedded video

Har noen av dere forslag til en god bok, eller en nettside ala den jeg allerede bruker til å lære meg C#? Liker bedre å lese enn å høre på folk snakke.

 

Kan sikkert betale, men foretrekker gratis.

Når det kommer til spillprogrammering vet jeg ikke helt hva jeg snakker om, men jeg kunne tenke meg å eksperimentere med MonoGame selv, og har googlet etter tutorials:

• https://github.com/mono/MonoGame/wiki/Tutorials
• http://monogame.net/taxonomy/term/35
• http://rbwhitaker.wikidot.com/monogame-tutorials
• (flere episoder her)