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 http://arduino.cc/en/Main/Software, 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…

Visual Studio tip: paste json/xml file as class

1 comment

Monday, March 09, 2015

I’m a long time listener of .NET rocks and today during my drive to work while listening to TDD on .NET and Java with Paul Mooney, Carl mentioned a cool tip I want to share with you.
In the past I have use XSD.exe to create classes from XML files for serialization purposes (and similar tools for json) but no more.
Using Edit –> paste special (which I didn’t even knew existed until today) you can create C# (or VB.NET) classes from
You can copy an XML file to the clipboard and and so the following file:
<?xml version="1.0" encoding="UTF-8" ?>
        <Overview>A man struggling with his faith is haunted by the sins of his past but is suddenly thrust into the role of defending humanity from the gathering forces of darkness.</Overview>
Will become this class(es):
And it would also work for json files as well.
It’s not perfect, I found that I needed to “re-copy” the source after each use and the “paste as xml classes” option will only appear for .NET 4.5 (and above).
No more using external tools to get serialization up and running – a big time saver.

Happy coding…

Catch - multi-paradigm automated test framework for C++

No comments

Wednesday, March 04, 2015

catch-logo-smallWhen unit testing in C++ I tend to use Google Test/Mock, it’s simple to use, multi-platform solution. In the last few days I have been having second thoughts about it due to a new framework called Catch.

What is (the) Catch?

“Catch” stand for C++ Automated Test Cases in Headers. It’s an open source project (GitHubbed). What I like about it is that instead of implementing the old and trusted “[A..Z]Unit” way its creators have decided to rethink the way tests are written - with a few small changes that make a difference (more on that later).
Getting started with Catch is done by downloading catch.hpp and that’s it - you’re all set to go, no need for linking with a dll/lib which can be quite painful when working in C++ (where you sometimes need a different library for each release/debug, platform, single/multi-thread and day of the week).
But this quick & simple way to get you up and running is not the reason I find myself liking Catch – it’s the way the tests are written.

Taking it for a spin

I’ve wanted to try Catch and see how it rolls. For that I’ve decided on implementing the Bowling kata (if you don’t know what it is – go read about it, I’ll wait).
Writing the first test was simple and looked very similar to the tests of old:
    Game game;
    int result = game.Score();

    REQUIRE(result == 0);
Noting big here – or is it? Have you noticed something different about my assert?
Catch has done something that the unit testing world should have done a long time ago – use code to describe what assert is needed instead of dozens of Assert.X methods (in fact I’ve been doing the same for .NET). When running the test I was pleasantly surprised to find the following error message:


See that – it tells me exactly what went wrong: I have a variable called result which does not equal ‘0’, in fact it’s ‘-1’. With test failures like this I can understand what went wrong – even without debugging my test.
I’ve wanted to see if I can get even better error message from Catch and so I moved the call to the method into the REQUIRE block and got the following error:
Even better – now I can really understand what’s going on – Game.Score did is not zero.
I’ve continued my TDD experience and then I found the 2nd feature that makes Catch standout – Sections.
Usually I have a hard time with developers (ab)using Setup methods. I’ve wrote (read: ranted) about this before.
In a nutshell – I do not like setup methods because:
  • After a while the setup method becomes hard to understand and tend to initialize fields that are only needed in some of the tests.
  • It’s hard to fully understand a test that is split between two places (setup and actual test method)
  • As an added bonus you also get shared state (fields again) that can (read: will) cause a lot of damage in the future (test A fail when run after test B)
And so I was happy to find out that Catch has initialization per test case and the actual tests are written in isolated sections:

