Ben Tomasini Welcome Guest | Login or Register

There is a discussion going between Howard and the Apache folks over at the Tapestry Dev mailing list regarding using Git at Apache.

http://old.nabble.com/Re%3A-Status-of-Git-at-Apache-ts26582579.html#a26616699

Git’s would essentially give non-committers the same tool set as committers, greatly enhancing Apache’s community and promoting greater meritocracy.  It sounds like the sign off feature of Git would address Apache’s IP concerns. Considering the compelling “social development” model Git, the success of sites such as GitHub, and the mass of folks independently moving from SVN to Git, I expect that eventually Apache will migrate to Git.

Getting a handle on an inherently complex system is satisfying.  I enjoy working a sound mixing console for just that reason.  A friend of mine said that heaven for me would be a room full of knobs that I could turn and tweak to my hearts delight, because that is how I tend to operate a sound console.  Some of these adjustments do nothing but make me feel like I am in control of the output.  Some of the adjustments actually make a difference.  Most of the time I get the sound “just about right.”  Rarely to I really nail it and get it right.  You know its right because the final mix hits that “zone” where the blend is so natural and full.  Musicians recognize the zone and they get better as they play in it.  The audience feels it and becomes more engaged with the performance.  These factors build on themselves in a self-reinforcing cycle.

As a kid I would make my stereo sound “cool” by turning up the bass and the treble, creating the classic “V” EQ curve.  Of course, the improvement to the sound had more to do with compensating for the cheap speakers I was using than any kind of real signal improvement.  And of course, such and approach on a live sound system would make a listener wish to be temporarily hearing impaired.

There are “zones”, and there are “zones”.   As I figure out a system I am able to reproduce a certain level of quality with some regularity.  Often there are lingering problems which seem intractable.  The vocals are too boomy or harsh.  The piano sound seems to swell uncontrollably at certain notes (in the key of E for some reason).  “Zones” with problems are fine.  They produce an overall pleasing experience because usually I can control these problems with aggressive equalization.  But they are still limited.  Every once and a while I am able to get past band aids for these problems and resolve the real issues.  This produces the “zones” that approach perfection.

I am not a perfectionist (most everyone who knows me may disagree). I just enjoy when I can manage to make a system to produce closer to its full potential.  Consider the problem of sound mixing console.  You average channel has 15 controls which affects its output, and your average mix has about 24 channels.  Add in the other 20 master controls and you have 380 factors to determining the output of the system.  The mind is able to group these together with common patterns, so the problem is not as complex as it may seem.  But the fact remains that any of those 380 controls may be ruining your mix and killing the “zone”.    The challenge in mixing sound is not so much getting most of them right, as narrowing down the spoilers.  At 40 controls “out” you have big problems.  At one or two out, you have fixed all but the most subtle ones.

The last problem I chased down was with a male lead vocal using a Beta 87A used at close distance.  It had a nasty “boomy” quality to it.  I cut back about -12dB on all kinds of frequencies from 250Hz to 600Hz.  While the voice was listenable, its body was diminished, and I still couldn’t push the volume to a the level I wanted.   I sorta figured this was just a limitation of the room acoustics (can’t exactly blame an 87A).  It just wasn’t right.  The band seemed “in a box” as a result.

Then, last night, at practice, I found it, the boomy frequency was around 190Hz, right below the range I normally play with with vocals (maybe I am used just too used to SM-58s).  Bingo.  Cut that around 9dB and I was able to punch all the vocals through the mix without muddying the sound stage.  The band came alive; everyone noticed the change.  One setting limited the entire mix - the last piece of the puzzle.  I was frustrated that it took me that long to figure out, and thrilled at how good it sounded after it was fixed.

Complex systems require follow through.  A dedicated approach to move problem after problem out of the way until only the most intractable linger. Dealing with those lingering problems can be tough.  The payoff is worth the time and patience required.  The final fixes, though minor in scope, fulfill the goal of all the work that precedes.

The more I work with software, the more I think of it in economic terms.  I recently gave a presentation to my team that included an introduction with a strong economic emphasis.  From the feedback I got, it was thought providing, but not “to the point” enough - too much talk about economics itself.  That isn’t surprising, because I tend to go on about academic things, and because I love the subject.

But I am left with the impression that us software folks, on average, would greatly benefit from more of a grasp of economics than we have.  I think everyone would benefit from a deeper understanding of economics.  Why?  Because it describes how the world actually works.  It doesn’t concern itself with intentions, but with outcomes.  It deals with the realities that we would often rather not think about - but must.  “You can have everything, and certainly not now.”  It is the central tenant in the all-important engineering reality of trade-offs.

While often associated with money, economics is primarily about the use of resources - of any kind.  The fact that you are reading this now is an economic reality.  You could be spending your time doing something else, but you choose to be doing this.  Your time is scare, and it has alternative uses.  The loss of the alterntive use (like reading a better blog) at this moment, is an opporunity cost.

