Posted tagged ‘Ramblings’

An Idea for Tracer Bullets

August 6, 2010

My favorite software development related book, The Pragmatic Programmer, has a section in it where it mentions tracer bullets. The tracer bullet system they describe really reminds me of the scaffolding system that Rails made popular. It’s sort of a loose structure that gives you something to play with but that really needs to be fleshed out for your finished application. The idea behind using a tracer bullet, or scaffolding, is to have that basic structure to build with and help avoid the ‘blank page’ problem (writers and programmers both know that a blank page is the most difficult thing to write from). So scaffolding is useful, and what Dave and Andy remark as tracer bullets I’m going to call scaffolding for this piece. I would like to introduce a different idea for what tracer bullets are, and how they can help you focus on good Test Driven Development (TDD) and battle the problem of forgetfulness due to complexity.

Book cover for The Pragmatic Programmer

This is an amazing book. My top choice for any developer, especially ones just out of college or with limited 'real world' experience. Buy it, it's worth the price.

If you’ve ever worked on a new system or a larger refactoring of an old system, you’ll have noticed that you get into a sort of groove with what you’re doing. You look at the big picture and you start making your modifications. Something comes up though where you change a method signature and you have to adjust all of the places that use it, which maybe makes you rethink some basic designs and causes another smaller refactor or something during your larger one. Eventually when that’s all done you go back to what you were originally doing. You’re testing all the way which is good, but eventually you get to a point where you stop and say “I’m done”. Or at least that’s the idea. Often it comes out  more like “Am I done?” and you wrack your brain trying to think if you remembered to put everything into place or are you leaving out some small bit that’s going to cause a bug later on. If this has never happened to you and you don’t understand what I’m talking about, you may stop reading.

The main problem seems to be that you have this grand idea at the beginning, and you know pretty much all of the parts that you’re going to have to modify to make things work, you just loose track of what you’ve done and what you haven’t done. Now you can make a paper ToDo list at the start and check everything off, and that’s a viable method. However I would submit that you should utilize your best programming tool right from the start to keep track of your progress: your tests.

When you first collect your refactoring (or basic design) idea, you should know many of the places that you’ll need to modify in order for it to function. Create unit tests for each of these major ideas. These tests should fail with an error message relating to what the idea is and a note that it isn’t actually implemented yet. As you start to refactor, replace these tests with the actual tests for that piece of functionality. You won’t be fully removing the tests (just by having those tracer bullet tests to start with means there’s something that needs to change and those changes need to be tested), but you’ll be adding real tests for your changes to them. When all of your tracer tests are replaced, you should know that you’ve covered everything that your design required.

That doesn’t mean additional testing shouldn’t be done, there are often times areas that need to be modified or added that you did not originally envision. However, it should be a good start to tracking down those areas that need work. It should also prevent you from forgetting any of those key areas that you thought about originally but lost track of during the hectic course of development.

Tracer Bullets in this sense are really just empty failed tests that provide guidance as to what you need to work on. They’re not real tests, but they’re placeholders for where tests should be in the future. They act as a guide to help you figure out what you should be working on next. In addition, since you need to modify those failed tests for your build anyway, it should encourage you to work in a more test driven way by writing your tests first. Since you’ll look at your list of failed tests as your “ToDo” list, it will encourage your first action being to change those tests to something useful rather than a paper ToDo list which encourages you to jump into writing the application code before your tests.

Storm Trooper Helmet

As additional encouragement to practice Test Driven Development, here's the coercive face of failure.

Anything that keeps us more organized and removes unnecessary burdens to our mental flows is a helpful device for a programmer. Being able to utilize any technique that will increase your likelihood to properly test your application code is also a great benefit. This is just an idea I’ve been pondering for some weeks and I’m sure it’s not the only one for combining your design and testing in an up front mannor. If anyone else has any suggestions or practices that they use, please feel free to let me and others know what they are.

Interesting Work

July 8, 2010

One of my largest problems at my job is finding interesting work or making my work interesting. Without having the physical exertion associated with an outdoors job, having something that keeps you actively engaged not only increases productivity, but also personal enjoyment and quality of life. Basically, if you don’t find your work interesting, you’re not going to want to do it.

My Cat Mischief

My cat sometimes attacks the chair in her more crazy moments. She is always interesting, but I don't work with her.

