One Year Later

[caption id="attachment_930" align="alignright" width="300" caption="Where I've hung my hat this last year"][/caption]

For the last year I've worked as the Director of New Media and Web Development for 614 Media Group. It's a lofty title, meant to inspire all who read my email signature that, "Hey this guy is a bigshot." In reality what I did was much more mundane, I wrote LAMP applications. For the last year I've sat down everyday at this Mac, popped into TextMate, and wrote PHP. I was king of the castle, and being king is good, I got to choose my tools: Mac + TextMate + Git + MAMP + MacGDBp + GitHub + GitHub Issues + Flourish. I got to work on interesting products, if you had told me a year ago that in a year's time I would have written both a Groupon Competitor and a full CMS system, I would have told you that was crazy talk.

Over the last year I have grown as a developer and as a system administrator and as someone trying to get traction for a new product and as a million other hats I got to wear. For the first time in my career I was able to go from concept to "functioning-putting-money-in-the-bank" web application. This is huge. Having been a consultant for years before this job, I spent most of my time maintaining other peoples systems, throwing in a feature here or there, coding up a new report, stuff like that. At 614 I was able to start from nothing, build up a database schema, create the framework and the code, paint it all pretty, launch, iterate, relaunch, iterate, tear my hair out, wake up to fix problems at 3am, curse the server for being slightly different than development, drink more caffeine than any human should drink, but most importantly learn and grow.

With learning and growing in mind, I have an announcement to make, at the end of this month I will be leaving my job at 614 Media Group. I leave on a good note though, the software is stable and quietly humming along bringing in revenue. I am leaving behind a framework with a proven track record, a stable foundation that can be built upon. But most importantly I'm leaving as a friend and supporter of 614, wishing them nothing but the best for the future. 614's curse is that they put a lot of responsibility into your hands and if you are good at it, other people will take notice, and those other people may come in and make you an offer you can't refuse.

[caption id="attachment_935" align="alignleft" width="245" caption="They made me an offer I couldn't refuse"][/caption]

I'm not sure how much I'm allowed to say about the new position, but I will be moving out to the West Coast this month to start a new chapter in my career. For the PHP folks out there, do not worry, I will still be rocking PHP (but also probably rocking some ruby and java as well and anything else they want me to learn). This is a big, stressful, somewhat scary decision to make, but I believe in the company that I will be joining, and after meeting with their people am nothing but excited to work with and learn from them.

Growth and change are good things, they can be painful and stressful and sad sometimes, but the minute you stop growing as a developer you've given up, and I love programming too much to give up. This next month is going to be a blur of packing and moving and unpacking and learning a new area and learning a new codebase and new people and new places. Parts of it will be uncomfortable, parts will be stressful, but overall it will be a learning experience I couldn't get anywhere else, and I wouldn't have it any other way.

Excel and PHP

[caption id="attachment_920" align="alignright" width="380" caption="You got Spreadsheet in my Web App, you got Web App in my Spreadsheet... and it's delicious!"][/caption]

Note: I may seem a bit harsh on Excel, but I actually think it's an amazing piece of technology, I just don't like how people abuse it.

Web development for business people follows a fairly predictable path. Here is a generalized form of it.

1. Business person encounters problem


2. Grabs Excel, Excel being the magic fix for everything


3. Creates abomination of a solution in Excel, it grows too large, concurrency and consistency issues creep in


4. At this point normally a web developer will be brought in to "Make this Excel sheet work on the internets"


5. Work work work work work...


6. Everyone is delighted


7. Hey is there anyway we can dump these value back into Excel?!


8. At some point they will use the dump to create some new spreadsheet, go back to step 3.

Now of course it's not always this bad and normally there are really good reasons to dump things back into Excel, instead of bothering the web developer with a bunch of business analysis, they can dump the data and perform the Excel wizardry they love so much. I actually think this is a good idea, instead of me baking in calculated values or reinventing Averages and Means and all the other cool stuff Excel can already do, I just drop them off some nice raw data and let them have their business fun. They get exactly what they need, I get exactly what I want (less fragile code with less crazy business rules) and everyone is happy.

Now in PHP there are various solutions to dumping out Excel. The first would be the venerable Spreadsheet_Excel_Writer. I've used it before and it works, it's a port of a Perl library called Spreadsheet::WriteExcel, but there are a few drawbacks. The first is that it's a PEAR module, you use PEAR to install it and it brings along all kind of PEAR stuff like PEAR_Exception and the like. The second is that on the homepage for Spreadsheet_Excel_Writer is this very happy message, "Spreadsheet_Excel_Writer is outdated and needs a complete rewrite. If you want to help with this task please get in touch with us. Otherwise we don't recommend this package for new development." So in short, we should avoid Spreadsheet_Excel_Writer.

The next thing you might find in your googling is PHPExcel which writes out OpenXML 2007 files. This is another large and much more well maintained library for working with Excel files. If you need any advanced features I would highly suggest looking into this one.

But I want something simpler than this, I just want to dump some data out. I don't need to have all these bells and whistles. Also I hate the fact that to write out a few cells in most of these Excel Libraries requires the following.

[php]
$objPHPExcel = new PHPExcel();
// Add some data
$objPHPExcel->setActiveSheetIndex(0);
$objPHPExcel->getActiveSheet()->SetCellValue('A1', 'Hello');
$objPHPExcel->getActiveSheet()->SetCellValue('B2', 'world!');
$objPHPExcel->getActiveSheet()->SetCellValue('C1', 'Hello');
$objPHPExcel->getActiveSheet()->SetCellValue('D2', 'world!');
[/php]

The way these libraries work are just, ugh. They are very heavy and when you are just trying to plop some values into a spreadsheet so someone can have at them, they are overkill. I found myself rewriting the same solution again and again, it's a fancy little solution using some pack() magic that I found over here. Here's what a simple little spreadsheet looks like.

[php]
require_once('Excel.php');
$sheet = new Excel('My Awesome Spreadsheet');
$sheet->label('Hello'); //Write out 'Hello'
$sheet->left(); //Move the cursor left
$sheet->label('World'); //Write out 'World'
$sheet->down(); //Move the cursor down
$sheet->home(); //Head as far left as possible
$sheet->number(1337); //We are so 1337
$sheet->send(); //Melt the user's face off
[/php]

This has met my needs and you can find it as a Gist right over here. I wanted an object oriented way to use those functions and I wanted some help in moving the cursor around and some simple sanity checks on things so that I didn't ruin anything. It's got plenty of comments in code and should be pretty simple to pick up. You can write out labels or numbers and you can move the cursor all around, left, right, up, down, top, and home (top being the first row, home being the first column).

For right now this is meeting all my needs and more, I've recently been playing around with the fact that Excel will happily turn HTML Tables into Spreadsheets, I've got a library cooking for this but have been playing around with some interesting ideas for styling and other advanced features. Until then hopefully this will help any PHP programmer who just wants to dump out some data without going into dependency hell.

Happy Coding

Get my handy dandy Excel Writer here

Form Generator for Flourish

[caption id="attachment_892" align="alignright" width="300" caption="Machines are complicated, so is software"][/caption]

A while back I saw a post in the Flourish discussion boards requesting a Form Generation system, see here. The short discussion that follows basically argues that form generation is too subjective and although it may at some point be added to Flourish it won't be anytime soon. I work in Flourish all day, everyday, and I love every minute of it. I'm probably beating a dead horse at this point, but Flourish really is just a tremendously solid core to build off of. Working with Flourish so much and finding myself performing the same form mark-up again and again, I've given some serious thought to building a Form Generation system and have been using a prototype system for a week or two. Having built a working Form Generation system and used it for a while I want to talk about the good, the bad, and the ugly.

The Good

