Author: Shelley Powers

Categories
Writing

Learning Node: Concepts and TOC

Recovered from the Wayback Machine.

The Learning Node book is far enough along so that I can publish the Table of Contents for the book and it shouldn’t differ significantly from the TOC for the book when it’s finished. The chapters with an expanded TOC are those already finished—the rest are still in work. Before I print out the TOC, though, I thought I’d write about some of the underlying themes that helped define the book structure and determine the direction of the writing.

The primary theme behind the book is simple: you don’t have to have prior experience working with Ruby or Rails in order to understand this book.

Seems like a silly thing to say when we’re talking about a technology based in JavaScript, but you’d be amazed at how much a Ruby/Rails background assumption flavors interactions in the Node world. One of the real issues I found with Node in the last year is that all too often explanations are given in Ruby or Rail terms. For instance, when a person asked about what framework to use, another answered him that “Express is like Sinatra, while Geddy is more like Rails”. Well, that’s just peachy…if you’ve worked with Ruby, Sinatra, or Rails. If you haven’t then the answer might as well be Martian for all the useful information it provided.

My book assumes you have experience with client-side JavaScript, and you’ve mainly worked with more traditional web/Ajax type of development. There are no references to unknown technologies, and no esoteric Rubyesque or Python asides. Even when I cover how to create an MVC (Model-View-Controller) application using a popular framework, Express, I do it in such a way that you can follow along no matter how much experience you’ve had with MVC.

This doesn’t mean I talk down to my readers, but I happen to believe that Node is actually a lot easier to use than may be first apparent, and one major roadblock to understanding are all the assumptions shared among many of the current practitioners.

Another underlying theme to the book is dealing with a second major roadblock to Node adoption: lack of documentation. Or I should say, uneven documentation. Some of the third-pary modules are nicely documented, others have no documentation, and the Node modules, themselves, fit somewhere in-between. There are tutorials and other reference material—some very good material, in fact— but it’s scattered about and you have to hunt for most of it.

Having said this, the one thing the Node modules all seem to share is really nicely written code. They all seem to make excellent use of white space, good variable naming conventions, and effective use of in-line comments. The objects aren’t bizarrely defined, the coding isn’t excessively cryptic, the methods aren’t overlong, and the purpose of most can be deduced without too much trouble. Once you have a good grounding in how Node works, you can discover what you need to know about how a module works just by looking at the source.

Of course, it would still be nice if Node module developers provided a little more documentation.

(I won’t even get into the odd fascination with light gray text on darker gray backgrounds that seems to be shared by so many Node developers. Pure headache inducing web design.)

The third underlying theme in the book is to focus on providing the tools so that you can build the awesome applications—not try to create awesome applications in the book to impress you with how great I am. My examples are focused, they’re simple, they’re clean, and they show how things work. That’s it. When I want to learn how to do something, I want simple, clear examples that demonstrate exactly what I need—no more, no less. I don’t want fancy and I don’t want something overly complex. I assume most folks feel the same way, and write accordingly.

I’m also not especially creative in my writing—I try to avoid the cutesy, and definitely stay away from the profound. I’m writing a book on computer technology, not Gone with the Node.

I don’t know if all of this leaves you more interested or less, but best to set expectations right from the beginning.

My editor, Simon St. Laurent, has mentioned about the possibility of releasing my book under the Early Release and/or Rough Cuts program. I hesitate doing so, because I’ve seen reviewers who have been extremely critical of a book primarily because it is Early Release and/or a Rough Cut. Seems to me that the early release programs are equivalent to firewalking: may be great when it works, but the consequences when it doesn’t can be unfortunate.

Stay tuned on this one. If I do release early, the book will probably be available in May; otherwise, July.

