In my ongoing quest for a sensible programming environment, I’ve filed an OpenEmbedded bug with patches providing support for version 1.7.0 of Spidermonkey, Mozilla’s javascript engine. It hasn’t gotten me much further toward my goal, but it’s nice having a quality javascript interpreter available for my OpenMoko phone, should I ever need one…
Add comment December 31st, 2007 tonyg
NDocProc, our small and simple .NET javadoc-like documentation generator, has been updated for C# 2.0 and Generics.
Changes since the previous announcement include:
The project homepage is here. You can download a zip of the latest version, or use darcs to check out the repository:
darcs get http://www.lshift.net/~tonyg/ndocproc/
5 comments November 7th, 2007 tonyg
Recently I had to configure a FastCGI application to work in a mixed SSL and plain HTTP environment. A few hours into the adventure I remembered LigHTTPd (pronounced lighty, usually), a new free software web server that is gaining popularity, especially within the dynamic community, and thought I might as well give it a try.
Continue Reading 6 comments December 12th, 2006 Tom Berger
It’s hard to believe only a week has passed since we’ve integrated the project blog into Trac - with the Timeline view now displaying both source code changes and blog entries, it now became really convenient to just keep Trac open and refresh it every time we want to get an update on the state of the project.
I still found myself switching between Trac and Bugzilla all the time, and that can be very frustrating - so frustrating it can ruin even days like this, when the weather is so fine. Something had to be done - it was time to integrate our project’s bug-list from Bugzilla into Trac.
Continue Reading 4 comments November 27th, 2006 Tom Berger
Trac is the best thing that happened to humanity since the cultivation of chik peas. Finally software project management has a centralized hub almost anyone can use to make the process more effective. It is beautifully designed and implemented. Extending it is easy and there’s a strong community of developers and users. I decided to see how difficult it would be to extend Trac to grab feeds from our project blog and display them in the timeline view.
Continue Reading 9 comments November 20th, 2006 Tom Berger
For a new web project we’re working on, we wanted to use a dynamic environment. We’ve resolved to use Python, a language we feel very comfortable with, and I went to test several pythonic web components, in particular the stuff that gets bundled with TurboGears and web.py.
Continue Reading 18 comments November 15th, 2006 Tom Berger
Sometime around the beginning of July I rewrote our internal jukebox
in Erlang. It’s taken me four months to get a round tuit, but new
stock has just arrived: here’s the code for our AJAX jukebox
web-application, as a tarball. (There’s
also a darcs repository:
darcs get http://www.lshift.net/~tonyg/erlang-jukebox/.)
Click on the image for a screenshot.
To run it, you will need Erlang, Yaws (the Erlang webserver), a modern browser, mpg123, ogg123 (from vorbis-tools), and some MP3 or OGG files to listen to.
I’ve made a start on a bit of documentation and design rationale. Here are a few highlights for the curious:
You point the jukebox at one or more root URLs, which it then spiders, collecting URLs for MP3 and OGG files, which it puts into a simple flat-file database. Just expose, say, your iTunes folder via Apache, point the Jukebox at it, and you’re away.
It relies on mpg123 and ogg123’s support for playing HTTP-streamed MP3 and OGG files, respectively, rather than retrieving or playing the media itself.
The user interface is completely written in HTML+Javascript, using prototype for its event binding and XMLHttpRequest support.
The server side of the application communicates with the user interface solely via JSON-RPC.
Erlang made a great platform for the server side of the application. Its support for clean, simple concurrency let me design the program in a very natural way.
As part of the development of the program, I built a few stand-alone modules that others might be interested in reusing:
the execdaemon and its associated Erlang controller module is a filthy hack I threw together to get better than the built-in support for POSIX process control and signalling from Erlang.
jsonrpc.js is a tiny, simple layer atop json.js and prototype that supports basic parsing of Simple Method Description (SMD) files, generating Javascript client proxy objects for each JSON-RPC service described by an SMD.
[Update: fixed an issue with json.js, tweaked the use of screen real-estate, and now seems to work with Safari, IE6, and Opera. I’ve changed the tarball link above to point to the new version.]
[Update: fixed a couple of links that had broken over time as the darcs repository evolved.]
17 comments November 6th, 2006 tonyg
In these days of semantic markup, liquid three column layouts and image replacement it’s quite evident that using CSS is just not as simple as it promises to be. There’s not only the flow and box models to internalise, but the numerous quirks in how browsers implement them, and the constraints imposed by accessibility guidelines, and—well, special cases galore. As usual the solution is care, attention, and better tools.
Grouping rules
To start, there is the matter of how to arrange CSS code: One reason why CSS can be trouble to maintain is that there’s no obvious best factoring of rules. Do you clump like properties together under a single selector
h1, h2, h3, div.title {color: #f3c;}
on the basis that there’s then one place to change that property of these related elements; or, group like selectors
h1 { color: #f3c; font-size: largest; font-weight: bold; }
so that the entire style of a particular set of related elements can be changed at once?
There is at least one program that will automagically group rules for you, but it does it dumbly, collecting rules by common properties, and as it’s been pointed out, that’s not always what you want.
The real answer is that it depends on for what each property is intended. If a property is part of the overall theme, it should be in one place. Colours often fall into this category, as do fonts. If the property is a consequence of some extra semantics you’re asserting with your selector, it belongs with all the other such properties under one rule. For example, if I create a distinction between hyperlinks to elsewhere in my site and hyperlinks leading away from my site by using the class external, I would put all the properties related to external links in one rule.
These rules may have related selectors:
// Thematic property --- this colour is part of my colour scheme
h1, h2, h3, div.title {color: #0f0;}
// Semantic properties -- I'm asserting a set of things that are titles
*.title {
margin-left: 32px;
background-image: url('images/title-marker.gif');
background-repeat: no-repeat;
}
(Note to CSS standards authors: some extra sugar for selectors would be helpful, like distributing combinators over parentheses; for example thead (th, td) as shorthand for thead th, thead td)
Cascade Simply, Stupid
The typical practice is to put hooks in the HTML upon which to hang styles. An id attribute can be used for unique (per page) elements, and the class attribute can be used to create arbitrary sets of elements. This coupling between the HTML and the CSS introduces a maintenance burden, since when the HTML changes the CSS must change, and vice versa.
There’s many ways to select a particular element, and there’s many ways of getting a style to apply to an element. A question Mark Bernstein poses is how do you make sure your style applies to precisely the right set of elements, now and forever?
We want to minimise three things: the knock-on effect of changing the CSS or the HTML, the possibility of unintended matches, and dependencies between rules. We can go a long way with both by keeping selectors simple and predictable.
Use either very general selectors with thematic properties (”set all body text to green”), or very specific selectors (”the element with this ID has a blue background”). This makes it easier to predict which elements will be affected by a rule, and reduces the chance that undesired properties will be inherited.
If you use relative units on elements that can be nested, you can end up with effects like shrinking text. This applies not only to single rules, but to combinations of rules:
span.info { font-size: 0.8em; }
// OK, since it won't be nested
fieldset#login { font-size: 0.9em; }
// but what if we put a span.info in that fieldset?
To avoid this situation, keep relative units away from generic containers. Let paragraphs default to whatever the body text size is, and adjust only for non-nesting elements.
Use selector connectors (descendant, child, sibling) very sparingly: they appear specific without being very predictable. Qualify sub-selectors with a class, or better an ID, to help avoid matching undesired elements.
Refactoring
Refactoring is the process of removing duplication and other bad smells from code. We can do the same for CSS.
What are the bad smells?
Sets of repeated properties in several rules often signal that there’s a common class to be extracted. You have to be careful though: it may be coincidence. A rule of thumb is that if you can consider the set of selected elements semantically alike, then you can replace the rules with a class. The semantic similarity means there’s a reasonable chance that the class, and the elements to which it it is attributed, aren’t going to change.
Class names or IDs that mention styles, for example .redBox, suggest that thematic properties are being mixed with semantic properties (or possibly that you were running short on imagination that day). Move the thematic properties into their own rule and think of a new name that reflects why you’re saying the elements with this class are different to other elements; e.g., .warning.
Long chains of combined selectors, for example body#about-page div.sidebar p a {...} may mean you’re trying too hard to narrow a selection — use a class or ID further down the chain to simplify the rule and make the selection clearer: p.about-page-links a {...}.
The hypothetical refactoring browser
What’s really needed is a refactoring browser. Not only would this browser let you view and edit CSS and HTML (and HTML-like code) side-by-side, it would understand how CSS applies to HTML, so you could
It would also offer refactoring transformations:
By definition, refactoring transformations should not alter the observable output of the code; however, you will also want to know when something you’ve done has failed to preserve that, so the refactoring browser should tell you.
Xylescope comes very close—it does a excellent job of showing you both which rules apply to an element and to which elements a rule applies, and has some handy visualisations of CSS properties (especially the box model). Sadly it doesn’t have a stellar editing facility, or any refactoring, but we can hope that culturedcode are planning to extend it.
Care and attention
While tools go an awfully long way, the most important thing is to give CSS your care and attention. Don’t let it get out of hand, by constantly refactoring; update the CSS when you update the HTML to remove unneeded rules; and confirm that each new rule does what you think it does. This last activity is the essence of testing, which I’ll talk about next time.
Add comment September 13th, 2006 mikeb
Haskell’s QuickCheck is a very neat tool for automated testing. One specifies properties that one would like a program to satisfy, and generators for test data, usually involving some form of randomisation. QuickCheck then uses the generators to produce test cases and check the properties against them.
The original QuickCheck was designed to test purely functional code only. However, the project I am working on contains a fair amount of imperative code, most of it performing operations on a database. Is it possible to employ QuickCheck for testing this code?
Continue Reading Add comment July 20th, 2006 matthias
We wanted to add a ’search this site’ function to a client’s website but did not have the time to study the 200+ existing ways of doing this. Perhaps using the “Microsoft Indexing Service” (or “Index Server”, IS), which fits well with the software running the existing site (IIS), can easily be extended to search within MS Office and PDF documents?
But there is a problem with using IS for this: IS can only index files
on a local or remote file system, it does not crawl a website.
In our case that is not good enough because the content lives in a
database, and we have to follow links like http://mysite.com?page=42.
Moreover, we wanted to make sure exactly the content exported through
HTTP is indexed, no more no less.
The solution we came up with works like this:
This cleanly separates the webcrawl and the indexing, and the search is entirely ignorant about the (possibly heterogeneous and complicated) software architecture of the site.
So far it is just a prototype, but it seems to work fine.
2 comments July 17th, 2006 sebastian
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Jul | ||||||
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |