I may be giving too much credit to Mike Stackpole, Rick Loomis and the rest of the crew at Flying Buffalo for inventing the genre, but I give them credit for coming up with an interesting way of bringing interactivity to paper.

Creative as it was, the resulting stories were difficult to read. I had to stop every few sentences to turn pages, and jumping around through the book like a peripatetic kangaroo kept me from getting involved in the story itself, kept me all too aware of the medium rather than the message.

Yet how many of us today follow this noble, but failed, experiment when writing our code?

We begin writing our methods with the best of intentions. We lay out the opening scene (the arguments) and launch into the gripping tale of what is happening to them.

Yet only a few lines into the story, we stop. We interrupt the narrative flow in order to make a decision and send the reader off to somewhere else, with no regard for what is happening in the main storyline.

It might be something simple. We might break the reader’s concentration with something like:

id = params[:id].nil? ? 1 : params[:id]
Model.find(id)

Not only that, but if you wanted to be sure you weren’t getting slipped something troubling, you’d also have to check to see if what you were handed as the id actually is a numeric, and if not, handle that separately. It may be a small thing, but it distracts the reader (and ourselves) from the main point of the adventure, which is what we’re about to do with that id.

But we have to be sure there’s something both safe and useful in that id before we use it, I hear you say? Of course we do. It’s just there’s a better, more reader-friendly, way to word that. A way that will do less to distract our reader from our main plot.

If we use the fetch() method instead of simply [] to get the value, we can specify a default to use if the index is unset. This means we’ll get a real value back, no matter what, and won’t have to test for Nil and do any conditional branching to handle it as a special case.

Adding the .to_i method at the end of that (something we couldn’t do so long as the possibility of getting a Nil remained) will make the received value safer to use, by returning zero (a number) if the id value is anything but a number, which means the find method will always have a parameter it can work with, so we can drop it directly into the find:

Model.find(params.fetch(:id, 1).to_i)

This single line pulls from the model by id, supplies a default value of 1 if the id has not been given, and makes sure the given id is in fact a number, returning a zero if it isn’t.

By doing this we’ve handled the problems of Nil and non-numeric input at the same time, so we can guarantee the model will get a type of input it can use; failure in finding the zero id (the result of trying a non-numeric id) can be handled exactly the same as any failure to find an id not present in the database.

Look at your own code, this time realizing you’re telling the story of what happens to the data it encounters. Remember, the code you write today will be read tomorrow, either by yourself or someone else. Use good storytelling techniques to make that easier.

Tell the story of your code clearly, keeping digressions like error handling out if the main narrative flow as much as possible. Keep the main purpose of the code in a smooth unified narrative flow, so as not to confuse your reader. Your reader (who might also be yourself at some future date) will thank you for it.

And so will your code.

The issue with the ruby install is subtle, and doesn’t really show up until long after you have installed it. The issue is it points the gem repository to the wrong place. It points the gem repository to /usr/local/lib/ruby/gems/1.8 which is where the 1.8 gems should reside, not the 1.9 gems.

The ruby 1.9 gems should reside at /usr/local/lib/ruby/gems/1.9. And the default install doesn’t set that up. A sure way to make that happen is to put:

RUBY_DEFAULT_VER=1.9

in the /etc/make.conf file. It’s possible that adding the “-E RUBY_DEFAULT_VER=1.9″ flag on the make command will do the same thing, but I found the make.conf change worked, so I stopped at that point.

Make that change before you install ruby19 from the ports:

cd /usr/ports/lang/ruby19
make install clean

After that, the gems will install in the right location and everything will be work the way it’s supposed.

Nginx

The regular ports install for Nginx, on the other hand, is defective from the get-go. While the ruby issue is a subtle one that may not even pose a problem in some circumstances, the ningx issue will prevent the server from responding to any control scripts.

The issue here is the default configuration script points the .pid file to the wrong location. In the default nginx.conf file installed by the ports system is the line:

pid logs/nginx.pid;

This means the control scripts will not be able to find the nginx.pid file in order to send it signals. Instead the line needs to read:

pid /var/run/nginx.pid;

This will locate the nginx.pid file where the control scripts can find it, and everything will work.

Rails isn’t always an easy proposition on Dreamhost, and this was no exception. BTW, this is *not* the rvm version. I wanted to get the Dreamhost default setup working before I started playing with rvm. I’ll probably post an rvm-related set of instructions later.

In this case, I wanted to move some sites over to NginX as a trial, because the apache/passenger combination had been seeming rather slow and memory-intensive of late. I wanted to see how much time and RAM NginX would save me.

