Uncategorized

Red Cross Codeathon 2017

Some 6 months ago I found myself in a meeting where I had no clue what the topic was going to be or any prior knowledge to give away why I was there. Halfway through the meeting I found myself in complete awe at what was presented. The meeting was with the Norwegian Red Cross, the topic was how they wanted to take advantage of technology to gain insight into potential epidemics. The Norwegian Red Cross team had already done a couple of iterations on a software for dealing with this, trying out different technologies. They now had the real world experience from the versions they’ve been running and wanted to take it to the next level; professionalize the software – making something maintainable and sustainable. Red Cross does not have a software development branch within their organization and reached out to Microsoft for assistance and see how we could help. With Norwegian Red Cross being a nonprofit organization, they already get assistance from Microsoft through the Microsoft Philantropies. I was on Channel9 talking about the project, you can watch it here.

Taking the lead

With software there aren’t that many opportunities to really do good for mankind by applying the skillsets we already have(?). With what was presented and my position @ Microsoft, I started thinking about how there could be synergies and how it could all be brought together. My day to day work is an advisory type of role were I engage with ISVs around Norway and helping them move to the cloud or get the most out of Azure in general. With this work I get to meet a lot of people and I started thinking about opportunities of combining it all. In addition, I also felt that the most natural way for any of this software to be built would be to do it in the open with volunteers. Since Red Cross does not have any in-house developers and the cost of hiring consultants are very high. Besides, having external resources to do the work is not the best sustainable model for living software – ideally you’d want to do it in-house. With volunteers however, one would apply one of the core principles of Red Cross itself, that of volunteerism, as the Red Cross bases its work more than 17 million volunteers worldwide.

Understanding and getting the word out

We’ve had the dialog going the last 6 months on how it could be done – both from a process perspective, but also whether or not to base it on volunteer work and even go open source or not. I reached out to Richard Campbell to hear how they’ve been running the Humanitarian Toolbox for American Red Cross in the U.S.. He put me in contact with the product owner they’ve been having for the allReady project. From this, I gained even more confidence that the choice was right to do this on a volunteer basis as they’ve had 132 contributors pitch in on that particular project (@ the time of writing this post). As large organizations come, Red Cross also relies on a certain amount of red-tape and in general internal processes to make decisions.

In middle of June 2017 the NDC developer conference was held in Oslo. We were lucky to get a slot to talk about the project, what Norwegian Red Cross had done and our plans for the architecture for the new implementation. Richard Campbell joined Tonje Tingberg from Norwegian Red Cross and myself on stage (you can watch it on Vimeo here). I was really nervous whether or not there would be anyone coming to the talk, as we didn’t pitch it from a technology perspective – but was super glad and proud of my colleagues in the development community that wanted to learn more. We close to filled the room and the response from people was enormous, we got into good conversations right after and also good mail dialogs after NDC as well. This reinforced the belief that this could be done with volunteers. A couple of weeks ago I got a call from Tonje Tingberg bringing the happy news – Red Cross wants to move forward with the proposed model.

Codeathon – first call to action

The downside to basing everything on volunteer work is of course the fact that you have less control over when things get done. In order to get condensed and focused work done one needs a mechanism where you gather people in the same room for a couple of days.Building on the experience from Humanitarian Toolbox, Red Cross will be hosting a codeathon – not a hackathon or a hackfest – but more like a marathon for coding. The first of these will be held the weekend of 29 September – 1 October at the Norwegian Red Cross in Oslo. If you’re interested in joining and helping out; please sign up here. We will establish a core team that will be putting in place the framework for how we’re going to be building it and making sure we get as much work done as possible during the codeathon. Once you’re signed up, we will follow up with you to make sure you get to do what you want to do.

Learning Experience

One of the opportunities with this is learn. Not only from the project itself, but working together with others. In a room filled with developers and architects you’re bound to pick up a thing or two that can be brought back to your daily work. The solution will be built using modern techniques, state of the art architecture and utilizing the cloud as much as we can. It is also a great way to learn more about how to work in the open source community if you haven’t already got experience with doing open source.

Wrapping up

Seeing the impact of the work that Red Cross is doing really puts things in perspective. Bringing knowledge to the table is vital in helping others that don’t have the resources we are accustomed to. With the type of technical know-how we have as software developers, we can really make a difference. In our line of work, we focus on being problem solvers – trying to make smarter, more efficient systems. Imagine transferring this and saving lives by just using the power of our brains; this is what we as a community can bring to the table. I’m so glad I was asked to join that meeting months ago – finally I can help in a way I know how to.

Red Cross Norway has also put out a post on this with all the details as well. You can find it here.

/* Style Definitions */

table.MsoNormalTable

{mso-style-name:”Table Normal”;

mso-tstyle-rowband-size:0;

mso-tstyle-colband-size:0;

mso-style-noshow:yes;

mso-style-priority:99;

mso-style-parent:””;

mso-padding-alt:0cm 5.4pt 0cm 5.4pt;

mso-para-margin:0cm;

mso-para-margin-bottom:.0001pt;

mso-pagination:widow-orphan;

font-size:12.0pt;

font-family:”Calibri”,sans-serif;

mso-ascii-font-family:Calibri;

mso-ascii-theme-font:minor-latin;

mso-hansi-font-family:Calibri;

mso-hansi-theme-font:minor-latin;

mso-fareast-language:EN-US;}

Bifrost, C#, Cloud, CQRS

Bifrost roadmap first half 2017 (new name)

This type of post is the first of its kind, which is funnny enough seeing that Bifrost has been in development since late 2008. Recently development has moved forward quite a bit and I figured it was time to jot down whats cooking and what the plan is for the next six months – or perhaps longer.

First of all, its hard to commit to any real dates – so the roadmap is more a “this is the order in which we’re going to develop”, rather than a budget of time.

We’ve also set up a community standup that we do every so often – not on a fixed schedule, but rather when we feel we have something new to talk about. You can find it here.

1.1.3

