sprezzatech blog #0001
web design is decadent and depraved
sun 2012-01-29 19:20:26 est
sun 2012-01-29 19:20:26 est
I am not a web programmer, nor a graphics designer. Indeed, my career has been
focused on staying as far away from web development as possible, and I typically
answer queries as to what I code with "anything that doesn't have a user interface."
My favorite type of web page is what's commonly known as a “wall of text”;
I regularly browse with Links in its
text mode; I block JavaScript and Flash with enabled-by-default
NoScript; my favorite type of graph is a
tabular list of values, or better yet a function and some quadrille paper.
I have been programming since a wee lad of six years—1986 for those keeping track at home—and until this week I had never written CSS.
Unfortunately, every company needs a web page, and my Geocities-era level of composition wasn't going to cut it. I looked into some design firms, heard their prices, proposed that they engage in anatomically impossible activities, and accepted that I was going to have to spend some time in the dirty Triangle Shirtwaist Factory of modern web design. The languages (HTML, CSS, JavaScript) involved weren't at all worrying (any Real Programmer can learn a language in a few hours). Rather, the scrotumtightening questions in all this included: Where was I going to get images? How to make a logo which didn't look like something due a blind adolescent using Print Shop? What the hell is a “CSS Sprite”? Given that I only run Linux, how would I ensure things looked acceptable on Internet Explorer and Chrome? All I knew about IE were various exploitation methods; even if I included pwn-to-own code to start a Linux VM in IE visitors, the latency would be unacceptable, and this wouldn't even cover the Mac kids. This was a many-cigarette adventure if I'd ever seen one.
First, I needed a logo built up from scratch. My first attempt, built to be thrown away, resulted from 10 minutes on CoolText.com and some patching up with the GIMP. It was a sad affair indeed. After my call for submissions met with few submissions and even fewer decent ones, and some frustrating back-and-forth with various “graphic artists”, I decided to do one myself. I figured it wouldn't look as good as a professional's, but it oughtn't be laughably bad, and would allow me to concentrate on other things—dealing with various halfwit prima donna Photoshop cowboys, somehow to a man incapable of reading a work spec, had consumed enough time. Bring out the GIMP!
The GIMP has been around since before I started using Linux in 1998. It's touted as a commercial-grade, feature-rich, powerful image editor, and a marvel of Open Source. It deserves all these laurels and more. I have, however, never heard it praised as “intuitive”, “easy to use”, or “a good jammy for beginners”, nor
had I ever referred to it as anything but “the fucking GIMP” or sometimes,
reverently, “GIMP, the tool of dashed hopes and idle dreams” (and once in a
Jeopardy fantasy as “What is the GIMP?”. The answer, of course, had been “The
tool which fucks you hardest aside from
Blender.” It is rumored that people not
paid to work on Blender have used it to do something other than waste massive
amounts of time and frustrate themselves; after much research, I have concluded
that this is false). To the left, you'll see what greets one upon launching GIMP.
Not so bad, huh? We've got a trapezoid, a trapezoid with one retarded side (I
believe the technical term to be “right trapezoid”), something
that looks like a notary stamp, and I believe we're being given the finger in
that last row of icons, but there's tooltips and this doesn't look like anything
a few beers can't help us work through. Let's get our image manipulation on!
We know, however, that—compilers, editors and software RAID aside—things are rarely so easy on Linux. A few minutes into use of the GIMP, we find our workspace looking more like that to the right. We've reached Fucked Factor Five, cap'n, and bewilderment levels are approaching standard ISO/ANSI safety limits. Note that I have not yet actually opened an image, much less manipulated one.
Note that listed tools include “Aneurism [sic] Gradients”, the “Ega Palette”,
and the “orange swiss cheese? Pattern” (question mark not mine). Why create
a gradient whose name one can't spell? Why a pattern whose name is unknown?
Since when is Swiss cheese orange, and why would I want to pattern anything
with it? Does “Ega” refer to the venerable
Enhanced Graphics Adapter
of lore, and if so why, and if not, what the devil is an Ega? These mysteries
will have to be left for greater men than I.
While unified, complete GIMP documentation doesn't seem to exist, there are a great many tutorials covering various processes. These tutorials span a wide range of quality and currency, but that's livin' la vida Open Source, baby! Two separate tutorials exist for logo creation, each of them detailed and replete with screenshots, and both utterly out-of-date. It turns out there's a “Create Logo” wizard (or Script-Fu, as they're rather stupidly known in the GIMP community). The Starburst template (Engraver font with Supernova filter and Glow Layer blending) seemed promising. I ended up tweaking the starscape-logo Scheme script a bit:
Next up was some hot rounded gradient action. I found the common method of rounding corners, that of multiple images, disgusting on a number of levels. I resolved immediately not to admit it, and instead focused on the border-radius CSS property. It's not apparently supported in older browsers, but any excuse for elitism is a sweet salve to my aching sense of self-righteousness; the balm was applied for that Web 2.0 goodness. Likewise with the linear-gradient property, and now I had rounded gradients with not a single image added.
Especially given the blog's presence, I'd need a way to publish updates. RSS 2.0 and Atom 1.0 seem the most well-supported solutions. Atom appears to encompass more functionality (general content publication) and to be better designed (content type is specified, timestamps follow RFC 3339, etc.) but RSS claims wider support. Both are expressed in XML, which means they can be deterministically built up and modified using tools like XMLStarlet. This is, of course, a pull-based model; the <cloud> element of RSS 2.0 appears to provide an interface to push-based syndication, but I've not yet thoroughly investigated it.
As always, I wanted unit testing available from the get-go. XMLStarlet provides validation against DTD/XSD/Relax-NG schemata, as well as simple verification of well-formedness. It'd be nice to assure conformance to things like the RSS Best Practices and John Panzer's RSS/Atom Feed tips, though—that is, domain-specific semantic checks. Several services (W3C FVS, FeedValidator, and Validome were just the top Google results) exist online to do this. FeedValidator offers their tool for local use, and Debian packages it as python-feedvalidator. After checking its man page and /usr/share/doc/ entry for usage notes (always my first action upon installing a new package, and it ought be yours, too), I integrated it into my build process:
Good deal! I fixed these two up: RFC 822 dates can be generated by supplying the
-R option to date, and the <atom:link> element is
explained in the RSS Best Practices
(be aware that it requires adding the Atom XML namespace to your <rss> element).
Populating the <channel> with <item> elements
automatically required external content entries, as I was fundamentally unwilling
to automatically extract information from the current HTML 4.01 file. I thus
“reverse-engineered” a content entry from the current page; since
this represents a duplication of data (and thus a source of errors), I assigned
myself Bug 519 regarding
generating the blog's HTML from these snippets. Having prepared entries.xml
using the RSS language elements, it was simplicity itself to directly transclude
them using XInclude technique
together with xmllint.
Setting this up using XMLStarlet and GNU Make was trivial:
And indeed, the RSS discovery icon now lit up in Firefox, and I could add the syndication to my readers. I used ImageMagick's montage tool to stitch together the image in my header. GIMP's Film Filter is used for the demarcating images following each blog post.
Go go Open Source! The site grows a little less terrible each day.
I have been programming since a wee lad of six years—1986 for those keeping track at home—and until this week I had never written CSS.
Unfortunately, every company needs a web page, and my Geocities-era level of composition wasn't going to cut it. I looked into some design firms, heard their prices, proposed that they engage in anatomically impossible activities, and accepted that I was going to have to spend some time in the dirty Triangle Shirtwaist Factory of modern web design. The languages (HTML, CSS, JavaScript) involved weren't at all worrying (any Real Programmer can learn a language in a few hours). Rather, the scrotumtightening questions in all this included: Where was I going to get images? How to make a logo which didn't look like something due a blind adolescent using Print Shop? What the hell is a “CSS Sprite”? Given that I only run Linux, how would I ensure things looked acceptable on Internet Explorer and Chrome? All I knew about IE were various exploitation methods; even if I included pwn-to-own code to start a Linux VM in IE visitors, the latency would be unacceptable, and this wouldn't even cover the Mac kids. This was a many-cigarette adventure if I'd ever seen one.
First, I needed a logo built up from scratch. My first attempt, built to be thrown away, resulted from 10 minutes on CoolText.com and some patching up with the GIMP. It was a sad affair indeed. After my call for submissions met with few submissions and even fewer decent ones, and some frustrating back-and-forth with various “graphic artists”, I decided to do one myself. I figured it wouldn't look as good as a professional's, but it oughtn't be laughably bad, and would allow me to concentrate on other things—dealing with various halfwit prima donna Photoshop cowboys, somehow to a man incapable of reading a work spec, had consumed enough time. Bring out the GIMP!
The GIMP has been around since before I started using Linux in 1998. It's touted as a commercial-grade, feature-rich, powerful image editor, and a marvel of Open Source. It deserves all these laurels and more. I have, however, never heard it praised as “intuitive”, “easy to use”, or “a good jammy for beginners”, nor
Doesn't look so bad...yet.
We know, however, that—compilers, editors and software RAID aside—things are rarely so easy on Linux. A few minutes into use of the GIMP, we find our workspace looking more like that to the right. We've reached Fucked Factor Five, cap'n, and bewilderment levels are approaching standard ISO/ANSI safety limits. Note that I have not yet actually opened an image, much less manipulated one.
Having this many windows open is a crime in 18 different states.
While unified, complete GIMP documentation doesn't seem to exist, there are a great many tutorials covering various processes. These tutorials span a wide range of quality and currency, but that's livin' la vida Open Source, baby! Two separate tutorials exist for logo creation, each of them detailed and replete with screenshots, and both utterly out-of-date. It turns out there's a “Create Logo” wizard (or Script-Fu, as they're rather stupidly known in the GIMP community). The Starburst template (Engraver font with Supernova filter and Glow Layer blending) seemed promising. I ended up tweaking the starscape-logo Scheme script a bit:
[skynet](0) $ diff -ur starscape-logo.scm /usr/share/gimp/2.0/scripts/starscape-logo.scm
--- starscape-logo.scm 2012-01-28 05:17:46.761685401 -0500
+++ /usr/share/gimp/2.0/scripts/starscape-logo.scm 2012-01-28 05:23:24.242681491 -0500
@@ -59,8 +59,8 @@
(w (* (/ (- width (* border 2)) 2.0) 0.75))
(h (* (/ (- height (* border 2)) 2.0) 0.75))
(novay (* height 0.3))
- (novax (find-nova-x-coord logo-layer (* width 0.2) (* width 0.8) novay))
- (novaradius (/ (min height width) 7.0))
+ (novax (find-nova-x-coord logo-layer (* width 0.6) (* width 0.8) novay))
+ (novaradius 10)
(cx (/ width 2.0))
(cy (/ height 2.0))
(bx (+ cx (car (find-blend-coords w h))))
@@ -106,7 +106,7 @@
FALSE 0 0 TRUE
cx cy bx by)
- (plug-in-nova RUN-NONINTERACTIVE img glow-layer novax novay glow-color novaradius 100 0)
+ (plug-in-nova RUN-NONINTERACTIVE img glow-layer novax novay glow-color novaradius 50 14)
(gimp-selection-all img)
(gimp-context-set-pattern "Stone")
[skynet](1) $
and then used the Eraser, Color Selection, and Color Replacement tools to
manually wash out some of the glow-layer's effect and establish transparency.
The Text Tool was then used to add the subtitle (Courier font), and we were
(arguably) ready to roll.Next up was some hot rounded gradient action. I found the common method of rounding corners, that of multiple images, disgusting on a number of levels. I resolved immediately not to admit it, and instead focused on the border-radius CSS property. It's not apparently supported in older browsers, but any excuse for elitism is a sweet salve to my aching sense of self-righteousness; the balm was applied for that Web 2.0 goodness. Likewise with the linear-gradient property, and now I had rounded gradients with not a single image added.
Especially given the blog's presence, I'd need a way to publish updates. RSS 2.0 and Atom 1.0 seem the most well-supported solutions. Atom appears to encompass more functionality (general content publication) and to be better designed (content type is specified, timestamps follow RFC 3339, etc.) but RSS claims wider support. Both are expressed in XML, which means they can be deterministically built up and modified using tools like XMLStarlet. This is, of course, a pull-based model; the <cloud> element of RSS 2.0 appears to provide an interface to push-based syndication, but I've not yet thoroughly investigated it.
As always, I wanted unit testing available from the get-go. XMLStarlet provides validation against DTD/XSD/Relax-NG schemata, as well as simple verification of well-formedness. It'd be nice to assure conformance to things like the RSS Best Practices and John Panzer's RSS/Atom Feed tips, though—that is, domain-specific semantic checks. Several services (W3C FVS, FeedValidator, and Validome were just the top Google results) exist online to do this. FeedValidator offers their tool for local use, and Debian packages it as python-feedvalidator. After checking its man page and /usr/share/doc/ entry for usage notes (always my first action upon installing a new package, and it ought be yours, too), I integrated it into my build process:
[skynet](0) $ make -f buildpage/Makefile test sprezzatech.rss - valid Validating file:///home/dank/src/sprezzatura/sprezzatech.rss line 8, column 24: lastBuildDate must be an RFC 822 date-time line 9, column 1: Missing atom:link with rel="self" make: *** [test] Error 1 [skynet](2) $
Go subscribe to this scintillating feed!
$(RSS): $(CONDIR)/$(RSS) $(ENTRIES) $(MAKEFILE_LIST) xmllint --xinclude $< | \ xmlstarlet ed -i //item -t elem -n lastBuildDate \ -v "$(shell date -R)" - > $@
And indeed, the RSS discovery icon now lit up in Firefox, and I could add the syndication to my readers. I used ImageMagick's montage tool to stitch together the image in my header. GIMP's Film Filter is used for the demarcating images following each blog post.
Go go Open Source! The site grows a little less terrible each day.