murdering your baby

[caption id="attachment_356" align="alignnone" width="370" caption="don\'t worry, no babies were harmed"][/caption]

Yesterday my friend Ian sent me a tweet about prosper

@ihumanable I'd be more interested in using Prosper if it provided support for true prepared statements instead of concatenating strings.
6:29 AM Dec 7th - pian0

With that my baby was born, the baby was a version of prosper that utilized prepared statements where appropriate. Prosper's main functionality has been coded for a while and the bulk of the work I've been doing as of late has been testing, improving backend support, and adding new functionality. The nice thing about this kind of work is that you don't have to go mucking around in working code, you are just fixing broken stuff and adding new functionality. The idea of adding prepared statements made me a little queasy, I had briefly looked at it when I was starting prosper but decided that they were so varied that for the first attempt I would just avoid the headache. What's the problem you ask, let's take a look at this feature table real quick.

Database	Supported by Prosper	Can Support Prepared Statements
dBase	YES	NO
DB++	NO	NO
FrontBase	YES	NO
filePro	NO	NO
Firebird / Interbase	YES	YES
Informix	YES	YES
IBM DB2	YES	YES
Ingres	YES	YES
MaxDB	YES	YES
Mongo	NO	NO
mSQL	YES	NO
MS-SQL	YES	YES
MySQL	YES	YES
OCI8 (Oracle)	YES	YES
Ovrimos	YES	YES
Paradox	YES	NO
PostgreSQL	YES	YES
SQLite	YES	NO
Sybase	YES	NO
Tokyo Tyrant	NO	NO

As you can see the support for prepared statements varies in the Vendor Specific Database Extensions of php. There is also the fact that prepared statement support is poorly implemented in several extensions, they can be coded around but it adds a good deal of complexity. Despite all the reasons not to implement prepared statements, safety, speed, and correctness dictate that I should at least give it a go.

Yesterday and today were my go, and I met with some success. Prepared statements are not all that difficult to implement for a given backend, throw in some question marks, call the correct bind function, and you're off and running. The real difficulty is the cross-platform nature of prosper. I wanted prepared statements to be a first class citizen, I didn't want to decrease any existing functionality, I wanted to not overly complicate the way prosper works, and because there are 11 adapters that need to be upgraded, I wanted it to be simple to add this functionality to a given adapter.

I worked and toiled and toiled and worked, I tried hacking something up to make the MySQL adapter work, ran into the bind_results function and screamed at it for a while. Then I got out some paper and drew out some diagrams, thought about sample code. Then I went to sleep. Then I woke up and in the shower pondered the proper syntax for passing around typing information and the division of labor for transformation. Then I hacked on it some more and wrote a quick test. Then and this is the most important part I realized I had done it absolutely backwards.

I had some clues that stuff wasn't working out right, I hit a point where I would either need to embed an if statement in every function of an adapter or have a duplicate function. I thought that with some clever coding I could shove this down into the base class, it wasn't great but it was working. Then I saw another red flag when I realized that the processing in the where clause was identical to the processing in the values clause, and I applied some refactoring. This is when I realized that there was a single function that I could have modified and had the whole thing work much more elegantly.

That is when I had to come to the decision to murder my baby. I had painstakingly worked out the kinks for two days, traveling far down this road, touching a bunch of code, and now I realize the best way forward is back. The best thing I can do right now is to revert my changes to Monday morning and lose 2 days of work, and that is great!

It's not the best outcome, in an ideal world I would have seen this solution before and applied it and not wasted 2 days. The thing is that I've learned a great deal, I've come up with a much better implementation, and I've been reminded of an important lesson, never be afraid to throw away code. The code I wrote is adequate, it works well enough, but it is far from optimal. I could keep going, head down, plowing away making as many problems as I solve trying to build a house on an unsound foundation. The point here is to pay attention to those red flags.

The other important point is that sometimes you have to actually try something to find the thing that will work. You may lose some time, but even after sitting down with pencil and paper, thinking long and hard, the optimal path didn't come to me until I walked down the wrong road. That's just life sometimes as a software developer, you have to learn to live with it.