One of the things we never really had the need for was to scale Bifrost out. This release is focusing on bringing this back. At the beginning of the project we had a naïve way of scaling out – basically supporting a 2 node scale out, no consideration for partitioning or actually checking if events had been processed or not. With this release we’re revisiting this whole thing and at the same time setting up for success moving forward. One of the legacies we’ve been dragging behind us is the that all events where identified by their CLR types, maintaining the different event processors was linked to this – making it fragile if one where to move things around. This is being fixed by identifying application structure rather than the CLR structure in which the event exist in. This will become convention based and configurable. With this we will enable RabbitMQ as the first supported scale out mechanism. First implementation will not include all partitioning, but enabling us to move forward and get that in place quite easily. It will also set up for a more successful way of storing events in an event store. All of this is in the middle of development right now. In addition there are minor details related to the build pipeline and automating everything. Its a sound investment getting all versioning and build details automated. This is also related to the automatic building and deployment of documentation, which is crucial for the future of the project. We’ll also get an Azure Table Storage event store in place for this release, which should be fairly straight forward.

1.1.4

Code quality has been set as the focus for this release. Re-enabling things like NDepend, static code analysis.

1.1.5

Theme of this version is to get the Web frontend sorted. Bifrost has a “legacy” ES5 implementation of all its JavaScript. In addition it is very coupled to Knockout, making it hard to use things like Angular, Aurelia or React. The purpose of this release is to decouple the things that Bifrost bring to the table; proxy generation and frontend helpers such as regions, operations and more. Also start the work of modernizing the code to ES2015 and newer by using BabelJS. Also move away from Forseti, our proprietary JavaScript test runner over to more commonly used runners.

Inbetween minor releases

From this point to the next major – it is a bit fuzzy. In fact, we might prioritize to push the 2.0.0 version rather than do anything inbetween. We’ve defined a version 1.2.0 and 1.3.0 with issues we want to deal with, but might decide to move these to 2.0.0 instead. The sooner we get to 2.0.0, the better in many ways.

2.0.0

Version 2.0.0 is as indicated; breaking changes. First major breaking change; new name. The project will transition over to be called Dolittle as the GitHub organization we already have for it. Besides this, the biggest breaking change is that it will be broken up into a bunch of smaller projects – all separated and decoupled. We will try to independently version them – meaning they will take on a life of their own. Of course, this is a very different strategy than before – so it might not be a good idea and we might need to change the strategy. But for now, thats the idea and we might keep major releases in sync.

The brand Dolittle is something I’ve had since 1997 and own domains such as dolittle.com, dolittle.io and more related to it. These will be activated and be the landing page for the project.

Uncategorized

Bifrost; Getting back to it…

Its been a while since I wrote anything about Bifrost. In fact the last post I did was about me not maintaining it anymore. The thing is; its been an empty year for me personally since February when I announced it. I didn’t realize it until I was at a partner who wanted to dive deep on SOLID, DDD, CQRS, EventSourcing and more and we only had a couple of days to prototype something. We talked it over and we decided that doing Bifrost would get us there quicker… what a relief… I’m so glad we did that. All of a sudden it all became very clear to me; I need to continue the work – its just too much fun. I had a hunch, but didn’t see it all that clear. A few months back I started pulling things from Bifrost into a new project called Cratis and making it more focused. Never kind of thinking that it should go back into Bifrost.

So, what am I doing about it. Well, first of all; I took down the post announcing the stop in maintenance. It didn’t make sense to have it there when coming to this realization that I need to push on. The second thing I did – in order to get back into the mood and understanding Bifrost (even though I wrote most of it) again, was to start writing the proper documentation that it deserves. This now sits here. The next thing that will happen is that development will be picked up again.

From the top of my head, this is what needs to be done:

Add a support for running on Azure in a distributed manner – with a working sample
Clean up. Remove platforms not being used.
Simplify code. Make it more focused.
Modernise it. Make it run on .NET Core
Rewrite JavaScript to be ES2015+
Break it apart into many small GitHub projects that can be maintained individually

In between there might be some features that sneaks in. But the majority of new development will have to happen after these things have happened.

Alongside with it all; more documentation, more samples, more videos – just simply more. 🙂

Really looking forward to getting back into this and see what 2017 have in store for Bifrost work.

Uncategorized

The Code Lab

I’ve been wanting to try out a new format, or at least a new format for me; live interactive webcast. I got inspired when I saw some ex-colleagues of mine started something called “Kodepanelet” and figured I had to do something similar. The goal is to have a one hour show on a regular basis where anyone can chime in on social media and ask technical questions and I’ll try to be as agile as possible answering, or probably preferably show. Some things I can answer live – other things might need preparation for a later show, or a follow up in a blogpost or similar. This part is still a bit fuzzy. To be honest, since this is all new and I’m trying something out – the format will more than likely change over time.

The concept is called “The Code Lab”;

I will be using the Facebook live video streaming system for this and you’ll find the Facebook page for the concept here.

Details

First airing will be on Friday the 4th of November @ 13:00 CET (1PM), here.

What can you expect?

First of all, this is supposed to be for software developers. And I can’t do more than I know or can easily acquire knowledge on. My background stretches from games development including graphics – low level programming to line of business applications and architecting highly available durable and scalable systems. I also have a knack for process and how to build teams. I consider myself pretty open-minded, and as a result I’ve always been all over the place when it comes to platforms. These days I find that I am probably most experienced in macOS and Windows, but an apprentice in Linux – trying to gain more experience there. I try to be polyglot in languages, but have most experience in C/C++, C# and JavaScript. Thrive in the backend as well as the frontend and loves my patterns and eat my SOLIDs for breakfast. I focus a lot of my time on cloud, and specifically Azure. Containers, MicroServices and in general decoupled software is something I am really passionate about.</>

How can you help?

Content is always king – I’m hoping people find this interesting and want to jump in with good questions. To get the topics right, there is a survey on Facebook

Health warning

If you’re out to troll me, I’ll try to ignore you. 🙂

General, Personal

Renault Zoe: The Electric Car Lie

1st of January 2015 I started working in Oslo, Norway. About 124 kilometres from where I live; Sandefjord.

I started off with taking the bus. Did that for a couple of months and found it to be sub-optimal with trying to work on the bus on the way in and back, seing that it was constantly crammed going back. I swapped to train to try if that would be more optimal. Sure, the comfort was way better – but had the downside of me walking to take the bus to take me to the train. Ended up being an end-to-end travel of about 3 hours each way. Compared to 2.5 hours with the bus (including walking to the bus and to the office from the bus), which was still a lot. We only had one car at the time and my wife needed it during the days.

In with the electric

