Discipline in Coding

Posted June 17, 2010 by Jearil
Categories: Design, Programming

Tags: , , , , ,

The title is perhaps slightly misleading. I think overall that coding should be fun. Figuring out how to do something and getting it to work is a mental exercise that can be pretty enjoyable, especially when you finally have something finished that you can get other people to play with. However, when launching into learning a new language, platform, framework, or basically anything outside of your regular development comfort zone, you can lose your focus on doing things the right way. This is where some discipline comes in.

Mr. T Pointing at you. Be Afraid.

I don't know why, but the first image that came to my mind when I thought 'discipline' was Mr. T. So here he is.

By now, we should all be doing certain things whenever we code. Writing unit tests first is important, as is writing good tests that actually prove the working of things. Using version control is a given; even the stuff you mess around with should use version control since it’s hardly any work at all to add it. Building off of interfaces so that you can easily exchange implementations without messing with the code that uses those interfaces (this also goes well with testing). Decoupling your view from your controller from your business logic. These are all great things, but sometimes in the excitement of learning something new we forget about them.

Recently I began learning about Android programming. I started with their tutorials, and used them and the API reference doc to try to create my own simple program. The idea was to create a simple game, something that shouldn’t take too long but that other people could play and have some form of enjoyment from. I decided to create Zilch (also known as Farkle). Since the portion of android that is newest to me is building and manipulating the view, I ended up writing code that was very coupled between the view and the game logic. It reminded me of code I would have written early in my college career. Not my best code.

After the main gameplay was done so that I could see things on the screen and touched them I looked at my code and realized how bad it was. Events tied straight into business logic actions rather than calling a packaged up set of game rules that could be tied to any front end. This means if I wanted to modify my front end to use a different widget for a particular task I would have to change my business logic as well. Not very efficient, and very difficult to work with.

I think this sums it up about nicely. Link goes to the original creator.

It did however help me identify something that makes it difficult to learn a new language or framework: We don’t always port our knowledge across. I’m very able to utilize TDD, separation of concerns, and creating elegant designs that decouple the view from the model and controller, but when jumping into a new language or drastically different platform I tend to devolve to the most simple of programming practices (which aren’t good). Some practices like TDD can, and should, be applied to every project regardless of language. Having come to that realization, I’m going to restart the game that I had been working on by creating a pure backend first in Java and then tying the front end up with the Android specific stuff. I think it will both help in learning android, and in creating a decent implementation of a game.

So when moving to a new territory, try not to forget what you already know and see how it can apply to what you’re doing. There is great carryover between many languages, leverage your strengths and knowledge and strive to write good code, even in your hobby.


20 second builds

Posted June 11, 2010 by Jearil
Categories: Build Process, Design, Java

Tags: , , , , ,

Back in May of 2007, Linus Torvolds did a talk at Google about git. Specifically he tended to reiterate the point on how your workflow changes dramatically when you can perform a merge or get new code from other people in under a second. Merging multiple branches into your own branch without remembering revision numbers and knowing that your history is in tact, being able to view the entire history of a project without an internet connection, and just being able to work with your version control system in sub-second time can change how you work with your code. You become willing to make branches because it’s so cheap and easy. You can try out new things quickly and have an easy way to toss them if it doesn’t work out, or merge back parts if it does. I think that the philosophy of really fast version control and its effects on your productivity are quite real, and very important. I also think that the same mentality can and should be applied to your build process.

An example of how development might work via a revision control system such as git. I just needed a picture. Image provided by wikimedia commons.

Of course the first thing you might think is “There is no way I’m going to get my build down to under a second.” And for anything non-trivial, you’d be right. However, I think having a goal of a build plus unit tests in under 20 seconds is not an unreasonable demand. Even better if it’s under 10 seconds. But projects can get really large and involve thousands of files and a similar set of thousands of unit tests. How can you build all of that in under 20 seconds? The answer is: you don’t. Do I sound contradictory? I’m not, but you might have to change how you think about your project.

The main idea behind getting a build under 20 seconds is that it will allow you to compile what you’re working on and run all of your unit tests so that you can test your changes and see if anything breaks. If your build takes several minutes you’re not going to want to build and run your unit tests until your done. This makes doing Test Driven Development a lot more difficult because if you don’t run your tests constantly, you’re probably not designing around your tests passing. You might write less tests, have a less elegant design, and ultimately produce poorer quality code. But still, a large project with hundreds of thousands of lines of code isn’t going to even compile, much less run all of the unit tests in under 20 seconds, so what do you do?

