Ionrock Dot Org

My Weblog

Home Network Sysadmin

After an excellent term of service, my Linksys WRT54G finally started showing its age and revealed a need to be replaced. It was the first wireless router I had ever had and served me well. Yet, with new hardware comes new possibilities.

Besides an upgrade to the newer specifications, one of my goals was to find a router that allowed network storage. NAS systems have become insanely cheap, but they are not mobile. We often need our files on the road, which means the router + hard drive combination is a slightly better fit.

I settled on a Netgear WNR3500L after a good 20 minutes at Frys randomly looking at the selection of networking gear. This process took much longer than expected as my home sysadmin skills have wavered in light of cheap VPS hosting. It was always a lot of fun to run a dynamic DNS service and host my website and media files at home. Unfortunately, I now value reliable service over noodling on geeky endeavors at the house. The result is that computer and home network hardware have failed to pique my interest for quite some time. I’d consider myself completely out of the loop when it comes to knowing what kinds of hardware is out there. Fortunately for me, home networking gear hasn’t changed too terribly much.

My new router supports something called Readyshare (they put a TM at the end of this, so I suspect it is something specific to Netgear) that will let you place a USB based storage device on the network. It shares it via Samba. It was trivial to set up and I was backing up my data in no time.

I also use Vonage for my home phone and previously had its router doing my local DHCP and sitting in front of my wireless router. Seeing as I rarely even use my home phone (it forwards to my cell), it made more sense to go ahead an put this new wireless router first in the chain. After a little trial an error, I configured my vonage router with a static IP and opened the necessary ports for UDP traffic, successfully allowing my home phone to function once again. The fact this didn’t take a few days of noodling to get to work made me feel pretty good about the whole process.

There are times where I wish I could be a sysadmin. Actually, I take that back. There are times I wish I knew what a sysadmin knows. None of it is so difficult you can’t understand it, but it takes practice and requires a different type of mindset that thrives in making software and hardware play nice. I’m confident when this router dies after 10+ years I’ll have another chance to flex my sysadmin muscles a bit at home and be thankful for the experience. But, I’m also thankful I don’t have to do it every day. Thanks to all you sysadmins out there!

Ubuntu HUD

I had seen an article on Ubuntu HUD recently and finally got a second to actually read a little about what it does. The idea seems to take the use of tools such as Quicksilver or Alfred and apply the same workflow to menus actions in all applications. Overall it seems like a slick idea. The video in the post above shows how it can be used on the command line! Very nice.

My biggest question is that of discoverability. I remember when I was working on the NLD 9 usability and felt the push for search was somewhat misguided. Search is extremely powerful, but it is also something of an art form. As a programmer, many times my goal in asking questions in forums or on IRC is to gather new terms to help aid in my searches. When you are a young programmer with no formal training trying to understand how to work with files, knowing terms like “handle” or “EOF” can be tough to discover on your own.

What is easy to appreciate in the HUD idea is that you never need to leave your keyboard. This is the reason I’m enamored with Emacs. It provides an interface to do so many things, that you rarely need to leave the comfort of your frames and buffers. In Emacs the use of plain text enables this sort of tool to work and I’d assume that GTK+ (more or less) is what allows HUD to take things like menus out of the application and add them to an index. If this assumption is correct, we might finally see how a free platform has an advantage in providing a better user interface. I doubt you could ever see such a widespread conceptual change in something like OS X or Windows, partially because it may not make sense to users, but also on a technical level it seems really difficult.

No matter the long term effects, it is exciting to see some innovation in user interfaces that reflect the maturity of the “computer” as a tool that the majority of people use.

Making Transitions

I can’t tell you how many times a transition has made a song work. A riff or chorus, no matter how interesting or catchy, is only as good as the transition that introduces it. This theme also holds true when developing systems. APIs and tools such as databases are only as good as the data formats used in the transitions. A well designed architecture with a poorly designed data or storage format will quickly gain complexity, losing the benefits of the system design.