We have a pretty good insentivised deal in Norway for electric cars. There is no sales tax on them, making them a better deal than their carbonfuel based counterparts. In addition we have other good deals with free parking on public parking spaces and also no toll for toll based roads. I therefor started thinking about buying an electric. Did the math and figured a car loan would in fact be cheaper than taking the bus or the train. In fact a whole 1000 Norwegian Kroners (about 130 USD or 110 Euros). And the best part, I could save a lot of time. Another benefit is that electrics can drive in the bus-lane – meaning you don’t have to get stuck in traffic. There are some local changes to this, but its a question about timing – when you drive, but still in place. With all this upside, what could possibly go wrong. <>Having absolutely no experience with electric cars, but have owner a bunch of regular gas and diesel based cars over the years – I jumped into it with the wrong goggles. I didn’t look too much around as most cars really didn’t have the range I needed, except for Tesla – but even in Norway these are very expensive. I know people argue they aren’t, with all the benefits – but a car half that price is still half that price with the benefits on top. So I set out to find something not Tesla with enough range to get me one way. I was counting on being able to charge when I was at work – giving me a full 8 hour charge. Seeing that the infrastructure was in place in Oslo, I was willing to take this gamble.

After reading a bit about a few cars, I found the Renault Zoe to be the most interesting from a range perspective. Unlike the competitors, it had gotten reviews claiming the range to be accurate to what they were promising; 240 kilometers on one charge. I even stumbled upon this article, claiming it had almost unnoticable drops in performance in -25 degrees celcius. Everything was pointing towards it. They even had a deal were you could get it with a home super charger included in the price.

I had my testdrive of the car on the 28th of April 2015. Found the car a nice drive, but found it weird that I had to stop for a 45 minute charge halfway to Oslo. The battery had dropped to 20%. I charged and drove it in, parked it for charging for the day. Called the dealer and explained my situation and the salesguy told me to drive it in ECO, which would prevent the car from going faster than 96 km/h. This is were I go; OK and then WTF.. But willing to do what he said when I drove back, I managed to get back – but the display said there only was 15 kilometers left on the battery. Sure, it was a bit confused since its averaging. At this point I knew little about the car and was willing to except that it might be displaying wrong information due to me not driving ECO in and then ECO back. Messed up the statistics, kinda. Did point this out, and the salesguy was surprised.

I was skeptic, to say the least. But had the car for a couple of days for test driving, this time only driving ECO and proved a couple of times it would make it all the way in. So I decided to buy one.

Got the car…

13th of May 2015; super excited. Picked up the car. The installer of the super charger thingy came the day before – all set. Since I was going to charge in different locations, I did order the car to come with a transformer that was able to transform from regular 240 volts to the 400 volts the car needed and also convert whatever it needed to convert. This was not ready from the manufacturer and I was promised to get this in August. Which was perfectly fine for me, as I could charge on the way home if I couldn’t find a charger that was compatible in Oslo and still save time on my travel in comparison to the bus and train options. The compatibility question is related to the volts but also the fact that it needs 3 phase charging and the plug being a Type 2 plug.

A week later

I don’t travel the distance to the office every day. Some weeks 2 days, others 3 and occassional 1 day a week. So I didn’t get into trouble straight away, due to this fact. 19th of May I drove the car in and found a public charging pole and plugged my car in. Shortly after it said “Battery charging impossible” in the display.

Pretty non informative message to get, and it didn’t help to drive to a charger I knew worked. Same message. Anyways, I ended up having to get the car and me picked up by a dealer in Oslo. They plugged in the car to their charger and the message went away. Apparently this happens from time to time. The car then needs to reset its software (turn off the car and wait for a minute or so).

First death

Yes, you read that right; first… The car died on the 29th of May. Not full two weeks after I got it. They had it for almost a full month, claiming to have swapped out the engine and had visitors from France and what not. That may very well be true, but a full month. Really. For a brand new product. Impressive. They hadn’t really found the problem, just swapped out everything. I use the car till I go on my holiday on 11th of June.

Second death

Yup, there was a second one. Got back from holiday and went on a work related trip to the US. I drove the car to the airport, which is farther than Oslo – so I had to charge on the way to get there. Parked it at the airport. Got back from the trip on the 3rd of August. Drove the car to the nearest super charger. It didn’t work for some reason. Drove to a second, got the famous message. Drove to a third, still – same message. Tried “resetting” the car. Googled for help – nothing. I had enough charge to drive to the Oslo dealer, did so. No magic charge could wake the charging unit to life.<>This time it took 5 weeks in the garage. But now they had found the reason for the car dying, some condensator internally not withstanding the type of power we have in Norway is what I’m being told.

Now what

At this point I’m beginning to really become desperate and annoyed. While waiting for the car during its second death. I contact the dealer on the 17th of August to hear about the transformer thing that was supposed to show up during August. Figured I had to have some dialogue with them and try to get my own mood better. The message back is; it will be delayed for another 2-3 months.

A year has passed…

… and then some, since I bought the car. It has not died on me since its second death. But it does occassionally say “Battery charging impossible”. And its just completely random. <>I still have not gotten my transformer. But I have a massive brick with me that does the job, almost.

It weighs in at 27kilograms. So not a lightweighter.

And it does only support 10 ampére charging. Which makes it take some 16 hours to charge when I drove it winter time and had just a few percent of charge left in the battery.

The range lie

Lets bring the story back to the title. Ok. I’ve been messed with quite a bit by Renault and the local car dealer; BilService here in Sandefjord. I’ve been served lies upon lies related to both the performance of the car, range, delivery dates and all. But the biggest of them all is related to the range. And that was actually what got me started on this. I got an email yesterday with an advertisement for Zoe from the local car dealer. Again promoting the awesome 240 kilometers of range of the car. This time with a * next to the 240 kilometers. Me hoping that meant they were going to be more honest, but no.. They actually pointed out that it was 249 kilometers according to the NEDC (New European Driving Cycle). The ad is in Norwegian, but it shouldn’t be hard to get the gist of it.