As with any development problem, you break it down into a smaller and more manageable chunk. Instead of writing a giant application with thousands of different files and unit tests, you write more small libraries and services that hold maybe a few dozen or hundred files and tests that contain decoupled and independent structures. These smaller libraries and services can have their own separate build process as they are all separate small projects in and of themselves. That way you can write just the unit tests relating to those small projects and cut your build times down to under 20 seconds.

Now granted that’s only the build time for one module, but all of them together can still take several minutes. But that’s ok. Most bugs and development that you’re working on will only touch one or maybe two modules at a time, causing you to run the build process for just those modules to fix the problem or add the feature. There’s no need to compile and run unit tests for a lot of other systems that are completely unrelated to what you’re working on. As for if your change will break things in other packages, that’s what integration tests are for.

Besides, if you separate your code into smaller libraries and services, you’ll be providing a natural way of decoupling systems and making them no longer become dependent on each other. If you write good strong unit tests that mock any external entities that are called or would call your service or library, those tests enforce the contract that your other systems will require. This will ensure that changes you make will not break other systems. If the changes you make do break the systems, you just create or modify your unit tests to fail due to this breakage so that you know why your system should output what it does or call who it does.

By driving down your build times by having sections be in separate projects, you will have faster turnaround and feedback on the work that you are doing right now. You can run a build right after changing a single line of code just to make sure, and 20 seconds isn’t too long of a wait to get a response. It’s almost like a small break, but no quite long enough that you start trolling slashdot and forget you’re building something.

I feel this post needs another picture, so here's my cat Mischief playing with some rope.

iPhone vs Evo

Posted June 9, 2010 by Jearil
Categories: Android, Ramblings

Tags: , , ,

Updated: A friend corrected me that you don’t need a google voice number to forward calls straight to voicemail. I’ve updated my post accordingly.

Recently I switched from an iPhone 3GS to an HTC Evo. This was mostly due to wanting to switch away from AT&T to cut costs, but the choice was also fueled by my desire to experience an Android phone. After having waited outside of a Sprint store for an hour and a half I was rewarded with an HTC Evo 4G. There are several people that I know that would appreciate a rundown on the differences between the devices and what to expect because they are thinking about what to get as well. I thought I would document my own experiences and relate the differences both good and bad between the iPhone and the Evo.

While this is in part a comparison between the physical devices of an iPhone 3GS 32GB and an HTC Evo, it also is a comparison between the iPhone OS 3.1.3 and Android 2.1. Obviously some things will change when the iPhone 4 comes out along with iOS 4. This is a pretty hefty list of my impressions so it might be a bit long to read.

iPhone vs Evo

Stock images of an HTC Evo and iPhone. Note that they are not scaled to each other!

The image above may be somewhat misleading as it is just a composite of the stock images of both phones and is therefor not to scale. The Evo is larger than the iPhone by a perceptible amount. If you thought the iPhone was too big, you won’t like the Evo. However if you want to see more of what you’re doing, the Evo’s increased screen surface area is quite welcome. The iPhone’s screen is 3.5″ diagonally while the Evo’s is 4.3″. The resolution is also quite higher on the Evo to go with its larger size being at 480×800 compared to the 3Gs’s 320×480. Obviously this will change with the iPhone 4.

As far as the rest of the physical layout goes, the Evo has a kickstand on the back which is quite sturdy and pretty handy I think. I know I’ve tried to watch videos on the iPhone before and having to hold it in your hand is sort of a pain. There’s no real good way to prop it up. The Evo gets around that by having a built-in stand that lets it sit in landscape mode for watching vids on your desk (or floor as I did the other day).

The iPhone comes with a small switch above the volume controls that lets you put it into silent mode with a quick flick. There is no such switch on the Evo and one has to turn it on and press the volume down button until it goes into vibrate mode. Similarly you have to press the volume up button to bring it out and back to your normal levels again. Annoying I think. You can download a widget to make silencing a simple button press which is handy, but uses up screen space and still requires you to unlock your phone and press something on the screen.

