Eddie Welker.com

My first order of Quarry House wings was “medium.”  The waitress had told me that they ran one level hot, and the medium were actually hotter than an standard “hot.”  My nose was stuffed and my eyes were fully watered up at the end of twelve.

We decided to set up a trip with Andrew, Rich, myself, and my sister. I realized that Aman loves hot food too, so I invited him as well.  We formally decided to go the night that Young Frankenstein played at the AFI. The final group was myself, Simon, Andrew, Rich, Alissa, Cathy, Shveta, and Aman.

The order came out, 9 wings each of the mild, medium, hot, and 4 alarm.  As my sister said later, we probably should have started with the mild and worked our way up… but instead we each went to the 4 alarm. Lips started to burn, glasses (Rich’s) came off, and instead of laughter, yelling, or anything positive, we all spent time making sure we were physically ok.  When the burning stopped, we could taste a familiar sweet habanero flavor.

Aman had three, Cathy and myself two each, and Andrew and Rich one.  Shveta took one bite and gave hers to Aman, while continuing to enjoy her Fin du Monde.  Cathy had her first Dogfish Head Palo Santo (and enjoyed it).

Young Frankenstein was amazing as usual.  Where wolf? There. There wolf.

… it would seem that I own too many CDs.

Managed to concoct a recipe that I ended up quite liking today.  Documented since I am unlikely to randomly repeat it.  Makes 3-ish decently sized portions.

Start cooking 3/4 of a cup of rice.

Brown an onion in a tablespoon of olive oil, adding some salt (I used a medium amount [about 1/3 of a teaspoon] of coarse sea salt), and a decent amount of black pepper.  Cook until moderately browned.  (I added a teaspoon of A-1 sauce for a vinegar taste, and 1/4 of a tablespoon of hot thai seasoning [extremely spicy with a hint of lemon], but these are probably optional.)

Add 2 (or more… as much as you like) tablespoons of sliced garlic (not too thin), and 1 red pepper, cut into aprox. 1cm by 1cm cubes (you want a little flavor in each bite), and another tablespoon of olive oil.  Cook until the peppers look good (the garlic will follow).

Add about 4-5 sprigs of fresh dill, ripping it into small pieces, and then the rice, and stir (feel free to add a tbsp or so of water if it’s sticking).  Cook for another 3-5 minutes, until the liquid is drained.

I served it with two tiny-tiny steaks cooked in the same large-sized pan, seasoned with salt and pepper, though the rice would have been enough split between two people.

Tonight I tried a new recipe tonight, on a whim (I hit up the grocery store on the way home from work]. It was my first time making any pizza, much less two whole large pizzas, and they turned out extremely well.  Only tools used were a food processor (with dough blade), oven, two pizza pans, and a pizza cutter.  Adding the recipe here for my own records.

1. Proof a teaspoon of yeast (dump it in 1/2 cup of warm water), let rest 10 minutes until one consistency.
2. Add 3 cups of (bread, it’s high-gluten) flour to food processor, 2 teaspoons (on the small side, unless you like salt), a teaspoon+ of freshly ground black pepper (optional), and pulse the food processor for a few seconds.
3. Turn food processor on, add the 1/2 cup of water, and then get another 1/2 cup of water and add that.  Add 2 tablespoons+ olive oil to the mix.  Make sure the dough isn’t sticky enough to stick to the sides, and not so dry that it’s not sticky.  If not, either add a teaspoon of flour or water (1 per 30 seconds) until it’s the right consistency. Adding too quickly means it won’t work it’s way through, and you may over-do it.
4. Take dough, knead for a few seconds, put in a greased bowl, and let rise in warm area. Try for an hour or two, but 30 minutes (the time needed to get the other ingredients) is possible.
5. Get all of the other ingredients together.  Add slicing blade to food processor if possible.  Gather all veggies, and slice them.
6. Grab dough, pre-heat oven to 500 (or a little above.)
7.  (Very lightly) flour a countertop.  Knead for a minute or two, then cut into two.  Make two flat-ish, 5/6-inch (but still a little thick) pizza crusts.  Let sit for 10 minutes (which makes it easier to shape), and then roll the dough into real pizza-crust sizes.
8. Add olive oil on top of the dough.  Then add tomato sauce, then add cheese.
9. Add veggies.  If sliced in the food processor, you can stack ‘em high, and they’ll simply bake down.  Any thicker, and they may take a little longer. I used the 4mm slicer blade, and everything came out perfectly.
10. Cook pizza for 10+ minutes, looking in @ 10 minutes.  If you like, throw a 1/5th or less cup of water at the bottom, which [should] help the crust rise.  If using a pizza stone, you can cook 2 @ the same time… one on the pizza stone which will cook faster, and one beneath.  When the first is done, move the second up on the stone, and it will finish in just a few minutes.

