Sunday, July 25, 2010

Decorating for Geeks


The decoration of your home should be a reflection of your personality. How, then, should an individual who loves software engineering decorate? I decorate mainly with old arcade machines, giant inflatable Mountain Dew promotional bottles, an expertly framed poster of the periodic table of the elements, and the green Ikea plush snake.

But if I had pillows on my couch, I would want them to make a statement. Pillows can be more than a place to rest your head for a nap, they can turn your couch into a great conversation piece. Here is a collection of the best pillows and cushions I've found.

Ctrl+Alt+Del Pillows. Reboot your sofa.

RSS Pillow. Really Simple Sleep?

Facebook Pillow. Yes, even your furniture is on Facebook. 3 of your friends like this.

Calendar Icon Pillows. Can be a constant reminder of important dates.

Giant Hamburger Scatter Cushions. I wouldn't eat it, but I would sit on it.

Super Mario Bros. Mario Hat Pillow, and Super Mario Bros. Luigi Hat Pillow. Suitable for resting on after those marathon Wii sessions (or SNES, if you're old-school like me).

Fortune Cookie Pillow. The beginning of wisdom is to desire it. Your lucky numbers are 4, 33, 7, and 12.

Peanut Butter and Jelly Pillow. Put one half on each side of the couch?

Bacon Pillow, and its associate the Egg Pillow. Sleep on them, then wake up and eat them.

Ketchup Packet Pillow. Oddly enough, I could find no french fry pillows.

Cherry Pie Pillow. I'm allergic to apples.

And no cookie lover's home would be complete without the Chocolate Chip Cookie Pillow and the Chocolate Cream Cookie Pillow!

The pillows will add a lot to any room. But I'm still looking for Pac-Man curtains.

Saturday, July 24, 2010

Have a Programming Party

Want to have a completely ridiculous amount of fun this weekend? Plan to have a programming party! Yes, a programming party. In one day you can combine the three guiding principles of Amphibian.com - thinking, building, and playing - together with your friends, pizza, and beer.

Here's the deal. Back some 15 years ago, one of my favorite activities was getting together with some friends in a unused, run-down room off the side of a honey bottling plant with a couple computers and writing software. Yes, I know that sounds a little strange but don't let that distract you. We were writing games for BBS's. That's Bulletin Board Systems for you kids that don't remember a time before the Internet. We'd eat flavored honey, drink RC Cola, and write what was probably terrible code, but it was great fun.

I think back to those days often lately, because if you look at the types of software products that are really making news today you'll find them to be striking similar to the old BBS games we worked on. They were small, turn-based, social games - the same kind you'll find on Facebook or your iPhone today. Except we don't use ANSI graphics anymore. That's a shame. But the point is that if the "programming party" paradigm worked for us back then, think how much better it can work today!

Goals of the Programming Party Paradigm

1. Development of a small game or game framework in one day

This seems like a lofty goal. Does a small game have any chance of really being completed in a single day? Well, keep in mind there are 24 hours in a day. And if you have 5 friends working together, that's like 120 mythical man-hours that can be squeezed into a single box on the calendar! Alright, so I'm not serious. I don't think you could actually have a polished, bug-free, ready-to-go application done in a single day. But you could have a playable, slightly buggy, half-working application done enough to share with other people. That should be enough to convince you to either meet again to finish it (after taking feedback from your testers, a.k.a. other friends) or use what you created as the springboard for your next project.

2. Creativity in design

Don't host the party as an attempt to extract free labor from your friends. If you have an idea for what you'd like to create, great. But the point of inviting people over to the party is to get creativity in the design. You need to all throw your ideas together, bounce them off each other, throw out creative feedback as soon as it jumps into your heads. Even if they deny it, I think most people who write software are creative people. They are creating things every day. They combine different software packages together to come up with new and interesting things. When you put a whole group of creative people together with the goal of coming up with something fun and cool, it will absolutely amaze you what can be produced. Yes, software is math and algorithms and logic and a whole bunch of other dull-sounding things, but to make software products that people are really going to enjoy takes a creative touch. Windows 7 and Farmville are both software products, but people enjoy Farmville (although I don't know why). Do people enjoy Windows 7? Eh, maybe if they used Windows Vista they'll say they enjoy Windows 7 because it doesn't suck as much, but that's a whole different meaning of enjoyment. Windows is a tool. Farmville is entertainment, made by creative people. While I guess you could use a party to make a tool, I really think they are best suited to making fun-to-use software that is like nothing the world has ever seen before.

3. Social interaction and fun

There's a stereotype that programmers are loners. Freaky nerds who like to sit alone in poorly lit basements cranking out code. I think people who like to write software are just as social as the rest of the world, but they have a harder time finding people to socialize with. For example, when I am visiting someone, usually because I've been dragged someplace by my wife, people try to talk to me about the local sports teams, or last night's episode of American Idol, or something along those lines. I have nothing to add to conversations of that nature, because I don't follow any sports teams or television shows. But if someone started talking to me about the new Facebook social graph API, I could go on for hours. So getting together with people who share the common interest of programming will be great fun. Even if you don't actually produce anything that works in the end, you'll have probably learned something and had a great time anyway. If you are tempted to try having your programming party over Skype or something like that, think again! You've actually got to get in the same physical location as your friends. Back in the BBS days, this wasn't optional. We were programming in DOS mostly. There was no multi-tasking OS to let us use Borland Turbo Pascal and dial up to BBS chat at the same time (in fact, many BBS's only allowed one caller at a time anyway!). If we wanted to talk to each other about what we were developing, we had to meet in person. It worked for us then, and it will work today.

Programming Party Plan

This is my outline for having an effective and fun programming party.

1. Set up your location. To use my old BBS programming analogy, set up your own honey plant. Everyone in attendance will need to have a computer to work on and a place to sit. Ideally, everyone should be in the same room or two really close rooms. Set up folding tables and chairs if you need to, and get extra furniture out of the way. If people are bringing their own desktops or laptops, make sure they can all hook up to your Internet connection, either wired or wireless. You should also try to have a whiteboard or similar large drawing area nearby.

2. Do your homework. Depending on what type of application you plan to create, you or some of your friends may need to do some research before the event has to start. You don't want to waste a lot of time the day of the party reading whole books, so make sure you tell people in advance if there is a particular topic they should brush up on. Using the Internet to look things up while working is one thing, but you don't want to spend too much time learning the language you are trying to work in while you're working.

3. Start with a schedule, but be flexible. I would recommend getting started early, like 0900. Plan on going until at least 2300. Make sure everyone has a good breakfast, lots of protein and Mountain Dew. Do a couple hours of brainstorming for ideas, then order some lunch while you get started on the programming. Keep in constant communication throughout the day, so if anyone gets stuck on something they can get immediate help. Take breaks every 1.5 hours and have a snack. And more Mountain Dew. Order some pizza for dinner, then break out the alcohol. You don't want to start drinking too early in the day, or the code will get really messed up later on. See what you end up with at the end of the day!

Addressing Criticisms

Many will read this and think I'm crazy. "This will never work!" they will cry out. "Games take years to develop and millions of dollars!" If you think that, you and me are talking about totally different kinds of games. I'm talking about casual games. The kind you pay $0.99 for on your phone or play against your friends on Facebook. They are no different than the old BBS door games. People like me used to crank those things out in no time, working alone, without the benefit of Google searches to help us out when we get stuck on something. This will work because the resources at our disposal today are infinite compared to what we had 15 years ago, and because when a group of friends get together to accomplish something fun they will never fail.

When you schedule your party, don't forget to invite me.

Monday, July 12, 2010

Cheese Soup and the Semantic Web

If you haven't yet heard of the Semantic Web, don't worry. You will eventually. It's going to take off any day now. Really. Web 3.0. Ok, so the world has been moving very slowing in the direction of the Semantic Web. Sorta like IPv6. We'll get there eventually.

So I've decided that I want to help move this thing along. I see big potential here, and I think there are some practical applications already. Consider searching for a recipe on Google. Let's say you want to make some cheese soup. It's delicious and I highly recommend it. Your search results will probably look something like this...

That first site sounds like a great place for cheese soup recipes, but wait... Alton Brown's recipe has a bit of extra information displayed. A rating, number of reviews, prep time, and cook time. How is this possible? Google's pretty smart, but how did they manage to parse that information out of the web page? Searching for other types of recipes reveals that this information is listed on most recipes from the big recipe sites (Food Network, All Recipes, My Recipes). Here's the trick - they've already embraced the semantic web by adding RDFa to their web pages. Google has the ability to parse this information out and uses it for better search results.

It just so happens that CheeseSoup.com is my site, and today we're going to work through the steps of adding RDFa to my cheese soup recipes. Not only will this enable me to better serve the cheese soup-loving public, but it will teach a lot of practical concepts in the emerging world of machine-readable web pages.

To begin, let's first understand what RDFa is. It stands for Resource Description Framework in Attributes. Basically, it's an extension to XHTML that adds a set of attributes for embedding metadata in web documents. All we'll have to do is add some simple attributes to the existing XHTML tags and we're done.

To make this work, you have to include the namespace declaration for the RDF vocabulary you want to use. You can see how I do that here in the markup from one of the recipes. I've simplified it a little for this example, but it looks pretty much like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:v="http://rdf.data-vocabulary.org/#">

<head>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8" />
<title>Cheese Soup</title>
</head>
Make sure you put the # at the end of the URL, it's required. You can use this namespace whenever you want to mark up recipes, and also people, places, events, and reviews. There are lots of other RDF vocabularies for things other than recipes (Dublin Core, Friend of a Friend) you can use, and you can even make your own. We might cover that in a later discussion.

Another thing to note in the code snippet above is the doctype declaration. I'm using the XHTML+RDFa document type because this document will be XHMTL with RDFa and I want it to be completely valid.

Now when it comes to the actual recipe, we just have to add the right attributes in the right places. There is a containing div around the whole recipe, so we'll add a typeof attribute to that indicating that the div represents a recipe. Everything contained inside the div will be associated with the recipe.
<div typeof="v:Recipe">
Inside the recipe div, we'll add property attributes in the appropriate places to mark up the various properties of recipes.
<h2 property="v:name">Canadian Cheddar Cheese Soup</h2>
Basically, all we've done here is set the "name" property of a "Recipe" to be the contents of the h2 tag. These tag contents are now doing double-duty. They're both human-readable and machine-readable. Things get a little more interesting when we get to the ingredients list.
<ul>
<li rel="v:ingredient">
<span typeof="v:Ingredient">
<span property="v:amount">1 lb</span>
<span property="v:name">shredded cheddar cheese</span>
</span>
</li>
<li rel="v:ingredient">
<span typeof="v:Ingredient">
<span property="v:amount">1/2 lb</span>
<span property="v:name">bacon</span>
</span>
</li>
...
</ul>
You'll notice that the li tags contain a rel attribute. This indicates a relationship with another resource, which in this case in an ingredient. Ingredients are types of objects just like Recipes, so inside the li tag we put a span with the typeof attribute indicating that its contents are an Ingredient. Ingredients have names and amounts, so spans inside have property attributes to annotate them. All of this extra information is included for the machines to read, and the humans don't even notice!

There's just one more special thing to consider. What happens when you want the made-for-human content to look different than the made-for-machines content? This happens especially when working with times. RDF wants everything in a particular date/time format, which happens to be ISO 8601 duration format. Fortunately, there is a simple solution. An optional content attribute overrides the contents of the element, so the human sees one thing and the machine sees something else. Here's an example of this for the preparation time.
<p>Preparation time: <span property="v:prepTime" content="PT15M">
15 minutes</span></p>
The rest of the recipe (instructions, rating, etc.) can annotated in a similar fashion. You can see the complete document here. As you can see, the page looks perfectly normal despite having all this great "hidden" information. Be sure to view the source of the page to see all the RDFa markup, and notice the link at the bottom. The page successfully validates as XHTML + RDFa using the W3C validation tool.

If you're interested in everything that the Google bots can use from your RDFa markup, check out this page on Google Webmaster Tools. Hopefully, my cheese soup recipes will get re-indexed soon and the extra info will show up in the search results. But let's not do this just for Google searches. There's amazing potential here if we annotate all of our web pages with as much RDF as possible. Check out the Dublin Core and Friend of a Friend vocabularies. The Semantic Web will only appear if we build it!

Monday, July 5, 2010

iPhone App Review - Cookie Dozer


Just had to mention this great game I've been playing on my iPhone, Cookie Dozer by Leftover Studios.

Remember those games you'd see in arcades where you have to drop a coin or token in, attempting to position it where it will push a bunch more coins off a ledge? Well this game is the same concept, but with cookies. Yes, that's right. Cookies. The graphics are awesome. You get hungry just looking at it.

The game gets a little more complicated than just pushing cookies over a ledge. Sometimes special foods will appear, like chocolates and pie. If you succeed in knocking those off the ledge as well, you can trade them in for additional cookies when you run low. Get all the treats of a particular type and you'll unlock a special reward, such as having treats appear more often.

The game physics are exceptional. The cookies behave just like you'd expect them to in the real world, if for some crazy reason you actually found a machine like this full of cookies in your local arcade. The graphics are awesome, but the sound effects are a mixed bag. I would say that the cookie falling noises are quite realistic, but the sounds when a treat appears or drops are hackneyed. The game play is addicting, but is very slow at first. Basically, when you run out of cookies you have to wait for what seems like an eternity to let your numbers build up again. While the game is running, you get an additional cookie every 30 seconds. Between play times you earn new cookies at the rate of one every 12 minutes. This will drive you crazy when you run out and all you really want to keep dropping them. I was extremely frustrated, yet I couldn't stop playing anyway.

And the value? Well, the game is FREE! You can't beat that for value. Overall, I give the game a 7 out of 10. I would recommend downloading right now in case they decide to start charging for it!

It's worth mentioning that Cookie Dozer is basically just the edible version of their previous game, Coin Dozer. I like Coin Dozer too, but it still has some bugs (sounds stop working after getting a pop-up from the phone). I'm waiting for an update. Oh, and you can't eat coins. Still, I'd recommend downloading both.


Sunday, July 4, 2010

Easy Web Application Layout with Dojo

Whenever you are writing software, you want to spend most of your time working on the business logic of your application. That is to say, you need to put the work into what makes your application special. I've found that when making web applications, too much wasted time can easily be spent trying to get the layout correct. That's why I love The Dojo Toolkit.

Using Dojo's BorderContainer to do your layout is extremely simple and saves countless hours that you could waste doing it yourself. Let's look at the steps involved.

First, set things up. BorderContainer is actually part of the Dijit Widgets subset of the Dojo Toolkit. The first step in using any of these things is to download and set up Dojo on your web server. See the Dojo website for information on how to do that.

Once you have the Dojo scripts available to use in your pages, consider this simple example.

<html xmlns="http://www.w3.org/1999/xhtml">

<head>
<link rel="stylesheet" type="text/css" href="/dijit/themes/tundra/tundra.css" />
<script type="text/javascript" src="/dojo/dojo.js" djConfig="parseOnLoad: true"></script>
<script type="text/javascript">

dojo.require("dijit.layout.BorderContainer");
dojo.require("dijit.layout.ContentPane");

</script>
</head>

<body class="tundra">

<div dojoType="dijit.layout.BorderContainer" design="sidebar" style="width: 100%; height: 100%;">

<div style="background-color: #FF66FF;" dojoType="dijit.layout.ContentPane" region="top">This is the top pane.</div>

<div style="background-color: #66FFCC;" dojoType="dijit.layout.ContentPane" region="center">This is the center pane.</div>

</div>

</body>

</html>
So what exactly is going on here? Well first, you can see the CSS include. This is just one of the styles that comes with Dojo. You can change this if you want.

Second, you'll notice the script reference for dojo.js. This is the main Dojo library. Every page that uses a Dojo function or widget needs this. The interesting part of the script tag is the djConfig attribute. Since we use inline specification for the widgets (the dojoType attributes on the divs) we want that set to parse on load.

Third, there's the dojo.require stuff. Dojo has a great dynamic feature-set loading capability. Instead of having to explicitly add a script tag for every feature you want to use, you just "require" the stuff you'll be working with on this page. We want to use the BorderContainer and ContentPane, so we have the require lines for them here.

Now we're into the real layout of the page. The outermost div has a dojoType attribute of "dijit.layout.BorderContainer", which basically means that this div is going to be the border container object. When Dojo loads completely, it will parse the HTML of the page and transform this simple div into a complex and awesome layout container for you. Notice also the design attribute. When set to "sidebar" the left and right panes will stretch from the top of the window to the bottom. The other option is "headline", which is the default if no design attribute is specified. In headline mode, the top and bottom panes stretch the entire width of the window and the left and right panes are the same height as the center pane. The style attribute sets the width and height of the container to basically take up the whole window.

Inside the main div, we put the divs that will hold our content. They have the dojoType "dijit.layout.ContentPane" and have a region attribute that specifies where they fit in the container. Content Panes are quite simply just panes for your content. They can contain any HTML or text that you would normally put in a div.

The top pane has the region attribute set to "top". This div can also have a style tag if you want to specify a height for the pane. The center pane has the region attribute set to "center" and should not ever have a width or height specified. It's size will be automatically calculated to fit all the space remaining after every other pane is given its size.

You can see the page in action here.

Hey hold on a minute! In the text above I just had "This is the center pane." as the text for the main pane, but in the example it had a bunch of cool gibberish text. What's going on? Well, the gibberish text is Lorem Ipsum. You've probably seen it in lots of places. We use it so show how something will look with text in it when we don't want the reader to be distracted by what the text says. You can generate your own at this website! I didn't include it in the example code above to save space and to not distract from the code.

The longer text also allows demonstration of how the center pane will have scroll bars automatically appear if the content is too large for the pane.

Now let's make our layout a little more complex by adding side panes.

Place this code inside the border container div, before the top pane:

<div style="background-color: #99FF66;" dojoType="dijit.layout.ContentPane" region="left">This is the left pane.</div>

That will be the left pane. Place this code as the last thing inside the border container div:

<div style="background-color: #FF9966;" dojoType="dijit.layout.ContentPane" region="right">This is the right pane.</div>

Look here to see what we have now.

Pretty easy, huh? Now remember I said earlier that you can specify sizes for any pane except the center. You just use standard CSS styles to do that, and you can use either percentages or pixels. Let's give it a try, and add a bottom pane as well.

Add this code before the div for the right pane. This will be the bottom pane. Notice that it specifies a height of 300 pixels. The middle panes (top, center, and bottom) will have their widths automatically sized so only heights make sense for top and bottom.

<div style="height: 300px; background-color: #66CCFF;" dojoType="dijit.layout.ContentPane" region="bottom">This is the bottom pane.</div>

Change the style attribute on the left and right panes to include "width: 25%". This means that the side panes will take up a combined 50% of the window width, leaving 50% for the top, center, and bottom panes. Resize the window to see the sizes of all the panes change. The left pane should now read like this:

<div style="width: 25%; background-color: #99FF66;" dojoType="dijit.layout.ContentPane" region="left">This is the left pane.</div>

and the right pane should look like this:

<div style="width: 25%; background-color: #FF9966;" dojoType="dijit.layout.ContentPane" region="right">This is the right pane.</div>

Check out the changes here.

But wait, it gets even better! You don't have to make your border container the size of the whole window. You can specify any width and height you want, but more importantly you can nest border containers inside other border containers!

Let's try it by replacing the text in the bottom pane with another border container, itself with left, right, top, and center panes. Replace the text "This is the bottom pane" with the following code:

<div dojoType="dijit.layout.BorderContainer" design="sidebar" style="width: 100%; height: 100%;">

<div style="width: 25%; background-color: #99FF66;" dojoType="dijit.layout.ContentPane" region="left">This is the left pane.</div>

<div style="background-color: #FF66FF;" dojoType="dijit.layout.ContentPane" region="top">This is the top pane.</div>

<div style="background-color: #66FFCC;" dojoType="dijit.layout.ContentPane" region="center">This is the center pane.</div>

<div style="width: 25%; background-color: #FF9966;" dojoType="dijit.layout.ContentPane" region="right">This is the right pane.</div>

</div>

Now have a look at the finished product.

As you can see, doing web application layout can be insanely easy with the help of Dojo. If you want more information on Border Container or any of the other Dojo tools, check out the online documentation here.