Fuck You Internet Explorer

[caption id="attachment_907" align="alignright" width="360" caption="This is for you IE"][/caption]

Be Warned: This post has very little technical value, more just a rant against my most hated enemy

I hate Internet Explorer, with a fiery passion. Normally I just code along in beautiful browsers and use cross browser CSS and JavaScript frameworks. It's gotten to the point that I can code something up in Firefox and make it pretty and go over to old IE-saurus Rex and load it up and it looks 90% of the way there and a few hacks later it's fine. You see I still hate IE, but I've ingrained in my brain somewhere what things are "safe" and will probably work in that POS browser and which will require hours of tweaking, reading, googling, hacking, gnashing of teeth, and general misery. I try to avoid the latter.

So If I've developed this system to insulate myself from the misery of IE, why the hate today? IE9, that's why. I've read several reviews both positive and negative, but at the end of the day I'm not switching browsers, so I really care about one thing and one thing only, does IE9 make my job as a web developer better or worse. I've come to the conclusion that it's worse, and for that I have a lovely pile of "Fuck You" cake sitting right here with IE's name on it.

Not Available for Windows XP

First of all, IE9 is not available for Windows XP. Great, game over right there you fucking idiots. I don't think people should use 10 year old operating systems, but people are stupid, see: the continued popularity of American Idol for proof. Firefox is taking the responsible route and helping these poor souls bring their browser into the 21st century even if they are fine with an ancient OS. As Firefox Engineering Director Johnathan Nightingale says about XP, "...the best metrics that we’ve got say 40 to 50 percent of the web is still on XP. That’s too big for us to just leave them behind"

Missing a metric ton of shit

IE9 is just missing a ton of stuff. Stuff that web developers care about, stuff that would make our lives easier and happier, stuff that IE9 rapes right before sleeping soundly on a pile of skulls. Paul Rouget of Mozilla makes this case, let me quote some of the juicier parts.

No CSS3 for you

Here's a list of CSS3 stuff IE9 won't support: CSS3 Transitions (for animations), CSS3 Text Shadow, CSS3 Gradients, CSS3 Border Image, CSS3 Flex box model. Great news, don't put photoshop away just yet, you are going to need 1px wide gradients and text with shadows baked in, and fuck it.

Suck it UX

Hoping you might get HTML5 History API, Drag'n Drop from Desktop, or Web Workers to speed up your applications. Not with IE9 you won't.

Not the point though

Let's not get caught up in a feature list shoot out though, because that's not the point. Let's move onto the next subject.

Fractured even further

Does IE9 make my job easier, nope not at all. Microsoft's all consuming obsession with backwards compatibility means that they won't force anyone to upgrade. While other major browsers are moving to a model of strongly-recommended / automatic background updates to keep everyone on the latest and greatest, Microsoft is still playing the game by the old rules. Now the browser landscaped is fractured even further, I have to make sure my code works in IE6, IE7, IE8, and IE9, and if I want to be really sure I should also check in IE7-compatibility, IE8-compatibility, and Quirks Mode. Microsoft has never made it easy to run different IE versions side by side, I've used several products to do this and they all work to varying degrees. Now I will have to run another different virtual machine with either Vista or Win7 so I can test in IE9. And with no / terrible developer tools for all of these browsers, well its a fucking nightmare.

Conclusion

I wish I had one. At this point the only thing I've concluded is Fuck You Very Much Internet Explorer. Here's an idea, stop already Microsoft. I don't care how good you make IE10, the fact of the matter is that since you won't force upgrades, it isn't fucking helping. The only thing you are doing is making more work for the people that actually make the web beautiful. I fucking hate you. Fuck you very much.

Lipsum Lives

[caption id="attachment_903" align="alignright" width="300" caption="This is how I feel right now"][/caption]

I've been hard at work for the last 7 weeks, sprinting from start to finish on a custom CMS system that will manage our company's various online publications. It has been a grueling experience. When I started my friend, Jeremiah, told me, you are crazy, don't do that, I'm going to hit you in the face. And yet, undeterred, I soldiered on.

I was not so foolish or prideful to think that other CMS systems were inferior or stupid or ugly. I use WordPress to power this blog, and let me tell you, WordPress is friggin sweet. Drupal 7 just came out, it looks to be an amazing piece of software as well. I looked at various PHP CMS systems, but at the end of the day I decided to build my own for the following reasons.

• I have no experience with developing for WordPress / Drupal / Insert favorite CMS here


• Time was at a premium


• Flexibility is a must

Now I'm sure there are Drupal Ninjas and WordPress Wizards out there, thinking, if you need to get a flexible website up fast, just use [the CMS system I know and love] and it will be easy peasy. I'm not against learning, and I try hard to fight NIH syndrome. The long story short version of this was I was told, "5 weeks we need A, B, C, D, E, F, G and it needs to work in X, Y, Z, (several other alphabets worth of letters) ways." I knew that I didn't have the time to climb up the learning curve of a CMS and become a WordPress Guru or Drupal High Priest. I did have time to write software, and since I know PHP and Flourish like a fat kid knows cake (aka, like I know cake), I decided that the route with the highest possible success was to write something.

