Development, Testing

Mocking internal interfaces

Yesterday I’ve worked on connector library used to access data warehouses provided by two external vendors. In order for it to be easy to use I limited public members to:

  • library interface – can be used to aggregate connectors and testing
  • two connector classes that that provide public methods to retrieve prepared responses
  • DTO request and response classes

Continue reading


Elipse and Circle inheritance problem

Recently I’ve been listening to Coding Blocks podcast, an episode which subject was software design anti-patterns. They described one of them, which is pretty well known: the Circle-Ellipse problem.

The problem goes like this: let’s assume we’re writing a program and we’ve created IShape interface (which might have methods to calculate circumstance and area of the shape). Now we create Ellipse, which implements IShape interface and follows that with Circle class. Now since Circle is a special case of Ellipse, and every circle is an Ellipse it naturally should inherit from Ellipse.

Continue reading


I just wrote that without StackOverflow

In the life of many developers comes the moment, when you write something non-trivial and it just works. And you don’t have to google anything! It’s quite thrilling!

I have been creating a mock object for testing, that could store several graphs at the same time. The graph was very simple, it could have only root (portfolio) and leaves of several types. Linking was done from leaf to root, by setting two properties (a little redundant): parentId and parentName.

I figured that writing a function that would link it automatically without the need to repeat that every time could improve code quality. However, leaves were of different types. They just happen to have the same properties, but no way I could write a generic method that could use it.

Neither of them was inheriting from any other object, but I figured I should go with the interface anyway since I just required for two properties to be there and I know that some databases don’t like when types share a common ancestor:

public interface IPortfolioLinked
    string PortfolioId { get; set; }
    string PortfolioName { get; set; }

I had been using Ploeh.Autofixture before, so I just went with whatever it was providing me and I have created an extension method that would take builder, attach parent symbol to it and return builder of the same type

public static IPostprocessComposer<T> WithLinkedPortfolio<T>(
    this ICustomizationComposer<T> builder,
    PortfolioDTO parent) where T : IPortfolioLinked
    var parentId = PortfolioDTO.CreateId(parent);
    return builder
        .With(x => x.PortfolioId, parentId)
        .With(x => x.PortfolioName, parent.Name);

Overall it’s not impressive. But I’m quite excited about it because:

  1. I’ve just written it and everybody is excited about things they wrote
  2. I haven’t used any external sources. I just knew all of that quite intuitively. Yey!
Development, Testing

Mock – my favourite mock engine

When I try to unit test class one of the most important things is to eliminate all dependencies and replace them with proper mocks. Such mocks allow me to fully control inputs that object will access and verify that proper methods have been called.

Recently I’ve written one business logic class that manages SPA (Single Page Application) and uses four different repositories from which it pulls data and presents them as Web API.

Continue reading

Development, Philosophy

Customize your work environment, and why it’s a bad idea

dvorakA long time ago I’ve heard about the Dvorak keyboard layout and how superior it is compared with standard QWERTY layout. After few minutes of Wikipedia research I’ve learned that QWERTY is one of the worst possible layouts and was introduced with explicit purpose of slowing down typists. You see a long time ago, in era of mechanical typewriters, if you happen to push two keys at the same time the machine would jam. This would require you to manually unjam it, which takes only about 2-3 seconds, however it would happen so often, that loss of speed was noticeable. Enter QWERTY layout – the one that would maximize the distance each finger need to travel between letters in english alphabet and therefore making jamming less likely and (paradoxically) increasing overall typing speed.

And a hundred years later, we’re still stuck with it…

So in my mind I’ve come up with perfect solution! I will master Dvorak layout and became even more awesome programmer. I would be mystical, less prone to make mistakes and I would type even faster. What could possibly go wrong!


I’ve purchased keyboard stickers, that would allow me to rearrange keys on my Microsoft Sculpt ergonomic keyboard (I wouldn’t dare to snap them out and rearrange. They wouldn’t fit anyway), found online learning course and started typing. Beginnings were quite hard as my fingers would subconsciously snap back to old memorised key positions. I did tons of mistakes at the beginning, but after about 2-3 weeks (of daily training) I gradually started to type faster and with fewer errors.

Shortcut limbo

At this time I started to notice some issues with Dvorak keyboard layout. True – every english sentence was quite easy to type, but learned over the years keyboard shortcuts were real pain. Just imagine doing Ctrl+C, Ctrl+V. Yes.. both are quite far away from Ctrl button. I’ve learned that one of the most common combinations that I would try to use is Ctrl+S, which I simply could not use with just one hand and just imagine me trying to undo some mistake with Ctrl+Z. There were also few Resharper shortcuts that became a hassle like Refactor -> Rename (Ctrl + R, R).

Programmers != Typists

Another important thing that I’ve learned is that programmers aren’t actually typing all that much. I spent most of my time reading and making small adjustments in the code. DRY (Don’t Repeat Yourself) principle tried hard for me not to write too much code overall, so the advantages of Dvorak layout became less and less obvious.

Your team will hate you

But worst part of actually having uncommon keyboard layout is that nobody else is able to use it. The usual scenario would look more or less like this. I would ask one of my teammates to help me understand some obscure class, they would come over look at the class, start a polite developer conversation, something like: “Oh yea. I remember this shit, a guy that used to work here 2 years ago wrote this, and nobody touched it since“, then they would try (to the best of their abilities) to remember as much as they could about a topic. They would pick a mouse and try to navigate to some connected classes, they would use one of the keyboard shortcuts to navigate properly just to learn that (at best) it wouldn’t do anything or do something bad. Afterwards they would look at the keyboard, then give me my mouse and keyboard back and just point at the screen and say “get to definition of that, I can’t use this shit“.

Similarly if somebody junior will ask you to help him, because this simple snipped of code just doesn’t compile. You come over and you know just one shortcut that will make it all work. But you can’t use it.. You look at the “normal” keyboard and wonder … where is “R”.

Standards are there for a reason

So I’ve abandoned Dvorak. It took me even less time to relearn QWERTY using Ratatype online course and I haven’t looked back since. Dvorak might be a nice solution for some people, that work alone and type awfully lot in english like writers or journalists.

Programmers however are more about cooperation and readability of code than typing speed and should stick to standards. Same principle holds true, when customizing shortcuts, fonts and system commands. It might seem alluring to type “CheckPullOpn” to check-out branch, pull all changes and open in your favourite IDE in one command, but soon you will understand that you have mastered only your machine. And everywhere else you have to keep using those boring and standard command that you haven’t used in quite some time.

Development, Testing

NCrunch – A plugin that makes TDD sexy

Before I started working at my current job I’ve never seen continuous testing tools. For me running unit test, despite being really useful, was a chore that I would do after modifying several files and (usually) writing few additional tests.

It shouldn’t come as a surprise, that several of them will be failing, enabling me to do what developers like the most – fixing errors in their code or, even more fun, fixing errors in somebody else’s code.

Continue reading