I will continue working on prepared statements for prosper, and I hope that by 0.7 or 0.8 they will be implemented and in there. I still question the syntax and think that I can clean it up, right now the plan is for prosper to support unnamed parameters (?), named parameters (:name), unnamed typed parameters (%i), and named typed parameters (:name%s), but all this seems like a little much. Good thing prosper hasn't had a 1.0 release yet ;-)

php pain

[caption id="attachment_353" align="alignright" width="210" caption="he never forgets, even the stupid decisions"][/caption]

I am a fan of php, ever since my first software development job where I was thrown in the deep end and had to sink or swim. I swam in the sea of php and actually think it is a very nice language (begin receiving hate mail.... now!). You see, I never knew the non-OOP php, I was brought into a well managed project with Classes and Interfaces, it was basically Java with dollar-sigils thrown in. I never suffered through the spaghetti nightmare that so much php is, so I'm admittedly wearing some rose-colored glasses.

There is one feature that I love about php, it is the height of elegance, the associative array. The associative array can do anything, need a stack just use array_push and array_pop, need to do some functional programming array_map, array_filter, and array_walk are your friends. The beauty of the associative array in php is that it is ubiquitous, its a hash map, array, stack, object, all rolled into one.

The problem with the associative array though is that its create syntax is ugly. Here is how you create an array in php

[php]
$example = array(1, 2, 3);
[/php]

That doesn't seem so bad, what am I complaining about, well the problem comes when you have nested arrays (which is somewhat common).

[php]
$configuration =
array(
'name' => 'My Configuration',
'server' => array (
'name' => 'localhost',
'port' => '8080',
'users' => array (
array (
'username' => 'example',
'password' => 'example'
),
array (
'username' => 'user01',
'password' => 'pass01'
)
),
'overrides' => array (
'https' => false )
)
);
[/php]

The biggest problem is not that I have to keep writing the word array its that arrays don't look like arrays. They look like function calls, with other nested function calls, of course the newlines and tabs help out, but they don't solve the problem. Let's look at how this would appear in JavaScript using super-awesome JSON.

[javascript]
var configuration = {
name: 'My Configuration',
server: {
name: 'localhost',
port: '8080',
users: [ {username: 'example', password: 'example'},
{username: 'user01', password: 'pass01'} ],
overrides: {https: false}
}
};
[/javascript]

That's much nicer and the more important part is that hashes look like hashes and arrays look like arrays. There was a proposed php syntax change that was discussed to death and an analysis here which would have made the following legal php

[php]
$configuration = [
'name' => 'My Configuration',
'server' => [
'name' => 'localhost',
'port' => '8080',
'users' => [ ['username' => 'example', 'password' => 'example'],
['username' => 'user01', 'password' => 'pass01'] ],
'overrides' => ['https' => false]
]
];
[/php]

But this is not the case, and more importantly, may never be the case. The issue has been brought up and rejected several times, with the following reasoning

I see no advantages here, only another way to do already possible thing and yet another way to confuse people.

- Anthony Dovgal

For the record: I'm -1. array() is enough. Ridiculous idea to begin with.

- Jani Taskinen

There is no reason to add another syntax for *exactly* the same thing, especially because it's ungoogable

- Derick Rethans

Then there is this

I'm ok with it as well. Like I said over a year ago (*), it is a syntax very familiar to web developers and it feels natural to most people.

(*) http://marc.info/?l=php-internals&m=117060700805108&w=2
- Rasmus Lerdorf (the guy who created PHP)

The problem I see here is that the vote finally breaks down to 1 / 3 contributors in favor and 17 / 20 users in favor, it was then rejected. There is no recourse and as long as the people maintaining php see this as a useless feature, as a "backward incompatible syntax that duplicates already existing one, but 5 characters shorter" change request, it will never move forward.

This is a shame and it is myopic and dishonest. To trivialize this change supported by the vast majority of the php users voting as some sort of luxury people want so that they can avoid typing 5 characters is intellectually dishonest. The major point is that square brackets mean arrays in php, unless you are creating one, then it looks like a function.

[php]
$array = array(0, 1, 2, 3, 4, 5, 6); //Create the array
$element = $array[5]; //Get the element at index 5
$array[3] = "hello"; //Set the element at index 3
$array[] = "example"; //Push an element onto the array
[/php]

