So why am I talking about reactive vs. proactive? In case you haven’t seen it yet, AT&T recently came out with an app called AT&T Mark The Spot. The idea behind the app is that if you have a dropped call or bad reception, that you open the app, click your problem and it will mark the spot by sending the information to AT&T. I am still not entirely sure how this app works in an area where there is NO reception, how does it know where you are to tell AT&T?

But I guess that’s a little beside my point. My point is that if AT&T had done this when no one was complaining of service issues, they would be considered geniuses. But since they waited until Verizon was taking potshots at them with their 3G map commercials and New York and San Francisco (the 2 locations in the US with the highest density of AT&T smart phones) started having serious connectivity, coverage, and consistency issues, it was reactive and borderline pathetic. One thing that should be noted is that AT&T is not doing this in replacement of testing their own network. I have no idea where that myth came from and can’t imagine why it holds any credibility. Because they are being reactive with this tool, they are considered trying to recover.

I actually think that although they are behind the power curve, this is actually fairly ingenious. This is a classic case of the squeaky wheel gets the grease. The places with the most common issues will likely get the most attention the quickest. It’s a good customer service move but might be a bit too late to save a lot of customers.

In the future, being proactive instead of reactive (no matter how nifty your reactiveness is) is the way to go. It can not only save you customers (if that’s the business you are in), but it can also get you a leg up in your market or your job. Plan ahead and act ahead.

No related posts.

The first and foremost reason that I write blog posts is that engineers who spend a lot of time figuring things out on the fly could use a helping hand. A lot of that figuring is done piecing together parts of other people’s solutions to problems from various blogs and papers. Every time I run into an issue or fix a problem, I try to write a blog post about it. I don’t do this because I feel that I have more to offer than anyone else, I just feel like my work should be able to benefit others (there is no use in reinventing the wheel). And to top it off, if I do something and someone has a better way, I like hearing about it in the comments or from an email.

My personal preference when writing blog posts is when possible, short and sweet. Just do what you’re going to do, explain when necessary, but convey the idea and intention. If something needs substantiation, context, or proof then give it. Don’t just say something like, “writing your query like XXX will speed it up by 100ms” without context. I wrote a lot of queries, that run in hours; 100ms won’t mean anything to me. I also am not a huge fan of academic papers or pure blue sky optimistic benchmarks. Now that’s not to say that those papers don’t have their place, but in reality, most situations aren’t blue sky with unlimited budget and all hardware being equal.

Nirvdrum prefers academic papers with lots of peer review and benchmarks. Those types of things are great for theory, but in practice, implementing in such circumstances is not the norm. I typically lump white papers into that group as they tend to be slightly biased towards the companies that prepare them. White papers are great for ideas for solutions, but I think the real nitty gritty lies in finding the right blog post or posts to help you find your solution.

Related posts:

1. Busiest Person You Know

The method for this was a lot more straightforward than I expected it to be. For the conversion tool, I used Nirvdrums fork of svn2git. It a feature complete version of the svn2git portion though the rest of it is still is development. Since it is a Ruby gem, getting it installed was a breeze. Just make sure that you have Ruby and rubygems installed.

Then I created a authors.txt file to make sure the subversion committers got transferred over to Git cleanly. The file looked like this:

Then I went to my Remote Code Storage Location of choice (Codaset) and created an empty repository for my personal files. I then cloned the repository to my local machine:

Then I changed into the directory of the personal-files git repository and ran the following command:

The entire process took me about 15 minutes. Then I did a simple git push back to Codaset to save all my changes.

Related posts:

1. Git Command Aliases
2. Remote Code Storage
3. Git Branch Name in Your Bash Prompt

I have been using version control in some form or another for many years. I started with CVS, then moved to Subversion (which I still use quite a bit), and now, as my latest post about Git GUI’s on the Mac suggests, I have moved to Git. The one thing that has been consistent across every single transition has been that I had some sort of remote code storage every time. During the CVS days, I used a CVS pserver and stored my code locally and remotely for safety (and ease of checkout/deployment). For subversion, I always stored my code locally and used an apache install somewhere with a WebDAV module to get at and deploy whatever code is necessary.

Ultimately I use remote code storage for 2 reasons, back up my existing code base (so I have it in more than one place) and to have a visualization of what is going on in your project. That visualization is handy to be used as a central consistent view for multiple people (unlike a personal client which can be different per user).

Now in my more experienced days, I have decided that Git is the best VCS (Version Control System) for me. Not only does it allow me to use branching in a way that makes sense (which is something that Subversion still doesn’t do), but there are remote code storage entities that satisfy my requirements exactly. I have a few requirements:

• Look good
• Allow me to deploy using your system (via Capistrano)
• Allow me to manage projects (ticketing, wiki, etc)
• Have access control (user levels, etc on a per project basis)
• Support my version control system of choice (Git)

So now the point of this post, what’s out there. I have essentially found 2 options and have already had experience with both:

• Codaset
• Github

Codaset:
Codaset is still in beta so everything that may or may not be wrong with it will definitely be getting better. I have a great appreciation for the aesthetics that Codaset has. I find the color easier to work with and look at than Github’s basically gray and white theme. It may not have a lot more color, but the little bit helps. And speaking to that colorization (is that even a word), the colorized diffs are fantastic. Although Github has colorized diff as well, I find the Codaset diff’s are much easier to read.

