ihumanableusable in any place a human can be used

it cuts the roof of your mouth so the chemicals can get into your bloodstream faster

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

having a bully day

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.

i know how you feel

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).

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);
}

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 for somewhere

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.

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.

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.

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

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.