The first bits were simple. Setting up the VPS using the Dreamhost CP went easily, then came time to configure it. The settings are pretty much self-explanatory, as you can see. The idea is to select the NginX web server, then turn mod_php off. (I did the latter just because I’m anal-retentive: mod_php is an apache module, so it wouldn’t work with NginX anyway. But even if it did, I wouldn’t want it; I want to run PHP as a fastCGI/FPM process, anyway.)

Setting those gives you the basic setup for the domain. Unfortunately, that in itself isn’t enough to get the default Rails setup on Dreamhost (Rails 3.0.3 at the time of this writing) working properly. The fun starts now.

After

rails new appname --database=mysql
bundle install

builds the rails app, but there are more issues to come. The first is that Passenger doesn’t find the bundler to load. This is because it’s not looking for it (and, by extension, all your site’s gems) in the right place.

I recommend covering this in a couple of places, because this is something that will end up biting you again and again if you don’t. So, first, in the .bashrc file of your home directory you’ll want:

export GEM_HOME="$HOME/.gems/"
export GEM_PATH="$GEM_HOME:/usr/lib/ruby/gems/1.8"
export PATH="$HOME/bin:$HOME/.gems/bin:$PATH"


This will make sure your deployment tools, like capistrano, will see the gems. The ‘/user/lib/ruby/gems/1.8′ path is the default path Dreamhost is storing its own set of gems. You should check to ensure that’s where it is on your system, and if it’s different change it to whatever it is on your site.

Then you need to do something similar in /config/setup_load_paths.rb (you’ll need to create the file yourself, it’s not in the standard Rails 3.0.3 setup):

ENV['GEM_HOME']='/home/username/.gems'
# You can also set GEM_PATH if needed
ENV['GEM_PATH']="#{ENV['GEM_HOME']}:/usr/lib/ruby/gems/1.8"

You need it here, so that Rack can find the gems; it loads before Rails, after all, so putting them in the Rails config area wouldn’t help.

You’re probably not done yet. There’s another bug waiting to bite you in your Gemfile. I built this Rails app for mySQL, remember? This line:

gem 'mysql2'

was put in the Gemfile by Rails as a default. It resulted (in my case) in bundler using the Dreamhost-supplied mysql2-0.3.7 gem. And you’ll probably trigger an ActiveRecord error with that, along the lines of “this version of mySQL2 doesn’t ship with the ActiveRecord adapter.” Oops.

The solution is to drop back to a previous version of the mysql2 adapter for this, by changing the mysql2 line in your Gemfile to be

gem 'mysql2', '< 0.3'

That tells bundler you want one earlier than 0.3. I've seen it work with 0.2.7 and 0.2.13, so it doesn't seem to be too picky. It may even work with later ones than that; all I can say is I know 0.3.7 doesn't work with it.

That was the extra work it took me up front to get just a vanilla Rails install functioning on Dreamhost VPS. Hope it saves someone else the hours of searching and trial and error I spent getting it to work.

And Of Course Apache Is Different

It can't be so simple as to be the same changes with both. With apache, you need to place the gem path code at the top of config.ru:

ENV['GEM_HOME']='/home/demorails/.gems'
# You can also set GEM_PATH if needed
ENV['GEM_PATH']="#{ENV['GEM_HOME']}:/usr/lib/ruby/gems/1.8"

and it doesn’t need the setup_load_paths.rb file to be present.

Of course, you can always put the path code in both places. Having the setup_load_paths.rb file doesn’t seem to disturb apache and the extra code in config.ru doesn’t bother NginX. It’s not DRY, no, but it’s also not something that will be changing very often, if at all, so I can live with it.

Credits

• David Liu
• Trinitronix

I even hear Apple and Steve Jobs positioned as wanting to “destroy the web” with their focus on “native apps.” That their “focus on native apps” is “splintering the web.”

Now that I’ve laughed myself silly at the irony, it’s time to take a closer look at the facts in the case. But before we do so, some full disclosure. I use more than one Apple product. I also build Windows machines from parts for my church, contribute to Open Source projects, and run Ubuntu as well as Windows 7 and OSX in my house (in fact, there are more Windows licenses than OSX licenses around here). My prime work is done on OSX, not because it’s perfect, but because it and I get along better than Windows or Ubuntu and I. If that changes, I’ll have no compunction about switching. My computer is a tool, and like any competent workman I use the tool that fits my hand best.

