Drupal 7 was released on 5 January 2011. The latest version of the venerable Content Management Framework (or System, if you wish) contains hundreds of changes, including a new paint job, new standard features, and lots of work under the hood. Drupal is one of those projects that is not afraid to break backwards compatibility for the sake of a more elegant and powerful system. As such, each new release of Drupal brings with it a need for new documentation. It is in this spirit that Drupal 7 Module Development from Packt Publishing was born. This book is meant to help programmers familiar with the PHP programming language to learn how to develop custom modules for Drupal 7. Packt Publishing was kind enough to send me a review copy.

The first thing I noticed about the book were its authors. There are no less than six authors for this book, and the names are ones that the Drupal community will know. This, along with the foreword by webchick herself, gives the book instant credibility to those within the community, and the list of the authors’ credits at the beginning of the book should lend an air of authority to those without. It does not disappoint.

The book’s almost 400 pages are divided up into twelve chapters, two appendices, and an index. Along the way, several small custom modules will be built, along with custom Drupal entities, fields, and even an installation profile. But the book starts at the beginning.

Thankfully, though, not the very beginning. I suspect half of the books on Perl that sit in my library start out with where to get it and how to compile it. Many Drupal books start off similarly, telling you to go to drupal.org and grab the tarball, set up a (L|W|M|X)AMP stack, and so forth. As this book is aimed at developers, not admins, we are spared those steps. Chapter One is instead a fantastic introduction to what is known as “The Drupal Way(tm)” for developers already familiar with PHP. It is an excellent introduction to Drupal 7 for developers. If I were going to get a team of programmers started with Drupal development, I’d use Ch1 as the introduction, especially if they’ve never used Drupal before. Including mentions of the devel module, coder module, and drush shows that the authors are serious about using the best tools for the job. Using the testing subsystem from the beginning, our first module in Chapter 2, is also a very good sign. Included is a rundown of Drupal’s amazing coding standards. Something that first drew me to Drupal almost ten years ago is the cleanliness of the source code, and that’s thanks to the coding standards and the ways it is enforced. The book does a good, though not perfect, job of sticking to these standards throughout the book, and that’s to be commended. Among the standards it attempts to adhere to are the Doxygen comments. Not too surprising, given the authors, but this feels like very modern Drupal development. Absent, however, is any real discussion on development environments, though I suspect here we’re assuming developers are already comfortable with something.

Chapter three could quickly lose you at first reading. It’s a dense discussion of the theme system, which at first might seem out of place in a developer’s text. If you thought Drupal 6’s theme system was an onion, wait until you see the layers in Drupal 7’s Theme API. The examples are fine, but to me there are more details here than necessary. We’ll be told several times to “see the API site for more details” later in the book, and some of that glossing over would be welcome here.

The main problem with Chapter three is that it’s all just a setup for Chapter 4, sort of an “I told you that story to tell you this one” deal. We’ll theme our module, using some, but no where near all, of the layers we learned about in Chapter 3. They perhaps could have been thinned and combined, but it’s still nicely done.

Chapter four contains my favorite quote in the book, talking about making an API instead of burying your logic in hooks:

Remember, be lazy. If your module’s API is good enough, some other developer will write the code to integrate your module with theirs.

So we’re a third of the way through the book before “it” rears it’s ugly head. In chapter five we see it — the Form API, Drupal’s most complex subsystem. The introduction to it is a good one, building an administration form, one of the more simpler uses for FormAPI. It’s an excellent way to start dealing with all the nuance and power in the arrays. Sitting in my rocking chair with my pipe, pausing to yell at the kids on my lawn, I could tell you of days before there was a FormAPI, and there’s little doubt that this is better. Still, it’s complicated, but the authors here do a good job of getting you into it. We’ve seen and have been warned about Drupal’s love for the structured array all through the first few chapters, and here’s where it really hits hard. Again, the examples are clear and worthwhile, and do delve into the majority of what a developer will need to know.

On the other hand, Chapter six deals with something completely new to Drupal 7, the ability to create “entities” that are not nodes. While there is no doubt this is an incredibly powerful new subsystem, allowing you to leverage Drupal for all sorts of things which can turn Drupal into “Anything” Management instead of “Content” Management, it seems to me that we’re going down this road just because we can. That’s necessary in a book concerned solely with development, I suppose. Perhaps I’ve just got old-Drupal-guy syndrome, but I would have liked a good explanation why we’re building our own entities instead of overloading the node system, something we do in Drupal 6 all the time.

I think I would have liked better the treatment of Chapter 7 before 6. In chapter seven, we’ll go through hanging fields off of our entities. This could have used the node system for this, and then we could have talked about creating new entities that inherit this ‘fieldability.’ In seven, we’ll even create our own field types, and, while it’s implied that nodes can take advantage of this, I fear that new developers will see chapters six and seven as The Way things are done, instead of the new entities being presented as a way to better allow Drupal 7 to fit in places where Drupal 6 needed some shoehorning.

