Technology

A Secret Weapon Against Technical Debt

2. February 2014 — 2 Comments

Technical debt is not the only monster we have to fight – it has a hidden evil twin, as pointed out by Niklas Björnerstedt: Competence Debt. The rope of ignorance that binds our hands and suffocates us by fear so that we don’t dare to change the system. Technical debt makes change difficult because the structure of the system does not support it. Competence debt makes change difficult because we do not know the system well enough, what & where to change and what impacts a change may have.

There is an often neglected tool at our fingertips that might help us fight competence debt. Its name is – behold – JavaDoc. An example from practice: I have returned to a client after two years and needed to understand the functionality of a part of the system. And, to my surprise, I found my own JavaDoc providing exactly the answer I was looking for. A colleague of mine mentioned that I should get the award for the “most documenting developer”. But I don’t do it for fun or just to help my bad memory and to be nice to my colleagues. It is an important contribution to the fight against the ever growing hydra of legacy code. Next time you code, try to remember that you are not typing code, but fighting. As every fight, it is hard – but do not give up or the enemy will prevail.

Side note: Writing JavaDoc that helps yet is not too verbose and not too likely to get outdated soon is hard. Getting the right balance – neither too little nor too much, focusing on the why and the broader context and relationships instead of the changing implementation etc. is difficult. But it is worth it. Help yourself, help your fellow colleagues, strike the hydra. Write good JavaDoc.

PS: This post is about competence debt even though the title mentions technical debt, sorry for the confusion (even though they are two sides of the same coin). And “good enough” documentation, though important, is not the sole remedy, as well as developers’ lack of knowledge is not the sole cause of competence debt. Also, Niklas provides a more in-depth review of the technical & competence debt terms in Misunderstanding technical debt  (tech. debt as evolving understanding [but not code] and crappy code). He wrote also A deeper look at Competence debt.

Youtube for video conferencing

29. January 2014 — 2 Comments

It’s been a hassle to integrate video conferencing into web applications. Sure, there are solutions available, like long running Skype and Webex or newer things like Google Hangout. What they all have in common are small universes surrounding the core product: Skype requires a signup and a friends list, Webex requires an executive deal, Hangout requires a Google+ account, and so on.

Thankfully, Telenor Digital addresses these limitations with their latest innovation project appear.in, and here’s how we’ve used it successfully in a recent customer project:

Helping Red Cross help school children

Norwegian Red Cross offers “Leksehjelp”, a voluntary service for helping school children with their homework. As of February 2014, they also offer a digital meeting point: Enter the website, choose what kind of homework you’re working on, and meet your volunteer in a video conference.

When my company Iterate was asked to develop www.digitalleksehjelp.no on behalf of Red Cross, our challenge was to connect children and volunteers using as few clicks as possible.

Reactive UX with Meteor.js

Secondly, we wanted to avoid any serious integration challenges. (We love a tech challenge as much as anyone else, but when working for the Red Cross you do want to keep things as inexpensive as possible..)

Continue reading

Scala eXchange 2013 – dag 2

4. December 2013 — Leave a comment

Følger opp rapporten fra dag 1 med en oppsummering av de foredragene jeg fikk med meg på Scala eXchange 2013 dag 2.

The Road to Akka Cluster, and Beyond…

Dag 2 startet også med en felles keynote, denne gang av Jonas Bonér, grunnleggeren av Akka. Han snakket om utfordringer og løsninger i distribuerte systemer, og gikk igjennom teori og forskningsresultater rundt slike systemer. CAP-teoremet er kanskje det mest kjente av disse og har vært vesentlig for NoSQL-bølgen de siste årene, men nå beveger pendelen seg noe tilbake igjen med blant annet Higly Available Transactions (HAT). Siste del av foredraget handlet om Akka sin cluster-løsning og detaljer om hvordan cluster-konfigurasjonen vedlikeholdes, f.eks. gjennom gossip-protokoller for utveksling av node-status.

Reconciling Eventually-Consistent Data

Noel Welsh ga en introduksjon til hvordan man kan aggregere endringer fra flere noder i distribuerte systemer ved å ta i bruk konflikt-frie replikerte datatyper (CRDTs). Tenk deg datastrukturer som kan slå sammen endringer og aldri få merge-konflikter. Eksempler han gir er distribuerte tellere (f.eks. side-visninger) og set (mengder). Synes dette var en veldig god introduksjon til grunnleggende byggestener i CRDTs, som man så kan bygge mer avanserte datastrukturer ut ifra.

