SO many of you (where many is defined as N greater than or equal to one) may remember that the Wiki was down for “security reasons”. Well, this wasn’t that someone had hacked the site, trashed the data or even just spammed the comments pages: it was, more literally, a security issue with my web hosting provider, which tightened its security provisions on script hosting and killed OddMuse, the wiki engine I was using. Fortunately Bolot Kerimbaev, a friend from Taido class, uses the same wiki engine and the same service provider, and he told me that the use of semicolons rather than ampersands in the URLs was causing the problem. A simple fix, really.
Well, not so simple.
I worked at it for a while, but found that other features were broken on my site as well … because semicolons were EVERYWHERE in URLs in the OddMuse code. At first I tried changing them individually, then, as the problem got more complex, decided to try to abstract out the separator character into a $SEP variable that I could change and control. That worked well … for a while … but eventually the OddMuse instance I was working on became unstable, then stopped working entirely. Because I’d been futzing around with vi on a local directory and uploading the Perl script to my web site rather than using proper source control (for shame!), I couldn’t even roll things back successfully without losing all of my changes.
SO I called Bolot for help, and we got together at Atlanta Bread Company at Perimieter Point to take care of the problem. This Atlanta Bread Company (one of their best stores) is right next to a Starbucks Coffee, which kindly provides T-Mobile Wi-Fi. So we logged in and tackled the problem, and after a few minutes showing Bolot what was going wrong, he took over the keyboard to fix it.
And a whole lot more.
First, rather than laboriously editing the files locally and uploading them with FTP, Bolot suggested we use SSH and edit the files in place so we could see the changes immediately. This point is so important I’m going to follow it up with a separate post, but that’s another blog for another day. Now, apparently I got through thirteen and a half years of Georgia Tech without using SSH extensively (I almost always relied upon remote X Windows logins prior to my Windows/Cygwin days) so this option never occurred to me. Bolot, however, was able to do it almost instantly:
ssh -l username hostname
Moreover, we found that using the Cygwin instance on my laptop, we could not just SSH in to the site … but could actually use VIM, the enhanced VI editor. And with a few quick commands, he had syntax highlighting and color schemes working – remotely, via SSH, in the bash window already set up in Cygwin on my machine. Other than the window title and the lack of a toolbar, it looked identical to the gVIM I frequently use on my machine.
(Note tab completion actually works on setting the colors!
After finding and fixing the first and most important of the problems, we then went to test. Bolot immediately became frustrated with my Internet Explorer installation and turned to my copy of Firefox instead, which was hopelessly out of date. Within moments, he showed me why people use Firefox: within moments he was able to painlessly install gesture support, web developer tools, a variety of search tools, flash blocking, ad blocking, and a host of other applications which made the Firefox experience almost palatable, despite the fact that its interface is still slower, clunkier and uglier than IE. Shortly thereafter, Bolot was able to find and eliminate the rest of the problems in OddMuse, realizing that the problem was not semicolons in URLs in general, but the presence of the string “;id” in the URL. By the time he was done, he had not just corrected the problems in OddMuse itself, but also other problems with my installation which were interfering with stylesheets.
SO: an improved browser, web site, method of connecting to the web site, and a whole host of other tools. All delivered straight to my brain in less than an hour.
Lessons learned: Be dogged with your tools. Find out all they have to offer you. Use them as they were best intended. And be dogged about eliminating problems in your way. Make it possible to get feedback on changes instantly, so you make many small changes safely and feel free to experiment. Then, you will be able to work far faster than you ever thought possible.
More thoughts on this later …. but, until then, hats off to you, Bolot Kerimbaev, Technology Commando.