Finding interesting work, or ways to make your work interesting, is not a very easy thing to do. But I find that sometimes those things that are boring are excellent opportunities to find ways to automate and therefor make a computer do instead. This serves two main purposes. The first is that you’re no longer doing boring work, a computer is. The second is that you just created some interesting work in creating a way to automate the boring stuff. Typically the stuff that’s boring is something that has no uniqueness to it and you have to repeat over and over again, which is the perfect target for automation anyway.

For example, testing is boring. Going through and finding all of the areas where your program can break and trying to make it happen can be a drag, especially when you have to do it for every release. However, creating automated tests is more interesting. This is especially true if you add extra flair such as making lava lamps turn on when a build breaks, or integrating it with an sms service that sends you texts every 5 minutes that the build is broken, causing you to drive back to work at 11pm to fix something wrong with the continuous integration system itself since the ops people decided to shut down one of your auxiliary systems. Ok, that’s less fun.

Having a passion for what you do and having your work be interesting is critical to your success in life. Hating what you do for a living and finding your work boring will just cause you to be bad at your job and unhappy in general. If you’re unable to discover a way to make your work more interesting for you, maybe you should consider changing career paths.

I don’t have any great suggestions for making any boring work fun. I know from experience that I personally enjoy taking any project and attempting to find the most elegant way to solve it with the best performance possible. Making sure that everything has documentation and that the unit tests cover over 90% of the code gives a wonderful sense of satisfaction. But any sort of goal that yields a high rate of satisfaction should be targeted as something to strive for in your day to day working life.

Fun at Maker Faire

May 28, 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 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.

Do Research. Don’t Be Just A Code Monkey.

March 22, 2010

I don’t think that good developers are good because they’re overly smart and well suited for the work. Being smart is definitely a plus as it helps get to the heart of problems faster, but even the blade of the keenest intellect will be rendered blunt by the muffling sheathe of ignorance.

Waxing poetic aside, you can’t do a good job if you don’t know what you’re doing. No matter how good you think you might be, you can be better by research, study, and experimentation. I feel that this sentiment applies not only to programming, but to all matters of life. The driving force behind this reckless abandon in the pursuit of knowledge and research is passion. You might not have a passion for your job, but hopefully you have a passion for programming (assuming your a programmer… insert other career as it will work well enough in substitute). If you don’t, consider finding a different career, one you have a drive and desire to succeed in. You’ll go farther in an area you have a passion for than one you don’t. It’s better to be an expert at a “lesser” career than a bad or mediocre at a “higher” career. No one wants a rocket surgen that doesn’t really have a passion for rocket surgery.

“But how?” you may ask, thinking that just saying to ‘research’ without any idea of what goal to pursue isn’t very helpful advice at all. Well that might be true, but everyone’s passions, interests, and job requirements will differ so saying ‘learn about parallel processing’ or ‘research distributed computing’ or ‘learn Ruby, it’s awesome’ isn’t very helpful either. But there are a few methods you can use to start your exploration.

The main idea is to explore areas around your current job, but perhaps not directly related. Try learning a different language that you could, theoretically, implement your same work project in if you knew the ins and outs of it. Maybe start a personal project at home that uses that language to discover the differences between it and something else you already use. Sometimes the features of one language can give you ideas how to better use the one you’re stuck with. If you’ve ever used closures in Ruby (or another language that has them), you’ll start thinking about your Java or C code quite a bit differently.

Another excellent thing to do is learn a new framework or way of doing things that is not the norm for your day to day job. Let’s say you’re writing web apps that deal with a lot of relational database transactions and data manipulation. Try learning about non-relational databases such as object databases or NoSQL. There are many open sourced, non-sql dependent databases that you can try out to learn how you can store and retrieve semi-structured data in a non-relational way. Try to figure out the benefits you gain with your current methods, and compare them to the benefits you’d gain if you switched to a different one. You probably won’t switch your work project over, most people don’t have the authority to do such a thing, but it’s still useful because you’ll open your eyes to different ways of doing things which will end up translating to useful knowledge in your daily job.

Learn a new language every year. Do personal projects in that language. If it’s scripting, maybe make some scripts to help your day to day life out a little. Knowing how to utilize more langages will help you appreciate the differences of them and allow you to be better able to pick the best tool for a given job. It also doesn’t hurt when someone at the office starts asking for someone with experience in some new language and you’re the one who knows anything about it. Embrace change, and don’t get stuck in a rut.

Learn something new every day. Be it a use for a framework, a new language feature, or just something about your own code. Continually learning is critical in the high tech field, as you’re knowledge goes out of date way faster than a lot of other professions. Letting yourself get out of date is like letting a knife rust. It won’t be very useful to its user for long, and will be replaced if it gets too far worn.