Philosophy aside, these continue to be well-written, with useful examples, and nice treatments of leveraging Drupal’s built-in functionality to create robust types of content with custom code. In contrast to the “why do this?” feeling I had in Chapter 6, Chapter 7 presents a very clear reason why we’re diving into creating our own field type instead of repurposing existing types for our cause. I would have loved to see the same reasoning given for not using a node as the basis for our custom data types in the previous chapter.

While I appreciate the effort taken to define some viewing queries for our new data types, Chapter 7 should, I think, instead go into programmatically creating views via the Views API. Yes, this is a “third-party” module, but in name only. No Drupal site worthy of the name will run without views.module within the last three years or so. It’s a good time to talk about it, but it just slips by without a mention.

Chapters 8 and 9 are examples of very fine, clear, and concise technical writing. A good overview of the permissions system, great introduction to the new and updated hooks, and well-done examples of where to deviate from the easy and standard to the harder and custom. Among the highlights of chapter 8 is a discussion of what FormAPI does to increase the security of Drupal forms. In nine we get to the node access system, and it’s dealt with through useful examples, good discussion of what’s happening behind the scenes, and excellent points to consider when leveraging this powerful, and potentially tricky, API.

The low point of the book for me was Chapter 10. It is a glossing over of the Javascript and AJAX available in Drupal. While a full treatment of the subject is quite literally a book all its own, this chapter may make too many assumptions about what a PHP programmer might know about JS/AJAX, or even what to do with it. I would have liked this chapter to be fleshed out quite a bit more. I found the examples given to be silly and without any practicality. For example, in keeping with the “Artwork” content type examples used earlier, it would have been interesting to add a bit of ajax validation to the form for our “dimensions” field, alerting us when we have, for example, left our field without all the dimensions defined. Such browser-side validations are good UI and some examples here would have been quite helpful, both in continuing what earlier chapters started, and in showing real-world uses for the powerful subsystems we’re talking about. Alas, no treatment of the subject exists.

In Chapter 11 the FileAPI and ImageAPI systems are given a light workout, showing small but useful examples of how to leverage the systems that before were relegated to contributed modules. We even get into a tiny bit of GD programming as we add a watermark to images. Again, it’s light, and perhaps could have been fleshed out some more, though the examples given are good.

The final chapter of the book deals with installation profiles. While at first it may seem that would be a discussion best left for site and system administrators, there are actually quite a few places where we can add code to customize the installation, and it’s nicely done in the example profile.

The first appendix deals with the new database subsystem, as Drupal now relies on a heavily wrapped PDO. It’s obvious, to a fault I think, that this information was part of Chapter six and was later spun off into the appendix. There is a fair bit of good information in here on writing queries the new way, and it’s most welcome. I would have liked to see the appendix and Chapter six switch roles — a whole chapter on the new db stuff, and an appendix on the new entity system.

Appendix B is little more than a pamphlet on web programming security in general and Drupal programming security in particular. It’s a nice but very sparse treatment on a big and important topic. Again, this is a topic that literally has its own book, but still I wanted more.

What the book gets right

The answer to that is almost everything. This book will serve as a tremendously helpful introduction to Drupal programming for programmers. It does assume you know PHP, and warns you (or comforts you, depending) early on that there won’t be much OOP here and there will be a lot of structured arrays. The chapters don’t necessarily follow in order one to the next, and aren’t explicitly linked one with another.

For programmers new to Drupal chapter one should be required reading. And while occasionally the book slips into “what’s new” mode, for the most part the reader is considered a competent PHP coder but not necessarily someone fluent in Drupal programming.

The examples given throughout are mostly useful. One thing I hate about programming texts is when they show what the language/system can do with ridiculous examples. With the glaring exception of the Javascript chapter, this book does not stoop to such levels, instead giving real-world problems solved through the Drupal API.

The style of the book is nicely conversational. The overt humor is sparse, but at the same time you don’t ever feel that you’re sitting in a lecture hall. The authors seem quite well-versed in the material and aren’t subjecting you to death-by-powerpoint-by-screenshot. They don’t talk down to you, ever, guiding the reader through the API as a comrade. Even in the areas of security and best practice, when it would be easy to slip into browbeat mode, they resist, presenting facts instead of opinion and advice rather than orders.

What the book gets wrong

The main problem I had with this book is that I feel there are parts missing. The book begins talking about how we’ll use modern techniques, and mentions Drush, the Drupal shell, one of my favorite tools. And that’s the last we’ll here of it. Seriously. Even when the installation profile chapter says we can use profiles at the command line, we end up writing a command line PHP script instead of leveraging Drush. An oversight in the editing, perhaps, to mention it at all?

Also absent any real treatment is contributing rather than simply developing. A “10 minute git tutorial” appendix wouldn’t have been out of line. There’s no mention of how to be a good module maintainer, dealing with releases, submitting your module to drupal.org, or any such thing. While that’s not necessarily within scope, such a discussion is noticeable in its absence, particularly when the community is perhaps the strongest thing about Drupal. Given the status of the authors as top-tier contributors, it’s a curious omission.