Scala and Graphs

Dette viste seg å være en mer eller mindre ren introduksjon til graf-databasen Neo4J, og hadde lite å gjøre med Scala. Men foredragsholderen var morsom og entuastisk så hvis man ønsker å få en intro til graf-databaser generelt og Neo4J spesielt, så synes jeg det var bra 🙂 Han snakket også om spørrespråket Cypher, som er et SQL-aktig språk for å gjøre spørringer mot Neo4J basert på pattern-matching. Her kom vel den eneste ordentlige Scala-relaterte, ved at han viste eksempler på bruk av AnormCypher som er et bibliotek for å gjøre Cypher-spørringer fra Scala.

Hidden Gems in ScalaTest 2.0

Bill Venners holdt dagens andre keynote og fulgte opp foredraget sitt fra dag 1 ved å vise mange kule funksjoner i ScalaTest 2.0.

Akka for the Rest of Us

Phil Willis fra The Guardian snakket om hvilke deler av Akka man kan ha nytte av selv om man ikke kjører på et cluster med 2400 noder 😉 Han var skeptisk til hele systemer basert på Actors, hovedsakelig på grunn av at man mister en av styrkene til Scala, nemlig typesikkerhet. De bruker allikevel Actors i noen spesifikke situasjoner. I tillegg bruker de Schedulers for å spre last fra automatiske jobber utover korte tidsperioder, og Agents som et alternativ til standard caching der man har et lite, velkjent antall elementer som alltid skal holdes i minnet.

Overcoming U-Turns and Dead Ends

Endelig et erfaringsforedrag 🙂 Foredragsholderne hadde tatt i bruk Scala, Akka, Spray, Heroku, MongoDB, Redis, m.m. på et greenfield-prosjekt – uten å ha særlig erfaring med noen av de fra før. De delte villig av feilene de hadde gjort og fellene de hadde gått i. Interessant og underholdende foredrag.

Patterns for Slick Database Applications

Siste foredrag på konferansen ble en gjennomgang av en del mer avanserte patterns for bruk av Slick, et bibliotek for databaseintegrasjon fra Scala. Slick 2.0 kommer med en rekke forbedringer som vil føre til mindre boilerplatekode, blant annet i forbindelse med joins, og bedre håndtering av auto-increment kolonner. En grei gjennomgang, men skulle gjerne heller ha sett litt mer erfaringsbasert foredrag om bruk av Slick og hvilke tradeoffs man må gjøre i forhold til f.eks. direkte bruk av SQL.

Oppsummering

Så hva er konklusjonen? Er Scala eXchange verdt å få med seg?

Jeg synes det var en bra konferanse. Jevnt over godt nivå på foredrag og foredragsholdere. Skal jeg trekke frem noen enkeltforedrag så var det vel Spray-foredraget dag 1, og “Overcoming U-Turns …” fra dag 2. Skulle gjerne sett flere erfaringsforedrag, men det virker å være samme situasjon på flere andre tilsvarende konferanser om Scala. Savnet også litt lyntaler, som jeg synes er en veldig bra måte å få inn flere nye impulser på kort tid, men det er ingen show-stopper. Det var sosiale happenings begge kveldene, med øl + mat + panel-debatt første dagen og tur på puben etter konferansen sluttet dag 2.

Kommer gjerne tilbake 🙂

Scala eXchange 2013 – dag 1

3. December 2013 — Leave a comment

Her kommer en kort rapport fra dag 1 på Scala eXchange 2013 i London. Konferansen er delt i tre spor, med noen felles keynotes underveis.

Lenses

Dagen startet frisk med en keynote av Simon Peyton Jones om Lens-biblioteket i Haskell. Lenses gjør det mulig å “gripe inn i” hierarkiske datastrukturer og hente ut eller endre data, men på en funksjonell måte som muliggjør immutability, komposisjon osv. Her gikk det relativt kjapt i svingene, og jeg fikk definitivt bruk for hver minste lille dråpe med Haskell-kunnskap jeg har. Det var allikevel ikke et foredrag om Haskell i seg selv, men mer om konseptene i Lens-biblioteket og styrken i abstraksjoner som sterkt typede (funksjonelle) språk gir en.