So, can we as software practioners benefit from a better undersanding and practical application of economics?  Absolutely.

More to come.

http://tech.slashdot.org/story/09/07/30/1854243/Emacs-Hits-Version-23

Yea!

For those unfamiliar, Emacs is simply the best text editor on the planet.

Sometimes I read books because I want to.  Being in school, I usually read books because I have to.  In either case, it is nice to have someone else summarize the book for you, like this video summary of “The Long Tail”:

http://www.readitfor.me/2009/05/book-summary-10-the-long-tail-by-chris-anderson/

Reasons why I like this:

• It is entertaining
• It can provide a good mental “glue” as I dive into the detail in the pages
• I think you can get 50% of the value of a book in these summaries.  What is important is the main thesis.  Much of the rest is context and filler.  Often times you can support the thesis with your own experience.
• Professors often ask for summary analysis.  Shortcut?  Sure.  I call it efficiency.

Disclaimer in case my professor is reading this:  I am reading the book in its entirety. 

I almost sent my new laptop computer back to Dell.  It was taking 15 minutes to boot up, a disc was stuck in the drive, the hard drive light was on constantly, and it was super slow.  I was following the instructions from the Dell tech on how to re-image the system using the built-in recovery partition, but that wouldn’t even work.  So the tech was proceeding to send me a shipping box.  Just one more thing to try - press the optical drive eject while in the BIOS setup screen.  Viola.  Out pops my Nintendo Mario Kart Wii disk.  “Huh.  Been looking for that,” I thought.  It was surely inserted by one of my boys.  Probably Aaron.

There you have it.  Wii games cause Dell computers to go wonky.

I recently did a talk with a group of IT professionals on Agile Development practices.  It must have not sounded like a normal Agile talk because the organizer came back and asked if I wanted to change the title for the transcript.  The new title is “Software Simplicity: Doing More by Coding Less”.  The basic premise is that, in aggregate, the biggest determinant of software quality is the number of lines of code required to meet a business function.  Think of business and utility function as an asset and lines of code as a liability.  I believe this for both the simple fact that more lines of code mean more bugs, and the more subtle fact that less lines of code reflects a more deft approach to software.  Software is a craft where quality usually goes up when one hits the delete key because a better design has made bad form out of certain verbosity. Every line of code must prove its worth.  Pack your apps with less, not more.  To borrow from XP: YAGNI.

The theme of this talk arose from recent work I have been doing getting a large team up to speed on a relatively large project.  The main challenge of the project was the number of people involved.  I found two keys to success:

(1) Model a super clean application with a good application stack:  The abstractions should be not too opaque (I still think SQL is a good thing), but not too thin (Something is wrong if I have to close a JDBC connection or pull a parameter from HttpServletRequest).  My favorite is: Struts2, Spring, Spring Security, iBatis, running jetty under Maven.  The code should be as minimal as possible and impeccably clean.  You cannot elimate entropy in the process, but at least you can keep the energy state high and organized to start to positively influence the end state.

(2) Mentor mentors.  Start with a small group. Work together.  Lean from each other.  Make the stated goal for the this prototypical team to produce work like it came from a single developer.  Add more developers when the base of mentors can support it.  Keep the mentoring cycle alive throughout the entire project.

Nothing magical, kinda boring.  But it works.

I believe the iPhone is the most revolutionary device and software platform brought to market in the past ten years.  It is just so usable.  My 21 month old son Aaron knows how to unlock it, navigate through multiple pages, and start the games he likes.  Rolando is a real hit with both the kids.  Perhaps the most telling impact this kind of early exposure will have on the future of computing is the fact that my notebook screen has been completely covered in smudge marks from the kids trying to use their fingers on the screen.

The iPhone is a major breakthrough toward solving the “blinking twelve problem”.   Neal Stephenson refers to this problem in his book, “In the Beginning was the Command Line”.  In the book he criticises the modern computer GUI as being clumsy and poorly suited for many tasks, a clumsy abstraction bolted onto a computer whose power is often limited by the GUI.  Ask any expert UNIX admin and they will attest to the fact that nothing beats the power of the command line (and Windows command promt doesn’t count).  But that is beside the point.  The iPhone returns the GUI to a state that is more about the user.  It remains the first computer Aaron could operate.

Turns out I share a birthday with the Apple Macintosh.  I was seven when it was introduced.

Happy birthday, Mac!

 http://venturebeat.com/2009/01/24/25-years-ago-apples-macintosh-says-hello/

I was getting frustrated with the fact that Emacs default modes didn’t handle long lines well.  This is fine for editing code where I keep all lines under 80 characters, but for editing documents it was a pain.  Going to the end of a line <Ctl> + E took you to the beginning of a paragraph since Emacs was concerned with the actual line of the file, not the displayed line.  The solution is longlines mode. This mode breaks up long lines for editing, and still saves them as a single line.  I used to have to download and install it.  Now it is bundled with Emacs 22.  Nice.

<Alt>+x, longlines-mode