Now, on with the TOC:

    • Chapter 1: Node.js, Up and Running
      • Setting up a Node Development Environment
        • Installing Node on Linux
        • Partnering Node with WebMatrix on Windows 7
        • Updating Node
      • Node: Jumping In
        • Hello, World in Node
        • Hello World, from the Top
      • Asynchronous Functions and the Node Event Loop
        • Reading a File Asynchronously
        • A Closer Look at Asynchronous Program Flow
      • Summary: Why We Like Node
    • Chapter 2: Interactive Node with REPL
      • REPL: First Looks and Undefined Expressions
      • REPL’s Own Unique Hello World
      • Multiline and More Complex JavaScript
        • REPL Commands
        • REPL and rlwrap
        • Creating Your Own REPL
      • Stuff Happens. Save Often.
    • Chapter 3: The Node Core
      • Globals: Global, Process, and Buffer
        • Global
        • Process
        • Buffer
      • The Timers: setTimeout, setInterval, clearTimeout, setInterval, and clearInterval
      • Servers, Streams, and Sockets
        • TCP Sockets and Servers
        • HTTP
        • UDP/Datagram Socket
        • Streams, Pipes, and Readline
      • Child Processes
        • child_process.spawn
        • child_process.exec and child_process.execFile
        • child_process.fork
        • Running a Child Process Application in Windows>/li>
      • Domain Resolution and URL Processing
      • Utilities and a JavaScript OO Refresher
      • Events and EventEmitter
    • Chapter 4: The Node Module System
      • Loading a Module with Require and Default Paths
      • External Modules and the Node Package Manager
      • Finding Modules
        • The Colors Module: Simple is Best
        • Optimist: Another Short and Simple
        • Exploring JSDOM
        • Underscore
      • Creating Your Own Custom Module
        • Packaging an Entire Directory
        • Preparing Your Module for Publication
        • Publishing the Module
    • Chapter 5: Control Flow, Asynchronous Patterns, and Exception Handling
      • Promises, No Promises, Callbacks Instead
      • Sequential Functionality, Nested Callbacks, and Exception Handling
      • Asynchronous Patterns and Control Flow Modules
        • Step
        • Async
      • Speaking of Node Style
    • Chapter 6: Routing Traffic, Serving Files, and Middleware
      • Building a Simple Static File Server from Scratch
      • Middleware
        • Connect Basics
        • The Connect Middleware
          • connect.static
          • connect.logger
          • connect.parseCookie and connect.cookieSession<.li>
        • Creating a Connect Middleware
      • Routers
      • Proxies
    • Chapter 7: The Express Framework
      • Express: Up and Running
      • The app.js File in More Detail
      • Error Handling
      • A Closer Look at the Express/Connect Handshake
      • Routing
        • Routing Path
        • Routing and HTTP Verbs
      • Cue the MVC
    • Chapter 8: Express, Template Systems, and CSS
      • The Embedded JavaScript (EJS) Template System
        • The Basic Syntax
        • Using EJS with Node
        • Using the EJS for Node Filters
      • Using a Template System (EJS) with Express
        • Restructuring for a Multiple Object Environment
        • Routing to Static Files
        • Processing a New Object Post
        • Widgets Index and Generating a Picklist
        • Showing an Individual Object and Confirming an Object Deletion
        • Providing an Update Form and Processing a PUT Request
      • The Jade Template System
        • The Quick Nickel Tour of the Jade Syntax
        • The Use of Block and Extend to Modularize the View Templates
        • Converting the Widget Views into Jade Templates
      • Incorporating Stylus for Simplified CSS
    • Chapter 9: Structured Data with Node + Redis
      • Getting Started with Node + Redis
      • Building a Game Leaderboard
      • Creating a Message Queue
      • Adding a Stats Middleware to an Express Application
    • Chapter 10: Storing Content with MongoDB
    • Chapter 11: The Node Relational Database Bindings
    • Chapter 12: Graphics, Video, and Audio

(Notes: Creating, streaming Canvas, Working with Imagemagic, Working with image files, multipart upload with progress, livestreaming-js. How connect.static implements ranges, allowing functionality for HTML5 video to work. Discuss ranges.)

    • Chapter 13: Creating a Quick Chat with Sockets.io

(Notes: No, not everyone needs to implement a chat client, but it is the best way to demo websockets, Speaking of which, explain websockets. (socket.io does not have session info))

    • Chapter 14: Testing and Debugging Node Applications
    • Chapter 15: Security (chapter title TBD)

(Notes: connect-auth, EveryAuth, OAuth, crypto, SSL, injection attacks, hardening code, Validating (node-validator), Sandbox (vm))

    • Chapter 16: Scaling and Deploying Node Applications

Using gearman for parallel machine deployment? Benchmarking, Deploying app to one of the clouds, Possibly Azure if I can get to work, Heroku, Joyent, others, Creating and landing a module, nodemon, hook.io?)

  • Appendix A: Git and Github
  • Appendix B: Useful Resources and References
  • Appendix C: A Redis Primer
Categories
Specs

Any element can be replaced by something more relevant

Recovered from the Wayback Machine.

I only check in to the doings of the HTML WG at the W3C once a week.

