Archive for April, 2010

If you write code, write tests

Posted in software on April 30th, 2010 by Junho – Be the first to comment

So… I’m scrounging around the internet looking for some TDD-related tidbits and I came across the following at www.artima.com.

I like.

If you write code, write tests

The pupil asked the master programmer:

“When can I stop writing tests?”

The master answered:

“When you stop writing code.”

The pupil asked:

“When do I stop writing code?”

The master answered:

“When you become a manager.”

The pupil trembled and asked:

“When do I become a manager?”

The master answered:

“When you stop writing tests.”

The pupil rushed to write some tests. He left skid marks.

If the code deserves to be written, it deserves to have tests.

Making the Most Out of Band Rehearsals

Posted in Ministry, music on April 21st, 2010 by Junho – 5 Comments

Band rehearsals–some love ‘em, some hate ‘em, but there’s no denying that they are very much necessary, even for bands that are comprised of phenomenal musicians.  Since 1997, I’ve had to partake in many band rehearsals–about 700 or so (a very rough estimate)–99.9% of them having been with bands that are associated with churches or para-church organizations.  I wanted to take some time to write down various tips on making the most out of band rehearsals–tips that have (and still do) helped me and hopefully will help you/your band/your church as well.

So here they are!

PART I:  First, I’ll start off with tips that deal with helping you (and your band) to become better prepared for band rehearsals:

1. Recordings: If you want to make the most out of your rehearsal, it is absolutely crucial that everyone in the band knows the songs before they get to the rehearsal.  It is very helpful for everyone in your band to hear recordings of the songs you’re planning on rehearsing before the rehearsal.  Unless the recordings deviate greatly from how you want your band to play the songs (which may accomplish nothing more than confuse the people in your band), email out the recordings to your band before the rehearsal–even if the recordings do not sound like how you want your band to play the songs.  For people who are in your band, being able to listen to the recordings will help them become mentally prepared for the rehearsal.  If you don’t have the recordings at your possession you may want to check out grooveshark.com or youtube.com and simply send the URLs of the songs to your bandmates.  Both websites contain enormously large databases of songs.

If, for various reasons, recordings of the songs you’d like to perform do not exist (i.e. in the case of originals) I’d say take some time to create a recording on your own.  Even a simple recording with just a guitar and voice will be very helpful for your bandmates.  And you most certainly do not need any “professional” recording equipment.  Just get yourself a cheap computer mic and use a freeware such as Audacity which will enable you to do multi-track recording on your computer.  The sound quality will be pretty bad; however, even a cheap-sounding recording is way better than no recording at all.  Trust me.  Take those extra 30 minutes to create a recording and you may very well save yourself and your band 30 minutes of rehearsal time because no one in your band knows the song.  If you’ve got a few hundred bucks at your disposal, do yourself (and your band) a huge favor by picking up some audio recording gears.  If you have a decent computer you can create some really nice sounding recordings with equipment that will cost you less than 400 bucks (including a condenser microphone, mic stand, cables, etc.).  It’s simply astounding how cheap these recording devices are these days.

2. Chord Charts: Spend some extra time to prepare nice, clean, readable, correct chord charts.  Please, please, please don’t be lazy and grab those online guitar chord chart/tabs and print them out!  They are not very readable and the chords on them may very well be wrong.  Anyhow, back to chord charts…: I’d suggest including the following in your chord chart (sorry, most of these will be painfully obvious): title of the song, key, tempo, sections (i.e. verse 1, verse 2, chorus, etc.), lyrics (duh), chords (duh duh), scan (the flow of the song–such as v1 -> v2 -> chorus -> v3 -> chorus -> bridge -> chorus…), composer, copyright info.  Here’s a screenshot of a chord chart for a song I play rather frequently (note: I cut out the middle, unnecessary portion of the chord chart):

Chord Chart