Having an experience were I see the range be more in the line of 150kilometers on a sunny day with high temperatures and next to no wind resistance and on a winters day with sub zero (celsius) its more in line of 110-130 kilometers, depending on air moistness and all. Added on top that I get the summer range if I drive in ECO with maximum speed of 96 km/h and for the winter range I have to stay at maximum of 90 km/h – there is something really fishy with how these cars are at least being marketed. When I buy a car, no matter what car, I’m not expecting it to be driven in a magical way to get from A to B. I also don’t expect it to have imaginary performance numbers in the lines of “if you drove the car off a cliff and fell for 240 kilometers, you would be able to make the range”. If I were to ever make that range, I think I would have to drive the car at a speed of 50 km/h. I think this is a big fat lie. Renault has yet to come with any excuse to me as a consumer of their products.

The best part, I think… I asked the dealer about the transformer; again… Almost 3 weeks ago, with a more annoyed tone from me. The answer I got was that he could see that I was on the list for the following week. Now, 2 weeks later – I’m just writing down on the “keeping score card” – another lie.

Fantastic.

And its a shame, the car is a nice drive. But if I could turn it back in I would – in fact I was in dialogue with the authorities; Norwegian Consumer Advice – they basically said it was hard to do anything with the situation, just based on the fact that the manufacturer has responded and done “… what they can…” to help me out. I’m now stuck with a product I kinda hate. And the awesome part; the battery quality will deteriorate – lithium based batteries has a tendency to go to 70% capacity after 1000 charging cycles. So that is brilliant when I was hoping to almost make close to one full cycle per day traveling rather than 2. All my math based on a lie, and I’m the one having to pay for it. Thank you Renault. Guess I won’t be your customer for long – nor the local dealer; BilService. Its the worst consumer experience I’ve ever had – I hope you don’t run into this.

Edit: I don’t do these kinds of posts – and trust me, I would’ve preferred not to this time either. But I don’t really know any other way. I’m frustrated, I’ve got a product that is not delivering on a promise, a manufacturer who is not in dialogue mode at all, a car dealer who is just trying to push the problem away, authorities basically saying I’m stuck. I know this is not the ideal way to deal with these things. I could “lawyer up”, but that can easily become expensive. So I don’t know.

Code Quality

Evangelizing

A while back I got into a discussion with another developer. The other guy basically critiqued my code because Angular 1 was so much better than Knockout. It really annoyed me, not because I felt the other person was wrong, or at least not wrong in the sense that I loved Knockout that much. But it annoyed me because its really comparing apples and pears. Sure, both targeting to solve workloads for frontend development on the Web. The arguments presented was very clearly for Angulars ease and against Knockouts idiotic properties being “ko.observable*”. But fundamentally they are different in its underlying core values and concepts. Knockout aiming for a reactive model with its observables, while Angular not having any reactive model at all and being a MVA (Model View Anything) – not opinionated.

This is what bugs the hell out of me. Since these things are so different, fundamentally – how can one be better than the other? And as a consequence, just because one has found something that makes sense for you, why does it have to be true for everyone else? To me for instance; Angular is just completely weird and can’t understand why one would like it at all.

Lets take a step back; this is not a “Foo Framework” against “Bar Framework”. I’m trying to get to the core of something that I think is way much broader than just software development – but probably more visible in software, seing we have all the options we have. Going back to when I grew up for instance, I was a fan of SONY’s HiFi equipment, while one of my best friends was a JVC fan. We had the weirdest discussions. Enter my third friend who was fan of things no one had ever heard of; NAD, Denon and similar. The discussions got even weirder – not from our third friend, but from the others trying to convince him that he was wrong. You can see this with just about everything – people being so convinced their choice of car is the best, TV and of course religion. It seems that this is part of human nature. And we love to evangelize it and try to convince everyone else we’re right.

Trust me, I’m not taking a high road here; because I do this myself. I find something that I enjoy enough to start “evangelizing” it. This is probably something well defined in psychology already; related to wanting to getting a reinforcement of ones own beliefs and decisions.

Core values

There is nothing wrong with a good discussion and if you’ve discovered something you should of course show it off and see if others find it cool. But if you’re in a team, having these discussions around one thing being better than other can truly be poison. In my oppinion it also reflects a symptom of lack of common core values. The discussion of Angular vs Knockout as described above is a weird one because it really is not about a discussion between the two, but rather about the differences in underlying mindset and core values. If you’re used to and enjoy a particular way of thinking, changing to something else is very hard. For instance, if you’re used to object oriented programming, functional can be too far away to understand.

Job protection

A scary thing I’ve seen a few times; people get comfortable in their job – so comfortable that they start making up reasons for keeping their beloved way of doing things. The reasons behind this is not always obvious. The ones I’ve encountered have been in two categories.

I’ve spent a lot of time learning what I know now and don’t see the point of learning anything new.
The company has had success with the way we’ve done things.

For the first reason I’m just going to say “ehh… what…”. That is especially true for our line of work; software development. A relatively young business with so many things changing all the time, and not only changes in software – but the hardware in which the software is running on. Personally I think that is a risky way of going about thinking in our line of business.The second reason; if you’re having success it is really hard to see and even argue that you should change your way. If the business you’re working for is having success, but for instance the software you’re working on hits a snag and you get to the point of getting to rewrite it. Even then, you will have a hard time seeing that you need to do it in a different way; after all – the way you did it worked, because it brought success.

In both cases I think the boiling frog anecdote might be the reason behind. Basically, while building something over time – you won’t notice the things that lead to something not really being done in a good way. You’re having many small successes and feel good periods and you simply aren’t noticing that the project is in fact failing. Most projects do tend to have the best velocity in the beginning and slow down over time. Something the team members executing on it won’t notice, because it is happening slowly. But anyone external to the development team is noticing, because their demands for new things have not declined over time but rather increased and often these are the people dealing with the problems as well – while the development team is having a hard time getting through things at the right pace.

I find what Einstein saying: “Insanity: doing the same thing over and over again and expecting different results.” interesting and so true. One gets into discussions with management of needing to recreate the product from scratch, because you’ve identified something that is holding the development back and is too painful to fix. You get to do “File -> New Project” and do it again using the same kind of thinking we used when we created the problems in the first place (referring to another Einstein quote).

We are so lucky in our profession; there are so many choices – so many ways of doing things. It truly is a luxury.

Mixing it up

At a place I was we were about to embark on a rewrite. A few of us had discovered some new principles and experienced some pain while doing a small 3-4 month project in isolation. From this two of us were tasked to do a small proof of concept for the larger project, to sketch out a direction and a starting point for a discussion. After doing this we decided on the direction for the project and what fundamentals to go for. To get the team familiar with different thinking, we mixed things up a bit by doing a period of Ruby development. Writing Ruby and discovering the culture of rubyists let us write our C# in a different way when we got back to it.

