kentcowgill.org/blog

Turns out I was able to get Text::VimColor to work after all - seems I wasn't quite reading the documentation properly. See, vim needed a little help to figure out what's what - in this case, what kind of terminal it's attached to (which it isn't in this case, which is running as a CGI under apache).

According to the documentation for vim:

-T {terminal}
        Tells  Vim  the  name  of the terminal
        you are using.  Only required when the
        automatic way doesn't work.  Should be
        a terminal  known  to Vim (builtin) or
        defined in the termcap or terminfo file.

So all I really needed to do was give it a hint so it wouldn't complain about not being attached to a terminal. Therefore, the solution is:

my $vim = Text::VimColor->new(
  string => $code,
  filetype => $filetype,
  vim_options => [qw(-RXZ -i NONE -u NONE -N -T xterm) ],
);

Unfortunately, it's slow.

It's a known issue - this is why Apache::VimColor uses caching to speed up the HTML generation. In fact, with five code snippets on the main page (just prior to this current time of writing) case the page generation speed to go from about 0.07 seconds to nearly 1.1 seconds. That's quite an order of magnitude increase. And that's not counting adding these two snippets in a single post⁵, nor the posts in the future that will undoubtedly have more code and other syntax colored snippets.

⁵ Adds another 0.4 seconds for a total run time of nearly 1.5 seconds.

Minding my own business, browsing my del.icio.us network, I see a webcomic -- which reminds me, it's been a while since I've seen XKCD. So I, click the 'previous' button a few times, and stumble on this gem.

Earlier today, I was walking toward the kitchen, Spike was looking at me, and I swear as I walked up to him, I pointed at him and I said exactly "You're a dog!".

I guess I shouldn't be surprised.

I was hoping to post up bits and pieces of my .vimrc file - after all, Text::VimColor displays .vimrc syntax just fine. Naturally.

Unfortunately, Kate doesn't appear to support .vimrc files.

At least not yet.

Until I write Syntax::Highlight::Engine::Kate::Vim, I'll have to make due with using the 'LPC' syntax file, which at least colors comments differently from non-comments , and somewhat reliably.

Here's a snippet from my .vimrc for some new (to me) features that I've been playing with lately:

" auto indenting, dealing with tabs
" how to deal with tabs.  indent of two
set tabstop=2
" expand tabs to spaces
set expandtab
" number of spaces to use for autoindenting
set shiftwidth=2
" auto indenting features
set autoindent
set smartindent
"make tab in visual mode indent code
vmap <tab> >gv
vmap <s-tab> <gv

Enjoy!

(Note, due to difficulties and annoyances beyond my control, I've manually edited the above snippet using Text::Textile formatting.) Figured it out.

I think I know why I can't show HTML pre tags inside a pre block, and it's not Kate's fault, and it's not Textile's fault.

It's my fault.

  if( $text =~ m/<pre class="([^"]+)"/s ){
    $lang = $1;
    $text =~ s/<pre[^>]+>(.*)<\/pre>/$1/s;
  }

See the problem?

I'll probably have a few more posts about this until I figure it out.

But it's not like you were doing anything better than reading this :)

Always looking for inspiration, I happened upon Jonathan Rockway's blog and noticed that he makes use of syntax highlighting in his Angerwhale blog. After a few aborted attempts to use Text::VimColor, I broke down and decided to try out Syntax::Highlight::Engine::Kate.

I'm pretty pleased, after I finally figured out enough of how it formats bits of code and how to translate that to my vim colorscheme of choice.

All it takes is the following modifications to your text:

  <pre class="Language">
    # your code here
  

And if Kate recognizes your 'Language', it'll format your text.

N.B. -- I can't quite figure out how to show a closing 'pre' tag inside a 'pre' block. Hope that doesn't offend you.

As a follow-on to my last statistical post, I thought I'd also create a graph that tracks what days I generally post on.

The SQL is amazingly the same, but only slightly different. In fact, nearly everything is exactly the same -- I should just generalize the code.

I don't mean to make this the "Andy Lester" week, but the company I work for is in technical debt -- there's no better way to put it.

For a little introduction on the concept of technical debt, there's a nice wiki page. But what brings it home for me are the slides from Andy's infamous technical debt, which are available on his website.

So what am I griping about?

Version control.

Love it.

Hate it.

Gotta have it.

Unfortunately, it's a big undertaking.

What we currently have in place is a script that does:

  cp $current_file ARCHIVE/$filebase-`date`.$fileextension 
  rsync $current_file $production_cluster

