Dagbog-bloggen

Praktikforløb for en datamatiker

Hos Kviknet er vi så heldige, at vi snart får en datamatikerstuderende i erhvervspraktik.

Praktikforløbet varer 3 måneder, og det er meningen, at vores praktikant skal lære en masse om programmering og opbygning af IT-systemer.

Min opgave er nu at udarbejde en fornuftig praktikplan, og jeg indbyder læserne til at komme med gode råd og tips undervejs.

Forventningsafstemning

Når vi som virksomhed opretter en praktikplads, er det en investering i fremtiden. Selv om en praktikant ikke koster løn, skal der stadig stilles arbejdsplads, frokost o.l. til rådighed, og jeg forventer, at vi skal bruge en del tid på selve undervisningen.

Til gengæld er der måske en chance for, at vi kan bruge praktikanten som udvikler engang i fremtiden, og uanset hvad, er det nok sundt for virksomheden, at vi får styrket vores rutiner til overlevering af viden.

Et godt samarbejde med de lokale uddannelsesinstitutioner kan også være med til at sikre os et fornuftigt rekrutteringsgrundlag i fremtiden.

Praktikanten kommer med en grundlæggende viden om programmering i C#, og han har stiftet bekendtskab med PHP, JavaScript, jQuery og .NET under introforløbet på uddannelsen.

I vores virksomhed kan han bruge PHP, JavaScript og jQuery, men vi har ingen Windows-servere og regner heller ikke med nogensinde at få det.

Udgangspunktet vil derfor være, at vores praktikant skal arbejde med en LAMP-stack, men muligvis med nginx som webserver - også kendt som en LEMP-stack.

Man bliver ikke ekspert i noget som helst på 3 måneder, så vi skal sammensætte et forløb, hvor praktikanten bliver klædt på til at fortsætte sin uddannelse på egen hånd efterfølgende.

Af egen erfaring ved jeg, at fiktive opgaver ikke er særlig spændende, så vi planlægger nogle opgaver, der har en reel værdi for virksomheden, hvis de bliver løst.

Praktikantopgaven - en microservice i en sandkasse

Som beskrevet i et tidligere blogindlæg er en stor del af vores kodebase monolitisk, og det giver indlysende nogle problemer, hvis man skal have en uerfaren udvikler ind og rode i systemerne.

Derfor lader vi vores praktikant udvikle en microservice, som fungerer uafhængigt af vores andre systemer, og som blot modtager et read-only feed af den type data, der skal bruges for at løse den givne opgave.

Opgaven kan fx være at udvikle et værktøj til analyse af fakturadata eller tracking af RMA-sager på vores hardware.

Vores praktikant har gennem længere tid arbejdet i vores kundeservice, så han har allerede et godt kendskab til virksomhedens rutiner og behov, hvilket vil hjælpe ham en del, når han skal løse opgaven.

Vi skal dog have ham klædt ordentligt på i PHP, før han kan gå i gang, og derfor forestiller jeg mig et introforløb, hvor vi gennemgår følgende områder:

Udviklingsmiljø:

  • Opsætning af IDE
  • Opsætning af LAMP-stack på testplatform

PHP:

  • Strenghåndtering, aritmetik og arrays
  • Tegnsæt (UTF-8 vs ISO-8859-1)
  • Database (MySQL) - herunder sanitering af input
  • Basic HTTP (headers m.v.)
  • Objektorienteret PHP
  • Dataudveksling - herunder XML og JSON

Microservices:

  • RESTful API

Er der andet, vi mangler, og som er realistisk at nå på 3 måneder?

Relateret indhold

Kommentarer (58)
Magnus Lund

Med fare for at I allerede har tænkt det ind:

En eller anden form for Kanban-board-agtig ting, så praktikanten kan prøve at bryde opgaverne ned i features/bugs osv. og kan kommunikere hvor langt tingene er.