The Evo sports 2 camers, a low res front facing one and a higher res rear facing one. Most of the time you’ll use the rear camera as it has higher quality, but if you want a quick pic of yourself or you want to do video chat the front camera is useful. The rear camera comes with an LED flash which can be handy in low light situations. The camera application for Android has way more controls including shutter speed, white balance, modes such as greyscale and sepia, and the ability to adjust the resolution. It can also zoom (though it looks like a digital zoom so the quality suffers, you might rather just crop after taking a regular photo), and record 720p video.

My cat Mischief on her plush throne. She was the unknowing model of one of my first Evo photos.

There is an HDMI port to plug your phone up to a TV if you wanted to, but I don’t own a cable and I can’t really imagine myself doing that very often. Still it’s nice I suppose since it’s there. The other port on the bottom of the phone is a mini USB port for data transfer and charging. One of the things that I really like about having the Evo now is that I can use the same cables on my phone as my fiance’s Palm Pixi or my Kindle. Using a standard type of cable rather than a “dock” connector means we can have just one car charger and exchange cables around the house with whatever is available. Also, replacing the cable should be cheaper.

Rather than just a home button, the Evo (and I assume most android phones), has 4 buttons on the bottom including a home button, menu, back, and search. This turns out to be nice in some ways, but less so in others. I find that applications for Android tend to rely on those buttons too much and as such apps are less intuitive on Android than iPhone since controls are hidden behind a menu or rely on a back button.

The virtual keyboard on the Evo is pretty standard, though laid out differently than the iPhone. I do like that it comes with a button to hide the keyboard so you can see more of the app underneath. Also the keyboard is set up by default to give very small vibrations as you press the buttons as feedback to your tapping. As the clicking noise of the iPhone annoys me (so I turned it off), the vibration is a welcome change for knowing when you’ve pressed a button. It also works on the navigational buttons on the bottom. The keyboard itself does auto-correction like the iPhone does, but it seems less accurate on the word that I was looking for. I prefer, however, Android’s practice of showing you possible matches as you’re typing, letting you choose one of 4 possible matches.  The built-in dictionary can be added to if you type in something that doesn’t appear on the list of matches, and I thought it odd that by default it was missing things like ‘voicemail’. Also if you type something in and want to make a correction, it’s more difficult to place your cursor on the Evo than it is on the iPhone. On the iPhone you can get a little magnifying glass showing your cursor position if you hold down the tap, the the Evo you just have to tap and hope it was close enough. If not, tap again. Holding the tap down just brings up a menu for selecting text and copying and pasting.

In a way it’s nice that the battery is removable so that you can carry a spare, upgrade it, or replace it yourself. Unfortunately the battery doesn’t seem to last very long. It may be that my phone battery just wasn’t ‘seasoned’ yet, but a day from 9am to 11pm doing pretty much nothing but standby brought it down to 5% battery. Now this also could have been because I had applications running in the background that I didn’t know about, and there are apps out there to monitor and kill unwanted background applications. It’s a bit more of a hassle, but it might help my battery woes. Luckily one of the really neat features with an android phone is that the battery information screen will actually tell you what applications or services are using up the most battery.

Under the battery is the micro SD card. By default you get an 8GB card. You can upgrade to a 32GB one, but I’ve not seen anyone sell anything larger than 16GB. You can swap out as many as you want to give yourself more storage, but its placement makes that impracticable. Also until Android 2.2 is out on the phone, you can only use the 440MB of internal memory for storing applications, unlike on the iPhone where it’s all one space that you can install apps and have data. However, the other side of that on the Android is that you can see the whole filesystem and actually save files directly on the Evo and transfer them later to your computer.

This brings me to one of my biggest annoyances with the Evo, especially after having come from a set if iPhones: sync. Basically sync on an iPhone blows android out of the water. There’s no de-facto integrated package for syncing contacts, calendars, email accounts, photos, videos, and music on Android. There is an attempt to do some of those things with double-twist which is a sort of iTunes clone, but it fails in a lot of ways. Music syncing isn’t too bad, but videos need to be put into playlists for any type of control and photo syncing is basically broken. For photos it copies all of your photos into a single directory and skips ones whose names match. This means if you’re using a digital camera that labels photos with something like DSCF1293.jpg and you have 2 folders with different photos with the same name, you won’t get one of the photos. Also since it doesn’t sync folders you lose any organizational ability. I was surprised that Picasa doesn’t have any Android syncing, but it seems to not be important to Google. What’s also frustrating is that due to digital photography making larger and larger files it is hard to sync your entire library. I ended up using Picasa’s export feature to scale down photos in a separate directory that I would copy to the Evo. Picasa forces you to export one directory at a time so it can be a tedious process.