Test your code before you write it. Test Driven Development really works. You’ll end up writing way more test code than you ever did before, which is a good thing. You might also notice that you structure your code differently if you write your tests first. The main idea is to allow each piece of code to be tested individually from any other piece of code. If you have a class that you want to test a method of, you should be able to fully test that method without implementing any other class. Any reliance on another classes behavior should be implemented through mock objects. Keep your code decoupled and program based on interfaces. It might not be a bad idea to look into a dependency injection framework, or to get familiar with the finer points of the factory design pattern.

Learning and knowledge is the key to success in our world. I would much rather have someone who’s passionate and willing to put in some work to learn how things work and how to do things better than the average day to day code monkey on my team rather than a good code monkey. The second can implement things that I ask for, but the first can invent new implementations and design reusable code that is worth 3x the code monkey.

Go/Chess Timer with Camera

March 5, 2010

So as I mentioned previously, I’ve been interested in building things recently. I haven’t yet purchased an Arduino yet (I’m waiting to find the right package and for some spare money), but I still think about projects that I want to do. I’ve glanced at several things that other people have done and while making my own skill crane might be pretty cool, I came up with another idea that’s been floating through my head for a few days now.

I’m a big Go fan, so for me making something related to Go would be interesting. There are lots of programs for playing games on the internet which have the unique advantage of recording the games that you play so you can exactly review them later. For physical games, you need to create a kifu to record the game, which requires that you write down your move after you make it. Writing the move down however can be distracting from thinking about the game. In major games, professionals will have a recorder who sits and records all of the moves for them (they also keep track of time), but that’s not very feasible for the majority of players.

So the idea is to make a device that automatically creates kifu for physical board games. I think there is a fairly obvious path for doing this as well. In a tournament style game of Go, players would use a Go/Chess timer for keeping track of how much time each player has. The devices are generally a box that sits on the side of the board with two largish buttons on top and two clocks underneath. The clocks show the time for each player. When it’s your turn, your clock is counting down the time. When you finish your turn, your clock stops and your opponents clock starts counting down. There’s a few more advancements that can happen in these clocks like dealing with overtime and such, but that’s the basic principle.

Creating the clock with an Arduino shouldn’t be too hard. Two buttons (plus maybe a few more for configuration), two LCD screens, and maybe something to make noise when you run out of time should be fairly easy to wire up and program for a basic timer. What I’d like to do though is also attach either a web camera connected to a computer (laptop) or a digital camera that has a remote shutter control. The idea is that when you press the button to signify that your turn is over, the web or digital camera takes a picture of the board. You can use these pictures later to manually recreate the game in like an SGF file, or if I’m feeling really ambitious utilize some digital photo analysis and recognize where the pieces are played and automatically create SGF files. This way you can review even your physical game after having played it.

The PS3 eye Toy camera is my current target camera platform. There are USB drivers that make it run on windows (and I can look for Linux drivers) so I can pull data off of it. Since I acquired my camera with the Eye of Judgement game, I already have a neat stand that is designed to look down on a surface. When a button is pressed, the Arduino can send a signal over the serial cable to the laptop (or other computer) to signify that an image should be taken. If I later use a digital camera with a remote shutter control, then the whole process wouldn’t need a separate computer at all.

I realize that the same thing can be done just using software on a general PC and designating two keys for the timer, but I think having a dedicated device with better buttons that feels more like a game timer would be a more enjoyable experience. Also the ability to add blinking LEDs and/or sound when your time is running out would add to the overall feel.

If I ever do make it, I’ll be sure to post some info about the end result and some pictures. I’m going to go back to pondering my future building plans.

Remote Datasources

February 18, 2010

Almost all applications today deal with persisted data. The only rare exceptions are usually not very complicated such as a calculator, unit conversion tool, or minor utility. Let us assume that any application we’re working on is going to have some sort of persistant state that must be kept between executions of the application. Typically the state is stored in either a file or a database. File access is useful for many desktop applications used by a single user as the format can be created very easily from the data model, the data is easy to transfer to another user via email or some other file transfer process, and backups involve just storing the file somewhere safe.

Many applications that involve multiple users, including web applications, will instead employ a database. Even single user desktop applications sometimes use a database. Database access is often performed by a section of the code converting objects or structures into database tupils and storing them in tables. When the data is required again, select statements are made that call the data and turn it back into a structure. Usually this storage and retrieval of data is done in the same code base as the rest of the application.

