This is one of the songs I sang at church this past Sunday and I liked the sound of it… so I thought I’d record it. This song is definitely a Matt Redman classic.
[soundcloud url="http://soundcloud.com/junhopark/let-my-words-be-few"]
After listening to it, just in case you’re curious here are some of the chords I’m using (capo on the 4th fret):
024100
034100
2×2200
4×4440
…some of my favorite chords.
Do you remember how in college there were classes that were actually below 100-level? The classes that some folks were required to take but they didn’t count for any credits? Well, in trying to come up with a decent title for this blog post, I thought I’d throw in a 090 at the end of the title there since this post will be, in some ways, kinda like those sub-100 level classes. Simple (or simplistic, even), easy, basic-knowledge kinda stuff.
I have to tell you, I was in such a good mood at work today. I finished up a small project which I had begun last week (it feels so very good to make your final code commits… even though you know that bugs will be found, requirements will change, and something will inevitably be wrong with your code), and today I had to come up with a UI design for a filtering component in our application. To put it simply, our application has various “list” screens that list a lot of records and each of these list screens have a filtering component that can filter the records that are displayed to the user. They pretty much function as search pages. Anyhow, I was asked to come up with a design so that our users can not only search for records (existing functionality) but can also perform CRUD (create/read/update/delete) operations with their search settings.
Sounds like a ton of fun–was my first reaction. 
I was enthused about taking on this task because I saw this new functionality as being such a useful functionality for everyone–end-users, QA folks, us developers, business analysts, etc. I knew that anyone and everyone who uses the application would benefit from this functionality and find it extremely handy. Another reason why I liked taking on this task–I was told only the very high-level requirements–namely, that this functionality should allow the users to perform CRUD operations with their search settings. There was no story (i.e. requirements) written for this functionality and no mock-ups. It was all up to me. I love such freedom.
Well… without further ado, here are the steps I took to tackle this task. The last step is still in progress. I call this my User Interface Design 090:
1. Screenshots: Since this was going to be an addendum to our existing search dialogs and list screens, I took screenshots of all of the screens that were going to be affected. I then opened the images up in Gimp, cropped them so that only the parts I want are captured and then copied them into Open Office. I always find that to be a handy way of printing out screenshots that fill up as much of the paper as possible. There’s just something special about doodling on papers as opposed to staring at the monitor–it lets me be a little bit more creative.
2. Research: It didn’t take me too long to realize that I’m not the first person in the world to implement this functionality. This has been done many times before. Originality is good but why waste time trying to be original when there are already perfectly fine existing implementations of this functionality? I looked at various implementations of this–Bugzilla (opensource bug tracking software we use), Twitter (did you know you can now save your search settings in Twitter?), eBay, and even my BlackBerry Bold–the email application. I spent some time playing around with all of these applications. I made mental notes of things I liked and didn’t like, things that made me happy as an end user as well as things that made me scratch my head a little bit.
3. Doodling: After my research was completed, I went to the hard copies of the screenshots and simply stared at it for some time, trying to come up with a mental image of how I want this functionality to be implemented. Slowly, little by little, I started drawing the necessary components–checkboxes, text fields, buttons, etc. I also made various written notes on it–things that can’t be explained by drawing alone.
As I was doodling away, I tried my best to get into the mindset of the end user. To me this is such a crucial step in UI design work. In the end, when it comes to the UI, it is my end users that I need to please. I can build UIs that make my boss super impressed, the QA folks really happy, and my fellow developers envious, but if my end users aren’t gonna like it then I have failed. And that not only makes me look bad, but it makes my team look bad and the company look bad. I tried (as best as I could) to get into the mindset of our end users who use this software–for folks who have absolutely no aptitude nor interest in building software. And to be honest, I wasn’t exactly sure how I could most effectively accomplish this other than to simply take my time asking the What Would the User Do? question with every single doodling element I added on those screenshots.
One more thing to note–as I was doodling, I didn’t give too much thought to the limitations of the architecture/APIs. As long as I knew I wasn’t doing anything crazy I was let myself doodle away. I think it’s a bad idea to be bogged down with such limitations in your creative thinking stage. I’m not saying ignore all limitations. I’m just saying don’t worry about such things too much too soon. I can’t see how that’s going to help you come up with a good UI design.
After I got done doodling, I imagined myself as an end user accessing my doodle-turned-UI. As I went along this step, I made a few adjustments I thought were necessary.
I then went to Chipotle and rewarded myself with a 1110-calorie (yes, I did check my facts online) chicken burrito. SO GOOD.
4. Mock-up: Scribbles you’ve got written down on pieces of paper are useful but it’s even better (and more useful) if you can get them down electronically. After lunch, I made use of the Pencil Firefox add-on, which is a tool built specifically for UI mock-up purposes. You can drag and drop various UI-related items such as checkboxes, text fields, dialogs, fieldsets, and many more. It’s super easy to use. You can then export your finished work into a .png file.
This step took me no more than an hour to complete. Pretty impressive considering the fact that it was my very first time using this tool.
5. Consultation: After I finished mocking everything up, I sat down with my boss and discussed my mock-up with him. A lesson to be learned here: It’s a good idea to run your UI (or anything else, for that matter) ideas by someone. It doesn’t have to be your manager obviously, but it should be someone who is familiar with the software as well as the end users’ uses of the software. My discussion with him proved to be valuable since during our conversation a few things came up that I hadn’t addressed in my original mock-up.
6. Requirements: I got to write up a user story which details the new functionality. We make exclusive use of Google Docs for such purposes at the office. This is the first company I’ve worked for where that’s been the case and I’ve been really happy with doing it that way (What would we, software developers, do without Google?!?). I included the mock-up (exported as .png files) in the story. I tried to be as detailed as possible without specifying the implementation how-to’s of the new functionality in the mock-up. Even though I will most likely end up working on this feature set, the right thing to do when writing user stories is to leave such details out. Let others worry about the implementation details.
7. Review: Perhaps this should be bundled with the above step, but for emphasis-sake, I thought I’d make this into a separate step. It’s never a bad idea to review. If there’s one thing that being in seminary for 4 years taught me, it’s that you almost always discover mistakes when you’re re-reading through your essays. I read through what I wrote down in my user story. Surely, some minor edits were in order. I then printed out a hard copy of it so that I can take it with me and re-read through it before I arrive at the office tomorrow. As of now, the printouts are sitting on my desk next to me. If I finish this blog post up soon enough I’ll be sure to read through it before I go to sleep.
And this concludes User Interface Design 090.
As always, I’d love to hear your comments/questions/feedbacks via this website/Facebook/Twitter.
This has got to be the most unique use of my music to date in my quasi music career :
If you’re not in the mood to watch the video, it’s an instructional makeup video. :) I met her (Hanh Bui) at Kollaboration, which is an annual/semi-annual Asian-American talent competition show which I performed at 2 weekends ago. She was one of the judges at the show. Here’s a true YouTube celebrity with about 80,000 subscribers and over 2.8 million views of her videos. Those are some crazy numbers, if you ask me.
While I”m not into wearing makeups, I’m at least a little bit flattered by the use of my music in her video.
2 rather brief blog posts in a row–I promise the next one will be much longer.
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.
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.
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):
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!
Updated my music page by incorporating SoundClound to share my music. All the songs on my music page are now downloadable!
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.
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.
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.
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…
This upcoming Sunday is going to be a pretty big & important day at the church I’m serving as a worship leader–it’s the grand opening day at our Vernon Hills location. We moved into the Sullivan Community Center (SCC) a few months back and had our first service there on Sunday, 1/24. Since then we’ve mailed out tens of thousands of invitation mailers to homes within a 5-mile radius of the church and I’m told that we should expect around 100 – 200 visitors this Sunday. We normally have about 50-60 adults at our Sunday service so 100+ visitors would be a huge deal for us. We, as a congregation, have also been encouraged in these last few weeks to invite others to the grand opening and I am certainly hopeful that there will be many visitors present at church on Sunday as a result of personal invitations from our congregants.
Some may argue that our “grand opening” this Sunday may not qualify as one since prior to our move to SCC, we had been meeting in Palatine for about 3 years. As for me, I really don’t care. Grand opening or not, I’m going to treat it as such while hoping and expecting that we will have a ton of visitors to our church on Sunday morning. And while it would certainly be nice to have Christian visitors there who are looking to change churches for all sorts of various reasons, what I would really love to see is to have a lot of people there who are not Christians. People who are unchurched. People who don’t have a church home. People who have been away from the whole “church scene” for a long time but have decided to give church, Jesus, and Christians one more try. Honestly, I’d rather have 10 unchurched people/non-Christians visit us than 100 people who are Christians.
And from my point of view as a worship leader–it would be kinda cool to have 100+ Christian visitors come check us out this Sunday and see a bigger group of people be engaged in worship. It would be kinda cool to have a bunch of new people who are already at least sort of familiar with the songs we typically sing at church and be able to sing them with us. It would be great if some of these Christian visitors are skilled musicians who are already familiar with the songs we normally sing on Sunday mornings and are wanting to help in the worship ministry.
BUT it would be even better if we have visitors join us this Sunday who have not been to church in a long time… perhaps never. People who think that the songs we sing are strange. People who can’t help but to feel uneasy and awkward during Christian worship just because they’re so unfamiliar with it. People who don’t know how to pray.
Up until a few years ago, I used to be a member of a church where many (most?) of the congregants had “immigrated” from other churches. And when I think back on those days, all I can say is that while it was nice to have a lot of additional people show up at church on Sunday mornings, at the same time, it felt a little bit pointless. It felt pointless because even though the church had a sudden significant jump in numbers, there was absolutely no net increase in the number of Christians. All of these newcomers had already heard the gospel and they were already members of an existing community of Christians.
So with all this said, I am looking forward to this Sunday. And I will be praying that people who are unfamiliar with Jesus and His church will come join us this Sunday. And if that’s the case, this Sunday might be my first Sunday as a worship leader where I don’t mind people who simply look lost during worship.