As a programmer there is nothing more frustrating than finding a library or an API you want to use and having it just be an absolute nightmare to integrate with. I spend a lot of time, ever since Prosper, thinking very hard about how to provide great APIs that make people want to use my software. After a lot of thought about how to go about building a Form Generator library, I've come to what I think is the right balance. The ideal API should fit well with the Flourish way of doing things, be flexible, powerful, expressive, and extensible. So without any further bloviating, here is my proposed syntax, in this example I will use a simple sign-in form.

[php]
echo fForm::post()
->add(fForm::text('Username'))
->add(fForm::password('Password'))
->add(fForm::submit('Sign In'));
[/php]

This would produce the following output

[html]
<form action="http://the/current/url/" method="post">
<label for="username">Username</label>
<input type="text" id="username" name="username" />
<br>
<label for="password">Password</label>
<input type="password" id="password" name="password" />
<br>
<input type="submit" id="sign_in" name="sign_in" value="Sign In" />
</form>
[/html]

The API is fluid, simple, and concise. It follows the Flourish style and uses fGrammar::underscorize() to turn labels into ids. It produces clean simple markup and doesn't mangle any ids, allowing for JavaScript to be easily attached. As far as the API goes, I'm really quite happy. The other powerful thing this allows you to do is tightly integrate your Form Generation with value repopulation, for automatically refilling in values when an error occurs. With this tight integration I've been able to create a prototype system that automatically repopulates across posts when an error occurs, can use an existing fActiveRecord instance as a seed to make editing amazingly easy, and display beautiful inline errors on the form.

The Bad

Having used the prototype for a while I can say it's not all great. Simple CRUD style forms are incredibly easy to mock up, having error values persist automatically is really nice, and having inline error message (especially those from fActiveRecord::validate()) work with little fuss has been a huge speed boost. I can knock out simple pages in a fraction of the time. The problem comes when I want to do some edge case, PHP's greatest strength is easily outputting whatever markup you want, by introducing this layer of indirection you give up this inherent strength for whiz-bang features. It's still incredibly easy to output whatever markup you like, but the disparity between the automatic features the fForm library gives you and your own simple markup is stark and will bewilder a normal user. The problem here isn't that fForm lacks power, it's that it imbues certain elements with too many features and makes creating a one off element prohibitively expensive.

The Ugly

The architecture that worked best for implementing the prototype was a tangled mess of inheritance, and no matter how much I tried to refactor I still haven't found an inheritance graph that I find acceptable. Using my prototype has considerably cut down on development time, but the amount of memory used holding a object graph in memory to represent complex forms is a trade-off. The API has several inconsistencies that bother me, but don't really impact the performance or usability of the library.

The Future

So where to go from here? That's the question I keep coming back to. I want to introduce a layer between object graph and view, this way a plugin system can be used to change the rendering of elements and the form itself in a fundamental way. As soon as possible I plan on releasing a clean room open source version of the fForm library for use with Flourish on GitHub. I believe I've come up with a way to make an easily extensible widget system, now I just need to get something out the door. I will release it with my alpha framework, Rigby, in the coming weeks. Comments, and of course forks, are welcome. I will release some screencasts about how to use Rigby once I get it into a stable state. Stay Tuned!

Second System

[caption id="attachment_883" align="alignright" width="300" caption="Just a little more to the left...."][/caption]

I've been working, both on the job and as a freelancer, right now my 9-5 is starting to enter that ever so exciting phase where one project enters maintenance mode and another project starts to spin up. The new project starting to spin up is to rewrite the CMS system that powers our various publication websites. Now for those of you not in the know, a CMS system is crazy complicated. I'm writing this current blogpost in a very specialized CMS system called WordPress, just for blogging. This software probably has had somewhere upwards of eleventy-billion man hours go into it (once you factor in themes and plugins and all that jazz).

Of course whenever you are faced with a complex problem that's been solved to death your best bet is to look around and see if anyone has done the heavy lifting for you already. So I started looking around, WordPress, Joomla, Drupal, all mature PHP CMS systems, none that I'm familiar with even a little. I started reading, out of the three I ended up liking Drupal the best, it seems well engineered, flexible, and very stable. I read and read and read about nodes and the way Drupal thinks about content and I started to think, ok maybe we can use this. The problem is that management is used to a level a flexibility that I won't have with Drupal for months, maybe even years. They want this flexibility from the beginning and that was making using Drupal seem less and less likely. Then some requirements filtered in and out and it looks like a custom solution is going to be best... c'est la vie.

Now this is in no way a slight against Drupal or Joomla or any other CMS system out there, I'm sure in the hands of Drupal Ninja or Joomla Gurus this would be easy as pie. For me though, building a solid system on my time tested and well worn toolbox of PHP, SQL, and Flourish will probably be the best way to deal with the constantly changing features and requirements that we need to support. Now I'm going to start building, start sketching out how things will work, how data will be thought of in the system, user models, documents, revisions, all kinds of fun stuff. It's a bit intimidating, but as a Software Developer this is really the stuff I live for, big gnarly problem, blank TextMate buffer, well known tools, get cracking.

The big problem I'm fighting right now is the dreaded Second-system effect. Watch out for this my dear friends, it's not a nice trap to get caught in. It works a little something like this.

1. Build a system, this is the First-system, it works, celebrate and have a shot of Jack.


2. That stupid "real world" comes in and messes up your data model, you add a little hack to compensate.


3. Oh, it has to be able to do what? No, you said it didn't have to do that!! Fine, hack hack hack.


4. Maybe some cleanup, probably some more hacking and bending.


5. You've tried your best to keep First-system shiny and new, but the shine's off the apple.


6. Crazy requirement, requires rewriting huge parts of the system, oh noes!


7. Alright, now that we know so much more let's build Second-system.

Herein lies the danger. You get the go ahead to build Second-system, and you have all this experience from First-system, you really think you understand the problem domain a lot better, so far so good. Here's where things get hairy though, you start thinking about how you would build the system so that you don't run into the same problem First-system had, you start abstracting and abstracting, it gets more and more complicated, but you are now a master in this domain, you can handle it. Users who have been frustrated for months or years using First-system start throwing in their advice, things that have always bugged them, their nice-to-haves, and hell, you haven't built anything yet, chuck that automated-frog-boiler in your system plan.

Before you know it you've got a beautiful masterpiece, it handles everything, all the problems encountered in the First-system, all the nice-to-haves, everything, it is a theoretical thing of beauty. Now all you need is 6 maybe 7 years to build it.... oh shit. But there's something even more wrong about the Second-system, it has buried in it a dirty lie, that you understand the problem domain. You probably have a pretty good understanding of the problem domain, as it stands right now. Having already tackled this problem once does not make you clairvoyant, there will be changes to the system and your system will have to adapt to those new realities. This compounds the Second-system effect, because your Second-system is almost inevitably more complicated than the First-system and therefore harder to change and bend and make work in that pesky "real-world."

Right now I have to fight the urge to over-engineer, to outwit this problem, because I'm just not smart enough to solve this problem forever and ever into the future. So I'm going to focus on building a solid platform that let's me build out modules and snap them off when they aren't needed anymore. Something robust but simpler than the current system. Doing this will mean trading things off, it will mean making hard decisions upfront about architecture to meet our current needs but also look to the future, and this is what a good Software Developer is supposed to do. And once my current project is safely resting in maintenance mode, quietly humming along making my company money, I will begin building a Second-system and hopefully avoid Second-system effect.

ipad

[caption id="attachment_649" align="alignright" width="300" caption="nerd law also required I use a picture with Spock in it"][/caption]

As required by nerd law, here is my mandatory post on the iPad. I've got lots of nerd friend and the general feeling I get from them is a sigh and a "meh." The term "underwhelmed" is being thrown around a lot, reinvigorating the debate as to whether or not there is a perfect amount of "whelmed" one can be so as to be neither under- nor over- whelmed. Here is my take on the new shiny.

