Daniel Sundman

Daniel and Martin have been in the same team since the beginning of summer and they’ve been collaborating in an unconventional way. Yassal interviews them to understand what’s been going on.

You’ve been successfully using mob programming with your team at Expressen for the past 6 months. How did you get started?

Daniel: The project started without any tech solutions in mind. We decided as a team that mob programming was a good way to figure out what tech stack to use. We had no backlog, but we sort of knew what we needed to do

Martin: I remember proposing this as the best way to do discovery work from a tech perspective. We didn’t know what language or tech platform we were aiming for, and this way we would learn more quickly as a team and could come to a decision. 

So, what is mob programming anyway?

Daniel: I don’t really care about the formal definition, to me it’s group programming rather than pair programming. One person is at the keyboard and the others act as support, coming up with suggestions, or researching potential solutions. This helps the whole team stay on the same page, and makes sure that we’re all learning at the same pace.

Continue reading

Our goal at the Crisp hack summit last weekend was to migrate our 2 year old shopping app written in Meteor to the latest version and to learn about Google’s material design. Our old app was built as a way for us to learn Meteor. The structure is less than ideal, and as we learn new things we add them to the app, but don’t revisit old parts. So we followed Dan North’s experiment rewriting the app from scratch. We also decided to use Materialize for the UI. We wanted to rewrite the app in 2 days, keeping all the functionality we currently have, but at the same time adding the UI and usability improvements that we really need.

We ended up completing the rewrite in 9 days: 2 hack days and then a couple of hours each day for the next week. Not too bad for a brand new app, but surprisingly longer than we would have guessed. Both Meteor and Materialize are pretty simple to get started with, but adding Materialize to Meteor proved to be challenging. Here are some highlights!

Continue reading

If you’re a TDD addict you know that it’s not always easy to Test Drive your JavaScript. Which testing framework should you use? How do you set your CI pipeline up? Etc…

There are quite a few frameworks out there and it seems like writing a testing framework is what everybody wants to do. I am pretty sure we don’t need any more. We just need them to be easy to use. In this post I’ll show you how incredibly easy it is these days to start using Grunt, Jasmine and PhantomJS.

Continue reading

As JavaScript is transitioning from the dark ages as a language of ridicule to a respected language of it’s own, it is obvious that some of the rough edges need polishing.

There is no rougher edge than the global namespace issue and the difficulty providing encapsulation. Even for a seemingly trivial JavaScript application, it is no longer OK to just whip up some JavaScript files and assume that you can maintain the code base as it grows. The application now lives in the browser and the amount of code you need to maintain requires modularization.

Continue reading

Backbones aren’t the usual fare for tech blogs, but if you’ve been following frontend development, then you’ll have heard of Backbone.js. From their site: Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions,views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface.Continue reading

As some of you may remember, a year ago I took Q3 off to focus on building a JavaScript application. I learned a lot especially about Node.js. Yassal and I have a pet project called FeedMe that we have worked on over the years. FeedMe implements a shopping list for us to use when doing

The basic premise of Node.js is that I/O is expensive and that, since I/O is expensive, we can’t block waiting for it to complete.

Many traditional Web Servers typically adopt a one thread per request approach, and any I/O (database, web service, file system call…) during the request blocks that thread of execution. This is inefficient in many ways because when the thread is blocked waiting for I/O to complete, it can’t respond to other requests.

Continue reading

Have you ever wondered why Spring MVC supports @RequestParam but not @RequestAttribute? There are probably plenty of philosophical reasons for this – good or bad. But if your hands are tied and you’re stuck with, let’s say a CMS, that insists on passing context as request attributes what are you going to do? As usual,

It turns out that I’ve gotten completely side tracked…or maybe not side tracked per se, but at least not completely focused on the client side of the Application. The past couple of weeks I’ve been engulfed in Node. Trying to figure out what it is, what I can do with it and obviously how I can test drive it. I found nodeunit which seemed to be a good testing framework candidate.

Continue reading

As I mentioned in my previous entry, the goal of my sabbatical is to build a JavaScript Application. Notice the emphasis is on Application. That is, I don’t intend to build a JavaEE web application with plenty of JavaScript. The goal is to build an Application in the browser. It will probably (eventually), communicate with a server side component for persistent storage and synchronization but for now, that’s secondary.
Continue reading

It has finally started. My sabbatical. In April I decided that I needed some time to step back and try some things my own way. I told my current client that in Q3, I would not be available. A lot of Q3 has passed but, as of this Monday, summer in Sweden is over and our two daughters are back at school and daycare which means I can actually start. 🙂

Continue reading