1 April 2008 21:50
There's a tagging system which is starting to creak under the sheer number of different tags, and several back-end parts of the site make use of AJAX calls.
Most of the script lives in a single file common.js which I cobbled via a process of trial and error, augmented with a little copy & paste coding.
It works. But I knew I could do better ..
This was my first attempt to make a site be truely dynamic and "pretty". It has succeeded in that respect, although the lack of members makes the site itself essentially a failure.
This library made it almost too easy to add flash. I liked it a lot.
Having said that though the sheer scope of the library and the way it didn't fit in the way that I coded made it painful to use at times.
It works, and it works well. Like it? Yes. Love it no?
Most of the code here is the simple kind, reverting back to the way I worked on the Debian Administration site; we're talking about basic effects such as:
- show/hide a div
- make an AJAX request every now and again.
- Do a bit of auto-completion.
To get more of a feel for whats out there I wrote this initially with my own code, then later migrated it to jQuery.
Quite frankly jQuery rocks. The way it works is a little strange at first, but it is so natural after a while. As an example:
// find the div called "foo" - hide it.
I'm liking this library a lot recently, but only time will tell if I use it more.
In conclusion I filed #473125: ITP jQuery failing to see the existing ITP already present.
ObQuote: Stand By Me
5 April 2008 21:50
François Marier has recently been posting some interesting entries about the Mutt mail client upon his blog.
His tips are pretty basic, but that doesn't make them less useful. So here's my tip of the day: reply_regexp.
When you're viewing a mail, and you choose to reply it the subject of that mail is the basis of your message's subject. For example given a message with "Subject: hello" your reply will typically have the subject "Subject: Re: hello".
This is real rocket science here, people.
Imagine you're using SPAM filtering which tags messages it isn't sure about with a prefix "UNS:". Suddenly things don't look so hot, as you might end up with a mail with the subject:
Subject: UNS: Re: Hello
Reply to that mail, whilst being half-asleep, and what do you get? You get this:
Subject: Re: UNS: Re: Hello
Bad. Ugly. Wrong.
The following snippet in my ~/.muttrc file correctly deals with this case:
set reply_regexp="^(((UNS:[ \t])|[rR][eE]:[ \t])*)+"
Neat. Cool. Nice.
I've paid for some advertising upon the LWN.net site. (No link, I'm not trying to game things here.)
I didn't know what to expect, but I was willing to risk the expenditure as a way of saying thanks to them for their great content. (Because of my Debian Project membership I get a free LWN subscription, as do all developers. see here for details if you're a developer without a subscription.)
I've paid $30 and that has given me a months run of my advert, with clickthroughs hovering around 1%. Not horribly bad at all!
I probably won't repeat the experiment for the forseeable future, but I'm glad that I did it at least once.
If you have something appropriate for a Debian-based audience don't forget you're welcome to advertise upon the Debian Administration website for free - See the Advert FAQ for details.
ObQuote: The Craft
Tags: advertising, jquery, lwn, mutt, muttrc
7 May 2008 21:50
Well a brief post about what I've been up to over the past few days.
An alioth project was created for the maintainance of the bash-completion package. I spent about 40 minutes yesterday committing fixes to some of the low-lying fruit.
I suspect I'll do a little more of that, and then back off. I only started looking at the package because there was a request-for-help bug filed against it. It works well enough for me with some small local additions
The big decision for the bash-completion project is how to go forwards from the current situation where the project is basically a large monolithic script. Ideally the openssh-client package should contain the completion for ssh, scp, etc..
Making that transition will be hard. But interesting.
In other news I submitted a couple of "make-work" patches to the QPSMTPD SMTP proxy - just tidying up a minor cosmetic issues. I'm starting to get to the point where I understand the internals pretty well now, which is a good thing!
I love working on QPSMTPD. It rocks. It is basically the core of my antispam service and a real delight to code for. I cannot overemphasise that enough - some projects are just so obviously coded properly. Hard to replicate, easy to recognise...
I've been working on my own pre-connection system which is a little more specialied; making use of the Class::Pluggable library - packaged for Debian by Sarah.
(The world -> Pre-Connection/Load-Balancing Proxy -> QPSMTPD -> Exim4. No fragility there then ;)
I still need to sit down and work through the Apache2 bugs I identified as being simple to fix. I've got it building from SVN now though; so progress is being made!
Finally this weekend I need to sit down and find the time to answer Steve's "Team Questionnaire". Leave it any longer and it'll never get answered. Sigh.
ObQuote: Shooting Fish
18 July 2008 21:50
ObQuote: Short Circuit.
28 April 2009 21:50
I'd forgotten how sexy, useful, and great mod_perl is.
I've recently been struggling with a friend's CGI-based site, and after a minor effort we made it run with Apache::PerlRun:
Apache::PerlRun gives you the benefit of preloaded Perl and its modules. This module's handler emulates the CGI environment, allowing programmers to write scripts that run under CGI or mod_perl without any change
Because the site code wasn't very clean we had to make a lot of changes to get it working under Apache::Registry.
Apache::Registry is the Apache module allowing you to run CGI scripts very fast under mod_perl, by compiling all scripts once and then caching them in memory.
But the payoff is very noticeable - the site is now blazingly fast!
At some point I should write a guide to doing basic things with mod_perl. Mostly I guess the challenge is that you can write toy applications in moments, but to demonstrate how useful it is you need to apply it to something the reader is familiar with. Or demonstrate why the effort is worthwhile, given that it ties you to the Apache + mod_perl platform.
Any links to existing guides, or suggestions on how to approach the guide-writing in a beginner-friendly but still useful fashion are welcome.
(For what its worth I mostly write web applications using CGI::Application & jQuery these days.)
ObFilm: Pretty In Pink
Tags: cgi::application, jquery, mod_perl
20 May 2009 21:50
Etch -> Lenny
This Saturday I'll be upgrading my main box to lenny.
Mostly this should be painless, as the primary services aren't going to change too much.
I've tested the upgrade of the virtual hosting configuration which I use for exim4 on lenny and that works, as-is. I also have a local version of qpsmtpd which I'll be deploying and that works on lenny with my custom plugins.
A new version of Apache 2.x shouldn't cause any problem, although I will need to test each site I have to make sure that Perl module upgrades don't cause any breakage.
I expect random readers will neither notice nor care if my sites go down for an hour or two, but for local people consider this notice ;)
This allows dl/dt/dd/definition lists to have their contents collapsed easily.
Currently I use some custom code to do that (e.g. as used here) but this jquery plugin is far neater, even if the plugin code isn't perhaps the best.
This plugin converts plain links to things that make AJAX requests. In theory this allows graceful enhancements.
e.g. <a href="foo.html#bar">link</a> becomes an AJAX request that loads the contents of "foo.html" into the div with ID bar.
It seems this is a cheap clone of ajaxify, but I didn't know that when I put it together.
ObFilm: The Breakfast Club
Tags: etch, jquery, lenny
22 January 2010 21:50
I also managed to put together a tremendous hack to solve a pretty annoying problem running multiple distributions from a single external kernel under KVM.
Ubuntu users, in particular, will be well aware of dmesg SPAM coming from the use of CONFIG_SYSFS_DEPRECATED.
In short the way that the kernel presents information beneath the /sys tree has changed over the life of the kernel - and this has a knock-on effect to the userspace supplied by different distributions and releases of GNU/Linux.
Some distributions need an "old" kernel and an "old" udev with "old" udev rules in order to create the appropriate device nodes such that the kernel will boot & mount its filesystems. (i.e. These need CONFIG_SYSFS_DEPRECATED to be set.)
Conversely some distributions mandate a "new" minimum kernel version, and supply a "new" version of udev with "new" udev rules and they absolutely will not function when presented with an "old" kernel. (i.e. They must have kernels without CONFIG_SYSFS_DEPRECATED set.)
I've solved this problem via a kernel patch which is both evil and genius. The details are a little me-specific, but in short:
- devtmpfs is used to setup and mount an initial /dev tree before /sbin/init is launched..
- udev launches later and mounts a tmpfs over /dev such that it can start creating its own nodes.
- At this point evil begins: I've patched the kernel such that any attempt to mount a tmpfs filesystem at /dev is silently changed to mount a devtmpfss filesystem instead.
- The alternative is that udev creates many nodes, but manages to fail to create the root & swap nodes such that the KVM guests fail to boot.
Ultimately udev doesn't get an empty /dev tree to play with, instead it finds one already pre-populated, such that any devices it cannot create are there regardless - because the devtmpfs implementation has already created them.
Genius. And evil. So very evil.
Steal that idea. I dare you .. (I'm impressed at how well devtmpfs works, and how easy I was able to make my "patch of evil"tm. Just a few lines in fs/namespace.c.)
ObSubject: The Last House On The Left
Tags: evil, jquery, kernels, kvm, linux kernel, stealing, udev
18 April 2010 21:50
This past week has had a couple of minor software releases:
I made a new release which improves support for foreign language; so dates can be internationalised, etc.
The online demos now include one in with French month names.
The perl-based sysadmin tool had a minor update earlier today, after it was pointed out that I didn't correctly cope with file content checks.
I'm still pretty pleased with the way this works out, even if it is intentionally simple.
This is a simple bug-record-thingy which I was playing with recently, and I've now started using to record bugs in other projects.
I'll pretend its a fancy distributed-bug-tracker, but actually it isn't. It's nothing more than a bunch of text-files associated with a project, which have sufficiently random names that collisions are unlikely and which thus becomes semi-distributed-friendly.
I need to either come up with my own which looks like galleriffic, or port the thumbnail bits over.
(I'm currently using a slightly modified version of gallerifific for my people-shots.)
30 August 2010 21:50
this blog to be
This post is a test.
I'll need to check but I believe I'm almost 100% jQuery-powered now.
It is a well-known fact that AJAX requests are only allowed
To pull content from other sites users are often encouraged
to write a simple proxy:
- http://example.com/proxy/http://example.com allows arbitrary fetching.
Simples? No. Too many people write simple proxies which use
PHP's curl function, or something similar, with little restriction on either the protocol or the destination of the requested resource.
Consider the following requests:
ObQuote: "You're asking me out? That's so cute! What's your name again? " - 10 things I hate about you.
19 June 2012 21:50
So status displays are cool. Seeing what is happening in real time is cool.
As a proof of concept I put together a trivial load-graph:
This is broken down into three parts:
- Load Client
The load client is a trivial script which reads
/proc/loadavg, and sends the 1-minute entry to a remote server,
via a single UDP packet.
- Load Server
The load-server is a service which listens for UDP traffic, and when it receives a new integer records that in a redis data-store.
- Load Display
This is a HTML page which has the values from the store in it, which is then plotted using javscript.
So the UDP-server which receives load will receive two things:
- load:N - The load figure. The text "load:" is literal, and present in case I decide to extend the stats..
- x.x.x.x - The IP address from which it received the message.
This is inserted into a Redis database as an array. This array could then be fetched via an AJAX script to update the HTML display in real-time, but at the moment I just have a shell script which updates it in near-real time.
The idea of having a UDP-server receive values from remote clients is interesting. We just need to define a mapping to redis. For me I've just done this:
receive a UDP packet with value "load:1.2" from source 18.104.22.168
append "1.2" to key "22.214.171.124-load".
append the value "126.96.36.199" to the global "known_hosts"
The values received can be truncated (i.e. keep only the most recent 60 entries) with ease, due to the available Redis primitives, and we can easily graph these using the qjplot library.
Adding more metrics just means updating the clients to send "memfree:400m", "disk-free:50%", "users:2", "uptime:12345s", or similar. The storage is wonderfully abstract - all you need to do is get the graph-drawing code to a) Know which source to display, and b) which metric.
For example, if we did extend the client to send that data I could draw a graph of the memory on host foo.example.com just by selecting "memfree" against the origin "188.8.131.52".
ObQuote: "Come here, damn you, I want to touch you. " - Hellraiser
Tags: jquery, node.js, status