Entries tagged jquery

Recently I took stock of my Javascript programming efforts, with the intention of simplifying things. To date I've put together three sites which make use of Javascript:

debian-administration.org

There isn't very much javascript in use upon this site, and you might be forgiven for thinking there was none at all if you don't have an account, or don't login.

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 ..

ctrl-alt-date

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 time round I decided that I'd utterly refuse to write my own Javascript. So instead I used script.aculo.us (damn I hate those ugly URLS).

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?

mail-scanning.com

This site has a fair amount of javascript upon it, but that isn't obvious unless you're actually a user. The only piece that I can recall is the real-time count of spam caught upon the front-page. (Realtime stats are cool!)

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.
$("#foo").hide()

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.

Once the package makes it through the NEW queue I will update it to follow the skeletal javascript-policy.

I disagree about the naming scheme suggested by that policy primarily because we already have packages of several of the "big" javascript libraries, such as scriptalicious, and see no gain in renaming them. But otherwise the policy is sane enough; following it will cause no harm at the very least.

ObQuote: Stand By Me

Tags: javascript, jquery, prototype, scriptalicious | No comments

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

Update: jquery was accepted yesterday. Today I uploaded a new version to more closely align it with the javascript-policy.

Tags: advertising, jquery, lwn, mutt, muttrc | No comments

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 ;)

Finally I made a tweak to the Debian Planet configuration. If you have Javascript disabled you'll no longer see the "Show Author"/"Hide Author" links. This is great for people who use Lynx, Links, or other minimal browsers.

TODO:

I'm still waiting for the creation of the javascript project to be setup so that I can work on importing my jQuery package.

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

Tags: bash-completion, bash-completion, debian, javascript, jquery, mail-scanning, qpsmtpd, todo | 2 comments

Over the past few nights I've managed to successfully migrate the Debian Administration website to the jQuery javascript library

This means that my own javascript library code has been removed, replaced, and improved!

The site itself doesn't use very much javascript - there are a couple of places where focus is set to a couple of elements, but other than that we're only talking about:

• Adding tags to articles, blog entrys, & polls
• Looking at the tag cloud
• Using the messaging system

Still there are a couple of enhancements that I've got planned which will make the site neater and more featureful for those users who've chosen to enable javascript in their browsers.

Here's my list of previous javascript usage - out of date now that I've basically chosen to use jQuery for everything.

ObQuote: Short Circuit.

Tags: debian-administration, javascript, jquery | No comments

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 | 4 comments

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 ;)

In other news I put together some javascript plugins for jquery recently:

dltoggle

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.

autoajax

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 | 2 comments

Good people steal ideas, right? On that basis I setup a static domain to host the javascript and icons I use upon a few different sites & projects. This was preempted by the release of a new version of the excellent jQuery library.

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.

Meh.

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 | 2 comments

This past week has had a couple of minor software releases:

chronicle

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.

slaughter

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.

milli

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.

Today I'll be learning to love Javascript a little more. I want to use the gallerific image gallery - but it doesn't make thumbnails automatically - which galleria does.

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.)

ObFilm: Hancock

Tags: chronicle, galleria, gallerific, javascript, jquery, slaughter | 6 comments

Blog Update

I've just updated the home-grown javascript I was using upon this blog to be jQuery powered.

This post is a test.

I'll need to check but I believe I'm almost 100% jQuery-powered now.

AJAX Proxies

It is a well-known fact that AJAX requests are only allowed to be made to the server the javascript was loaded from. The so-called same-origin security restriction.

To pull content from other sites users are often encouraged to write a simple proxy:

• http://example.com/ serves Javascript & HTML.
• 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:

• http://example.com/proxy.php?url=/etc/passwd
• http://example.com/proxy.php?url=file:///etc/passwd

If you're using some form of Javascript/AJAX proxy make sure you test for this. (ObRandom: Searching google for inurl:"proxy.php?url=http:" shows this is a real problem. l33t.)

ObQuote: "You're asking me out? That's so cute! What's your name again? " - 10 things I hate about you.

Tags: ajax, javascript, jquery, meta, security | No comments

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:

• http://static.steve.org.uk/load/

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 1.2.3.4
append "1.2" to key "1.2.3.4-load".
append the value "1.2.3.4" 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 "1.2.3.4".

ObQuote: "Come here, damn you, I want to touch you. " - Hellraiser

Tags: jquery, node.js, status | 4 comments