Let's not forget our history. When the iPhone came out people far and wide declared that it will fail, is failing, already failed. Yet despite such serious problems as no cut-and-paste and a weird virtual keyboard, somehow it won Time's gadget of the year award, and a huge population of happy iPhone users. People to this day don't quite get it, I have an Android phone (one of the first G1s) and I love it, but there is no denying the sexiness and sleekness of an iPhone. If you don't understand the big deal play with one for a week, its just a completely polished user experience.

That is the strength of Apple's products, the experience. Its easy to find plenty of small, reliable mp3 players that store tons of music, people buy iPods because they are seamless and easy. I was asked recently what made OSX superior to Win7, I didn't have an answer, I work with both and I enjoy OSX much more but have no real good bullet point for why. I was looking for some big reason, oh the dock, oh it's pretty, oh the finder, but couldn't think of any quantitative reason why they were better. When it came down to it, there are just a million little reasons that all add up to a great experience.

To each their own though, I don't want to start a Windows vs. Mac flamewar, there are plenty out there if you feel the need just type "I hate Windows" or "I hate Mac" into google if you must. The point I want to make is that Apple thinks about their products from a full end-to-end experience, and that's where something like an iPad could beat the pants off of a netbook. Make no mistake about this either, that is where they are targeting, Jobs said it in the keynote and the pricepoint confirms it. iPad is not meant to compete with MacBooks or Dell D830s (the computer I'm currently typing on) they are meant to compete with Dell Inspiron Minis and eee PCs

There is a niche market out there and I think Apple has the marketing and business savvy necessary to corner it. With all the hype it would have been difficult to not be underwhelmed. It doesn't cure cancer or come with a free pony, boohoo!

Now I'm going to take my life into my own hands here and make a prediction (watch out!) The iPad will succeed, it will have a spreading pattern to certain niches until it picks up a critical mass and people who don't really need them start to buy them. First the early-adopter and mac-fanboys will start buying them up, then there will be some app that endears it to some group of people in a fierce way. Maybe a text-book app or medical records app, whatever it is there will be some population that is in love with the iPad. They will start to infect their friends and family with iPad fever and it will become hip and cool, then it will become annoying, and then it will just be fact, 30 jillion people have iPads and you won't be able to walk into a Starbucks without someone reading Hipster monthly on one.

I'm excited about the iPad, it doesn't have everything I always wanted, but it will definitely move the ball forward. I personally think the very slightly modified iPhone OS was a mistake, I think there are lots of mistakes and things that I wished were included (like that pony I really wanted). But I'm going to have to reserve judgment until I ca go down to the Best Buy and screw around with one.

api

[caption id="attachment_618" align="alignright" width="142" caption="oh creator of hot pockets, we praise thee!"][/caption]

I remember being a young lad preparing myself for university I was given a gift from my mother, "C++ for dummies." The vote of confidence on my status as a "dummy" aside, I read the book with great interest. There was an analogy the author used to explain the idea of classes and what functions they should expose, I'm going to shamelessly steal it (paraphrasing as I don't have the book with me).

Imagine your son comes up to you and says he wants to make some nachos. You tell him that its fine by you, just go cook them in the microwave, and there is nothing controversial about this statement. Microwaves are actually boxes full of high energy radiation being produced by cavity magnetrons or waveguides, to the end user, the microwave is just a magic warming box. It exposes a very simple interface, some buttons that allow you to enter the amount of time you want to cook something.

This is the essence of an API (Application Programming Interface), wrapping up something complex and possibly dangerous in something safe and easy to interact with. When building code that you intend other people to use someday, it is the part that is most important part, and the part that is easiest to overlook. The problem is that we are often too close to something and too concerned with our use case. If you want to design code for others to use, it requires significant time and effort, and even then you probably still won't get it right.

Prosper is still undergoing active development, I'm currently agonizing over how I want to expose various execution modes. The solution, no matter what I pick, is trivial to implement, but the api is the most important part. A great api exposes a consistent concept, something that is easily grasped and allows the end user of the api to declare what they want to do without having to worry about how its going to get done. Since good programmers write good code and great programmers steal great code, I've modeled the api for prosper extensively off of jQuery. And why not, let's take a look at two different APIs, the browser dom api and jquery.

[javascript]
//Let's barber pole a list by coloring every other element blue
var list = document.getElementById('the_list');
var highlight = false;
for(var i = 0; i < list.children.length; i++) {
if(highlight) {
list.children[i].style['backgroundColor'] = '#FF0000';
}
highlight = !highlight;
}
[/javascript]

Fairly straightforward implementation, but it concerns itself heavily with the "how" of what its doing. Manually traversing to pick the elements it wants, eww.

[javascript]
//Same thing using jquery
$("ul#the_list li:odd").css("background-color", "#FF0000");
[/javascript]

jQuery is definitely magic, but this code is great because it let's you focus on the "what" of what you are doing. How does jQuery go about selecting the right elements and all that? I don't care, and the great thing is I don't have to care, and if in the next version of jQuery they find a way to do it faster, I win without having to do anything.

Writing a great api is difficult, you have to divorce yourself from the concrete problem you are solving and look at it in the abstract. Put yourself into the shoes of someone trying to figure out how the api works, and then ask the questions they are going to ask.

• Why do I need to build up this context thing and pass it in?


• How come there isn't a sensible default for these arguments?


• What dumbass made this thing?

Answer those questions, and keep working at it, strive for elegance and consistency, because then it will be easy for people to learn and use. If your code is easy to learn and use, people are going to want to use it more, and they are going to want to tell their friends about it. Then you can get some lucrative ad campaigns with Nike because of the boffo library you write in FoxPro.

There is a more subtle lesson in all of this though. Any code you write is exposing an api to someone else. "But only I am ever going to use this code!" I hear the naysayers warming up their keyboards for the comments section. This may be true now, but the six-months-from-now-you is going to look back at the you-of-today and wonder what the hell he was thinking.

Get in the habit of making your code easy to use, and expose a nice api. This will endear you to your fellow programmers and help make maintenance easy. Strive to be that guy on the team that writes functions and classes people want to use. Make life easier for your fellow developers and even if they don't return the favor, maybe they will take you out for a beer. People notice over time that your code is the best to work with, they internalize it, and they start to think of you as a great programmer. That's a pretty great api to expose to the world.

shiny new toy

[caption id="attachment_389" align="alignright" width="214" caption="it cuts the roof of your mouth so the chemicals can get into your bloodstream faster"][/caption]

I took a half-day today, got to sit at home this morning waiting for the Fedex man (who turned out to be a woman). A few weeks ago I got the go ahead from my company to buy an iMac for home (HMB has a program where they will pay for half of your hardware purchase, because they are an amazing company). I got the news yesterday via fedex that my package had arrived overnight from Shanghai in beautiful Anchorage. I was told that the delivery would arrive this morning, asked for a half-day off, and this morning leisurely enjoyed a bowl of Peanut Butter Crunch.

Then I heard the thump thump thump of someone climbing the stairs outside of my apartment and a knock on my door. After subduing my dog Harvey I opened the door, signed the Fedex pad, and took a giant heavy package inside my house. The size of the box blew me away at first, here are the specs of my new iMac.

• 27in Aluminum iMac


• 2.8GHz Quad Core Intel Core i7


• 8GB 1066MHz DDR3 SDRAM


• 1TB Serial ATA Drive


• ATI Radeon HD 4850 512MB Video Card


• 8x double-layer SuperDrive


• Magic Mouse


• Wireless Keyboard

Now I have played with Macs before, I've spent countless minutes over the last month or two at BestBuy goofing around with the 27in iMac there. I thought I was prepared for how large this beast is, but I was not. It's a heavy machine and it is ginormous. The packaging was simple, effective, and beautiful. I had it up and running in about 10 minutes, and most of that time was moving stuff off my desk to make room. A little while back I had purchased a cheap opened-item (although very nice) 22in Velocity Micro Monitor (similar to this one but not identical). When I brought it home I thought it was huge, it looks Lilliputian next to this hulking behemoth.