The photo application that came with the Evo can link up to your flickr and facebook photo albums, but strangely enough not Picasaweb. I thought that was really odd considering Android is a google OS and the gallery application seems like it would be standard. Apparently there is another gallery application (some call it gallery3d) that can link to Picasa to view your web photos. If you don’t mind the minor delay and paying $5 a year for 20GB of photo storage (a good deal), then you can avoid copying photos to your phone all together and just use Picasa’s web photos. You’ll save space on your phone for music and video as well.

Since the phone can run multiple applications, it needs to be able to tell you when something has happened with one of them. On the iPhone you would receive a notification popup that would block whatever you were doing in order to handle it. This can be really annoying if you’re in a game or even just browsing a web page. On Android, there is a very nice notification system that places notification icons at the top of the screen near the battery and cell status info. You can drag from the top of the screen down to expand the notifications and deal with them as you see fit. You can also clear them if you don’t wish to act on them. This is helpful for apps like Meebo which tell you your status or if you have a new IM at the top while not getting in the way of your current application.

The app stores on both devices are fairly similar. They both divide apps up into categories and have tabs for top free and top paid applications along with a search. An interesting addition to the Android market though is the ability to install apps via a barcode scanner. You have to download a separate barcode scanner app first, but after that you can scan codes like the one below to launch the marketplace installer for that app. It’s good for when you see an app on your computer but you don’t want to type in the info or search box on your phone. Just scan and go.

This is the QR code for Replica Island, an open source game for Android.

When you want to uninstall an application, the iPhone has a much easier system of just tap-holding and clicking on an X. In Android you need to go to Settings -> Applications -> Manage Applications, click on the application, then click on uninstall. Interestingly enough you can also go to the Market app -> Downloads, click on the app, and do an uninstall from there. Either way it’s not quite as easy as on the iPhone.

Applications can do more than just run in the foreground taking up the whole screen, they can also be (or supply) widgets that run on one of your home pages providing information or interaction on their own. There are many handy widgets such as Pandora’s radio controls, clocks, a calendar, quick contacts, a friend feed streamer, and probably a lot of other ones. The ability to get quick info without having to open a full app can save a bunch of time that you would be spending opening and closing custom apps for simple things. Unfortunately on the Evo you have to be careful of how many widgets you use as screen real estate isn’t as plentiful as on the iPhone. There are 7 screens to the home page instead of the iPhone’s 9, but it shouldn’t be too much of a problem. For all I know there might be an app to increase the number of screens. The android also has a nifty spaces-like display of all of your screens that you can access by hitting the home button while on the center home screen.

Making phone calls is probably important for a phone as well, and the Evo does the job ok. It’s sprint rather than AT&T which can mean different things to different people in different places. For me it runs faster and more reliably, but I have good Spring coverage and AT&T wasn’t so good in my area. One thing to watch for though with the Evo on Sprint is that unlike the iPhone on AT&T, voice and data do not go together. This means if you’re using a data app like an IM client and you make or receive a call, you’ll get disconnected from your app (unless you’re on wireless). Not too big of a deal for me, but an interesting note. If you’re lucky enough to be in 4G coverage, this isn’t a concern as 4G works with both data and voice. I don’t have 4G yet though so I can’t comment on that.

The Evo has multi-touch, but I don’t think the apps support it as well as on the iPhone. For instance, if I receive an HTML email there is no way for me to zoom in and out to various parts of it in the email apps that came with the phone. It’s possible that a 3rd party app would allow you to do so, but the default ones are lacking in that area. Other apps don’t always take into consideration orientation as much as apps on the iPhone seem to, but that could just be my luck with applications so far.

The iPhone brought out visual voicemail which was amazing at the time. The Evo has this as well by default, but even better is the ability to get a Google Voice account which acts like visual voicemail on crack. You not only get to see the message in an inbox like setting, but Google with transcribe the messages as well. You can set custom greetings on a group or person basis so that certain people get certain messages. You can also set up special rules such as certain numbers going straight to voicemail or dropped completely.