Hvis I har mulighed for det - så lad vedkommende bruge noget GroupWare/Versionsstyring så der kan kommenteres hvilke features et commit vedrører osv.

Men ellers er det fedt at I giver opgaver som rent faktisk skal bruges til noget.

Yoel Caspersen Blogger

Hvis I har mulighed for det - så lad vedkommende bruge noget GroupWare/Versionsstyring så der kan kommenteres hvilke features et commit vedrører osv.

Jeg har overvejet at inddrage Git, da det er det, vi bruger hos Kviknet. Men taget i betragtning hvor kompliceret, jeg selv finder Git, er jeg lidt usikker på, om det er for svært og tager for meget fokus væk fra selve programmeringen. Subversion er dejlig simpelt til sammenligning, men det virker som en blindgyde at bruge tid på en teknologi, der er på vej ud.

Skal vi inddrage Git i vores introduktionsforløb?

Yoel Caspersen Blogger

Vores praktikant kommer nok til at arbejde på en Ubuntu-baseret computer. Hvilket IDE skal vi introducere ham for?

Selv har jeg gode erfaringer med Netbeans, men det er stort og tungt, og der er ganske givet bedre alternativer derude.

Jeg sætter selv pris på følgende elementer i et IDE, der skal bruges til PHP:

  • Syntax highlighting
  • Code completion
  • Code formatting (med valg af en given standard)
  • Integration til Git/SVN
  • SFTP-upload til webserver m.v.

Det skal være open source.

Junior Ronnie

Måske er det en idé at lade ham lære lidt omkring type håndtering og php mærklig måde at håndtere dem på.
Her tænker jeg eksempel på at strpos kan returnere både boolean og int :? (Får dårlig mave bare at tænke på det)

Som IDÉ synes jeg bedst om PHPStorm men hælder lidt mere til Ecilpse

Yoel Caspersen Blogger

Her tænker jeg eksempel på at strpos kan returnere både boolean og int :? (Får dårlig mave bare at tænke på det)

Ah ja, klassikeren med == som sammenligningsoperator og === hvis man skal være helt sikker.

Jeg er fristet til at starte med den klassiske PHP: a fractal of bad design, men omvendt er jeg ikke sikker på, jeg selv ville have lyst til at lære en masse om PHP efterfølgende, hvis det var mig der blev introduceret til sproget på den måde.

Men det er da nok en god ide lige at nævne de værste af PHP's gotchas.

Michael Hansen

"grundlæggende viden om programmering i C#," C# er nu på ingen måde windows only, det kører fint og er supported på både Linux og Mac (det samme med asp.net mvc fx), der er en del der bygger microservices med C#, der kører på docker instances på Linux etc..

Men ja ikke super relevant når i nu kører PHP :)

Yoel Caspersen Blogger

C# er nu på ingen måde windows only, det kører fint og er supported på både Linux og Mac

Der blev jeg faktisk en smule klogere, og tak for det. Er der tale om reelle cross-platform-systemer eller er det mere et spørgsmål om at gøre det, fordi man kan?

Jeg har selv bygget indtil flere socket servers i PHP, men jeg vil ikke anbefale andre at gøre det samme, da PHP er det forkerte værktøj til formålet. Kan situationen sammenlignes med C# på Linux - eller er C# vitterligt brugbart på tværs af platforme?

Claus Juul

Lad han gennemgøre nogle interviews med dem der bruger jeres produkter (kunder) eller dem som arbejder med de interne processer.
Se om han kan finde nogle forbedrings muligheder og lave en PoC/beta udgave af noget software der kan forbedre forretningen.

Michael Hansen

Er der tale om reelle cross-platform-systemer eller er det mere et spørgsmål om at gøre det, fordi man kan?

Det er ikke som i gamle dage, hvor det under linux krævede mono, som ikke var officielt supported af microsoft, det er ikke længere tilfældet (ikke baseret på mono / er supporteret af ms):
https://www.microsoft.com/net/core#linuxubuntu