No, I did not make the sauce.  Needed to save something for next time!!!  Actually, next time I will let the dough rise in the fridge either from AM to PM, or overnight, though that may be overdoing it a bit.  We’ll see.

In the last few years much emphasis has been placed on web performance issues. Browser vendors have optimized JavaScript engines, JavaScript libraries have been honed, and content delivery has been improved. Unfortunately, CSS has received less attention. Developers have been advised how to optimally transfer CSS files, and instructed to use CSS shorthand, but very little has targeted CSS code itself.

Ms. Nicole Sullivan is among those looking to improve CSS code. She has been promoting “OOCSS,” or “Object Oriented CSS,” her methodology for how to design and refactor CSS¹. She has collected a number of best practices for architecting a CSS framework. The benefits are simple: CSS will perform better, become more modular, as well as being grounded with a consistent API, making it easier to learn and use. This is accomplished by reducing the file size and complexity of our CSS.

While many of these techniques can be considered common practice for experienced CSS programmers, implementing them can be difficult. The art is in analyzing trade-offs and picking the optimal path. That said, these rules are not for everyone, or every site. It all boils down to deciding if the site’s performance gain is greater than the time it takes to learn and use the techniques.

Useful for sites with

• Many pages
• A common visual and structural design
• Critical performance requirements

Less useful for sites with

• A few pages or just one page
• Varying design (possibly “portfolio” or design sites)
• Few performance concerns

So how do we get started? We go hunting for bad code smells. In Chapter 3 of Refactoring: Improving the Design of Existing Code, Martin Fowler and Kent Beck coin the phrase “code smell,” meaning “structures in the code that suggest the possibility of refactoring.” Simply put, we go looking for chunks of code that our intuition tells us could be cleaned. In the chapter heading, Grandma Beck is quoted (then talking about child-rearing), “If it stinks, change it.” We’ll take a more formal approach to finding these code smells, going from easy to difficult. First, we’ll sniff around the CSS selectors, and then move onto the CSS properties. Finally we’ll look for visual design patterns that can direct the structure of our CSS.

Selectors

Selectors are both the easiest place to find code smells in CSS and the easiest to correct. Three big code smells tend to stink up CSS selectors; unused selectors, location-based selectors, and overly specific selectors. Each contributes significantly to increased CSS file size.

Unused Selectors

Code that does nothing is obviously wasteful, and is the first candidate for removal. Tools like dust me selectors that can spider a site can identify all of the unused or orphaned styles that your stylesheets still contain.

Location-based Selectors

Location-based selectors prohibit code reuse because they are intended to isolate styles for a specific part of the page, yet frequently used HTML components are often reused in a different context. Therefore, its counterproductive to hard-code that initial context into a selector.

Location-based selectors are easy to spot. The pattern is a long list of selectors that starts with the same initial selector, as follows (assuming the source is reasonably ordered).

.sidebar {…}
.sidebar .nav {…}
.sidebar .nav .box {…}
.sidebar .nav .box .header {…}
.sidebar .nav .box .body p {…}

Because each selector chain starts with a location-based selector, none of them are reusable. What if we add a new group of pages that use the same .box structure but need to be placed in the content, header, or footer? A novice would add more comma separated selector chains, but that amounts to copying code.

.sidebar .nav .box, .content .nav .box, .header .nav .box, .footer .nav .box {…}

The correct approach is to factor out the common functionality while ditching the location-based rules. Now the styles can be reused regardless of the box location.

.box {…}
.box .header {…}
.box .footer {…}

Why not break the .box and .header/.footer chains apart? Here the .box class encapsulates the .header and .footer behaviors, hiding these names from the global scope and allowing the “header” and “footer” classnames to be used elsewhere.

To those looking ahead to HTML5, you should already recognize how this pattern can be applied to section elements containing header and footer elements.

Varying specificity

By 2010, everyone should be aware that adding “style” attributes directly to HTML elements is a bad idea (and code smell). What about everything else?