Keeping fresh

So, how do you keep fresh thinking? It is hard, it really is. Everyone suggesting everything from kode katas, pair programming, friday lightning talks and all these cool things must realize that it is hard to get there. They are all good ideas and things that can help your team keep fresh. But getting to a place where you can build this type of culture is hard. You need the trust from the business to be able to do so. Also, you probably need to have a certain critical mass of people working together before it can be accomplished. Lets face it, being a development team of one makes this very hard. But it is very doable. It starts with recognizing that one has to keep fresh and on top of things. If you think when you graduated that you didn’t need to learn new things, you need to start with changing your attitude. That attitude won’t push anything forward in terms of new ways of doing things. Innovation comes from being aware of what is going around out there and combining wizdom and build on top of it or go in a different direction from established wizdom – but nevertheless, its about knowledge.

Breaking it all up…

One way of being able to push forward and try different things to be able to learn new tricks and gain knowledge could be to start breaking your software up into smaller pieces; enter the buzz of the Micro Services. Sure, there is a lot of buzz around this. But cut to the bone; its about breaking monoliths up into smaller digestable pieces. These digestables could be implemented in different ways, in fact – I would argue they should be. Basically because the different parts have different requirements both for business and ultimately also technical. This is a great opportunity to mix things up.

Back to the value thing…

Remember I said something about core values. I’m convinced this sits at the heart of it. If you get to work and it is a predictable environment in terms of you know you share something with your coworkers. Having the thing you share being core values, rather than the belief in something hard and concrete as a specific technology – you move the discussions to a more healthy level. If your discussion is which of Windows, Linux or OS X is the best operating system, you’re probably not solving the real problems. If you can look past this and past implementational details and start having a solid fundamental that you all believe in – you can move up the stack much more rapidly. Chances are that a lot of the decisions will automatically be made for you if you settle the core value debate first. I’ve blogged about this before – I have no problem reiterating the importance of this, I think it is at the heart of a lot of silly discussions that could’ve been resolved without them having started.

Wrapping up…

Is it really important that I drive a Toyota and you drive a Ford? Will the world be a better place if I switched to a Ford? Probably not! Conformity is nothing but just that. It doesn’t really solve any fundamental issues, it covers it up. It is the fundamentals that are different. In software development, these fundamentals are core principles – how you believe software should be written and what makes you productive. This view is a subjective view and it is also a very temporary view. Once you’ve learned new ways of doing things, chances are you look back at your previous knowledge level and laugh or you’re embarressed you ever had that view. If you’re really cool, you even move forward in life and forget you had the view and laugh at people who have the view you had way back… ehh… a whole month ago… Everything is hard until you know it, and then it is the easiest thing in the world. We tend to make a point about it as well. Once we know it, we’re so proud of knowing it that we tell everyone. Knowledge is a moving target, new knowledge emerges – embrace this concept and embrace change. I know I will work for this and aim for getting better at doing better in this area. I have a few comfort zones to break out of and will push forward. Wish me luck!

Uncategorized

Identifying core values

Those who have worked with me have most likely heard a few times and probably also got bored by me saying we have to establish a core set of common values before we do any code writing. What I mean by that is that you can’t have a team work in the same general direction without the team actually believing in the same things. Take a thing like being test driven. If you have a split in the team and not a common consensus of wether or not automated testing is good or bad for your team and your product, you’ll end up having tiring discussions and not establishing a climate for establishing a good culture. Worst case; you might hurt your velocity directly by not adressing a bunch of the elephants in the room and over time establish a declining velocity and not notice that it is declining.

Elephants

Yes, there always seem to be an elephant in the room. And they are so hard to get out of the room. Subjects that are impossible to discuss, because you really can’t reach an agreement. Every place I’ve been to have these, and in my experience, there seem to be more than average in software development. I think this comes from a bunch of reasons, but in my experience it boils down to not adressing the underlying issues and also in many cases, really understand why we go to work. In our industry there are some elephants seem to be quite common, things like my favorites; performance and the “keep it simple stupid”-principle. Performance is by some the trump card, whenever a discussion gets out of hand, you might run the risk of this card; hoping it will kill the discussion and we can move along.

Business Value

Why we as developers go to work is something that can be hard to remember. Our job is to add business value to the place we work. It is so easy to forget this fundamental thing and end up doing things that is not related to this, often based on an established culture of developers having the ability to just ignore this fact. By having the power to create something in code makes us experts in our fields, we do something that not many people understand what is. This power comes with great responsibility, we should not abuse this just because we want to do something exciting. Its easy to bullshit a manager into thinking that using technology X will solve all problems, while you could have done this with a different approach in shorter amount of time but you never got the chance of trying out X. Don’t get me wrong, we should always look at tools that actually improve our productivity or helps us get our business value done more accurately or delivered faster or better. Just don’t make up excuses to get to try it out to get it on your resumé.

Lack of understanding

Lets face it, not everyone wants to learn new tricks all the time. And that is actually fine. Being conservative to change can help balance out those who wants to change everything all the time. That being said, there are also those who are conservative because its convenient, because it suits them to not necessarily go in the right direction and hinders development and moving forward. A great way to protect your own job for someone who has been there since the dawn of time and really just want to continue doing the tasks that has been mastered. In our industry I think you’d be crazy to even try to want something like this. Our industry moves quite rapidly compared to most others and knowing only things that belong to the past is not necessarily a benefit. I think this is also important to understand for some of the elephants in the room, people protecting themselves; they just don’t necessarily understand the new ways of doing things and don’t have the full motivation to actually bother learning it. A good manager should be able to pick up on this and make sure the team is motivated and keep the risk down for the company by actually facilitating for learning.

The User

Who are these users we hear about. Adding business value is good for business, but not thinking about the user and keeping them close could be a disaster for business. So even though you think you’re adding something to your system that you believe will add business value, the users might not want it because you made it in a way the users won’t understand. This is something I see all the time; developers making software look like their development tools and thinking the users will just intuitively get it. Heck, I’ve done this myself on numerous occasions. Its like we get tunnel vision, thinking that everyone thinks like us. They don’t! We are possibly the worst frame of reference for what a user wants. This is one of the things that I think brings more elephants in the room that are not up for discussion. Because we’re used to do something, that wasn’t good for the user, we should just continue down that path.

