My grandparents house was outside of town, at the foot of the mountains, surrounded by woods. Papa kept his guitar in a black case under his bed, along with his violin. Sometimes, after dinner, if we grandkids begged and pleaded enough, Papa would get his old guitar out and play us a few tunes. They were simple folk songs, sang without any of the southern drawl common in country music. One I remember the most was about his mama sending him to town to buy a chocolate ice cream cone. The little house would spring to life those nights, we would be warm from the fire, and full from Grandma’s cooking, and listen to the simplest, most honest music I have ever heard.

Papa tried to teach me how to play, and I think if I had not been so young and stubborn I would have listened to him. He would tell me where to put my fingers, I would get it wrong, and he would grab my fingers and try to put them where they were supposed to go. It didn’t work out, and so far I have only learned a few basic chords. Right now my guitar sits in the corner of my office, staring blankly at me through it’s black case, waiting for me to bring it to life.

Sometimes a friend will come over who knows how to play, and I’m always amazed at how he can call such beautiful music from the strings of the guitar that I can only coax out a basic tune from. Years ago this friend and few other sailors who shared a place in Virgina would get together to write, play, and even try to sing. For now, learning to play guitar is still on my to-do list, but appreciating honest music has always been close to my heart.

The other day I was helping my daughter do the dishes, and we were taking turns picking songs to listen to while we washed. She would pick out one pop song after another, and as she did I realized that pop music hasn’t changed in at least twenty years. It is still as synthetic and manufactured as ever, pandering to the lowest common denominator. I struggled to find something that we could both enjoy, but almost every song I chose was coldly marked as “weird”.

She has a point, a lot of it is strange. Strange, and a bit raw, unprocessed, analog. I have, so far, 22 albums of the Grateful Dead, most of them live bootlegs from the seventies. There is something about the energy of the live shows, how I can close my eyes and almost be there. Sometimes you can hear the crowd yelling out asking for a song, the Dead hear it and when they start playing you can feel the energy spread through the crowd like wildfire, the beat of the drums matched by clapping hands. There was nothing scripted about these old shows, the Dead would just get up there and start playing.

This is real music, a person and an instrument coming together to create something beautiful. From Papa’s strumming to the Dead’s wall of sound, there runs in my musical preferences a common thread of musicianship, of jamming for the love of the song. I was browsing through the Archive’s library of Grateful Dead shows the other day when I saw mention of a Grateful Dead cover contest. That mention led me to YouTube, where I found one of the best covers of one of my favorite Dead songs:

The Giving Tree Band had me captivated as soon as I heard the violin, but when the steel guitar and the piano started, I was there. It’s not just the song, although it is a fantastic song, and it is not just that they have these instruments, the band appeals to me because it sounds sincere. It is hard (for me at least) to explain the difference in this recording and any other, but I think it has a lot to do with the lack of post processing. I believe I’m hearing the musicians real voice, not a digitized representation of it that’s been leveled and artificially harmonized. I’m hearing the banjo, and the electric guitar as the musicians intend their instruments to be heard.

I love music, even if I would sometimes rather drive in silence. I like to listen to music that relates to me, that’s played by people who might just drop by for a cup of coffee to catch up on old times. Music that makes me feel at home. Music that reminds me of the smell of burning pine, the taste of pumpkin pie fresh on my lips, the sound of Papa’s guitar, and knowing deep in your heart that you are warm, safe, and loved.

Just beautiful.

One of my favorite things about the Internet is finding a little treasure trove of writing and style that I previously did not know existed. Electrogent is one of those little gems, and his list of 50 rules for his son is full of timeless advice.

Thanks to science, we have all sorts of polymers, synthetics, polyesters, crystalline, and other man-made materials for making life a little better. However, few materials are as awesome, timeless, and useful as leather.

• Rule 42: Choose Leather

Travel the world… but then come home. Your mother misses you.

• Rule 15: Travel When You Can

You should strive to become an expert in everything like Galileo. The old adage “shoot for the moon and even if you miss you’re still among the stars” applies here. Even if you try and fail to become a great master in all fields of study, you will still attain great knowledge across many disciplines and become a well-rounded person. Even though failing is sometimes necessary, there is basically no way to fail in this pursuit because anything you learn is a success in itself.

• Rule 16: Strive to Be a Renaissance Man

Life is meant to be a quest of continuous self-improvement, becoming a little better every day. Electrogent gets it.

Don’t miss his fantastic gallery.