There have been some reports of the i7 showing up DOA. I'm lucky enough to have not had this happen, my iMac is pretty and working. I turned on the power, answered some questions, and watching "Welcome" fly at my face in multiple languages for a few minutes, and it was up and running.

The Good

• This screen is huge and beautiful, plenty of real estate to take on the job of 2 (maybe even 3) physical monitors


• The wireless keyboard and mighty mouse were pre-synced with the computer and worked right off the bat


• The Apple Remote synced nicely (after I reread the syncing part of the manual and saw the phrase "menu and right button" instead of just "right button")


• I can now retire my Acer tower to be a HTPC (It's a little big but I have a cabinet it will fit nicely in)


• The wireless keyboard is a joy to type on


• Opened a terminal and typed ruby --version, it replied with 1.8.7 instead of " 'ruby' is not recognized as an internal or external command, operable program or batch file."
  

The Bad

• After syncing my remote I couldn't get it to do anything, I tried controlling a DVD with it to no avail.


• I only took a half day instead of the whole day off so I can't play with its beauty right now


• I took some great pictures with my phone, but foolishly left behind my usb cable, a gallery will be posted tonight or sometime over the weekend


• I don't know what I'm doing. This is the first Mac I've owned and so far things seem simple enough, but I'm not at home yet.

There you have it, about 2 years of thinking about buying a new iMac, a few weeks of waiting, and 4 hours off of work later I have my new shiny toy. It is a work of beauty and really a testament to the skill and care the engineers and designers at Apple put into their products. I'm hoping to avoid fanboyism though, I will be running a Vista / Ubuntu powered HTPC and working on an XP Pro laptop everyday for work.

This weekend I will get better introduced to the new member of my tech family, for now though I have to get back to work. Check in Monday for shiny pictures. I hope to do a bunch of how-to's and screencasts in the future about development on macs and setting things up if you are a developer, so stay tuned.

---

PS. I have changed the RSS Feed to use FeedBurner, if you experience any problems please let me know at ihumanable [at] gmail [dot] com

solve it forever

[caption id="attachment_277" align="alignright" width="200" caption="having a bully day"][/caption]

This is a very simple rule that I have for solving problems at work, solve them forever. Its not always practical and sometimes you need to bend the rule, but its a great guideline. When I'm presented with a problem at work, I take it as a personal insult, someone could have solved this before and made my life easier but they chose not to and burdened me with it, and I refuse to do that to anyone else.

This has some downsides, you have to put in a lot of effort, and sometimes little things take a lot longer than the "man" thinks they should. There are some upsides though, you avoid technical debt. A lot of coverage has been given recently to the idea of technical debt, how you define it, how you avoid it, should you avoid it and so on. It is one of those nebulous concepts that everyone has a different definition for, we all know what it feels like to run up against some technical debt, its that situation where something that should be simple is needlessly difficult.

Technical debt is not complexity, sometimes doing seemingly simple things within a complex system can be cumbersome, but that's the price you pay for some other benefit (dynamic forms, automatic mapping, etc.) You know that you've hit some technical debt when something is complicated and difficult, but there is no upside.

Boss: Change the text on that button
Dev: Ok, I'll just update the html
...several hours later...
Boss: Why'd that take so long?
Dev: You see that text is pulled from an i18l file, which is populated dynamically by a database table, that table is autorouted by the orm layer, so I had to change a bunch of configuration entries, then I had to run an update across several tables, some tables were using the name as a foreign key relationship, even though they didn't declare that formally to the rdbms, so I had to go track down what tables were doing that, and once all that was through I had accidently made a typo and had to go through the whole damn process again.

Debt like this is incurred when you solve a problem for now, not thinking about the future. Solving a problem forever means that as long as the problem domain remains the same that you don't have to do anything. The issue is that many people misinterpret solving a problem forever as solving all problems forever, and that is not what I wish to promote.

There is an important difference, you should solve the problem domain thoroughly, but your solution should be specific to that domain, don't try to do too much. There are innumerable problems that someone will take the time to solve for themselves, but give no thought to what happens to the next guy. Coming onto a new project I've come face to face with an age old developer problem, rolling on.

Rolling onto a new project is often an exercise in navigating technology to set up a development environment, navigating the corporation to integrate yourself into it, and navigating the team to find a place. All this navigation seems to be on the shoulders of the new person, there are people you need to talk to to get mainframe access. Which people? Where are they? When do I talk to them? How? There are often answers locked up inside someone's brain, and if you ask the right people you can, like a detective slowly unraveling a mystery, find the answers and get your email and passwords and id badges.

This is a problem that should be solved forever, once the first guy joined the team he should have documented what he did, when, how, why, and that document should be part of team cannon, available as a helpful guide to the next new guy. This rarely happens though, it is a shame, but understandable, new people are struggling to get up to speed on a project they don't have time for the meta-project of documenting their up-to-speed-getting project.

That is just an example, the next time you are guts deep in a problem that you've encountered before think about your fellow developer, and think about how you can solve it forever. The more problems you permanently put to bed, the smoother development can go and the faster you can get your project done.

baggage

[caption id="attachment_265" align="alignleft" width="300" caption="i know how you feel"][/caption]

Finally! I am finally about to start working at my new project after all those squishy human beings got done drawing pretty charts and signing dead pieces of trees. I now can put myself into the beautiful cold clutches of the machine again and get back to what I do best, code stuff. I'll be moving from .Net web development to Java middle ware development, and I'm excited to get back to programming.

That seemed like quite the dig at .Net, I don't intend it to, it's just been my personal experience. The problem with the .Net projects I've worked on is that they've been amalgams of third party libraries, and I've been in charge of gluing them together. This isn't a weakness, some would say its a great strength, drop some cash and boom, big problem solved by a nice clean little dll (or 4). I will say that it greatly reduces time to market which is a Good Thing© and that it lets you get down to the customizations that clients spend the big bucks on.

The problem is that I'm a programmer, not a customizer. I like to write code, not tweak little settings here or there (although as a nerd I'm a fan of that as well). The .Net environment always seemed like a bunch of black boxes that I was just trying to lash together in a pretty enough package to call it done. Any actual code I wrote was always just taking business rules and turning them into something a computer can understand. That's ok, in fact companies make a lot of money doing this type of work, I just don't as a programmer feel fulfilled by it.

Now though I'm heading into a project where there is a problem without a solution, something that actually needs to be designed, implemented, tested, deployed, iterated, and other fun nerd words. I'm excited to be back to programming, but I'm worried about technological baggage. What is technological baggage you ask, let me find you an example (anonymized, of course).

[javascript]
function Recalculate(...)
{
if (isNaN(CleanNumber(ctrl.value)) ||
CleanNumber(ctrl.value) == "")
{
ctrl.value = "0";
}

var newValue = parseFloat(CleanNumber(ctrl.value));
var oldValue = parseFloat(CleanNumber(prevCtrl.value));
var diff = newValue - oldValue;

ctrl.value = newValue;
prevCtrl.value = parseFloat(CleanNumber(changedPrevControl.value))
+ diff;

//Snip some similar code
FormatMoneyWithCommas(ctrl, 0, 0, 0);
}
[/javascript]

There is nothing wrong with the above javascript it works just fine. But look at it, that's .Net wrapped in script tags if I've ever seen it. There are many non-javascript things going on in this code, anyone familiar with javascript will see them straight away. My intent is not to shame the author of the code or to call it out as bad javascript, it is merely to show that when steeped in a technology it can be very hard to pull yourself out. I picked on .Net but I've see plenty of javascript written like java, in fact I've gotten actual java code thrown between script tags back from offshore "resources" before.

There is a lot to keep jumbled up in our heads when we are programming, to lessen this burden we adopt naming conventions, and calling conventions, and all kinds of conventions and that is a good thing. The bad thing is carrying your languages conventions into other languages, its a kind of linguistic egocentricity that makes the natives upset.

Now I am trying to purge the .Net from my fingers and get them ready for Java again. I'm sure I won't remember all the little gotchas, but the important part is to be aware. There are some basic strategies for carrying over as little baggage as possible.