There are some nitpicks, some spelling errors, wrong screenshots, and discussions of things (ie., drush) that just aren’t there. No more, perhaps, than any other book of its size, and nothing that was too glaring or anything that would stop one in their tracks. We do occasionally slide away from coding standards (eg, after singing the praises of Doxygen comments earlier in the book, chapter seven contains no code comments at all), but it’s nothing too big.

Final thoughts

I was very happy to read through this book. It’s well written by competent authors. It gets me excited to write some custom code of my own for Drupal 7. While there’s not too much that will serve as a desk reference within the book (the authors are quick to point us to api.drupal.org, early and often), Drupal 7 Module Development is a worthy addition to the shelf and serves as a wonderful introduction to coding for Drupal.

You say there is a God
Above the boundless sky,
A wise and wondrous deity
Whose strength none can defy.

You say that he is seated
Upon a throne most grand,
Millions of angels at his beck—
Why don’t he lend a hand?

See how the earth is moaning,
What countless tears are shed,
See how the plague stalks forward
And brave and sweet lie dead.

Homes burn and hearts are breaking,
Grim murder stains the land;
You say he is omnipotent—
Why don’t he lend a hand?

Behold, injustice conquers;
Pain curses every hour;
The good and true and beautiful
Are trampled like the flower.

You say he is our father,
That what he wills doth stand;
If he is thus almighty
Why don’t he tend a hand?

What is this monarch doing
Upon his golden throne,
To right the wrong stupendous,
Give joy instead of moan?

With his resistless majesty,
Each force at his command,
Each law his own creation—
Why don’t he lend a hand?

Alas! I fear he’s sleeping,
Or is himself a dream,
A bubble on thought’s ocean,
Our fancy’s fading gleam.

We look in vain to find him
Upon his throne so grand,
Then turn your vision earthward—
‘Tis we must lend a hand.

‘Tis we must grasp the lightning.
And plow the rugged soil;
‘Tis we must beat back suffering,
And plague and murder foil;

‘Tis we must build the paradise
And bravely right the wrong;
The god above us faileth,
The god within is strong.

— Samuel Porter Putnam

/via lukeprog at Common Sense Atheism

The programming days of my work life are taken up by a major grants/accounts lifecycle Drupal application. This is a rewrite of a 10 year old Microsoft Access database+forms. It’s massive, it’s interesting, and I’m doing lots of things with Drupal that I have never done before, and some that until I got in to it I wasn’t even sure it was possible.

This week’s task (I get two days a week, usually less, to work on this) has been to implement defaults for some fields, based on a node reference. The main node type on this site is an ‘account,’ which is attached to a bunch of other node types via reference. One of these types is a ‘sponsor,’ basically a granting institution. These accounts include administrative, technical, and billing contact information. While these are per account, for a lot of sponsors they are per sponsor, meaning that they won’t change for each account that is attached to the same sponsor. But, it’s not always the case.

And it’s the “it’s not always the case” that has led to this task. Each sponsor will have default contact information, which should be copied in to the account. For many accounts, that’s fine. But for some, these contacts will have to be edited. So what we want is, when the user picks the sponsor (a nodereference) for the account (colloquially called a “card”), the contact information gets pre-filled from the defaults listed in the selected sponsor node.

I should add at this point that it’s very possible, likely, even, that I’m going about this in the wrong way. Please feel free to contact me and tell me how stupid I am and point me to the module that does this in a more elegant manner.

After looking at the #ahah properties that are part of FormAPI, I couldn’t figure out how best to adjust form values. The #ahah properties seem to be geared towards adding fields and manipulating divs by using wrappers and such. I’m sure there’s a way this could be shoehorned in to what I was trying to do, but I determined that it would just be too complicated and would feel too much like a hack.

Which leaves jQuery. jQuery’s part of Drupal, which has led to some great UI innovations and lots of cool functionality. And jQuery is opened up to Drupal in wonderful ways through the Drupal javascript object. I’m not a JavaScript or jQuery programmer, but I have dabbled a bit. So I decided that a jQuery-based solution would be the route I would take for this task.

First, here’s what the UI looks (just a placeholder theme in place at this point — don’t get excited):

The sponsor node where the “defaults” are put in:

And here’s the relevant portion of the card, where the pre-filling will take place:

So the card has a nodereference type pointing into the sponsors. There are multiple sponsors; the first sponsor is where the contacts will come from. The nodereference field is an autocomplete textfield that pops up a list of eligible sponsors and allows the user to pick one. The goal is that, once one has been picked, that the defaults would be looked up from that sponsor and the rest of the fields populated from that data.

The key part of this is getting the data out. If you ever develop for Drupal and find yourself with a task that can be stated like “What I need is to be able to construct a query…” your mind should immediately turn to Views.

So much has been written about the incredible Views module, the versatile query builder from super-smart nice guy Earl Miles (@merlinofchaos). I’m not going to go in to a discussion of what Views is here, except to say that Drupal without Views is little more than a well constructed blogging platform. With Views, it’s a powerful tool for quickly writing versatile web applications.

Views could build the query for me, of course. It’s a very simple view in fact: “Gimme these fields from a sponsor node with nid of x.” A few fields, and an argument for nid. But how could jQuery handle this data?

