- Culture
- Design
- General
- Marketing
- Networking/Systems
- Open Source
- phpSprockets
- Productivity
- Security
- Software
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- Coding Horror
- Innova @ Flickr
- Joel on Software
- Lifehacker
- phpSprockets on Google Code
- Smashing Magazine
Productivity Basecamp: First Day Impressions
Innova has tried a few things in the past to keep our projects organized. We have an internal Wiki that we use for sharing data, fileservers every five feet for document sharing, an inter-office Jabber server that keeps our IMs going. We use FogBugz to track bugs, Harvest to track time, and emails and sporadic meetings to tie everything together.
On larger projects that span more than three people, this tends to break down a bit. The individual tools are awesome, but emails and occasional face-to-faces just weren’t getting the job done. We just couldn’t keep everything organized amongst everyone with such an ad-hoc system.
Enter Basecamp.
Productivity Being a Missionary
If you’ll excuse me for a few minutes, I’m gong to be a language missionary. I could apparently be a better programmer if I avoided this, but we all have our parts to play, and I like mine.
At Innova, our default language is PHP. We make this decision by default, it’s assumed that a new project is going to be done in PHP, because that’s what we use for everything else. And it’s certainly the lowest-common-denominator amongst our crew: Eddie enjoys C#, and Keith is in love with Python and Ruby, but we can all work and be productive (for varying levels of productive) in PHP.
Sometimes, a tool emerges that’s simply better. It maps 1:1 to your domain. For Innova, that’s writing kickass web apps, and the tool in question makes PHP look like an amateur rig. Imagine a major metropolitan newspaper that’s got a fleet of Xerox machines cranking out the Sunday edition, vs. the industrial printing machine they’ve actually got. That’s the difference. You can make some damn awesome things with PHP, for certain, but that doesn’t mean that you should overlook better tools when starting new projects.
Now, what do you do if you have an existing project that could benefit from ten tons of awesome framework, but you can’t just freeze the current codebase and begin porting? Do what I do: every time you’re spending time writing code to fix something that’s a non-issue if you’d only switch tools, mention it. Don’t get in anyone’s face, don’t do a victory dance, just point out that if you were using X, you’d be busy fixing real problems and not wrestling around with solved problems.
Then write blog posts with no less than five subtle links. Subliminal messaging is powerful stuff.
Being a missionary has its time and place, of course. Similarly, it goes without saying that there’s definitely a cost in switching languages and frameworks, and that sometimes that cost is too steep. But that doesn’t mean you shouldn’t be taking every opportunity to point out places where improvement can be had. I care about the company I work for, and I want us to produce the best possible work we can. Suggesting fixes for common development problems we’ve experienced is part of that caring.
Productivity This Explains Everything
Design, Open Source, Productivity Writing Drupal Themes
One of the many things that I do here is create custom themes for Drupal. It’s kind of an artsy thing, and since I’m the resident designer (or so it says on my card), I tend to be a bit artsy about it. One of the things that being artsy means to me is being off-site. The Innova office is a very cool space, but I like to have a change of pace every once in a while. A change of lighting or a change of atmosphere does a world of good.
But one thing that becomes a problem is remote access. Sometimes, I really like to get off the beaten path, and away from it all. I have a laptop, but I’m not going to be able to connect to anything when I’m sitting in the middle of a park. And even if I could, I certainly don’t want the lag time in connection, especially if I’m tweaking css. “Okay… just one more pixel to the left. Right. Save. Okay… Now I’ll go make a sandwich while that goes through the VPN.”
In be beginning stages, I like to do everything remotely. Most of the time, the client has only sent a spec, maybe some rough ideas about what they want the design to look like, and maybe some color ideas and or photos. Usually, I don’t have any content at all, besides a tentative site name, and I can’t sit around waiting for content.
To develop locally, and rapidly, I use MAMP (what do you want? I’m on a Mac). You can do the same thing with a windows machine, with a stack called XAMPP. It’s a full Apache-Mysql-php stack that you can kickstart whenever you need to, and can shut it down when you don’t. In short, I love the thing. I didn’t at first, but I didn’t like Drupal at first either.
Until I get content here’s what I do:
- I have two different setups: one for Drupal 5.x and one for Drupal 6.x.
- I keep two seperate databases: called drupal5 and drupal6. These databases contain only the most generic of content. It’s basically all lorem ipsum but it has the content that I expect clients to want (stories, pages, blog entries, etc.)
- Copy one of the stock themes in /themes to /sites/all/themes/projectnamehere. This keeps all of my new themes separate from the stock ones, and if this directory gets clogged (which it will after a few projects) it’s easy to offload the directory to somewhere else.
- I’m not usually trying out modules at this phase, but if I do need to, I try to keep them sequestered out from the stock modules and keep them in /sites/all/modules. That way, I remember that there are modules that I need to upload to the production environment.
And away I go. I can take my laptop anywhere I want, and I can sit down pretty much anywhere and get things knocked out pretty quickly.
Getting out of the office is often a great way to get things done. If I can work without a network connection (as I generally do when working as outlined above), it’s a great way to shut down a lot of the distractions. I can’t check the news. I’m not going to be pinged with IMs. I’m not going to be sidetracked with new mail. It’s a lovely world out there, so go out and get to work in it.
Productivity, Software SVN choking on TextMate’s metadata files? Not any more!
The Innova Mac Guys, whose number swells daily, tend to use TextMate as our editor of choice. Most of our files live on SMB-mounted network shares from our various Linux development servers.
TextMate has two problems with this scenario: one, refreshes can take a while because TM is rereading every file in the project directory. If you’re on an Intel Mac, and you suffer form this “feature”, try ReMate, which will offer a “Disable Refresh on Window Focus” option.
The other issue is that we use SVN for our revision control. TextMate, when it can’t put setxattr metadata on a file, such as over our aforementioned network shares, it defaults to writing a bunch of .\_filename files everywhere. This is fine, but now running svn status produces a list of garbage: SVN will happily inform you that you have a hojillion .\_filename files lying around that you haven’t told it what to do with, which makes locating the one actual file you want to know the status of pretty painful.
You can make TM stop generating these files by doing a defaults write com.macromates.textmate OakDocumentDisableFSMetaData 1 at a terminal (with TextMate closed), but I find that to be overkill. The metadata stored (caret poisition, bookmarks, what text is folded, etc.) is useful as hell to have.
Or you can also set the svn:ignore property on every single project you have, but that sucks when you’ve got 50-some odd projects. Besides, this isn’t really a project-specific property, it’s more of a global, machine-level, “do not touch” sign on these files.
So, it should come as no shock that SVN has a global and a per-user configuration file, On sane, UNIX-y oeprating systems, you can find your personal config at ~/.subversion/config. The line you’re looking for is global-ignores. My default config had this line commented out, so uncomment it. By default it looks like this:
global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store
Each entry (separated by a space) is a glob to match files against. The default line has all of the standard things a UNIX geek would want to ignore: object files generated by the C compiler, files ending in ~, and even the Mac OS X .DS_Store metadata file.
To get this to cooperate with us, add the glob ._* to the list:
global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store .\_*
This will force SVN to ignore those ._filename files when doing svn status, svn add, and svn import, effectively making these commands useful again — especially when working with Windows users whose file managers don’t hide dot-files for them!