• Google - Go and google Language X for Language Y developers, Language X and Langauge Y can be almost any combination of languages and there is a good chance someone wrote an article, feature matrix, common pitfalls type document for it.


• When in Rome - If you are going into an established project, adopt its idioms.


• Tutorials - Even if you know the language you are heading into, go read a few tutorials, brush up on the basics

I remember the painful period between Java and .Net, being frustrated trying to figure out what the hell a HashMap was called (Dictionary) or wanting to declare what my functions throw. I'm sure I will have the reverse, but the one thing I'm looking forward to is getting back to Eclipse, I love Eclipse, and I will not miss Visual Studio at all.

leaving

[caption id="attachment_92" align="alignright" width="300" caption="leaving for somewhere"][/caption]

I've been working on a project for the last 5 months, but finished active development about a month ago. I finished in the best possible way, the product shipped, the customer likes it, and there hasn't been much to do besides the minor bug or feature here and there. It's a good place to be in, since I'm a consultant it's also not economically viable. If I'm just sitting here writing blog posts and drinking smooth delicious Diet Dr. Pepper all day, I'm not making money for my company, so they went and found me another project to work on, which I talked about here.

I'm looking forward to starting my new project, but as Semisonic taught us, "every new beginning comes from some other beginning's end." (Have to try to pull this post out of the tailspin caused by quoting Semisonic lyrics now). The problem is that when you start a new project, the glitz and glamor of a new project you haven't learned to hate yet can blind you from the responsibilities of being the guy leaving.

Leaving a project comes bundled up with a bunch of responsibilities. The cliched, "what if you got hit by a bus tomorrow?" question that managers love to ask (because they are too afraid to say, "what if you quit" or "what if I fire you" but oddly enough have no qualms with theoretically knocking you off) actually has some value. The "bus" of leaving this project is barreling down at me, and I have to make sure I dump enough of my brain out that people can still maintain the code I wrote.

If you read my rant / guide to project documentation, here's a chance for me to prove myself. Throughout the project I've dutifully created and more or less kept documentation up-to-date about everything from server credentials to step-by-step deployment procedures. I cannot recommend this approach enough, after reading through some of my wiki pages on these topics it is clear that trying to compile this information after the fact would be difficult if not impossible. So since, ostensibly, everything is done already, what am I left to do?

1. Read through documentation - Projects move fast, things that made sense a month into a project probably won't make sense 5 months into a project, be sure everything is up to date. Read the documentation with the mindset that you are trying to start working on a project, is it clear, could you set up a development environment, fix a bug, and push out your changes in a day? If not, figure out why not, and fix it.


2. Bug your coworkers - Someone will be around to work on the project, start bugging them to read the documentation, have them go through a dry run of some complex task you normally do, and let them mock your ability to document things properly. It is much easier to have a minute or two of verbal in-person explanation then trying to remember how things work and having a 20 email long thread of questions and answer a few weeks into your new project.


3. Clean house - Those tasks you were putting off doing, get those done, and for fsm's sake, do it right! There is nothing worse than being knee-deep in a new project to have a past project rear its ugly head, forcing you to dredge up long forgotten knowledge to fix some minor issue.


4. Cut ties - Clients and other developers get used to coming to you with issues, if you are moving on to a new project, let them know about it. Inform them that you will no longer be the contact for the garthok narfler and that they can talk to developer x about it from now on. For an extra touch of class let them know that it was nice working with them.

The way you leave a project is almost as important as the work you did on the project. Rest assured no matter how good a job you think you did, a few weeks after you leave, other developers will be cursing your name. Your job as you leave is to make sure that those angry expletives are few and far between and that you can rub it in their face when they complain about this problem or that obstacle with the fact that you left them very clear documentation on how to handle such a situation.

workflows and rough edges

I've got this new blog now, and I have to say that I'm a huge fan of WordPress, they definitely have created a great piece of software here. I'm going to split this blog post in two, half for my programming diatribe about workflows and the other half for some rough edges commentary about my new blog.

workflows

The idea of a workflow is central to software development, on a simple project your workflow might be

1. Type up some code


2. Compile or run the interpretter

This can get more complicated, here is a standard workflow with some sort of version control software in the middle

1. Type up some code


2. Build


3. If broken go to step 1, else go to step 4


4. Check-in changes


5. If necessary merge changes with server

It can get more complicated even still with test driven development.

1. Write up a test, make sure it fails


2. Write code until test passes


3. ...same as above

And when office bureaucracy get involved.

1. Write up test, make sure it fails


2. Write code until test passes


3. Perform necessary QA testing and UA testing


4. Submit changes for Code Review and Architecture Board Approval


5. Deploy changes to production environments


6. Monitor health of production


7. Pray nothing goes wrong, if it does, prepare for more reviews and meetings

[caption id="attachment_35" align="alignright" width="300" caption="flow"][/caption]
The job of a programmer is to program, the "Write Code" part of all the lists above, the job of a software developer is to be able to do that and navigate the lists of bureaucracies and procedures necessary to get their code into the user's hands. Now I'm not a bash the process person, source control, unit tests, and peer-review are all great ideas and serve necessary purposes. The great thing is that we are humans and our brains are amazing at internalizing these kinds of tasks and making them second nature.

There have been many times when I have been asked to document a process I've performed hundreds of times, only to sit there blankly looking at my empty word document, silently thinking to myself, "How do I deploy to production?" Normally I then do a dry run through the task, observing the stranger that takes over my body and knows how to do a production deploy. He works quickly clicking this or that, as I furiously document the procedure, he knows all of my passwords, even knows when to stop to ask me a pertinent question or two, but more or less he effortlessly autopilots his way through. I'll look at the documentation I've taken of the steps I just performed and sometimes the list is staggering, 23 steps, wow! In my head it is just 1 thing, do the deployment.

I don't currently have a major project that I'm assigned to, so I've been relegated to working on several smaller projects, none to complicated, the only problem is that I don't have the workflows down yet. This cause a major problem because there is a psychological theory of flow that states

Flow is the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity.

None of the new tasks I have are difficult, on the whole they are very easy, but the fact that I can't get into a flow state means that I'm less productive than I normally am, and it is a little bit frustrating. This is why we dislike changing gears, this is why when someone distracts you even for a moment it can be dreadfully annoying, because getting back into that state of focus can be incredibly difficult. The new tasks I'm on are constantly pulling me out of the flow, I have to stop and think about how to get my code into this repository or that, what was the password again, where is the remote test environment, ugh.

When starting a new project or when documenting an existing project one of the most important first things to do is to set up your workflow. I'm going to have my source code right here (points at directory), and I'm going to edit it with this program right here (points at program), and when I've made a change I'm going to see if that worked by doing xyz, and when it works I'm going to submit my changes by doing abc. It seems like a stupid thing to do, you can easily figure out from one step to the next what you should do, but explicitly defining it in your mind will help you stay in the flow.

rough edges

New blog means spending some time making it feel like home. Here are some rough edges you will notice for a while until I get everything set up nicely again.

• In article links may link to the old ihumanable.blogspot.com version of an article instead of the new ihumanable.com version


• Syntax Highlighting is broken in many posts


• JavaScript is being escaped and so some posts that rely on JavaScript don't function properly


• The import process changed all my tags into categories, which feels wrong


• The css is the shine theme default, it needs to be tweaked to my liking


• The navigation on the blog isn't as nice as it used to be


• ihumanable.com redirects to ihumanable.com/blog/ which takes a noticeable second, I'm planning on putting a home page there that will also have links to software projects and other stuff I think is worthwhile


• Still need to learn the ins and outs and workflow (see above) of WordPress

The move was fairly painless but there might be some wonkiness for the next week or so, I hope to get some time over the next few days to clean up links, fix the scripts, and restyle some stuff, so bear with me.

