Personal.X-Istence.com

Bert JW Regeer (畢傑龍)

Editing SQL data dumps

I must enjoy pain on a huge level, as I am still using MySQL, and even worse, I am still using software that is using reserved words in MySQL, so doing a dump from the DB and then re-inserting it will cause some funny problems.

Now, since that will fail because of the reserved words I have to manually edit the field names, and add the proper quotation marks around it, so MySQL will grok it. I have a multitude of editors available to me: TextMate, SubEthaEdit, nano, vim and a few others.

I try to open it in SubEthaEdit. It goes on it's merry way and allocates a gig of ram, and then fails miserably. Same thing happens with TextMate. These programs were designed to do text editing on text files, with syntax highlighting.

nano causes the system to lock up while it tries to allocate about 1.10 GB of ram before it too is cut off by the kernel. This is insane, text editors that are unable to deal with a relatively small dump. Only 600 MB worth, I have done dumps where the data was well over 16 GB.

So after all this, I open it in the application I knew could handle it, but hate to use since it's syntax is really still baffling to me. vi.

vi uses 10 MB of memory, and has the file open and ready to be used within a few minutes. Searching through the file is just as fast as using grep or other tools. The makers of all the other text editors should take a page from vi's book, and figure out how they got so much functionality into such a small package, and off course being able to open multi-GB files is always a big plus for people that have to deal with such things!

Ruby on Rails

And why I will never use it: Slide by creator, about people who don't like Ruby on Rails.

Now, for a more serious reason, I absolutely dislike how it is structured, and I dislike Ruby itself. I have never been able to wrap my head around Ruby because of the way it does certain things, and it's syntax. Not only that, in my experiments, and working on more mature projects I have NEVER been able to find a way to scale it in any reasonable fashion, as the RoR people all seem to think that throwing more CPU's at the project is the way to go. That too me is retarded, as soon as I need to scale bigger with PHP, I implement some caching of the op-codes for PHP, then I implement an op-code optimiser, and then I start looking at doing load balanced servers, maybe even just a few front end squid servers with one apache back-end, or one front-end lighttpd server and a few back-end PHP fastCGI implementations ready to rock.

Yeah, that slide just puts me off the language forever. Fuck you indeed.

mod_magnet for Lighttpd

So today I found out that I had accidently broken my blog by trying to nest a url.rewrite-once in a $HTTP["URL"] statement in my Lighttpd config. Which meant that my rules for rewriting Drupal nice URL's were not being executed, as apparently you can't nest them like that. Took me a bit to track it down, but once I did I found a link to nordisch by nature which included a new mod_magnet script which did the same thing the rewrite rules but better.

Looking at mod_magnet now, I think I like it better than the Apache .htaccess stuff, as it is just like a programming language so it is extremely powerful. The thing that kind of scares me is that it runs within the server's core, not as a seperate module, then again, PHP runs as a module within the core of Apache when it is known as mod_php. (Lighttpd does not have mod_php support, but does do FastCGI properly, unlike Apache).

More about mod_magnet as I come across other neat tricks. Maybe I will finally get my "About me" website back up and running, as Lighttpd does not do SSI includes like Apache did (no nesting. Understandably, but still ...)