Jeg sitter i styret i Dataforeningen Østlandet hvor jeg er med å arrangerer Software 2015. Software er en kryssfaglig IT-konferanse hvor vi samler spesialister innenfor forskjellige fagfelt for å få dem til å snakke sammen på tvers av fagområdene. På konferansen er det dagsaktuelle temaer og trender som står på programmet. Jeg er stolt av alle de spennende temaene faggruppene har tatt fram og samarbeidet vi har fått til på tvers av fagmiljøer.

Do you ever miss a command line to a web application? If you’re lucky, you may use a REST API with appropriate tools for the same job. This Christmas, I bought a Sonos system for our family. It’s a wireless speaker system that uses music streaming services. It supports both Spotify and Deezer, but works better with Deezer and it came with a one year free subscription, so Deezer it is.

JavaScript Promises provide a strong programming model for the future of JavaScript development. So here I’m playing with promises. First I need a bit of a package.json file: { "name": "promises", "scripts": { "test": "node node\_modules/mocha/bin/mocha" }, "devDependencies": { "chai": "^1.10.0", "mocha": "^2.0.1" }, "dependencies": { "q": "^1.1.2" } } Now I can write my first test (test/promises_test.js): var Q = require('q'); var expect = require('chai').expect; describe('promises', function() { it('can be resolved', function(done) { var promise = Q.

The first commandment that any young programmer learns is “Thou Shall Not Duplicate”. Thus instructed, whenever we see something that looks like it may be repeated code, we refactor. We create libraries and frameworks. But removing duplication doesn’t come for free. If I refactor some code so that instead of duplicating some logic in Class A and Class B, these classes share the logic in Class R (for reuse!). Now Classes A and B are indirectly coupled.

Whole frameworks have been written with the purpose of handling the configuration of your application. I prefer a simpler way. If by configuration we mean “everything that is likely to vary between deploys”, it follows that we should try and keep configuration simple. In Java, the simplest option is the humble properties file. The downside of a properties file is that you have to restart your application when you want it to pick up changes.

This summer has been the most significant in my life. While I don’t often write about personal matters in this blog, I will make an exception. On July 12th my son Leon was born. Healthy, happy and obviously, from the perspective a father, perfect. Going through this fundamental life change has made me decide to re-evaluate a lot of things. Most importantly, I wanted to evaluate my career. In the last few years, I have spread my focus thin.

Pop quiz: What will be the output of this little program? public class DateFun { public static void main(String[] args) { long hours = getHoursOfDay(LocalDate.now(), ZoneId.systemDefault()); System.out.println(hours); } private static long getHoursOfDay(LocalDate date, ZoneId zoneId) { ZonedDateTime startOfDay = date.atStartOfDay(zoneId); Duration duration = Duration.between(startOfDay, startOfDay.plusDays(1)); return duration.toHours(); } } The answer is, like with most interesting questions, “it depends”. How can it depend? Well, let try a few examples: getHoursOfDay(LocalDate.of(2014, 7, 15), ZoneId.

This article is dedicated to the ExileOffice team - revolutionizing the way we run our business in Exilesoft. As applications move more and more of their business logic to the client side, it falls upon us to simplify what’s left on the server to avoid distractions. My previous article shows how I get rid of lot of the boring and noisy code. There is one thing that the server will always be responsible for: Security.

I once visited a team that had fifteen layers in their code. That is: If you wanted to display some data in the database in a web page, that data passed through 15 classes in the application. What did these layers do? Oh, nothing much. They just copied data from one object to the next. Or sometimes the “access object layer” would perform a check that objects were valid. Or perhaps the check would be done in the “boundary object layer”.

Working with web applications in NodeJS is great. Using the same language and libraries on the client and server simplified the thinking. And NodeJS has fast tests and restart for a super quick edit-verify cycle when you’re coding. I like to write tests to verify the server-side and client-side logic, but do you know that the whole solution really is working? You can of course test your service manually after deploying, but that becomes tedious.