Being pragmatic

This I hear a lot, and it gets presented as an accusation, as if one is not pragmatic. Short and simple; it is an abused term. It is something that gets twisted to fit as a trump card and thrown on the table to stop discussions. It doesn’t really reflect a value of any sort, its just a way of hiding any core value of actually bubbling to the surface. Its often related back to the “keep it simple, stupid”-principle and is just an instrument used to belittle the other person(s) in the argument. I look at other professions whenever I encounter things like this and ask my self, would they throw this card — ever? Take a plumber, would he pragmatically drop putting in a pipe or even worse pragmatically decide to not comply with building regulations. We can do much better than this. The KISS principle is a really good example of something that has completely different meanings depending on the person you talk to as well. For some this would mean; “… put everything in a stored procedure in the database…” type of KISS, while for me it means I adhere to the SOLID principles amongst other things. I don’t like these terms – they don’t bring anything positive to the table.

Core Values

Back to the original intent of this post; establishing core values. This is not an easy task, it is something that can take a while and it is not something you delegate to one person and hope it solves everything. It is a team effort. The team has to do this together and they are going to have to work together to get the wheels smoothly running. An approach that I’ve had great result in slight variations with, is to let every team member write down on three post-its the three most important things to them. One is not to discuss the items with anyone else, the items can be anything related to what the person consider important to be able to do their job. Every team member has to do it themselves for themselves. Put this up on a wall and let every team member present the case for their items and what they mean. You then optimize the wall by grouping the things that are the same. We now want to cut the list down, we can’t have all the items as our core most important values. Then you give the team 3 votes they can distribute on the things they now find the most interesting with the knowledge that we’re not keeping them all — chose wisely. You should now have a ranked list the things with the most votes are more important and you do a cut off at the number of items you decided to keep. I usually tend to keep it at 10. With smaller teams you might consider increasing the number of post-its and votes, so that you get more than your cutoff, even after grouping. A variation of this that I’ve used was after a disaster of a release at a company were we had a yearly release-cycle. After the disaster and weeks of firefighting I put the team together and asked them to come up with 3 post-its each for how we could make the next release even worse. This triggered something very interesting, people got really creative and every one had great ideas of how to really sabotage the next release. We then voted for the things we found most relevant and that we wanted most to do. We then took the list and we converted it into things we should not be doing and then had a cut off of 10 items that became the law of the land for the development team.

What you now have produced is something that can kill the things used to kill discussions, you have a list of things you all have agreed upon is important. It is the compromise, the things that you as a team believe in. Whenever nonsense arguments are being thrown into the mix, the different trump cards or elephants that sit in the room, you can refer back to the list.

Sometimes it is not clear cut what things mean, and you can end up having discussions about the meaning of it all. Try to capture what people are saying when presenting their post-its, put this in writing and get the team to read through and commit to this. But even after doing that, it might be hard to understand. A tool that can help with getting a common understanding is doing pair-programming as part of how you work. Circulate who pairs and start building the dynamics into the team. You end up discussing some of the items on the list and you will eventually break down barriers and create a team that at the very minimum executes more in unison. Typically the elephants can actually be taken out of the room and you will hopefully and most likely also address the lack of understanding and get to the need of learning much easier.

An example of the process is below, this is from a real exercise.

The things that made it into the list

The things that didn’t make it into the list

The board of votes

Conclusion

Though probably not perfect, it is a way of getting the conversation going and making everyone aware of the fact that we have to be on the same page. You should never underestimate the importance of having the team thinking pretty much the same, and you need to address the core belief system in order for you to be close to getting your team thinking in the same terms. Having a team that anticipate each other and can have a dynamics together that pulls in the same direction gives higher velocity in the long term and also helps people keep motivated. Nothing is worse than not being motivated to go to work because of elephants and established truths. It can feel constraining and for someone not in the same mindset, completely arbitrary because the world has moved on ages ago.

Bottom line; communication is super important and probably the hardest thing to get right.

.net, C#

Machine Specifications – .NET Core

I’ve been working on a particular project, mostly in the design phase – but leading up to implementation I quickly hit a snag; my favorite framework and tools for running my tests – or rather, specs, are not in the .NET Core space yet. After kicking and screaming for my self for the most part, I decided to do something about it and contribute something back after having been using the excellent Machine.Specifications Specification by Example framework and accompanying tools for years.

The codebase was not really able to directly build on top of .NET Core – and I started looking at forking it and just #ifdefing my way through the changes. This would be the normal way of contributing in the open source space. Unfortunately, it quickly got out of hand – there simply are too many differences in order for me to work fast enough and achieve my own goals right now. So, allthough not a decision I took lightly; I decided to just copy across into a completely new repository the things needed to be able to run it on .NET Core. It now lives here.

Since .NET Core is still in the flux, and after the announcement of DNX being killed off and replaced by a new .NET CLI tool called dotnet – I decided to for now just do the simplest thing possible and not implement a command or a test framework extension. This will likely change as the tools mature over time. Focused on my own feedback loop right now.

Anywho, the conclusion I’ve come to is that I will have my own test/spec project right now be regular console apps with a single line of code executing the all the specs in the assembly. This is far from ideal, but a starting point so I can carry on. The next logical step is to look at improving this experience with something that runs the specs affected by a change either in the unit under test or the spec itself. If you want a living example, please have a look here.

Basically – the needed bits are Nuget packages that you can find here, here and here.
The first package do include a reference to the others. But right now the tooling is too flaky to predict wether or not intellisense actually works using things like OmniSharp with VSCode or similar, so I have been explicitly taking all three dependencies.

The next thing you need is to have a Program with a Main method that actually runs it by calling the AssemblyRunner that I’ve put in for now.

<img data-position="3" src="https://03ab57ec0b644567a1e7442a.blob.core.windows.net/wp-content/2016/04/2016-04-16_23-55-21.png" data-mce-src="2016-04-16_23-55-21.png"

Once you have this you can do a dotnet run and the output will be in the console.

<img data-position="3" src="https://03ab57ec0b644567a1e7442a.blob.core.windows.net/wp-content/2016/04/2016-04-16_23-40-52.png" data-mce-src="2016-04-16_23-40-52.png"

.NET Core Version