Scala har selvfølgelig flere Lens-implementasjoner, som Rillit, Shapeless og Scalaz. Se f.eks. Lenses-foredrag fra Scala Days 2013 for en god intro.

SPJ er vel forøvrig en av de få som kan komme unna med å bruke Comic Sans på slidene sine, i gult på blå bakgrunn intet mindre… 😉

What’s new in Lift 3

Lift var det første web-rammeverket skrevet i Scala, men de senere åra har det vært mer stille rundt Lift. Andre web-rammeverk som Play! og mer lettvekts REST-biblioteker som Unfiltered, Scalatra og Spray har fått mer oppmerksomhet.

David Pollack & co holder nå på med versjon 3.0 av Lift. En av de store nyhetene er støtte for “klientside” actors. Lift 3.0 støtter actor-kall fra klient til server og tilbake med automatisk (de)serialiseing av JSON begge veier. Det er mye fokus på REST og asynkrone tjenester. Utover dette har Lift sterk støtte for sikkerhet, og tar seg automatisk av en del lavnivå ting som håndtering av http-connections (multipleksing, osv.) og retry av kall som timer ut. Litt usikker på argumentene for hvorfor Lift bruker egne typer/biblioteker for Futures o.l., må se nærmere på dette i forhold til Play!, Akka o.l.

Implicit Conversions => Implicit Parameters

Bill Venners fortalte en del om hans oppdagelser og erfaringer med bruk av implicit parametere i Scala og hvordan det hadde åpnet for ny funksjonalitet i ScalaTest2.0 i forhold til bruk av implicit conversions i ScalaTest 1.x. Blant annet bedre støtte for konfigurasjon, typesikkerhet, med mer.

Failure: Deal With It!

Viktor “Legend of” Klang fra Typesafe holdt en keynote om feilhåndtering. Hovedbudskapet var at man bør håndtere validering og feilhåndtering hver for seg. Validering er planlagt/ønsket, mens feilhåndtering tar for seg de uforutsette hendelsene. Dette er ofte ortogonale aspekter og bør håndteres i forskjellige deler av koden. Han snakket om hvordan feilhåndtering gjøres i Akka ved hjelp av supervisor-hierarkier, ikke i selve applikasjonslogikken.

How to Please Everyone, All of the Time

Jon Pretty snakket om hvordan man kan bruke type classes i Scala for å tilby forskjellig funksjonalitet til forskjellige brukere. Han viste hvordan man ved hjelp av import av utvalgte type classes kan gjøre feilhåndtering implisitt (exceptions) eller eksplisitt (Either/Try som retur-typer). Synes han brukte vel lang tid på å komme til poenget, snakket mye om Monoids og slikt før han kom til det som egentlig burde ha vært motivasjonen for foredraget.

Let the Types Set You Free

Et foredrag om korrekt bruk av typer for å signalisere funksjonalitet og hensikt i koden din. F.eks. bruke Option for å angi at funksjoner kan ha en retur-verdi eller ikke, eller Scalaz sin IO-monade for å signalisere eventuelle feil som kan oppstå under IO. Foredraget var ganske kort (drøye 20 minutter?) og kunne med fordel ha gått litt mer i dybden på en del ting, og også forklart det litt mer detaljert. Hvis man har vært borti Option og lest litt om monads så synes jeg ikke det ga så mye.

Spray: Http for your Akka Actors

Siste foredrag jeg fikk med meg denne ettermiddagen handlet om Spray, et lettvekts-bibliotek for håndtering av HTTP-kall i Scala, både som server og klient. Foredraget besto for det meste av live-koding, og ga en god intro til mulighetene i Spray. Blant annet viste han kobling mot Akka actors og hvordan man kan bruke både lav- og høynivå-mekanismene i Spray for å håndtere slikt som HTTP-connections, uthenting og validering av query-parametere, og f.eks. komprimering av HTTP-responsen.

Economies of Scala

18. April 2013 — 25 Comments

As a consultancy, we’re always on watch to see what might be the next step forward in the field of software development. I usually find that paying attention to what our developers are playing with provides a good clue.

These days, many of them are toying with Scala, and they are eager to try it out on a project. I have challenged them to come up with compelling business reasons to use Scala on a project, but they have come up short.

