August 2009 India Pale Ale

So San Diego is hot as hell this time of year, so I thought I’d brew up a batch of India Pale Ale to cool things off.  And what is better than a single batch of beer?  Two batches of beer.  I have to thank Brandon for supplying the recipe, the hops, extra equipment, and time to help me put these batches together.

Base Recipe:

• 1/4 lb. of 20L Crystal Malt
• 3 lbs. Wheat Dry Malt Extract
• 3 lbs. Amber Dry Malt Extract
• Irish Moss
• Dry English Ale Yeast

First batch:

1. 2 oz. Simcoe @ 60 minutes remaining
2. 1 oz. Simcoe @ 10 minutes remaining
3. 2 oz. Simcoe @ 0 minutes remaining

Second Batch

1. 2 oz. Columbus @ 60 minutes remaining
2. 1 oz. Columbus @ 10 minutes remaining
3. 2 oz. Columbus @ 0 minutes remaining

We started steeping the grains when the water hit 100 degrees Fahrenheit, and let them steep until just below boiling point.  We had two brewpots going, one with a copper bottom and one without.  It turns out the copper bottom really made a difference.  It took about a third of the time to get the brew up to boiling point in that pot.  We intentionally tried to stagger the brew times of both batches because we only had one wort chiller, but we hadn’t anticipated the difference in boil times.  As a result, we kept the second pot steeping for about 30 minutes just below boiling point.  It took a long time to chill the wort and we had to pitch it a little warm at 85 degrees, but it seems to have given the yeast a good head start and I haven’t noticed any funky smells coming from the fermentation chamber.

IPAs are rather hardy beers, brewed originally by the English to supply the settlements in India.  They were designed with high alcoholic and hop content so the beer would be able to survive the 8-10 weeks it took to deliver the barrels from London.  If you don’t have a basement, refrigerator, or some other cool place dedicated to fermentation IPAs, work very well in the hot summer months.

Compiz Fusion

This is perhaps the best thing to ever happen to my PC since Gentoo Linux.  I know that it has a tenancy to be a bit buggy at times, but, what good is a window manager if you can’t use it to draw flames and raindrops over top of everything, or explode your desktop into a cube showing each and every window with little gears inside.  The only downside seems to be that my productivity has dropped by about 75% because it’s just too fun make jiggly windows, raindrops, and flaming words on my desktop.

Here’s a few screenshots, yeah they’re kind of silly:

I still think that Compiz Fusion puts anything that Mac or Vista has to absolute shame.  To the authors:  Keep up the good work, it’s much appreciated!

Writing a Test Case.

No matter how you slice it, software development is tricky business.  A majority of problems can usually be solved by isoloating your problem in a few lines of code.  Secondly, well written test case can help others make sense of what you are trying to do.  There are not hard and fast rules as to what makes a good testcase, but the following guidelines should be kept in mind.

Often times people jump into IRC asking for help.  Usually they post 300+ lines of code to a pastebin, get no response then rage quit.  Most people fail to realize is that even the most experienced and seasoned software engineers will need to sit down for a minute or two to figure out what’s going on.  Most people on forums or chats are simply unwilling to do so, because their time is valuable and they’re certainly not going to bend over backwards sifting through somebody else’s code to figure out what’s going on…unless they’re getting paid to do so, of course.

1. Stick to only standard language features. The core language features are extremely well tested and documented.  Isolating your problem to only standard features virtually eliminates the possibility that the problem you’re encountering is the fault of third party code.   That is not to say that all language implementations are perfect, often times implementation bugs are discovered through simple and isolated test cases.
2. Keep it concise. You are trying to solve only one problem at a time.  Usually a good testcase involves a single class or function demonstrating the problem.  Create mock objects where necessary to use in place of more complicated objects.
3. Post the actual results, expected results, and how they differ. This helps anybody reading your code the opportunity to pinpoint the particular problem.  For instance a VB programmer may attempt to use something like 2^3 to represent pow(2,3) in C.  A proper testcase would  contain a the comment, “I’m trying to calculate two raised to the third power, but this program just prints ‘1′, I should see 6.”  Followed by a snippet of code you could feed into any c-compiler that would demonstrate the problem.
4. Avoid any random, unpredictable, or undefined behavior. Random results are difficult to interpret.  Often times code relying on undefined or indeterminate behavior may work fine on some boxes but not on others.  It is possible to post code that crashes for you, and works fine for everybody else.
5. The code should be a complete program. A complete program should compile and run.  If you’re trying to solve a particular compiler error, try to write code that produces just that compile error and nothing else.  It’s usually easy to explain a single compile error with a little bit of context than it is to muddle through dozens of errors.  Don’t assume that somebody understands some framework you’re using.  Once again, even seasoned software veterans need to study an unfamiliar base of code before knowing how it applies to your problem.

If you learn to write test cases well, you can better communicate your coding problems to others wheather they be bosses,  coworkers, or random people on chats/forums.  You also will force yourself to write stable and maintainable code, and will likely learn a thing or do doing it and won’t have to rely on others nearly as often to accomplish what you want effeciently and effectively.

Shocker!

So I picked up a good deal on a new paintball marker this week. Shocker SFT 2006 model. I took it out for a few games this weekend and it quite fun to use. The picture shows the old VL Revolution loader. Unfortunately, there was a slight mix-up in shipping and the hopper it came with was shipped separately. It’s supposed to have a Halo loader with it, but it’s in the mail so I went a day without it.

The marker has a vision board, which is a really nice feature. I’m not sure if that feature is standard on all new NXT Shockers, but I do remember a few years ago the vision feature was optional and quite an expensive upgrade. Unfortunately, this model has the reflective style sensor, which I’m told isn’t as reliable as the break-beam style sensors which are available in the NXT Shockers. Regardless it performs quite well and I had fun with it on the first day. I can’t wait to take it out again for some games, this time hopefully with a proper loader attached.

Review: Lost Winds

So for about a year now, Nintendo has been stuffing my email Inbox with the weekly promotional email touting the latest and greatest releases on the WiiShop channel. For those of you who have been living in a small cave off in some desert island somewhere, WiiWare was released a few weeks ago in the United States. A few days ago I decided to give in and download Lost Winds by Frontier Development. I have to say that I found the game to be quite impressive and well worth the 1000 Wii Points ($10.00) to download. The object of the game is to navigate the hero, Toku, through various side scroller style puzzles. His sidekick, Enril, an ancient wind spirit assists him in clearing obstacles and vanquishing his foes. Toku is unable to fight enemies directly and relies on Enril and his surroundings to take care of enemies. The gameplay features WiiMote like gestures to direct the wind which indirectly affects the surroundings of the main character. The game’s progression reminds me of the Metriod series of games. Each area has several doors or passageways just out of reach, and the player is left to unlock new powers and abilities to enter new areas. The game tries not to repeat itself too much, but parts of tend to drag. The usage of the WiiMote as a pointing device proves itself well for this title, although it can get a bit awkward at times. Also, as far as I can tell, the main character can’t die. Even when he runs out of health, all it takes is a shake of the WiiMote to revive him. This seems to take some of the challenge out of the game, though the game is still fun to play. Overall, I have to say the game is well done and I look forward to seeing more titles from Frontier Developments.