Thought of the week:

I don’t like this “top ten” business. It’s the bottom ten that I like. I think you’ve got to go for the little things, the stones that make up the wall.

– Donald Knuth

No server, desktop, or laptop install is complete without Vim, and yet, there are times when I still see questions pop up on IRC about how to do basic editing of config files with vi. I remember, years ago, asking some of the same questions of an older Unix guru, and asking why I should bother learning such an eccentric and “outdated” text editor. His answer has stuck with me, he said “Because it is the only text editor guaranteed to be on every server, and some day you will need it, and have no other alternatives.” Vim, short for “vi improved” is ubiquitous, but it is also so much more, and the time you spend learning it will be repaid to you tenfold in productivity.

Vim is designed to be run from the command line, without a mouse. To get around in a file, Vim uses three different “modes”, where the same keys might do very different things, depending on which mode you are in. From my experience, this is the biggest obstacle of learning Vim, wrapping your head around what mode you are in, and how to navigate the text.

When you first launch Vim, you are in normal mode. Normal mode does not allow you to edit the text directly, but allows you to move the cursor around the text using the keyboard. The basics of what you need to know are:

• j - Move the cursor down one line
• k - Move the cursor up one line
• l - Move the cursor to the right one character
• h - Move the cursor to the left one character

Once you have the cursor where you want it, you can press “i” to enter the next mode, “insert”. Insert mode behaves more like other text editors, where the keys you press show up as text characters in the file. When you are done editing, you return to normal mode by pressing “Esc”. This is a good start for getting used to how Vim works, and over time, those keys will become ingrained as muscle memory, you might find yourself inadvertently reaching for the escape key after typing in a web form.

Moving around one line or one character at a time is fine, but time consuming. What if you would like to move the cursor down five lines? In that case, you would enter “5j” in normal mode. What if you know exactly what line number you would like to jump to, say line 42? Enter “42G” in normal mode, and you will jump down to that line. Or, if you would like to jump straight to the end of the document, you could just enter “G” by itself. I do this quite a bit, jumping between “1G”, the first line of the document, and “G”, the last. If you would like to move 10 characters forward, you would enter “10l” in normal mode. Same to move back, “10h”

What if you just moved down ten lines, and would like to move down another ten lines? You could enter “10j” again, but it would be faster to use another Vim shortcut, the humble period. Hitting “.” in normal mode repeats the previous command. So, whatever you did last, hitting “.” will tell Vim to do it again.

Hitting “i” in insert mode will allow you to start inserting text, however, there are a few other options as well.

• a - Append, or, start adding text right after where the cursor is
• o - Create a blank line on the line below the cursor, move the cursor to this line, and enter insert mode.
• O - Same as above, but the new line goes above the cursor, not below

Once you have the basics of when and how to insert text, moving around the text becomes more important. Luckily, Vim knows text well, and has a few tricks here as well.

• w - Move the cursor ahead one word
• b - Move the cursor back one word
• ( - Move the cursor back one sentence
• ) - Move the cursor forward one sentence

What about copy and paste? Vim has that covered as well, but instead of “copying” text, you “yank” text with the “y” command. To yank the current line, which means to copy the current line, you press “yy”. To paste the line, move the cursor to where you would like it and press “p” in normal mode.

So, now that you can fly around your text with ease, and insert new text at will, what are you going to do about the plethora of typos? A few more normal mode commands to commit to memory are:

• d - Delete one character, word, sentence, or the entire file if you like
• r - Replace one character
• R - Replace all the characters till you hit escape, just write right over them

To use the delete command, you can either place the cursor over the text you would like to delete and press “d”, or you position the cursor at the beginning of a string of characters you would like to delete, for example, to delete one word, you press “dw”. To delete five words, you press “5dw”. To delete a sentence , you press “d)”. To delete the entire file, you could jump to the beginning of the file: “1G”, and delete to the end: “dG”.

And if you make a mistake? No problem, Vim keeps a detailed record so you can undo the last command with “u” in normal mode.

So, you can jump around the file, insert text, and delete text. How do you save the text? To do this, we need to enter a third mode, command mode. To enter command mode, you must first be in normal mode, and then press “:”. You should see the cursor move to the very bottom of the window next to a colon, waiting for you. To save the file in the current working directory, you would enter:

:w FileName.txt

If your file already has a name, then simply entering “:w” will work.

