Log files are dull to look at. Lines and lines of text and no pretty colors to make it nicer to look at and easier to spot those weird errors you can’t simulate on your machine.
Vim rocks and writing a syntax file is supposed to be a breeze judging from the vast amount of syntax plugins out there. I didn’t quite find one I liked for syntax highlighting HTTP log files, so I thought I’d get down and dirty with some vimscript myself and see if I could hack something together.
It turned out alright I think. So to share the fun I’m hosting the logsyntax.vim plugin on Github and the vim.org scripts library for all to use. It highlights dates, HTTP verbs, URLs, IP addresses etc for IIS, W3C extended, NCSA and probably a bunch more typical log formats.
A while ago I noticed that some of my older posts had some silly misspellings in it, so I was looking for a way to spell check all my posts in one shot. I couldn’t really find anything that was free, so I figured I’d try to write something myself to do this for me.
I knew about the free and open source Hunspell spell checker and that you can use it from the command line. So I thought using that together with the WordPress export XML file which has all your post’s content it should be possible to spell check the whole lot.
The end result is a PowerShell script which reads out the XML export file and runs it through Hunspell, parses the spelling errors found and finally bundling it all into a simple HTML report.
It worked nicely for me, even though it’s pretty crude and simple. I only had to use this once, so I don’t see the point of fine-tuning it a lot further.
However this could be handy for others who want to do the same thing, so I cleaned it up a bit, slapped a readme file on it and posted it on Github as the WordPress full site spell checker.
Check it out if you want to spell check your WordPress blog in a single run and maybe this will be good enough to get your job done. You find more info on how to set up and use it on the Github page.
Space invaders. Probably one of the first computer games I ever played on a console. The blocky invaders have turned into pieces of geek culture all by themselves showing up all over the place from graffiti to tattoos and post-it art. So at one point I ran into this image on Flickr with yet another space invader on it and thought it would be great to use that as a desktop wallpaper somehow. I tried it out but didn’t like the result enough so I decided to make my own. From there I had a template to create some more and now I’m putting them up here for you to download. Yay!
All images are Creative Commons licensed so you can use them quite freely and share them with anyone you like. To maintain the crispness of the awesome gradient backgrounds (yeah, that’s about how far my Gimping skills go) all images are saved in PNG format for maximum quality. I’m also sharing the original GIMP XCF project files with these so that you can go ahead and create your own smashing mash-up of the space invader wallpaper suited to your own personal taste. There’s a template in there with the space invader ranging from very small to rather large. New backgrounds, new resolutions, new compositions, it’s all within your grasp if you get yourself a free copy of GIMP. Don’t forget to link back here if you create something truly awesome btw. I don’t mind some kick-ass wallpapers myself.
All files are released under the Creative Commons Attribution-Share-Alike license just to keep things a tad fair and make sure that everyone finds it way to the source files and gets the same chances of being creative with them. It’s all about the sharing baby!
Images are available in a blue, gold and green background and in 1024×768, 1280×1024, 1440×900 and 1680×1050 screen sizes.
Click the images to get a larger preview. To download you just click that little blue arrow appearing in the right upper corned when hovering the thumbnail.
Can’t see a widget? No problem, click here for direct linkage.
It’s turning out to be quite the musical week in posts here, but I just had to post about this one as well. Do you remember that 60×60 Buzz compilation I started last year? Well, since the Buzzchurch forum turned out to be a live bunch of music producers supplying the main source of tunes coming in for that entry, Owen Gilbride aka Cryptowen thought it would be cool to start up a new compilation. This time the theme was to write a soundtrack to the End of The World. How about that?
You can guess where the chaotic vs calmer tracks will be at right? Anyway, this collection is another one containing a wide variety of tracks in genre and style, which makes this one great to listen to and explore some new sounds. No matter what style you are in to, you’re bound to find some gems in here that you’ll like. It’s free anyway, so nothing is wasted if this turns out to be not your thing at all, but I doubt it.
Feel free to leave some comments here, or at archive.org if you like this release. I’m sure the folks who participated in it (like me) will love it (like me).
Update: there seems to be a problem with the VBR versions of some disks, which results in the VBR zip-file not being complete. Every file seems to be available in OGG format however.
The name servers are pointing to the new Linux machine from now on, and things are running smooth (so far).
The WordPress database issue was solved by upgrading to the latest 2.3.1 version, which required a DB upgrade anyway, and fixed the tables that where incorrect. I had manually fix the md5 hash codes for the passwords, but since only a few users have accounts here, that wasn’t a problem.
I have nice permalinks up again now, without that index.php thing in them even, so that’s even better than before. I’m using Dean’s Permalink Migration plugin to make sure old links from all over are still working, and not loose too much Google rank etc, though I doubt that all those http errors from the Windows machine did a lot of good for that.
While I’m at it, here’s a tip if you plan to migrate a WordPress installation any time soon. Then you’ve restored a database backup on a new system, the first thing to do is adjust the blog and site URL to the new location. While you’re at it, change the blog title as well.
WordPress has a habit of using those URLs a lot in redirects, and if you forgot to change those, you’ll end up being swung over to the site your backup is from. If you didn’t change your blog title there’s a big chance you won’t notice you’re now working on the live site, and might end up screwing things up.
Which ain’t fun.
You can find and change these parameters in your mySQL database in the wp_options table with the values (option_value) “home“, “siteurl” and “blogname“.
Yup. After the latest hickups and glitches and the fact that hosting on a Linux machine is considerably cheaper at my hosting co than doing the same thing on Windows I’m moving this blog over to a brand new spanking Linux machine in the following days.
I’m hoping I’ll manage to set up things smoothly, but working in the IT biz makes me expect a few bumps here and there anyway. I think I’ve ran into the first today, as I noticed my WP database doesn’t seem to be up to date for some odd reason, causing issues with the new setup as I couldn’t login any more with my admin account.
I’ll post again here after the move, so hopefully you’ll be seeing that post pop up automatically in your rss readers. If it takes too long, maybe check back here the oldskool way, by pointing your web browser to this very address.
Things that suck: having to change your permalinks.
They’re called permalinks for a reason, but if for some unknown reason you keep getting CGI errors on the old links you can’t just keep that setting can you? So now I’m using the old and ugly WP default permalink structure again, linking to a post using it’s ID. Blegh.
I hate it, but I nothing else seemed to do the trick. Looking up the error, it turns up a lot all over the internet, but nowhere there’s a solution to be found. So if you see this:
The specified CGI application misbehaved by not returning a complete set of HTTP headers.
You’re in trouble.
It has something to do with the combination of IIS and PHP, and maybe something with timing issues on faster, multiprocessor computers, but there’s no fix around for that.
So I guess I’m stuck with it for now. I’m thinking of switching to a Linux hosting soon, since those are not only cheaper, but I guess more stable when it comes down to PHP support. You also get PHP 5 there, so that’s neat as well.