BlackBox

I’ve been working on Chama recently and have been making some good progress. One of the last big hurdles before getting all of the Model, View, Controller generation working has been:

1. Connecting to a database and gathering metadata – 90% complete (just have the relationship, primary key, foreign key stuff to work out)
2. Getting Chama packaged up as a real distributable app that you can download and get up and going quickly

Rather than go through a whole bunch of Ant copy scripts and integrating that with my Maven build I decided to write a plugin that would copy everything over into a specific directory structure and zip up for me (and I can also add in the tar.gz stuff real easy now too). I gotta say it wasn’t too difficult, although the docs leave a lot to be desired in this department. With all the plugins out there you would think this would be more fleshed out, especially since they want everyone to move away from the old Jelly scripts that people wrote in Maven 1. Anyways, it’s fairly simple to do with some caveats.

• There appear to be no docs on what all the custom expressions are such as:
  • expression="${project}"
  • expression="${project.build.directory}"
  • expression="${component.org.codehaus.plexus.archiver.manager.ArchiverManager}"
• Or if you can actually use expressions like these when setting default values of properties (you can, at least that’s what I’ve gathered by looking at other plugins)
• And if you do or do not need to have getters and setters for your variables that you’ve “annotated” (I say that in quotes because it doesn’t act like true annotations, or at least there isn’t a package in Maven called annotations where you can find docs on all of these)
  • My assumption is that at least the setters are necessary so that it can use those to populate the variables you want Maven to populate your plugin with)

All that said it was mostly easy to write my little packaging plugin as I was willing to dig through the source code of some of the existing plugins that were doing similar things (maven-assembly-plugin and maven-war-plugin). That isn’t to say that I’m 100% sure I understand exactly how everything works (good idea but not 100% .

If I get a chance I’ll see if I can contribute something a little more to the plugin docs than what is there currently because others shouldn’t have to do what I did to get through this and it isn’t that difficult once you know the secret handshake.

This post started as a seed from interviews that we are holding for the project I’m working on for my day job (Kuali). The vast majority of the programmers that are working on this project are the cream of the crop from each institution. That isn’t to say that I’m one of those or that the rest of the programmers are not excellent, they are, but it’s a higher standard. This standard makes us that more critical when we choose new programmers that are going to come on to the project.

One of the qualities that I tend to look for (without really knowing it until recently) is passion. When someone comes in and just does the bare minimum or a little above that to get the job done it tells me that they have no passion for what they do. All of the good or excellent developers that I know all have a passion for programming. To them it isn’t just a job, it’s something they enjoy doing and they enjoy expanding their horizons, not because it is a part of their job, but because they truly enjoy it.

I think that this passion extends further than just this though, most of the good programmers that I know are passionate about other things and aren’t afraid to share their passion with other people. This of course can lead to either a healthy discourse or heated debate in the office or elsewhere , this is what happens when you get passionate people together. Of course one of the tricks of a truly good developer is to know when to put your passion (and your ego) on the shelf for the betterment of the project or task at hand.

Further along this line of thinking lies creativity, in his piece ”Hackers and Painters”, Paul Graham describes the commonality between hackers and painters

What hackers and painters have in common is that they’re both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things. They’re not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.

And honestly I couldn’t have said it better myself, but I’ll elaborate on this idea a little further based on my personal experience. Every really good programmer that I’ve met has had some other creative bent, most of them have been musicians of one form or another, or they have really been into photography, painting, etc. I think that this derives from the desire to create, to make. One of the reasons why I like programming is because I like to make stuff, for me this has also extended to music, film, and writing (in fact I started out writing fiction way back in grade school). But it is the act of making, the act of getting something to work that fascinates me still. Whenever I hear a problem that needs a solution my mind immediately shifts into “maker” mode and I start thinking about how I could so do that – if only there were like 20 of me all of the cool ideas I’d ever had would be done .

This all leads back to passion, if you are truly passionate about what you do then you will do better at it, it really is that simple. But that doesn’t mean that that is where your passion has to end, I would say that if you are currently playing around with the idea of learning how to draw, or learn how to play an instrument, do it, don’t wait.