That’s most of what you need to know to become proficient with Vim, but of course, there is so much more. I’ve barely scratched the surface of what Vim can do on its own, not to mention Vim’s vibrant community of users and developers who have extended Vim through plugins. It is through the plugins that some real magic can start happening. However, to avoid asking on IRC how to edit a text file, this should have you covered. Finally, when you are finished editing, jump into command mode and enter “wq!”.

You get good at something by doing it repeatedly. I’ve been writing on this site for six years now, but with little direction or topic. I’ve gotten good at not making anything of the site, which is not where I wanted to be when I wrote about why I kept this site in 2011. I’ve not kept to a regular schedule, or a common theme, so I am not surprised to see that the only traffic I have going to the site is my own, and a few that found the site from Google. The preceding statement will make the next seem a bit ridiculous, but bear with me.

I’m starting a weekly sponsorship program for the site. When you sponsor a week of posts on jb, your product post will appear in the main feed three times, Monday, Wednesday, and Friday. Your product or service will also be mentioned in the site header for the week. Sponsoring jb will expose your product to a small, but growing, audience of creative and technical professionals. Consider this your opportunity to “get in on the ground floor”.

I have, for the past six years, been practicing finding my voice, my interests, and honing my writing style. I have also been deciding on the topics that interest me, that I’m passionate enough to write about, and that I care enough to share with the world. This is a site about quality, quality in our things, how we choose them, what we decide to accept into our lives, and what we spend our time on. I want to shine a light on the goods and services that I find exceptional.

I am also putting up some barriers to what I will write about here. I will not write about systems administration topics, or anything dealing with the general topic of open source software. I already have a venue for those topics, so they are out of scope here. If an open source application that I use is outstanding in some way or another, I might cover it here, but not on the merits of it being open source. Personal and family subjects have been mostly taboo since I started, and will remain so now. I will also not talk about politics or religion. These barriers are mostly to keep myself on track.

This is also a site about the pursuit of excellence in all that we do. This site is about using things that are worth having, and spending our time building things that are worth selling. The previous years were a warm up, the main game starts now, this is a great place to start reading.

After reading the MacSparky piece on craftsmanship, I’m reminded of how I like to look at my career as a systems administrator. I find that there are times when things that are not quite right just bother me. Like when there are inconsistencies or one-offs scattered throughout the environment I am responsible for. There may well be perfectly logical reasons why some systems are monitored and some are not, why some are registered with configuration management and others are not, but in my mind it is these little inconsistencies that add up and make your work look sloppy.

A craftsman is not sloppy. They are careful, competent, precise, and thorough. It is knowing that the little details matter, if to no one else but you, the accumulation of details is what defines the quality of your craft. It is knowing what the right tool for the job is, it is knowing when to use the power tools, and when to do it by hand. It is knowing that every corner you cut will come back to you in the end.

Cutting corners is unacceptable for a professional sysadmin. It doesn’t matter if you consider yourself “devops” or an old school neckbeard, you must decide to do the right thing and make sure that all of your bases are covered. I like to think of the environment like the internal workings of a clock. There are lots of tiny little gears, but when they all work together, you can feel the system ticking happily along.

Your profession matters less than how you approach your work. Do you do it sloppily, haphazardly, or as a craftsman?

So, while I was debugging the first post using Scout, I found an oddity in NSString. I was building the links between the posts using stringByAppendingPathComponent, to join the site’s base URL with the path component of the individual post. Unfortunately, that method seems to be stripping one of the forward slashes off of the http:// string, which screws up building links.

To test it, I created a blank Xcode project, and added this method to the App Delegate:

-(void)awakeFromNib
{
NSString *first = @"http://first";
NSString *second = @"second/part.html";
NSLog(@"first + second = %@", [first stringByAppendingPathComponent:second]);
}

And, sure enough, here is the output from that method:

2013-01-03 19:26:02.388 NSStringTester[39861:303] first + second = http:/first/second/part.html

A quick search through Scout’s source files shows that I’m using stringByAppendingPathComponent 53 times. Looks like I’ve got some work to do.

Also, this is a good time to point out that when you are doing web development, it is very important to test with multiple browsers. Safari hid the problem, Firefox did not.

Finally, it turns out that this is not actually a bug in NSString, but a bug in my understanding of this method. My thanks to Matt Yohe who was kind enough to point out my mistake on Twitter.

I’m still considering filing this as a bug, but I can see where they are coming from. Double slashes would not work for a file URL, but if they are already parsing the string for something like that, why not just check for “http” as well?