So let’s turn back the pages of time and look at the iPhone launch. A note from Chris Zeigler on Engadget from that time says Apple was encouraging developers to code web apps and download them from their own servers. If Chris’s word isn’t good enough for you, here’s an official Apple press release: that says the same thing. Apple even set up a directory specifically to point to those web apps.

But the devs in Apple’s customer base clamored for the ability to write native apps, so Apple shipped an SDK, and created the AppStore to distribute those apps. No, not out of the goodness of their hearts. Of course they knew they would make money off it.

But note the chronology, here. Apple intended, even encouraged, devs to write web apps that could be hosted on their (the devs’) servers, uncontrolled by Apple. In short, Apple was pushing open web access on Day One of the iPhone launch. And, so far as I can tell, has never backed off that.

So go ahead and build web apps. It’s fun, the technology is open to all, you can build and ship what you like and keep all the money for yourself, if you wish. Just don’t say you’re “circumventing Apple’s iron control” when you do it. Have the integrity to say you’re taking Steve Jobs advice for how to develop for the iPhone, because that’s really what you’re doing.

So in the interests of helping out anyone else out there with the same idea, that of wanting to try out something new in hopes of finding something better, here’s a quick-and-dirty glimpse at the way I use git around here.

Git isn’t SVN

The first thing to remember is that git isn’t svn. It’s not server-based. It’s a distributed code management system, meaning there could be potentially hundreds of repositories involved. You can use it just like svn, and have a single repository on a single server, but that would be like buying a minivan to drive two people around town. Of course, I have a repository on my server (and I honestly question the wisdom of anyone who doesn’t) but that’s only one repository, and it isn’t the first one I create.

I start out by creating the repository in my project directory on my development machine:

git init
git add .


Those two lines of code initialize an empty repository and then add every file in my current directory to the repository. The second line might instead be broken into several lines, if I didn’t want to add every file, but this is the quickest. (If there arejust a few files you want to leave out of the repository, you’ll want to check out how “git ignore” works.)

What About The Server?

Well, that’s all fine and good for your local development, but what about shared development? Don’t you need a server for that?

Yes, but you don’t need git on the server. After all, a git repository is simply files. All you really need is ssh access to the server.

ssh user@server.com
mkdir projectname.git
cd projectname.git
git init

The first line above gets you into the server, the second line creates the directory you’ll be using for your remote repository. The final two lines above create the empty repository. After those, you can log out and return back to your local machine.

You send your changes from your local repository to your remote one by using the “git push” command. But first you’ll need to tell git where the remote repository is:

git remote add origin user@server.com:projectname.git

This line creates a reference to a remote repository and calls it “origin” (it’s a longstanding custom that the main remote repository be called origin, but it’s not a necessity). It points “origin” at the remote repository we set up earlier.


git push origin master

This line pushes the changes in the local repository up to the remote one identified as origin.

Now you can continue to develop on your local machine, committing changes to your local repository, and once you’re finished, you can push all (or just some of) the changes up to the server.

(And yes, the obvious “git pull” would be how you bring changes pushed to the server by other members of the team down to your local repository.)

A quick sheet of “normal” git commands.

Git User’s Manual

Come gather ’round people wherever you roam
And admit that the waters around you have grown
And accept it that soon you’ll be drenched to the bone.
If your time to you is worth savin’
Then you better start swimmin’ or you’ll sink like a stone
For the times they are a-changin’.

It always happens. Something comes along and catches on with the new kids, while the old fogeys pooh-pooh it as nothing special. Change comes, and only the agile survive. The gesture-based interface made popular on the iPhones and iPads is the change this time around.

I’m not going to insist the specific iOS gesture interface will be the final winner, but I am going to insist that a gesture-based interface will be. If you don’t believe me, hand a gesture-based device to a child and see how quickly they figure it out. Any interface that can be picked up that quickly by a bright toddler is going to succeed, no matter what you or I think about it, and no matter how hard you fight against it.

And if we (web designers and developers) want our work to stay relevant as time marches on, we have to listen to Dylan. We had better start swimming or we’ll sink like a stone. Or like a WordStar. We need to stop thinking in terms of specific interface actions, and shift into more portable semantic abstractions.

Stop Hovering Around and Get Semantic On It

Stop thinking in terms of “hover.” There is no cursor in a gesture-based interface, so hover-based actions no longer make sense. Apples’ iOS turns that event into “touch and hold”, but future interfaces may even dispense with touch, so don’t count on that being the replacement as the gesture-based interfaces mature.

