Archive for May 2010

I have not been posting as much as I would like. I’ll be returning to 3 posts a week (excluding holidays) to try to get back into the swing of things.

This last weekend my fiancé and I attended Maker Faire up in northern California along with some friends. It was an interesting time, and one that I would recommend anyone near a Maker Faire attend.

A picture of the Maker Shed from hackaday.com. All of the neat toys you might buy were sold here.

I think the most interesting of the many projects that we saw at the faire was a 4 player version of simon says. They used 16 dome lights, 4 in front of each player build into a square table. In the middle there were several clear tubes that had LEDs at the bottom of them. The tubes would light up a series of lights (and accompanying sound) that the players were supposed to mimic, just like the original electronic game. More colors would be added to the end of the sequence each round and the last player standing would win. Then the game would reset.

For me it was interesting because it was fun to play (or watch play, as Ash played it and not me), and because I’m pretty sure I could build it myself. The whole thing was powered by an arduino and the parts seemed pretty basic for a game like that.

That is what the Maker Faire is about in my opinion. Seeing cool stuff and thinking of how you could make it yourself or improve upon other people’s designs. Granted I wasn’t going to start building large musical tesla coils, but a Simon Says game with lights and buttons is an interesting project to handle.

One of my favorite parts of the whole event was probably the Makers Shed. It was a physical version of the online store. If I were rich, I would have filled my car up with the interesting kits, books, and parts that lay in that hall. Instead, I came home with a few kits and books, including a Minty Boost kit from Adafruit. After having bought a 10-pack of altoids gum, I worked through the kit and was rewarded with a portable usb charger.

Soldered this together a few nights ago from a kit I acquired from Maker Faire. Handy little device that keeps my fiancé's cell phone charged on the go.

So it was another step on my path to making things. I’ll probably make another (I have a lot of gum tins now) so that we can both have one.

This is a really niche topic of discussion. Those who have both practiced software development and played/studied Go may appreciate the relation. If you’ve never played go and are not a software developer… well I can’t really help you there. However, today I found the similarities astounding.

There are a lot of terms from Go that are used to describe the game or situations in the game. Things like “lightness” and “flexibility” where your stones are spread out to cover a larger area but with gaps in the middle. The idea being that since they are spread out you’re not too attached to any one stone and can adjust your battle plan by sacrificing a single weak stone rather than being forced to protect a large group of more valuable, and yet still weak, stones. If you cluster your stones together too much, especially at the beginning, you’re said to be over concentrated and are not being very efficient with your stones. Your stones can become “heavy” when they’re too large to lose, but very difficult to keep from being captured. You are forced to make moves that benefit your opponent more than yourself just to make sure you don’t lose those heavy stones.

Japanese style floor goban. Large board tables like this are often made of Kaya, a rare japanese tree known for it's properties as Go board. They are often very expensive.

What does this have to do with software development? Quite a bit actually, especially if you follow the Agile Development Methodology. When creating a software design, you will be more rewarded if you keep your design light and flexible, able to adapt to new change as it happens. The ability to sacrifice (refactor) a weak section will help your greater strategy of winning (producing a complete product). When pieces of your development get heavy, they are difficult to refactor, possibly because they’re not designed to be tested. When modifying that section of your code, it tends to break other sections. Since you built a bad foundation early on and refused to sacrifice it (refactor), you end up being stuck trying to save a dying design and spend a lot of time and effort for little gain.

Once you’ve sacrificed enough bad designs and followed your test driven development to the proper design, your code becomes flexible and more maneuverable. In Go terms, sections of it become “Alive“. Building off of those sections, as long as you keep to your design principles, makes fixing bugs and developing new structures a lot easier.

There are several ways to play go. There is speed Go, where you give yourself only a few seconds to play your piece. There is Go played with a normal time limit, usually an hour or so for each player with some overtime after that. And there’s games which are not timed at all. Speed Go often results in a lot of mistakes, however you can finish a game a lot faster. The result won’t be the best however, and you wouldn’t want to use it to represent your skill in the game. Regular Go is what is good enough for most people. You spend a reasonable amount of time thinking about most moves, but in general you rely more upon any experience you have than reading out the board. In an game that isn’t timed you can really sit and concentrate on your move. You might think about dozens of possibilities of what you could play and the replies your opponent can make and future moves you would make to those replies, etc. It can take a long time, but the resulting moves can be brilliant at times, and often will result in the best game.

