Do you apologize in code comments?
Sunday, December 30th, 2007Apologetics in comments are usually a sign of the presence of design smell.
− from webmonkey
Apologetics in comments are usually a sign of the presence of design smell.
− from webmonkey
Dion Almaer (of Ajaxian fame, of course) is writing a cool series about Google Gears. Apparently the nice people at Google have further-reaching ambitions than “just” an offline browsing api.
Reading through the Gears wiki you’ll sense that there’s no distinct direction for the developments of the tool, but there’s plenty of stuff to look forward to: The Location API, the Image Manipulation API (although it seems to be quite limited since you can’t manipulate images on the bit level and thus program your own manipulations), and the Messaging API.
Update: This new post in the series underlines the potential problem in the Image Manipulation API. You can only do the stuff with images that Google allows you to. No access to the actually content of the Blobs − only the meta data.
I wrote about YUI Charts the other day and I guess my conclusion was that the library is promising, but still a long way from being perfect. Today, I have been using it in a real-life setting a found that I wanted to do some stuff that’s isn’t supported out of the box in order to build something that looks like this:
By default the library accepts one datasource containing a category, which is turn can have multiple values. This would be an array, which looks like this in Yahoo’s own documentation:
var data =
[{ month: "January", rent: 880.00, utilities: 894.68 },
{ month: "February", rent: 880.00, utilities: 901.35 }];
This looks great paper, but when preparing data from the database it’s requires some clever trickery to set up such a datasource. Instead, I wanted to prepare several arrays containing label/value pairs and merge them into a data source. For example:
var rentValues =
[{label: "January", value:880.00},
{label: "February", value: 880.00}];
var utillitiesValues =
[{label: "January", value:894.68},
{label: "February", value: 901.35}];
The example includes a simple piece of code, which merges these two (or more) datasets into something which is edible for the YUI datasource. Make sure that the label properties are the same in all datasets though. Otherwise, you’ll see strange results..
Even though you’ll actually be sending all the required information to the chart library, it won’t build a chart legend for you. Which is bad. Instead, the documentation shows how to set up something similar in HTML. In this case, I wanted to allow selection and de-selection of items on the chart and have the visualization scaled accordingly.
In the example I’m using the same data to build both a data chart and a HTML form, which displays the name and color of each line on the chart — and which handles a redrawing after selecting and deselecting individual items on the form.
Yahoo’s own examples are pretty cool, but drawing a chart isn’t exactly a one-line job. I wanted to make it — so I’ll be able to do something like this:
var rent = {displayName:'Rent', data:rentValues};
var utilities = {displayName:'Utillities',
data:utillitiesValues};
prepareChart('container',
[rent, utillities], 'formatFunction');
…where container is the name of the html elements holding the chart and the legend, and where formatFunction is a reference to the JavaScript function responsible for formating data on the Y-axis.
The data objects can be expanded slightly to include both information about the color of the line and when the dataset should be shown by default:
var rent = {displayName:'Rent', data:rentValues,
hidden:true, color:'#cc0022'};
The example generates some random data about a fictive web site and displays “New signups”, “Total number of users”, “Active users” and “Returning users” for the past two months (if somebody has ideas for real data to plot, please let me know). This it simply does:
var signupsPerDay = {displayName:'New signups',
data:randomSignupUsers};
var numusersPerDay = {displayName:'Total number of users',
data:randomTotalUsers, hidden:true};
var activeusersPerDay = {displayName:'Active users',
data:randomActiveUsers};
var returningusersPerDay = {displayName:'Returning users',
data:randomReturningUsers};
prepareChart('users',
[signupsPerDay, numusersPerDay,
activeusersPerDay, returningusersPerDay],
'usersCountFormat');
I’m actually not planning on writing much about charts and graphs — but since we’re prototyping the back-end of Nosco’s prediction market application I’ve been reading a lot about the subject. For big and interactive charts we’ll be using either YUI Charts or some native Flex stuff depending on the level of ambitiousness, but John Resig’s JavaScript Sparklines demonstrates how to do something a little simpler in a much, much simpler fashion.
Basically, you insert an html element containing the data for the sparkline — and then the library does the rest for you by creating a <canvas> element and drawing the sparkline:
<span class="sparkline">10,8,20,5...</span>
Very, very cool… Although the library doesn’t seem to support baselines and highlighting of the min and max values, which takes some of the coolness out of the idea of sparklines.
Remember to use excanvas as well to emulate canvas support in Internet Explorer.
This:
The idea that a language should be designed from the ground up for the purpose of providing you with an experience of harmony, calm, and enjoyment is fundamentally alien to American programming culture, and when American programmers discuss why they prefer Ruby, the fact that it was designed for their enjoyment vanishes from their own vision even when it’s right in front of their eyes. The closest equivalent we have in this country is an idea that the language was designed to be fun – which is similar, but not the same thing.
… made me this of this:
No one (so far) has said “Well, I really like my job because what I do is fun, and I get to work with some really nice people.” So here’s the question: Is that typical? Is that really how most Americans view work – as a means to an end rather than something that could (and should!) be pleasant in itself? What do you think?
It nicely poses a question I cannot answer. And it makes me wonder why don’t I find Ruby particularly pleasurable in spite of my being Danish.
This blog post provides a few simple tricks for coding efficient stylesheets — in the sense of having an organised structure which is easy to navigate and to modify. The color grouping seems like the most useful tip.