If you have any suggestions or comments about the new blog now is your time to act, since I'll be doing work already, your suggestions might actually get implemented instead of just thrown down the memory hole like I normally do.

new site

I've finally gotten around to registering a domain and setting up my own website, you are currently looking at it. There are some rough edges that need to be smoothed over, but WordPress made the process incredibly simple and painless.

I will be working on this new blog's theme and content over the coming week or two to get it pretty and personal. So if you enjoyed my daily rants and ramblings over at ihumanable.blogspot.com all you have to do now is drop the blogspot, ihumanable has gone legit.

of mice and men

My birthday is coming up Novemeber 14th, *wink* *wink*, and the one gift I've been angling for is a Das Keyboard because I like clicky keyboards. Growing up I had a classic IBM Model-M, the original clicky keyboard. I'm not sure why I like the clicky keyboard, it's mostly in my head I'm sure, I feel more productive if I'm making a tremendous amount of noise I guess... maybe that's why I talk so much.

What it comes down to though is feedback. Computers are these amazingly pliable machines, I can play a game of solitaire, balance my checkbook, and write a blog post all on the same machine. It's one of those amazing things that has sadly become commonplace, so much so that we barely think anything about it anymore. This is sad because it's kind of a big deal, take a modern computer back in time 100 years and watch people flip out.

We often think about the User Interface that we see on the screen, but rarely do we consider the Physical Interface that we have with the computer itself, mainly the keyboard and mouse. There is one company though that continues to push the envelope, Apple. Look at their new Magic Mouse, think that chiclet style keyboards are neat, Apple did it first, multitouch you're welcome. This is not an Apple lovefest (all evidence to the contrary), their products work really nicely but that's not the point, they spur others to innovate as well, that's the important part.

So suddenly there is a resurgence in thinking about how we physically interact with computers, look what Microsoft is doing. There is a cornucopia of rumors flying around about a speculative Apple Tablet. And this means really cool interesting gadgets and ideas are now getting the funding to take them from scribbles on a napkin to sketches on a whiteboard to mockup videos to prototypes and then maybe if they hold out to market.

Then I encountered a video a few weeks ago that was so brilliant, so full of potential, that I just wanted to learn as much as possible about it, 10/GUI. Don't take my word for it, check this thing out.

10/GUI from C. Miller on Vimeo.

Pretty neat, huh? There are definitely things some people might not like or want to change, but it is an intriguing idea. With proper funding and research it could turn into something awesome. The problem is that you still have to transition between a 10/GUI touch surface and a keyboard, not a huge deal, but once I saw this my mind was set ablaze with visions of a seamless 10/GUI interface. If you don't want to read that whole page, here is the important part.

The described system in the patent application would individually detect all ten fingers and separate palms on a person's hand, giving the ability to type, write, draw and interact with a device large enough to support multiple hands.

...
Typing is a large part of the lengthy application. The document goes into great detail about how a multi-touch interface could distinguish what keys a set of hands intend to type on the surface. It discusses pressure on the sides or center of individual fingers and palms, and how to interpret those various signals.

The major problem to overcome is feedback, a system that automatically tracks your palms and places the keys under it could allow for touch typing, but as someone who types all day, I don't know if it could work without feedback. This is what they said about the iPhone onscreen soft keyboard, but reports are that people can type anywhere from 40-60 wpm after adjusting.

I'm not sure what the future of the Physical Interface between the user and computer will be, but its definitely an interesting thing to ponder about. Will we have a minority report like 3D interface or a neat 10/GUI pad or the tried and true keyboard and mouse or something that hasn't made it off the scribbled on a napkin phase yet. It sure will be exciting to find out though.

I plan on moving this blog to my own domain over the weekend, but never fear I will keep everyone informed on the move and where you can always get your daily dose of my crazyness

orm and sql

I've been working on a side project in earnest lately. It's all kinds of PHP fun and I'm enjoying learning the ins and outs of PHP 5.3 as well as relearning some of the stuff I already knew about from my PHP glory days. I've been looking at various different ORM solutions to use with my project and I'd like to take some time to review them, explain why I chose none of them, and what I'm doing instead. For the non-technical in the audience, ORM stands for Object-Relational Mapper, its a piece of software that allows you to save parts of your program to and load them back from a database, supposedly quickly and easily.

• Doctrine
  Doctrine is the 800-pound gorilla of PHP ORM solutions, it has it all, and then some. It is an ORM sitting on top of a DBAL (Database Abstraction Layer) which leverages its own query language DQL (Doctrine Query Language). It can be configured in any number of ways, supports all kinds of backends, is mature, stable, and feature rich. That's all the good of Doctrine, the bad is the learning curve. The manual for Doctrine is 30 sections long, each section is quite a bit to take in. This is great if you are doing an enterprise level program, but for my project Doctrine was overkill.


• Flourish Lib
  This is not an ORM solution, although it does contain one. Flourish is an unframework, and a really, really good one at that. If you want to shut someone up who says you can't write good code in PHP, send them to Flourish, the creator Will Bond did a tremendous job with this unframework, and I still plan on using large parts of it. The ORM layer is actually really nice, there is a bit of a learning curve, and at the end of the day I decided that it did too much and polluted my models too much. Flourish though is definitely worth learning, the website also has great best practices to follow if you are building a PHP Web Application.


• php.activerecord
  Based off of the widely successful Ruby on Rails ActiveRecord class, this project aims to bring the ease of Rails database interactions to PHP. It does not attempt to be a PHP on Rails framework, there are plenty of those, its just a great implementation of the ActiveRecord pattern. The documentation is also fantastic, covering the essentials and letting you jump right in, it feels like there is no learning curve at all.


• RedBean
  This is a complete departure from normal ORM solutions. In a normal solution you are cognizant of both the object model and the relational model, the ORM acts as a pleasant interface for interactions. In RedBean you are freed from having to know about the relational model, in fact you are allowed to let the relational model change on the fly. Need a new attribute for that object, don't worry about migrating schemas, just slap it in there and let RedBean figure out the rest. It is definitely an interesting idea, and it is maturing quickly, but I was wary of using it because of the overly fluid nature and the business constraints of my project

Those are the most interesting ones I investigated, I investigated quite a few other ones, but these were definitely the cream of the crop. None of them fit my project, but my project is a little bit weird (if you keep reading this blog you will no doubt see it one day, unless something shiny grabs my attention and I wonder off). If you are looking for a really powerful ORM with all the bells and whistles, check out Doctrine. If you are familiar with ActiveRecord, php.activerecord is a fantastic implementation. If you are programming PHP at all, take the time to read through Will Bond's amazing Flourish Lib. If you need some lightweight persistence or want to dabble in some object-oriented databases, give RedBean a try. Really on that last one, if you are even at all interested by technology, check out RedBean, it is a little young but shows amazing potential and is a great example of thinking outside the box.

So what did I decide, well I decided I don't want to use an ORM layer. ORM didn't fit my use case, I was only experiencing developer pain trying to shoehorn it in there. I decided that what I needed was something a little different, and I'm currently developing exactly that. So what is this mystery project that I'm working on, its a couple different parts that work together, but I decided that all I really wanted was the following list of things.

• Cross platform SQL


• Automatic CRUD


• Lightweight library

So I'm writing them, and I will be releasing at least part of it soon, once I get it to a point where it does something, then expect a blog post with trumpets and whatnot. I conceived the project structure last night and began coding, I was able to put in 3 hours of work and got a very nice proof of concept running, but it is still all sharp edges and scuffed surfaces.

Stay tuned though, I hope to have something people can put their fingers on soon. I think there is a need for the lightweight components that I'm building, as a platform for future innovation and because after 3 months of looking around I couldn't find anything out there that did what I needed.

related tasks

I remember watching Mitch Hedburg one time talk about how comedy is an odd kind of profession because if you are really good at it you have to stop doing it. The point he was making is that if you are successful enough at stand-up then one day people are going to ask you if you can act and write and star in movies. Here is the pertinent quote.

