Menu Close

Docker – just do it.

boot2dockerLots have been said in praise of docker. I agree with all most often named advantages, but I think one is really neglected to be named. Or maybe it is so obvious that I am the only guy who thinks it should be named explicitly. What can that be? As soon as you get basic docker skills your entry barrier to learn new trendy technology gets decimated. For every Redis, Mongo, akka.net, EventStore, Kafka, .Net Core, Ruby, Elixir, R, Python, Clojure and what have you – you can get started in seconds to minutes by delegating environment setup for each of these to docker system. No heavy environment setup, no missing dependencies, no accidental co-modification, no problems if your machine needs to reinstall OS – just pure engagement with what you actually want to do. And once you get there every taken step encourages you to take two more.

I’m by no means docker expert, but it has changed my professional life so much, that I promised myself that I will share some examples just of sheer gratitude.

Disclaimer: I will not explain what docker is and what is it used for. This is not description of what docker is, it’s a entry level tutorial for people who know that already and now want to try it out.

Part 1 shows how to get docker running on windows machine.

Working in (really) small chunks

1463585843_hourglassIt has been said multiple times already that one should work in small chunks. I was subjecting myself to such approach since long time. But I think I have never reached level that I have just recently. And surprisingly key factor that led to this is not at all work related – it’s my family situation.

We’ve just got a 2nd daughter! One of practical implications of preceding pregnancy was for me increased work time fragmentation, because of doctors appointments and stuff alike. This naturally means, that the longest time slot that I could work on something was (on average) shorter than in has been before. But that on it’s own was not a game changer.

The actual game changer was the thought, that any minute I can get the “it’s now!” call.  This made me organize my work in a way, that allowed to reduce waste in such case. This means that I coded in very small chunks, committing code 8-12 times a day, instead of 4-6 commits/day, as it was before. As it turned out it is still possible to keep every commit relevant to business case and having unique value for solution (I also have to admit, that the project and the tasks allowed it just fine).

Furthermore, if I got any information or came to a realization that could be relevant for the project in foreseeable future I rushed to share it with people around me, so that they could use it independent of my presence.

If you think about it it’s really paranoid approach. The one moment that is unavoidably coming is affecting weeks/months of work-style. But this is something that I will try to keep doing, accidental improvement if you will.

One more thing to keep in mind: committing must be fast not to destroy the flow.

 

[Freebee][DE] Happiness index graphics

Happiness Index in ControlExpertAt my workplace we’re collectively trying to change the stuff for the better. Our management is flexible enough to give a try to some of our ideas. Therefore few days ago we got first consultancy session from Holger Koschek, whom I got to know at XPDays2014 (awesome conference btw). As one of the results of this meeting we’ve introduced our own version of happiness index. It gives a possibility directly show what is the reception of decisions and processes going around. This results in very short feedback loop.
Happiness Index

Of course this changes nearly nothing by itself. But this will be our yard stick for employee satisfaction in upcoming months (or maybe longer).
Regardless of our future success or failure with it, Holger, who authored the graphics, had nothing against me sharing them with rest of the world. Neither did my boss, so here it is, use as pleased. Do-what-you-want licensing applies.

Download Happiness Index Graphics

Sharing ReSharper’s settings across multiple project and team members

After unifying understanding of what good code looks like in my team I tried to configure tools that could help us in striving for this goal. We all use ReSharper, but built-in settings sharing mechanism doesn’t support our use scenario well enough. We are maintaining system of systems, we are working with multiple code repositories on daily basis. Rules for nice code stay the same in each of these, same as domain language, recognized abbreviations and so on.

ReSharperSettingsLayertStyleCop seems to understand and support such usage scenario. StyleCop sequentially scans all parent directories, starting from analyzed file’s location, up to drive root in search for settings files. All files get merged to form effective results set.

Fortunately there is a plugin for ReSharper that can do the same, it’s called “ReSharper Solution Settings Autodiscovery“. It only requires to adjust settings file name – it has to match *.AutoLoad.DotSettings pattern. This plugin integrates super-nicely with ReSharper.

 

ReSharperSettingsSavingIn my team we have dropped all project-specific StyleCop and ReSharper settings files in favor of shared ones. Only thing to remember is that when adjusting the settings they should be saved to this shared settings layer.

To keep settings up to date and track the changes we have made root directory of cloned repos just another repository. Thanks to .gitignore that looks like this:

*
!Settings.StyleCop
!TeamGlassCheck.AutoLoad.DotSettings
!.gitignore

ReSharperAndStylecopSharedSettingsthis tracks only files that we want to track here (tools settings files).

As a cherry on a cake automatic pull/commit+push tasks can be added to system scheduler, to make sure that setting are always up to date.

 

Entity Framework’s quirk: imagined ambiguity

Triple-facepalm

Lots have been said about Entity Framework, in past mostly bad things. Lately I hear more and more voices speaking in advantage of this library. It is being said that it has reached maturity point and is actually usable now. Of course it was usable earlier, but it had its quirks. Unfortunately some are still there. I have recently found one that I couldn’t really believe is true. I had(also severe) problems with EF before, but this one is absolutely no-go for me. If exception message below reads familiar, then most probably you are experiencing it too.

 

Schema specified is not valid. Errors:

The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type ‘<<entity name>>’. Previously found CLR type ‘<<namespace1.entity name>>’, newly found CLR type ‘<<namespace2.entity name>>’.