It even has enough brains to accept multiple files as arguments, even if they're in separate directories, and create the backup in a given files' subdirectory. While this (kind of) works, it's a pain for "rolling back", which I just had to do due to technical problems at our other office out of state. Especially painful when there had been changes to files that haven't made it to production, but the developer (me, in this case) is blissfully unaware of said changes, so it's not clear which version to restore.

Ugh!

Similar frustration for trying to re-restore the changes for eventual re-promotion.

But moving to a real^™ version control system is a chore. Why? Because there are 5-6 years worth of these archive files that would be nice to have as version history. Altogether, there are about 99,300 files total. And the perl program I wrote to import them into our version control system³ takes an average of about 3 seconds per file⁴. My math tells me that's about 3.5 days.

³ Perforce seems to be what the company has elected to use, even though the few times I've tried it, I've hated it. Nowhere as intuitive for me to use as more reasonable (and by the way, free) version control systems such as subversion.

⁴ Pitifully slow. But since the Perforce server is a bit far topologically, speed issues are to be somewhat expected.

I ran across some guys' blog recently where he decided that for every 100 posts to his blog, he should figure out some of his blogging statistics. Or something like that.

One of which was to see what time of day he generally posted. He explained some procedure for doing a database query from the shell, piping the output through some command line utilities, and then running some commands or somesuch to feed into some graphing program (gnuplot) to produce a chart.

Seemed like a terribly manual process.

Inspired by that, I created the following:

Which is pretty much what I stated, but it updates automatically. As in every time it gets displayed. What you see above is current, even now. However long ago this was actually written.

For the morbidly curious, the SQL to create the data looks like this:

    select count(*) as posts,
      substring(blog_date,12,2) as hour
      from blog
      group by hour;

I keep getting reminded of the story about the broken window I read recently in a great book I've purchased called The Pragmatic Programmer.

Most recently was this set of conversations between a coworker and myself, and my manager and myself.

Coworker Y: "Kent, can you please run sudo command xyz on the production cluster?"

me: "Sure, but only if you promise to fix the race condition that causes condition X on the production cluster."

Coworker Y: "I would, but it's not on my platter."

me: "Whose platter is it on?"

Coworker Y: "Coworker Z."

me: "This has been a known issue for nearly a half a year, hasn't it?"

Coworker Y: "Actually, about 9 months."

... time passes ...

phb: "Kent, does sudo really need to be run for command xyz? Can't you just¹ do it with normal user privileges?"

me: "I assume so - they wouldn't ask me to do it otherwise, no? BTW, the cumulative time taken to run or have someone else run [sudo] command xyz every time this happens is probably much greater than just fixing the race condition that causes condition X, which as I understand has been a known issue for at least 9 months."

phb: "They tried to fix the race condition and failed. But I didn't know coworker Z had been running sudo command xyz all along, I thought he had another way to deal with it. Until he comes back from vacation, can you take care of these requests?"

me: "I'd much rather the race condition get fixed."

phb: "I agree, however coworker Z is out of the office this week and coworker Y is swamped -- we will have to wait."

me: "Coworker Z hasn't been out of the office for 9 months, though."

phb: "Coworker Z and coworker W tried a couple of times and could not get it fixed."

me: "Did they exhaust the entire technical resources of our company?"

phb: "No one really had lots of time on their hands. If coworker Z tells me again they can not fix it, I will hand it over to someone else for sure."

I really wish conversations like this didn't happen.

I really wish that more people at my job cared more about what they did.

Why did coworker Z and coworker W give up?

Why didn't they ask anyone for advice?

Sure it doesn't take much time to run sudo command xyz, but how much time is lost from breaking your concentration, switching contexts into "firefighting" mode, running the command, and trying to pick back up wherever you left off? And then what if you're so distracted by this craziness that you have to write a blog post about? How much time gets lost then?

I really wish people would care more.

¹ Andy Lester pointed me² to a great rant of his about this very phrase "can't you just...".

² And a second article linked from Andy on complexity management (I think he's on to something here)

Please forgive me - I'm working on updating this. "This", of course, can mean different things. But what I mean is that I'm working on finishing my Grand Unification Project. What's that? Well, I'm finally bringing everything together. And finally making my blog public. It's done in Catalyst, everything else is plain CGI.

All this means is that you might find some things that don't work from time to time. If you encounter this, please excuse me. I'm only human. I can't know about every single bug. Yet.

So far, most of my blog has been updated. I even have a new version of my photos up and running. Even my resume has been somewhat updated... :)