Important thing to notice is that I’ve chosen to be right there on the bleeding edge of things, taking dependencies on packages and runtime versions from the MyGet feeds. The reason behind this is that some of the things that I’m using only exist in the latest bits. Scott Hanselman has a great writeup with regards to where we are today with .NET Core.

Future

Well, I’m not yet knee deep into this and not focusing my effort on this project. I’ll be building what I need, but of course – totally open to anyone wanting to contribute to this project. But if I were to say anything about my own vision and steps I can see right now that would be natural progressions for this it would be that I’d love to see the first step be an auto-watching CLI tool that will run the appropriate tests according to files being changed. I would not go all in and do a full analysis of call stacks and all to figure out what is changing, but rather have an approximation approach to it – similar to what we put in place for our test runner project for JavaScript called Forseti. The approximation was basically based on configurable conventions mapping a relationship between the systems under test and the tests – or specs as I prefer to refer to them as. After that I can see integration with VSCode – which is my favorite editor at the moment. Something similar to WallabyJS would be very cool.

IoT

Building a soldering station – step 1

When I first got started with IoT a couple of years back, I was fiddling at a very high level with the .NET Gadgeteer platform. Everything where finished modules with fixed wires with connectors on them that you just connected – voila; write some code and you had a fairly powerful device with a bunch of capabilities through the modules that exist for it. After going deeper in understanding and started working with the ESP8266 I got back into soldering again. Its been years since I’ve been there. As part of this, I went out and bought the things I didn’t already have; among this a pair of helping hands:

These just turned out to bee way too much of a hassle to use. Couldn’t really get a good stabile soldering station out of it and the helping hands ended up not being helpful at all.

I decided to research what was out there and couldn’t really find something that was affordable enough IMO. Being a hobby, I don’t want to flesh out too much cash on it.

After a bit of research I came across quite a few DIY projects and started planning out my own version, inspired by these. The ones I found the most interesting was the ones based on the gorillapod style camera tripod. The reason I found this the most interesting is that I wanted to have some really sturdy legs – and these are perfect IMO for the job. Anyways, the ones I got were these. With regular crocodile clips

The build

The first thing I did was to disassemble the tripod completely. You can simple pull the legs off by hand with a little force. I peeled off the base – it was glued to the end joint of the legs. With this, I ended up with the following

The next thing I did was to drill a hole in the end joint that is the end of the leg – mine was covered with rubber, so I took the rubber off, pulled the hemisphere off the leg and drilled a hole to fit the crocodile clips.

With the holes I could now start fitting the crocodile clips:

I decided to glue the clips to the hemispheres. This is a decision I might go back on and figure out a better way to attach them to the hemisphere. I’ve thus far had a couple of times they move out – not really a big problem, but still; perfectionism and all :).

The glue I used is a typical building bond:

My idea was to have a stone base – heavy enough to not move around when I am working. I had a particular look in mind and wanted to frame the stone. I decided to go with varnished oak, which gives a look I’m quite fond of.

On three of the sides I fitted the arms. I decided to go with stands from a prototyping board I had been using and put the arms on these. First I needed to drill holes for these and an inset for them to fit in.

This is how they fit in the inset.

On the flipside I just put a nut on it.

I then drilled a hole in the opposite hemisphere of the leg, the one that was glued to the base. This will then be mounted on top of the stand and attached with a screw going through.

With this in place you can attach a leg and get a general feel. On the picture you’ll see the stone I picked. It is in fact a regular cheramic tile with a specific stony look. This one I got for free at a local tile store. Turns out they hand out tiles for free for the purpose of sampling at home.

The last piece of the pusle is then to put together the frame and glue it all together. I decided on gluing it all with the same adhesive as mentioned earlier. Its not going to move around all that much, so my theory is that its more than good enough.

The end result

Next step

This is the first step of this – just to cover my most immediate needs; helping hands. I do however want to expand on it. For instance, adding compartments in front for all the consumables (soldering tin++), cleaning wool – but also a holder for the soldering pen that I use. I’ve also contemplated buying a more advanced soldering pen with a base for regulating the temperature and have looked at a couple that could easily fit in my build. Stay tuned – don’t know when though.. 🙂

IoT

My Internet of Things

Back in the days when I got started with computing as a kid, we soldered our commodore 64s quite a bit. We added things like reset buttons, which the computer didn’t have and similar. We modified like crazy, to make our every day of coding easier.

I left this itch behind for years until a couple of years ago when I started playing with the .NET Gadgeteer platform. Lowering the threshold to a bare minimum to get started. I ended up buying a lot of sensors and modules, but really didnt’t have a project to use all the stuff I had bought – until about a year ago. We had only ony remotecontrol for our garagedoor and I started looking at buying a second one. They were so expensive and I decided to build my own. It quickly exploded in what I wanted to do; it had to have RFID and eventually an app and much more, things like geo-fencing for automatic opening when I got close to home.

With high spirit I went all in and got it up and running on first attempt. There was a problem however, there were edge cases that caused the relay to generate an interrupt in the gadgeteer that looked like the button I had attached was clicked whenever the original remote was clicked. With next to no real understanding of how the electronics really worked, this completely stopped me in my tracks and I abandoned the project till I had figured out how to fix this. Then I discovered ESP8266 after an internal hackathon we had @ work. My mind was blown with the price. You could get for less than 2 USD, and it included a WIFI adapter onboard. My frame of reference being the Gadgeteer platform where you could easily end up paying 80 USD just for the WIFI adapter alone.

ESP

So, a computer – very small, with a 80/160 MHz CPU and a WIFI for under 2 USD. What could we do with this. Well, it does not provide the abstraction of the gadgeteer platform. But it is really not hard to dive in still. Sure, a few more things, different tools and a bit more hardcore – but very doable. Firstly, there are a few versions of the ESP. The simplest being the ESP-01 with only 2 GPIO ranging to the ESP-12 with 11 GPIO pins. Also in the mix are all the abstraction platforms often referred to as developer versions built on top of this to make it simpler to work with by exposing a USB header in front to be able to connect it directly to your computer. There is a good comparison of the most common ones here. I ended up researching this myself and ended up buying a lot of variations. My conclusion is that I will be running the ESP-07 for those scenarios when I want an external antenna for better reception and ESP-12 when I need more GPIO and ESP-01 for my basic projects.

Getting started

