New Domain

Posted September 14, 2010 by Jearil
Categories: Uncategorized

I’ve moved my blog to my own domain name. All of the old posts have been ported over. This one will stay around for historical reasons, but new posts will be made at I may eventually change it to or, but those changes will be noted on the new site if it happens.

This has all been made possible by Amazon Web Services and EC2 which I talk about in my most recent post:

Learning notes from a C++ n00b – Part 1

Posted August 25, 2010 by Jearil
Categories: C++, Design, Programming

Tags: , , , , , , , , ,

I am primarily a Java developer. My college decided in my sophomore  year to switch from C/C++ to Java for most of the classes. While it did give me a very good foundation in Java development, it created a bit of a gap in my education. While I’ve done work in C in the past, I haven’t had the opportunity to work on a serious project in C or C++. Since my goal is always to learn a language a year, starting now C++ will be that language. It should be exciting.

Get excited by vintage letterpress

I'm excited. Are you excited? You're probably not. You're probably thinking "Why don't you already know C++? What sort of developer are you?" Well to find out, you should keep reading!

This post is the beginning of a series describing my process of exploration and discovery into the wonderful world of C++ from the perspective of a Java programmer. I imagine that some people who know C++ and Java are getting out popcorn waiting for the inevitable meltdown with dealing with things like memory leaks, makefiles, platform differences, and probably a bunch of other common issues I know nothing about. While that may eventually be the case, I’m not there yet.

Immediately, one of the biggest departures between Java development and C++ development is the change in IDE. For Java development I’m a big fan of IntelliJ IDEA. Java has a lot of import statements that involve very long package names and an IDE like IDEA tends to take care of that for you. Refactoring, like changing method or class names, is easy since I don’t need to manually find all usages and change them. Autocomplete and click jumping to method or class definitions is also very handy. The integrated debugger is useful when needed, and I like that it can easily import maven pom files as projects. While I’m definitely a proponent of being able to program in your language without an IDE (you shouldn’t let your IDE program for you), it still can be a useful tool at times.

My new IDE for C++ is vim. Ok, I don’t know if I’d really call it an ‘IDE’ exactly, but it’s my editor. I like vim overall, and I’ve been an avid user of it for about 7 years, so I can maneuver my way around. After reading about ctags, I wrote a script to generate them so that I can use it to jump between functions and methods. I’m pretty sure I’m not using it correctly however, as I have a tags file in each directory and I think the editor doesn’t always pick up all of the tags files I want. I have no idea how to use a debugger, and dealing with import statements is still a pain. Overall though vim is very fast and never hiccups unlike IDEA, so that’s a plus.

Another large departure from Java development is going from maven to makefiles. In Java I can create a maven pom.xml file to list all of my dependencies and plugins. Maven supplies a natural file structure that I can use to arrange my files into packages and place external resources in a place where the classpath will pick it up. There are tools to automatically create stub maven projects that I can just jump into and start coding. I can have any tests in my test directory automatically run just by calling mvn test. I can compile my project using mvn compile, and I can package it all up into a nice jar or war file by using mvn package. These are all default things that come with maven. It takes care of running the javac command to compile my code. It also sets up a testing environment for running tests. A very handy tool.

So makefiles. Makefiles sort of remind me of ant. I never really got into ant because it’s fairly verbose. It requires you to be more explicit in telling the system what to do and how to do it. Really though, makefiles are a bit less useful than ant, as they seem to be more like elaborate shell scripts that use the make utility to run. I still have to put in all of the g++ commands, along with lines of what libraries and other sources to give to the linker. Dependencies have to be accounted for manually. Tasks like clean or test have to be defined along with instructions for what those things actually do. There is no standard setup with clean interfaces for running tests or setting up your file structure. The main positive aspect that makefiles have over maven pom files is that a single makefile can generate several different deliverables (pom files only create a single jar).

I know that there are tools such as autoconf and automake that is supposed to make makefiles more portable to deal with library issues, but they’re not very easy to use. The GNU tool chain has a fairly extensive manual, but it feels like one needs to read the entire thing before even getting started. I haven’t had the time, so the GNU tool chain hasn’t entered my arsenal yet. I’m still not sure how to deal with the library distribution issue, but I’m sure that will come with time.

This is the book I'm currently learning C++ from. It doesn't get into the surrounding tool chain like make or the compiler much, but it's still useful for the language itself.