I find that too many people play Speed Go in their development efforts. They’re told “Fix this bug” or “Make something that does this” and they open up their IDE or programmer’s editor or echo and cat and put some code in files trying to solve the problem as fast as possible. Problems are dealt with as they come up. There isn’t really a design per say, just how the code all comes together. The problem with this is that the code created by Speed Code is often very problem specific and difficult to fix and modify. There’s no flexibility, and often pieces of the code are heavy.

The last form, coding without a time limit, can yield some surprising results. I’m not saying that you should give everyone unlimited time to code even the most simple of things, nothing would get done. Nor should you try to get the “perfect” design before coding anything, as what you’ll get in the end won’t be worth the time spent. Rather I think that, especially at the start of the project, some actual thought should be put into what you’re coding. This thought shouldn’t be just in your head however, it should be in the form of Tests. If you write up tests that utilize the code you haven’t even written yet, you can get a good design before you code. If it seems hard to test, try something else. You should be writing and throwing away tests as you work on the design of the piece of code you’re tackling. This is equivalent of reading ahead moves in a Go game, seeing where the pieces might lead.

Of course there’s only so far reading ahead will get you. Soon enough you’ll have to implement what you’ve designed and look at the next piece. However, don’t assume just because you have tests and an implementation and that they all work that you can’t change them any more. Everything you write should be flexible to be rewritten or refactored and thrown away or modified to handle new business rules or requirements. Having the tests in place will make modifying the code easier as you’ll see where things will break and can modify them accordingly.

I noticed this correlation in my own code just today. I was finishing up an implementation before moving on to the more difficult part of my project when I realized that from the structure I have built up and the loose framework that I’ve designed, the “difficult” part of the project was able to be solved in the framework that currently existed. The same framework that I’ve built up and torn down and built up several times over the past few months.

A while ago I entered the Make: Robot Build contest. The contest was to build a robot using CDs/DVDs as the primary building material. The robot needed to be able to navigate around obstacles. The design also had to be flexible enough to allow additional additional sensor-systems to be added on top of the obstacle avoidance system. The deadline was May 7th (Later moved to May 10th). I submitted my entry last night.

This is the final product that I submitted in the end. It's a very basic bot using only 'bump' sensors.

Gimpy the CoasterBot is made from 2 CDs connected via hex spacers with 2 modified servos driving 2 wheels. The front is held up by an old dice case that’s used sort of like a ski. There are two front ‘bump’ sensors that detect when the robot has run into something so that it can back up and change direction to get around the obstacle. The sensors are two switches that have strips of CDs connected to form larger antenna-like arms.

This was my rough attempt at creating a schematic for the electronics systems of the CoasterBot

This was a very interesting project for me. I had been interested in robotics since I played with a lego mindstorm kit in college as part of an advanced Java programming class. Having custom hardware to program for seemed like a very natural extension to software development. However, I never took any classes in electrical engineering so my electronics abilities were minimal at best. Learning how to wire up the physical components and construct a robot from parts and not a kit was the real challenge for me.

Part of my path to success was through reading the Make: Electronics book. It also helped that I stuck a large sticky note of Ohm’s law on the side of my desktop computer at work (at least I think it helped). I learned a lot of new things in an area that I did not have a very large knowledge base to begin with. I find this quite a different experience than learning a new programming language, framework, or other aspect of software development that I’m already fairly familiar with. In this robot building exercise, I was still able to relate with my field of software development since I had to program the thing, but I was also able to dive into a new realm of electronics and physical computing that I hadn’t experienced before. I think that the most rewarding aspect of any project like this is knowing that your expanse of knowledge is growing to cover a wider field than you held previously.

For entering the contest, assuming that the judges mark my entry as valid, I shall receive a Maker’s Notebook. I own one of these already and used it for part of this project, but it’s a nice little notebook and I’ll enjoy having a second one. I found that having a prize just for entering was a fairly important aspect to this contest. While I don’t really need another Maker’s Notebook (mine only has 6 of 150 pages filled), knowing that I would get one for completing the project gave me a motivation and drive to finish under a deadline and complete my work. Also the contest provided me with a direction, a goal, and a timeline to complete. Hopefully I’ll see some more contests by Make or maybe some other sites that will give me ideas or spur me on to create other relatively useless but ultimately interesting things.

So that’s my robot. It’s not very smart and if I had a lot more money to pour into it I could add a bunch of other sensors (and maybe a front wheel) and make it more aware of its surroundings so that it doesn’t have to run into things. Even still I’m pretty proud of my accomplishment, even if he does fall backwards when hitting the lip of a carpet.

Subscribe

Aspirations of a Software Developer syndicates its weblog posts
and Comments using a technology called
RSS (Real Simple Syndication). You can use a service like Bloglines to get
notified when there are new posts to this weblog.