The easiest way to get started is to get one of these development boards. You should get a breadboard. But, I want to point out however – getting up and running without a development board is fairly easy. A bit more connecting things manually, but very rewarding when its done. Besides, tons of learning on the way – which I find the most important part of my journey. Anyways, to satisfy both cases there are kits out there that provide you with the breadboard, power supply for the board, USB to UART and the necessary wires. For instance this kit, which I bought. The USB/UART module here is based on the Prolific PL2303 and you need a driver for it, which can be found here.

If you’re going to be working a lot with the ESP-01, I recommend getting a breadboard adapter to easily connect and disconnect your ESPs. I bought this.

Moving beyond the breadboard when you’ve prototyped things, you can step up the game by going for the prototype PCB boards. Lowering the footprint and making it more permanent, but without having to play with chemicals or send your Fritzing drawing for production. I’ve personally not reached the Fritzing level yet – but aiming for it – so I’m happy playing with my soldering iron on the prototype boards for now.

Making things nice and feel more like proper devices instead of a spiderweb of wires coming out of your project, you can look at using connectors – you can get all kinds. I’m trying out different ones, for instance the 3 pin connector.

Power

One of my goals has been to create small self-contained devices, preferably with a certain WAF. This has meant that some sort of embedded power is important. This could be battery or its own AC/DC adapter making it possible to put it directly into a power socket for instance. All the components are easily accessible. For instance, there are some very neat and small AC/DC adapters for only 2-3 USD. If your project needs only 3.3 volts, you could go for this. If you need 5 volts, then this could fit the need. The ESP runs on 3.3 volts, so you would need to step down the 5 volts using a step-down converter like this. If you need more than 100mA for over time you need to look at other options. Remember however, working with AC is a lot more risky than the DC low voltage, low current things you end up with and you must be sure that the adapters are good quality so you don’t end up with a fire hazard. An option to this would be to just embed a USB charger, they tend to be small enough. Then at least you’re using something that is well tested and won’t invalidate your insurance.

What about those projects you want to place where there is no power source? There are quite a few options when it comes to batteries. You can use anything from a couple of AA batteries to a special purpose lithium polymer battery like this or if you need something like 6000 mAh you can go for something like this. There are chargers out there for these, but I’ve been looking at this and wanting to make it with an embedded charger and just expose an USB. Luckily there are solutions for that with something like this. These types of batteries is my goal in the long run, but for now I’m fiddling with regular AA batteries and also the 18650 batteries, packing a whopping 6800 mAh. Since they deliver 3.7 volts and have this capacity, I figured I could do with one battery for each project. So I went for this case holder. I also bought a charger for them. For holding your regular AA batteries, you can get something like this.

An interesting aspect when it comes to power is to make sure the device is not drawing more power than it needs to. Luckily the ESP has a few tricks up its sleeve that we can utilize to achieve this. Looking at Espressifs site, you’ll find the different consumptions you can go for.

For some purposes you might want to go all the way down to deep-sleep and just come out of it on a regular basis. If you’re measuring something on an interval for instance. The ESP-01 does not support the deep-sleep from a hardware perspective, but with some wizardry on the hardware you can get it to support it. Have a look at this. The beauty of this is that you can easily with the battery options I’ve mentioned get a solution that can last for years.

Development Environment

The default firmware will let you develop using C and you can lower the treshold using the Arduino IDE. Another option is to go for LUA, which the NodeMCU for instance comes with. To be honest it does not really matter which language you chose – as it will most likely be very small programs you’re writing anyways. That being said, I focused my effort pretty early on Espruino – it enables JavaScript. Sure, I’ve read the Pragmatic Programmer and should probably have chosen LUA, since I don’t know it – C is something I know very well, having written it professionally for 10 years. But couldn’t really see the huge benefit for me in this scenario, besides – LUA is not that different from JavaScript.

Flashing is pretty simple with the right tools. First you need to get the firmware from here. The flashing process is described here for all operating systems.

Once you’re up and running with flashing, you can use something like the Espruino Web Ide to do your development. It works fine and enables you even to connect to the ESP over WIFI. The ESP has a Telnet server, so once you’ve configured the network on the ESP you can simply telnet to it on port 23. Read more about configuring the network on your ESP and how this all works here.

My goal however is to be using Visual Studio Code for development and connecting to the board when I want to try things out. A promising project could then be this. I failed at getting it to work. I therefor started looking at alternative approaches to let me stay inside Visual Studio Code but just connect to the device and upload code easily. There is for instance the EspruinoTools that has a CLI tool. Unfortunately, this tool does not have the scenario of connecting over WIFI, which I found to be very good for me. So I ended up starting on a tool my self that can be found here. My first goal is to hook these up inside VSCode by using the task system. Who knows, maybe I’ll move beyond it – providing a more integrated experience.

Another thing that I find important for me is to be able to write nicer JavaScript. This is just an itch that I have, I could easily do all my work with the toolset I’ve described. I just have this “if I know I can do something better, I better do it”-itch. So ES2015 is a clear goal. This can be achived using things like BabelJS. I’m working on a set of Gulp tasks to do this. Sure, there is a slight overhead with this on the memory footprint. But with bundling and minification in combination, I should be able to aleviate some of this. Besides, I think memory is not going to be an issue for most of my projects. Well, at least not until I start pulling in MQTT libraries or similar. 🙂

Summary

The treshold for building IoT stuff today has really been lowered. Sure, we can still do things like the gageteer things or maybe even better yet for kids do something like LittleBits. Once you get the hang of things and have an urge for diving deeper, it still is not all that hard. I’m impressed with the amount of resources out there, so learning should really just be a question of crawling the web – and it shouldn’t be hard. The hardest part I found was getting the vocabulary right. What are the names of all the things I needed for my projects. This is still a pain point, but I’m not sweating it too much – I see that it increases day by day. I’m totally hooked and really have found a hobby that is a lot of fun where I can also build things that are somewhat useful at the same time.

One thing I find really interesting is the evolution of the ESP platform, it has exploded in just a couple of years – and its still being pushed forward. The upcoming member to the family; ESP32 is very interesting with its bluetooth option and more GPIO. Really looking forward to it coming out.

Hope you found this writeup useful – feel free to add pointers and correct me if I’m wrong on things in the writeup (I’m pretty sure I’ve misunderstood a few things in my journey thus far).