That’s right. The gestures aren’t completely worked out, yet. Apple has a leg up on defining them, but first doesn’t equal winner in this game. If things are going to keep changing, how can we cope today?

We can come out of our denial, first of all. Remember when the mouse was sneered at? Remember when the WordStar folks claimed “the mouse is the ideal computer interface — for those with three hands”? I’ll bet you don’t even remember WordStar, do you?

And that’s my point. We need to change our thinking, now, or we’ll be tomorrow’s WordStar.

Instead of thinking about cursors and pointers, about specific interface actions like “hover” and “mouseout”, think instead of semantics. For example, what we think of as a hover action today (touch and hold in iOS) is really a “more info” action. When you design, define it that way: “triggering MoreInfo on this link will show a further set of menu selections” or “triggering MoreInfo on this term will bring up a definition of it.”

Don’t stop with hover. Continue this process for every action. When you write your scripts, don’t name the objects after specifics like “hover” or “tap” or even “rollover”. Name the objects after the response, such as “MoreInfo” and then apply that object to every UI element that triggers it.

Not only that, use those terms in your presentations. Speaking to clients in terms of “action/response” can help keep you from getting bogged down in implementation minutia during the presentation (“Should that be left-click always? Shouldn’t it be right-click for left-handed people? What if there are 1/3/9 buttons on the mouse?”). You’ll keep your meetings on track, and have more time to build.

The complaints are justified — what it does to links is insufficient for some vision-impaired users, and justified text looks horrible without good hypenation, which Safari doesn’t do, just to name the two most obvious.

But that can be fixed.

The proper way to adjust Safari’s defaults is through a custom user style sheet. But that doesn’t work here, because Safari doesn’t load the user style sheet when the Reader is engaged. Hopefully Apple will fix this bug (and yes, it should be considered a bug) in the near future.

But that doesn’t mean you have to wait until they do in order to change the reader style defaults. It just means you have to go a little deeper to do it.

1. Open your Applications folder
2. Right- (or control-) click on Safari
3. Select “Show Package Contents” from the contextual menu
4. Open the “Contents” folder
5. Open the “Resources” folder

There you will find the file “Reader.html,” which is the template for displaying pages in Safari Reader. In order to change it, you will need to open it in your usual text editor. (Neither Pages nor TextEdit are up to doing this. I used BBEdit to change mine, but Text Wrangler, Textmate, or Coda should be up to the challenge as well. You may be warned about the ownership of the file when you make changes to it.) All of the styles you want to change will be inside the style block with the ID “article-content.” For example:

.page a {
text-decoration: none;
color: rgb(32, 0, 127);
}


is the code block that sets the colors and removes the underline from the links, and

.page {
font: 20px Palatino, Georgia, Times, "Times New Roman", serif;
line-height: 160%;
text-align: justify;
}


is where it sets the text to be justified, instead of ragged-right.

If you want the links underlined, change “text-decoration: none” to “text-decoration: underline” and if you want ragged-right paragraphs, change “text-align: justify” to “text-align: left” and save the file (the system will prompt you for the password when you save the file). Your Reader will now pick up your new settings.

The usual warnings apply to making this sort of change. It’s best to save an unchanged copy of Reader.html to fall back to, and any changes you make may be erased by a future update to Safari, so you might want to store a copy of the changed file in your documents folder, as well. But, hopefully, the next time Apple updates Safari it will fix the bug that prevents user style sheets from being applied to Reader. If/When that happens, I’ll follow up with instructions for creating a sheet to do that, as well.

(Edited 6/14 to correct “left/right” typo. Mea Culpa. Meus bardus.)

The fundamental point I was making, that the future of web development lies with web application frameworks and not in traditional CMS’s, relies on two rather finely drawn (I cheerfully admit) lines.

The first is on the difference between implementing a CMS and developing for the web. To implement a CMS you typically need specialized knowledge and skill concerning which modules to employ to achieve the aim. The user group got hung up on this distinction, I suspect because many of the CMS implementors thought I was denigrating what they do. I wasn’t. I was simply saying that particular skill set is different from a developer’s skill set. It’s the difference between a production designer and a graphic artist — the graphic artist creates the images the production designer uses. The one who implements the CMS (I’ll call that particular skill set “systems integrator,” for lack of a better term) has a specialized knowledge that comes into play as the modules are assembled to make a web site. The developer’s skill set creates the modules the systems integrator selects from. In the world of the CMS, both skill sets are required, and they are generally found in different people.