At work I’ve been taking an existing internal API and transitioning it to a service based API. The process has proven to reveal a wide arrayf of complexity. In my efforts to manage this complexity, the best tactic has been to focus on the data format passing between the two systems. Defining expectations and the contract using the format, it has enabled simplifying the service as well as making the client code manageable.

While I’m still very much in the process of making the changes, the strategy of adjusting the data going between the systems has made other decisions much simpler. The result is that both the service and the client application can be implemented with elegance and simplicity.

Slowing Down

Speed is overrated and yet my mind thinks it is of extreme importance. The extra few minutes spent triple checking some detail is agonizing to my silly brain that simply wants to go go go. It is extremely frustrating that the process of communicating ideas is rife with peril. Just taking the words from my mind to my keyboard is a struggle at times. Typos are just one example. My eyes look at what was written and find the concepts I wanted to communicate instead of words that need proofreading.

The one tool I know I have to battle this curse is to simply slow down. Instead of the silent reading most do, I can read aloud to help improve my comprehension. My own ears filter the cruft and make clear when an idea is simply wrong. When I was a kid I took a test that suggested I was an auditory learner, so my assumption is that by communicating audibly, my mind gets a healthy does of reality.

Even though I recognize this powerful tool, my mind wants to avoid it in the quest for speed. I need to slow down and speak clearly to myself. This post is meant as a reminder.

Testing and Design

A well designed system does not always imply it is easy to test. Adding a flexible, modular design can make testing difficult. The complexity that hides behind a good design still exists, which means we need to be sure the interfaces between the different layers of the design are fully tested.

Conceptually, testing interfaces seems relatively simple, but as layers build upon other layers, things can become more difficult. Typically a layer of design will interact with libraries which may in turn have similar layers. A change at one layer may have a larger impact than expected.

Fortunately there are strategies to help manage the complexity when managing complexity! Mocks can be a good options as long as you also test the real interface using the same parameters. There are other tools such as code injection, but it is something I’m personally familiar with.

If you do have to test a complex, well designed system it may not be easy to test, but it should still be testable. The difference lies in the fact that testable software can be tested effectively. Even though the process of testing a system might be difficult at times, it should be clear that it is possible. If the code doesn’t seems impossible to test effectively (brittle tests, tons of stubs/framework for small corner cases, extremely slow tests), then it is probably a sign of a poor design. This is unfortunate as code that is difficult to test is also code that is difficult to confidently refactor.

A Busy New Year

I’ve been slacking on my writing this year thanks to life getting in the way. With that in mind, I have had a couple small things I wanted to post about even if they don’t really need a full fledged blog post.

Other Programming Languages

Recently I’ve found myself having a desire to check out some other programming languages. It has nothing to do with Python being lacking anything, but it just sounds like fun. When I begin actually taking a closer look, my desire quickly fades away into the reality that learning another language would be really hard and have very little benefit. Python is a great language and no matter what other language I try, heading back to Python always ends up being a beneficial decision.

If I did have a bit more motivation here are some languages I’d like spend some quality time with.

A Silver Lining Amidst Tragedy

The new year brought a painful dose of tragedy in the loss of our friend Esme. To learn more about what happened and to find information on how to help check out these words from waterloo records. Esme was a really amazing person. She loved music and was an example of the kind of person that makes all the hard work and money spent being in a band completely worth it.

Losing someone is never easy as it creates a void. Something is missing that you wish was still there. The experience is different for everyone, but what is consistent is the mark left behind. It is safe to say that Esme left a beautiful and deep mark on everyone around her.

It is this mark left behind that we can see some positivity within the tragedy. People begin to speak up and share stories. Friendships are grown and the community rallies. Some people find new meaning in what they do and others make commitments beyond themselves. I hope that as we reflect on our lost friend we do so with a desire to change how we live today. Let great things rise up from the sadness we feel in the loss of our friend. We as a community have already begun to react and while our feelings are sad, the actions are becoming more powerful and spread memories of a great person.