Selectors that contain properties set as !important should be avoided because their specificity makes them difficult to override.

Browser selector hacks like * html {…} should be avoided because they tend to require redefinition of both the problem properties and all other properties, leading to duplicate code. When hacks are needed, use property hacks like the star (IE7 and less) and underscore (IE6 and less) instead.

Because IDs can be used only once per-page, selectors containing IDs can typically only be used in a specific place on each page. IDs are great when you need to grab something from the DOM in JavaScript, but avoid them in your CSS.

Element selectors should be used to provide element defaults, especially when redefining styles previously zeroed out by a reset stylesheet. Using them for anything but defaults tends to yield repetitive CSS.

Keeping selector specificity as similar as possible makes it easy to use classes that only define differences.

HTML:

CSS:

.box { padding:1em; color:black; border: 1px solid black; }

/* simple selectors because the specificity is equal to the base ".box" object's selector */
.green_border { border: 2px solid green; }
.red_border { border: 2px solid red; }

Properties

Properties appear in CSS more frequently than selectors, and as a result their quantity masks their code smells a bit. However we can exploit their frequency to find repetitive code².

Margin: 0 and padding: 0

Resetting the margin and padding properties to zero is extremely common. Using a reset stylesheet will help you do this everywhere in one place. A reset will zero all margin and padding properties, leaving only the non-zero values left to set. If you find that your CSS contains more instances setting the margin or padding to another value (for example, 1em), you can edit your reset or add a global rule setting this alternate default.

Before:

(my.css)

.portlet {margin:0; padding:0; … }
.header {margin:0; padding:0; … }
.footer {margin:0; padding:0; …}


After:

(Reset.css)

div {margin:0; padding:0}

(my.css)

.portlet { … }
.header { … }
.footer { … }

Float

Overuse of the float property is a code smell indicating repetition in placing items on a page. Use of a grid structure will reduce duplication caused by object placement. Rather than have each element float itself, a grid structure will do this all one time only.

Font-size

It’s rare for sites to use multiple sizes of body text on one page, or site wide. Therefore most font-size properties are likely used to define header-like text sizes. Ms. Sullivan does an excellent job pointing out, that of a finite number of font-sizes that can be used on a page, there are even fewer that a user can differentiate (for example the difference between 15px and 16px browser font sizes). Font-size therefore is usually a code smell for repeating headers.

Mingling box model, visual formatting model, and presentational properties

The CSS specification groups similar properties into sections. The Box model is the most famous (because it had previously been the most infamous). Everyone is familiar with its margins, paddings, and borders building on widths and heights. The Visual formatting model uses the display, position, float, clear, and z-index properties to dictate the layout of the boxes in the document. The CSS specification makes no mention of “presentational properties,” but that’s a term I use to include color, background, font, and text properties that style the boxes or their contents.

Separating selectors along these lines allows for greater code reuse. The box model properties are the most easily re-used of the three. It is not uncommon for a number of boxes on the page to share the same properties, so moving these properties into a new class will allow you to apply these styles in a consistent and efficient manner. The visual formatting properties are typically less likely to be reused, therefore separating them from the boxes will allow greater reuse of both the visual formatting and box properties.

It must be noted, however, that there will be cases where the same box model properties will often be paired with the same visual formatting properties. In that case it is perfectly acceptable to leave them coupled together.

Presentational properties are the least likely set to be reused. This isn’t surprising because they are typically dependent on the contents of the boxes. That makes these the most logical candidate for extraction, because doing so will increase the usability of the remaining properties.

Keep in mind we are still trying to build a consistent API for others to use. Creating new patterns of box model, visual formatting model, and presentational property oriented classes will give future developers a wide range of flexibility to mix-and-match these classes while styling new elements.

Visual design patterns

In the last section, we looked at the effects of mingling box model, visual formatting model, and presentational properties. Searching for visual design patterns is the next logical step, albeit a complicated one.

This technique is tricky. Unlike the others, this has the additional restriction in that it is usually only suitable for finished designs. Attempting this on an in-development design may send you on the road toward madness. Additionally, it doesn’t lend itself very well to searching code. In effect we are looking for repeating groups of CSS properties… but these properties can typically span multiple selectors! So instead of looking to the code for patterns, we look for patterns in the other direction, at the visual output.

