Essays
This design started out from imagining that the dotless ı was the primitive i, and the dots on i and j were diacritics. I was traveling in Turkey and Hungary at the time, and the other diacritics flowed naturally.
Feel free to let me know what you think, good or bad. I’m also looking for a name, if anyone has any suggestions.
Old-school hackers had a long tradition of ensuring job security by building applications so unmaintainable that only the original authors could work on them. But in these days of web applications, unmaintainability has fallen by the wayside. Instead, design fads like CRUD, REST, MVC, DRY, and KISS, have eliminated the average programmer’s job security.
Here are ten quick tips for achieving maximum unmaintainability in your web application. Following them will ensure that, in thirty years, a web programmer like you will be as valuable as a fifty-eight year old COBOL programmer contracting at $200/hr for a Fortune 500 company that still hasn’t migrated off of PL/1. You too will be able to live on a dairy farm in Pennsylvania, grow a beard down to your navel, and work in your underwear. And you’ll never have to learn anything new, work with anyone else, or start another new project.
<script> tags. Cram multiple JavaScript statements into onclick and other event attributes — the longer, the better. Do the same with CSS; put some into external files, some in <style> tags, and also put some critical CSS into complex style attributes. And remember to put most of your <script> and <style> tags in the middle of the page content, instead of in the <head>, so that they will be difficult to find.eval. Generate HTML server-side using templates and browser-side using JavaScript. What’s harder than working around a obscure IE layout bug with weird markup tweaks? Making sure both your server templates and your JavaScript HTML generation work around the same bug with the same HTML black magic.authorized=1 just scream out for URL hacking, and storing them in hidden form fields is only slightly harder to hack.name, alt or title attributes, or by their position in the DOM. That way when anything in the page changes, the hierarchy, the attributes, or when the site is translated into another language, things break. If you do end up using class or id, be sure to make a separate class for every node in your document and assign the same id to several different nodes.If, however, you want to write flexible code that can react to and evolve with the ever-changing needs of its users, even after you have left the project in the hands of a clever but inexperienced hacker, you should probably avoid these techniques, and read up on some of those lame new design fads instead.
Special thanks to all the programmers whose code has illuminated these techniques over the years. My job may not be as secure as yours, but at least my code, and my conscience, are clear.
Lately I’ve been playing with rapid prototyping, also known as three-dimensional printing. It’s a (relatively) new fabrication method that allows creation of shapes that would be impossible to create by moulding. It allows for creation of things like interlinked rings, objects trapped inside other objects, or complex voids.
Shapeways, a Netherlands-based website, offers high-quality, relatively cheap rapid prototyping, and a place to host your own selection of models. As a website, Shapeways is no RedBubble — the interface and marketplace tools leave much to be desired. The ratings and sorting can be gamed, it’s trivial to figure out the markup on another user’s model from its price, there’s no way to replace a published model with an improved one, and the site has encoding and markup issues. But what’s a few flaws when you own the category?
The free version of Google SketchUp has been satisfactory for rendering thus far, and its user interface is leaps and bounds ahead of the bizarre interface of Blender. I’m sure Blender has a superior feature set, but what good is power when you can’t figure out how to use it? Meshlab and AccuTrans3d have both come in handy for checking surfaces and converting between formats.
On to the models! Click on the pictures to see more views of each.
Trapped Outside is a model of Boy’s Surface with a sphere trapped in the space cut out by the one-sided surface. Boy’s Surface an immersion of the projective plane, which means it is a Möbius strip with a disk glued to its edge. It is a non-orientable surface with no edges and no pinch points.
Trapped Outside was fairly easy to create using Google SketchUp. It’s just a few circles extruded along each other here and there.
The Hollow Knotted Gear, inspired by Oskar van Deventer‘s Knotted Gear, consists of two interlinked knots; a trefoil knot (in green) and its dual, a 3,2 torus knot. The green trefoil forms a rectangular cross section and a triangular hole. The blue knot forms a triangular cross section and a rectangular hole. The two knots gear perfectly together, and can move around each other, but only if they are both moved simultaneously.
After many failed attempts at getting various applications to render this complex extrusion properly, I wrote a small Python program to calculate the surface for me and output VRML. Then, after much more trial and error, I used AccuTrans3d via Wine to convert the VRML surface to a DAE file for uploading to Shapeways, and to a 3DS file for examining in Google Sketchup (and to take screenshots).
There are a few more of my designs on Shapeways right now, and even more rattling around in my head just waiting to be prototyped.
Here’s a tiny fix to Remy Sharp‘s excellent jQuery Text box hints plug-in. Without this fix, jQuery‘s val function will return the hint text if the text box hasn’t been filled out by the user yet.
Here’s the patch:
@@ -20,7 +23,7 @@
$win = $(window);
function remove() {
- if ($input.val() === title && $input.hasClass(blurClass)) {
+ if ($input.realval() === title && $input.hasClass(blurClass)) {
$input.val('').removeClass(blurClass);
}
}
@@ -41,4 +44,17 @@
});
};
+
+$.fn.realval = $.fn.val;
+
+$.fn.val = function (value) {
+ var i = $(this);
+ if (value === undefined) {
+ return (i.realval() === i.attr('title')) ? '' : i.realval();
+ } else {
+ return i.realval(value);
+ }
+}
+
+
})(jQuery);And here’s the full plugin with the patch applied:
/**
* @author Remy Sharp
* @url http://remysharp.com/2007/01/25/jquery-tutorial-text-box-hints/
*
* better val() method added by Matt Chisholm, 2009/07/27
* http://glyphobet.net/blog/essay/878
*/
(function ($) {
$.fn.hint = function (blurClass) {
if (!blurClass) {
blurClass = 'blur';
}
return this.each(function () {
// get jQuery version of 'this'
var $input = $(this),
// capture the rest of the variable to allow for reuse
title = $input.attr('title'),
$form = $(this.form),
$win = $(window);
function remove() {
if ($input.realval() === title && $input.hasClass(blurClass)) {
$input.val('').removeClass(blurClass);
}
}
// only apply logic if the element has the attribute
if (title) {
// on blur, set value to title attr if text is blank
$input.blur(function () {
if (this.value === '') {
$input.val(title).addClass(blurClass);
}
}).focus(remove).blur(); // now change all inputs to title
// clear the pre-defined text when form is submitted
$form.submit(remove);
$win.unload(remove); // handles Firefox's autocomplete
}
});
};
$.fn.realval = $.fn.val;
$.fn.val = function (value) {
var i = $(this);
if (value === undefined) {
return (i.realval() === i.attr('title')) ? '' : i.realval();
} else {
return i.realval(value);
}
}
})(jQuery);OkCupid is one of the best-designed websites out there. It’s addictive, captivating, easy to use, and pretty. But since it’s free and completely funded by advertising, the ultimate design goal of the site must be to get users to visit more pages, view more ads, and click on some. And this design goal can be taken to extremes that are at odds with the goal of providing quality matching. Consider this screenshot:
This was from the unauthenticated view of my (now-disabled) OkCupid profile. The black text in the bottom half of this screen-shot was my somewhat snide response to OkCupid’s seventh-grade reading level getting-to-know-you question. And at the top is a plug for a different user and an ad for a book that has absolutely nothing to do with me or my tastes1.
The last thing that any OkCupid user should want is for readers to be distracted from their profile like this. And I really didn’t want some site co-opting my identity and interspersing advertisements and links to generate more page views into the middle of it. Even if it was to support a free site. So, OkCupid, you have joined the ranks of other online dating sites that just don’t cut it. Thanks, but no thanks.
Zed Shaw’s recent Python Neglect article raises a few points that are unquestionably valid: easy_install and mx.DateTime suck big time, and it sounds like the email tools have some serious problems. But I would like to hear better explanations from him about:
datetime module (introduced to replace mx.DateTime and fix shortcomings with the time module) is missing? It’s always handled everything I’ve thrown at it.optparse? Usage? Functionality? Implementation?I also just plain don’t understand his complaint about del versus remove. I think mystuff.remove(mything) and del mystuff[4] do exactly the same thing, so what’s the problem? That del exists?
His promise to provide patches will be an interesting test of the Python community’s ability to judge patches on their objective merit, not by their contributor, since Shaw seems to have a tendency to ruffle feathers1.
And a “WSGI for templating,” and efficient state machines with generators? Sounds exciting.
A vote for the President of the United States is actually a vote for an “elector” who pledges, but is not legally obligated, to vote for a specific candidate in the Electoral College. Forty-eight states then allocate all of their electoral votes to the popular vote winner in that state. This means that a candidate receiving the most votes nationwide is not necessarily the one that receives the most electoral votes and becomes President. If the popular-vote loser many states by small margins, and loses some of the others by large margins, they can win the electoral vote, despite losing the national popular vote.
This winner-takes-all system of allocating electoral votes also has the side effect of making a few “battleground” states the primary focus of election campaigns. Candidates descend on these states, funneling money and advertising into them, and tailoring their campaigns to win over voters there. Voters, of either party, in the remaining “spectator” states are effectively disenfranchised, and the small percentage of voters in the battleground states elect the president.
This isn’t even how the electoral college was intended to work. The framers intended that the electoral college would usually fail to choose a clear winner, instead nominating the most popular candidates for election by Congress. This hasn’t happened in over two hundred years.
Programmers have a term for something that’s neither operating as originally intended nor guaranteed to do what their users ask it to do. The Constitution is buggy.
Yet the Constitution is notoriously hard to change. A programmer might use the term legacy.
How would a programmer fix this? Find a way to hack1 a bug fix into the legacy system.
What should the goal of the fix be? We should elect the president in the same way that every governor, mayor, senator, representative, city council member and dog-catcher2 is; by popular vote. If popular vote is good enough for every single other elected office in this country and in many other democratic countries around the world, it should be good enough for the President of the United States of America.
How do we change the Constitution? Turns out we don’t have to. The founders left the allocation of electoral votes up to the states:
Each State shall appoint, in such Manner as the Legislature thereof may direct, a Number of Electors…
-U.S. Constitution
The appointment, and mode of appointment, of electors belong exclusively to the states
-U.S. Supreme Court
And the fix? The National Popular Vote Plan allocates all of a state’s electoral votes to the national popular vote winner. It only goes into effect once enough states pass it to command a majority of electoral votes. The electoral college won’t go away, but it will become obsolete. In programming terms, this plan ensures a buggy legacy system will never (again) get fed the kind of data that triggers the bug.
The National Popular Vote plan has been making its way through state legislatures for the last few years. I’ve brought it up in conversation a few times recently (because of my Visualizing the National Popular Vote plan project), and I’m surprised how many people don’t know about it. There should be a huge grass-roots movement behind this plan to re-enfranchise the electorate, but even smart, well-informed, thinking people haven’t heard of it. So please, if you agree with me and think the National Popular Vote Plan is a good idea, forward this page or NPV’s website to your friends, bring it up at parties, or support it with a donation. And if you don’t agree with me, forward this page or NPV’s website to your friends, bring it up at parties, or… well I guess I can’t expect you to support it with a donation.
Let’s get rid of this obsolete, broken, idiotic electoral college system once and for all.
This graphic visualizes the progress of the National Popular Vote plan (more about the politics of this plan in Hacking the Constitution).
The existing visualization on National Popular Vote’s website was flawed enough to inspire this attempt at fixing it. They use a national map with states colored according to the plan’s progress. Using geographical visualization conflicts with the plan’s intention to make the states as entities less influential, and with the plan’s success depending on the number of electoral votes, not the geographical size or population of the states1. And even though the steps in passing the plan suggest a spectrum, the colors are seemingly random.
Plus NPV is a good cause that deserves more attention. And as a vocal Flash critic, I should put my money where my mouth is and implement a cross-browser, scalable, interactive, vector graphic to show that it can be done without Flash.
Visualizing complex data well is challenging, and this is no exception. The plan will likely be adopted slowly over many years, so the graphic must be designed to expand. The technology must also be future-proof; I don’t want to have to re-implement the graphic, convert it to a different format, or get access to future versions of software, or the operating systems that software must run on, just to keep supporting it. This pretty much rules out Flash and Sliverlight.
These constraints make SVG2 and JavaScript a good choice. SVG support is still nascent in Gecko and WebKit3 (and even Opera supports it), but the standard is pretty usable and I expect it to gain more adoption over time. All of the rendering code is in JavaScript. I’d put money on JavaScript interpreters remaining readily available ten years from now. I unfortunately have no ability (or desire, for that matter) to test this in IE with Adobe’s SVG plugin; if you try it, email me the results.
There are many different entities involved in the process: fifty states, each with two legislative bodies and a governor, and a total of 538 electoral votes; and many different events: passing the first body of a legislature, passing the second, bills passing the same body subsequent times, being signed into law, being vetoed, vetoes being overridden, and (hopefully never) laws being repealed.
The data comes from disparate sources; most comes from NPV’s website, but I had to search for the vetoes. The data is not just linear; it overlaps and interacts. A veto affects two of the charts but not the third, and a repeal would affect all three. The three charts have an order; a bill cannot pass both houses before it passes one, and cannot be signed into law before it passes both.
To include all this data, a visualization would either have to be interactive or poster-sized. This one is interactive; you can mouse over vertexes in the charts and get more information about the events they represent. You can quickly and easily find out:
As with many real-world data visualizations, unexpected patterns emerge. Most activity is clustered in the winter, spring and early summer, when legislative bodies are in session. The only things that happen between August and December are vetoes. This cycle will likely become much more obvious once the graphic spans a few more years.
Hawaii’s legislature overrode their governor’s second veto, and The Governator has twice robbed the plan of California’s 55 electoral votes. Neither of these facts is obvious from the current graphic. If the plan is ever repealed, the graphic would need to show that too.
As I said in Hacking the Constitution, the the National Popular Vote plan deserves a lot more attention and support, so forward this page or NPV’s website to your friends, bring it up at parties, support it with a donation, or include the graphic on your web page.
<canvas> element might also have been a viable option, but I already knew SVG. ↩It’s business as usual over at Ubuntu headquarters. This time the “Root Terminal” menu item, installed in the system menu by default for at least the last few years, is suddenly broken. Irate users commenting on bug reports in Launchpad are dangerously close to starting a full-blown flame war:
Sebastien, your comment seems to imply that Launchpad bug reports are a waste of time. Is this really what you meant? I had been under the impression that Launchpad was intended to be a gateway/portal for bug reporting. If Launchpad reports do not get forwarded upstream automatically once triaged then what purpose does it have? -Russel Winder
and:
With all due respect Sebastien — I can hardly believe that
I’m reading this: “ubuntu only distribute it”.(why even have a bug reporting system in the first place,
one wonders, btw.). -bjd
(That’s right, those are in response to the same Sebastien Bacher I took to task for unhelpful comments on other bugs last year.)
The bug itself isn’t Ubuntu’s fault, but the fact that the menu item survived intact in the default Ubuntu configuration despite being non-functional for (at least) the last four months speaks volumes about what passed for testing on Jaunty Jackalope1.
Temporary workaround, until Gnome fixes this regression and Ubuntu inherits it: change the menu item to gnome-terminal -e 'sudo -i'. It took me longer to write this paragraph than to change that.
Bert Bos’s Why “variables” in CSS are harmful illustrates some all-too-common mistakes technologists make when considering feature requests from their users. It also indicates how deeply out of touch Bos (and possibly the entire W3C) is from people who actually have to read, write, debug, and use CSS on a regular basis.
It begins:
Constants have been regularly proposed and rejected over the long history of CSS…
Proposals for a feature indicate that a technology (whether it be a specification or an application) has pain points that are going un-addressed. When those requests are frequent, they indicate that the person (or organization, in this case, the W3C) in charge of the technology is out of touch with its users.
…so there is no reason why constants should be useful now when they weren’t before.
This claim that constants are not useful underlies the entire essay, but Bos fails to ever really justify it. Here he wanders around in pseudo-mathematical jargon instead:
[An implementation of costants in CSS written in PHP] proves that it is not necessary to add constants to CSS…. But the PHP implementation has the benefit of letting authors determine the usefulness for themselves, without modifying CSS on the Web.
It sounds like Bos refuses to consider an implementation of variables1 in CSS unless someone provides him with a mathematical proof of their utility. But utility is an opinion, not something that can be proven, like Turing-completeness or the irrationality of √2.
The existence of the PHP implementation Bos mentions, and of other implementations like the wonderful CleverCSS or Reddit’s vaporous C55, argues strongly that variables are useful — so useful that many people have implemented them on top of CSS. Of course, this does not prove usefulness any more than any other opinion can be proven.
Next Bos considers implementation effort:
…extending CSS makes implementing more difficult and programs bigger, which leads to fewer implementations and more bugs.
Difficulty of implementation should never be a deciding factor in whether or not to address the needs of the users. This point is important enough that it bears repeating: implementation effort is not relevant when deciding what your users need.
Why not?
Technology exists to make users’ lives easier. As a technology evolves and matures, users express needs and the authors of the technology develop features to address those needs. It is the user’s needs, not easily implemented features, that drive development of a technology.
If two features serve the same need, then picking the easier-to-implement one is perfectly reasonable. And if the only way to address the users’ needs is with a feature that’s extremely difficult or impossible to implement, then a project might find itself considering whether some or all of it is still viable. But a difficult implementation is never a justification in itself for not addressing the users’ needs.
In the case of CSS, the users ask for variables because they need some way to stop repeating themselves when they encode colors, lengths, and other values in CSS.
Refusing to serve the users’ needs because the requested feature may be difficult to implement shows a lack of understanding of those users’ needs as well as poor judgment about how to handle feature requests in general.
There’s another subtle fallacy here too. When Bos worries about ease of implementation, it sounds like he’s trying to make browser authors‘ lives easier, as if they were the users that the W3C are working for. But browser authors aren’t the real users of CSS any more than, for example, the authors of a C compiler are the ultimate users of C. Web designers are the real users of CSS. They are the target audience whose needs should be considered.
Arguing from implementation effort, and talking about browser implementors instead of CSS authors illustrates how far out of touch Bos is with real web designers, doing real work.
It’s also questionable how truly difficult implementing global, un-scoped variables (or un-changing constants) in CSS would be, especially compared to other complex aspects of CSS like the cascade. But that’s a discussion for browser authors.
Next Bos argues that variables would make CSS less maintainable, not more. Bos presents two reasons that code is encapsulated behind a function in programming languages:
Dividing up a problem into smaller ones is only one reason for defining functions. Just as important is the fact that a function that fits on one screen is easier to write than one that needs scrolling.
Because CSS variables wouldn’t help divide up a problem into smaller ones or help CSS stanzas fit on the screen more easily, Bos argues, they aren’t helpful:
[Constants] would add a cost (remembering user-defined names) without a benefit (avoiding problems that are longer than one screenful).
Experienced programmers know that there’s a third benefit to encapsulating code or data behind a function, variable, or constant: not repeating yourself. This is why users keep asking for variables in CSS. Bos goes on to say that variables would be detrimental to CSS because they would increase the length of stylesheets. However, not repeating yourself is much more important than just keeping your code short2, so this point too is moot.
This section concludes:
What remains is the cost of remembering and understanding user-defined names.
Of course, stylesheets are full of user-defined class names, and CSS authors seem to have no problem using and remembering those, so it’s hard to see how user defined variable names are going to be any more intellectually challenging for CSS authors than class names.
The next two sections, “Reusing style sheets,” and “Learning CSS” continue to conjecture that user-defined variable names would be a great hindrance to using and learning CSS. But the frequency of proposals to add variables to CSS suggests they are not difficult to understand, and including them would not significantly hinder learning CSS.
But there’s not much point in arguing over such conjectures. Arguing from the point of view of a theoretical group of users who have, and lack, certain skills, is a dangerous distraction. If you have data about your users, use it. If not, collect some before making your decisions, or base your decisions on what you know your users can already do.
For the sake of argument, assume Bos’ hypothetical group of users exists. Assume there is a subset of the CSS authoring population that can comprehend the CSS cascade, relative sizes defined in ems, hexadecimal RGB color codes, and user-defined class names, but are unable to grasp the concept of a user-defined variable in CSS. (It sounds bizarre, but that’s what he’s claiming.)
These hypothetical users could just refrain from using variables in their stylesheets whatsoever. Unlike hexadecimal colors, em units, and many other aspects of CSS, nothing about variables would force CSS authors to use them. Variables could be added to the CSS standard without increasing its complexity or the effort required to learn it.
Bos also claims that user-defined variables would break easy reusability of CSS:
CSS is fairly easy to learn to read, even if some of its effects can be quite subtle. When there is a page you like, you can look at its style sheet and see how it’s done.
Anyone who has tried to copy a CSS effect from one site to another knows how difficult it truly is. To copy the visual appearance of a single element, you must understand not only the computed style of that element, but the computed style of all of its parent elements. You need at least a rudimentary understanding of both the CSS cascade and the structure of the HTML of the page. To copy the look of an entire page, you have to copy all of the CSS files for that page and mimic the structure of the HTML exactly, or reverse engineer the entire thing from the ground up.
Beyond the issue of whether copying CSS effects is easy or not, however, the question is whether CSS variables would make the job more difficult.
Bos points out that in-browser debugging tools help you to copy CSS by showing you the computed style. Presumably if CSS contained variables, those debugging tools would show you the values computed using those variables, not the just the variable names.
And if you were just copying a site’s HTML structure and CSS wholesale, then there’s no reason why you would even need to read the CSS or figure out what the variables mean.
It is too difficult to look in two places at once, the place where a value is used and the place where it is defined, if you don’t know why the rule is split in this way
Of course, when reverse-engineering the CSS for a site, a designer already needs to look in multiple “places at once” — they look in multiple CSS files, match class names in the CSS to names in the HTML, and consider the effects of the cascade. Is Bos really suggesting that a person capable of doing that will be incapable of finding a variable definition in the same file where that variable is used?
Rather than showing us that CSS variables would make re-using CSS more difficult, Bos asserts that a difficult, complex process is simple, and that CSS authors already performing this task are too stupid to handle a much simpler one.
Bos also claims that figuring out what variable names mean will be difficult for CSS authors — even when debugging their own code. Most CSS authors use generally descriptive class names like green-button, huge, and floatleft3. High traffic sites run their CSS (and their HTML and JavaScript) through compressors/obfuscators, but most of those sites use descriptive names internally too. It’s hard to see how CSS variables would be named any differently than CSS classes, so it’s hard to see how CSS variables would be any more difficult for CSS authors to reverse engineer or remember.
None of Bos’s arguments against variables in CSS hold up. He claims CSS doesn’t need variables, but fails to recognize CSS authors’ true need to avoid repeating themselves. He argues CSS variables would be too difficult to implement, but implementation difficulties are invalid grounds to justify leaving users’ needs unaddressed. He argues that CSS variables would add too much complexity to CSS and no benefit whatsoever, but overlooks a key benefit that CSS variables would provide. All his arguments about the complexity variables would allegedly add to CSS are difficult to accept given the current complexity of CSS.
A feature request is a need in disguise, and multiple, persistent feature requests indicate a serious need behind a very thin disguise. Rather than arguing against a feature, you should endeavor to understand the underlying need. Rather than arguing from implementation complexity, you should decide whether that need must be addressed. Rather than arguing from hypothetical, invented users, and speculating about complexity, you should collect real user data or look at the kinds of tasks your users already handle.
This entire article4 calls into question Bos’ ability (and, by association, the W3C’s) to identify and address the needs of real CSS users and choose features to solve real shortcomings of CSS. I hope my analysis of this article helps other technologists learn to understand and address their users’ real needs better, and avoid poor reasoning when arguing against, or for, a specific feature.
For more on problems with CSS, see CSS Considered Unstylish.
yves and coralie. ↩