(Vi snakker ikke om GUI applikationer, men console/web), kender flere der udvikler microservices der kører på Linux.

asp.net mvc core, kører via kestrel (baseret på libuv fra node.js), det er fuldt cross platform og optimeret til hastighed, det vil typisk blive reverse proxiet fra apache/nginx.

Jørgen Elgaard Larsen

Det er naturligvis nemmest at lade jeres praktikant arbejde med et lille, afgrænset projekt.

Men den største læring vil efter min mening ske, hvis han får lov til at arbejde med eksisterende kode.

Han behøver ikke at være i praktik for at små projekter. Derimod er praktik en enestående mulighed for at opleve, hvordan mange mennesker arbejder sammen om en kompleks kodebase, og hvordan man strukturerer kode, der skal kunne vedligeholdes.

Så kast ham endelig ud i git, issue tracking, komplekse systemer, linux og alt hvad der er nødvendigt for at arbejde med jeres systemer.

Han behøver jo ikke at forstå alting til at starte med. Lad ham starte i et hjørne og tage fra i det omfang, han kan.

Lad ham deltage i parprogrammering og i reviews af andres kode. Og lav reviews på hans kode på lige fod med andres.

Morten Toudahl

Hvis han er fra EASJ, så behøves du ikke bruge tid på at introducere gense netværks protokoller, eller API's. Hverken soap eller rest baseret.

Medmindre han/hyn har sovet i timen selvfølgelig... :-)

I skal også huske på at han/hun nok også gerne vil lave et hovedeprojekt med jer.

Jeg endte i hvert fald med også at lave mit hoved projekt ved institut for miljøvidenskab. Så for mig var jeg 7-8 måneder det samme sted. Hvilket gav mig nok tid til at lave noget de har lagt i produktion, som erstatning for tidligere systemer.

Morten Toudahl

Jeg kan se at der også bliver foreslået ting som er helt basale i uddannelsen.
Projekt styring.
Scrum/kanban boards
Versionsstyring

De ting har været brugt aktivt siden 2. semester på EASJ.

Ud fra det arbejde jeg har lavet med akkreditering af andre skolers datamatiker uddannelse vil jeg vove den påstand at du kan forvente at alle datamatiker praktikanter kan de her ting.

Patrick Kerwood

Hvis der skal arbejdes i JavaScript/TypeScript vil jeg varmt anbefale Visual Studio Code.
Jeg er inkaraneret Linux bruger og havde aldrig regnet med at jeg skulle installere et Microsoft produkt på min maskine. Men VS Code er virkeligt et godt værktøj, plus det er open source -> https://github.com/Microsoft/vscode

Jeg vil anbefale at kigge på Docker/containerized environments, da det helt sikkert bliver en stor del af fremtiden. Du kan faktisk lave apps i .Net Core + C# og deploy dem i containers på en Linux server.

Han kan evt. tjekke min blog igennem for Linux guides. Den er lidt gammel men jeg prøver holde den i live. Der er bla. nogle NGINX guides også.

https://linuxbloggen.dk/

Anders Urban

Jeg er selv datamatiker studerende(4. Semester) fra UCN i Aalborg og vil sige, at når det kommer til versions styring så brugte vi det fra dag et, vi startede med subversion og fra andet semester brugte næsten alle Git og github.
Så vil bestemt ikke mene at det burde være svært for ham at bruge Git, tværtimod vil jeg mene at det kun vil hjælpe ham.

Ved UCN kørte vi UP de første to semestre og tredje semester kørte vi scrum. Nu ved jeg ikke hvordan hans skole køre det, men han burde have stiftet bekendtskab med både UP, scrum og kanban.

Tim Lund

Jeg har selv brugt netbeans i ~5 år, det er et udemærket værktøj, især til nybegyndere. Den er heller ikke så tung som Eclipse.