This technique also takes the longest, since it requires looking at all of the pages on a site as a whole.

Headers

Finding headers on the page should be fairly simple, and to be honest, you’ve probably taken care of this searching for repeated font-size properties as described above. However a visual inventory may convince you that your headers are more alike than different, and you may find an opportunity to tighten the differences. You may even decide to dump one of the variations—even better.

Portlets

In a portal or information dashboard oriented design, each chunk of output, whether contained in a box/window type structure, or structure-less (think Apple’s Dashboard) is bound to share common characteristics. In the structure-less design you can focus on extracting the visual formatting properties into reusable classes defining position. Box or window contained portlets can be constructed using a combination of box model, and presentational properties. And if you’re using a dashboard design, these chunks of output can probably be arranged using a grid structure.

Grids

Alignment is the key to identifying patterns where grids can be applied. Take five steps back from your monitor and look at the top-level page objects. If some of these objects are loosely aligned, they can probably be included into a grid. Sketch the grid and the objects within on a piece of paper. Now walk three steps forward, and look at the each individual section in your wireframe. If you identify objects aligned in your sections, you may be primed for using a nested grid. Sketch that grid (have you realized that you’re wireframing yet?). Keep going until you’ve exhausted all of the sections you’ve drawn (have you realized you’re using recursion yet?)

Then start the tedious process of tearing out the previous code and replacing with a grid structure.. The end product will be far more efficient and easier to maintain. (Which grid should you use? Which every you choose! As long as you are using one your code will be cleaner and more efficient.)

“Media Blocks”

One pattern that Ms. Sullivan found frequently on the Facebook site is something she has coined a “Media Block,” which she defines as “an image to the left, with descriptive content to the right.” Simply put, this is just a compound object, which is slightly more abstract than the previous examples. She analyzes these media blocks in two steps. First define their constant functional properties (what they do), then identify the variables in the design (parts could fluctuate in certain conditions).

Not all sites will contain objects like these, but if yours does, identifying the patterns will help to reduce code duplication and promote code reuse.

More

This short list couldn’t hope to represent the entirety of the visual design patterns that can be found on a website. That’s why a site inventory is required. If you find similar patterns repeating multiple times, this is a chance for you to optimize.

Results

Once these rules have been applied, your file size should be smaller, so less information has to be downloaded, making the page load faster. The overall complexity of your CSS rules should also be reduced, meaning the browser will have less redundant rules to apply, and your page should load faster. And finally, you will have defined an API for common CSS across your site, making it easier for developers to create new pages.

Footnotes

¹ Personally, I find the choice of the “OOCSS” or “Object Oriented CSS” name both poor and misleading. To call something “Object Oriented” when the metaphor doesn’t fit (CSS has no data per se, and it certainly has no methods) is confusing, especially when the audience is likely to be familiar with the term. To then give your CSS library the same name and overload the term twice obscures a very useful set of CSS refactoring methods.

² This can be accomplished with the Unix tool grep, a powerful text searching utility. It is also possible to accomplish this through your editor, as long as it supports searching multiple files at once. It is especially useful to be able to count occurrences across files.

I just removed a (real live) bat from my living room.  That was easier than installing PIL in a virtualenv for Ubuntu 9.10. Why?  Googling the subject seems to bring up a lot of old or mis-information.  This will explain how… mostly so I can do it again next time.

I started with a –no-site-packages virtualenv, so as not to use (or more  importantly depend) on any of the global site-packages.  Ok, cool.

$ virtualenv --no-site-packages myEnv

First, I needed to install the python developer tools. (Use apt-get or aptitude, whatever floats your boat)

$ sudo aptitude install python-dev

Then, I needed to install libjpeg and libjpeg-dev.  I’m not sure why, but I needed libjpeg simply doesn’t exist, so I needed to install libjpeg62.  I can’t pretend that I know the difference (or if there is one).  In fact, I may have gotten away with installing libjpeg62 and libjpeg-dev (rather than both “62″ versions… libjpeg62 and libjpeg62-dev), but only further testing will tell.

Why? If you install PIL without this library, you’ll get those wonderful “decoder jpeg not available” messages in Python.  Or worse yet, if you’re trying to use it in a Django, you may get some errors (specifically the “Upload a valid image. The file you uploaded was either not an image or a corrupted image” warning), or you may not get any until you open the shell.  Either way, you can test with the method listed below.  If you get the “decoder jpeg not available” message, your install didn’t work.

