Greg Crisp

Technologist. Pragmatist.

The Industrial Software Press

Most bit plumbers I know either love or loathe Eclipse. Or they just make fun of it. I keep multiple copies and multiple versions of Eclipse on my laptop. It may have it’s quirks, but what product doesn’t? It’s a well-debugged platform, with multiple years of use by hoards of software folk, making it as mature and stable as any complex software can be. More to the point, it’s a power tool for software development. Like unto an industrial software press.

Integrated Development Environment (IDE): An IDE is to a bit plumber as Photoshop is to a graphic designer. It’s where you spend most of your time each day, except perhaps for your instant messenger. An IDE is like an industrial-grade software press. If you know how to use it, you can get more done in less time.

Eclipse is open source, so if I really were a masochist, ever had desperate need, or it looked like it would be reasonably profitable, I could choose to modify it in any way I saw fit, and even provide those modifications to others. Is that true of other IDE’s? It wasn’t back in the days when I cared about other IDE’s.

Eclipse is everywhere. Most of the software tooling companies that once built custom tools have abandoned proprietary platforms and migrated their Unique Selling Propostion tooling to the Eclipse platform. The two notable exceptions being Microsoft and Apple.

Even non-Java languages are moving there. The last four PHP projects I did were managed in Eclipse. Even Macromedia/Adobe went there, ala Flex. Aptana supplies an Eclipse hosted RoR/Javascript IDE.

I sometimes hear people whining, about Eclipse specifically, but also about IDE’s in general…

  • “Iiiiiiiittt’s slooooooooowwwwww.”
  • “Iiiiiit uses tooo much meeemorrryyyyyyyyy.”
  • “It takes up too much space on my haaaaaarddriiiiiiiive.”
  • Etc.

What do you do for a living? Do you grind code? If so, and you’re not using an IDE, you’re probably not as effective as you can be.

Let’s imagine a different profession that also has “hackers”.

If you were a master carpenter, notwithstanding the current housing bust, you could always find work, and probably more interesting work than nailing up 4×6’s for a stick-built house. You’d be building ornate, custom cabinetry for rich people who already have too much money to spend.

A annecdote on pragmatism and carpentry: The house I’m living in right now has a really nice, custom cabinet in the master bath. I’m told the previous owner, who supervised the second half of the renovation, paid $4500 for this jewel. However, the driveway is so narrow that we’ve worn a rut with all the times we’ve gone off the edge. That money would have been better spent on a wider driveway. How is this relevant to the IDE topic? It isn’t.

Imagine a master carpenter’s workshop. If you look around, what do you see? Everywhere? Tools. Tools for working with wood. To be good at the job, and to be competitive with the other master carpenters out there, you have to be fast and efficient. You need tools, and lots of them.

Do you work with code? Grind it all day, every day? How many hours did you work last week? Last month?

As a bit plumber, when you look around your shop, which is your laptop, you should see tools. If you’re wasting too much harddrive space on pr0n or game graphics, you should put that on another machine, and stop complaining about the footprint of the tools that help make your mortgage payment every month.

Does your opinion differ? Any IDEA fans out there? Tell me why [so long as you're not going to whine about the Eclipse footprint]. Post your retort on your own blog and link back to me. I can use the link-juice.

Make Mine Wordpress

Today’s post is part of a group project for the Atlanta Bloggers group.  

I left Mambo as a CMS because: 1) it’s too complex for most uses, and 2) I ran in to major quality problems with many of the plugins I was using on [former] customers’ web sites.

When I rebuilt my personal site, I chose to switch to Wordpress. Here’s why:

  • Simplicity: The Wordpress administration interface is very clean and easy to use. The most used stuff [The blog] is easy to find, and the options are not overly complicated. Related to this, I was able to find a good number of minimalist themes, including the one I chose: Hemingway Reloaded.
  • Stability: There is a community dedicated to the platform, plus a large number of plugins. Also, the base code and plugins seem to be stable, at least more so than what I encountered on the Mambo platform. When something does break due to an update, the system seems to do a decent job of detecting the problem and turning off the offending part.
  • Language: I want to modify and enhance the system. Wordpress is built on PHP and MySQL, both of which I know. I briefly considered Movable Type, since it seems to also have a large community, but it’s based on Perl, I have neither time nor desire to update that knowledge base.

There were other minor reasons, including an API for offline editing, but these were the primary factors that drove me to Wordpress. I reserve the right to change my mind later.

Start a side project to do the things you WANT to do

You can’t always enhance your skills the way you want in the work you’re being paid to do on a daily basis.  Specific technology may not be compatible with your primary employer’s business need, IT strategy or the job role you presently hold there.

Read the rest of this entry »

The Right Way: Defining the Problem

Over the next few weeks, you’ll find here a series of articles that discuss the “right way” to build software for the web. To paraphrase John Galt: ‘ Right?  By whose standard?’  I am the man who has asked that question.

I’m going to start by channeling Alan Cooper and define the problem. Read the rest of this entry »

Spending 10 minutes one day to save 5 every day after

You’ve heard the saying “unable to see the forest for the trees”?  So many projects suffer needless delays on many levels because there is so much work to do, that time can’t be spent up front to reduce the overall effort.

Here’s a small, but specific example I encountered recently, and how I made things better.  A client has a complex, command-line oriented build process, which involves several steps to complete, each executed in a different location in the folder tree.

It’s really not that complicated, but executing all the change directory commands, followed by the build commands for each step is tedious, and also difficult to remember.  It’s a lot of typing.

To streamline this, I spent about 10 minutes writing some XP command scripts to execute these steps in sequence.  Also, to save time, brain cells, and keystrokes I made these command files’ names short [though unfortunately cryptic], and put them into a folder in my system path.

There are still multiple commands to execute [not all steps need to be executed every time, so it's not one script], but each time it saves at least 20-120 seconds of typing time, depending on what I’m working with.  Add that up over a whole day of building and debugging, you’ve got several minutes per day.

If you’re splitting hairs, this seems like a net loss, and insignificant on a single day, but on day two, it breaks even.  Every day after that, it adds up.  Think about what you can do with an extra hour every week?

How many other repetitive tasks could be automated?  What happens on a larger scale?  How much time could be saved over a long term project if you spent two weeks automating your regression testing?

Automation always seems painful initially, but the gains for repeated process are significant over time.

Your Performance Problem May Not Be What You Think

 

Performance problems can be hard to deduce, and the root cause is often not very obvious.  On a recent project, I ran in to a serious performance problem rendering part of a DOM tree.  Those things that were suggested as the probable causes, turned out not to be.  The root cause turned out to be not so obvious, and was only found through deeper analysis using good debugging and profiling tools, in this case, Firefox and Firebug.

Read the rest of this entry »

Optimizing for the right things

For a while now, I’ve been thinking about building a blog system of my own.  I did build a very basic blog engine in PHP once before, way back in 2002.  It worked quite well, but I never seemed to be able to commit the time to make it complete, which brings us full circle to the reason I have yet to get a big enough round ‘tuit to build something more, better. So to hell with it.  I’ve decided to use one of the off-the-shelf systems and be done. I’ve worked with Mambo in the past, but it’s too complicated, so let’s go with Wordpress.  It seems to be the right thing.