AssertHelper V1 released

No comments

Friday, April 24, 2015

Exactly one year and four months passed since my first try at fixing the state of asserts in NUnit. You can read all about it in my post – One assert to rule them all.
My intent was to create one assert that would automatically choose the right way to check test result (I didn’t invet the idea but the old project has been discontinued).
Since the initial release I’ve used AssertHelper on several occasions (projects), taking requests and adding support along the way. Finally AssertHelper V1 is ready to be tested in the real world.
I’ve added MSTest support and a last minute entry – print the “offending” lambda that caused the assert to fail.
So why don’t you give it a try - AssertHelper is available via NuGet (Install-Package AssertHelper).

And please let me know what you think.

I’m a software developer - not a lawyer

No comments

Wednesday, April 15, 2015

61101315A long time ago not that far away I’ve been hired by Omni-Corp to work on the new and shiny product. We had talent, budget and cool technology on our side, and that project was going to crash and burn (and ultimately cancelled) in less than a year.
Nobody’s perfect - we had our share of problems, some technical and some not. One of which was the way that requirements were managed:
The product guy (or gal) would create a word document describing a new feature. A few meetings would happen and when development agree on the specifics of that feature coding would begin. Lastly testers would use the word document to create test plans and validate that the requirements were met.
It was a good process, easy to explain (and follow) with clear stages (Requirements –> Development –> Testing), and clear outcome of each stage.
Like all best laid plans – this one did not survive its meet-up with the real world.
Since the product persons were “business people” and not “software developers” they did not fully understand the logical way in which developers understood the requirements and since developers were being “developers” we tended to come up with our own solutions whenever we met a “logic hole” in the requirements document.

And mistrust and chaos would follow…

We (devs) would claim that since it was not in the document we had to implement was we saw fit – and so a young bright manager came with the solution: quickly update the document five minutes before a meeting and then point it out that “it was definitely in the document!”.
Now we had a new problem – it was impossible to write software with a constantly changing requirements and so the “requirement freeze” came to be.

Requirement freeze!?

As you might have guessed at a specific point in time the requirement document would be locked and cannot be updated again, and just like code freeze – it didn’t last. Once a product guy discovered that he can make a copy of the frozen document, update it and link to it.
At his point it was just ridicules as well and counterproductive – mistrust grow as both teams felt that the other team is trying to cheat them. The development team felt that product was trying to shove half baked, constantly changing features while the product team felt as if the developers were always on the lookout for new excuses to avoid work.
And so every single stage in the process felt as negotiation between opposite sides – I got to a point where I refused to sign on requirements before reading them several times and then asking my boss to read them to make sure that they were complete and did not contain any hidden conditions.
I felt like a lawyer! There’s nothing wrong in being a lawyer (some of my best friends are lawyers) as long as it’s in your job description.

And it was all our fault

We (both teams) forgot that it was our job to create software according to the demands of our customers.
Looking back at that time I realized something – requirements change, even in a perfect project customers tend to change their minds, bugs are fixed and new data can cause us to look at our product differently. I got to work for many companies before and since and not once did I meet the mythical 100% true never changing requirements project – even with the best of the best.
We were fighting reality – where projects tend to change over time. If only we’ve used the same passion and energy to make sure that we could change our code as easily.
The truth is that it should be easy to change your code. Refactoring, unit testing, code reviews and other software development best practices can help you get there and as good, experienced software developers it was our job to use the right practices in order to provide our customers with new features and bug fixes as quickly as possible – instead of complaining about the fact that requirements always changed…
It can be very hard to make changes in large complicated code bases. When we make changes it's important to know that we are making them one at a time. Too often we think we are changing only one thing but instead we end up changing other things unintentionally: we end up introducing bugs.
Michael Feathers – working effectively with legacy code
It’s as simple as that – simple code equals easy to change. So make sure you’re doing your job before trying to change the world.

Happy (& clean) coding…

Electronics 101 - Getting started with Arduino

No comments

Wednesday, April 01, 2015

ArduinoYunFront_2_450pxThese days everybody talks about IoT. Connecting your toaster to the internet has become a nationwide priority. Finally the barrier to entry to the hobbyist/home electronics have fallen and anyone can hack an hardware solution using cheap and simple components.
And putting together a simple circuit controlled by Arduino/Raspberry Pi/whatever is easy, it’s just a matter of
I have always enjoyed writing software that effect the real world and this new wave seemed like a good opportunity to dust off my 12th grade electronics classes from old. Having acquired an Arduino Yun I’m ready to create my very own “hello world” example. In this case make a LED (Light Emitting Diode) blink.