It’s sunday and I’ve been looking for something reasonable to do while not actually working. So I though I’d address an issue we’ll be having at 23 within the next month or so. We want to let people choose their language from a drop-down select box, and we want each option in this box to have a flag icon representing the language. Such specific styling isn’t doable through plain HTML, so custom code is needed…
(We’re certainly not the first to address this issue, and a lot of people have begun to include custom select boxes in their web applications. Most notable in this crowd is Google in Google Reader and Gmail.)
I’m still a few hours from a result that’s usable in the real life, but the first prototype demonstrates where I’m going. Already the JavaScript and the accompanying stylesheet is well-commented, but since it seems like a great example of advanced web scripting in action I’ll be back with a detailed walk-through soon.
It’s nice to see Google entering the scene for easy chart building — along with Yahoo’s Chart library and new JavaScript/Canvas-based stuff like Ole Laursen’s Flot. Frankly, I’ve been postponing doing a pretty chart based reporting tool for Nosco’s prediction markets for quite a while now (we do build nice charts for the web app though) but all of this could be becoming easier.
I’m still not jumping deliriously up and down. My first experiments with YUI Charts were mixed, and for everything it lets you do there’s two or three things out of reach. The same thing probably goes for Google’s hosted solution and it’s worth approaching the service with a bit of skepticism.
A while back Dustin Diaz did a nice explainer on pieces needed for your own personal JavaScript and AJAX interface — if you’re not using a prefrabricated one, that is. The basic idea was that you’ll save both time, bandwidth and debugging troubles by getting the foundation right. And the same thing goes for the CSS foundation.
First of all, your basic stylesheet should include a few lines to void browser-specific stylesheets and to reset padding and margin on all elements. This means that all browsers will behave the same when you add your own styling, and that you know that you’ll be responsible for all padding, margins, colors, borders and size in the final layout.
There are plenty of examples of such reset stylesheets that you can steal from. Usually, I go for YUI’s version. Along the same lines, have a look at YUI’s Font CSS, which provides similar normalization for font support across different browsers.
Apart from the resets you’ll want to include a list of the styles that you commonly use. Such as bold, underline or highlightbackground. When you get used to using the same class names over and over, it’ll save you a lot of style=”text-decoration:none;” and so on.
But the main advantage is that you’ll be using one common convention on all pages and on all sites. This saves a lot of cleaning-up when the design is finalized. For example, most sites have boxes with a light background, and you’ll usually want to keep those backgrounds similar. But that background colour can change color as the design develops. Vowing to keep to convenstion from the start means that this is not a problem. And having long-established conventions makes this even easier. I’ll usually go for something like this:
.clear {clear:both;}
.clearleft {clear:left;}
.clearright {clear:right;}
.discrete {color:#7F7F7F; font-size:.95em;}
.discrete a {color:#7F7F7F;}
.small {font-size:.95em;}
.verysmall {font-size:.90em;}
.big {font-size:1.2em;}
.verybig {font-size:1.6em;}
.gray {color:#666;}
.jumptop {margin-top:15px;}
.jumpbottom {margin-bottom:15px;}
.jumpright {padding-right:10px;}
.jumpleft {padding-left:10px;}
.bigjumptop {margin-top:40px;}
.bigjumpbottom {margin-bottom:40px;}
.bordered {border:1px solid #666;}
.borderedtop {margin-top:15px;
padding-top:15px; border-top:1px solid #666;}
.borderedbottom {margin-bottom:15px;
padding-bottom:15px; border-bottom:1px solid #666;}
.center {text-align:center;}
.floatleft {float:left;}
.floatright {float:right;}
.left {text-align:left;}
.right {text-align:right;}
.bold {font-weight:bold;}
.nobold {font-weight:normal;}
.italic {font-style:italic;}
.uppercase {text-transform:uppercase;}
.nouppercase {text-transform:none;}
.underline {text-decoration:underline;}
.nounderline {text-decoration:none;}
.opaque {filter:alpha(opacity=40);
-moz-opacity:.40; opacity:.40;}
.lightbackground {background-color:#F4FBF2;}
.highlightbackground {background-color:#FFFFCC !important;}
(By the way, the jumptop, jumpbottom, bigjumptop and bigjumpbottom have turned out to be particularly useful because it allows for easy and consistent margins. And if you want to modify margins for a particular section, it’s as easy as this: #sidebar .jumptop {margin-top:8px;})
Yahoo’s web programming framework, YUI, is out in a new version, which frankly wouldn’t be too exciting if it wasn’t for the new Charts library. Basically, quite a few people have been experimenting with doing charts and graphs with on html canvases (including myself). This method can work well for specific purposes, but it certainly doesn’t scale well, and nobody has come up with a good general library for all charting needs yet.
And the YUI team hasn’t either. Instead, they’ve taken a much more interesting approach by building a JavaScript library for accessing Flash’s (or Flex’s?) Charting engine. Hopefully (in time) we’ll get all the power of Flex Charting through YUI.
Update: Apparently, this is a joint project between the Flash and JavaScript teams at Yahoo, so the Flashy people have more info on the YUI utility.
Updated update: It also turns out that this isn’t based on Flex Charting, rather it’s built on top of a Yahoo-specific Flash library. This probably makes it less interesting?