I figured I would help them find a good business case for Scala.

For software companies in a tight employment market like the one in Norway, most technical advantages are dwarfed by one concern: Access to good developers. It clearly doesn’t matter what kinds of technical advantages a new language can bring if you can’t hire any developers to work with it. On the flip side, if you can bring great developers to your project, you’re probably in good shape no matter what language you have chosen.

The question, then, is what language should you choose to maximize your access to good programmers?

Continue reading

The Sprinting Centipede Strategy: How to Improve Software Without Breaking It

14. January 2013 — Leave a comment

Our code has been broken for weeks. Compiler errors, failing tests, incorrect behavior plagued our team. Why? Because we have been struck by a Blind Frog Leap. By doing multiple concurrent changes to a key component in the hope of improving it, we have leaped far away from its ugly but stable and working state into the marshes of brokenness. Our best intentions have brought havoc upon us, something expected to be a few man-days work has paralized us for over a month until the changes were finally reverted (for the time being).

Lessons learned: Avoid Frog Leaps. Follow instead Kent Beck’s strategy of Sprinting Centipede – proceed in small, safe steps, that don’t break the code. Deploy it to production often, preferably daily, to force yourself to really small and really safe changes. Do not change multiple unrelated things at the same time. Don’t assume that you know how the code works. Don’t assume that your intended change is a simple one. Test thoroughly (and don’t trust your test suite overly). Let the computer give you feedback and hard facts about your changes – by running tests, by executing the code, by running the code in production.

Continue reading

Why does Iterate sponsor flatMap(Oslo), the functional programming conference

19. December 2012 — Leave a comment

Iterate has traditionally sponsored the conferences JavaZone and Smidig. This year we have decided to support flatMap(Oslo), the conference about Scala and functional programming on the JVM.

We believe that alternative JVM languages have the potential to enable higher productivity and better software. Especially functional programming (FP) is very promissing, with its focus on better reusability via higher-order functions and on concurrency via referentially transparent functions and immutability.

Many companies can benefit from the powerful mixture of new and time-proven features that these modern languages offer but they are often discouraged by their (relative) novelty, lack of knowledge and experience, and fear of unavailability of capable professionals. Therefore we want to contribute to spreading information, exchanging experience, and attracting more developers to these languages to enable the IT market to step forward and grab the benefits of FP.

JavaScript tests on your Continous Integration server

19. December 2012 — 8 Comments

A modern web page does a lot of things, hence the term web application has become more commonly used over the last year. A consequence of this is that we are crafting widgets and entire modules using JavaScript, or at least in some language that eventually ends up being “compiled” to JavaScript.

Where there is code there should also be tests. And the tests need to go green every time the code is changed. You are testing your client side code, right?

Continue reading

Do You Know Why You Are Testing?! (On The Principles Underlying TDD)

30. October 2012 — 1 Comment

Kent Beck in his recent post Functional TDD: A Clash of Cultures summarizes well the key principles and benefits that underlie test-driven development. I think it is really worthwhile becoming aware of and thinking over these foundation stones of TDD (and testing in general). Knowing them enables you to apply TDD in the most effective way with respect to a particular context to gain the maximum of these benefits. People that do not really understand the value of their tests and TDD tend to write hard to maintain tests of limited (and occasionally even negative) value. Are you one of them?

Continue reading

Books Our Developers Should Read

19. August 2012 — 12 Comments

There are a few books that every developer in Iterate should read because they express what we believe in and are extremely valuable in themselves. The books chosen are generally and broadly useful and not tied to some too limited domain (contrary to e.g. Effective Java).  The list is kept as short as possible, about 4-5 books, and is revised regularly.

Why particularly these books, why lean and agile? Our people are primarily responsible for crafting solutions for our clients, for making sure that they use the customers’ limited resources efficiently to produce the maximal business value possible. However, according to our experience, it is never truly known upfront where that value lies. Software development is therefore inherently a learning and exploration process. A process that needs to be continually adjusted based on empirical feedback from the reality and on shifting conditions. This is what lean is about: eliminating waste, maximizing value by maximizing learning, making sure that the right product is built. We value software craftmanship and building things right – but building the right things is crucial.

Here are the books and why we believe they are so important.

Continue reading