Tag Archives: programming

Codekvast soon available as a Heroku add-on

Posted on by

Codekvast is a tool for detecting Truly Dead Code in your Java application.

Truly Dead Code is code that is in production, but has not been used for a significant time.

Codekvast has been lurking in the spare-time realm for too long. Now the project has eventually been granted some full-time development effort, with the initial goal of being made available as a Heroku Add-on.

The alpha test period is just about to start. For this to happen we need YOU!

Read more about how to become a Heroko add-on alpha tester here.

TL;DR Participant must be a Heroku-app written in Java/Gradle, request invite by mailing codekvast-support@hit.se.

 

Programmer productivity: SP < PR < PP < MP

Posted on by

In my experience, when it comes to programming productivity, mob programming beats the rest. Of course the definition of productivity in this context is debatable and these are just my observations. Thus, it is not a proper scientific study but bear with me anyway.

I wish to compare one aspect of productivity, how we work together. I look at single programming, pull requests, pair programming and mob programming.

read more »

Programming with kids & co-speaking with my son :)

Posted on by

Yesterday me and Dave (11 yrs) spoke together for the first time! We did a public talk at Spotify about how to help kids learn to program. We’ve been experimenting a lot with that in my family (4 kids to experiment with… muahahaha), and wanted to share some learnings. Worked out better than we could have hoped, considering all the risky tech demos and live coding involved 🙂

Shared the stage with teacher Frida Monsén who talked about how to get this kind of stuff into schools. Thanks Helena Hjertén for organizing this, and Spotify for hosting & sponsoring. Here’s an article in Computer Sweden about this event and our little “mod club”.

Here are the slides! They are in Swedish though. Might do an English version of this talk some day 🙂

Dave on Stage

read more »

7 Rules on Code Readability

Posted on by

What makes good code? Many things but whatever the qualities are, readability is a cornerstone.  If you can’t read the code, you can’t fix it. So how do you write readable code? I’ll give you my view but it’s like books, what I find enjoyable may be different from you.

read more »

Programming with kids using LearnToMod and Minecraft

Posted on by

I’ve spent years experimenting with how to teach kids programming, mostly using Scratch. But now we’ve found a new favorite: LearnToMod! Kids love Minecraft, and LearnToMod is entirely based on Minecraft, so it’s a perfect match!

We now do a Mod Club every Saturday evening, my older kids (9 & 11 years old) and some of their friends. It’s basically a programming school based on LearnToMod and Minecraft programming. Reeeeaaaally fun, the kids go wild (OK, me too)! AND they learn lots while doing it. To them it’s “magic powers”, not “programming skills”.

I made a 5 minute video showing how it works:

read more »

Another builder pattern for Java

Posted on by

Whenever you have a domain object, data transfer object, parameter object or any other object that can’t be instantiated with constructor parameters only, you need to create a builder for its class.

The great thing about Java is that it is statically typed so a builder can give you compiler errors if you forget to set the compulsory parameters. If you use the builder in this pattern, you also get a very fluent interface that imposes order on the parameters. When using the builder, your IDE will suggest the next parameter to set.

read more »

Stop the Line – Build Quality In with Incremental Compilation

Posted on by

We in the software industry are still far behind when it comes to automated quality checks. Toyoda Sakichi for example invented the automated loom with stop the line capability almost 100 years ago. I write more about that in my first blog in a three-part series on building the quality in on the SmartBear blog.

It may seem old school, but every now and then I’ll start pristine Emacs and hack away on a piece of Java. I mainly do this for small stuff, since starting or setting up Eclipse takes a little bit too long for such minor projects. Even so, I don’t do this as often as I used to.

Why? I guess you know the answer: Nowadays, even the thought of not having instant feedback on syntactical and semantical correctness makes me shudder. It’s like coding in the dark. Incremental compilation is one of those great innovations that have increased the quality of our work.

Read the rest of the blog at SmartBear.

Twitter Bootstrap: Easy to Use

Posted on by

Are you building a Lean Startup, and want fast results? Twitter Bootstrap could be the solution you’re looking for. Are you a “backend” programmer who would love to have a beautiful site, but you “don’t know frontend”? Twitter Bootstrap could be the solution you’re looking for. Are you just looking for a simple frontend that works? Twitter Bootstrap could be the solution you’re looking for. Nice rounded corners, customizable colors, margins that look good, padding that’s right, JavaScript that just works: that’s what Twitter Bootstrap offers.
read more »