Everyone that said “JSON” gets a point. Part of what makes Views so completely awesome is the system of plugins that orbits around it. Views can be adapted with other code to output in a variety of formats. The “views_datasource” suite of modules allows Views to output in a variety of microformats, including XML, RDF, and, yes, JSON. A views “page” that is available at a URL and outputs JSON is exactly what jQuery would like to work with, and perfectly fits this use case.

So all things are now ready: We’ve got the nodes and fields defined, a view to get the data from one node, and a clear idea of the task. All that’s left is to write the code.

The module for this is exceedingly simple. All we really need the PHP to do is to add the Javascript to the appropriate form. This is just a hook_form_alter(), calling drupal_add_js(). The meat of the module, then, is just:

function cards_ahah_form_alter(&$form, &$form_state, $form_id) {
  if ($form_id == 'account_node_form') { // here we are
    drupal_add_js(drupal_get_path('module', 'cards_ahah') .'/sponsorajaxhelper.js');
  }
} // endfunction cards_ahah_form_alter

Yeah, really, that’s it. Yes, I’m calling the module “cards_ahah” — that’s just historical, from earlier attempts, but it sort of fits. So the bulk of the work will be in the referenced Javascript file, sponsorajaxhelper.js, which will be attached to only the edit form for new accounts (cards).

The tasks the Javascript will need to complete are:

1. Find the node referenced by the sponsor field.
2. Grab the JSON from the view, referencing that sponsor’s nid.
3. Go through the fields for the contacts, setting the value of each element to the appropriate value from the JSON.

Step two is easily handled by a call to jQuery.getJSON(). The third by a series of calls to $().attr(). The first requires just a touch more work.

While we can get the value of the field by calling $().attr('value'), it’s not the nid that we need for the view. That is, it’s not only the nid. It actually looks like “Sponsor [nid:44].” The nid is in there, it’s just surrounded.

Stand back, I know regular expressions! So a call to $().attr('value').match() can grab it.

Attach that to $().blur(), and we’ve got our solution. Here, then, is what the jQuery code looks like:

Drupal.behaviors.sponsorhelper = function () {
  $("input[name='field_sponsor[0][nid][nid]']")
    .blur(function() {
      nidRegEx = /\[nid:(\d+)\]/;
      SponsorHelper.fill($(this).attr('value').match(nidRegEx)[1]);
    })
};