Jeg vil dog til hver en tid selv vælge PhpStorm, men nu har jeg nok også lidt flere behov end en nybegynder :)

Tim Lund

Jeg kan anbefale at lære dem at bruge debugging værktøjer (som dem der er i netbeans) sammen med xdebug.
Print debugging er spild af tid, man kan ligeså godt lære at debugge korrekt fra starten.

Claus Pedersen

Helt enig.

Vi lader altid vores praktikanter indgå i vores daglige projekter.

Dels giver det praktikanten en bedre idé om hvordan udviklingsprojekter reelt forløber, end hvis de sidder med deres egen lukkede opgave (som de jo også gør på skolen).

Dels er det nemmere at give sparring, hvis mentoren arbejder tæt sammen med praktikanten på det samme projekt.
De kan med fordel få små del-opgaver og kan på den måde være med til at løse de projekter som de fastansatte sidder med.

Det giver også en bedre idé om praktikanten er værd at satse på til en fast stilling fremadrettet.

Peter Rosenberg

I har vel allerede en vis standard for, een eller flere af:
- Kodekommentarer (Prolog / Epilog)
- Pseudokode, der kan afprøves ved skrivebordet
- UML eller ObjectOrienterede Beskrivelser (UML er måske lidt vel stort at inkludere i 3 mdr forløb)
- Jeres egen minimumsstandard.
Skriver i på Engelsk eller Dansk osv... Skabeloner

Men ellers er det en god måde at starte op i en virksomhed på.

mvh

Yoel Caspersen Blogger

Lad han gennemgøre nogle interviews med dem der bruger jeres produkter (kunder) eller dem som arbejder med de interne processer.
Se om han kan finde nogle forbedrings muligheder og lave en PoC/beta udgave af noget software der kan forbedre forretningen.

Spændende forslag, der faktisk rummer en vigtig pointe: En succesfuld programmør har ikke kun styr på sin kodning, men forstår også sin betydning for forretningen og vil selv kunne identificere de steder, hvor indsatsen gør størst gavn.

Det er nok en helt generel ting i erhvervslivet - uanset hvor specialiseret man er inden for sit fag, har man en kæmpe fordel, hvis man intuitivt forstår forretningen og hvordan man forbedrer den.

Yoel Caspersen Blogger

Han behøver ikke at være i praktik for at små projekter. Derimod er praktik en enestående mulighed for at opleve, hvordan mange mennesker arbejder sammen om en kompleks kodebase, og hvordan man strukturerer kode, der skal kunne vedligeholdes.

Så kast ham endelig ud i git, issue tracking, komplekse systemer, linux og alt hvad der er nødvendigt for at arbejde med jeres systemer.

Jeg forstår og har fuld sympati for synspunktet - og i det omfang, det kan lade sig gøre, vil han også kunne kigge på vores eksisterende kode, deltage i fejlfinding og lignende.

Vores udfordring er dog, at vi som en mindre iværksættervirksomhed ikke har bemanding til at have en medarbejder allokeret til ham hele tiden - så der vil være behov for, at han i perioder kan sidde med sit eget projekt uden at skulle være afhængig af en anden medarbejder.

Det er nok nemmere at opnå den optimale attention som praktikant i en lidt større virksomhed, hvor der er flere specialiserede udviklere, som man kan hægte sig på.

Joseph Petersen

Istedet for at bruge tid på SFTP, hvad så med at lave et setup for ham med lidt automation.
Når han skubber sine commits ind, få automation til at tage det igennem statisk kode analyse, kode stil tjek og hvis han skal lave REST API så kig på at bruge postman sammen med automation.
Eventuelt med unit tests.

Efter det er kørt igennem så deploy det på jeres dev webserver.

Det kan være med til at give bedre kvalitet og give tryghed omkring det arbejde der bliver udført.

Niels Buus

Nu kender jeg jeres monolit, men hvis I alligevel skal til at splitte den ad, så forstår jeg ikke hvorfor I ikke benytter lejligheden til at udforske nye sprog.