Building a desktop application that manages creating your site is great, but only publishing to a local folder is for the birds. After only a few posts using Scout, I can say that the process of publishing to a folder, switching to Terminal, and running rsync will not fly for any potential customers I may have. It’s a pain.

However, the choices for publishing online like Scout is meant to are not great. The point of Scout is that you can publish to any bare-bones, $3-per-month web host in the world, and not have to worry about the site going down because of high PHP or database processing overhead. There is no database, and there is no active code being executed. The only thing you need for Scout to work is a web server to serve up the site, and an ftp server to get your site to the server. But, that means that I need to write the code for dealing with FTP, and probably SFTP.

This is going to be hard for a couple of reasons. There could be a thousand different implementations of FTP, and a virtually unlimited number of “edge” cases that I might run into. For example, just testing some FTP code with my current web host caused all of my FTP connections to the host to be denied for a few minutes, too many connections at once. I clearly still have a lot to learn about stream programming, but if there were ever anything I would like to use a library for, this is it.

Speaking of libraries, I’ve kind of got a thing about using external code, and I’m a bit conflicted about it. On one hand, I don’t want to continuously reinvent the wheel, but on the other hand, I don’t want to mindlessly drop someone’s half-baked framework into my project. Choosing someone else’s code to use must be done very carefully. Right now, I’m considering two things for networking, writing everything myself using CFNetwork, or building in support for libcurl. The libcurl library might be a better choice, since I could also use it for SFTP file transfers, but, it might also complicate my code, and add an external dependency. Tough call, still need to think it through.

In the mean time, another thing I’ve noticed Scout needs is a decent full screen mode. The current full screen mode just makes the window bigger, which is not really a lot of help. Full screen should vertically center the current text being edited, make the font bigger, and possibly make the text view a bit narrower than the full width of the screen.

Also, themes are coming along nicely. Scout will support a fairly simple development of themes for your site, in a little theme.stemplate package file. Double-click on the theme and Scout will import it, and it will show up as an available choice in the theme chooser.

Scout is by far my most ambitious project. Still tons to talk about, and lots of possibilities. Who knows, what about live statistics in the app? Beautiful PDF report generation? A Farmdog hosted option available with in-app subscription and zero configuration? It’s all possible, all it takes is time.

Development continues.

I’ve searched high and low for an alternative to iTunes, but I’ve yet to find a suitable replacement. I use iTunes for playing music, mainly over AirPlay in my home office, and it works great. I’ve got smart playlists, star ratings, and an iTunes Match account to keep everything in sync between home, work, and mobile. Given my investment of time and money over the years, it’s possible that I may be suffering from some type of sunk cost fallacy, but honestly I really enjoy iTunes.

I’ve read several arguments against iTunes, and most of them make perfect sense. The application does try to do too much in a way very unlike most Apple designs, but I find it easy to ignore what I don’t use. Most of what I’ve read centers around how bloated iTunes has become, but the performance counters I see tell me that it is not much, if any, heavier than comparable applications. I recently compared iTunes 11 to Sonora and Tomahawk monitoring CPU utilization per process using Activity Monitor while the window was closed.

• Sonora
  • 3.1% CPU, 66.7MB - No Window
• Tomahawk
  • 4.3% CPU, 82.6MB - No Window
  • Occasionally spikes to 91% CPU use, not sure why.
• iTunes 11
  • 2.9% CPU, 94.5MB - No Window
  • 2.9% CPU, 97.7MB - Mini Player Window
  • 2.9% CPU, 97.8MB - Main Window

So, from what I can see, iTunes does use more RAM, but not by much. But it also uses less, or at least comparable CPU than the other two. I’ve done the same checks previously with different music players, and normally find similar results. With the feature set that iTunes has, I don’t see a reason to go through the hassle of using anything else.

A few other people I follow on the web have stopped using iTunes in favor of web based streaming services like Spotify or Rdio. I haven’t checked the resource use of the web players or the native clients of these services. I prefer to manage my music collection myself, and living out in the boondocks in the midwest, I don’t like having to depend on my Internet connection when I want to listen to something. Also, I still haven’t figured out where my bootlegged collection of Greatful Dead shows fits into a service like Rdio.

I still believe that Apple should split iTunes into separate apps, and I know that there are other people who’s use of the app differs from mine significantly enough that they see problems with it. It just doesn’t happen to me.