The zlib package handles PNGs.

$ sudo aptitude install libjpeg62 libjpeg62-dev
$ sudo aptitude install zlib1g-dev
$ sudo aptitude install libfreetype6 libfreetype6-dev

Alright, now we seem to be done with the prerequisites. Start your virtualenv (of course, myEnv in the example is the name of your virtualenv).

$ source myEnv/bin/activate

Download PIL and install.  This will make sure to install PIL within your virtualenv’s site-packages.

(myEnv)$ wget http://effbot.org/downloads/Imaging-1.1.7.tar.gz
(myEnv)$ tar zxvf Imaging-1.1.7.tar.gz
(myEnv)$ cd Imaging-1.1.7
(myEnv)$ python setup.py install

If you run into further problems (the “decoder jpeg not available” message again), you may have to resort to the long directions to get PIL and libjpeg to play happily together, but I hope not.

Now that you have everything installed, test it.  Open up a python shell from within your virtualenv.

(myEnv)$ python

Now try the following (with an image in your home directory) to see if everything is running smoothly.

>>> from PIL import Image
>>> i = Image.open('/home/username/someJpeg.jpg')
>>> i.save('/home/username/someOtherJpeg.jpg')

If all of that works, you should now be ready to work.

Note: I would love to install the jpeg, freetype and zlib packages locally as well, but that was a step beyond what I was willing to mess with.  Maybe for a future set of instructions.

****

UPDATE:

In Ubuntu 11, it seems that you need libjpeg8-dev, rather than libjpeg62.

There were many things to like about this book Learning jQuery 1.3 by Jonathan Chaffer and Karl Swedberg. The stand-out positive in my mind is the wealth of topics covered. Both simple and difficult concepts are included, and both are handled with ease. Good coding habits are repeatedly mentioned throughout. Subjects like progressive enhancement are encouraged, and pitfalls like memory leaks are warned against. Many real-world examples are included, as well as the full source code.

Learning jQuery 1.3 has a writing style that is very dry for a book written in a semi-conversational voice. I prefer a writing style with a little more personality to it, but acknowledge that’s not for everyone.

I did have two small complaints. First, I like to see the API list out at the top of the chapters. Appendix D contains a complete reference, but I like having a list of methods to be covered at the beginning of the chapter. While I’m at it, I may mention that the “complete” reference is little more than a cheetsheet style list. Perhaps a little more would have been useful.

My second complaint is about the poor code syntax highlighting. Just for record, this has nothing to do with the content, it’s just a complaint against the publisher. Take page 145, where three-quarters of the page is example code, but contains only bold line at the top showing the emphasized line. First, the bold often wasn’t enough to draw the eye… especially at the beginning of the book when a novice reader has to mentally separate standard JavaScript from jQuery code. Second, I understand that the example code is included, but couldn’t it have simply been excerpted here? I don’t understand wasting an entire page, when much less would do.

Based on the overall quality of the book, I recommend it for jQuery beginners.

I am fighting the typical developer’s feeling that I should write my own blog software… something that does what I want how I want it (less I forget, eats up a lot of time and would almost certainly be worse than an out-of-the-box solution).

Instead, I ditched my theme in favor of something different, and added a few links. Enjoy.

Summer was ending so I decided to move.  Ok, not really, it was simply time.

I’ve moved back to my parent’s house in Laurel, MD… which is exceptionally close to Columbia, MD.  I’ve moved into my parents house in an attempt to save some money, I want to clean it and restore it, while putting my would-be rent money into the property taxes here.

The move wasn’t difficult in and of itself, but tied with the work that needed (and still needs) to be done at the house, it has been quite an undertaking.  I have so much to do it’s quite overwhelming.

All of that mess aside, I am looking forward to getting back to study.

The Scheme steering committee has decided to sever the Scheme language into “Large Scheme” and “Small Scheme.”  Can we expect the same from Scheme-inspired languages like JavaScript? 

Finally got the cranks on, the pedals on, the new 17 tooth cog on the old wheel that I re-tensioned and trued (well, partially trued at least), only to put the chain on with a broken chain tool. (I didn’t realize it was broken). So one of the bushings became bent, and on my ride home, I popped the chain. Tried to use alternate links to fix it, but they stuck (and ended up with only slightly bent bushings). So a new chain it is for me, unfortunately.

