Entries tagged javascript

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

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

A couple of days ago I was lamenting the state of webstats, although I was a little vague as to my purpose. Specifically I was wanting to find out about the screen resolutions and user-agents viewing a couple of sites.

To get screen resolutions you really need to inject javascript into your pages, which is icky. Still its a small price to pay, and chances are most people won't notice.

Of course there are drawbacks:

Javascript dependency.

If the visitors don't use/enable javascript you see nothing.

You cannot capture everything.

e.g. HTTP status code isn't available.

To solve this problem completely you therefore need to have access to both your apache logs and your javascript-captured information. Probably.

As a proof of concept I've injected the following javascript into most pages of three sites. This code:

• Finds the screen resolution.
• Finds the HTTP referer.
• Finds the current page's title.
• Then submits that to a server-side collection script, via a one-by-one pixel IMG

The script that receives the data writes out the data to a small per-domain SQLite database, which I can then use to generate prettyness. However I suck at being pretty, in most ways, so I've only got functional:

• Debian-Administration.org Statistics

All of this is dynamic and most of the data is anchored to "today", as thats proof of concept enough. Were piwik not written in vile PHP I'd use that - I don't see anything similar out there which is Perl..

The big decision is now "Keep it dynamic" vs. "Output static pages". (vs. call off the experiment now I know that I'm safe to assume "big resolutions").

(Naming software is hard. Recent stuff I've done has had an skx prefix primarily for google-juice. e.g. Randomly I notice that if you search for my personal site on Google's UK engine I come top. Cool.)

ObSubject: The Bourne Identity

Tags: javascript, random, skxstats, webstats | 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

Last night I was up again, really hard to sleep when you have a bad cold.

I decided to do something fun, and allow my tweaking guide to accept comments.

Like many of my sites this is 100% static, and generated by templer, so comments are "hard".

I've seen a few people try to rewrite disqus as a general-purpose solution, and I like that idea, because I don't trust that particular service.

I wasn't so ambitious though, I just hacked up a quick sinatra server:

• "GET /comments/ID"
  • Retrieves the comments on the specified identifier as a JSON array of comment-hashes.
• "POST /comments/ID"
  • Append the submitted comment to a redis set.

My jquery/javascript is nasty, but the thing seems to work pretty well. The page loads and comments are populated, and new ones are persisted as expected.

I can see the appeal of putting all this magic in one javascript file. You include that and get both the existing comments and the form to add new ones - my approach is to hardwire the submission/display in my generated site.

Perhaps something for the future.

In conclusion if people wish they can now leave feedback on most of the pages :)

Tags: disqus, javascript | 9 comments

The simple external-comments code is now complete enough for me to stop poking it on a daily basis:

• Although the comments are styled minimally you can override that with CSS.
• Although the default "Add your reply" form is ugly you can replace it with your own.
  • The reply-form may go above or below the comments.
• If you add an email field then your comments will include a gravitar link.
• Comments are assumed to be in markdown now.
• The commments may be retrieved in newest-first, or oldest-first order.
• There's now a simple anti-spam plugin system present.

All in all I'm pretty happy with the way it works, and the server-code. The client-side Javascript is less good, but I'm probably done poking that too.

In an ideal world the client-side code should be a jQuery plugin, but I've not worked out how to make a static method (the JSONP callback) be a member of a jQuery plugin-object. So without that I have to re-pass the options around too many places, rather than making them a member of "this".

Meh, pull requests welcome for adding new storage back-ends (redis and sqlite are supported by default), and similarly for cleanups.

Links:

• https://github.com/skx/e-comments
• Simple demo & Customized demo.

Tags: disqus, e-comments, javascript | No comments