…creating request for fact (state)
Wrapping in logger (state)
And authenticating (state)
Calling service (state)
Attaching to state
Out of callback
reformatting response and out of callback
Out of callback
There – we can continue. the fact that you need to use callbacks so extensively. Don’t get me wrong – the non-blocking principles that Node is built around is awesome. I especially like that you “fall into the pit of success” since everything is written around non-blocking code, which automatically helps my application to scale and manage resource wisely. But seriously… all those nested callbacks are making my eyes bleed. Talk about hiding the intention of the code. And I also grew very tired of trying of passing state through the chain of callbacks just to be able to use it in the final one. And for the record; Yes – I have heard about promises, but for some reason I couldn’t wrap my head around it. For me, it didn’t feel natural. Never gave it a proper chance, I’m willing to admit. But when I saw Koa Js things started to make sense again. Here is a mini-application that returns a user, from MongoDB by name sent to the URL. Pretty nice, huh? Thumbs up from me! I even threw in some logging and error handling just to make it a little more interesting. Strip that out and you end up with 2,3 significant lines of code. I take my web frameworks like my coffee – short, sweet and powerful. And we have not lost the non-blocking features that we’ve come to expect and love in Node. In short – Koa help med Code Better! In the rest of this post I’ll introduce you to the concepts of Koa and give you a short overview to how it works. Continue reading →
We had set the system up for a test of how this A/B testing stuff could work for us. Would it be useful? Could we communicate it clearly to the others around us? Would the data be easy to read?
In order to know what we where doing we picked a no-brainer feature to test it on: registration with or without CAPTCHA. You know, like the one to the left.
Since all of us (and probably you too) hate to type those strange, unreadable letters we were confident that we knew which one would win. Hence we had some really good test data for how A/B testing would work. A registration page with CAPTCHA turn on was created and one with it turned off. We then used Google Analytics to direct 50% of the traffic to either page.
The only thing was… the result was puzzling. And it started a really interesting process at the client. And the same reasoning has been made by everyone I told this story to after. I wonder: do we really dare to be data-driven or are we’re chickening out when it comes down to it?
A couple of months ago I was very fortunate to work alongside a great team. They had a not so envious task before them, namely to introduce a new main concept into an legacy code base. You know, the code has been around for at least 5 years and now you need to add a concept that was no-one ever thought we would have in there.
They did that. In just 3-4 months and delivered with flying colours. I didn’t have much to do with that, I merely observed their work.
When they were done I proudly introduced the team to a new senior in the company and told him about their feat and how they had gone about doing it. His words: well, that’s Lean backwards then.
He was right, but I never thought about it until then. In this post I’ll describe how they worked, what the “lean” way would have looked like and what we can learn from the difference.
Let me just say that the way the team went about their worked, and the feature was a success in production. Very high quality (2 bugs reported if I’m not mistaken) and well received.
In order to not put any blame on that great team I will talk about “we” in this post. Although I didn’t have much to do with their success.
There are some tools and practices that I use on a regular basis that have grown so familiar and accustom to me that I’m almost embarrassed to talk about them. Because I thought that everyone one did it this way. Not seldom it’s just like that too – it’s something that everyone knows and I end up being laughed at. I can take that, since the one person that didn’t hear about it before might have got something new that could help him. And, not to mention, I often end up learning myself in the process.
So… if you know about this practice (that I don’t know the name for, I call it Weighted index) or not; here we go. I’ll start with a story…
At one of the teams I’m coaching right now at Tradera (Swedish Ebay-branch) we are experimenting with increasing our focus on delivering completed work. We have had a big goal (technical upgrade of the complete site in a very short time) and there’s been some challenges to get the focus and team working together, towards this goal. Which has led us to try to experiment with some new practices and visualizations (board and backlog etc) and is summed up with a new question that we ask ourselves at our daily standups (you’ll find it under the Daily Standup heading if you’re in a hurry :)).
These a just a couple of practices that together has proven useful for us. In this blog post we’ll take a look at each one. Our starting-point was that it’s more important that we complete work than making sure that everyone is busy, that is built from the core ideas of lean. Hopefully you can get some ideas and insights from reading about this.