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”;

TheCodeLab.png

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. 🙂

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.

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.

  1. I’ve spent a lot of time learning what I know now and don’t see the point of learning anything new.
  2. 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!


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 get reach an agreement. Every place I’ve been to have these, and in my experience, there seem some be a tendency to 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.


Tagged ,

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.

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

.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.

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.. 🙂

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.

20150112172151.jpg

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).

Bifrost – end of the line

Prior to 2008 I had only worked at ISVs (Independent Software Vendors) and game companies going back to 1994. At this point I decided I needed to get a change of scenery and become a consultant – try something completely different. In the beginning, since I had no experience with being a consultant – my boss and me figured it would be best to have a few small projects to get the gist of things. After a couple of these small projects I started feeling some pain; I was rince-repeating a lot of the things. I’m not entirely sure how other consultants do things, but I decided it was time to gather the things that I was constantly doing into an open-source library; a collection of tools that would speed up the process when onboarding into projects. From this Bifrost was born.

It grew from over a couple of years and at the time had no true vision other than make my everyday easier. Back in 2009 I got hired as a consultant @ the largest eCommerce in Norway; Komplett. At Komplett I was tasked at first with working on some integration and establishing a new object model, or as we liked to call it back then; a domain model. It was pretty much an anemic domain model, something representing the data in C#. An approach I had done a number of times over the course of my career at this point. In the middle of this work, someone had discovered a missing feature in the system which was a critical feature for a company being merged into the Komplett group. I was asked to head development of this feature and I could bring 2 more devs. We decided to make this a learning experience in addition to concretely implement the feature. In the learning we wanted to pick up on new ways of thinking and also some new tech, amongst it ASP.NET MVC. The team ended up being Michael Smith, Pavneet Singh Saund and myself, plus a dedicated product owner. We did quite a few discoveries in this project and by far the most important being the discovery of commands. We also discovered how domain models as we knew at this point in time didn’t really work. Worth mentioning is also how we started seeing patterns of how we should not do things. This lead to larger project, a rewrite of the core web. Midway through this, I gave a talk @ NDC 2011 about our experience with applying CQRS, which was the conclusion we were closing in on. From this I was contacted by a representative of Statoil a few months later. They found the topic interesting and also the platform; Bifrost (yes we got pretentious and dropped the library and framework label and called it a platform – it kinda grew 🙂 ). We were onboarded in the beginning of 2012, and I mean we – Michael joined and later also Pavneet. Kept the team together, all as individual independent consultants. This was a huge part of our progress in learning; the team. We knew each other well, had concrete focus areas and managed to move and learn fast.

At this stage we found ourselves in a position of having gone through a sort of knowledge transition. To me it felt like I had gone back quite a few years from 2008 and created a fork in my knowledge bank. It felt at times like this fork was diverging more and more from what was commonly being done on projects around us. Not claiming that our fork was better or anything, but made more sense to us – with our history together and our shift in mindset that we decided to do. From my experience, comparing before and after – I conclude with we managed to write better and more predictable software. But it came with a certain amount of friction. The stuff we were talking about was not as Google-friendly. Less resources to refer to, which is a very important aspect when you have for instance a team of 20+ developers that you’re trying to convince that your thing is better; not to be underestimated at all! Something we were quite aware of and made us a bit hesitant to push through, but had confidence from key persons on the projects we were on to push forward. The huge disadvantage I’m seeing today of having pushed on in this fork and having to spend a lot of time maintaining and convincing others, left us blind to what was going on outside and we became an echo-chamber for a lot of things, not realizing that some of the concepts we had discovered and if I dare; maybe even pioneered (without letting anyone know) has surfaced in elsewhere and are now becoming part of how we all do things. Which is just truly great.

 

The future

 

Its now been 7-8 years since the project was started, where is it today. Well, it still exists, sits on GitHub. Thus far the project has moved forward because of the maintainers needing it to. We were using it for the projects we were on. This has also been the key reason why we’ve implemented things; if it had a real world scenario – we could identify it and develop it. We’ve always kept a close eye on the real world, not making anything for its own purpose – but fill a need. Fast forwarding to today, February 2016, our team is no longer a team and skattered in different companies. We are no longer working together, and none of us really using Bifrost for our day to day work – this represents a problem for moving things forward, given the history of how things have moved. Take me for instance, I’m no longer actively working on a real world project – although I’m working on changing that somewhat. To keep my knowledge fresh in the type of role I have now, I’m dedicating time to build a project I’ve been thinking of for a couple of years and something I need myself. But it turns out, this is not enough of a reason for me. I have decided to go a slightly different route to build relevant knowledge to what I do.