Not a technical post, but a personal update.  I promised over a week ago.

I’ve been exceptionally busy at work, we’re beginning to finish up a much needed, much discussed by librarians, redesign of PubMed.  We’ve put a ton of user interaction effort into this project, as well as a good sprinkling of graphic design (watch out, I even did some parts!)  I think people will be really positive about these new changes.

[Just for the record, if someone happens to stumble upon this from the librarian community, yes, release date is still end of summer, and yes, there will be a Beta period, so no need to worry about a short timeline to update your class or instructional slides.  We do listen!]

It’s also been exciting that we’ve brought a few new people on board.  Always exciting to have new hires, despite the fact that it’s a lot of work… and all of the trainings I have to do.

What else…  I’m planning on attending the DelveUI masterclasses this week in Brooklyn.  It will be interesting to see what some of the heads of state have to say about the field.  I’m a little excited, this masterclass format isn’t the usual boring no-content fluff that you hear at most conferences. I get the feeling that there will actually be code present!  My thanks to the lovely Jina “Sushi & Robots” Bolton for the opportunity for the free ticket.

I’ve been reading… way too many things.  I’ve been reading Learning jQuery 1.3, jQuery UI 1.6, and jQuery in Action and you’ll see the reviews of those two books very soon.  (Can you tell that we’ve switched to jQuery at NCBI?)  I’m a little behind with that reading, but I’ve been working hard on other things.  Additionally, I went on an Amazon spree, and started reading Programming the Semantic Web, An Introduction to Lambda Calculi for Computer Scientists, To Mock a Mockingbird, 101 Things I learned in Architecture School, Code Complete 2.   Last but not least, I’ve also been reading any photography book that I can get my hands on.

Yes, that is a lot of books, and I haven’t had much time for them.  I’ve been working hard at work, and I want to relax a bit when I come home.  Once summer ends, things will return to a slightly more regular pace.  I’ve been learning so much on the job, that I’m not very worried about falling behind in reading.

It’s the summer, so I have been riding… not a ton, but some.  I wish I had time to do more, but I don’t have time for everything.  I have been taking long-ish 7 mile rides home, and then going out to play some basketball with my roommates.  That’s a good time.  As soon as I finish this post, I am going to go and fix my fixie… my favorite Bianchi… I somehow mashed the pedals hard enough to shear off part of the thread of both the crank and the pedal, so there go the original cranks and some lovely MKS Sylvan Track Pedals that were on there. I’ve got a new, generic replacement crankset and new Sylvan’s.  Also, I’m moving from a 42×15 to a 46×17, but with the change in crank length (172.5 down to 165mm) I’ll have the same gear ratio as before.  I’m interested in seeing how the shorter cranks feel.

Not to mention le Tour this year… I was captivated.

And then I’ve been taking some photos.  Still have been good on my New Year’s resolution of taking a photo every day… with the exception of Jan 20 (yes, Inauguration Day, the day more people in my Washington DC area took photos than any other this year).

I also got an iPhone.  While I was in California for Joel and Olga’s wedding, I dropped my phone of more than 5 years on a rug, and the antenna that had been barely holding on for a few months finally fell off completely.  I had previously told myself that I would try to wait until my phone broke before getting a new one. So I was going to buy one at the first sight of antenna problems, until it was suggested that I wait for a new version.  Well, my phone’s demise and the new version’s release coincided, so now I have a 3GS.  Really the thing I like most is having my calendar with me at all times.  The only other part I really like is the speaker, so I can listen to music while on my bike for the first time.

Alright, so that’s about that for the moment. Go out and do something summer-y, that’s what I’m doing.

I’ve been… not away, but simply taking pictures. I should get back to writing… more JavaScript (to refresh myself), more XLST, a little Django/Python here or there. I’ll do that soon.

On Mar 31, 2009, at 11:45 AM, Edward Welker wrote:

>> Aaron wrote:
>> This may be one of the best URLs I have ever seen:
>> http://www.ringling.com/FlashSubContent.aspx?id=11654&parentID=320&asset
>> FolderID=340
>>
>> Just looking at it, I can tell exactly what I can expect when I click
>> it.

***

To me, that URL tells a delightful children’s story…