Some additional notes regarding chord charts: If you’ve got a song where some musicians will play the song in different keys (for instance, if the song is in the key of F#, the guitarist may put the capo on the 2nd fret and play the song in E; the keyboardist may prefer to play it in G and transpose the keyboard down half a step) be sure to prepare copies of the chord chart in all the different keys.  Most of the copies of chord charts I have are in various keys.  For instance, if I have a song entitled Hello, I may have Hello(C).doc, Hello(B).doc, and Hello(A).doc.  If you’ve been playing in bands for any significant length of time, you should know by now that most musicians can’t transpose on the fly :)

3. Notes on Chord Charts: In many cases, it’s not enough that you have chord charts–you need some extra notes on them for yourself and your musicians.  On the chord chart, include some notes regarding items such as:  Who’s supposed to play the intro, which instruments should come in where, and highlight any important parts of the song.  And when you make copies of the chord chart, it might be a good idea to make copies of the chord charts with notes on them for all your bandmates to see.

For an example click here.

4. *Know* the song: If you’re the lead person in the band, you of all people should *know* the song inside out.  And not only should you be familiar with your own part, you should have a pretty good feel for all the others’ parts as well.  It doesn’t mean that if you play the guitar and are the lead singer, that you should also be able to play the keyboardist’s part as well as the drummer’s, etc.  However, you should at least know when each instrument/vocalist comes in and out and have a rough idea of what should be played.  Knowing what each musician should play (or sing) will help you discern how well your band is playing during the rehearsal.  After all, “that sounded really bad… period.” is not a very helpful comment for your bandmates to hear.  You, as a leader, should be able to say, “that’s not quite how it should sound… how about you try something like [blank]?” If you’re the lead person in the band, knowing how to play more than just your instrument and/or sing harmonies will be extremely helpful.  (And it is *never* too late to learn!)

And while we’re on the topic of *knowing* the song, you should spend a good amount of time practicing on your own before the rehearsal.  This is especially important if you’re the lead person in your band.  Practice is good and good practice makes perfect.  And while you’re at it, may I suggest getting into the habit of practicing with a metronome (if you’re not already in the habit of doing it, that is)?

…And now…PART II:  Here are some tips that deal with helping you with the actual rehearsal:

5. Metronome: I’ve recently gotten back into the practice of using a metronome during the rehearsal.  I’m sure are there are different ways of doing this, but here’s how I do it:  Come rehearsal time, I hand over the metronome to the drummer and the drummer sets the metronome in a “mute” mode while the thing clicks away.  Most metronomes, along with the ticking sound, have blinking lights that blink at the specified tempo, thereby allowing the drummer to put the metronome down off to the side and look at the blinking light via his/her peripheral vision.  That way if the drummer goes out of sync with the metronome all that needs to be done is to look away (instead of being torturously thrown off by the off-beat ticking noise) and attempt to get back in sync with the metronome.

Back in the day, a long long time ago, I once had the metronome hooked up to the sound system during a band rehearsal so that the entire band could hear the metronome’s ticking sound.  That was a VERY bad idea… so bad that I still remember it after all these years.  If you really want to annoy your band, give that a try sometime. :)

6. Sound Person: This tip might be way too obvious, but it’s a really good idea to have a sound person at the rehearsal.  It’s just too much work having to go back and forth between the mixing board and your instrument/microphone and attempt to adjust the levels and EQ.  I used to have to do this all the time and it can get pretty annoying having to constantly go back & forth back & forth.  I am so very thankful there’s always a sound person at my band rehearsals these days. :)

7. Only Certain Parts: In a song, not all sections of the song are of equal importance.  And, not all sections of the song are of equal level of difficulty.  Some sections are easier, some are harder, some are really important (where if you make a mistake at that spot, you’ve just killed the song and might as well do-over), and some are really not nearly as important.  During (better yet, before) the rehearsal, determine the parts that are of higher importance & difficulty, and focus on those parts during the rehearsal.  Don’t just play the song from beginning to end X number of times and call it quits.  And if you need to get nitpicky, get nitpicky but pick and choose when and where to get nitpicky.  Getting nitpicky over sections that are of higher importance is always a very good idea.  Getting nitpicky over sections that aren’t really all that important may not accomplish more than cause annoyances amongst your bandmates.

8. Is That All?:  When you think the rehearsal is almost over, ask yourself is there anything else that we need to go over again? Ask yourself (as well as your bandmates) if there are any songs (or sections of songs) you should go over again.

… and that’s it. :)   I hope these tips will be of help to you if you play in a band at any capacity.  Please let me know if you’ve got any comments and/or questions!

Updates – Music page

Posted in Site Maintenance on April 17th, 2010 by Junho – Be the first to comment

Updated my music page by incorporating SoundClound to share my music.  All the songs on my music page are now downloadable!

Lessons Learned From Being in the Shoes of QA

Posted in software on April 15th, 2010 by Junho – 1 Comment

No Bugs!At work we have a huge product release coming up very soon.  There are a lot of new features to the application, which means that there has been a ton of changes to the code, which has meant a lot of hours for testing.  As a result, I’ve been having to help test–in volumes I don’t think I have yet in my software development career.  I’ve had to run the application through a variety of test scenarios as well as going back to bugs and verifying that they, in fact, have been fixed.  In the last week or so, that’s where 90% of my time has been spent.  While I’m a little sad about not being able to code nearly as much as I’d like to at work, I’m glad for the lessons I’ve been able to learn in my very brief stint as a QA personnel/software tester.  One thing I’ve been realizing is just how incredibly expensive writing buggy code is.

Having to devote so much of my time towards verifying bugs that have been fixed has given me a rather fresh awareness of just how expensive writing buggy code is.  If a developer (say, Developer X) writes code that isn’t quite right (or extremely wrong) in the first place and commits his/her code, well what happens?  Since QAs do not tend to test code that have been committed right away this means that once the code has been committed, chances are pretty decent that the at least 1 other developer on the team (say, Developer Y) will start making use of the code that Developer X has committed.

