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.

I inadvertently started a bit of a conversation today when I complained about the state of NetNewsWire on Twitter. I’ve been a NetNewsWire user for years, and I was very surprised when it was sold to Black Pixel. My surprise turned to disappointment when the application was not updated, and now NetNewsWire has stopped working for me completely.

I have a group of feeds in a folder called “Read”, which I keep as my must-read list. It just so happens that this list is the one that has stopped syncing with Google Reader. I recall there being conversation online about moving away from Google Reader, and how it being the only RSS syncing service was Not A Good Thing. From what I can gather, the new version of NetNewsWire was going to sync it’s feeds using iCloud instead of Google Reader, a move that I would have welcomed. I keep a separate account used only for syncing my Google Reader feeds, so being able to get rid of that account would be great. Unfortunately, NetNewsWire uses core data as it’s data storage back end, and development has hit enough significant problems with this setup that Black Pixel decided to work on something else instead.

Reminds me of another story, another once favorite app, Yojimbo. Bare Bones has been documenting their efforts with Yojimbo publicly, and have had to push back releasing a new version that supports iCloud syncing several months. They had once promised that syncing would be implemented by the time MobileMe syncing was unavailable, but were unable to meet that promise.

Black Pixel and Bare Bones have some of the sharpest, and most experienced developers in the business working on these problems, and have not been able to come up with a shippable solution. In that light, I’m actually a bit glad that I didn’t try to tackle iCloud syncing with Go2, and that I’ve settled on using plain text for storage in Scout. The plain text setup should allow me to build Dropbox (or any other comparable technology) syncing into Scout, although I’m not sure that it will be available in version 1.0.

The programming, it is hard.

I’d like a really simple way to insert footnotes in the text. However, I’m not sure how much of that I can do with the Markdown parser that I have now, which means inserting ugly HTML, which I’d really rather not have. I could do something in the generation of the site, inserting my own marker in the text and parsing through that later, but that seems like reinventing the wheel. Surely there are better ways to go about this.

I’ve also been thinking about other scripts or “plugins” for Scout. An early idea I had was to build in analytics, so you could download hit counts and other statistics from your host and Scout would build a nice report for you. Or, maybe even do some type of live updating, but I think that might be taking it a bit too far.

MathJax would be a nice addition, but I don’t think it would be appropriate for everyone. Maybe a preference pane with optional plugins you could check and uncheck and have them included in your site. That way, if you want MathJax or Google Analytics or jQuery you’d just select them and hit publish. Still so far to go to get there.

Which leads me to the next thought, when is it enough for 1.0? I need to balance two weights; on one hand, I need to actually ship the app, but on the other hand, I want Scout to be great from day one. What is it going to take for it to be great? What is the bare minimum that I need in 1.0 before I can ship it? These are the questions I’m asking myself.

One feature that I keep coming back to is the ability to have zero configuration publishing. For example, what if you don’t have a web site or a domain name, but you’d just like to write and publish online in the easiest way possible? Scout should be able to grab your iCloud user name, have you click an in-app subscription, and let you publish to a Farmdog hosted server. That way, you can just download Scout and start writing, and Scout and Farmdog take care of all the little details. That’s the dream anyway, but is that a 1.0 feature? Tough call.

Syncing is another thing that’s going to be a tough call. I’m using plain text as the data storage, so I should be able to monitor changes in the filesystem and merge them into the application. Hopefully, building on plain text and integrating with Dropbox will allow me to (eventually) build an iOS companion to Scout. Scout on the iPad with Dropbox on the backend could be fantastic for writers.

If I only had 30 hours per day to work on this.

I would like to introduce you to Scout, my desktop, baked blogging engine. I’d like to, but Scout is not quite ready yet, so I’m keeping him under wraps till I’m sure. There is only one way to be really sure, and that’s to use Scout to publish my own blog, every day.

So, a little about Scout. I first got the idea a few years ago when I noticed Jekyll. I built the previous version of this site on Jekyll, and used Github as my host. Jekyll works great, but it is very much a power users’ tool. Anything that requires the user to pop open the terminal is not going to pass muster with the average Joe. However, I like the idea of a static blogging engine, and luckily, I’m not alone. So, I set about trying to bring the power and control of Jekyll to a nice user interface.

I’d like to say that I started working on it, worked on it steadily and consistently for a few years, and now it’s almost done. Unfortunatly, I had a lapse of judgement where I was not properly backing up my laptop, and was also two months behind on my offsite version control, and wound up loosing months of work on the first version. I still haven’t recovered completely from that, I wrote a Wordpress importer that I still need to recreate. After loosing so much work, I got discouraged and moved on to other things.

This Fall I decided to pick it back up again, and I’ve been working on it in every spare second that I have. I very excited about Scout, and can’t wait till it’s ready, but like they say, the devil is in the details, and I have to make sure this is done right.

Scout is heavily centered on the writing experience. The main interface is a plain text, markdown syntax highlighting editor, with built in preview, easy to build and customize themes, and a minimalist media manager.

Scout builds and publishes the entire site every time the site is exported. Once the site is uploaded to the web server, the server itself needs very little resources to serve up the site. There is no dynamic code to execute, which makes it very unlikely that the site will slow down or crash because of a high influx of traffic.