The second line is between a traditional CMS and a framework. This line is becoming even finer, as more CMS’s (such as Radiant or Expression Engine) are developed that rest upon published frameworks (such as CodeIgniter or Rails). For my purposes, I’ll define the CMS as a collection of software modules that require no (or minimal) coding in anything other than the standard languages of the web (HTML and CSS) to implement. WordPress, for example, requires little or no knowledge of PHP (the language it’s written in) in order to be installed and used.

I received a lot of push-back when drawing the first line; it seemed to me a lot of the noise was being generated by the implicit assumption that I was saying the systems integrator skill set was somehow inferior to the developer skill set. This isn’t the case at all.

What I was saying was that the systems integrator skill set wasn’t interesting to the developer. This isn’t saying it’s inferior; I could say the same thing about the developer skill set not being interesting to the integrator. It’s not interesting, because at root it’s not relevant to what they do best. Just as excellent graphic artists can make bad production designers, excellent developers can make bad integrators, and vice versa.

These days it’s possible to put together a CMS that adequately meets 80% of most customer’s business needs from a free or low-cost CMS, using off-the-shelf modules. If a developer plans on making more than a subsistence living in that market, it can only be by giving up or seriously limiting the amount of time spent doing what a developer does best (if satisfactory extensions are free, there’s not a good economic case for getting paid to write them from scratch) and instead turning into a systems integrator. Some developers can do this, some can’t, but even those who can do this only succeed by, in effect, ceasing to be a developer.

Therefore the developer has to step out in a different direction. One possibility is to build completely custom coded websites, while another is to develop and sell modules for the systems integrators to use.

If a developer chooses to go the custom-code route, a framework will provide a solid foundation to build off of. Frameworks provide stub code and basic functionality which can easily be extended to cover the precise needs of the site at hand, without incurring the burden of unnecessary code. Built-in or otherwise available framework modules to handle user authentication, for example, form the basis for a more complete user profile system, only requiring the custom features of the user profile required by the community site under development to be written by the developer. The framework does the heavy lifting, while the developer supplies the chrome and the custom business logic, tailored to 100% of the site owner’s needs. Instead of off-the-rack, the result is a custom-tailored fit.

This road isn’t easy. Off-the-rack suits fit most bodies reasonably well, so the potential market is smaller. But at the same time it’s more lucrative, so the two balance. And with a good framework, a creative and knowledgeable developer can provide enough of a value add to make the time and cost more than worth it to the customer. If the “standard” CMS yields 80% of the goal, a good framework under it can often make the other 20% easier to reach.

If the developer chooses to build and sell CMS modules or extensions, the market is tighter. There will be a lot of competition from low- (or no-) cost alternatives exerting downward pressure on the market, still it’s possible for a developer to make a living there. But in taking that route, the developer still is using a framework. In this case, the internals of the CMS itself form the framework that is used to build the extension. Sometimes that’s explicitly designated as a framework, as with Expression Engine or Joomla, and sometimes it’s just a published API, as with WordPress or Drupal. But whether it’s officially named that or not, it’s still a framework.

So what’s the “action list” for you as a developer?

• Look at the framework first. Don’t (please, just … don’t) write your own framework from scratch. There are plenty of Open Source ones out there to contribute to; find one you can live with and while you’re learning it, fix some bugs and add some features to make it better. It’ll be easier to add the features you want to an existing framework than write an entire framework from scratch around those features.
• What CMS choices are built on it? This will feed into the next decision you make. If there are some good CMS choices on the framework, it will make it easier for you to write extensions for others to use, expanding your reach and your market. And, hopefully, your bank account. (Yes, money isn’t everything but the lack of it makes it hard to buy new hardware.)
• Decide — Custom Code or CMS extensions. Make this decision on top of the best framework you can find. The framework itself will provide some of the tools you’ll be using to build the modules, after all, and no one likes working with inferior tools.

There’s you road map. Start your journey.

Robert Vining, newly minted chief spokesman and admin for All Together As A Whole is finding that out, right now. He writes about it in this blog post.

I’ve been there, Robert. You made the right choice.

In a nutshell, he was told he was going to be removed from helping with the joomla.org forums unless, now that he’s in charge, he bans an individual from an unaffiliated website. (It says “independent” in the tagline, in case you’re easily confused.)

Now let’s note that this person was banned from joomla.org, and from all appearances the banning was certainly with cause. But note also this individual has not given cause to be banned from the site Robert administers. And that’s the crux of this.