FlashSubContent = a wonderful fantasy world
[elephant] id = 11654 [Dumbo]
[elephant] parentID = 320 [Mrs. Jumbo]
[cage] FolderID = 340 [because they took her Dumbo away, and Mrs. Jumbo got angry, so she had to get locked up]
aspx = evil clown makeup wearing Microsoft employees who locked Dumbo’s mother up

-e

I ran across a mention of “Prototype-Based Programming” back when I was first learning JavaScript.  I thought it would be an interesting read, but forgot to bookmark it, and forgot to look into it further.  Once I finally remembered it, it proved hard to find (and an expensive gamble from Amazon), until I found it through NIH’s interlibrary loan system.

I was quite excited to get my hands on a copy of this book, I was interested in learning more about the general theory that went into languages with prototypal inheritance.  I thought this would allow me a special insight into JavaScript.  However, as I found reading it… despite it’s 1999 publication date, JavaScript wasn’t even mentioned in the book!  Regardless, I found parts of it to be quite interesting and insightful.

The book is broken up into three sections (as mentioned on the cover), Concepts, Languages, and Applications.  Each section has 4 associated chapters which are really various papers, some of which seem to be difficult to find elsewhere.

The first section, “Concepts” was the most interesting. The first was titled “Classes vs. Prototypes: Some Philosophical and Historical Observations.”  This chapter provided a nice introduction to the topic, including the history of classification, going back to Aristotle and proceeding to Ludwig Wittgenstein who had an interesting example about classifying the characteristics of an item as simple as a “game”.  It goes on to transition to a programming perspective.  A point that is made repeatedly throughout many chapters that the idea of classical inheritance necessitating construction from the top (superclasses) to the bottom (subclasses) is inherently contradictory to the way humans think.  When unfamiliar with a domain, a person can more easily deal with concrete examples, and only discern the abstract general form after discovering these patterns in the concrete cases.  Though unable to put my finger on this idea, I’ve experienced it a number of times when programming myself, and couldn’t agree more.

The next chapter, “Classifying Prototype-based Programming Languages” sought to categorize the theoritical aspects of different prototypal languages.  This is the chapter where I most missed the reference to JavaScript, but I may look into doing that myself some other day.  “The Stripetalk Papers: Understandability as a Language Design Issue in Object-Oriented Programming Systems”, made an argument that prototype based systems could be used to enhance the learnability of languages.  Finally, the chapter “Classes versus Prototypes in Object-Oriented Languages” looked at the advantages and disadvantages of class-based and prototype-based languages.  This chapter was quite interesting, however brief.

The second section, “Languages”, lacking JavaScript, was less useful than I had hoped.  “Programming as an Experience: The Inspiration for Self” was interesting as it described the thought process going into creating the Self language, and expanded some of the ideas presented in the book’s second chapter.  Alas, I’ve haven’t yet gotten around to learning Self, but the ideas and history presented were interesting in the abstract.  “NewtonScript: Prototypes on the Palm” was interesting mostly because of it’s Lisp-like syntax and it’s description of internal closures, while “The Prototype-Instance Object Systems in Amulet and Garnet” took an in-depth look at the implementation of these two languages.  I only skimmed the “Omega: Statically Typed Prototypes” chapter, as it was rather brief, and I don’t feel confident enough (or have any real desire) to enter the static-typed/dynamic-typed languages argument.

The final section, “Applications”, was where this book showed it’s age.  “Self includes: Smalltalk” involved translating Smalltalk programs into Self, which is interesting, but I don’t see much practical application for this today (maybe if you’re translating Ruby to JavaScript? Not sure).  “Using Prototypes for Program Restructuring” demonstrated the use of an algorithm that would help to restructure code into a slot-based prototype system in a application called Guru.  “Prototype-Based Programming for Abstract Program Visualisation” ended up being skimmed, because while the topic matter seemed interesting, the demonstrations from the black-and-white mac era looked totally antiquated, and I am sure that they have been written many times in other languages since the writing.  Finally, “Agora: The Scheme of Object-Orientation, or, the Simplest MOP in the World” detailed the Agora language, a pure OO language which relied only on objects and message passing, while being implemented as a reflective language inspired by Scheme, of all things. Weird, but interesting.

You know as well as I do that computer technology is a moving target, and something published in 1999 will be outdated to a certain degree.  The good part of this book is that the abstract notions in it are rather timeless, as they have been built on over time.  Parts of this book may be out of date, but parts aren’t, and regardless, it’s an interesting read.  I recommend it, if you’re even slightly interested.