I’m using a single window for Scout, and the views fade in and out as needed. The list of previous posts is available on the left hand side of the window, but normally stays closed to concentrate on new writing. I’m also experimenting with the preferences view, trying to keep it very simple, beautiful, and functional.

I’d like to give a time table for Scout’s availability, but it would probably be a bad idea. Even writing this brief post I’ve noticed a few things that either need fixing or need to be enhanced. So, I’ll keep polishing, and polishing, and polishing, till Scout shines as much as I can make it. Then I’ll call it 1.0, release it to the world, and start fixing everything that the world finds.

I will be writing more about Scout in the coming weeks, and would love to hear your thoughts on the concept. Feel free to drop me a line.

It is very easy when living in the technology field to ignore the actual physical space we occupy. Skills once thought essential are slowly being forgotten as we move farther and farther away from a culture of being able to create and fix things.

We visited my wife’s sister’s family for Christmas this year. They have a beautiful thirteen acre wooded plot out in the country, and I savor our visits and the time that we get to spend there. My favorite times are standing outside listening to the quiet and watching the birds. On this particular occasion, we met in town before heading out to their place, and when we arrived my wife and I wondered if we beat them home. We didn’t see the truck they were driving, so I got out to knock on the garage door. Jeff, my brother-in-law, was washing his truck in the garage, draining the water down two drains centered under the parking areas for two cars, and using the hot water tap.

I was more than a bit envious. His garage is heated, has several electrical outlets, hot and cold water taps, and drains. It is, in short, the perfect place to do a complete detailing of a vehicle in winter. Jeff greeted us warmly, and asked if I’d like to wash our van next. I could not turn down that offer, especially since we were just at a car wash that turned out to be closed. We finished his truck, pulled it out of the garage, and pulled the van in. Jeff walked me through a thorough deep-cleaning of the van, pulling out plastic bits to spray out the sand and junk that accumulates in the undercarriage, and explaining how certain parts of the frame are more prone to rust because of the lip. The van had never been so clean by the time we finished. He asked when the last time the van was waxed, which was probably before I bought it. We talked about the different kinds of waxes for a bit, and agreed to let the van dry in the garage and wax it in the morning.

I slept in till eight, and by the time I got up, Jeff had already put the wax on the van and was waiting for it to dry. We worked together to finish the job, and he even got out his buffer to get some of the marks out of the doors.

Jeff is a park ranger, and over the years he’s accumulated a collection of very practical skills focused on maintenance and preservation of things. It’s an interest we share, and reminds me of my first few years in the Navy when I worked as a machinist. The main goal of the enlisted man in the Navy is the maintenance of the ship. That means everything from cleaning the toilets and sweeping the deck, to replacing broken bolts. It means working with your hands.

It wasn’t too long ago when families made most of the things that they needed. At the least, the things they needed were made locally. Towns had to be somewhat self-sustaining or they would not survive. As more and more of our things started to come from factories, and the factories where the things were made were moved to far away lands, our need for creating things left, and with it the skills to do so. I was completely fascinated by this video posted by Shawn Blanc of a blacksmith creating a knife, and then a leather worker building a beautiful sheath for the knife. Being a blacksmith would have been exhausting work, but I can only imagine the satisfaction at having built something like a knife out of pieces of steel.

There is no steel in programming. Only thought. We like to think that there is blood and sweat in our applications, but the truth is that there is only deep thought. Computers are tools; fascinating, engrossing tools, but still just tools. We should all pay as much attention to the rest of our possessions as we do to our computers. At least I should. I’m not one to make new year’s resolutions, but in the coming year I am making it my goal to become less reliant on my computer, and to take better care of the things God has granted me.

Instead of looking back, I like to look forward. As a guide on how I’d like to live the next year of my life, here are Benjamin Franklin’s famous 13 Virtues, written when he was 20:

1. Temperance. Eat not to dullness; drink not to elevation.
2. Silence. Speak not but what may benefit others or yourself; avoid trifling conversation.
3. Order. Let all your things have their places; let each part of your business have its time.
4. Resolution. Resolve to perform what you ought; perform without fail what you resolve.
5. Frugality. Make no expense but to do good to others or yourself; i.e., waste nothing.
6. Industry. Lose no time; be always employ’d in something useful; cut off all unnecessary actions.
7. Sincerity. Use no hurtful deceit; think innocently and justly, and, if you speak, speak accordingly.
8. Justice. Wrong none by doing injuries, or omitting the benefits that are your duty.
9. Moderation. Avoid extremes; forbear resenting injuries so much as you think they deserve.
10. Cleanliness. Tolerate no uncleanliness in body, cloaths, or habitation.
11. Tranquillity. Be not disturbed at trifles, or at accidents common or unavoidable.
12. Chastity. Rarely use venery but for health or offspring, never to dullness, weakness, or the injury of your own or another’s peace or reputation.
13. Humility. Imitate Jesus and Socrates.

One of the many things I love about this list is not how it says to do things, but how it says to avoid things. For example, “Avoid trifling conversation”, “waste nothing”, and “cut off all unnecessary actions”. I think there is something for everyone in this list.