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
Continue readingOlle Hallin
Why you should do Continuous Code Cleansing
First we had Continuous Integration. It solved the problem of uncontrollable snowballing integration phases at the very end of development projects. Then we learned about Continuous Delivery and Continuous Deployment. They make putting new features into production a risk-free no-brainer. Now it’s time to learn about Continous Code Cleansing! It is about continuously making sure your code base is as small
Continue readingYANIA – You Ain’t Needing It Anymore
In the agile community we use the acronym YAGNI to remind ourselves to stay away from building (however cool) stuff that no-one is asking for.
If used wisely, the YAGNI veto will help teams maintain velocity over time and let them focus on delivering true business value early and often.
Now when we start adopting Lean Startup principles, it’s time to learn a new acronym: YANIA!
Alla mjukvaruprojekt borde ha en Kodkvast!
– “All kod är en skuld!”
– “Den bästa koden är den kod man inte skriver!”
– “Snabbaste sättet att få upp testtäckningen är att ta bort död kod!”
Jag tror att alla är överens om att det är bra att hålla sin kodbas så liten och kompakt som möjligt. Byggtider hålls korta, testsviter går fort att genomföra, driftsättningar går fort, statisk kodanalys går fort, nya teammedlemmar kommer snabbt in i koden, risken för buggar och sårbarheter hålls nere och så vidare. Kort sagt, man blir mer lättrörlig!
Så alla utvecklingsteam borde ägna tid åt att inte bara skriva ny kod, utan också att faktiskt städa efter sig. Men det är lättare sagt än gjort…
Continue reading
Mitt drömuppdrag
Som frilansande konsult kan man ju oftast inte utforma sina egna uppdrag, utan man får ta det som kommer i ens väg.
Har man tur kan man välja mellan två eller kanske till och med tre olika uppdrag. Har man haft bra beläggning under en tid och lyckats samla i ladorna kan man stå över tills det kommer något bättre i ens väg. Men till slut har man inget val alls utan måste ta vilket uppdrag som helst eftersom skattmas och bolåneinstitut skall ha sitt.
Nu är det inte så illa för mig, men jag tar mig i alla fall friheten att utforma mitt drömuppdrag. Om många vet vad jag drömmer om är ju chansen att det slår in större, eller hur?
Hur man låter Gradle kolla om man har de senaste versionerna av sina tredjepartsbibliotek
Inledning
Nu för tiden använder nog de flesta Javaprojekt någon sorts dependencyhanterare i sina byggen.
Den tid då man checkade in sina tredjepartsbibliotek i versionshanteringen är förbi. Nu låter man Maven (eller Ivy eller Gradle) läsa en incheckad förteckning, hämta hem jarfilerna ifrån de centrala förråd som finns därute och sätta upp class path.
En sak som dessa verktyg dock inte hjälper till med är att hålla koll på att man inte ligger kvar på gamla versioner. Att köra på gamla versioner kan ses som en sorts teknisk skuld, eftersom det blir värre och värre att uppgradera ju fler versioner man har missat.
Det är dock ett mödosamt och tråkigt manuellt arbete att kolla hur bra man ligger till.
Jag har därför utvecklat en Gradle-task som automatiserar detta!
(Se där, ännu en anledning att byta till Gradle!)
Hur man kan hantera Continuous Delivery med MongoDB
MongoDB är en schemalös, dokumentorienterad databas som har fått stor popularitet i den agila världen bland annat därför att man inte behöver underhålla något databasschema.
MongoDBs schemalöshet gör att många leds att tro att Continuous Delivery blir en promenad i parken, eftersom det ju inte behövs några datamigreringar när man driftsätter en ny version av koden!
Rent teoretiskt är detta sant, men är ett sluttande plan in i Land of Crappy Code™ !
För att slippa onödig komplexitet i form av varierande utseende på lagrade domänobjekt beroende på deras ålder, rekommenderar jag att man utför regelrätta datamigreringar även när man använder MongoDB!
Jag rekommenderar även att datamigreringen är en del av applikationen — till skillnad från skript som skall köras vid sidan av innan applikationsstart — helt enkelt för att eliminera risken för misstag.
Jag har i mitt sidoprojekt Varmfront.nu utvecklat en kompakt liten lösning som i MongoDB implementerar det som Flyway gör för SQL.
Mönstret bygger på Spring Data for MongoDB och Spring JavaConfig, och migreringarna är skrivna i Java. That’s right folks, no XML here 😀
Läs vidare, så får du se hur man kan göra!
Äventyr i molnet – del 4
Jag ber om ursäkt för det långa uppehållet sedan förra delen. Förklaringen stavas Valle. Valle är en hund, närmare bestämt en Lagotto Romagnolo. Valle är nu snart ett år gammal, så nu har jag “fritid” igen. Wohoo!
Denna gång skall det handla om något som så gott som alla webappar behöver, nämligen användarhantering och autenticering.
Handen på hjärtat, visst vore det skönt att kunna plugga in en färdig användarhantering, och kunna låta folk logga in med sina redan existerande Facebook/Google/Windows Live/Twitter/whatever-konton?
Om svaret är ja, läs vidare!
Continue readingMönster för flertrådade enhetstester
Detta är ett designmönster för hur man skriver ett enhetstest som utför samma test samtidigt i flera trådar.
Genom att utnyttja java.util.concurrent
på ett smart sätt säkerställer man maximal samtidighet, vilken kan avslöja trådbuggar.
Kom ihåg: det går inte att bevisa att ett program är fritt från trådbuggar. Det handlar om att göra det sannolikt att det fungerar i en flertrådad miljö.
Nyfiken? Läs på…
Continue readingÄventyr i molnet – del 3
Nu när det finns en första "Hello, World"-version av Eats-o-matic i drift, är det dags att fundera på allvar på den vidare utvecklingen.
För att det skall bli något så behövs det bland annat möjlighet att lagra data, samt ett ramverk för att skapa själva webbapplikationen med.
Jag har kollat igenom ett antal av de alternativ som finns för GAE och kommit fram till ett val som jag tror passar mig som utvecklare och Eats-o-matic som applikation.
Continue reading
Äventyr i molnet – del 2
Google har en Eclipse-plugin som automatiserar bygge, integrationstest & driftsättning av applikationer för Google App Engine.
Men hur gör man om man liksom jag tycker att det skall gå att bygga och driftsätta från kommandoraden?
Mitt svar är Maven. Tyvärr finns det inte (ännu) någon Mavenplugin, så det blir lite meckigt att få det att fungera.
Continue readingÄventyr i molnet – del 1
Det är mycket prat om Cloud Computing nuförtiden. Amazon EC2, Google App Engine, SpringSource CloudFoundry, och nu snart Windows Azure.
Detta är första delen i en serie som beskriver utvecklingen av Eats-o-matic, som kommer att köras på Google App Engine (GAE).
Häng med!
Continue readingWhy Are Installers So Slow?
When I started with Windows programming back in 1990-something, Install Shield was de-facto standard. It wasn’t too bad; installations were reasonably easy to create and quick to execute.
Then Windows Installer entered the arena. All the CPU power that Moore’s Law gave us was consumed by Windows Installer.
Even the simplest program takes ages to install. But in most cases, the flow is straight-forward; accept Express installation, accept Terms & Conditions and GO!
Continue reading