How to avoid Play Framework killing performance

  Note: This article is about Play Framework 1.2.x and might not apply to Play 2.x projects. The other day I had to convert some code from C to Java. This code runs some pretty simple calculations, using a few classes as data-holders, and running a few thousand iterations. I had to get this working as part of the backend for a Play Framework web application. In C the code would run blindingly fast, and return the results within 10-20 milliseconds. All good! After a couple of hours of converting the code and fixing the pointer/reference/initialization oddities between Java and C, I got the code running. Well, more like walking, or lazily sauntering along. The Java code took 4 seconds to run. I know Java is perceived to be slow, but my experience with it was telling me that there is no way it should be so slow. I had a look at the Java code. Lots of Math.Pow(), Math.sqrt() calls, a lot

read more How to avoid Play Framework killing performance

Pragmatic OOP

In my last blog post I talked about people pushing a process as the magic bullet when it is the people that matter. Having the wrong people on a team can cause havoc and kill a project. Sometimes these wrong people are cargo cult programmers. According to Wikipedia: ‘Object-oriented programming (OOP) is a programming paradigm using “objects” – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.’ OOP is supposed to be a practical way to organize a program into hierarchies of objects where similar objects can inherit behavior from each other and override that behavior when necessary. Objects can also contain other objects and that is a technique called composition. Certain programmers pick up OOP and fall in love with the rule-set without fully understanding it, or they over-apply the principles. These people are cargo cult programmers.

Don’t optimize!

Actually you should optimize, but not at the wrong places, or for the wrong reasons. But I’ll get back to that in a minute. I recently released a small XNA-based game together with my friends at Badgerpunch Games, and have been following the indie game development community through forums and twitter. Game developers are very concerned about performance, mostly for good reason. No one wants a game with choppy framerate. Because of all this worrying about performance, there is an array of optimization tips and articles that get passed around to alleviate the problem. The majority of the tips and articles are informative and useful, but hardly any of these articles touch on the main issue of optimization: When not to optimize and why not.

FindBugs for statisk analyse av kode

For de fleste programmerere er det viktig å finne defektene i koden man produserer, slik at kvaliteten er høyest mulig. Man har ikke lyst til å gi ut programvare som er full av feil. Men et trist faktum er at de aller fleste programmer har defekter. Undersøkelser viser at kommersielle programmer har i snitt 20-30 bugs per tusen linjer kode. Det er mange forskjellige typer defekter i kildekode, og noen er mindre kritiske for programkjøring enn andre, men alle feil bør finnes og fikses. Det finnes en del metodikker som kan senke feil-frekvensen. Noen eksempler på disse er Extreme Programming,Test Driven Developmen og Code Review Disse metodikkene er fullverdige metoder for å øke kvaliteten på programvaren man produserer, og bør vurderes som en del av den totale utviklings-modellen. Det er flere måter å finne bugs i kode. Et av disse er statisk analyse av koden. Statisk analyse er å gå gjennom koden og lete etter kjente mønster som indikerer feil,

read more FindBugs for statisk analyse av kode

Integrerte utviklingsverktøy

Jeg har installert Linux hjemme med diverse hjelpeverktøy for utvikling. Mest fordi jeg er en tekno-junky, men også fordi jeg liker å pludre litt med ting hjemme som kan hjelpe meg å gjøre jobben min bedre. På Linuxen min har jeg installert Subversion, DokuWiki, Bugzilla, CruiseControl, og MySQL. Jeg har konfigurert opp disse programmene slik at jeg kan sjekke inn kildekode i Subversion, så henter CruiseControl ut den koden og kompilerer den og sender meg en epost hvis den ikke greier å bygge det prosjektet kildekoden hører til. Jeg har brukt DokuWiki til å kjapt kunne skrive ned spesifikasjoner og notater om ting jeg holder på med, og dermed ha dem lett tilgjengelig til senere. Bugzilla har jeg ikke brukt mye enda, men det er meningen at den skal hjelpe meg å holde oversikt over bugs i prosjektene mine. Alt dette er vel og bra. Jeg har stort sett det jeg trenger til å kunne utvikle et produkt og holde

read more Integrerte utviklingsverktøy

Er alle programmeringsspråk skapt like?

Ifølge denne artikkelen er ikke alle programmeringsspråk like kraftige. Noen er mye bedre enn andre. Det er vanskelig å ikke være enig etter å ha lest artikkelen. Han sier at man lett kan kjenne igjen språk man kan som ikke er så kraftige som språket man bruker i dag, men at det er umulig å vite om språk man ikke har erfaring med er bedre. De virker kanskje bare rare. Jeg tror det er på tide å lære noen nye programmeringsspråk.

Continuous Integration

Jeg kikket på Continuous Integration artikkelen til Martin Fowler for et par uker siden og oppdaget at han hadde oppdatert den ganske kraftig tidligere i år. Nå inkluderer den litt mer tidsriktig informasjon, som f.eks. å anbefale Subversion til versjonskontroll. Kort fortalt handler artikkelen om hvordan man får ned antall bugs i kode, og minimalisert stresset forbundet med integrering av moduler til en fungerende build, ved å integrere hele tiden. Det gjøres ved at man har en såkalt ‘build server’, som Cruise Control. Denne programvaren sørger for å bygge hele løsningen og kjøre tester, automatisk og så ofte som mulig, enten på bestemte tidspunkt, eller når noen sjekker inn ny kode i versjonskontroll-systemet. Hvis noe går gale får de ansvarlige utviklerne beskjed i form av e-post eller, hvis de vil, kan de sjekke resultatene av byggingen på en vevside som genereres av Cruise Control. Artikkelen forklarer fordelene ved å gjøre dette, og hvordan få det til i praksis. Jeg har

read more Continuous Integration