Det kunne være Java, Python, Ruby eller noget andet hæderligt.

Når nu at der er bred anerkendelse af at PHP er nitten, hvorfor fortsætter man så med at prutte mere kode ud?

Hvis I får afviklet jeres PHP platform til fordel for f.eks. Ruby on Rails, så bliver det måske også nemmere at tilstrække kvalitetsbevidste udviklere. :-)

Per Bellfield

Jeg brugte selv Eclipse i min praktik/afgangsprojekt, og føj hvor jeg havde jeg ønsket at PhpStorm var tilgængelig på det tidspunkt.
PhpStorm er helt klart at anbefale hvis man som virksomhed kan smide de penge efter en licens til en praktikant. De er ikke helt billige, men 1500kr for et års licens er givet godt ud hvis der alligvel er tanker om potentiel fremtidig ansættelse.

Har i andre udviklere? Hvad bruger de af IDE?
Hvis det er et projekt i starter fra bunden, tænker jeg at det vil være en rigtigt god idé at sørge for at bruge PhP 7, og ikke 5. Jeg er ikke sikker på at alle stacks er opdateret endnu.

Alex R. Tomkiewicz

Er det ikke meningen at praktikanten skal lære noget om virkeligheden og få erfaring med hvordan vedkommendes teoretiske indlæring kan omsættes til praktiske resultater? Og måske endda noget der kan bruges til noget i praksis i virksomheden?

Hvad praktikanten har lært på skolen kan skolen eller praktikanten oplyse om og så kan opgaverne justeres til dette. Jeg ser ikke den store idé i at opfinde teknologiske udfordringer som praktikanten enten ikke kan bruge, som praktikanten ikke kender fra skolen eller som ikke vil være praktisk anvendelige som produkt.

En vinkel jeg som projektleder og manager har fundet brugbar er at tage udgangpunkt i en virkelig opgave som skal løses. Det kan være en opgave hvor der skal findes en løsning og en implementering - eller en opgave hvor løsningen er givet og en brugbar implementering skal findes. Lad praktikanten lave et forslag til løsning og/eller implementering. Et sådant forslag kan du eller en seniorudvikler vurdere - er det brugbart og kan det implementeres - især kan det implementeres af praktikanten og med hvilken hjælp? Det vil være en case fra virkeligheden som alle parter kan bruge. Jeg har alt for ofte fundet at både skoler og studerende har sprunget alt for let hen over disciplinen omkring at kunne formulere og beskrive forslag og også at kunne udfærdige teknisk dokumentation. Det leder også på længere sigt hen mod at kunne lave business cases.

Under vurderingen kan man så i fællesskab diskutere valg af teknologi, hvis der er flere muligheder, f.eks. programmeringssprog, platform, kodestruktur, API design m.v.

Når der foreligger en beskrivelse - og tidsplan - som er godkendt, kan praktikanten prøve kræfter med selve implementeringen. Her kan det så være at praktikanten skal have mere viden om PHP værktøjer, brug af git, tegnsæt, JSON dataudveksling m.m. Men det bliver synligt og overskueligt gennem formuleringen og diskussionen af opgaven og implementeringen. Og så kan man lave reviews undervejs for at se hvordan tingene går.

Nikolaj Brinch Jørgensen

Jeg synes det er essentielt at han/hun laver automatiserede tests for det kode han/hun udvikler. Det undrer mig det ikke er nævnt?
Værktøjer (IDE etc.) er krydderi. Smart Editors som Sublime, Atom, Visual Studio Code osv. er rigeligt fine - men det handler om at forstå og lære, og der kan IDE hurtigt blive en kompleks størrelse der står i vejen for at vide/lære hvad der egentlig forgår.

