If you haven’t heard of it, go take a quick look at Twitter Bootstrap. As you click around the github project site, you’ll get the sense that all these layout guides and widgets and buttons and icons look oddly familiar. Part of that is the fact that Twitter itself is built with this style package. But even beyond that, many many many many sites are using this tool kit as well. I’ve sensed a little backlash, mostly from designers, at this rampant use of the Twitter Bootstrap. At a certain level, I agree, but I’m here to talk about why I love Twitter Bootstrap.

First, let me make it clear that I am not a designer. I am a developer. In fact, I am most comfortable doing server-side development. That should give you some stereotypical idea of what my design skills entail. So coming from this context, you begin to see why I love the Twitter Bootstrap so much. Very often, I’ll get an idea for an application but quickly get bogged down in spinning up a user interface for it. Sure, I could just go totally utilitarian while building the application, but it’s hard to put your heart in something using default browser styles. But now, with Twitter Bootstrap, I can download a small package of images, css and javascript and immediately have default styles that look halfway decent. I even have sane stylings for forms, buttons and other useful widgets. I have a simple way to do grid layouts and side bars and navigation bars and all those little things that you use on every single site.

Once the idea comes to fruition, I work with a designer to make it look less generic, but Twitter Bootstrap gets me from idea to implementation without bogging me down in the parts of a web project I find less interesting and often frustrating.

Over the next week, I’m going to be adding quite a few short posts chronicling my experience at the CodeMash conference. The event is a few years old, but this is the first year I’m attending.

Just arriving at the Kalahari resort, I can already tell this is going to be quite unlike any conference I’ve previously attended. I had a 7 hour drive from Milwaukee, so I headed straight to my room to crash, but I’ll be exploring the facility more tomorrow. Speaking of the rooms, I was pleasantly surprised at how spacious it was and all the amenities I had, especially considering the low rate. Kudos to the organizers for getting such a great deal for attendees.

CodeMash doesn’t even start until Wednesday, so I have two days to bulk up on sleep and get the lay of the land. If you’re attending, drop me a note and let’s get together for a meal or just some drinks.

Date and time manipulation is an area of programming that seems relatively simple on its surface, but lots of danger lurks just out of view. How hard could it possibly be to take a date/time and add 1 day to it? or 1 week? Piece of cake, right? You might do something like this:

$eventTime = strtotime('2011-09-15'); 

//add one day to the date
$newEventTime = $eventTime + (24 * 60 * 60); 

//expects 2011-09-16 and will USUALLY work
echo date('Y-m-d', $newEventTime);

We’ve likely all seen code like that and probably written some ourselves. Here’s another way to do it, this time using the built in date/time functionality in PHP.

$eventTime = '2011-09-15'; 

//add one day to the date
$newEventTime = strtotime($eventTime . ' +1 day');

//expects 2011-09-16 and will ALWAYS work
echo date('Y-m-d', $newEventTime);

These two pieces of code are functionally equivalent, right? Well, the answer is: most of the time. It’s the edge cases that can really drive you nuts though. What if you’re right on the boundary of daylight savings time? In these cases, a calendar day may be 23 hours or 25 hours in length, not 24 as you expect.

The lesson here is to use the built-in functions to their full potential. Don’t reinvent the wheel or be needlessly clever. This is a lesson I have learned the hard way while debugging in frustration. PHP has some incredibly powerful date manipulation and parsing functionality. Now go check your code for 24 * 60 and fix it before it bites you (and it will eventually).

Note: Part of the inspiration for this post was Derick Rethan’s excellent book php|architect’s Guide to Date and Time Programming. You might not think this subject could possibly fill a whole book, but you’d be wrong. Like I mentioned above, this topic is deceptively simple and I highly recommend adding this book to your library.

Most web sites use third-party code. This code comes in a few different flavors:

• client-side libraries (jQuery, dojo)
• server-side libraries (form mail scripts, oAuth integration)
• server-side frameworks (Zend Framework, Symfony)
• entire applications (WordPress, Joomla)

As a developer, when you selected one or more of these tools, you hopefully picked a project that was active and well supported. This means there will inevitably be upgrades to that third-party code. Some of these upgrades add features, but most upgrades also include bug fixes and security patches.

Blindly ignoring these updates is an (all too common) option that developers take once their site is launched and “done.” This can get you into a lot of trouble with a client when one of those unpatched tools is used as an attack vector to compromise the site or server. Sticking your head in the sand is rarely the right decision.

But the other factor to consider is that upgrading these tools takes time. In addition, it’s not uncommon for an upgrade to break your code. Maybe it’s a purposeful break with backward compatibility or maybe it’s an unintended consequence of how you integrated with that third-party code. This is one big reason why some developers ignore the upgrades, or at the very least, ignore them as long as possible.

If you are working on your own site on your own server, the issues are relatively clear. You can personally decide how much risk to accept for your site and server. You can decide how much time to invest in upgrades and testing. But things get murky when it’s a client site. Is maintenance of these third party tools billable? What about breaking changes? What if the client doesn’t want to pay, but the site is hosted on your server and you don’t want the exposure of unpatched security risks?