Holiday Recap

I’ve slacked a bit on writing thanks to the holidays, but that seems totally appropriate. Christmas is always a busy time because it provides some time without work which ends up being a lot of time for other work. Whether it is shopping for gifts or working on new music, there is something that needs to be done.

This time we went into the studio for some demoing. There are a lot of reasons to demo music. A demo is really when you record without a specific plan to release some music. Our goals were to put together some of the new songs we’ve been working on with our new drummer to see what people think and get folks excited about helping us with a new record. We’re pretty happy with how things are sounding, which only makes us more excited to keep writing music.

As music ended up taking a vast majority of free time, it meant that the work I did need to get done took up the rest of the time. This wasn’t terribly difficult work, but it was time consuming. One thing that made it easier was Xenv, a thin wrapper around virtualenv. This little tool is really just my own experiment. I found when using virtualenv it was all too easy to just use Python. This is an advantage in many ways because it means the tool is getting out of your way. But, when I wanted to work on creating a new environment (not just a virtualenv), it was not as direct. Xenv gave me a really simple place to connect to a specific environment. It also lent some clarity to my Dad project. It isn’t a lot of code and I don’t think it has to be used as much as implemented for other situations. The concept I think is most important aspect and generally it has felt like a personal success.

After Christmas, we did more recording and had a great New Year’s Eve show. It was the first time using some new Christmas gear and things seemed to go very well. New Year’s Day we went with some friends to The Choctaw Casino before heading to Dallas for the evening. We enjoyed a great Ethiopian meal and saw both my alma maters battle it out in the Ticket City Bowl. It was a great time.

I don’t have any major resolutions or new commitments this year. My goal is to be an incrementally better person, which seems pretty doable.

Instinctual Programming

Programmers often are searching for optimizations to their workflow. Editors, shell scripts and customizable tools are all examples making your development experience faster. As a programmer, you dedicate your life to knowing tools well in order to use them effectively. Effectiveness with many tools is a matter of making their use instinctual.

The irony of instinctual programming is that the tools you’ve become dedicated to finally get out of the way of your thinking and focusing on a problem. You find flow in thinking about and solving problems. The code ceases to be something you are typing into your editor and takes shape on your screen as though you are publishing your thoughts as you think them. Your body ceases to act based on your command and instead listens to an instinct you’ve developed through dedication to your tools and environment.

As nice as this may sound it is critical to recognize what I said in my previous paragraph. The tools you are dedicated to finally get out of your way. All the tooling and customizations you’ve made to optimize your development experience fall away to the background. Many times the tools you believe really help may actually be standing in the way of your focus and the natural instincts you have to solve the problem.

I’m not suggesting you shouldn’t use powerful tools. I can say from experience there have been many a time when my job was not to conceptualize and implement complex algorithms. It was actually mundane text editing that required next to nothing in terms of critical thinking. In these cases, mastering my editor became an optimization to help in hurrying through the mundane to get back to the important work of the day.

But just as my editor and tools have helped me to optimize the mundane, they have proven to be distracting. An infinitely customizable piece of software offers endless optimizations as well as an endless supply of pointless things to change. Change inhibits instinct. Instinct is when you body takes over and your mind is free to do other things. There is a reason cars all have roughly the same interface. Drivers immediately know how to drive any vehicle and to do so instinctively because they do not have to think about the basic tasks like steering, breaking and acceleration.

In the development world this relates to things like working with source control, build/test scripts and deployment processes. All these things should be instinctual processes that do not require excessive thinking. The same goes for documentation. Imagine your favorite programming language didn’t have a central place for documentation. You had to constantly search for random articles in order to find out how to use the language. You’d quickly change your opinion of the language and find something that was more usable.

Instinctual programming is not about optimization. It is about repetition to the point of mastery. It is important to recognize when the process you are repeating may not be optimal, but at the same time, it is important to beware that constant change will never allow you to act instinctively.