AWS Lambda functions are really great since the server is out of the picture. We don’t really need to care about it, since AWS will handle scaling, patching, starting and stopping for us. It’s just us and our code. Ah bliss! But wait a second: what if I do a console.log? Where will that be output? There’s no console, since I don’t have a server. Or is it? Spoiler alert: Claudia got you covered. A simple example As our example let’s use one of the example projects that Claudia has provided for us to learn from. In fact - let’s use the simplest possible: Hello-World. Create a new directory (called hello-world for example) and in it do a npm init and click through the wizard. There’s only one development dependency for this simple application, Claudia itself. Install it with npm install claudia --save-dev. Now create a main.js with the following...

The last week I saw yet another time when embracing uncertainty and embracing an experimental mindset, gave us great benefits and potential productivity gains. I wanted to share the story since I think it highlights these different mindsets and approaches in an awesome way. It’s also a great story… We are chasing a performance problem on our site, specifically on one of our more frequently used pages. Needless to say this have had high priority for quite sometime. A team was formed, a plan was created and a backlog of items that we thought would solve the problem was initiated. The first feature, our best bet, was further analyzed, setup and development initiated. The whole journey took about 1,5 months to get ready and another 2-3 weeks to develop. Finally, last Monday, we could do the first proper tests where we could measure against the current solution. Our efforts so...

I’m a fan of physical boards. But I have to say: many of the tools I’ve used are amazing (like JIRA, LeanKit etc.) in that they support working with the tool in a great way: shortcuts, intelligent search and great design. But I can’t get around the fact that I don’t think that they support me and my teams. Already now I can hear defenders of these tool racking up arguments and showing me better ways to do the things that I’ve experienced as problems. This post is not about that. This problem is about the general notion of any tool has it’s limits and that I run into more of them in electronic tools than I do using physical board. Also this is my experience - your mileage may vary. Glimpses of misuse As I have done for a few posts; let me give a few glimpses of situations...

In my last post on Claudia JS we only created a very simple function that echoed some data back to us. Still amazingly cool since that echoing scales to whatever load we will put on it, but a bit meek maybe. In this post I wanted to up the ante a little bit and store some data, more specifically in the AWS Document database called DynamoDb You might want to read up on the basics (creating accounts, what is Claudia etc) in my earlier post. I’ll write every step down here but I will not explain it as thorough as last post. Dynamo Db? Amazon DynamoDB is a fully managed non-relational database service that provides fast and predictable performance with seamless scalability. Ok - it’s a document store just like many others, the only difference is that it’s in AWS which means that it plays nicely with other AWS features,...

Many teams I visit nowadays have ditched story points and start to use Small, Medium and Large (aka T-shirt sizes) estimation instead. I like that. But very often a smell is creeping into the estimation, removing the “relative” out of “relative estimation”. Here’s how this problem will reveal itself. When someone suggests that you’ll use S, M and L for your estimates you will soon here: Ok - so a S is 1-2 days, M 3-5 and L 5-10 then or what's the scale? Don’t do that - it’s the wrong way around. In this post I’ll explain why and what is a better, more trustworthy, candid and transparent approach. Why attaching day-span to the estimate is bad Well, it’s quite obvious isn’t it; doing that (S = 1-2 days) is just giving “1-2” days another name. From that follows “resource-days”, then Gantt Schemes and the suffering that we all...

Recently I’ve been in many discussions about using agile in bigger enterprises that shows that one message of agile has been lost. It goes right to the basis of using agile (or lean for that matter, more on that later) in the first place. I think I speak too little about this, or at least I feel the need to be much more open and transparent about it. This post is a first attempt to bring some clarity. NOTE I know that this will come out like a rant. Sorry. It’s not. It’s just the state where I’ve seen it. If anything I think that I have not been candid, clear and transparent in how I communicated. Background I will give you some flashbacks first and then try to tie them together. In the beginning there was Scrum I remember when I took the Scrum Master certification way back in...

First time I heard about AWS Lambda my mind was blown to pieces. Quite simply AWS Lambda gives you the opportunity to run a piece of code without concerning yourself about the infrastructure - AWS will handle deployment, configuration, scaling and all of that stuff. You just push your code. That “just” in the last sentence proves to be quite a lot of grunt-work, sadly. That is, until you meet ClaudiaJs; your Node flight attendant for AWS Lambda - ensuring a smooth flight to the clouds. In this post I wanted to describe how I got started with Claudia and Lambdas. It will be loads of fun - let’s get on it! Getting off the ground with Claudia Js Claudia helps you deploy Node.js micro services to Amazon Web Services easily. It automates and simplifies deployment workflows and error prone tasks, so you can focus on important problems and not...

I have a couple of times been recommended the book The five dysfunctions of a team and the last couple of weeks I finally got around to read it. The book is really great and worth reading. In this post I wanted to talk about a very simple exercise that we used in our team the other day. “Review” First of all; I love the book. It’s another of the those text books that is a novel. In this case a very well-written, well-developed story about a new CEO that enters a startup. The company have some really good people in their management team, but their failure to work together as a team hurts the company. The rest of the book is devoted to how the heroine (Kathryn) helps the management team to really become a team and not just a bunch of people happen to work together. It’s of...

The team I’m in right now is under a lot of pressure and stress. And have been for some time before I joined it. I’ve been in meetings where no-one of the five people in the room could sit down, due to stress. Two weeks after I started I had to comfort a crying colleague after the “customer” yelled at her, despite her best efforts. Me, myself, I’m nervous to report any news (good or bad) to the customers, since they seem to be angry all the time. Things like that. I cannot help but wonder: What is important? Really. Glimpses Before I reveal my thoughts here - let me give a few glimpses (recent and old) that made me think about this; I remember in Indonesia that we had an important meeting that all of a sudden was interrupted by the news that one of the board members in...

As you might now the last couple of years have taken quite a toll on my personal life. It was work and my work situation that wore me (and my wife) down. Before we moved back to Sweden Elin and I decided to try to do something about it, so that we didn’t fall back into a work-life-situation that wore us down again. Therefor we decided to not work full time when we get back. Wednesdays are my day off. I wanted to share some initial reactions and … eeeeh … symptoms. Just to be clear - I’m ok. I don’t feel bad, stressed or depressed now. But I don’t want to go there again. This is my ways of protection. Others The first thing that have strike me is that I need to explain the reasons for me taking Wednesdays off to people around me: Oh, you're working for...