Fast forward a few weeks and now it’s time for some testing by the QA (Tester A).  Tester A finds some issues with Developer X’s code and files a new bug (expense).  And the expense comes from more than simply identifying the bug.  You see, often times it’s much easier & faster to see that something works than to see that something doesn’t work.  Unless Developer X is just a horrendous developer and most of the code he writes is buggy (in which case he should be doing something else…) QA will most likely give the developer some benefit of the doubt, which can amount to be an expensive “task”.  I’ve been noticing this a lot in my own testing.  When I come across buggy code, the first thing on my mind is not that there is something wrong with the code, but rather, that I must not be seeing something correctly.  At this point, I will almost always re-perform my testing (expense) and my understanding is that this is true for other, more seasoned software testers as well.  When a code a person is testing does not quite work right the first time around, that same piece of code may very well be tested at least 2 or 3 times before a bug is eventually filed.  Again, expensive.

Okay, so after the bug is filed, Developer X then has to go back to the code that he wrote a few weeks ago and try to remember what he did (expense).  There is also the hidden expense of  disruption to his flow of work.  And of course, unless the code that was written was super simple, it’s going to take some time to recollect why the code was changed.  Thanks to source control, seeing what changed is a simple task.  Trying to figure out and/or remember why something changed can be a pretty tricky task.  The Developer X thinks, thinks, and thinks (expense) and looks through not only his code but code that others have written which may very well have changed since the time he originally wrote his code (expense).  After some time, the developer figures out what’s wrong and fixes up the code.  Developer X commits his code.  Updates the bug that was filed in the bug tracking system (expense)–a process which often takes more time than one would like.  It tends to take a lot of time because trying to write something that is both concise & informative can be a tricky thing.  You don’t ever want to write (or read) an essay in the bug tracking system.

Once the code has been committed and Tester A has been notified, he may need to drop everything that he was working on in order to test this code, which means disruption to his flow of work (expense).  Re-testing code can be a very disruptive thing.  Once Tester A tests the code and verifies that it is working (hopefully) Tester A has to go back to the bug he filed into the bug system and make updates to the bug ticket (expense).  And once this takes place, there will have to be, at some point in the future, yet another test to verify that the bug has been fixed (expense).  While this last step isn’t completely necessary, I think it’s much too risky to leave this step out.

Obviously, if upon re-testing the code Tester A sees that either the bug hasn’t been fixed or worse yet, more bugs have been created as a result of fixing the original bug, well… that just means more and more expense.  And honestly, having to re-re-test code sucks.  BIG time.

At any rate, let’s say that Tester A finds that the code has been fixed and things are working correctly.  Not all may be done at this point, however.  Remember Developer Y?  The developer who made use of Developer X’s buggy code?  Developer X’s buggy code may mean that Developer Y has to go back to the code he wrote (expense).  Bug(s) may be filed against code that Developer Y wrote to no fault of his own (expense).  Developer Y may get really frustrated at Developer X (expense).  And if this kind of thing becomes a pattern, this will mean more & more expense for the entire team since other developers are going to become growingly weary of any code that Developer X writes, no matter how simple it is.

So, to sum it up:  As developers, it is critical that we write code that works the very first time around.  Code that works results in efficiency, happy developers, happy testers, happy managers, and less money wasted.  Writing buggy code results in slow-downs, demoralized developers, cranky testers, angry managers, and a lot of money wasted.

New Recording – Gone from the Portrait

Posted in music on April 14th, 2010 by Junho – 2 Comments

Over the weekend I started re-recording a song which I had written a few years back.  Vocals, acoustic guitar, electric guitars, bass, keyboards, drums-via-keyboard all recorded in my room.

You can listen by going to the music page or just click below to play the song.

Gone from the Portrait

So, a quick blurb about the song–it’s a goodbye song I wrote in response to a friend who was going away and I just remember having repeated thoughts of man, I really wish I had gotten to know this person better… it’s all too late now…

A good reminder to invest in relationships that really matter.

New Music – Lullaby (Instrumental)

Posted in music on April 4th, 2010 by Junho – Be the first to comment

After lunch @ Sweet Tomatoes with some friends I came back home and took a much needed nice, (too) long nap.  Fast forward a few hours and it was around 11: 30 pm…  and thanks to the nap I knew I wasn’t gonna go to bed for a little while.  So I picked up my guitar and started doodling around on it and I liked I was hearing so thought I’d record it.

So, here it is – Lullaby (Instrumental):
Lullaby (Instrumental)

A soothing blend of acoustic guitar and piano… with some shaker action thrown in there as well.

On a separate note, last night’s Good Friday service at Lakeview was awesome (as usual).  So good & encouraging to see everyone who helped out in various ways.  Lakeview Church is most definitely blessed.  Denny’s and chat with friends afterwards were awesome as well.  Looking forward to the Easter service tomorrow.

I just wish I didn’t have to wake up in four and a half hours… dang it… :)