Another great feature of Codaset (back to the visuals) is the idea that you can change the color format of a file while viewing it to any number of different types. Perl files are displayed differently than Ruby files, etc. Since I, like many avid geeks, program in a whole mess of different languages, this is a handy feature to help your eyes settle on syntax.

Github:
Github has a neat advantage over Codaset called Gists. Gists are basically pasties except they are a repository unto themselves and are therefore forkable and versioned and everything else cool that version control allows. As Github is more mature, there are a few more features it has as well like blame (which is handy for seeing who did what to a file).

Conclusion:
In the end, I have a Github account that I occasionally use for Gists, but I ended up on Codaset. So if you haven’t seen it, check it out. Let me know what you think. If you prefer Github, let me know why. But if you’re like me and although you may not be the best at making things look nice, but you want your tools to look nice, then maybe Codaset is the tool for you.

Related posts:

1. Converting From Subversion To Git
2. Git GUI on Mac OS X
3. ColorTail Gem

If it takes that engineer, admin, developer or whatever 10 minutes to get focused after each interruption and the initial getting into the office and getting into the swing of things; that means that out of an 8 hour day, 1 hour is wasted just refocusing. Refocusing just puts you back on the issue, it doesn’t put you back in the zone. Some engineers only get in the zone once per day. At that rate, you can massively waste someone’s productivity with a 10 second interruption.

What’s my point? Good question. That commercial/question/interruption that someone is pushing onto that engineer could be the straw that broke the camel’s back on a deadline. So be aware of the situation that your people are in, who is talking to them, who has access to them, and who takes advantage of that access. Those precious periods of concentration can afford you a huge win or bring about a big loss.

Related posts:

1. Creating a Slave DNS Server on Bind9
2. Culture of Product vs. Culture of Code

The problem is that this doesn’t interpolate the newline character. (For more information on interpolation, see Wikipedia here.) In order to have the newline interpolated, you need to add the command line switch ‘-e‘.

This will force Bash to interpolate any non-literal characters in the quotes. Note: Unlike Perl, single or double quotes don’t matter here when Bash is deciding whether or not to interpolate the new line characters.

Related posts:

1. Git Branch Name in Your Bash Prompt
2. Multiple Input Locations From Bash Into Ruby
3. Converting From Subversion To Git

Like any corporation, Oxford is in the business of making money and in this case, they are doing so by deciding not to pay for my PT. In the long run, the lack of rehabilitation will likely leave me in a weakened state and generally more prone to injury once I go back to my skydiving, motorcycle riding, MMA, and BASE jumping ways. If Oxford had said, let’s make sure he can walk and then we’ll cut him off, at least he’ll have a foundation and be less prone to injury; then they might be saving a bit of money on me in the long run.

So what does this sob story have to do with IT? A decision made now in order to save money can end up costing you more of time and money in the long run. And since time is money, sometimes a little bit of planning can go a long way. Should you add the feature now because your biggest client wants it by Friday. Well if you do that, then you might lose a few smaller clients along the way and the word of mouth may be more damaging than temporarily upsetting that large client.

Perhaps you set up Nagios and immediately turned on alerting without learning the thresholds that your machines typically sit at. Then you get a whole set of alerts and you spend more time trying to sort through the real problem ones versus the ones that just have a slightly abnormal operating level then you would if you just looked at your machines thresholds to begin with.

There are a million examples that could be listed here. The point is, before jumping into a decision, try to make sure that you’re not going to be paying for it in the long run. A little planning can go a long way.

Related posts:

1. Bing! Hunch! Decision Engine!
2. Shortcut Notation in Rails Callbacks

So if you know any rock star sysadmins, sysadmins who save the day, sysadmins who have done stuff previously that have saved many days or any combination thereof, enter them: http://www.bigfix.com/rockstar/enter.php.

Related posts:

1. Deleting Lots Of Files (SysAdmin problem solving exercise)
2. Count Instead of Sequence

You’re probably wondering why I putting this in a blog where I primarily spend time writing about technology and the things I figure out therein. Well, it is generally applicable because I come up with the most time saving, interesting, and generally reusable solutions to a issue when I am the busiest with other things just trying to get it done.

Recently Joel Spolsky wrote about being a Duct Tape Programmer. And many of the solutions I am referring to here are duct tape style solutions (also known as the ones that stick). It’s usually the quick and dirty solutions that last the longest because they are the simplest and yet somehow most effective (and no, I am not only talking about programming). I’m talking about getting things done. So be the busiest person you know sometimes and just get it done. The solution will probably be better and more effective than you think while you’re doing it.

Related posts:

1. Social Media Information Propagation
2. Thoughts on Blog Posting
3. Why Idea People Should Twitter

Well the solution, as is turns out, is pretty simple. Just go into your browser’s cookie repository, find and delete the cookie that calls itself GASO. And poof, the overlay is gone.

Related posts:

1. Transferring Email From Gmail/Google Apps to Dovecot With Larch
2. Thoughts on Blog Posting
3. Custom Google Maps Marker With YM4R_GM