There are a few problems with this approach however. For one, the database code can sometimes become tightly coupled with the business logic of the application itself. The application knows about the data being stored in a database and will often be changed accordingly to facilitate database access. Switching to a different database system can involve very large rewrites of not only the database code, but also application code as it can rely on database specific functionality. Think of functions that pass along snippets of SQL in order to construct the correct objects. Often that SQL will be database specific.

Besides being tied to a single database, the same coupling also ties applications to databases in general. If your application is expecting the data to be stored in a relational database, assumptions in the business logic will be made regarding that. This inhibits your ability to transition to a file store or other NoSQL solution if required. Because of these concerns, my topic for today is about abstraction and remote data sources.

If you code your database logic in with your application code, coupling can form. However if you separate them completely your application doesn’t need to know where the data comes from or where it goes when its saved. All the application has to do is follow a simple generic interface for storing and retrieving data. This not only elements coupling, but has some other scalability benefits that I’ll discuss a bit later.

To really appreciate interfaced based design and loose coupling, try removing your data access code from your application code base completely. Instead, use a language neutral format such as JSON or XML to communicate between your application and your data source, itself a small application. The application will send a request along with perhaps some data if it needs something stored. The data source will then transform that data into a format that can be stored and place it either in a database, file, or any other storage medium that you desire. Later if you want to modify how your data is stored, maybe a different DB system is more suited or you’re moving from a file-based system to a database, you can just modify the implementation of the data source application while not changing a line of code in your actual application. The loose coupling means that as long as the data source maintains a solid interface that the application can interact with, the application can be developed independently of the data source.

If each of your interactions between your application and datasource are atomic and independent of each other, stateless, you can horizontally scale your datasource using replication. Each data source can access a different replicated read-only data store for request information. Meanwhile write access will all go to a master data store that can be replicated to the read-only slaves. Read requests from an application can be distributed to multiple data sources, especially useful if the data source does any CPU intensive filtering or processing.

The main benefit however remains that by separating your data source from your application as a remote service, you can ensure that your code is loosely coupled and that your business logic will not rely upon the underlying method which your data is stored. This will lead to greater flexibility in your code, and a more agile platform on which to build.

Blog Schedule Modification/Goals

January 15, 2010

I’ve decided to change the schedule in which I update this blog. I’m finding it difficult to make 3 updates a week and still have something relevant to say. To that effect I’m going to try a schedule of Friday updates. This will give me a week worth of experience to draw upon every post and perhaps will lead me to more on-topic discussions.

With that said I still have a post to make, and make it I shall. Today I’m going to ramble again, but this time about my own personal career and personal goals; my Developer Aspirations if you will.

From the time my family acquired our first computer, a 486 SX 25Mhz beast with 4MB ram, 210MB hard drive, 2x CD-ROM, and 2400 baud modem, I was pretty much captivated. When you spend so much time tinkering and using a thing due to pure enjoyment of discovery, it makes sense to work that thing into your career. For anyone who still wonders what profession to get into, I would highly suggest something that you can enjoy and that you spend time doing anyway.

My overall goal had been, and to an extent I would say still remains, to become a video game programmer. However that dream is not the easiest to achieve due to a very competitive employment market along with my base skill set and experience hasn’t reflected that required of the industry. I also am not that big of a fan of 16 hour workdays 7 days a week for 3 month stretches which also plagues that industry. However the independent game industry is actually thriving more than ever now due to the increase availability of embedded devices like the iPhone and the Android OS. Platforms that require by design small, narrow-focused apps that can actually be written by a single person or a small team.

So a renewed focus on embedded devices and high performance applications in restricted resource environments. I have no OpenGL experience so the 3D stuff isn’t very obtainable (I’m not the best artist either). It seems like utility applications or gameplay rather than graphic oriented games are the areas I can still dabble.

So I suppose my current development goals are to become more focused on Objective-C and the cocoa APIs. I may also attempt to leverage my free time in making small C or C++ text-based games as a refresher to build my familiarity with the C-based languages and create something simple.

Ideally if I were able to manage the commitment I would dedicate myself to making a small game every week, just to get some code out. That might be a workable goal I can put on my todo list and see if I can’t make at least one decent attempt before Spring hits us.

I think as far as current career goes I’d like to focus more on research and scalability. There are some interesting problems that don’t seem to have very good solutions. Being able to just identify a problem that needs a solution is a good step to making a useful application or model. I know that our current application does not have a very good data model for scaling beyond a few servers, and it would be good to see a way to create the same application in a distributed way like we have with programs like Git.