When you’re in Hollywood and you’re a comedian, everybody wants you to do other things that are related to comedy, but are not stand-up comedy. ‘All right, you’re a stand-up comedian, can you write us a script?’ That’s not fair. That’s like if I worked hard all my life to become a really good chef, they’d say, ‘OK, you’re a chef. Can you farm?’

This is a less severe version of the Peter Principle.

But it's not just comedians, Software Development has a whole host of secondary tasks that are related, sometimes closely, sometimes not so closely, that need to be taken care of. I've found myself in a secondary task day the last few days.

• New client conference call


• Functional Specification examination and inquiry


• Task list creation and time estimates


• Talking to a hosting company about plan upgrades


• Researching a fix for PCI non-compliance issue


• Researching why in the hell IIS6 wouldn't serve .aspx pages (Web Service Extension wasn't permitted)


• Fighting with a dev environment to get an application running to test whether or not a PCI Compliance fix would break the application


• Taking a break from fighting with the maddening server to write a blog post

These secondary tasks are all necessary, some are enjoyable (blogging), some I'm surprisingly skilled at (research, talking), some make me feel completely out of my element (time estimates, server configuration). In the landmark The Law of Leaky Abstractions and the follow up The Development Abstraction, Joel writes

Any successful software company is going to consist of a thin layer of developers, creating software, spread across the top of a big abstract administrative organization.

The abstraction exists solely to create the illusion that the daily activities of a programmer (design and writing code, checking in code, debugging, etc.) are all that it takes to create software products and bring them to market.

Its not that I don't want to perform these secondary tasks, or that I'm not good at them, it's just that I'm much more productive at coding. My brain is set up for it, ask anyone that knows me, I think about life as one big program, I examine my emotions based off of function arguments, I turn situations into class hierarchies, it's just how my brain works. Programming makes sense to me, I feel at home there, I feel warm and cuddly wrapped in curly braces, and I work really well there.

These secondary tasks, related tasks, need to get done, and because of my availability I'm the one to do them. It's good to learn new things, but also scary and uncomfortable and frustrating.

I don't know if there is a point to writing this, it started off as a rant against feeling forced to waste my time and skills on tasks that I don't feel comfortable doing, but it hasn't ended there. It hasn't really ended anywhere, it's a reality, so I'll deal.

All I know is that right now the abstraction is leaking and getting my clothes wet, I long to wrap myself in comfy curly braces by a warm fire and feel like I know what I'm doing again.

installation

Today at work I had the joyful experience of installing WordPress on my development machine. My 9-5 is working in the .Net arena so my machine is set up with IIS 7, MSSQL 2008, Visual Studio 2008, a cutting edge Microsoft stack. So when I was told to install WordPress to do some testing, I knew I would have to install a LAMP stack (minus the L) and then the WordPress software, I prepared myself to do battle.

Actually I had the feeling that this would be pretty easy, I use to work in LAMP and MAMP and WAMP stacks all day long so I could at least skip over the, "how the hell do I start?" phase and jump in head first.