The next most important point is that I work for an amazing company. We are growing fast and the future is anything but certain. Ideas for the publication sites come fast and furious, sometimes radical, sometimes insane, sometimes brilliant, having total control of the software is a must. Getting something up was important, but building a solid foundation that would allow us to build new engaging features in the future was even more important. With our custom framework we will be able to pivot and experiment in a way that we simply couldn't with off-the-shelf CMS software given the engineering skills at hand.

Here's what I learned building a "successful so far" CMS system. CMS systems are hard. They are really really really friggin hard. They are hard in stupid ways and hard in smart ways. Getting it just right is impossible, getting it half-way good is a tremendous challenge. Every feature is 10x more complicated than it looks on the surface and you won't know how until you talk to the person that cares about that feature. Every feature, no matter how much you talk to people while building it and no matter how much you model and poke and prod, is going to be wrong in some way. You have to simultaneously be so cocksure that you look at this mountain of a task and say, I can take this on, and humble enough to listen to bug reports, user frustrations, and endless visual tweaks so that it's actually worth using.

I have a new found respect for the tremendous task software like WordPress and Drupal and Joomla and so many others try to tackle. I want to go and learn one, Drupal 7 looks nifty, just to see how the pros do it. I have also been reminded that even when you are Inventing it Here, you don't need to go NIH crazy. Building this software was an exercise in standing on the shoulders of giants. Our avatars are powered by Gravatar which easily has the most straightforward and easy API ever. Our comments are protected by ReCaptcha cutting edge captcha technology that also helps read unOCRable books. Our email campaigns are being handled by the amazing MailChimp. And of course the whole project is built on my favorite unframework, Flourish.

So now it's live, you can go view the fruits of my labor at DIG Baton Rouge. It's the first of four sites that will be moved over to the new Lipsum CMS engine. I will spend the following weeks, tweaking, adding new features, fine tuning and bug smashing. I'm incredibly proud of what our small team was able to accomplish in such a short time. Lipsum represents a solid technical foundation on which we will build the future of our publication sites. It was not easy, but it was necessary, and I for one am glad we took the road less traveled. As Joel Spolsky famously wrote, "If it's a core business function -- do it yourself, no matter what."

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.

Auto-timestamps in Flourish

This will be a short post, I just wanted to share a protip for anyone using Flourish and in particular using the fActiveRecord ORM. fActiveRecord is pretty awesome, with it and fRecordSet I find myself very rarely having to drop down to raw SQL, although for some reports it can't be avoided and then fORMDatabase::retrieve()->query() is your friend. Anyways one of the really cool features about fActiveRecord is that it has a plug in module based off of hooks and I wanted to pass along something that I've started doing as a convention that's worked out really well for me.

I like all of my model classes to have a created_at and an updated_at timestamp that automatically do the correct thing to provide a very basic audit trail. This does not let you off the hook for doing actual auditing, but it is a nice way to do sanity checks and get some instant information about records. fActiveRecord makes this pretty easy to do, let's dive into some code.

[php]
class someModel extends fActiveRecord {
/**
* The fActiveRecord class provides the configure function to let you set-up Active Record hooks. Let's do that now
*/
protected function configure() {
fORMDate::configureDateCreatedColumn($this, 'created_at');
fORMDate::configureDateUpdatedColumn($this, 'updated_at');
}
}
[/php]

Easy as that you now have your created_ats and updated_ats working great for the someModel class. Here's the cool part though, because boilerplate code is stupid ugly code, if you want to use this across your project simply do the following.
[php]
class ActiveRecord extends fActiveRecord {
/**
* For this project every model should record created_at and updated_at
*/
protected function configure() {
fORMDate::configureDateCreatedColumn($this, 'created_at');
fORMDate::configureDateUpdatedColumn($this, 'updated_at');
}
}
[/php]

Now when you need to create a new model simply extend ActiveRecord instead of fActiveRecord and auto timestamps are done.

freelance

[caption id="attachment_875" align="alignright" width="300" caption="I\'m not sure what this has to do with Freelancing, thanks Google!"][/caption]

I've been hard at work making sure that Faveroo keeps humming along, pushing out new features here and there and making sure everyone is happy. The growth we've seen has been steady and we are continuing to push forward. Work has been a little hectic lately, if anyone ever tells you that growing a product and a brand is easy, you just punch them right in the face, I don't care that it's your Grandma, do what I say, I'm a blogger. Anyways this blog post isn't about my 9-5 it's about my 6-10.

I do a lot of cool side projects, some of them like Prosper are just for fun, they scratch an itch I have and I think I might be able to use them later. Some never see the light of day, they lose momentum or turn into something that I can't figure out how to make any money or help anyone with so they just languish on my hard drive. Lately I've been trying to break into the freelancing stuff, I thought, how hard could this be, I have years of experience, I'm willing to work for a reasonable price, I write high quality code really fast, and I tend to think that I'm a fairly nice person to work with. Well its been an uphill battle so far, but I want to share my thoughts with you.

