BurningbirdI’m finally leaving my cave and buying a real, live smart phone.
I left the Apple world over a year ago, so I’m looking at buying an Android phone. I want one that comes with Ice Cream Sandwich. Hopefully a phone that doesn’t get stuck with one version of an OS for years and years.
Any suggestions for a phone? Any suggestions for a carrier/plan, here in the US? Anything I should be wary of?
Recovered from the Wayback Machine.
After denouncing the use of Ruby and Rails terms to describe Node and Node modules, I must now confess that I did use a Rails resource in the section on MVC in Chapter 6.
The Rails Guide has an absolutely beautifully written overview on MVC and routing, Rails Routing from the Outside In, I used as inspiration for the design of the MVC section in Chapter 6.
However, in my defense I’ll note that most of this overview really doesn’t depend on knowing either Ruby or Rails in order to benefit from the writing. It simply and easily demonstrates a mapping between HTTP verbs, routes, controller actions, and database CRUD (Create-Read-Update-Delete) probably better than anything else I’ve ever read.
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:
(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.)
(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))
(Notes: connect-auth, EveryAuth, OAuth, crypto, SSL, injection attacks, hardening code, Validating (node-validator), Sandbox (vm))
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?)
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?
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.