SponsorHelper.fill = function(nid) {
  var url = Drupal.settings.basePath +
      'sponsorajaxhelper/' + nid;
  jQuery.getJSON(url, function (data, result) {
    if (result != 'success') {
      return;
    }
    $("input[name='field_admincontact[0][value]']").attr('value',data.nodes[0].node.field_admincontact_value);
    $("input[name='field_adminphone[0][value]']").attr('value',data.nodes[0].node.field_adminphone_value);

(and a lot more of these, filling in the fields)

So, let’s go through that script in a little more detail.

Our call to Drupal.behaviors.sponsorhelper sets up our helper function. In our case, we’re attaching the SponsorHelper.fill() function to the blur event on the first sponsor’s text field. Which is to say, when the user clicks away from the sponsor’s field, we go. We need to pass the nid to the function, which is what the nidRegEx does, along with the call to $().attr('value').match()[1], grabbing the digits out of the regex.

Our SponsorHelper.fill() function first sets up the url that we’ll go to to get the JSON data. This is the page that the view exposes, ‘sponsorajaxhelper plus the nid. The call to jQuery.getJSON() runs the view, with the nid argument, as specified in the URL. What we get back, if we get anything back, will be a “nodes” object inside the data variable.

From there, it’s just a bunch of calls to $().attr() to set the other fields based on the returned data.

What could be simpler? (rhetorical)

This was actually a very interesting task. I’d not messed with jQuery very much, and certainly not tried to integrate it within Drupal to the point this requires. It ends up working very well — I can have defaults stored in the sponsor node, they get copied but are yet fully editable in the account node, where they’re properly stored. Sponsors where the defaults are good enough are completely filled in by simply selecting the sponsor. Those that need editing have sensible defaults.

Again, you Drupalers that are reading this have probably thrown up a few times during this discussion, and can’t believe that I’m doing this in such an incredibly wrong way. Again, please contact me and set me straight. I’ve got a few hours invested in learning this, but I’m very eager to see that this is horribly wrong and that there are lots of better ways to do this.

OK, so someone is wrong on the Internet. At least, my idea of wrong.

A lot of my Facebook “friends” (oh how Facebook has overloaded that word) are Christian. I am very much not. For the most part we live in a sort of standoff, an India-Pakistan kind of thing — each of us posting rarely things that rile up the other, but not engaging in all out Global Thermonuclear War.

And I do not post original content to Facebook, anyway, disagreeing strongly with their terms of service. So, on the occasion I feel the need to rant, it happens other places. Tonight, it’s happening here.

So, this post appears in my stream from an old acquaintance of mine:

For those of you who don’t believe in God please explain the beauty of this day. It is already 70 at 10am and it’s only April 3rd. Global warming you say? How can that be? That was your reasoning for all the snow. You can’t have it both ways. I surely hope when you are sitting in the firey pits of Hell the Lord doesn’t…

Now, I highly doubt she’s aiming this directly at me, but it’s hitting pretty close by. Hard to leave alone.

First of all, the easy, quick, snarky answer: I can’t explain the beauty of this day any more than you can. We actually have the same answer: “something greater than my understanding must be responsible for it.” It’s just that the “something” we speak of are on polar opposites of evidence, logic, and reason. That, and I just don’t know meteorology as well as I’d like.

Bonus snark: fiery* :)

Well and good, but there’s a whole lot more here, isn’t there?

I suspect that even the most informed climate scientists would have trouble explaining the weather here. After a very snowy and downright brutal Winter we are enjoying far above average temperatures this week. It’s an anomaly, for sure, and it’s probably no more than that. I’m ready to write off our several feet of snow as an anomaly, as well. “Goddidit” doesn’t factor in to it, because it doesn’t need to. Something as complicated and chaotic as weather is a bad place to try and stake your claim to your own particular notion of a god. This is known as the argument from ignorance: since we don’t know what causes something, it must come from something inexplicable, in this case, supernatural. It’s just unnecessary, that’s all. Why can’t we just not know something?

This is a slippery slope, a sort of “God of the Gaps” argument, where your particular supernatural being exists to explain the unexplained. “I don’t know, so hallelujah, and pass the collection plate.” Using this reasoning, your god used to be the explanation for many more incidents than it is now. As science closes in on questions, your particular notion of a god is pushed out. Advancement of science and technology leads to a smaller and smaller deity, and, perhaps eventually, the complete shutting out of your god. So perhaps here’s not the best place to take your stand.

No climate change scientist worth his degrees (oh, look, a bad pun. how unusual) would claim that this unseasonably warm few days is due to global warming. That’s a ridiculous claim to make, and I’ve not heard anyone actually making that claim. Neither did climate scientists claim that the particularly snowy Winter was due to climate change.

What scientists did claim, however, is that current climate change models predict more extreme seasonal weather, more and stronger storms. If you like, less Spring and Autumn, more Summer and Winter. Yes, the past few months seem to support that model. But that in no way means that anyone is claiming that the snow and current hot streak are due to global warming. That’s the logical fallacy known as lying. Or, at the very least, if you do find some kook directly claiming that, a faulty generalization. Just because evidence seems to support a claim, does in no way mean the claim is true. All it means is that the evidence supports the claim; nothing more.

And, “can’t have it both ways?” why not? I’ll not argue that that is what climate change scientists are doing here, because that is not what they are doing here, but it’s perfectly reasonable to claim the same set of circumstances can lead to differing, even almost opposite, results. In fact, that’s exactly what the models predict. However, to emphasize, that is not the claim being made by the scientific consensus. It’s the claim that you’re attributing to no one in particular. If you can point to specific people, that’d be fine, but again I do not believe that this claim is supported by consensus.

Global climate change (“global warming” is a poor term, and does not accurately describe the hypothesis) is misunderstood by many because, like the weather itself, it is incredibly complex. While it is easy to chop it up in to black and white, right and wrong, climate change is much more intricate and interesting. As is everything in nature and science, for that matter. Nuance exists where we’d like to see hard lines. It’s just the way our world works. We don’t do well when there are no hard and fast rules, but that’s just tough. I struggle with it myself. The world is not black and white. It is many shades of grey.

As to the last sentence, I’m having a hard time even parsing it. I suppose you’d like your particular notion of a god not to be nuanced when passing some sort of judgement. God is Hate, I guess. As for me, I like my chances. I cannot say your god does not exist anymore than I can say any other god exists. But the opposite is also true: I have no more evidence for the existence of your god than any other. Zeus is just as real as your Christian god to me, and just as imaginary. As Stephen Roberts puts it, “when you understand why you reject all other gods, you will understand why I reject yours.” You should hope that Zeus doesn’t send you to Tartarus. What? Don’t believe in Zeus? Now you know how I feel. There’s just as much evidence for all that nonsense as all your, ahem, nonsense.

I remain “agnostic” however, and not all-out “atheistic.” I don’t completely reject the concept that there could be some being outside of what is supported by evidence, and am quite willing to change my mind should something compelling and testable and falsifiable ever be discovered. I just don’t think it’s an interesting question. All of our species’ work into logic, evidence, and reason has given us science, which to me is the greatest tool we have for coming up with an estimate of what is true. I don’t find the need to believe in a supernatural being, because I see no need to even have a supernatural being. Sure, there are things we don’t know, as there have always been. As humans progress through the ages, that list of things we don’t know gets smaller and smaller, and not once has something been crossed off the list because of a supernatural entity interfering with what we know and learn and experience. That it may, one day, is what keeps me from being completely atheistic, but I just don’t see the question as being all that interesting. I really don’t care if there are any gods or not. And I certainly don’t see any need to worship something that doesn’t seem to meddle in our known universe.

So, to sum up, why are we having such brilliant weather just a few weeks after such horrible weather? I don’t know, and you don’t either. Which is why you’re resorting to some super duper magic man in the sky and his zombie stepchild. Fine by me. “Goddidit” can be your excuse, but I’m not buying it; it’s not necessary.

Some quick thoughts after the Stevenote where the iPad was introduced:

• The lack of multitasking doesn’t really bother me. There are times I miss it on the iPhone, but full-screen apps should be full-processor apps. My problem with no multitasking is with apps that don’t resume. That’s a failure with the app, to me, not the OS.

• 1024×768 on a 9.7” screen is a great resolution, but it’s not 16:9 HD. Apple missed an opportunity, I think. Even TV out isn’t HD.

• That said, this will be an amazing device to watch TV and movies on.

• A $499 price point is perfect, I think. I don’t need 3G on a device like this, and I’m glad it’s a option. For those that do, the unlocked-ness and contract-less-ness is also a very good idea. That price point puts it at the high end of the netbook range, which is exactly where this machine should compete.

• The device appears to be running iPhone OS 3.2, not the 4.0 that I was hoping for. But that does seem to indicate a bump for the iPhone soon.

• iBooks could mean the death of the Kindle. The fact that it’s using ePub is a win for all of us (many Project Gutenberg titles are ePub right now). ePub is an extensible format, so I’m thinking that Apple must have added some DRM on top of it, not unlike what they did with MP4 and AAC.

• iPad is a horrible name. Just horrible. It does reflect, though, just how close this is to an iPod Touch. I really hate that my laptop is a “MacBook Pro,” too. Also a horrible name.

• Just like with the iPhone/iPT, it’s the SDK that’s going to make this thing. Apps using the big screen are going to be really something. So much could be done with all that extra real estate.

• iWork on the iPad was the real surprise here. The interface is very intriguing, not so much for those apps, but for apps going forward. It’s obvious with this that Apple wants to take their OS, at least a version of it, into the single-app full-screen future.

• The other surprise, and a very pleasant one, is the keyboard dock that’s available. It’s no thin client, but it’s certainly a very thin PC.

Pinch/Zoom on the home screen. The app pages could be zoomable via a pinch motion, that would allow easier organization, and more icons on the screen.

Sorting of apps on the home screen. “Genius” could sort (when invoked. Not automatically.) by app usage, so apps used the most appear on the first screens. Sort by name. By date downloaded. By App Store category. Even by “set” which could save and recall groupings of apps together. Even a flyout folder similar to OS X’s Dock stacks for grouping apps together.

Notifications. I like TUAW’s idea of a notifications screen that is available via vertical swipe from any page on the home screen. A notifications app could be an alternative interface to that screen, with its own badges, and the app could allow for filtering push notifications, or suppressing push notifications to a badge on the notifications app (plus the app that actually triggered the notification). Apps will need to be rewritten to support this feature. The notifications screen would have Growl-like bubbles showing the app and a line or two of the message. A tap would open the app, or, at the app’s discretion, even allow a the bubble to expand to a larger preview. And some new notifications: Alerts from the Weather app, upcoming calendar events, App Store updates. Allow frameworks like OpenFeint or Plus+ to hook into notifications as well.

More refined notes app. Take a look at the Newton’s notepad app. Categories, support for free-form drawing and shapes (make something close to a triangle and it will snap to a triangle), customizable “stationary,” even mini-fields that turned it into a flat field database. Not anything to challenge Bento, but more structure than just a free form list. Also look at Notational Velocity, a wonderful, very simple app for Mac OS X in which you search for notes and create notes at the same time — the search bar turns into a title field once the search string fails to hit on an existing note. Simple, elegant, clever, and very useful on a iPhone-sized UI.

More refined Weather app. In addition to a live icon (the fact that this isn’t already the case borders on a bug), the Weather app should use GPS to get the weather for the current location automatically, include radar maps, and have notifications for severe weather alerts.

Wifi/Bluetooth syncing. Along with iTunes 10, the iPhone should allow for “mini” syncing over Bluetooth (updating IMAP/calendar data, play count for media files, pushes) or full syncing over WiFi.

Bluetooth Mac remote. Basically the features of the excellent TouchPad app, over Bluetooth.

Better support for A2DP. Those of us with advanced Bluetooth headsets, as well as Ford Sync users, demand it.

More informative lock screen. I don’t think we need to go full widgets, but would a “live” calendar and GPS-based weather display really kill you? Or a few lines from the Notifications app?

Integrated web search; open search API. One thing Palm’s WebOS gets really right. Start a phone-wide search. When there are no hits from the internal database, make the assumption that the search should go to the web and offer choices for the search provider. Google and Wikipedia are good starts, Bing and Wolfram|Alpha would be very nice too. Allow app developers to hook in to this, so (say) IMDB could add their search to the list. Searches added by apps open up in the app rather than Safari. Allow a preference pane (or even a dedicated search app) to allow the user to filter and order the search engines. Also, apps could make their own databases available to search.

Desktop display mode/app. The iPhone should be have a mode or app that activates when the iPhone is docked and oriented landscape. This could be a desktop calendar, showing a monthly calendar on half the display plus notifications or day calendar, just a digital clock, only notifications, currently playing track with controls, etc. There should also be a night clock mode, with a dark digital clock display.

Full suspend/resume. If multitasking isn’t an option (and I tend to agree that the UI to make this truly simple and elegant isn’t there yet), it can be easily simulated by full support for dumping application RAM into storage and doing a complete restore when the app is resumed. For 3GS and 4th gen hardware, there’s probably enough RAM to keep the last app in RAM without having to dump it to storage, making it even faster. But suspended apps don’t get any CPU time, keeping battery life high.

Integrated chat & SMS messaging. The WebOS can seamlessly move a conversation back and forth between GTalk and SMS. It seems simple enough: contacts have both a chat name and a SMS phone number. The threaded, bubbled, iChatty interface for SMS messages could be extended to switch to Google Talk or AIM if desired.

This site is beginning to gather dust as I am unsure where I should go with it. In the meantime, commenting is disabled.

Steelers at Browns (+10)

PIT look to be done (which makes me all warm and fuzzy). Brownies aren’t that good. The Steelers need the win to stay on life support, they’ll get it and cover.

Saints at Falcons (+10.5)

We’ve still got two undefeated teams in the NFL, and the Saints are the more impressive of the two. The Falcons’ run looks to have lasted just one year. Saints win and cover.

Bills at Chiefs (+1)

Ahh, Arrowhead. No one wants to play there, even, it seems, the Chiefs. But I think the Bills are worse. Chiefs in a straight up win.

Dolphins (+1) at Jaguars

The Dolphins are looking to stay in the hunt, and they could make a statement by beating the Jags in Jax. And I think they’ll do it. Dolphins, straight up.

Seahawks (+6) at Texans

Not sure anyone will see this game, but I think the Texans win, and the Seahawks cover.

Panthers (+13.5) at Patriots

The Panthers are out of the race, and New England needs to keep pace with the Dolphins on their heels in the division. But is 14 too many? Not for me. Patriots win and cover.

Packers at Bears (+3)

I love to watch these old rivalry games, but they’re hard to pick. The Pack looks to be in the playoffs, and the Bears are lousy. So, I’ll take the Packers to win and cover.

Broncos (+7) at Colts

Sigh. You know the drill by now. Broncos straight up and without explanation.

Lions (+13.5) at Ravens

The Ravens need wins and help to make the post season. They’ll get the win, but the Lions will cover that spread.

Bengals (+6.5) at Vikings

An amazing season for Cincinnati this year, and their schedule hasn’t been a cakewalk. They get the old Favre and his band of renown this week, and it’s a let down game for the Bengals. Vikings win and cover.

Jets at Buccaneers (+3)

They make you play the whole season, whether you’re relevant or not. Jets win and cover.

Redskins at Raiders (+1)

Lots of junk games as the playoff picture begins to focus. The Redskins seem to find ways to lose, and the Raiders look inspired by the QB change. The result: Raiders, straight up.

Rams (+13) at Titans

The Titans took a step back from their playoff run last week, and are now in trouble. An easy win against the Rams should do it. Thirteen doesn’t scare me, Titans win and cover.

Chargers (+3) at Cowboys

As a Broncos fan, I want to see San Diego fail in a big way. But playing Dallas isn’t going to do it. Chargers, straight up.

Eagles (+1) at Giants

Big time playoff implications here in this matchup, that has brought us some wonderful games in years past. Here’s another, Giants win and cover.

Cardinals at 49ers (+3.5)

The Cardinals will clinch a berth in the post season with a win. Losing Super Bowl teams don’t always do that. But the Cardinals play in a truly awful division. The Niners catch them napping, but they still win. Cardinals win but 49ers cover.

Jets at Bills (+3.5)

Kind of a junk game for Thursday night. I’ll take the Jets win but the Bills to cover. Results: Jets 19, Bills 13 (L, W)

Eagles at Falcons (+5.5)

The honeymoon is over in Atlanta. The Eagles need to make their move. So I’ll take the Eagles. Results: Eagles 34, Falcons 7 (W, W)

Lions (+13) at Bengals

The Bengals are impressive, but this is a big line. Too much? Yeah, I think so. Cincinnati wins, but the Lions cover. Results: Lions 13, Bengals 23 (W, W)

Broncos at Chiefs (+4.5)

Hate going to Arrowhead in December. Doesn’t matter, though, as I am a blind fanboy. Give me the Broncos. Results: Broncos 44, Chiefs 13 (W, W)

Buccaneers (+6) at Panthers

We’re still not sure what the Panthers are, but a divisional game and a slowly improving Bucs team spells trouble. Panthers win, Buccaneers cover. Results: Buccaneers 6, Panthers 16 (L, W)

Raiders (+14.5) at Steelers

The Steelers are reeling, and need to right the ship to stay in the race. Home against the Raiders will do nicely. I like the Steelers big. Results: Raiders 27, Steelers 24 (L, L)

Rams (+9.5) at Bears

The Bears are bad. The Rams are worse. But they’re not 10 points worse. While the Bears win, the Rams cover. Like, 6-3. Results: Rams 9, Bears 17 (W, W)

Titans (+6.5) at Colts

The Titans always play the Colts tough, and they’ve done a complete turnaround. So, is it time for the Colts to lose? Yes, says I. My upset of the week is the Titans straight up. Results: Titans 17, Colts 27 (L, L)

Patriots at Dolphins (+3.5)

The Patriots are ramping up the war machine, and the Dolphins get caught in it. Give me the Patriots by 4 or more. Results: Patriots 21, Dolphins 22 (L, L)

Saints at Redskins (+9.5)

The Redskins started poorly, and now their schedule toughens up. Too bad for Washington. Saints roll. Results: Saints 33, Redskins 30 (L, W)

Chargers at Browns (+13)

The Brownies are the laughing stock of the league this year. While SD is coming east, typically trouble, it’s a late game, so it’s not that big of a deal. Chargers by two touchdowns or more. Results: Chargers 30, Browns 23 (L, W)

49ers (+1) at Seahawks

The Niners are an up and down team, but that doesn’t matter since they’re playing Seattle, which is just down. Give me the 49ers straight up. Results: 49ers 17, Seahawks 20 (L, L)

Vikings at Cardinals (+4)

Can Arizona match the Vikings in what should be a shootout? I don’t see it. I’ll take the Vikings. Results: Vikings 17, Cardinals 30 (L, L)

Ravens (+3) at Packers

Since Baltimore plays on Monday night, they’ll already know what the teams above them in the Wild Card race did. This gives them added motivation. Ravens, straight up. Results: Ravens 14, Packers 27 (L, L)

A better week last week: 8-8 vs. spread, 11-5 straight up.

Packers at Lions (+12)

Giving twelve points at home? The Lions played well last week. The short week gives them momentum; that line is way too high. Packers win, Lions cover. Results: Packers 34, Lions 12 (L, W)

Raiders (+13.5) at Cowboys

Another double digit line, and another line that’s too high. The Cowboys offense has been anemic of late, and the Raiders have found a non-loser QB. While I think the Cowboys will win, it’ll be less than two touchdowns difference. Gimme the Raiders. Results: Raiders 7, Cowboys 24 (L, W)

Giants at Broncos (+6)

As a blind Broncos fan, there’s no pithy analysis here. Just give me the Broncos straight up, m-kay? Results: Giants 6, Broncos 26 (W, W)

Dolphins at Bills (+3.5)

The Dolphins are quietly making a bid for the playoffs. It continues this week; I’ll take the Dolphins. Results: Dolphins 14, Buffalo 31 (L, L)

Browns (+14) at Bengals

The Bengals lost a heartbreaker last week, and I think it’s the start of a mini-slide. They’ll underperform, but still win the game. Browns cover, though I’m tempted to push and say the Bengals win by exactly 14. Results: Browns 7, Bengals 16 (W, W)

Panthers (+3) at Jets

This one is hard. Two underperforming QBs and overall lackluster teams. But I’ll take the Panthers straight up in the upset. Results: Panthers 6, Jets 17 (L, L)

Seahawks at Rams (+3)

Hey, a junk game not on Thanksgiving. If anyone cares, I’ll take the Seahawks by more than 3, though again a push might be in order. Results: Seahawks 27, Rams 17 (W, W)

Redskins (+9) at Eagles

You’ve got to love the NFCE matchups. It’s one of those situations where the relative success of the teams doesn’t really matter. And, I think, in this game, we’re going to see it. I’m actually going to take the Redskins this week, straight up, in my what-the-hell-is-he-thinking special of the week. Results: Redskins 24, Eagles 27 (W, L)

Colts at Texans (+3.5)

The Colts are undefeated, but it seems every week they’re in a tight one. It happens again this week. Colts win, Texans cover. Results: Colts 35, Texans 27 (L, W)

Chiefs (+13.5) at Chargers

The Chiefs pulled the big upset last week, so are they playing with any more confidence? Sure they are. But their hopes are dashed, and the Chargers continue to roll, winning by at least two touchdowns. Results: Chiefs 14, Chargers 43 (W, W)

Jaguars (+3) at 49ers

I believe in the 49ers, but they’re still a few years away. Jax, on the other hand, I have no idea about. I’ll take the 49ers. Results: Jaguars 3, 49ers 20 (W, W)

Cardinals (+3) at Titans

Thinking back to where this season began, this is an odd line. But the Titans have done a complete turnaround (like the Broncos, but in the other direction), and they keep winning this week. I’ll take the Titans. Results: Cardinals 17, Titans 20 (Push, W)

Bears (+10.5) at Vikings

Here’s a double digit line that I agree with. The Vikings are good; the Bears incredibly not. Give me the Vikings big. Results: Bears 10, Vikings 30 (W, W)

Steelers (+0) at Ravens

No line for this game, probably because of uncertainty with PIT’s QB. Honestly, I don’t think it matters. Steelers fall away, making me very happy. Or maybe it’s just wishful thinking. Either way, without a line, give me the Ravens in a pickem. Results: Steelers 17, Ravens 20 (W, W)

Patriots (+1) at Saints

A delicious game for MNF. And we’ll see an undefeated fall. I’ll take the Patriots straight up in this upset.