The dishonest part about the argument against the change is that it would be some sort of crazy zany backwards incompatible change and we would never break backwards compatibility. First off, if you are going to classify any addition to the language as backwards incompatible, then stop having a core development team, you are done, close up shop you can't add anything to the language anymore. Secondly, php has a history of removing and adding things that break older code, anyone remember the first stab at classes, or ever written $stringvar{4} to access a character, that is going away and you should write $stringvar[4] from now on. It's deprecated as of php 5.3.0 and will most likely be removed as of php 6.

But we are left as a community without recourse, the array function to create an array exists and by that fact alone it will remain forever. The most disheartening thing about the whole misadventure is that because this has been brought up and rejected so many times any time it is brought up now it is automatically rejected as being rejected before. Discussion has attached to this idea a Scarlett Letter, most undeservedly.

At the end of the day I won't jump ship, but it's one of those things that makes you stop and scratch your head. Why be so against it? I don't buy the arguments against it, I don't understand the fervor that the devs fight against it with, and I don't see the harm.

As people push the boundaries of what the language can do and the concept of the DSL (pushed by those ruby people) becomes more and more prominent, language cruft will have to fall by the wayside. Not improving array literal syntax is not the end of the world, but the attitudes and egos on display fighting a harmless change that the user base wants could be.

---

Edit: My arrays were using non-literal keys, which is incorrect as pointed out by Mewp in the comments, they have been corrected. Sorry about that, thanks for the correction Mewp.

you asked for it

[caption id="attachment_337" align="alignright" width="300" caption="who is this happy at work?"][/caption]

I've been getting some feedback lately on the aesthetics of my blog, mostly its of the I-don't-like-light-text-on-a-dark-background variety. I got into a pseudo-argument about it here on Hacker News, then I realized I was being an idiot. People were telling me, I like your content, I want to read what you wrote, but because of the style choices you made it hurts to read and so I won't. So I thought long and hard about it and implemented a fix.

I wanted to first off let everyone know that this blogs theme started off as a great theme called zDark that I really enjoy. Over the last 2 months I have tweaked it and added somethings, removed others, and have gotten it to a place that I really like. Nothing is set in stone though, at the suggestion of Mark Essel I've bumped the text color from #bbbbbb to #dddddd. The point is that when someone complains about the theme, even though it's the exact wrong way for me to react, my first thought is "No one talks about my baby like that, nuh uh, no you didn't!"

After the initial offense wore off, I realized that people just don't want their eyes to hurt after reading my post, and I can understand that. That's when I resolved myself to fixing this issue, and I went looking for a solution, but not just any solution would do.

First off, I didn't want to change the default theme of the website, I really like it, and dark-on-light text hurts my eyes. Second, I wanted it to be something that stayed changed, without having to give people user accounts. Third, I wanted something that was unobtrusive yet obvious.

I fired up google and found Integrating Alternative Stylesheets in WordPress Themes it seemed like a great method for providing such functionality. It drops a cookie on the user's machine to remember the preference later, which is an appropriate use for cookies. So far this had hit points 1 and 2 of my wish list, now I just needed an unobtrusive, yet obvious user interface.

I hopped over to IconFinder (which in general is just a great resource) and started searching for some text icons. After a while I found a great dark-on-light icon and a few seconds in Paint .Net with the inverse color tool gave me a great light-on-dark icon.

Then I had to find a place to put these icons and hook up the functionality. I decided to put them above the posts in the menu bar, as can be seen in the figure below

[caption id="attachment_335" align="alignnone" width="580" caption="new style switcher"][/caption]

I felt like that (without the arrows and bright pink circle) would fit the third requirement of being unobtrusive yet obvious.

The only problem left was getting the damn thing to work. After pulling down the javascript from Integrating Alternative Stylesheets in WordPress Themes, I couldn't get it to work, there were some parse errors in it. A quick trip to JSLint and a little bit of work later, I actually understood how the thing worked and had it up and running. Here is my non-minified styleswitcher.js that is currently powering this functionality.