Let me speak to this from direct experience. I used to organize chess tournaments; my events were among the strongest held in my state every year. And more than once I had to listen to players from a neighboring state expressing “sympathy” for me for having to put up with another player from their state. And every time one of these “helpful” people said that, I responded that the person in question is better behaved in my events than most other players, including themselves. I don’t know what their issue was, and I don’t care. I just know that when he was in my house he behaved himself well, and I wasn’t going to let them litter my yard with their garbage.

I loaned money to a player once, and was instantly told (by my partner, no less) that I was making a mistake, and I’d never see the money again. And the next day, before play began, I got my money back.

This is the lesson I learned long ago, from direct experience. Behavior in one location, among one set of people, under one set of conditions, does not dictate forever behavior in other locations, among other people, under other conditions. And to assert otherwise is dangerously stupid.

I’m leaving names other than Robert’s out of this for a reason. The point here is one of principle, and is not in any way personal. Let me say that I would certainly have voted in favor of the original ban, had I had a vote, so in no sense is this aimed at criticizing the original ban, nor should it be seen as excusing or condoning the behavior that caused the ban. Let the joomla.org ban stand unchallenged, by all means. It is instead aimed at the presumption behind further opinions expressed during discussion of this by two members of the project leadership that this person should not be allowed the chance to prove he has changed and that he can participate somewhere else without giving offense. In effect, they assert he should never be forgiven.

I find that attitude dangerously arrogant, and deeply offensive. Almost as offensive, in fact, as the original conduct. People can change. I have first-hand knowledge that people can learn how to behave themselves. Not only have I seen it around me, I’ve seen it in myself.

We all know that we can blow it for ourselves by our own conduct. That’s how it should be. But how comfortable can we be around people knowing they’ll turn on us, and turn us out, when our only offense is to have the grace to give someone whose only transgression is words a second chance?

I honestly don’t know. And that worries me.

(Full Disclosure: I edited this post after it was published. I broke what was paragraph #3 into what is currently paragraphs #3 and #4, to make it more readable.)

It’s a lie.

And that’s a problem. Apparently, he made those wonderful claims of his without ever once checking the reality of them. Most of those sites that supposedly don’t show anything, actually do. As this set of screen captures shows.

Which means he wasn’t interested in truth at all, nor even in the experience of web users, as he claims. All he wanted to do was complain because that Big Meanie over at One Infinite Loop in Cupertino didn’t want to let him bring his own toys to the iPad and iPhone party. Boo hoo.

Let’s get something straight right up front. I ain’t no fanboy. I don’t own an iPhone, nor will I be queueing up on day one to get an iPad. I’ve been an Adobe customer for as long as I’ve been an Apple customer, since Photoshop version 2.x. I even stayed an Adobe customer after they deliberately killed the best illustration program I’ve ever used (Freehand — after two earlier failed attempts they finally managed, not to beat it in the marketplace, but rather they kept buying companies in a repeated attempt to get it off the market). I’ll admit to a point of view, here. I’m amused by the flash fanboys who can’t seem to realize their own playground is just as proprietary, just as limited and controlled, as Apple’s.

Yes, it’s amusing to watch Adobe, from their closed proprietary yard, cry foul at Apple’s closed proprietary yard (pot, meet kettle) but that’s about it. The world, and the web, will do fine, with or without Flash. Right now, there are far more examples of bad Flash use than bad HTML5 Video use, but I’m sure that will level out eventually — flash developers have certainly not cornered the market on ineptitude. It only seems that way, sometimes.

Professionals know the iPad is just another device we have to deal with, just like we know Flash is just another tool in the box, and no tool is the right choice for every device, and probably never will be. So we plow around the rocks in the field that we can’t lift. For simple video, the solution is fairly obvious: do your video in H.264, because that will give you the widest access to your customers. As John Nack pointed out in a post on a more official site Flash will deliver H.264 as well as native flash format. So you do the video in H.264, and use Flash as the ancillary system to deliver the H.264 to the clients that can’t see it natively. Problem solved, the same way we’ve been working around IE’s limitations for years (thanks for the practice, MS).

John raises other issues about why Flash is such a hog on OSX, and while they may or may not be true (I admit I don’t know) I really can’t see why I, as a professional web builder, should care. It is what it is, and I have to deal with it the way it is, not the way John Nock or Steve Jobs, or anyone else, for that matter, wants it to be. And the way it is, the performance of Flash on OSX is sub-par. That’s reality, and it’d be far more productive to fix that than stand around pointing fingers.