PHP er en skidt platform i mine øjne, men lad det ligge hvis det er jeres valg. Java (Java 8, Clojure, Scala, Frege), Python eller C# ville jeg nok vælge. Hvis det er en REST baseret microservice, er platformen jo også ligegyldig, og der kan drages fornuftige erfaringer med en ny platform, hvis i allerede benytter PHP.
Det samme gælde database. Er RDBMS egentlig egnet, eller ville Cassandra f.eks. være et bedre alternativ? Er Elasticsearch et bedre alternative til opbevaring af data som skal analyseres? Er Apache Spark måske værktøjet til analysering?

Det kunne jo være en læring, at man i dag ikke skal programmere en hel masse selv, men derimod benytte sig af de enormt mange open source komponenter der er lavet, og så få dem til at spille sammen til en fornuftig og brugbar løsning.

Men det er klart, at der skal benyttes noget tid til det basale, test, kvalitetsmålinger, versionsstyring, build automation, UTF-8, REST osv.
Samt selvfølgelig reviews.

Morten Mathiasen

Der er mange gode forslag her i bloggen til at tilføre praktikanten viden fra virksomheden. Prøv dog også at tænke praktikantens kompetenceområder ind i berigelse af virksomhedens udvikling.
Kig igennem virksomhedens ønskeliste for metoder, teknologier el. lign., som der endnu ikke har været tid til at afdække. Det er super motiverende for en datamatikerpraktikant at kaste sig over et sådant ønske, f.eks. indenfor test, programmeringssprog, versionsstyring, udviklingsmetode, projektstyring eller noget helt andet.

Peter Christiansen

Jeg kan ikke se problemet med REST + mysql eller hvilken som helst anden db backend der kan løse opgaven.

Ville gerne vide hvad de ellers skulle gøre. De fleste seriøse API'er er i dag RESTful med data som json eller xml, med overvejende vægt på json da det fylder mindre og er lettere at parse.

Hører gerne hvad folk mener er bedre / nemmere.

Morten Hansen