Programmerarna visar vägen

Posted on by

Lite i skymundan pågår något av en revolution inifrån i IT-branschen, och då särskilt i företag med många programmerare. På gräsrotskonferenser, i nätfora och i management-litteratur äger vår tids kanske mest avancerade och levande diskussion om hur man bäst organiserar arbete rum. Om det skriver jag i en längre essä om hur programmerarna visar vägen till ett bättre, roligare, effektivare och mer innovativt sätt att arbeta.

En första nedkortad version publicerades i februari i Aftonbladet. I somras publicerades en längre version i två delar i Dala-Demokraten (30 juli och 31 juli). Den finns också i sin helhet på antman.se.

Parprogrammering – är du tveksam?

Posted on by

Jag var själv en motståndare till parprogrammering från början, men är numera omvänd då jag av egen erfarenhet sett effekterna av det hela.

Om målet är att knacka ner så många rader kod man kan på en dag, gör två personer på varsitt håll detta snabbare än två personer vid samma dator. Men så går det inte till när man programmerar, även om många (programmerare också) tror att det är det de gör.

Ser man över en period, kommer en programmerare att vilja bolla idéer, göra design, få den konfirmerad av andra, diskutera vad kraven egentligen betyder, så småningom skriva kod, hitta buggar, rätta buggar, rätta fler buggar, osv. Bara en del av all tid går åt till att skriva själv koden. Det mesta är ju andra saker.

När man parprogrammerar gör man allt det här på en gång vid datorn i små små bitar. Det känns som man är mindre produktiv, eftersom man sitter längre tid (eventuellt) vid tangentbordet och dessutom är två, men räknat över en period sparar man tid, eftersom man gör design och förstår saker bättre när man är två, man kodar bättre och snabbare när man är två, man gör framförallt färre buggar när man är två, man gör snabbare felsökning och rättningar när man är två.

Frågan är då; går det dubbelt så fort när man är två med allt det här? Ja, faktiskt och ibland ännu fortare. Räknar man dessutom med den tid man sparar genom att andra inte drabbas av programmerarens misstag; felrapportmöten, testare, CMar, kunder m.fl. blir tidsbesparingen ännu större.

En kollega till mej (Mats Henricson) brukar påpeka att parprogrammering sprider kunskap om den kod som skrivs och vad som är sund programmering. Vill man ha ett företag där ett lite längre sjukdomsfall gör att en del av koden blir förlamad, eller ett företag där alla sitter på sin rum ensamma och skriver likadan halv-bra kod år efter år, ja då är parprogrammering fel grej. Vill man ha ett företag där alla lär sig hela tiden, och där man undviker att koden kollapsar för att någon blir sjuk eller säger upp sig, då är det parprogrammering som gäller.

Till sist får man dessutom ut en produkt av högre kvalitet. Om kvalitet är en nyckelegenskap borde det vara lätt att sälja in parprogrammering. Det går aldrig lika bra att testa in kvalitet i programkod (i efterhand) som att skriva kod med hög kvalitet från början. Det vet ju alla, inte minst testare och kunder.

Så om utvecklarna i en organisation känner sig oproduktiva när de parprogrammerar kanske man skall fråga dem hur de mäter produktivitet och koppla till detta. Man ska dock ha i minnet att antalet kod i sig självt inte är ett mått på produktivitet. I själva verket skriver man färre rader kod när man parprogrammerar eftersom man skriver bättre kod. Så man får titta på saker som är kopplade till det funktionsinnehåll man levererar (t.ex. velocity om man kör Scrum).

Till sist, parprogrammering är en vana man tillägnar sig. Det finns många saker som gör det svårt för en del att börja. Inte minst att du måste förklara vad du håller på med för den som sitter bredvid. För en del är det pinsamt, eftersom de helt enkelt provar sig fram (vilket inte behöver vara fel i alla lägen). Dessutom får man ju omedelbar kritik av den som sitter bredvid och alla kan inte ta det sådär direkt.

Innan man blir bra på parprogrammering tar det ett tag. Man kan inte köra att par dagar och sedan säga något om effekterna. Det tar ett par veckor innan man börjar bli en van parprogrammerare, men det är ju bara en halv sprint!