This is how I should respond to complaints, not by arguing, but by addressing the concern and coming up with a solution that makes all parties happy. The functionality is live and you can try it out right now. The dark-on-light theme is definitely a work-in-progress. I am working on some stuff for it and hope to have it somewhere nice soon. I'm thinking of doing a nature inspired theme for it, that still captures the same layout and feel as the current theme's techno-neon roots. Looking back at that sentence makes me realize the insanity of what I'm trying to do, so it may take a while. Please bear with me as I try to make the dark-on-light theme as nice as the light-on-dark. For now though, if the light-on-dark hurts your eyes, this new functionality should at least make the content readable to you.

To sum up.

• Lesson learned, user feedback is a good thing, you shouldn't argue with it, incorporate it.


• The new dark-on-light theme is up and running, although its kind of ugly


• I will be releasing a more beautiful and integrated dark-on-light theme soon enough, I thank you for your patience

state of the blog

[caption id="attachment_328" align="alignleft" width="300" caption="danger danger will robinson"][/caption]

I was having a discussion the other day with my pal Jeremiah about blogging, on-line presence, and other nerdly things (nerdly clearly a portmanteau of nerd and worldly). We talked about how one drives traffic to a site, maintains quality, and he pointed me to a smart bear. As you can imagine this only spurred more discussion about blog-promotion and self-promotion.

I got to thinking about how I promote ihumanable.com and I want to share with you my method of promoting and how its all working out.

First off I think it's important to understand my goals with ihumanable.com. You may have noticed that this site has no advertisement, in fact the pixels your eyes are gobbling up cost me money to send to you. I don't write this blog to make money off of it, so that capitalist drive to push ad-views and click-throughs doesn't exist. It's not all kumbaya and hippies though, the general idea is that this blog will help me create an identity for myself which makes me more marketable as a programmer (someone has to pay for these delicious pixels). The main reason I write this blog though is that I love to program and when I'm not doing that I love to talk about programming, this blog gives me a nice outlet for both.

Here is my formula for success

• Read a lot - Hacker News, Coding Horror, Stack Overflow, these sites are well worn in my browser. So are Practical Common Lisp, Learn You a Haskell for Great Good!, and Learn You Some Erlang for Great Good!. Read everything you can, read voraciously all the tech, if you love to do it like I do then all the better.


• Remember things - This goes along with the point #1, if you are reading and reading but not recalling anything, then its no help at all. I have a pretty good memory, but I've found that Delicious Bookmarks and Firefox's Awesome Bar are the most helpful additions my memory could ever use. Example: I remembered the article Jeremiah sent me but had no idea what it was, typed 'bear' into the Awesome Bar and bam, there it was, thank you Firefox.


• Write what you know - Write about the stuff you know, take the time to learn something before posting. Post about things you've actually done, that's how this blog started wanting to share my experiences doing ruby koans.


• Links are your friends - You might lucky enough to be interesting, but you don't have to be. Include plenty of links to the interesting things that you've read from the point #1.

[caption id="attachment_326" align="alignright" width="150" caption="breaking up the wall of words"][/caption]

• Wall of words - People get intimidated by a wall of words, break it up with video embeds, pictures, and blockquotes


• Promote Appropriately - Every time I post I tweet about it, I've posted a few posts on Hacker News and met with some pretty good success. I don't spam Hacker News though, I like the community and when there is something of interest, I submit it.