I headed over to XAMPP and grabbed the latest Windows installer. 44 megabytes later I double clicked, selected my destination directory, C:\ (XAMPP automatically makes a folder called xampp to put itself in, I've made this mistake more than once and ended up with my install in C:\xampp\xampp), and clicked install. It churned and churned and I took the opportunity to grab a Diet Dr. Pepper. 5 minutes later I had a fully functional WAMP machine at my fingertips.

I double-clicked the XAMPP Control Panel icon and fired up Apache and MySql, clicked the Admin button and was whisked away to http://localhost/. After some security configuration, clicked security, entered a password, simple enough, I turned my sights on WordPress.

I pointed my web browser at the WordPress Download Page grabbed the zip and clicked through to the handy guide

The handy guide lived up to its name, especially the Famous 5-Minute Install.

In about 15 minutes I was able to painlessly install Apache, MySQL, PHP, Perl, and WordPress. It cost me nothing, and it all just seamlessly worked. In short it was the model install experience.

Installation can be easy to overlook, you write your app coding and coding away and you never think about getting it set-up. What often makes it worse is that as programmers we normally don't think much of complicated tasks or dialogs that would scare the average user. Installation is your software's first impression, and you know what they say about first impressions, try not to be a jackass.

When installations work right you should feel more and more comfortable as you follow the steps, WordPress is a great example. Every step I could see more and more of WordPress shining through, it didn't just work, it was intuitive and actually made me want to use it. Every step assured me that I had done the right thing and helpfully pointed me to the most important things to know for the next step. There was no technical jargon, just do exactly this, type here, click here, enjoy! It was short, simple, and sublime.

So in this world of web applications where we no longer think about installation, if you are going to make your end-user install something, make sure that you do the following

• Provide plenty of up-to-date documentation


• Make the process as simple as possible


• Provide feedback, both positive and negative


• Centralize your installation process

Follow this advice and someday someone will write a blog post about how much of a joy it was to install your software.

motion controls and ai

I was talking with a friend today about dj hero (which comes out later today) and he asked a simple question, "Have you heard anything about the next wave of game systems?" I read all kinds of electronics blogs like Gizmodo, Engadget, and even Hacker News and haven't seen anything about a PS4 or a Xbox720.

The PS3 was released on November 17, 2006, the Xbox 360 on May 12, 2005. So we are looking at about 3 or 4 years since the last generation, considering that the PS2 and original Xbox launched in 2000 and 2001, respectively, means that we may not see anything for a little while longer. But the weird thing is that there is no chatter, no rumors about the next-gen consoles, and I got to wondering why.

You may have noticed above that I left someone out, Nintendo's Wii. Hold on, don't get your Mario shaped pitch-forks out yet, I would argue that the Wii is what is causing the current drought in next-gen systems. The old logic of producing a next-gen system was as follows

1. Release system


2. Make giant profits


3. Wait for Moore's law to create more powerful hardware


4. Put more powerful hardware in box


5. Increment number after system name


6. Brag about polygon count


7. Goto step 1

The problem is 2 fold though. The first problem is that we are approaching the uncanny valley, possible even stuck in it. Have you seen the games little kids get to play these days, they are gorgeous, expansive, photo-realistic dream worlds. Let's compare and contrast

Super Mario (NES)

Gears of War (Xbox 360)

Need for Speed: Carbon (PS3)

Pumping out more polygons isn't really an issue anymore, we have reached the land of diminishing returns. So the idea of just putting out a more powerful machine isn't really going to get most people off of the couches and out in the stores.

The second issue is that Nintendo totally messed everything up, they put out a system that was just about the same power, had some weird remote control thing, and they DOMINATED the market. This decimated the conventional wisdom, you can't put something out that isn't more powerful and have people buy it, what's happening!?!? This can't be happening, deep breaths everyone, Bill Gates just threw up. The news talked about it nonstop, people were selling Wiis for a ton on ebay, the holiday season saw more than its fair share of customers fighting, waiting, and pleading for the hottest new video game system, the Wii. And its actually pretty fun, I've played Wii Sports Resort with my brother for hours on end, kicking his ass at frisbee golf.

Immediately though, people had to know, what is the secret sauce of their success, it must be that goofy remote. Sony quickly tried to slap some motion sensing into their sixaxis controller, with terrible results. Well now both big players have gone back to the drawing board to make some motion sensing controls.

Microsoft's Project Natal

Sony's motion sensing wand thing

Everyone has decided that motion controls are going to be a big part of the future of gaming. The problem is that motion controls have inherent flaws that all the sensitivity and one to one motion sensing in the world can't fix. Motion controls fail in 2 important ways, the first is that motion controls only make sense for certain activities, bowling, frisbee, sword play, gun fights, all can be done nicely with motion controls. But have you ever played a Wii game where the motion controls are tacked on (95%) or confusing (90%) or annoying (90%) or the wiimote is turned into a glorified mouse pointer. If not then you have never played anything but the AAA titles, and that's fine, that's why we have AAA titles, because they are good. They represent a tiny fraction of all games on the Wii though, the vast majority of what's out there was pumped out to cash in on a phenomenon, with motion controls thrown in for good measure, and normally to the detriment of the game.

The prime example in my mind is the Ghostbuster Wii port, a serviceable enough game, but the annoying swinging and shaking and quick-time event motion controls for every single ghost get annoying and unnecessary.

The second problem is that motion controls is a concept that is at odds against itself. On one hand your body is supposed to become an extension of the controller, you should be able to blur the line (in your mind's eye) between your actions in real life and the actions on the screen. The problem is that there is no force feedback, when your sword blow is parried by a wily electronic foe, your arms keeps going but the character's arm on the screen stops. There is no resistance as you shop through a tree, there is no physical feedback for the motion you are making. The fantasy world where you are the brave knight bravely trying to rescue the beautiful princess comes crashing down around you when you and your characters movements become out of sync, and suddenly you are back in your living room in your sweatpants swinging a remote like a jackass.

The Wii was successful because they marketed their machine to the casual gamer, this great untapped resource, and they had a great novelty to get their foot in the door. And it worked, and I will admit that the well made games on the Wii are a hell of a lot of fun, and I do enjoy the little system that could. The point of this post is not to rag on the Wii but to say that it succeeded in spite of the wiimote not because of it, and the new adventure down motion control road will end up being a blind alley.

So where does this leave us, what is the future of gaming? I don't know for certain, but I will finish up with what I would like to see. Improvements in Artificial Intelligence. Artificial Intelligence's capabilities were over promised and underwhelming, this has led to AI Winter. Most people today think that there is something fundamental about AI that it could never work, that the best we can make is not very good at all. And that really is the state of most AI today, especially game AI. When was the last time the game gave you AI teammates and you thought to yourself, "Yea, AI Teammates!" instead of "I wonder if I will lose points for murdering them." Not very often I bet, because AI is horrible, its even worse when its trying to help you. If Sony and Microsoft spent some serious money on developing an AI framework for their developers to use, they could make the games much more fun.

How do I know it would be more fun, look at the rise of MMORPGs. Massively Multiplayer games are fun because your opponents and teammates are smart enough to make the gameplay more enjoyable. MMOs also suffer from various policing issues and behavior, anyone who has been called a n00b by a thirteen year old after he's headshot and teabagged you knows that the fun often comes at the price of dealing with the worst of human behavior. Its not always so bad, and after a while you learn the rules of the world and online gameplay can be great fun, that's why its a major part of almost any AAA title released these days.

Its this drive to have intelligent opponents that don't feel like they are cheating, teammates who can understand strategy and don't need to be micromanaged, and gameplay that is both rich and engaging that has brought MMOs, Xbox Live, and PSN to the forefront. The software AI has failed so we went back to using people, which is great, video game nerds need as much socializing as possible. But if a little injection of intelligence can be fun, much more intelligence can (and I stress can, not will, it could end up horrible) be much more fun. I think this is where the future of gaming lies, not in various wands and cameras.

This post got long and out of control, also it was fairly off topic, I hope to be back on programming tomorrow

treasure hunting

Working with programming languages is fun stuff. If you are a programmer then you probably only think about your language as much as you need to to get the job done. In fact you have to really, if you spent all day thinking about how the compiler is going to allocate this variable off the stack or this one off the heap or how its going to write out the virtual lookup tables, you could never get anything accomplished.

It's a shame though because our programming languages are some of the most interesting and complex software we interact with. If you are willing to look around you can find some real treasures out there, and even if you never code anything of importance in these new found treasures, the experience will pay dividends elsewhere.

I'd like to take you on a tour of the treasures I've found in my travels through the world we call programming, I'll split it into four easy to consume chunks.

The Past

The history of our field is short, still short enough that you can probably come to know most if not all of it. This is one of the interesting things about Computer Science, its a field that, in it's modern form, is about 60 years old. The amazing thing about all this is that there are some gems from the past, truly ground breaking work that we still use today.

• Lisp
  As you may well be aware I've recently fallen in love with lisp, I'm starting to think about her all the time, and you can too. The amazing thing that, to this moment, knocks my socks off, is that Lisp was originally conceived in 1958 and has all kinds of concepts that you wouldn't expect from a language in it's 50s. Closures, homoiconic code, anonymous functions, object oriented programming, and a web framework. There is a lot more to this language, and it is definitely worth your time, go read up.


• Smalltalk
  This one comes from the 1970's from the famous Xerox PARC. Smalltalk was way ahead of its time with a fully integrated development environment, a fully functional GUI, no files (this sounds bad at first, but its freeing not having to worry about where your source lives), everything is a file, and much more. Smalltalk's influence is far reaching even to this day, Objective-C borrows heavily from it, and the influential Gang of Four book offers source in C++ and Smalltalk.


• C
  Hard to believe that this staple of computer programming was invented in 1972. Without C, Unix would not exist. C is still crazy fast, basically human readable assembly, and still widely used. The backbone and infrastructure of most of our technology exists because of C. Have a scripting language, need a way to shut people up who are saying it's too slow, allow them to call C modules, done. C is definitely worth knowing, you can access a giant pile of source code, and get as close to the machine as possible without busting out the x86 Assembly Guide.

The Present

• Ruby
  This is the current hotness, although its hotness may be waning somewhat. Today ruby is the top language on github and there is a new interesting project written in ruby everyday. Ruby on Rails created the rockstar ruby programmer, and revolutionized data backed web development. Ruby is going to be around for a while, and because of REPL its easy to get started.


• JVM Languages
  Java may be out, but the virtual maching that runs the language has never been more popular. Clojure (a JVM Lisp, which will probably get its own article soon) and Scala are up and coming. The ubiquity of the JVM means that you can run this code on almost any machine, and the languages are squeezing speed and performance out of the JVM that would have been unheard of a few years ago. These languages can also leverage the huge pile of Java Libraries out in the wild, so the first major hurdle to a new language (what can this thing actually do and are there any tools for it), is easily leapt.


• DSLs
  Domain Specific Languages are starting to come into their own. Some of this popularity is owed to the rise of ruby which makes writing a new DSL somewhat trivial. Sass, Haml, and many others DSLs are beginning to find more and more adoption within their domain.

The Future

• Functional Programming
  Erlang, Haskell, OCaml, etc. are beginning to see an upswing in interest. The rise of multi-processor cores and the inherent complexity of mutli-threaded programming in imperative programming makes these languages a tantalizing option. Erlang can support millions of threads with simple, easy to understand code. CouchDB will be the proving ground for Erlang's efficacy.


• JavaScript
  As I wrote in the future: javascript

  When it get's down to it, JavaScript is a great language. It has a ton of exposure, and a huge amount of developer mindshare. JavaScript isn't going away anytime soon, and considering how hard it is to get browser vendor's to agree, isn't getting replaced anytime soon. JavaScript will become more and more prevalent both on the server and on the desktop. I welcome our new prototype based overlord, and so should you.

  So far nothing has changed.


• Anything
  That is one of the most exciting things about this field, it could be anything. Before Ruby on Rails, the ruby language was a small odd scripting language that few outside of Japan had heard about. With the success of RoR ruby (which is an acceptable lisp) use has exploded and they have gained massive developer mindshare. Tomorrow a new technology could set the world ablaze, and the best part is that we have a chance to shape that future. This is an industry in which a man with a great idea can truly change the face of the development landscape.

These are just some of the treasures I have discovered by opening my eyes and looking around. There are plenty more gems that I have found that didn't make it into this post, but only because these one's were on the top of my brain. If you encounter a new language, take an hour or so to run through a tutorial, it could be worth it, it might not. You may find yourself falling in love, or maybe you missed a few episodes of the Simpsons. At the end of the day though, you will be glad that you took the time to learn something new, when you see glimmers of it in something old, and your knowledge of share-nothing concurrency saves the day on your next project.

This is a dynamic wonderful field, go play!