One of the goals of Bifrost was to tackle things we believed would provide better quality software, one of them being to decouple and not build monoliths. Today, I see Bifrost as a bit of a monolith. There are too many things inside the core framework. It should have been broken up. On top of this there also are some logical couplings we never intended. There are also things I’d like to do differently in how its been architected, and basically learn from mistakes and correct them. Worth mentioning is also complexity that was put in there for imaginary problems that turned out to not be anything that would happen any time soon. For those using Bifrost, it would be too much work moving forward with the amount of refactoring that I’m looking for, plus too much work for me or anyone else maintaining it all. Although difficult, I see no other way around it but to just admit that I will not be able to set aside time to do this properly and therefor I will not continue the maintenance of it, nor maintain any pull requests at this point. When I can’t guarantee a feedback loop, it only looks bad in the repository. I’m truly proud of what we have accomplished with the project. It is by far the cleanest code I’ve ever written, adhering to the principles that I believe in. With more than 2000 automated specifications (BDD style), it has proven to be easy to refactor and as far as we know; very stable code – thoroughly tested. There are of course things I’d love to have done differently. Blogging more actively about the things we did in Bifrost, creating awareness – because as I said, I’m truly proud of what we have done. Actively maintaining documentation is a second thing – making it easier to figure out what things do. We did put in XML documentation into all C# code, but never really did anything proper with it. I’d also do WebCasts to cover topics, create tutorials and more. Who knows, maybe Bifrost could have been a business on its own. The luxury of looking back :).

 

Harvesting

The last couple of months has been a retrospective going on inside my head with the purpose of figuring out what I think was good and not. In combination with this, Pavneet, Michael and myself has had a few discussions between ourselves about the same topic. Gaining the distance from everyday maintenance and implementation has really helped and has made things a lot clearer.

From this I want to start harvesting from the experience. Primarily I want to harvest in the term of learning, take the knowledge and bring it forward – modernize it – keep it fresh. Then I have a hope, not willing to call it a goal yet, to turn this knowledge into something more concrete. I’m not entirely sure what this concrete thing is yet. If it appears in the wild in terms of an open-source project representing this or not, I’m not sure. I’d love to, but only if I find it viable.

What I do concretely want to do is to start braindumping some of the things we learned, the things we really enjoyed and we found useful. The braindumping will be in the form of posts here.

Below is a list of topics from the top of my head that I see as key points for the kind of harvesting I’m talking about. I have no idea what format things will take and what will end up where, so lets see.

 

  1. Core Principles – SOLID, SOC, DRY
  2. Productivity and true meaning
  3. Discovery mechanisms and Conventions
  4. Cross cutting concerns
  5. Domain Models
  6. Commands
  7. Events + EventSourcing
  8. Domain Driven Design
  9. Eventual Consistency
  10. Low Coupling, High Cohesion
  11. The importance of the clientside
  12. Validation != Business rules
  13. Operations
  14. MVVM – the building blocks
  15. Regions in the client
  16. Coding style
  17. BDD – Specifications by example style of testing
  18. Feedback loop
  19. Declarative
  20. Compositional software
  21. How inheritance creates coupled software
  22. Don’t be afraid of duplication in data – persistence polyglotism
  23. Bounded Contexts and their relationship to MicroServices

 

 

Conclusion

Being realistic can sometimes be hard. I must admit I have not been honest with myself nor with others. Its hard when its your own brainchild to let go, but the place I am in my life right now has little room for maintaining a project the size of Bifrost. I have a job that is different and demanding in its own way, I have 2 kids thats growing up and I must prioritize being there more for them before its too late! I have neglegted hobbies that I’m trying to get in touch with; my IOT devices, writing more blogposts, attending user groups. I have a house that I want to do some work on and tons of tools to do it with that’s screaming for my attention. I’m also active in the school, in something similar to PTA here in Norway. The only correct and honest thing to do is to tell everyone; I’m not going to maintain Bifrost anymore – nor maintain pull requests. Thanks to everyone that believed in the project, the guys maintaining it and fellow journeymen; Michael, Pavneet. A big shoutout and thanks to Børge Nordli who is on a project using Bifrost and has the last year contributed quite a bit back.

PS: Project will still sit on GitHub

 

6 months into it

Time flies when you have fun, they say. Its been 6 months into my life @ Microsoft. Figured I’d summarize a bit.

The first indication I’ve been busy is the fact its actually also been more than 6 months since I posted anything here. That is just crazy. I know I kinda have slowed down the last couple of years, but never to this level of NADA, ZIP, ZERO.. And trust me, its been very busy.

Onboarding @ Microsoft has been a lot of fun – so much to learn, and I love learning! My role; Technical Evangelist – really does not explain what I do – at all. Basically I’m more of an advisor. My job is to help ISVs in Norway get the best experience in Azure. The thing is; there are an estimated 600+ ISVs in Norway. Some of these aren’t ones we would talk to, based on “natural selection” (basically, those not doing anything or have any plans of doing anything in any cloud). But even after this, there are enough left to talk to at least one ISV every day. I work in a team with 3 others representing more of the business aspect of working with the ISVs, with different focus areas ranging from startups to more established ISVs. Needless to say, these guys run in a lot of meetings, talking and trying to figure out what ISVs are interested and need to dig deeper. This is were I enter; try to understand their business and what technical needs they have – but also what needs they might have based on where they see their business go. On occassion I dive deep and get involved in creating proof of concepts that requires me to deliver code – not something that will be put in production though.