How do you handle this? What are your clients’ expectations? Leave me a comment. Unfortunately, I don’t yet have a great answer to all these questions myself.

I’m a huge fan of php|architect: the magazine, the books, the online training and especially their conferences. Living in the Milwaukee metro area, I have a short 90 minute drive to the flagship php|tek conference they host in Chicago each year. My schedule doesn’t always allow me to attend, but I do everything I can to make it. I’m still putting into practice the things I learned at php|tek 2010 and I regularly keep in touch with the many friends I met there.

That being said, it came as a very welcome surprise today when I opened my mail and found an invitation to CodeWorks 2011 in Madison, Wisconsin! CodeWorks is a single-day, single track conference focused on PHP, but historically, it’s stayed pretty far away from Wisconsin. I suspect this is because we already have php|tek in our backyard, but I always lobbied hard to have a CodeWorks stop near us as well. Let’s face it: not everyone can take a week off work to attend php|tek, not to mention the travel and hotel expenses. Don’t get me wrong, it’s worth every cent, but for those that haven’t experienced it firsthand, it may be a big pill to swallow.

With a CodeWorks coming to my home state, I am going to sing (or at least blog) about it from the rooftops. I want the Madison event to be a success so there’s a higher likelihood it may return in 2012. I’ll be preaching about it at our next several Milwaukee PHP meetings, as well as on Twitter. With the low cost and the location, if you are a PHP developer in southern Wisconsin (or even northern Wisconsin or Minneapolis), you have run out of excuses not to attend.

Get your ticket by August 13 and it’s only $60. What are you waiting for? Go sign up now and I’ll see you there!

WordPress has a concept called shortcodes. They’re very handy for inserting chunks of text or functionality with a simple text syntax. For example, one of the stock shortcodes allows you to type [gallery] in a post where you want a photo gallery to appear. But the real power is exposed when you start building your own shortcodes.

A while ago, Scott, our Internet Marketing director, asked me to whip up some code that would allow him to display a different phone number on a page based on how the visitor got to the site. If they came through Google AdWords, we would target their specific city and provide them a local number, but this also allowed us to track AdWords clickthroughs all the way to actual phone calls. Even better, when someone entered the site with this contextual data, we stored it in a cookie, so that if they visited the site in the future, we could continue to provide the most relevant phone number.

Fast forward a few months and Scott now asks for this same functionality, but as a WordPress plugin. I looked around and found a few existing plugins that handled dynamic short codes and some even worked with similar logic on the query string and cookie, but none were a great fit. The one that looked most promising had been abandoned and didn’t work with any recent versions of WordPress, so I decided to start working on one myself. A couple hours later, version 0.1 of my Dynamic Text plugin for WordPress is up on Github and at least as functional as my original non-WordPress code.

Feel free to try it out yourself and share any feedback or suggestions you might have. Once I get through enough of my feature list, I’ll publish it on the WordPress plugin directory as well.

Let’s face it: there is a lot to know as a programmer. There is the syntax of your preferred language(s), the syntax and function library of your database technology and you probably have some sort of framework or common library containing dozens, if not hundreds, of classes on top of that. This can be overwhelming at first, but most programmers recognize the folly in trying to memorize everything. The reality is you probably only need to commit a small percentage of that knowledge to memory. The rest can be assisted by your IDE, the documentation or an Internet search.

Lately, though, I’ve begun wondering if programmers might take this notion too far and rely too heavily on their “extended memory.” This thought occurred to me as I was browsing my Google search history. I saw a couple searches come up repeatedly every few weeks over the course of the last several months. Could it be possible that I was really searching time and time again for the same answer to the same question? It was a scary thought.

That evening was our monthly Milwaukee PHP user group meeting, so I decided to bring it up as a question during introductions. The consensus among the group was pretty much the same pattern I had recognized in my own search activity: people were relying very heavily on search engines in their day to day work.

So I decided to try an experiment: cut myself off from this extended brain; force myself to work without that safety net. Would I become helpless? While it was definitely a difficult adjustment at first, I quickly realized that by forcing myself to recall the answer to the question at hand, it became easier to recall each time. I realized that much of this information I was repeatedly searching for was really rattling around in my brain all along, but by reflexively “reaching” for Google, I wasn’t giving myself a fair chance to remember it on my own.

I came to the conclusion that just because we can’t memorize everything, doesn’t mean we should memorize nothing. In fact, I’d wager that many programmers have committed less than they should to memory if they want to work at peak efficiency.

The long term result of this experiment is that I am far more judicious in my use of the all-powerful search engine for my daily work. I haven’t cut myself off completely, but I am far more conscious of what things I’m searching for and how often I’m relying on the hive mind. Overall, I have no doubts that both my productivity and my confidence have increased dramatically. Give it a try yourself and you might be surprised at the results.