For the purpose of this simple demo you would need to following:
  • Arduino software – download from, install and you’re ready to go.
  • Arduino - I’m using Arduino Yun but for the purpose of this demo any Arduino will do.
  • Breadboard – this nifty “board” would hold the components in place. This enable us to connect components without soldering stuff together. It has a bunch of holes in it with “wires” connecting the holes to one another.
    The idea is that all the components at the same row are connected to one another. Just make sure that you do not “cross the streams” – each component has at least two leads and they (usually) need to be connected to different rows.
  • LED (pick a color, any color)
    The star of this demo – lights up when current passes through it. you might have noticed that our friend here has two leads one longer than the other. The longer one is the positive one and should be connected to where the current comes from the other shorter lead should connect to the ground.
  • Resistor
    Since we don’t want to burn the LED we need to add a resistor to the mix.
    It has a bunch of lines on it with pretty colors. Those tell us what is the resistor’s resistance, but don’t worry about it just yet. In this case I’ve used a 1K resistor.
  • 2 wires – to connect stuff together.

Writing the application

Writing code for Arduino is easy. A program is called “sketch” and it uses a C like syntax. We have comments, variables and functions. The bare minimum are two methods: setup and loop.
  • void setup() runs once and this is where you add your initialization logic
  • void loop() runs continuously – this is where the program logic should be written.
You can add additional methods if the need arise but this is as simple as it gets.
Let’s write our program. We’ll use pin 13 for output. The reason for choosing pin 13 is that on most Arduino boards we have a LED on board.
The code for this first simple program looks something like this:

const int ledPin = 13; 

void setup() { 
    pinMode(ledPin, OUTPUT); 

void loop() { 
    digitalWrite(ledPin, HIGH); 
    digitalWrite(ledPin, LOW); 

Seems simple enough, but just in case let’s go over the code:
  • The first line declare a constant value which we’re going to use as the output pin
  • In the setup method we initialize that pin as an output pin
  • The loop would start with setting pin 13 to HIGH which supplied 5 volts to that pin –> LED light goes on
  • Delay for a second (1000ms) so that we’ll be able to see the pin light
  • Set pin 13 to 0 volts (LOW) –> LED is off
  • Another Delay
And that’s it, the loop would run continuously turning the LED on and off.
Use Ctrl+R to compile and verify the sketch. You can also upload and run without connecting any components and see the little L13 LED on the board light up – but what’s the fun in that?

Connecting the board

Looking at the Arduino you’ll see it has a few numbers and weird words on its side.
The numbers are the digital inputs/outputs. near number 13 we have GND (ground) which will also need.
Connecting to the outputs is as simple as putting a wire through a hole.
  • Since we’re used 13 as the output we’ll connect one wire to 13. The other wire will be connected to GND.
  • Connect the first wire to the resistor
  • Connect the resistor to the LEDs longer lead
  • Connect the short lead to the wire that goes back to GND (ground).

In the real world it would look something like this:
For the uninitiated it might look a bit “wireless” – the components do not appear to be connected. Just remember that the bread board has wires running underneath which essentially connect the whole line.
Here is the same circuit with the “hidden connections” marked.


Connect your Arduino to your computer and Upload the sketch.
Note: Don’t forget to choose the correct port and board before trying to upload.
And after a short while you should see the LED lighting up!


Troubleshooting: If your LED does not light up (but the on-board LED does)check that all the components are connected in the right order, make sure that you’ve connected the positive side of the LED (long) to pin 13 and the negative side to GND.
If you feel comfortable enough with this simple example – why not try and implement a binary counter:

What’s next

That was a simple electric circuit using Arduino Yun. I hope that it looked simple enough and that you’ll be able to use this post to build your own. I hate to see software developers shy from electronics just because it’s out of their comfort zone (being “hardware”).
As for me – I’m waiting for a big shipment of electronic goodies – and have plans for future hobby projects that I can use them in. I might even write a few more posts on the subject.

But until then – happy coding…
Related Posts Plugin for WordPress, Blogger...