Tech Blog :: tools


Oct 30 '11 6:42pm
Tags

Great list of new dev tools from Smashing Magazine

Here's a really superb list of "coding tools and javascript libraries for web developers" from Smashing Magazine. Some of the ones I'll be playing with in the next few days:

  • Tilt, Firefox DOM inspection in 3D.

  • Money.js, an open source API and JS library for currency exchange rates (the code on this will also be good for improving my Node.js techniques)

  • Bootstrap development toolkit

  • IE VMs - might cover more versions of the evil browser than the VirtualBox I use now.

  • a bunch of remote debuggers for mobile, haven't tried them yet

  • Less App - I've been using this one for a long time

  • Has.js - test your JS environment for available constructs.

and a whole bunch of others. After reading that post, I also added Smashing Magazine to my RSS reader.

Jul 19 '10 11:09pm

Pseudo-Best Practices and Tool Creep

Someone wrote to me recently asking if I could help them set up a Drupal development environment for an outsourced dev team. I don't have time and declined the job, but continued a brief correspondence about the requested project requirements, which I thought were interesting:.

The requirements included (each a full installation of a 3rd party software package):

Whoa.

This is the list of tools that you'll find by googling "best practices development environment" or something like that. But it's massive tool creep. Several problems I see here:

  • Toolsets need to grow organically. Dumping 10 enormous tools on a brand new team (outsourced/remote/global, let alone in the same office) is like throwing a 1000 page HR Handbook on a new employee's desk.
  • Most of these can be [ironically] outsourced to 3rd party services. There are several excellent Git hosters for example; there's no need to host a repo yourself (unless you have some crazy security requirements).
  • Tons of redundancy. Both SimpleTest and Selenium can do client-side unit testing. SimpleTest also does server-side; ditch Selenium.
  • Each of these tools requires maintenance, upgrades, TLC. The team is hired to develop a product, not maintain other companies' software, why not focus on the essentials?
  • Capistrano is great. I suggested they use Webistrano, however, and write a 5-line Ruby recipe that tells Drush to run SimpleTest before deploying. No need for Hudson anymore.
  • Issue Tracking, Wiki, and Forum? I worked on a team with Jira and Basecamp and that was more than enough for critical details to get lost. "Did you see my message from last week?" - "Which tool did you put it in?" - "I think Basecamp, but the specs are in Jira, and the wireframes in DropBox, and the timesheet in Google Docs" ... recipe for confusion.
  • This is a Drupal project. I asked several of the best Drupal developers I know if they've heard of Hudson; they hadn't. (I only have because I worked near a Java team that demo'd it for me. I didn't think it would be helpful for my workflow.) Having a list of tools like this on the job description for developers is likely to be a turnoff. Again, focus on essentials.

So I wish this project all the best. But I think they'd be much better off starting with some simple, well-known tools: Drush, SimpleTest, Webistrano OR Aegir (not both), Basecamp OR Jira OR Atrium. Better to over-use one really good tool than underuse half a dozen tools, in my opinion.

Thoughts, comments, rebuttals?