TEST_CASE("Simple Bowling score -- without score or strike", "[BowlingKata]")
    Game game;

    REQUIRE(game.Score() == 0);

    SECTION("All rolls are gutter balls --> score == 0"){
        RollSeveral(game, 20, 0);

        REQUIRE(game.Score() == 0);

    SECTION("All rolls are 1 --> score == 20"){
        RollSeveral(game, 20, 1);

        REQUIRE(game.Score() == 20);

    SECTION("All rolls are 2 --> score == 40"){
        RollSeveral(game, 20, 2);

        REQUIRE(game.Score() == 40);
not sure if I like the fact that I’m also asserting something about the initial state of the tests – seems a very un-AAA thing to do and it confuses the hack out of the test results (says it has 2 X 3 == 6 assertions) so I’ll remove it (and create a test just for this scenario).
When I first saw similar code in the tutorial I almost decided not to try Catch at all – it seems like pouring code instead of writing atomic, isolated tests. In order to really appreciate what Catch does I’ll make one of the tests fail:
We’re looking at three different tests - which means that if one of the sections fails – it does not effect the other two. This ability enable us to write common code in the beginning of the test case and then write different sections for each test (case?).
Have you noticed another cool feature on the way? The “tests” names are simple texts – we’re getting to a point in which naming a method with underscores and language trickeries will become obsolete.

Catching a case of BDD

Using macros Catch also cater to the BDD crowd, I’ve decided to write the rest of the tests using BDD style:
SCENARIO("If on his first try in the frame he knocks down all the pins, this is called a strike. His turn is over, and his score for the frame is ten plus the simple total of the pins knocked down in his next two rolls.")
    GIVEN("Bowled strike on first turn")
        Game game;

        WHEN("All rest rolls are gutter balls")
            RollSeveral(game, 18, 0);
            THEN("Total score is 10")
                REQUIRE(game.Score() == 10);

        WHEN("Next two rolls are not spare or strike")
            RollSeveral(game, 16, 0);

            THEN("Total score is 10 plus twice the sum of these rolls")
                REQUIRE(game.Score() == 24);
Again We have a common GIVEN step and two isolated When-Then clauses. When one of the behaviors fails we get a nice BDD style error message:


You might have noticed that I like Catch – but it’s not all a garden of roses. I miss having parameterized tests which I need for several of my projects and currently there is no Visual Studio test runner to be seen both of which are a deal breaker for some of the projects I’m involved with.
Since it’s open source there’s a chance that we’ll get an implementation for it in the future.
I know I want to use Catch as much as I can because of features such as sections, test “names”, one assert (require) and error messages.

Happy coding…

FizzBuzz TDD kata– using Reactive Extensions


Wednesday, February 04, 2015

I was thinking about Reactive extensions (and using it) and then it hit me – why not try and use Reactive Extensions (Rx) in order to perform the FizzBuzz kata – it seems like a perfect fit.
And so I set myself to try and use only Rx when performing this TDD kata.

What is this FizzBuzz – a quick introduction

Fizz buzz is a group word game for children to teach them about division.[1] Players take turns to count incrementally, replacing any number divisible by three with the word "fizz", and any number divisible by five with the word "buzz".
[Wikipedia] The idea behind this exercise is to solve the simple problem of writing the numbers from 1 to N according to the following three rules:
  1. Number is divisible by 3 –> write Fizz
  2. Number is divisible by 5 –> write Buzz
  3. Number is divisible by 3 and 5 –> write FizzBuzz
  4. Otherwise write number
It’s a simple problem to solve – in fact I’m sure you’re already solving it in your head. But don’t start just yet, one of the important aspect of TDD is to only concentrate on a specific problem each time and don’t design the whole solution up front.

My First test

I generally start with the simplest wrong input I can think about. I do this as a form of “warm up” to begin my test-code cycle.
In this case any input which is lower then 1 should return an empty string.
public void GivenNumberBelowOne_ReturnEmptyString()
    var result = FizzBuzz.Generate(-1);
    Assert.That(result, Is.Empty);

I wrote the simplest test, although some would claim that I should have used a negative number instead of ‘0’ – which would work for me as well. If you feel the test is inadequate – feel free to add another test as soon as you write the code to make this simple case pass
I run the test – and it failed (no surprises here).
Now to write the minimal amount of code to make the test pass:
public static string Generate(int max)
    return string.Empty;    
As simple as that.
To some my implementation would look like cheating (especially if you do not have any previous TDD experience). But when you think about it you realize that the code above elegantly fulfills all requirements (in this point and time).

Let’s make it more interesting

Now that we got that out of the way it’s time to start adding some value to our code.
The next requirement to  tackle is “unless the number is divided by 3 or 5 we should just write it”.
So the simplest test here should be using 1:
public void Given1_Return1()
    var result = FizzBuzz.Generate(1);

    Assert.That(result, Is.EqualTo("1,"));

To make the test pass I can write the following – trivial code:
public static string Generate(int max)
    if (max < 1)
        return string.Empty;

    return "1,";

Now let’s see what happen if we pass ‘2’ (code + test):
public void Given2_Return12()
    var result = FizzBuzz.Generate(2);

    Assert.That(result, Is.EqualTo("1,2,"));

// Code
public static string Generate(int max)
    if (max < 1)
        return string.Empty;

    if (max == 1)
        return "1,";

    return "1,2,";

Now we get to the 3rd stage of the TDD cycle – refactoring and since I wanted to use Rx I refactored the code accordingly:
public static string Generate(int max)
    var result = string.Empty;

    if (max > 0)
        Observable.Range(1, max)
            .Subscribe(i => result += i + ",");

    return result;

the code above is basically a simple foreach using Rx:
  1. Create an observable that would return a range from 1 to max

  2. Subscribe (iterate) the observable and add each item to the result
Refactoring is not only for my “production code” and since both tests are use similar code I can refactor my tests using NUnit’s TestCase:

public void GivenNumberBelowOne_ReturnEmptyString()
    var result = FizzBuzz.Generate(0);

    Assert.That(result, Is.Empty);

[TestCase(1, Result = "1,")]
[TestCase(2, Result = "1,2,")]
public string GivenNumberUpTo2_ReturnNumbers(int input)
    return FizzBuzz.Generate(input);

Although I could also test the 1st requirement (less then 1) using the same code I prefer to separate them since they are logically belong to different aspects of my solution. In other words I prefer to “pay” the (low) maintainability price in order to separate the requirements (readability).

Onward to Fizz

Now we’re finally getting somewhere – let’s write a failing test for “3”:
public void GivenNumberDividedByThree_ReturnFizzInstead()
    var result = FizzBuzz.Generate(3);

    Assert.AreEqual("1,2,Fizz,", result);
Since we’re already familiar with TDD I’ll allow myself to jump a few stages (in this post, not in the actual Kata) and show you the result after refactoring – the code starts to look better – Rx style
public static string Generate(int max)
    var result = string.Empty;

    if (max > 0)
        IObservable observable = Observable.Range(1, max);

            .Where(i => i % 3 != 0)
            .Subscribe(i => result += i + ",");

            .Where(i => i % 3 == 0)
            .Subscribe(i => result += "Fizz,");

    return result;

The end result

In a similar matter I’ve TDD’ed my way to Buzz & FizzBuzz and got the following code:
public static string Generate(int max)
    var result = string.Empty;
    if (max <= 0)
        return result;

    var observable = Observable.Range(1, max);

    var dividedByThree = observable
        .Where(i => i % 3 == 0)
        .Select(_ => "Fizz");

    var dividedByFive = observable
        .Where(i => i % 5 == 0)
        .Select(_ => "Buzz");

    var simpleNumbers = observable
       .Where(i => i % 3 != 0 && i % 5 != 0)
       .Select(i => i.ToString());

    var commaDelimiter = observable.Select(_ => ",");

    IObservable specialCases = (dividedByThree).Merge(dividedByFive);
        .Subscribe(s => result += s);

    return result;
I found a cool thing – as soon as I handled numbers that divide by 3 and 5 separately I “automatically” got the case of FizzBuzz.
That’s it – simple and elegant and with Reactive extensions. Unfortunatly I failed creating an Rx only solution (I still check for i < 0)
And the all exercise took a few minutes (more time than it took me to write this blog post).
Happy coding…

Agile practitioners 2015

No comments

Thursday, January 29, 2015

I’ve just came back from the Agile practitioners conference. I enjoyed being part of the organizing team – it was fun giving a hand and helping to make this conference happen.
After attending an excellent “Lean problem solving” workshop by Claudio Perrone yesterday I was ready for a day of breakout sessions.
We've kick started the day with Angel Medinilla’s  “unicorns, krakens, self organizing teams and other mythological beasts” – it was about why self organizing teams do not happen automatically but can be built.
Also: Unicorns

Being the “Beginner” track lead I got to hear all of the lectures in that track – they were interesting and were not strictly beginner material.
B8bJrUoCIAA2RYCWe’ve started with “The missing lecture” by Uri Nativ (@unativ). It was an excellent talk about the things no one tells you when you start doing agile. Uri has explained how to successfully adopt agile by understanding how the development team perceive the change. He had excellent “do”" and don’t” and used examples from his own experience – good and bad.
Next was Oren Ellenbogen (@orenellenbogen) – “engineering your culture: how to keep your engineers happy” -  a talk on what great companies do in order to attract and retain great developers.
After lunch we had three “lightning talks” (15 min):
  • Gull Ben-Davind - “Why are QA members good scrum masters”, it was refreshing to see a presentation without any slides where Gull walked us through the way MyHeritage used QA/Testers as SCRUM mastersB8bvH7kCcAAZ7i1.
  • Ran Deri & Noam ZweigManaging technical debt in Cyberark. They explained how they managed to measure technical debt and then decide on what debt to pay on each team – while improvement as well. It was amazing seeing how an abstract idea (Technical debt) was measured using metrics and questioners and how they keep track of their debt on a daily basis.
  • The last lightning talk was by Barak Benjo who talked about “The 10 commandments of an agile tester in a legacy world”. Barak explained about how testers can be agile even when testing Legacy code and the kinds of tests that are available and how to choose what to do.
After the lightning talks we had an “Lean Lens” exercise/game with Andrea Darabos.IMG-20150128-WA0009
By using a fictional story we got to find all sort of “waste” in common scenarios during the software development process. You can read more about Lean Lens here – and download it and use it (creative commons) in your company.B8cD86FCIAEeoOo
Afterwards I got to give my talk on TDD – I hope that the code I showed (https://github.com/dhelper/DesignWIthTests) was not too much for the late afternoon hour.

And finally we got an excellent closing keynote by Claudio – where he briefly explained A3 method for problem solving and his brand new “popcorn board”.

It was a great conference and I got to talk to some interesting people and hear excellent talks – all in all a very good day.


Happy Coding…

Azure IoT Hackathon


Friday, January 16, 2015

Yesterday (technically today) I participated in an Microsoft Azure IoT Hackton at IronSource offices.

When I heard that several CodeValue consultants were asked to come and I knew I asked if I could tag along.


Microsoft organized a great event – good venue, food (Pizza!) and very talented developers.

10915136_10152776995923768_4074683655461051494_nEach team had Raspberry PI (Model B+), Arduino (Yun) and/or Tessel and needed to create an innovative solution using an Azure backend – with not a lot of time to spare.

We CodeValuees got to meet talented and enthusiastic developers and to help them to utilize these new cool “IoT” devices. And let me tell you - my three years worth of high school electronics classes really helped.

We continued hacking until midnight then each team got to show what they’ve created:

  • an application that provides directions to the closest free toilet a.k.a “Smart bathrooms” (2Seek) B7bTIz2CQAEX3vZ
  • Dog tracker
  • parking spot finders (1st place)
  • and many more that I didn’t had a chance to see.
  • B7dBKibCEAAN23e (1)

In-between working with other teams we even managed to hack our own solution – meet the new CodeValue parking gate controller (Park-Value?) with permission management applications for the web, desktop, IOS and android:


It was an awesome event – we got to write code in JS, Python, something that looks like C (Arduino) and even C# (actually only Ariel). We’ve played with several controllers and connect resistors to other components (did I mentioned high school electronics :-) ).


I definitely plan to continue hacking using Raspberry PI/Arduino/Tessel/<other> perhaps even blog about it.


Until then – Happy coding…

The four species of Agile

1 comment

Tuesday, December 23, 2014

SukkotI’ve been a professional software developer since 2002 and worked for several software companies over the years - some practiced SCRUM, some used Kanban, some had a tailored made methodology and some didn’t have any methodology in place.

When starting with Agile a few years ago I found out that

“All waterfall companies are alike; each agile company is agile in its own way.”

Over the years I learnt to classify each company’s methodology using two factors:

  • Ceremonies – whether the company follows the methodology practices – iteration planning, retrospective, and/or daily standups.
  • Intent – does the company understand the agile values, strive for continuous improvement, quick feedback and embrace change (among other things).

And so I bring before you the four types of agile companies that I had the pleasure (in most cases) working for in the past:

Neither ceremonies nor intent (Aravah)

I got to work for several companies that had no visible software development process - or had a process which made no sense.

It doesn’t necessarily means that those companies didn’t had a project management “methodology” – in one case we had a whole division “planning” and “tracking” the various projects. Unfortunately the beautiful chats and predictions never affected us developers, and other than reporting (read: lying about) project hours it didn’t bother us much.

It was chaos incarnated – no one knew what was going on. Some of us were overworked while others would drink coffee all day. After finishing each task I had to ask my manager what to do next and from time to time we’ve shipped a product.

And so we’ve worked hard on fixing bugs and implementing new features without real understanding of the overall picture.

Ceremonies without intent (Hadass)

After a few years I got to work for Uber company Ltd. (if you know me you might know which company I‘m referring to). We’ve created a new shiny project that just had to succeed (at least until it got cancelled), and as such we needed to use the latest and greatest of everything - including a new methodology called SCRUM.

Consultants have been hired, courses have been taught, developers and managers were trained and a lot of money has been spent to make sure that the project would be a great success.

I was hired a few months after that and when I got there all that was left was the bills and a daily meeting that took between 30min to 1 hour – which for no particular reason we had to do while standing.

My educated guess is that the company refused to change its ways and so all that was left were the ceremonies: the daily meeting, planning that was done first by the team, then by managers and finally not at all and retrospective that happened three times during the year I worked there.

Intent without ceremonies (Lulav)

In one of the last companies I worked for before becoming a consultant was a team that knew about agile – the manager had experienced SCRUM before and wanted to us it to build software. He had a clear understanding of what he needed and wanted and how to achieve it. He had SCRUM custom made to fit his vision and while some of the benefits were lost on the way the underline values were always there.

Since the team was willing we were able to add daily meetings, retrospective and backlog and while the company never really wanted our iterations we were able to build a methodology very similar to ScrumBan that made sense for us.

We had TDD, task boards (plural) and clear priorities and we managed to create value for our customers – fast while reducing technical debt.

It was not always simple or easy but we all had the same goal and so were able to find tools and methodologies that worked for us.

Ceremonies and intent (Etrog)

This is where I became an agile addict – this utopian company decided to go with SCRUM and managed to stick to that decision.

When we noticed that SCRUM didn’t make sense for customer support – we’ve used Kanban for opened tickets.

After doing SCRUM by the book for more than a year we knew where we need to adjust our methodology and what we needed to keep on doing (retrospective) we’ve experimented with different iteration lengths, we had XP practices (pair programming, CI, TDD) and continuous deployment.

We managed to be productive and effective, we had management who was willing to provide us time to learn and much needed feedback.



There you have it – four types of companies based on my (limited) experience – some were successful and some failed miserably.

If there is one thing I learnt is that you have to have intent and understanding in order to succeed with agile – I got to use agile in waterfall companies and I also so bad agile (and “no agile) practiced even when someone up the corporate chain decided that the company is an agile company – the decision rarely left the board meeting if the developers (read: those who write the code) were not on educated or in some cases even part of the process.

Related Posts Plugin for WordPress, Blogger...