Jeg er selv uddannet Datamatiker for en del år siden - men bruger ikke php. Andre må gerne korrigere mig, men jeg mener også at der indenfor php bruges packages - så almen installation og søgning efter packages kunne jeg da godt foreslå (https://packagist.org/ https://thephpleague.com/ https://www.npmjs.com/)

Derudover nogle små hints om mappestrukturer i softwareprojekter, hvis man alligevel bruger IDEer som Atom eller Eclipse hvor der er mulighed for at have en hvis struktur over sine filer i projekter.

Yoel Caspersen Blogger

Nu kender jeg jeres monolit, men hvis I alligevel skal til at splitte den ad, så forstår jeg ikke hvorfor I ikke benytter lejligheden til at udforske nye sprog.

Det gør vi skam også - jeg synes dog ikke, vores praktikant skal kastes ud på dybt vand i et sprog, vi ikke kan hjælpe ham med, fra dag 1. Men jeg er da enig i, at det kunne være en interessant øvelse senere i forløbet.

Det kunne være Java, Python, Ruby eller noget andet hæderligt.

Jeg har overvejet Python ud af ren akademisk interesse, men de seneste benchmarks tyder på at PHP 7 performer voldsomt meget bedre end Python rent hastighedsmæssigt.

Fra en kommerciel vinkel er der følgende kriterier:

  1. En anden udvikler i virksomheden skal kunne vedligeholde koden efterfølgende
  2. Det skal være nogenlunde nemt at finde nye folk, der kan arbejde med de samme sprog

Java-udviklere er der mange af, da mange uddannelsesinstitutioner insisterer på at basere store dele af undervisningen på Java, men jeg har stadig til gode at se et website med høje trafikmængder, der kører Java. Ruby on rails har jeg ikke noget forhold til, men det er ikke mit indtryk at der findes voldsomt mange udviklere at vælge imellem.

Claus Pedersen

Vores udfordring er dog, at vi som en mindre iværksættervirksomhed ikke har bemanding til at have en medarbejder allokeret til ham hele tiden - så der vil være behov for, at han i perioder kan sidde med sit eget projekt uden at skulle være afhængig af en anden medarbejder.

Vi har heller ikke ret mange folk. Faktisk har vi nogle gange flere praktikanter end vi har faste.
Min erfaring er at det hjælper hvis praktikanten bare sidder ved et bord ved siden af den faste, og er vedkommendes lille hjælper.
På den måde er det ikke et stort fokusspring hvis praktikanten har brug for assistance, da det er et delelement til en opgave som den faste alligevel sidder med.

Det er også en stor fordel hvis man har mere end én praktikant, da de så kan sparre med hinanden før de skal spørge en af de faste.

Peter Christiansen

Jeg er selv blevet glad for "go", har lavet en del web api'er i det.

God understøttelse for div. sql backends mysql, sqlite, postgreSQL mfl. og rigtig godt til web generelt. Det har garbage collection og kræver ikke kæmpe runtime libraries.

Det excellerer hvis du skal lave web services.

Jeg bruger selv modulet "gopkg.in/gin-gonic/gin.v1" til web api'er og er meget glad for hvor ligetil det er, uden for meget boilerplate kode.

Det er ikke objektorienteret hvilket jeg ser som et plus. Dog kan man inddele koden i pakker for at gøre det mere overskueligt hvis man har mange del elementer.

Og til jer oldschool boys, er der nogen der mener at go minder om algol 68!!
https://cowlark.com/2009-11-15-go/

Whats not to like :D

Niels Buus

Jeg har overvejet Python ud af ren akademisk interesse, men de seneste benchmarks tyder på at PHP 7 performer voldsomt meget bedre end Python rent hastighedsmæssigt.

Hvis du laver benchmarks som fokuserer på rene cpu-bundne opgaver, så ligger PHP7 godt. Som i virkelig godt. Det har virkelig fået et løft.

Men jeg synes måske du simplificerer dit valg, hvis du alene fokuserer på fortolkerens performance i benchmarks.

Det er fagligt interessant, men forretningsmæssigt uinteressant, med mindre man er en fortune 500 virksomhed (eller har hostingomkostninger i millionklassen)

Hvis du er en almindelig virksomhed hvor målgruppen for din applikation er, i bedste fald, et par hundrede SAMTIDIGE brugere, så er sprogets ydelse ikke særligt interesant. Det skyldes at forskellen mellem et langsomt og hurtigt sprog måske kommer til at betyde nogle få tusinde om måneden i ekstra hostingomkostninger pga. dyrere hardware til at kompensere for det "ineffektive" sprog.

Dit vigtigste parameter er produktivitet.

Den største udgiftspost du har er din udvikler og hvis han/hun koster 50.000 kroner om måneden, så betyder det at hvis Framework A er 30% hurtigere at udvikle i end Framework B, så betyder det en forskel på 15.000 kroner om måneden i udviklingsomkostninger.

Og har du et hold af udviklere, f.eks. 5 stk. Så kan du jo gange med 5, og så bliver det 75.000 kroner dyrere hver måned at vælge det dårligere framework. Det er en lille million hvert år.

Som Ruby on Rails udvikler vil jeg våge den påstand at jeg kan slå de fleste Laravel (PHP) udviklere på produktivitet og jeg vil også våge den påstand at kvaliteten af min kode er højere og med færre bugs, fordi Ruby ikke modarbejder mig på samme måde som PHP gør det.

Anders Pallisgaard

jeg har stadig til gode at se et website med høje trafikmængder, der kører Java

Nærmest alle de små og mellemstore banker i Danmark serverer deres netbank fra en java-backend (det gjorde de i hvert fald for ca. 4-5 år siden da jeg arbejde i den branche, og jeg tvivler på at de kan lave en business case på at omskrive alt deres java til et andet sprog - ligesom de også stadig har en mainframe). Jeg ved ikke hvad Nordea og Danske Bank gør, men det ville ikke undre mig hvis de også har java i deres backend.

Uden at kende jeres forretning (ud over at I er en mindre virksomhed), så er jeg sikker på at både Java, Python og PHP performer tilstrækkeligt til jeres behov.

Anders Pallisgaard

jeg vil også våge den påstand at kvaliteten af min kode er højere og med færre bugs, fordi Ruby ikke modarbejder mig på samme måde som PHP gør det

Det er noget af en påstand :-)

