Meta

I recently had the opportunity to work on a PHP application that was written by a student in 2004. Before the time of PHP frameworks and separation of MVC, when applications had SQL and HTML in the same files. Each page was a form that submitted to itself. Everything contained in one file per page. Pretty crazy, right?

Crazy like awesome. I had so much fun working on features for this old application. It wasn’t just nostalgic, it was like comfort food. Easy and delicious. I’m not really sure how comfort food is “easy”, but just go with it. I was practically begging to do more work on it.

I can’t imagine myself creating a new application like this from scratch, but I’ve been thinking about the benefits. Anyone with just a tiny bit of PHP experience could pick it up and maintain it, there’s no technology ramp-up time. A project like this could be orphaned and passed around between anyone. It could be used to teach people basic PHP within the organization. Say, people who are so Java-centric they refuse to learn anything new or different.

It was a good opportunity to take a look at the past and see what we’ve lost by going forward with technology.

Recently a couple of groups here at work were brought together to try and standardize on a few things. The Software Development Community of Practice! Style guides came up. Everyone said they had no style guide and everyone agreed having a style guide would be worthwhile.

I had spent some time writing a style guide (customizing) so I was interested by this. I got to reflect on my style guide, how I’ve referred back to it in the year since I put it out there, and how I think it has helped or could help in this forum.

See the reason I created this style guide is not all that different from the reason these communities of practice are looking to create style guides. I was/am writing open source, and on the hope that someone will want to contribute to the project, I want a rule set defined so people won’t submit something unreadable.

For the community of practice, it’s a little different, but the spirit is the same. What they want is to have the option to point at something when a fellow developer is writing horrible code. The premise is you have a new developer and they don’t know how to write clean code.

The problem I have with this is everyone knows how to write clean code. And by everyone, I mean every professional software developer. If they’re not writing clean code, they’re not professional. Now that of course means if we are using student employees or taking in work from unknown outsiders (Open Source), that we are risking poorly written code being introduced and should therefore have a style guide. But if the premise is to have something for professional developers, I think it’s a waste of time.

Most style guides are 95% the same and we’re not talking about trying to enforce the 5% that is going to be different between individual developers. If ever a problem comes up with software developers where one is trying to say another’s code style is wrong, they should be able to say “google a style guide to see what best practices are” and be done with it.

Sadly, I’ve wasted more time arguing this than it would have taken to just agree, pick a guide that no one will ever use and move on.

So I spent the last few hours changing all links in one of my current applications to do a “hashbang” sort of call instead of loading new pages. This significantly increased speed when using our clunky LMS.

This was especially annoying because our LMS forces changes with <a> tags.

What made this especially easy to implement was that I had already made all links go through a smarty plugin so altering all links in the application was just in one file and I could make those links specific to whatever authentication scheme / LMS the application is living in. So I just had to alter that plugin and the LMS specific layout and bam. The only thing that’s not covering is form submissions. But there are only a couple of those, so I’m not going to stress about that.

The highlight of that being that with hashbangs, you have to go to the client and then back out, which reduces speed on the initial pageload. So twitter went a little fancier 6 months ago and used the history api’s PushState.

Implementing the hashbang urls was a very small amount of code, so I’m going to move forward with that for now, maybe next time I get a chance to do some research I’ll focus on converting that to PushStates.

Yesterday the New York Times posted an interesting article about research in the field of inactivity studies and the trend of workplaces transitioning to upright workspaces (standing desks), particularly at top tech companies. There has been a steadystream of articles and blog entries about the topic over the last few years. Is it just a fad? What are the implications for productivity and learning (if any)?