• Make sharing easy - See those things at the bottom of the post, they let you submit my article to social networks, tweet about them (that one's new).


• Make it easy to follow - See those icons at the top of the page, one let's you follow me on Twitter, one let's you subscribe to the rss feed.
  
• Make it memorable - I like to try and find an image to start an article that either captures the article's content or is just memorable. I also tried to pick a domain name that would be memorable and easy to type, ihumanable.com.


• Track readership - My hosting company keeps statistics and I use Google Analytics to track readership, this let's me know what is working and what isn't.
  

Those are the basic guidelines I try to follow and the results have been pretty good. I've had a general increasing trend in daily readers, and I've had a few big blockbuster days. Monday's article was on the front page of Hacker News for around 8 hours and had 1,806 pageviews. That was astonishing to me. I've had some other big jumps in the graph, but the general slope is what is even more exciting, people are starting to read regularly.

I've been posting every weekday (missed Thanksgiving and Black Friday) since October 2nd, 2009 when the blog started. I like to think that the consistent posting let's people know that they can check in everyday and get something new and fresh. This frequency is not required, but a consistent posting schedule is nice because it let's people know when more is coming and hopefully makes them look forward to the next post.

Here are the things that I've discovered that I didn't realize I would when I started.

• Relationships - Through this blog I've met some cool new people, like Mark Essel, and improved my relationships with existing friends, Jeremiah Peschka and Rick Kierner.


• Great Discourse - It may be the subject matter or the promotion avenues, but so far the discourse generated by my blog posts have been more than I could ever ask for. Comments are insightful and well-thought.


• Passion - I never really wrote before and now I love it. I look forward to writing a post everyday.

That's the state of the blog right now, I'm delighted with where it is. Growth is never easy, there is so much content and so little time. If you refuse to pander, write what you know and love, promote consistently and honestly, you will find people to read your words. That's why I write, and I would have never guessed what it would mean to me.

prosper 0.6

[caption id="attachment_248" align="alignright" width="128" caption="prosper"][/caption]

I plan to have another real post later today, just wanted to announce a point release for the prosper library. Prosper development has been moving along and I am happy to announce that I just slapped the finishing touches on version 0.6.

Here is the 10 cent tour of the new stuff

• Changed the configuration system to take constants instead of string literals


• Added support for the older mysql library in addition to the mysqli library


• Refactored adapters internally for more concise and logical class layout


• Moved project to GitHub


• Adapters are lazy loading now, this allows the configuration to be done with minimal overhead. This functionality also allows for unit testing


• Added phpDoc Documentation to the project


• Added GitHub frontpage documentation and project roadmap

There is a new download available on GitHub that contains all the documentation and source code. Since prosper is still in the 0.* stage it may be best to just clone or fork the source, a look at the 0.7 roadmap shows that there is still a bunch of work to be done.

If you want to help there are several ways that you can provide support

• Use prosper and submit issues


• Join the project*


• Give me some feedback*

If you want to join up or give me feedback just send an email to ihumanable@gmail.com with prosper in the subject line

fortune cookie wisdom

[caption id="attachment_306" align="alignright" width="175" caption="makes delicious chicken"][/caption]

I'm back at my company's main office today tying up a loose end for a previous client. This means that it's all the free Diet Dr. Pepper I can drink, a trip down memory lane to the land of .Net, and lunch at Saigon Palace. Saigon Palace is a wonderful little restaurant in the heart of Columbus that serves up a fantastic General Tso's lunch special. The best part of any meal is the desert, and at Saigon Palace the sweet treat to cap off the meal is the humble fortune cookie. The fortune cookies at Saigon Palace are infamous at work for containing a piece of paper with something written on it that is almost never a fortune, and frequently not even understandable.

Imagine my surprise as I got a fortune today that was a full sentence and it made sense.

Impatience may be appropriate at this time.

That made me sit up and take a second look. I might also be buying a lottery ticket with 20-5-15-51-27-13 on it. Back on track though, it made me think about where I am in life and where I want to go and what I've subconsciously been telling myself for my whole life, "Be patient, work hard, bit by bit you will reach your dreams." It's the kind of thing that works really well to achieve standard goals, to accomplish lots of things in life it's not a bad idea. The problem is that its effectiveness can blind you to any other way forward. Then yesterday I read Derek Siver's There's no speed limit (The lessons that changed my life.) and this fortune cookie brought the whole story rushing back into my mind. Patience can be a virtue, but it can also be a hindrance. To quote Monty Burns

If you can take advantage of a situation in some way, it's your duty as an American to do it. Why should the race always be to the swift or the jumble to the quick-witted? Should they be allowed to win merely because of the gifts God gave them? Well, I say cheating is the gift man gives himself!

Now I don't want to promote any cheating, but sometimes the impulsive, dangerous, caution-to-the-wind approach to life feels like cheating. There is no structure, there are few guidelines, its up to you and your guile to make it. Patience ensures you a slow steady build up, impatience can be dirty and dangerous, it can pay off big or blow up in your face. The cookie brings up a good point though, impatience is sometimes appropriate.

That's the idea I want to impart today, not that patience is bad or that impatience is good, but that sometimes impatience is appropriate. Gunshot wound, don't patiently wait for a taxi, demand an ambulance. Production server on fire, don't patiently wait for the Triage Committee to assemble, put it out. Bored at work, don't patiently wait for someone to walk by and hand you something interesting to do, go poke around for the good problems, become the person that solves them.

Patience is a virtue, but impatience is appropriate, sometimes. It's up to you to determine when it's appropriate, and you will have to pay the piper if it blows up. Learning when its right to leap without looking and speak up when others are quiet is the way that you take control over your own destiny.

riding the wave

[caption id="attachment_299" align="alignright" width="300" caption="wave"][/caption]

Yesterday's post seemed to strike a nerve within the programming community, it was encouraging to see that I was not alone. I want to thank everyone that provided great commentary both here and in the Hacker News entry. I will probably touch upon the topic again, unlike a sitcom the issue of professional burnout isn't solved in a half-hour, but not today. Today I want to talk about Google Wave!

I previously wrote about Google Wave in you can't understand google wave which had such gems as

The problem with people waxing inanely about what Google Wave will be is that they have their heads up their asses. They don’t know, because they can’t know.

I wrote that post a long time ago during the hype and the hyperbole about Wave being the savior of the world or the misstep that will sink Google. I also wrote that post from the outside looking in, not being lucky enough to have a wave invite, I could just read the whitepapers and wonder. Yesterday though the worm turned and my dear friend Jeremiah Peschka sent me a coveted invite. After the Google gears churned away I got the email later that night, the velvet rope had swung open, I would be able to ride the wave! I fired up firefox and clicked the link, my hands trembling with the joy of new technology. I was whisked off to the interface I had come to expect in screencasts and diagrams.

I then had A Universally Confusing Initial User Experience, and tried furiously to remember Mark Essel's Aha Moment. Once I typed "with:public" and then variations on that theme "with:public haskell" or "with:public erlang" I was off and running in the world of wave. I'd like to jot down my first impressions

1. There is a lot of stuff out there - so many you often see listings like "51 - 76 of lots" which is the cute way Google Wave tells you there is a ton of stuff.


2. There are other languages - I'm looking at Korean, Cyrillic, Chinese, and Spanish, all in one little window. Very rarely in my day to day surfing on the old internet do I see anything but English, on wave you see everything.


3. Gadgets == slow - Maybe it was just a bad first experience, but Gadgets seem to bog down the wave a ton. This coupled with the fact that the few I saw seem absolutely pointless made me despise that little puzzle piece


4. Wave == slow? - I have a fairly beefy home computer with the top tier internet connection Time Warner Cable provides, but wave felt sluggish. Things worked, but the wait times were on the high end. I thought at one point I should try it in Chrome, but that didn't seem to make anything better.


5. I don't know what I'm doing - This is the big sticking point so far, I have no idea how to use this thing


6. It pushes the boundaries - Often as a web developer we get too used to the standard paradigms, we also get stuck in a mental model that is concerned (rightly or overly) about bounce rates and conversions. Wave pushes these boundaries, Google has enough muscle to say, this is important, it doesn't matter if people don't "get it" right away, they will. It's big enough and important enough that people can bounce, they will end up back at Wave before long. This is what Apple does, and it's why people love (and loathe) Apple products.


7. Scrollbars - I read an article about the Google Wave scrollbars a week or two ago and couldn't make up my mind. After using them I will say you get used to it quite quickly, but I'm still not sure why they felt it necessary to re-engineer this feature. I'm thinking the biggest reason is the on-demand nature of Wave makes it so that even Wave doesn't know how many more items are in a list, making traditional scrollbars difficult

At this point I still need to play around with Wave quite a bit before I get the hang of it. I'm going to attempt to avoid making any statements predicting into the future, because I can't. I'm glad Google is pushing the boundaries, wave could surge or crash, either way I think its impact will be positive. Google is saying in a very public way that it is ok to think outside the box, reinvent scrollbars, change the way we view a web application, and that will have results.

People are going to debate the merits of all the parts of Wave, and that debate has definite value. The ideas that will come forth from that debate will have impact on usability, communication protocols, general design, and so much more. Pushing the community forward is never a bad thing, and so in that respect Google Wave is already a success.