I’ve only been really looking deeply into C++ for a week or two now, and there are a lot of questions that pop into my mind. I have certain philosophies dealing with programming that I’ve gained over the years. A lot of those practices have been fueled by ideas from the Pragmatic Programmers. Others I have developed on my own. I’m still uncertain as to how to incorporate some of these ideas in my C++ development.

The first and most important of these is unit testing. Java has some very standard unit testing frameworks with JUnit and TestNG. Boost has a library for unit testing C++, and so does Google Test, but I have yet to delve into either of these deeply. Also I’m not sure if there’s a standard way of running tests like you can find with Java. Making sure that each test is in its own section in a makefile doesn’t seem very appealing. Hopefully I’ll find a nice way to easily unit test code (including using mocks), I’m just not there yet.

Also, how do you profile C++ code? I’ve used a tool called yourkit for Java which works very well. I know that there must be profilers for C++, but I don’t know what they are or how to use them. Similarly, debugging is an area that is still very grey. I know that there’s gdb, but I haven’t found a good tutorial on how to use it or how to integrate it into vim or some other editor to set breakpoints and see variable values.

And honestly, while I understand the basic concepts of pointers, I’m still unsure as to when to use them and how to fully utilize their functionality. In Java everything is done by reference (except primitives) and there’s a garbage collector when items go out of scope. When passing any object to a method, it can be modified by that method. I still need to learn a bit more about how scope effects both objects created on the heap and other objects in C++.

Overall there has been a lot of learning in the short time that I’ve been playing around with C++. While I’ve used Objective-C in the past for some iPhone programming, I haven’t really seriously taken on any projects in C++. The learning experience has been great, and quite a bit of fun. While most people would probably argue that makefiles are really annoying to set up, I’ve been enjoying the learning process of figuring out how to use them and creating working builds. My tests have all been small at this point, but they’re sure to grow in size. That said, I know I still have a lot to learn. I shall be delving deeper into the Boost libraries and doing multi-threaded programming with some asynchronous socket connections. I’ll be sure to update again after having gained a bit more experience.


Posted August 16, 2010 by Jearil
Categories: Design, Programming, Ramblings

Tags: , ,

Back when I was learning programming and software development in college, I began a practice of learning a new programming language every year. I started with Java, then moved to Perl, C#, Visual Basic, Python, Ruby, Groovy, Scala, PHP… etc. I still think it’s a good practice for every developer. It’s even a recommended practice by many other developers on how to stay in your game. You don’t want to be stuck in a situation later on in life where you have to quickly learn a new language (including new concepts) after you’ve been using the same one for decades. The COBOL programmers learned that about a decade or two ago.

So learning a new language is good. It’s not just good to have the ability to use that language in your current project, which you may not be able to do, but also if you switch projects to one that uses that language. However, even beyond direct use of the language is how learning new ideas and ways of doing things will change your code in your language of choice, or at least the language you have no choice in because it’s the one your project uses.

The Matrix

I doubt that The Matrix was programmed in single language. I bet even an AI uses an abstraction to reduce the processing power needed to design something like that.

Of course, this actually brings me to my second topic about projects themselves. The idea that you should learn a new language every year isn’t really new to many people. However, I think that the idea should be extended further to encompass switching projects every few years as well. In a large project this could mean just switching from one portion of the project to another, but with smaller projects it might mean switching completely to a different project (or at least dividing your time between the two).

The reason behind this is actually similar to why you should learn a new language. By being forced into thinking in the new language and solving problems with a different set of tools, it can increase the breadth of your experience and help you perform better on that original project or ones you face in the future. Similarly, being forced to work on a new project will make you think in new ways about new problems that will help you in old projects and even future ones. If you stay with a single project for too long, you’ll star to stagnate and be unable to really explore and incorporate new ideas that your project’s problem domain doesn’t cover. Lack of exposure to new ideas will prohibit growth. Your resumé won’t be improving, and you won’t be growing as a developer.

Ideally, if you switch projects you would want to switch to one in a different language than your last project. This will help cover both aspects of learning a new language and a new project. While you can always learn a new language in your spare time and on personal projects, you will generally learn faster if you’re thrown in the water as it were. Similar to learning a language by living in a foreign country, learning a new programming language is much easier if you’re thrust into the depths of it with no choice to procrastinate. You have to learn it to work on your project, which will help you gain new insight into development in general.

