Following on from my first look at the Arduino, I freed up a few hours in my day to continue with the tutorial projects.

Project 6 builds on the LED chase effect that was created by project 5 and adds a potentiometer that adjusts the speed of the chase.  Shame I dismantled project 5 when I finished up on day 1.  It took me a few minutes to reconfigure all the LEDs and connect them to the Arduino.  Once this was done attaching the potentiometer and the update to the sketch was quick and easy.  I skipped the two exercises at the end of project 6 as they were effectively programming exercises.

Project 7 involves creating a single pulsating LED.  This is achieved by doing an analog write to the output pin (the output pin is a digital pin).  An interesting explanation of how we get a digital pin to behave like an analog pin follows with a description of PWM (Pulse Width Modulation).

Project 8 creates a mood light that uses a clear red, clear green and clear blue LED  and adjusts the brightness of each to simulate a range of colours.  The sketch was interesting as it managed the transitions so that transitions from one colour to another were not too abrupt.

Project 9 creates a fire effect using two yellow and a red LED.  The wiring and sketch are more basic than the last couple of projects so there really wasn’t a lot to this project.

Project 10 uses the same circuit as project 8 but uses the serial monitor to manually input commands to the Arduino.  Simple commands allow manual control of each of the LEDs individually.

Project 11 puts away all the LEDs and starts to play with some of the other components, namely the Piezo Sounder and the terminal block.  The circuit is trivial but we start to see new functions within the sketch that control the Piezo Sounder.

Project 12 uses the Serial Temperature Sensor to output temperature readings to the Serial Monitor.  There appeared to be an issue (which I caould not find the source of) that caused my PC to freeze when I connected this circuit.  It seemed to be a problem with the sensor itself.  This was the first problem I had with the kit so far.

Project 13 uses a light sensor to adjust the rate at which a LED flashes.  Normal service resumed and after putting together the circuit and downloading the sketch the LED reacted to the lighting as expected.  I’m a little relieved that there is nothing wrong with the board!

I’m not going to finish projects 14, 15 and 16 as the next thing I want to try is to control the Arduino from a Java program.  But that’s for another day.

My wife recently bought me an Arduino Starter Kit from Earthshine Electronics and I have been keen to start playing around with it.  Despite doing some electronics in university I have absolutely no idea where to start but there was a free book (downloadable PDF) that accompanied the kit.  I downloaded the book and followed the instructions to install the Arduino IDE and verify that the Arduino board was functioning.

Figure 1: The Arduino Board

Project 1 in the book involved connecting an LED and resistor to the board (using a breadboard) and writing a short sketch to make the LED blink every second.  While it was pretty straight forward, I was quite pleased when it all went to plan (I think trouble shooting would be beyond me at this stage) and the little red LED started to flash when I uploaded the sketch to the Arduino.  The book then reviews the C code (which I skimmed over) before providing an overview of the hardware for the project.  Its on the hardware side that I will find my challenge so I needed to read this section carefully.

Project 2 used the same hardware configuration but changes the sketch to signal S.O.S in Morse Code via the LED.  Given this only involved a rather simple sketch and the same hardware configuration I did not find this interesting.  On to the next project.

Project 3 simulates the light sequence on a set of UK traffic lights; that is, red, red-amber, amber and green.  Given the two previous projects this was pretty straight forward.  Different resisters were used this time so that the LED’s were not as bright as in the previous projects.  Given the additional components, I can see now why a strong table lamp is a necessity for this type of activity. Anyway, I’ll press on without one.

Project 4 adds a set of pedestrian lights (red and green) and a push button to the previous project.  Steady state shows the traffic green and the pedestrians red.  On pushing the button, the traffic is shown amber then red.  The pedestrians are then shown green.  After a little time passes the green pedestrian light flashes before changing to red.  The traffic lights then transition to amber and then green thus completing the sequence and returning to the steady state.  The circuit was straight forward although given the number of components I had to recheck the connections a couple of times.  I also made the mistake of placing and LED the wrong way around thus it did not illuminate.  This was easy to detect and diagnose.  The code itself was fairly straight forward.

Project 5 creates a LED chase effect.  Both the hardware and sketch are straight forward but given it uses 10 LEDs and 10 resistors it is fairly time consuming.  I worked through it anyway for completeness.

