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?)
I just finished my fourth chapter for my newest book for O’Reilly. I never feel a book is solid and real until the fourth chapter. By the fourth chapter, you have a book, not just an idea or outline.
My newest work is titled “Learning Node”, about Node, or Node.js for the purists among you. It’s a good fit with my other JavaScript books, and is focused on an interesting and rather fun technology.
I wasn’t sure about Node when it first came out. My very first JavaScript gig wasn’t client-side development, it was a server application for a company in Portland, Oregon. I can’t remember the name of the company, or even what the application was about (I have done a lot of contract work in the last 25 years) but I remember working with a contractor from Vietnam who is one of the nicest people I have ever worked with.
I also remember that server-side development with JavaScript died quickly, and there went another skill down the toilet. So when Node came around, I didn’t embrace it as profoundly as many people did.
In time, though, Node won me over. I like it—not in the giddy, bubbling-over-with-enthusiasm embrace I may have felt about server-side JavaScript (and Java, and EJB, and the earlier Cloud computing, and DHTML), but I like it. I think it’s useful. I think it is a very solid technology.
What won me over to Node? The fact that it’s based in JavaScript helped. I’m not going to join the effete in condemning JavaScript, because I like JavaScript. I think Dart is dead on arrival, and JavaScript is only going to get better over time. However, there’s also CoffeeScript for those who just can’t embrace JavaScript.
I like that we don’t have to worry about working with threads, that modules are the norm, and that Node doesn’t pretend to be the definitive solution for every problem. I also like the community support and how uncomplicated it is to create complicated applications. I don’t want to use “easy”, but Node doesn’t demand that the developer jump through an extraordinary number of loops to get a job done. For all the new geewhiz quality about Node, it’s a very pragmatic technology.
Node is also mature enough to last—no lost skills with it. The very fact that the creator of Node, Ryan Dahl, decided to step down as gatekeeper for Node, and his decision didn’t cause any earthquakes in the Node community, attests to the maturity of both the technology and the community.
The HTML5 community could learn a lot from the Node community in this regard.
If there’s a problem with Node is that many of the those who work with Node come from a Ruby/Rails/Extreme Programming background, and many of the concepts and explanations about Node reflect assumptions that can actually form a barrier to understanding. In some ways, Node can present itself as more complex than it really is, primarily because much of the terminology reflects a background that not everyone shares.
Another problem is that documentation is an interesting mix of the nonexistent, cryptic, and/or flippant—none of which is generally helpful. Then there’s the oddly peculiar “Node web style”, with web sites in dark gray backgrounds with pale gray writing, (or white background with pale tan/green/gray writing) where the only way you can see the text is by turning up the brightness of your monitor until your head hurts.
Still, times are a changing. Cloud9’s new new Node Manual web site is a solid start in the right direction, and I have high hopes for the official Node.js site, too.
Then there’s my book, which I’m sure you’ll want—if for no other reason in that it’s a nice break from me bitching about HTML5.
If you’ve been reading my weblogs in their various incarnations since the painful beginning, you’ve read me talking about my car, Golden Girl.
Golden Girl isn’t a fancy car. It’s a 4 door 2002 Ford Focus with a Zetec engine and painted in metallic gold. It is my very first car.
No, I’m not so young. I’m just one of those who didn’t decide to drive until I was…well, older than most people when they learn to drive. I started to learn to drive in Boston, practiced cross country, and received my first driver’s license in San Francisco. I bought Golden Girl a few months later via the internet, at a time when this was still a very new idea. I test drove a Focus, but didn’t meet Golden Girl until I picked her up.
My car was my delight. I drove her from California to Missouri, and from Missouri to Idaho, and back to Missouri, and on to Florida, then Missouri, and back to California and then returning, once more, to Missouri. Once in Missouri, I visited every nook and cranny in the state—including many dark hollows posted “Do Not Trespass”, with guard dogs that look at you as if sizing up which part to bite first.
Golden Girl is no longer young. A broken strut earlier has today been joined by a cracked thermostat housing, which followed a massive amount of work last year. There’s a short in the car somewhere, most likely in the instrument cluster that causes the instruments to peg out, go to zero, and then eventually recover. One could live with hyperactive instruments but the car’s lighting also dims as the same time, which can makes things a bit interesting at night.
I take her in to be worked on more frequently than I take her in to have her oil changed. And I no longer trust her for driving outside the city. Heck, half the time I don’t trust her for driving in the city.
I can’t afford to get a new car, and I won’t buy a used car full of someone else’s problems. I have to consider that at this point I’m driving Golden Girl until she can go no further, and then hopefully some charitable organization can get a little extra good from her.
Then I’ll be as I was before I bought Golden Girl—living carless.
It’s hard to think about going without Golden Girl, though. This last decade has not always been easy, with some sad losses along the way, but I’ve always had my car.