Online freelance boards just suck. They do, I hate you, I hate them, hate is really the only emotion I can feel about these boards. 90% of the posts are for ridiculously ill-defined or impossible jobs, 99.999% of the replies are someone in some third world country willing to write the new facebook for a shiny new nickel, and there is no way to get the point across to anyone that you get what you pay for. I've yet to find any useful paying work from these sites.

Craigslist is a mixed bag so far. When I started on this journey I got some help from a friend who basically just spammed me with every blog post they could find on the subject of freelance consulting. A nice thread on Hacker News, here's a Two part series by Ryan Waggoner on freelancing. One of the pieces of advice was to use Craigslist, so I tried that, there is a ridiculous volume of stuff in the Computer Gigs section, and since you aren't constrained by geography you can apply to a huge amount of them. I tried this for a few weeks but after sending out tens of emails, most custom written specifically for the project and only receiving one reply, I decided to try another avenue. I'm not giving up on the Craigslist approach yet, if for no other reason then the absolute mass of postings there.

Friends of friends. Right now this is where I've seen my only success. I'm currently working on a project for a friend of a friend and so far things are looking great. I'm enjoying the work, sweet lady PHP with my favorite unframework, Flourish, and I'm making great progress. It's been a good project to work on so far, the client has been great to work with, and the code has been flowing. I'm sure there's a downside to to this course, friends of friends will want you to do extra work for them for free or change things up as a solid, but so far so good.

Future plans. This blog post is part of it, but basically some self-promotion is in order. I'm going to be putting together an online portfolio of stuff I've done, Prosper is a nice large code base for someone to look at to see the quality of my PHP code. I realized I just need to get my name out there as an option, the current project I got was because I happened to tell my friend I'm trying to start consulting on the side, bam, first paying gig. I'm going to keep fighting the good fight on Craigslist, maybe come up with a more efficient system for submitting my name into consideration for postings.

If you need a good PHP programmer drop me a line in the comments or send an email to ihumanable@gmail.com and maybe I can write some awesome code for you.

sanity please

I'm sure this tale of woe will be shared by many of my web development colleagues, it has to do with Facebook. As a web developer I have to pay a Facebook Tax, Facebook has an API (I think they might be up to their fourth API now) and they have 500 million people, and so management everywhere wants their product to integrate with Facebook. Here's the problem, Facebook fucking sucks at documentation.

There are as far as I can tell at least 4 competing technology stacks going on over at Facebook: FBML, Javascript SDK, Old REST API, and Graph API. There could be more, some of those might not be fully APIs and are just components, I'm not really sure. I've been reading the pages at the official documentation website for weeks now trying to wrap my head around this thing. Maybe it's just me, maybe I'm dense or something, but I can't seem to figure out what the fuck is going on or what I should be using.

Here's a great example, let's say you want to integrate Facebook Connect (if that's still a thing, I'm not really sure), but more succinctly you just want to allow users to sign in using Facebook as their identity provider. How are you supposed to do this. Well there is this section on Single Sign-On that looks promising. But then later on if you follow the link to learn more about the Graph API you will find a section about Authorization that will lead you to this page on Authentication which I think is showing you how to do the same thing, maybe.

The problem seems to be too many ways and pages explaining the same thing or slightly different things, I just want one canonical authoritative place to look that says, "This is the API you MUST use for Authentication." I don't think that is asking too much. But I'm sure once I finish my primer on OAuth 2.0 and figure out how the extended permissions works it will all be more clear.

The API could be forgiven for giving you more than one way to skin a cat, if it then gave you specific details on how this stuff actually works. Let's say I want to build a website that displays events and then let's people use my website to mark themselves as attending that event in Facebook, is that possible... I have no idea. Here's a section of the Graph API about Publishing data to Facebook and it might be in there somewhere, but I can't tell. I guess I'll have to play around with how this supposedly RESTful API works when I have some state, maybe if I've successfully negotiated an OAuth Secret Consumer Token UID then I can call /EVENT_ID/attending and that will mark me as attending the Event with EVENT_ID, it seems to make sense a little bit, but the extremely helpful description of "attend the given event" and the arguments of none make me have to play around to figure it out.

Seth Call is similarly frustrated and makes a very nice detailed case for why the Facebook API is so woefully inadequate. I couldn't agree more, and I hope that help is on the way.

The problem I'm running into now is frustration and discoverability. There doesn't seem to be a particular flow to these documents, they are just disparate documents hyperlinked together in no particular order. I'm new is there a tutorial or common use case section, maybe somewhere buried 9 links deep. If you are going to embrace and extend then at least have the common courtesy to make our lives easier as you try to take over the world.

Facebook seems to have too many developers working in the API space not communicating, the "Old" and "New" APIs overlap in some areas and miss each other in other areas, there's no definitive answer on when support will end for any of the "Old" APIs, is it safe to use the "Old" REST API for functionality the Graph API doesn't support or will they turn off the tap at some point. When trying to navigate through the documentation it just feels like they made someone do a braindump and didn't try to organize it in any fashion.

Well I'm going to head back in because with the draw of 500,000,000 potential users we can't afford not to pay the Facebook Tax, which is a real shame considering how shitty the Tax Code they published is.