So far it has been fun learning about the Arduino and I’m looking forward to working my way through the other projects in the accompanying book.  It’s getting late so time to pack up for today.  Hopefully I’ll get some time over the Christmas holidays to tackle the rest of the projects.

I remember when I started commercial coding in early 1999.  The developers that I worked with would constantly remind me of the value of commenting code.  The main reason they would give was that it reduces the cost of maintenance by making it easier to return to the code at a later date.

Now, I wanted to write code and not comments so this did not come naturally but on my best days I would diligently comment every class/method declaration and adorn non-trivial methods with a liberal spattering of the same.  After a while I noticed the amount of noise produced by comments that added no value or that were no longer relevant was a considerable distraction.  In fact, this distraction was increasing the maintenance cost rather than reducing it as I had previously been told.

Since then much has changed and the publication of books such as The Pragmatic Programmer, Clean Code and The Clean Coder has changed the perceived wisdom surrounding the commenting of code.  The authors of these books suggested that better code maintainability will come from writing better code (who would have thought!).  By better code they meant code that is easier to understand but how do we write code that is easier to understand.  A good start is to:

• Use descriptive class and method names.
• Do Not Repeat Yourself
• Write SOLID code.
• …

Given the way in which modern logging frameworks work, using descriptive class and method names also increases the value of your application logs.

Bob Martin said that “The proper use of comments is to compensate for our failure to express yourself in code. Note that I used the word failure. I meant it. Comments are always failures.”.  I’m a little more open to comments and still see the value in class and public method comments (please, no bean accessor and mutator commenting!) but regardless of each individuals personal preferences for comments its is good that people are thinking about the subject and doing what makes most sense for them rather than blindly commenting everything.

Over the past couple of days, I have spent quite a bit of time reading around code branching strategies and the consequences of choosing one strategy over another. I found that ‘Advanced SCM Branching Strategies‘ by Stephen Vance gives a good overview of the practice and some of the considerations to be made when choosing a branching strategy.

Or course more recently, and perhaps as a consequence of SCM tools becoming more adept at textual merging, feature branching has risen to prominence. As he is inclined to do, Martin Fowler articulately expresses his views on why feature branching should be avoided when possible and the inherent conflict between feature branching and continuous integration. I must say that I find it hard to disagree with his reasoning (see also a short Q & A with Jez Humble).

So what alternative does he propose? Martin suggests applying Feature Toggle and Branch by Abstraction. I’ll leave it to you to read the background, but the removal of branching and merging from a teams development activity is certainly a big carrot.

Manual code reviewing can be a painful exercise. Typically it involves a developer identifying the files they have modified as part of a feature development or bug fix and then a number of people reviewing the changes in a round table review. Following this there is normally a number of iterations until all the points raised in the review have been addressed.

So, where are the challenges in this approach?

Identifying the files modified as part of a feature development can sometimes be a challenge and because of the dependency on the developer (a human) it is often prone to error (especially if the review occurs after a period of time).

Getting the right people in a room at the same time is the second challenge and often it is this that is the main hurdle to having an effective process for code reviewing. This limits us to reviewers in a single location unless we are using review templates, email, wiki etc. which are all less than ideal.

Finally, the intrusive nature of iterating over points raised in the review results in a process that tends to be treated with mild neglect at best, and at worst complete disdain.

These are the type of issues that Atlassian are looking to address with Crucible, a web based application for creating and performing code reviews.

To learn a little more, I have downloaded an evaluation copy and installed it. Pretty straight forward stuff. The download includes a standalone package that executes a web application within an embedded server.

Next, I created a repository, pointing at our SVN repository using the built in repository client. Crucible spends a bit of time creating change sets and indexing the repository and after that I was able to view the all activity on the repository.

From each repository commit, I can create a review and assign reviewers. This helps out with the developer having to identify the change set. The reviewers and the developer can then raise points and iterate (via the web application) over the points raised. Nobody needs to be in the same room at the same time…excellent.

I’m going to spend a bit more time playing around with Crucible to see if it could be truly useful. I want to play around with resource watches and I am looking for a feature that allows me to create developer profiles that trigger reviews based on the experience level of the developer, sensitivity of the source code region or branch etc.

It’s been interesting so far. If you have experience with a similar tool, I’d be interested in hearing about it.

(No Ratings Yet)

 Loading ...