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.

Continue reading “Don’t optimize!”

Game developer, and then what?

Wow, it’s been almost two years since Darkfall (Online) was released!

I was involved from the very beginning, in 1999 when we were a bunch of young inexperienced guys with a a dream of making “the best game evah” ™. We started a company here in Norway in 2000, moved to Greece in 2003 and released Darkfall, a badass full-loot player versus player  mmo, on the 25th of February 2009. That pretty much amounts to 10 years making one single game. Continue reading “Game developer, and then what?”

Maven Dependency Management (Deptools)

Dependency management in Maven is a tricky business. At the company where I work we have several large projects that include many different libraries and all dependencies are managed by Maven.  These projects end up having transitive dependencies where the libraries our projects depend on have dependencies on yet other libraries.

Maven does a good job of including all the transitive dependencies, but sometimes it resolves itself in such a way that Maven selects an older version of a library when given the choice between two different versions of the same library. This is extremely annoying when the older version contains bugs or lacks features that it’s dependent library needs.

A good colleague of mine, Morten Kjetland, has created an excellent Maven plugin called ‘deptools‘ that solves this issue by raising a compile error if it detects that an older transient dependency has been chosen instead of the newer version.

Deptools has saved us from a lot of head-scratching and frustration, and could potentially do the same for you, so head on over to the GitHub deptools repository and download it. It is open source and written in Scala, but works as any other plugin for Maven 2 or 3.

Weekend in Rome

I spent this last weekend in Rome. I got to see the Colosseum, Pantheon, Saint Peters’ Basilica, Piazza Navona and more.

Colosseum was the most impressive building. Even today in its broken-down state, it still is incredibly impressive. I would love to be able to take a 3d-tour of the place as it was when it was built. A good second best will be watching The Gladiator again soon! Continue reading “Weekend in Rome”

Ja Ja JavaZone

I got back from JavaZone last week; a 2-day Java-oriented programming conference. JavaZone 2010 was a very enjoyable and educational experience. I got to attend quite a few really good talks, including some good lightning talks. The most memorable talks in no particular order:

As you can see, most of these talks don’t have much to do with Java, but they were all great and might make me a better developer if I take just a bit of the wisdom to heart.

I was particularly impressed with the professional execution of the conference. Just about everything went smooth as could be (well, wifi at conferences is always a nightmare). Dinner and lunch was served to two thousand attendees with no more than a few minutes waiting once you queued up!

All in all a great conference! I am already looking forward to JavaZone 2011.

PS! If any of the above talks sound interesting, all the talks have been made available as videoes linked from the Javazone main page.

PPS! Here is the JavaZone 2010 music video:

Update

I guess this is the post where I say: Welcome to my new and improved website!

I’ve had a long pause in writing anything in this blog. Mostly due to laziness, but other contributing factors have been Getting Darkfall Released, followed by Moving Back To Norway, and last but in no way least: Becoming a Dad for The Second Time. That’s a time-consuming trilogy.

Well, all that has happened, and now I am back. I fixed my website (yay WordPress!), and I am going to be writing bits and pieces here again. At some point soon I am also hoping to put my experiences in the making of Darkfall into a post. When I do, it will be posted here.

Anyway, until the next post:

Have fun and code hard!

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, uten å kjøre koden. For Java finnes et program som heter FindBugs. Dette programmet søker gjennom byte-koden etter feil-mønster den kjenner igjen. Den kan f.eks. finne feil der man har glemt en break i en switch statement, eller indikere at noe er feil hvis den ser kode som ikke benytter retur-verdien fra en streng-operasjon. Findbugs kan også finne såkalte falske positiver, dvs at den indikerer at det er feil der det faktisk ikke er feil, men den har selvfølgelig som mål å finne færrest mulig slike.

Det som er veldig fint med Findbugs, er at den også finner kode som ikke nødvendigvis er feil, men som kan være en kjent men dårlig måte å skrive kode.

Jeg har testet FindBugs på et av mine personlige prosjekter, og den fant endel tvilsom kode og et par feil, som jeg sannsynligvis ikke hadde funnet selv før noe gale skjedde i programmet mitt. Jeg testet det også på prosjektet på jobb, og fant noen bugs som garantert hadde dukket opp senere og vært vanskelig å finne ut av. Jeg synes FindBugs er meget nyttig, og er blitt en integrert del av vektøyskassen min til utvikling. Versjon 1.1 er nettopp kommet, og bør sjekkes ut. Det kan være man blir litt flau når man ser hvilke rariteter FindBugs finner i koden, men de framtidige brukerne av programmene dine vil nok være fornøyd med resultatet.

Flere lenker:
Bloggen til forfatteren av FindBugs
Extreme Programming
Introduction to Test Driven Development (TDD)
Effective Code Reviews Without the Pain

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 oversikt over notater, og bugs, og evt om det er problemer med å bygge prosjektet fra kildekoden i Subversion.

Hvis jeg har en bug i et av prosjektene mine, må jeg skrive inn bugen i Bugzilla. Mens jeg holder på å fikse bugen skriver jeg kanskje noen notater i Wikien. Når jeg sjekker inn kode som er relatert til bugen skriver jeg innsjekkings-meldinger med notater om bugen også. Å holde dette i synk viser seg i praksis å være en tidkrevende og brysom jobb når det må gjøres manuelt.

I går leste jeg en artikkel om hvordan integrere Bugzilla, Subversion og en Wiki, slik at man enkelt kan legge inn lenker i Bugzilla til Subversion-filer, eller wiki-sider. Den forklarer også hvordan man skal få Subversion til å melde ifra til Bugzilla når en innsjekkingsmelding inneholde referanse til en bug, og legge til nye tags i wikien, så den automatisk lenker til bugs og kildekode i Subversion. Den viser også hvordan man auto-genererer ChangeLog filer direkte fra Subversion i forskjellige format.

Ingen av disse tingene er helt nye, men når man slår sammen alle verktøyene til en integrert verktøy-pakke, så blir resultatet ganske genialt! Det gjør det enklere og mindre tidkrevende å holde Bugzilla og Wiki og ChangeLogs synkronisert i forhold til koden, og man føler at man får mer utbytte av hvert enkelt verktøy når de er konfigurert slik. Jeg skal innrømme at det er totalt overkill for meg å sitte med et slikt system, men som tekno-junky er det veldig deilig å se hvordan man kan få til ting som dette. Det er nok mer noe for jobben enn for leking hjemmme.

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.