Ever get annoyed when your password manager doesn’t know how to fill out a form on a website? Or maybe it tries to fill in something you don’t want it to? If you build sites, here are some tips to save your users from similar annoyances.

Many times you can trace a bug back to a particular code change that was made. Or maybe it was caused by a package upgrade. But have you ever had something break when no code changed at all? How does that happen?

Today I realized something about myself, I actually really enjoy working in legacy applications. This may seem odd. It’s common to hear complaints about “how bad this old code is”, so why would I enjoy working in a difficult environment? First, it would be useful for me to define what makes an application a legacy application. I realize this may not be a universal definition for everyone, but here are the core elements I think of that make an application qualify as “legacy”:

Is git rebase a command to be avoided at all cost? I say no. Here’s one use case where I reach for rebase instead of merge.

Many of us have a seemingly endless backlog of tasks we could be doing. How can you figure out what’s most important, and use that decision to bring focus to your day?

Many developers feel overwhelmed with the amount of work they want to get done each day. Or they feel pulled in multiple directions and struggle to make progress on the important things. I can totally relate! One thing that helped me is keeping a work journal.

I was frustrated watching the news tonight, seeing reports of long lines of people waiting to buy lottery tickets for tonight’s $500,000,000+ jackpot. There are several angles of absurdity to consider here. For example, why all the excitement over $500 million? Wouldn’t any of these players be equally thrilled by $10 million or even $5 million? Another example: Several of the people interviewed, who had just bought hundreds of dollars of tickets, were unemployed, facing foreclosure, struggling to pay medical bills, and so forth. But putting all that aside, let’s just look at the math.

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.

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.

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.