I’ll be starting this exciting adventure myself as I transition from my current project in Java to a new project in C++/Perl. While I’ve been meaning to for a while, I’ve never done any serious work in C/C++. Being forced into it by having to work on a code base that is primarily in C++ will help facilitate that learning process through experience. I’m excited for the opportunity and I feel that everyone should strive to make those sorts of changes in their work from time to time to keep fresh and productive.

An Idea for Tracer Bullets

Posted August 6, 2010 by Jearil
Categories: Design, Programming, Ramblings, Uncategorized

Tags: , , , , ,

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.

Socially Geeky

Posted July 28, 2010 by Jearil
Categories: Gaming

Tags: , , , , ,

I’m pretty confident that any software developer is by nature a geek. If you start writing code without an interest in making computers talk to each other and at least a little passion for logic (and yes, math), then you probably are getting into the wrong profession. So we’re geeks, and that’s pretty damn niffty. Geeks however, are not all about algorithms and code. Most geeks aren’t programmers, but have a wide variety of passions and activities. Today I’m going to talk about some of the fun stuff. Those things that many geeks enjoy, and how they enjoy them together.

This last weekend I was fortunate enough to go to the San Diego Comic Con for a day and a half. It was my first time at this con, though I had heard a lot about it for several years. While I only was able to experience it for a short time, it did get me thinking again about geek culture and geeky society. Yes, we have a culture, and it’s pretty unique compared to the vanilla life that many non-geeks experience. Also, for anyone who’s silly enough to think that to be a geek (or even a nerd) you need to be anti-social, well that’s such a false stereotype that you need to get yourself to a gaming convention to sort yourself out.

A rather blatently stolen image. This time of Green Lantern vs Superman (or a variation thereof).

Geek society is full of memes, in-jokes, intellectual humor, imagination, passion, and storm troopers. It’s a society based in comic books, video games, the internet, sci-fi and fantasy novels, television, movies, steampunk, anime/cartoons, toys, pirates, ninjas, and awesomeness. It’s a community based on a shared understanding, interest, and love for those things in life that non-geeks would think of as weird or immature because they know not the value of taking down a raid boss or pondering the relative power levels between superman and the green lantern.

It has been said by a lot of people that humans are naturally social creatures. I think this is extremely prevalent in geek society. One can wear a t-shirt featuring stick figures using sudo on each other to acquire sandwiches, and act as a beacon to other geeks for starting up conversation about web comics, or science, or math. As many geeks feel ostracized by regular society, we tend to drift towards and bond more quickly to others of our kind, forming larger collectives of super geeks. Like unstable atom configurations form molecules. Or Voltron for that matter.

My personal realm of geekery ranges from comics to video games. I lean more towards video games due to some of the social aspects of them. As a youngling, I developed in a fairly rural area where contact with even other kids was fairly infrequent. Games and the internet helped to bridge that gap in my social development. In college, games were the focal point of my social interactions (I went as far as being the president of the Gaming Club). I realize that even now that I have “real” friends and a wonderful fiancé, that games are still an important aspect of my social life. Games can keep long distance relationships with friends connected, or forge new or stronger relationships with people.

StarCraft 2 has finally been released by Blizzard. My hope is that through this game, I can reconnect with lost friends and expand into new ones.

Recently, Blizzard released StarCraft II, a sequel to a game I played quite a bit with many of my friends in college. While the single-player game is quite fun, it’s the multiplayer opportunities that the game provides that draws a lot of the people that I know. It is my hope that, with the release of this game, I can once again connect with friends of mine on the other side of the country, along with meeting new friends in the conquest to eliminate the zerg scourge. And it is that, the unified goal of terrible vengeance upon our enemies; the subsequent battle that pits our strength and skill against those we would conquest against; the ultimate defeat because we really don’t play this game enough. Those moments, like the sharing of customized D&D character and world concepts, are what glue us together as a society.

Of which, if anyone is up for playing (usually after 6:30pst), give me a buzz and we can trade Real IDs™.

Mac ‘n Cheese

Posted July 16, 2010 by Jearil
Categories: Living


I’m a programmer, and I love to code. However I also love to cook. I did not have a good topic to talk about as far as development goes, but I still wanted to get a blog post out there. So today, I’m going to share the recipe and method that I use to make mac ‘n cheese. I’m always tweaking it, but here’s the basic idea.

Mac And Cheese – The Tasty

Things you will probably want:

