Jacqueline now features a development branch containing the latest changes to check multiple documents in a parallel fashion.
My first performance tests show that this boosts overall performance when checking large amounts of CSS selectors on multiple HTML documents. The next big step will be trunk-integration of this feature.
In the meantime check the dev-branch at http://code.google.com/p/jacqueline/source/browse/#svn/branches/threaded
Back in 2008 I wrote some articles about the proposed Selectors API for the DOM. Now, in 2009, it’s still “only” a working draft of the W3C. I’ve been exploring this topic for a long time, now I will finally have time to write about what I’ve been working on for several months.
Jacqueline is a library which will help you to find unused CSS Selectors in multiple HTML documents. This is a very important feature when you want to check a complete website: it will be almost certain that you have some CSS selectors used on page “A” but not on page “B” whereas “B” uses some CSS selectors which “A” doesn’t use.
Jacqueline is completely written in Java – this was necessary because we wanted to run it in our Java based infrastructure. This brings some other problems Jacqueline has to face: the DOM implementation in Java doesn’t feature the Selectors API. So I wrote a CSS-to-XPath engine – inspired by DOMAssistant. What this basically does is: it transforms CSS2.1 selectors into XPath queries which can then be used for node tests (since XPath support is included in the JDK) on the DOM tree of the HTML document.
Because our documents are still using HTML 4.0 (due to several problems when switching to XHTML 1.0) I had to use JTidy for building DOMs.
Jacqueline also uses Apache Batik to retrieve all the CSS rules and CSS selectors from a document – it was the only implementation of the SAC (Simple API for CSS) I got to run – and which had some special features. These include locator information of the found tokens for example.
At the moment Jacqueline only works single-threaded, but because this includes many cpu-intensive operations which could definitely be fastened by using the power of multiple cores I’m also dreaming of a multi-threaded version. Since most operations of Jacqueline could be executed in a parallel fashion this could bring a major speed-up.
The main thing of Jacqueline is that it’s one of the first pieces to the lately mentioned Project Mess Tool. We’ll be using the power of Jacqueline to detect unused CSS selectors in our web projects.
Finally, that stupid name: Jacqueline is named after Jacqueline Bouvier from my favorite TV show the Simpsons. See this poster in our office:
Jacqueline - Poster
This weekend I’ve been very busy on Instruments again.
Instruments now sports a core Java library which takes care of caching the states of system usage for the last time. This is included in an all new “InstrumentsService” which will provide the necessary methods to controllers.
At the moment this is all trimmed for using flot. There are no other “export options” for now.
I decided to make this publicly available in my Subversion repository. You can checkout the source tree of the Grails application here:
http://creatified.com/svn/creatified/Instruments/
The trunk includes the latest development version. Don’t forget the “grails upgrade”-command after checking out the source tree.
When you run the app, all you’ll find there for the moment is the following site which will be located unter http://localhost:8080/instruments/
You will then be able to see something like this:
for the CPU usage and this:
for the Memory usage
This will be all for now, be sure to check out your own version – I’ll also be testing this on the Google AppEngine soon.
After some days off last week I’m on it again… GInstruments definitely on the way I’d like it to be.
First things first: Fortunately Hyperic had placed an exception-statement into its GPL-licensed SIGAR – which allows to include the SIGAR binaries in – for example – Apache-licensed works. For me that’s really good news, because this means GInstruments could also be used in productive environments which I think often would not be GPL-compliant.
Second: One of the basic things I always wanted to have seems really close now. At the moment GInstruments only displays your current system usage – not too useful, because most times you’d be interested in the usage over time, say for the past 30 seconds or so. So that’s one of the core features I’ll be implementing before releasing anything to the public – sorry for the delay, I’m very busy in other projects right now, too.
For the next few weeks I’ll also be testing on various kinds of systems (Windows, Linux, …) and of course testing on Google AppEngine whether they support all the necessary features.
And for a great user experience I’ll also be working very hard on a prototype of the UI.
Some things that will probably make it into the first public release include:
As a developer I’m very often on the hunt for every last bit of performance – trying to optimize every single function of my program.
In the past weeks I’ve been thinking of, designing and developing on a new plugin for the growing framework Grails. It will be called GInstruments and it aims to provide some useful clues for Grails developers who want to know how their application is performing.
The plugin uses Hyperic’s (now SpringSource) SIGAR (System Information Gatherer And Reporter) to report vital system information such as CPU usage or memory comsumption overall or for the current process.
The first release (0.1) is only going to be a snapshot of my first ideas, hence I’ll not release it to the official Grails plugin repositories. It will show you some information about your system like name, version, vendor or architecture, the current CPU and memory consumption. Especially for your current process (which will be the relevant information to know). Take a look at this:
First draft of GInstruments 0.1
All these features are subject to change (I first wanted to know whether there could be a future for this). Possible features for the future may include
I’m open to all kinds feature requests but please bear in mind that I’m only doing this in my spare time, after work, school whatsoever ;-)
At last let me point you to a link (for the non-Apple-developers) to how Apple’s Instruments-app looks like. I think it has some other cool possibilities.
At the moment I’m also waiting for some response from the guys from Hyperic. I really want to license the plugin under the terms of the Apache License (the license Grails uses and many other plugins) – SIGAR is GPL-only at the moment.
Do you think this could be a useful plugin for the Grails infrastructure? What’s your opinion.