One of the true joys of the prototype part is that I can do things in the open @ GitHub when I identify common things that would benefit more than one partner. Having done open-source development for a few years, I’m careful though. Anything put out there needs more attention if its a reusable component.

Then there is this fact that my role is called Technical Evangelist; there is a part of the job that actually involves doing presentations and write blogposts. And I love both.


Different

I’ve worked a few places in my career. But hands down, Microsoft is different in all aspects – in a good IMO. Fair enough, I don’t have the type of role I’m used to having – but that aside, there is something to be said for the working environment, focus, structure and pace.


EMail

So.. What are these team chats you talk about. After getting used to everything being available on Flowdock or Slack for a couple of years, email feels like a true step down. This is a massive difference. The amount of emails I receive is ridiculous – but its needed. And I am coming to the realization that none of the tools I’ve been using could fix this in any way. So even with its shortcomings, email is king and I’m learning to live with it again. Its probably been 10 years since I’ve had to use folders to organize my emails – now after only 6 months I must have a 100 or more folders.


How about that coolaid?

Well.. Before I started @ Microsoft I had a few things I was starting to dislike about what they were doing. I felt that there was a need for revitalizing some of the tech and to be honest – recognize that there are other platforms and really start targetting them. I’m a Mac guy – and have been so since 2008. At this point in time I made a decision to step outside the Microsoft bubble I was in. It lead to a lot of cool new experiences and my favorite part; learning. Most of this learning I brought back to the projects I was on, which was C#/.NET projects. But the change of platform meant I had to actually learn new things which again lead to me wanting to explore even more. I grew back my apetite for learning. My wish has come through; Microsoft over the last couple of years have done the exact same thing and exactly what I criticized them for not doing when I was on the outside. The amount of stuff that has been open sourced for instance. Most of the things being done has a cross-platform thinking going into it. I’m really loving this. And yes, I’m half way down the cool aid. Azure has been on my radar and in my toolbox ever since it was launched in 2008 @ PDC. With all the new stuff thats going on top of this, I am truly smiling. I can now do all the things I’ve grown fond of over the years and the best part; I can use the best tool for the job – mix and match – on almost any platform.

My Biggest Challenge

Having a role like I have requires me to pay attention to a lot of things. Being in a small country, we don’t have the luxury of having a lot of people focusing on the different aspects of Azure – I basically have to know most of it, or at least know of it and go deep when called for. This is kinda fine, its knowing technology – and over the years one kinda absorbs new technology without too much hassle. The biggest challenge to me is to not stay in touch with real projects and gain real true experience with actually deploying the technology. This is truly the most important aspect in my opinion. Its when you use things you learn what works and what doesn’t. We’ve put in motion actions to actually gain the needed experience across our department. But in addition, I’m now starting a pet project that I’ve been planning for a couple of years and as luck would have it; the project will touch on most aspects of Azure. Now that I’ve gotten past the initial hurdles and starting to get a bit more comfortable with my role, I think I’ll be able to have the extra energy at night to do this.

Conclusion

In conclusion there is no conclusion. This is all so new and different that I just have to go day by day and see what is behind every corner. I’m excited, willing to learn and highly motivated. These things help.. 🙂




New and interesting challenges

First of July I’m starting @ Microsoft Norway in the Developer Experience (DX) team. My official, on the paper, title is Technical Evangelist – which might sound scary enough. But in reality it’s a multifaceted position ranging from sure enough evangelism in the sense of talking about Microsoft products and promotoing these, to advisory for clients, community work, blogging and more. My particular role will be geared towards the cloud; Azure, but I will be sure to keep in touch with the entire stack – as I really love keep on top of things. I spend a lot of time in front of the computer both work and non-work related, so I’ll be sure to keep up.

I’ve worked closely with Microsoft since 2001, since 2008 I’ve been a Microsoft MVP and at times its felt like I’ve been an employee without having the privileges an employee has. So when my new boss said to me a couple of weeks ago; “Welcome home..” – that is the feeling I actually do have.

The timing for me is perfect, both on a personal level, professional level and seeing all the cool things that really excites me that is going on at Microsoft these days. I’m bursting with joy for how Microsoft has turned around and really looking forward to engage more in the coming years with this.

How does this impact other things. Well, I’ve had a company on and off since 1997 called Dolittle. At first as a way of picking up freelance work and the last few years more focused. I am closing down the company. Keeping the brand though, with domains and all, but putting it to sleep as a company. For other things, the opensource projects I’m involved in; Balder, Bifrost, Forseti and more. I’ll keep on working on them when I have a chance. Maybe not as focused as before, as I’ve had the pleasure and luxury of being able to maintain the projects at work for the last few years. They’ve been with me for years and are babies to me, so it would be hard to let them go. Besides, they serve a great purpose for me in keeping up with the whats going on the world of development. I am a developer after all and if I am to do a good job talking about it, I need to maintain my knowledge.

I’m super excited and honored to become a member of the team. Really looking forward to it.