1/4 cup flour
1/4 cup butter (half a stick)
1-2 cloves crushed/minced garlic
1/2 diced onion
1 tsp or so chopped cilantro (I use the frozen cubes from Trader Joe’s)
dash of salt
dash of pepper
2 cups milk (up to 1 cup can be replaced with cream for a tastier cheese sauce)
8 oz. cheese (I use random combinations of cheddar, gruyere, gouda… other hard cheeses)
8 oz of large elbow macaroni (or whatever noodle you prefer)
optionally: crumbled cooked bacon, diced cooked sausage, cooked peppers, diced chicken, or other things you like in/on mac n’ cheese.

Doubling it is pretty easy. In general I consider 4 oz of cheese to equal about a cup. There should be equal parts milk, cheese, and macaroni. Flour and butter should each be around 1/8th of the milk/cheese/macaroni. You can adjust the quantities though depending on how you like your roux.

Ok, now on to the steps.

You can boil the pasta as per whatever instructions you have with it before or during creating the sauce, just make sure it’s ready when the sauce is ready.

For the sauce, use some sort of sauce pan and melt the butter under medium heat. Add the flour and stir it with a rubber spatula. What we’re creating in the first step if you’ve never done it before is called a roux. Flour or other starches can be used as a thickener for sauces, however it often has the problem of the flour clumping together into floury lumps that aren’t that appealing if you just add flour to a hot liquid. So instead we mix it with a fat (the butter) to dissolve it first before adding the liquid. Also, uncooked flour will give a starchy flavor that we’re not really looking for, so we’re going to cook the roux.

Blonde Roux

A blonde roux as captured by someone on Flickr. This is about the color we're going for.

It’s going to bubble a lot, and you’re going to want to stir it a lot as well. The rubber spatula is to scrape the bottom of the pan constantly to make sure no part stays on the bottom for too long and burns the roux. If you start to see black specs in it, you’ve burned it and have to start over. I’ve never had that happen, but I’ve read it can do so if you don’t pay enough attention. Also if it starts to smoke, you’ve hit the smoking point of your butter and should lower the heat a bit. Once you have a blond roux, the floury taste should be removed.

An interesting note on roux is that the more that you cook it, the more flavor that the roux will impart on the final dish. However, it also means that the roux will act less as a thickening agent. If you want to get more of the flavor from the roux (by making it darker), but don’t want to lose the thickness of a creamy cheese sauce, increase the quantities of the flour and butter.

After cooking the roux for about 10-15 minutes and having it change color to a light yellow, add in the diced onion. You’ll want to cook the onion in the roux for another 5 minutes or so, until it has turned transulcentish.

Add the garlic and cilantro and cook for a few more minutes. You can also add some salt and pepper at this time if you like that sort of thing.

Next, add the 2 cups milk/cream hybrid. For better results, heat the milk first in either a pot or microwave. Having a hot liquid added to a hot roux will prevent the roux from clumping as it suddenly cools. Even if you use cold milk though, you can eventually break it down again as it heats back up, so don’t worry too much.

Once you add the milk/cream you might want to use a wire wisk to really disperse the roux in the liquid. Stir it for a few minutes, then leave it on medium heat, stirring occasionally until it starts to bubble (nearly boiling).

Once it hits the boiling point the roux’s effect will become noticeable and the sauce will thicken. You can cook it for another minute or so if you like to make sure it’s at its thickest state (don’t leave it too long though).

Lower the heat to low or medium low and start adding the cheese. The cheese should be grated to increase surface area and promote melting. If you add it in slices or cubes, you’ll have to stir like a crazy person and keep it on the heat for way too long to get the stuff to melt. Add the cheese in small batches at a time and let it completely melt between additions.

Once all of the cheese is melted, you can turn the heat off. Place the pasta in a large mixing bowl and add the cheese to it, mixing it together. You can add any of your optional meat/veggie items at this time.

Pour the mixture into one or more lightly greased casserole, or other oven safe dishes. Personally, I often use a 10″ cast iron skillet, but I also use a ceramic dish as well. You can sprinkle more cheese and/or bacon/sausage/whatever on top. Place it in a 375˚ oven for a half hour.

Eat… or whatever else it is you want to do with mac n’ cheese.


I originally had a picture of a finished Mac 'N Cheese that I cooked in my cast iron, but the picture isn't on this computer. Instead, here's a photo of a sequoia from Yosemite national park.

Interesting Work

Posted July 8, 2010 by Jearil
Categories: Living, Ramblings

Tags: , ,

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.

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.