Most of my time is spent on my new book, Learning Node. Frankly, Node has been a refreshing change from the smoky labyrinth which is the HTML5 spec process. I’d check in with the Working Group less often, but I still hope to provide at least some moral support for those still slogging away.

You all do realize that the battle over longdesc is still being fought, don’t you? Oh, there’s other new battles, including some interesting ones over a new path object added to the Canvas2D spec (Eh? What?), and encrypted media (very long discussion about this one), but longdesc still remains the perennial favorite.

The issue now is keeping any decision about longdesc separate from decisions being made about ARIA attributes. At least, I think this is the issue. What caught my eye today was something Sam Ruby wrote to the group:

My biggest concern is resolving ISSUE-30. By that I mean done. There
may be Formal Objections, but there won’t be new information, so at that
point this Working Group is done subject to Director approval.

Put another way, I have zero interest in a provisional decision that
would likely lead to a reopening based on new information. At the
present time, I see two potential candidates for new information. One
is the subject of issue 204. The other would be somebody putting
forward a spec for something akin to an aria-describedAt attribute.

The reason I state that is that at the present time I see wide support
for the idea of obsoleting longdesc once there is a viable and clearly
superior replacement. Note: some may not believe that a viable and
clearly superior replacement is possible. Others may not believe that
such is imminent. But I worded what I said carefully to include such
people’s opinion.

So the task we face is eliminating all alternatives.

I can agree that resolving this issue, completely, should be a goal. However, Sam demands that those who support longdesc provide a surety that there can be no better alternative in the future, and that’s just impossible. There is no surety for any component or element of the HTML5 specification. I have no doubts that, in some future time, better and improved replacements can be found for all HTML5 elements, attributes, and various and assorted sundry APIs.

(Simple elimination comes to mind as a way of improving some of the new additions.)

No other element or attribute in HTML has undergone such rigid opposition, and such rigorous support. I would feel better, much better, about HTML5 if any of the new objects, elements, and attributes received even a tenth of the inspection and discussion that has been afforded to lowly, simple little longdesc. Objects, such as Path.

And now, the gauntlet has been tossed: longdesc is our princess in the tower, the W3C the wicked sorceress, and the demand has been made that either a knight in shining armour rescue the poor damsel or she be dragon kibble.

Eliminate all alternatives to longdesc? How many years do we have, Sam?

Categories
Critters Political

Horse slaughter house in Missouri

Yes, some folks wanted to build a horse slaughterhouse here in Missouri.

Let’s just say, folks here didn’t take kindly to the idea.

The last horse slaughterhouses in the US closed several years ago, when the funding for horse slaugherhouse inspections was yanked from the USDA. Thanks to three Congressional representatives tacking an amendment on to a budget bill, the USDA funding for house slaughterhouses has been added back. Thing is, they didn’t provide any money to do the inspections. Our Congress, not at work.

For an insider look at what it means to have one of these plants in your community, check out Texas Mayor Paula Bacon Kicks some Horse Slaughter Tail. Note that there’s ongoing efforts to build a plant in Missouri, Tennessee, Oregon, and Washington.

Categories
Critters

Horse slaughter in Missouri

Not only is Missouri home to the largest number of puppy mills in the country, but there’s effort underway to open the nation’s first horse slaughterhouse here.

The infamous Sue Wallis, who has been a leading advocate for bringing horse slaughter back to this country, first introduced the idea of converting a vacant warehouse into a horse slaughter plant near Mountain Grove.

At a public meeting on the proposed plan, the Community Preservation Project’s MacPerson aggressively challenged the idea of bringing in a slaughter house. She provided a fact list about problems with the plant, and rallied strong support in opposition.

Last we’ve heard, the plans for a plant near Mountain Grove has been abandoned, rejected by the community. However, Wallis and her Missouri cohort, Mindy Patterson (of anti-Proposition B, pro-puppy mill fame) are still seeking to build one of these horrid places here in this state. Might be kind of difficult when potential investors see even more facts (PDF) provided by McPerson.

It’s really great to have a motivated lawyer on your side.

Keep up with the opposition at a Facebook page setup for the Community Preservation Project.

Categories
HTML5

If it had remained the irrelevant attribute

Recovered from the Wayback Machine.

The latest round of discussions related to longdesc (yes, still) was triggered by a revert request from Laura Carlson:

As you know the editor made changes to the hidden section [1]. This biases an open issue [2] as it directly implements a material change from a change proposal [3]. The Chairs specifically asked for justification for this change in their change proposal review [4]. If the proposal lacks justification, then the spec lacks justification.

The change redefined the meaning for the hidden attribute, from:

When specified on an element, it indicates that the element is not yet, or is no longer, relevant. User agents should not render elements that have the hidden attribute specified.
…
Elements that are not hidden should not link to or refer to elements that are hidden.
…

It would similarly be incorrect to use the ARIA aria-describedby attribute to refer to descriptions that are themselves hidden. Hiding a section means that it is not applicable or relevant to anyone at the current time, so clearly it cannot be a valid description of content the user can interact with.

To:

When specified on an element, it indicates that the element is not yet, or is no longer, directly relevant to the page’s current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user. User agents should not render elements that have the hidden attribute specified.
…
Elements that are not themselves hidden must not hyperlink to elements that are hidden. The for attributes of label and output elements that are not themselves hidden must similarly not refer to elements that are hidden. In both cases, such references would cause user confusion.

Elements and scripts may, however, refer to elements that are hidden in other contexts.
…
It would be fine, however, to use the ARIA aria-describedby attribute to refer to descriptions that are themselves hidden. While hiding the descriptions implies that they are not useful alone, they could be written in such a way that they are useful in the specific context of being referenced from the images that they describe.

Similarly, a canvas element with the hidden attribute could be used by a scripted graphics engine as an off-screen buffer, and a form control could refer to a hidden form element using its form attribute.

The change significantly redefines the meaning for the hidden attribute. Why did the editor make this change? One reason was, as Laura pointed out, bolstering a change proposal to obsolete longdesc in favor of a proposal to use aria-describedby pointing to a section marked by the hidden attribute.

This triggered two separate discussions—one related to making an edit to HTML5 specifically in favor of a change proposal currently under rather contentious debate; the second related to redefining hidden in such a way that aria-describedby would be allowed to point to it.

The revert request was successful, which now leaves the discussion about allowing aria-describedby to point to content marked with the hidden attribute, and this change’s impact, or not, on the decision to deprecate longdesc. I’m not going to get into the longdesc deprecate debate—my views on this are widely known and I’ve long been in support of keeping this attribute in the HTML spec. Instead, I want to focus on the change to hidden.

A recent post to the HTML-WG mentioned separating the aria-describedby/hidden issue into a separate survey (and there’s now an issue for it). However, I wanted to remind the HTML-WG co-chairs that they already decided this issue back in 2010.

In 2010 I made a request to remove the hidden attribute from HTML5. In the change proposal to support the request, I wrote:

The hidden attribute was once named the irrelevant attribute, supposedly because the attribute is used to mark the contents of whatever element it is attached as “irrelevant”. The attribute was renamed because, a) the irrelevant term was confusing, and b) techs misspell words like “irrelevant”.

Is the content truly irrelevant, though? Consider the definition for the attribute:

Elements in a section hidden by the hidden attribute are still active, e.g. scripts and form controls in such sections still execute and submit respectively. Only their presentation to the user changes.

“An irrelevant element is not one that is active, receiving events, participating in the web page, or form submission. The only truly irrelevant page component is one that doesn’t exist. If people want a truly irrelevant page section, they should use the DOM to create and remove the element, as needed. There is nothing about the behavior associated with removing an element from user agent rendering that is made more meaningful using a single-purposed HTML attribute, rather than using a simple combination of CSS property and ARIA attribute. Both have to do with the presentation of the element.”

Presentation with the hidden attribute isn’t an incidental purpose, it is the primary purpose of the attribute. Rather than separate presentation and structure, it firmly welds the two.

My request to remove hidden wasn’t successful, based on the strength of arguments in favor. What were these arguments? The following is the primary one, from the counter-proposal:

Authors of web documents and applications often need to temporarily hide certain content from readers and users. Via a combination of script and CSS, such functionality is possible to build today, and there are hundreds of such implementations extant on the web. It’s clear that hidden=”” Solves Real Problems. Attempting to implement such functionality with JavaScript and CSS is fundamentally more difficult and error-prone than hidden=””. hidden=”” is literally the simplest thing that could possibly work, and thus we Avoid Needless Complexity in its design. By making it as easy as possible to author, and by defining uniform UA behavior (unlike bolt-on scripts which emulate this functionality), we preserve our Priority of Constituencies. Bolt-on emulations of hidden=”” can fail to correctly hide content in a media-independent way, resulting in a degraded experience for users of aural browsers and other AT tools. hidden=”” thus promotes Accessibility more than bolt-on alternatives.

In the survey deciding the issue of keeping hidden or not, several arguments in support of keeping hidden were given.

Cynthia Shelly wrote:

The existing mechanisms all miss one case or another, and it is complicated to understand when to use one over another. The new hidden attribute covers all the cases in a way that will make it much simpler to include markup on a page that is intended as input to a script rather than output to a user.

Gregory Rosmaita wrote:

a native solution which provides the means of marking content as not yet or no longer relevant, is highly desireable; while such a feature, of course, needs to be harmonized with what ARIA offers, it MUST be remembered that aria-hidden is part of a bridging vocabulary, which provides semantics and functionalities which native markup does not provide; the hiding and exposition of content that is not yet, or is no longer, relevant should not be left to scripting or an overlay such as ARIA, but should be an organic part of HTML5.

Jonas Sicking wrote:

I object to removing the hidden attribute as it would result in missing out of the positive effects listed in http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements#Positive_…

My experience working with web authors for several years is that they tend to do what is easy, whereas accessibility often ends up coming second due to time constraints and unawareness.

By including the semantic hidden element, we both make it easier for developers to do what they want, since they can use the .hidden IDL attribute, and they automatically get the desired semantic meaning.

I think it’s very unlikely that as many people would add proper ARIA attributes, as would use the hidden attribute. I think this is the reason that the WAI-ARIA specification encourages developers of markup languages to add semantic elements and explicitly declares ARIA as a bridge technology. I also think this is why the HTML Accessibility TF has endorsed the hidden attribute.

Among the arguments was the assertion that the hidden attribute is equivalent to aria-hidden, but better because the hidden attribute was integrated into the HTML semantics, rather than be “bolted on” via ARIA. Since aria-hidden is used specifically to designate material that is not perceivable to any user, this adds weight to the interpretation of content that is marked as hidden is content that is irrelevant to all users—at least until such time the hidden attribute is removed (equivalent to setting aria-hidden to “false”).

The co-chairs agreed with those who argued in favor of keeping hidden, writing:

It seems that the hidden attribute serves a valid, broad use case. It has interest from implementors and authors.

A number of arguments were made in favor of retaining the hidden attribute. It was argued with partial success that hidden captures useful semantics. Many cited the accessibility benefits of built-in elements and attributes, including hidden. A number of other concrete benefits were cited, such as likelihood of surviving syndication. These positive arguments were in general stronger than the counter-arguments, and provided strong reasons to keep hidden.

There were also arguments made against the hidden attribute. It was argued that CSS+ARIA-based implementations of hidden-like functionality are sufficient, so no attribute is needed. Deployment costs were also cited as a concern. And the semantic nature of the attribute was cast in doubt. In general, these arguments did not overcome the counter-arguments, and are not strong reasons to remove hidden.

The maturity argument against hidden had more weight. The Working Group has in the past chosen to remove features from the draft for reasons of maturity. However, this factor was not decisive in itself, at least at this time, since the W3C Process allows further opportunities for review, implementation and feedback.

Overall, the arguments in favor of keeping hidden were stronger than the arguments for removing it. Only the maturity argument provided a strong reason for removal, and it is outweighed by the arguments in favor of keeping it.

In my opinion, the decision was not necessarily a model of clarity. However, I do believe that this 2010 decision answers the question whether aria-describedby can point to an element marked with the hidden attribute, and the answer is, No.

An attribute used to designate content that is available for scripting purposes is not the same as an attribute that is used to remove the content from visual display. Why? because one implies the same result regardless of type of browser accessing the page, while the other implies something completely the opposite.

My understanding of the decision in 2010 is that “hidden” meant that the material was irrelevant regardless of type of browser accessing the page. This is supported by the fact that at one point in time, the hidden attribute was named irrelevant. The reason the name of the attribute was changed was more one of expediency than change of semantics. The visibility of the content should make no difference on whether it is relevant or not.

As the HTML5 editor, Ian Hickson, wrote when he renamed irrelevant to hidden:

It’s not different from hiding content that isn’t necessary. That’s exactly what it is. It’s a way to hide content that isn’t currently relevant.

I challenged the hidden attribute years ago because it seemed to me it was nothing more than an elemental equivalent of display: none. However, others, including the co-chairs, disagreed with me, and agreed with the HTML5 editor: the hidden attribute had the additional semantics related to its irrelevancy.

Based on this decision two years ago, I’m at a loss to understand why the HTML5 co-chairs would consider an option to allow aria-describedby to link to this content so that it can be rendered by screen readers—in effect, to make the content in the element with the hidden attribute, relevant. Something cannot be both relevant and irrelevant at the exact same time.