My Evo came with an application from Sprint that seems actually quite useful (not the NASCAR one), it’s called Sprint Navigation. It’s basically a turn-by-turn GPS direction program but it’s better than my current GPS in my car in that it will use traffic data to reroute you to get to your destination faster. While my GPS can also do this, it has a subscription fee. No fee on the Evo though so that’s a gain.

So that’s what I can think of and have experienced for now. I used to have an iPhone and this new one is definitely different, and not bad at all. All things being the same I’m not really sure which phone I would choose. I do know that for me, developing apps on Android will be a lot easier than iPhone, but that’s not a normal concern. Hopefully this little comparison will help someone make their decision and give a better idea about some of the differences between the two phones.

From iPhone to Android

Posted June 2, 2010 by Jearil
Categories: Android, Design, Go, Ramblings

Tags: , , , ,

Starting this friday I’ll be losing my wonderful iPhone and immersing myself into the world of Android with the HTC Evo. The decision has less to do with dissatisfaction with the iPhone or the merits of Android, and more with moving from AT&T to Sprint. My fiancé had been on Verizon and I was on AT&T. Her contract was up and we decided to merge to a family plan of some sort to save money. While originally we were going to move her to AT&T, she didn’t like any of the phones and AT&T was a bit expensive (and a pain to set up). After some research, it became a simple math problem that Sprint won out by saving us $50 a month.

Android Logo

The Android Logo is a little green robot man. Hopefully he will prove to be friendly.

So I’m selling my iPhone (eBay link) and switching to the Evo in order to save some money. However, this does bring up an excellent opportunity as a developer. Mainly in starting to learn about Android development for making mobile applications.

I find the Android development environment quite interesting. I’m not as big of an eclipse fan, preferring IntelliJ IDEA myself, but the Android integration with Eclipse is mighty slick. Having it bring up the simulator was probably as easy as it is for the iPhone. Interesting opportunities arise.

While programming for the iPhone is all done in Objective-C, programs in Android are done in Java or other JVM compatible languages. The ability to use Scala or Groovy for making mobile applications. Granted the integration for Scala and Groovy might not be as good as straight up Java, but it’s still a benefit that it’s available. Also, since I’m a Java developer at my day job, jumping into Android programming should be a lot easier as I will just need to get used to mobile development and not a whole programming language at the same time.

However there are parts of my iPhone I will miss. Since I play Go a lot, I’ve been very involved using a program called Boardz for turn based play. I’m not sure if there’s a good alternative app for the Android (I’m sure I’ll be looking on Friday). However, if there is not it actually provides me with an excellent opportunity. Basically to create my own version for the Android.

You see, I’ve always been interested in doing personal projects, but I’m never able to come up with a good idea. Having an excellently delivered piece of mobile software that will be unavailable on my new platform gives me a perfect opportunity to recreate a similar program for myself and others. I’ve already started a bit by starting a project to convert parts of the Fuego Go library over to Java. Ideally when I have a basic library for dealing with SGF files and game moves along with calculating things like ko and final scores, I’ll be able to plug in a nice Android interface to it and build a server, maybe on App Engine, to handle game events.

If anyone is interested in collaborating on a project like that, drop me a comment. I’ll have some actual code posted to my github project page later today.

Fun at Maker Faire

Posted May 28, 2010 by Jearil
Categories: Building, Ramblings

Tags: , , ,

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.

Relating Development To Go

Posted May 14, 2010 by Jearil
Categories: Baduk, Design, Go, Ramblings

Tags: , , , , ,

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.

CoasterBot Finished!

Posted May 6, 2010 by Jearil
Categories: Building, Robots

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.

Finished CoasterBot

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.

The motors are powered by 4 AA (eneloop) batteries. The robot is is controlled via an Arduino Duemilanove sporting a Proto Shield. The arudino controls the motors via an L293DNE motor controller. The microcontroller is powered by a 9V battery separate from the motor power source. It runs a fairly basic program that detects when an obstacle has been hit and causes the bot to back up, turn a little bit, and continue forward (only to bump into something else later or fall backwards and flail a bit). There are also a few pictures.

Electric Schematic

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.