Jeg vil vove den påstand at kvaliteten af koden i langt højere grad har noget at gøre med personen bag skærmen, end det har at gøre med det højniveau-sprog der udvikles i.

Yoel Caspersen Blogger

Men jeg synes måske du simplificerer dit valg, hvis du alene fokuserer på fortolkerens performance i benchmarks.

Hvis jeg skal investere min egen tid i at lære et nyt sprog, skal der være et eller andet, der tiltaler mig ved det pågældende sprog, da de sprog, jeg kan i forvejen, herunder PHP, i høj grad kan løse de opgaver, jeg står over for - også selv om PHP indeholder et væld af dårlige designvalg m.v.

Og personligt har jeg altid været meget fascineret af tanken om at presse hardwaren til det yderste, og jeg krummer tæer ved tanken om at køre software, som spilder hardwarens ydeevne på gulvet - også selv om det i kroner og øre ikke kan betale sig at optimere softwaren. Det føles i bund og grund bare forkert.

Det er en af grundene til, at jeg kraftigt overvejer Python - sproget giver så vidt jeg husker mulighed for at outsource performance-kritiske delelementer til C, og jeg har altid ønsket mig et program, der kan ophæve tyngdekraften.

Andre sætter større pris på produktivitet end på hastighed - og det er også en helt valid præference. Men hvis jeg udelukkende skal se på den forretningsmæssige side af sagen i vores virksomhed, skal vi bare holde os til PHP, da det fungerer godt nok, og det er nemt at finde udviklere, der kan arbejde med det.

Rene Nejsum

Jeg er selv en stor fanboy af Python/Django og kan derfor kun anbefale det, man bliver virkelig gladere af at udvikle i Python :-)

Jeg har lige været med til at udvikle et større bank produkt i Django. Teamet på 4 personer (3 dev, 1 design) gjorde det på under en måned, et job som jeg er sikker på at en bank IT afdeling nemt kunne have fået meget mere tid til at gå med i fx. Java.

Alex R. Tomkiewicz

Og personligt har jeg altid været meget fascineret af tanken om at presse hardwaren til det yderste, og jeg krummer tæer ved tanken om at køre software, som spilder hardwarens ydeevne på gulvet - også selv om det i kroner og øre ikke kan betale sig at optimere softwaren. Det føles i bund og grund bare forkert.

Man kan med stor fordel arbejde med sine følelser, hvis man har det sådan :-)

Det vigtige er den samlede økonomiske vurdering og implementering - økonomi taget som et bredt begreb omkring den bedste anvendelse af begrænsede ressourcer.

Jeg vil til hver en tid optimere min problemløsning og softwarens løsningsmæssige effektivitet, før jeg optimerer kodens tekniske performance. Men jeg er også mærkelig :-)

Glenn Dufke

Så vil jeg tillade mig at række hånden op og sige; hvad med Object Pascal?
Let forståelig og stærk syntaks, ægte nativ kode der kan cross-compiles til mange forskellige platforme og arkitekture.
Siden praktikanten allerede har haft fingrene i C Skarp vil det være nemt for ham at komme i gang :)
Godt nok er jeg biased ved at være medudvikler på Smart Pascal sproget, men det gør simpelthen livet så meget nemmere at programmere til en JSVM (Ja, den er god nok, Object Pascal kode der transpileres til JavaScript eller node.js for den sags skyld) :)

Log ind eller Opret konto for at kommentere