Posts in the Tech Category

The Web Stack

Published 14 years, 6 months past

Following on my “HTML5 vs. Flash” talk of a couple of weeks ago, I’m hoping to do a bit of blogging about HTML5, Flash, mobile apps, and more.  But first I need to get some terminology straight.

As I did in my talk, I’m going to refer to the collection of front-end web-standards technologies — (X)HTML (of any flavor), CSS, and JavaScript — as “the web stack”.  I’ve seen the term used here and there and it makes the most sense to me as a condensed verbal shorthand.  It beats writing out the specific technologies every time or trying to use similarly clumsy constructions like “front-end tech”.  If you like, think of “web stack” as a rough equivalent to “Ajax” — a term that was invented because continually saying “asynchronous JavaScript + CSS + DOM + XMLHttpRequest” was unworkable.

The web stack sort of includes downloadable fonts, but only in the same sense that images or any other external resource is part of the stack.  SImilarly, it encompasses frameworks like jQuery in the sense that they’re built out of the components of the web stack.

When I use the term “web stack”, though, I’m not referring to back-end technologies.  Those things are important, certainly, but not from the front-end point of view.  A browser doesn’t care if your page was generated by PHP, Django, Rails, Perl, or what have you.  It doesn’t even care if the server runs on Apache or something else.

Furthermore, it doesn’t refer to plugins.  Yes, that means Flash, but it also means QuickTime, Real, ActiveX, and so forth.  What I need to make clear is that I’m not doing this in an attempt to imply that plugins don’t belong on the web at all.  They’re just not part of that core web stack any more than the web stack is part of them.  That doesn’t stop them working together, obviously.

Okay, so that’s out of the way, and I hope my meaning is sufficiently clear to everyone.  Please do leave a comment if it isn’t.  Onward!

Web 2.0 Talk: HTML5 vs. Flash

Published 14 years, 6 months past

Earlier this week I presented a talk at the Web 2.0 Expo titled “HTML5 vs. Flash: Webpocalypse Now?” which seemed to be pretty well received.  That might be because I did my best to be unbiased about the situation both now and into the future, and also that the audience was very heavily weighted toward web stack practitioners.  Seriously, out of 100-150 audience members, about six raised their hand when I asked who was developing with Flash.

Many people have asked if the slides will be available.  Indeed so:  head on over to the session page, which I encourage attendees of the talk to visit so that you can leave a rating or comment on the session.  The 5.4MB PDF of my Keynote slides is available there whether you attended or not.

While I was at the conference I was also interviewed by Mac Slocum on the topics of the HTML and Flash, and that’s been put up on YouTube along with interviews with Brady Forrest and Ge Wang (both of whom are awesome).  I haven’t watched it so I don’t know how dorky I come off but I’ll bet it’s pretty dorky.

I indulged in a little good-natured ribbing of Adobe at the front of the interview (I kid because I love!) but the rest of it is, as best I recall, a decent distillation of my views.  I’m hoping to get a few more detailed thoughts written and published here in the next week or two.

Many thanks to Brady Forrest and the entire Web 2.0 crew for having me on stage and getting me out to San Francisco.  It’s always a great place to visit.

Seeking Hosting Advice

Published 14 years, 7 months past

A friend and I have decided to build a web service/site/whatever the kids are calling them these days.  A thing on the web to help you out from time to time.

As a result, we’re looking for a web host with great service, reliability, and scalability, and I was curious about your experiences.  Here are a few details on what we need:

  • A managed server where patches are applied automatically.  Neither of us are Linux experts, and we want something secured for us without us having to worry about whether some patch breaks the system. 
  • mySQL with phpMyAdmin.  (Don’t judge.)
  • PHP w/cURL, mySQLi, and mCrypt, as well as an editable php.ini file.
  • Apache!
  • Some sort of CVS (Subversion and the like) built in.
  • Bonus: some experience on the hosting side with the ability to escalate to Memcached and other noSQL techniques.

The mySQL and PHP bits are of course incredibly common, but still, no point not mentioning those requirements.  In our case, the bigger issue is really “Who can we trust to provide support for what may turn out to be a reasonably large-scale service?”  So the features aren’t nearly as important as the reliability and trust.

Thus: what say you, friends?  Who rates as a great place to plant a web service seed that could one day grow into a mighty forest?  Let me know!

Seattle Memories

Published 14 years, 7 months past

It’s been a week since I got back from An Event Apart Seattle 2010, and I’m still aglow about it.

I know it’s something a cliché for conference organizers to say “it was the best show we ever done did!” but damn.  It really was.  That’s down to the speakers, of course.  We’ve done our best to find great speakers with interesting things to say, and I’d like to think we’ve done just that.  This went to a new level, though.

You know how a band can have one of those nights where somehow, everything seems to go just right, where every jam riff builds on the others, where the music hits an indescribable groove, where the energy feeds on and multiplies itself until everyone in the place gets charged with it?  That’s what happened in Seattle, building throughout the whole show.  You could just feel it, buzzing in the room and through everyone there.  Every time a speaker finished I’d say to myself, half in gratitude and half in awe, “That is the best talk I’ve ever seen that person give.”

That was only half the experience, of course.  The other half was the audience itself, our amazing and wonderful attendees, who are as much colleagues as anything else.  They’re whip-smart, professional, veteran members of the industry.  That’s the demographic Jeffrey and I set out to address, and they’ve come to learn from and teach and challenge us to excel at every show.  Several speakers, some of them long practiced at the art of public speaking, have told me that they get uniquely nervous before going onto the stage at An Event Apart.  I absolutely agree.  To return to the band metaphor, it’s like doing a show for your fellow musicians.  While that’s comforting in a collegial way, it’s also nerve-wracking in a way other shows aren’t.

And the conversations!  Over lunch, in the hall between talks, at the party, it was non-stop talk with smart, funny, insightful colleagues who know their stuff through and through and are as keen to learn more as they are to share what they know.

So I can’t thank our speakers and attendees enough.  You are all incredible.  It was an honor and a privilege just to be there in your combined presence.

Turning Web Video On Its Head

Published 14 years, 7 months past

Here’s some fun.  (For a sufficiently nerdy definition of “fun”.)

  1. Launch Safari 4 or Chrome 4.

  2. Drag Videotate to the bookmarks bar.

  3. Go opt into the YouTube HTML5 beta.

  4. Find your favorite YouTube video.  Or maybe your least favorite.  Here’s one of my favorites: Walk Don’t Run.  Here’s another that’s not necessarily a favorite, but it seems like a fairly appropriate choice.

    Note: not all videos are available via HTML5, even when you’re opted in.  If you get a Flash video, the bookmarklet won’t work.

  5. Once the video has started playing, activate the “Videotate” bookmarklet.

  6. Enjoy.

Thanks to Simon WIllison for tweeting the JS I modified, and Jeremy Keith for helping me realize it would be easy to do during the HTML5 portion of A Day Apart.

Better PDF File Size Reduction in OS X

Published 14 years, 9 months past

One of the things you discover as a speaker and, especially, a conference organizer is this:  Keynote generates really frickin’ enormous PDFs.  Seriously.  Much like Miles O’Keefe, they’re huge.  We had one speaker last year whose lovingly crafted and beautifully designed 151-slide deck resulted in a 175MB PDF.

Now, hard drives and bandwidth may be cheap, but when you have four hundred plus attendees all trying to download the same 175MB PDF at the same time, the venue’s conference manager will drop by to find out what the bleeding eyestalks your attendees are doing and why it’s taking down the entire outbound pipe.  Not to mention the network will grind to a nearly complete halt.  Whatever you personally may think of net access at conferences, at this point, not providing net access is roughly akin to not providing functioning bathrooms.

So what’s the answer?  ShrinkIt is fine if the slides use lots of vectors and you’re running Snow Leopard.  If the slides use lots of bitmapped images, or you’re not on Snow Leopard, ShrinkIt can’t help you.

If the slides are image-heavy, then you can always load the PDF into Preview and then do a “Save As…” where you select the “Reduce File Size” Quartz filter.  That will indeed drastically shrink the file size — that 175MB PDF goes down to 13MB — but it can also make the slides look thoroughly awful.  That’s because the filter achieves its file size reduction by scaling all the images down by at least 50% and to no more than 512 pixels on a side, plus it uses aggressive JPEG compression.  So not only are the images infested with compression artifacts, they also tend to get that lovely up-scaling blur.  Bleah.

I Googled around a bit and found “Quality reduced file size in Mac OS X Preview” from early 2006.  There I discovered that anyone can create their own Quartz filters, which was the key I needed.  Thus armed with knowledge, I set about creating a filter that struck, in my estimation, a reasonable balance between image quality and file size reduction.  And I think I’ve found it.  That 175MB PDF gets taken down to 34MB with what I created.

If you’d like to experience this size reduction for yourself (and how’s that for an inversion of common spam tropes?) it’s pretty simple:

  1. Download and unzip Reduce File Size (75%).  Note that the “75%” relates to settings in the filter, not the amount of reduction you’ll get by using it.
  2. Drop the unzipped .qfilter file into ~/Library/Filters in Leopard/Snow Leopard or /Library/PDF Services in Lion.  (Apparently no ~ in Lion.)

Done.  The next time you need to reduce the size of a PDF, load it up in Preview, choose “Save As…”, and save it using the Quartz filter you just installed.

If you’re the hands-on type who’d rather set things up yourself, or you’re a paranoid type who doesn’t trust downloading zipped files from sites you don’t control (and I actually don’t blame you if you are), then you can manually create your own filter like so:

  1. Go to /Applications/Utilities and launch ColorSync Utility.
  2. Select the “Filters” icon in the application’s toolbar.
  3. Find the “Reduce File Size” filter and click on the little downward-arrow-in-gray-circle icon to the right.
  4. Choose “Duplicate Filter” in the menu.
  5. Use the twisty arrow to open the duplicated filter, then open each of “Image Sampling” and “Image Compression”.
  6. Under “Image Sampling”, set “Scale” to 75% and “Max” to 1280.
  7. Under “Image Compression”, move the arrow so it’s halfway between the rightmost marks.  You’ll have to eyeball it (unless you bust out xScope or a similar tool) but you should be able to get it fairly close to the halfway point.
  8. Rename the filter to whatever will help you remember its purpose.

As you can see from the values, the “75%” part of the filter’s name comes from the fact that two of the filter’s values are 75%.  In the original Reduce File Size filter, both are at 50%.  The maximum size of images in my version is also quite a bit bigger than the original’s — 1280 versus 512 — which means that the file size reductions won’t be the same as the original.

Of course, you now have the knowledge needed to fiddle with the filter to create your own optimal balance of quality and compression, whether you downloaded and installed the zip or set it up manually — either way, ColorSync Utility has what you need.  If anyone comes up with an even better combination of values, I’d love to hear about it in the comments.  In the meantime, share and enjoy!

Translations

Update 2 Aug 11: apparently there have been changes in Lion — here’s an Apple forum discussion of the problem.  There are two workarounds described in the thread: either to open and save files with ColorSync Utility itself, or to copy the filter to another folder in your Library (or install it there in the first place, above).

Update 27 Mar 12: edited the Lion install directory to remove an errant ~ .  Thanks to Brian Christiansen for catching the error!

MIXmasters

Published 14 years, 9 months past

The winners of Microsoft’s MIX 10K Smart Coding Challenge (for which I was honored to serve as one of the judges) have been announced, and the Grand Prize has been awarded to…

Jimmy D‘s Frog Log.

Which is an HTML5/CSS/JS entry.

That doesn’t run in Internet Explorer.

Yep.

Frog Log was my top pick, and obviously did very well with the other judges too, for a good reason: it’s a fun game.  It doesn’t play quite the same in Firefox previous to v3.5, as the drag-n-drop doesn’t work.  Instead, you click on a frog, then click where you want to place it.  I actually found that made the game a touch easier for me, but your interaction may vary.  In addition to working in Firefox, Safari, and Opera, it also runs on a number of mobile devices.

Here’s an excerpt from my judging remarks:

Just a great little game, addictive and well thought out with some interesting gameplay.  I would LOVE to see this developed further by the author…  My only ding was that drag-n-drop failed in Firefox 3.5; clicking worked fine, though.

I’m not sure why I had trouble with drag-n-drop in Firefox 3.5, since I don’t have have the same problem now.  Maybe I got confused with browser version numbers or something.  Regardless, it works fine, it’s a great game, and remember: it’s less than 10K unzipped.

I also gave high marks to the HTML5 runner-up, Chris Evans’ 100pxls, which was the source of my Dadaist tweet a couple of weeks back and lands right in my personal sweet spot for “doing odd things with popular web services”.  Here’s some of what I had to say in my remarks:

…really liked the concept here, especially the nonsensical tweets that were generated by drawing your own icon.  The icons could be made easier to see in the main display, but I suppose that’s a minor quibble.

I’d like to thank the MIX 10K crew for getting me involved as a contest judge; I really enjoyed seeing what people created and had a hard time narrowing down my votes to just a handful of winners.  More importantly, though, I offer my heartiest congratulations to all the winners, and most especially to Jimmy and Chris for doing such fun, interesting, and downright cool stuff with 10K of web standards goodness!

Inspector Scrutiny

Published 14 years, 9 months past

It’s been said before that web inspectors — Firebug, Dragonfly, the inspectors in Safari and Chrome, and so forth — are not always entirely accurate.  A less charitable characterization is that they lie to us, but that’s not exactly right.  The real truth is that web inspectors repeat to us the lies they are told, which are the same lies we can be told to our faces if we ask directly.

Here’s how I know this to be so: 

body {font-size: medium;}

Just that.  Apply it to a test page.  Inspect the body element in any web inspector you care to fire up.  Have it tell you the computed styles for the body element.  Assuming you haven’t changed your browser’s font sizing preferences, the reported value will be 16px.

You might say that that makes sense, since an unaltered browser equates medium with “16”.  But as we saw in “Fixed Monospace Sizing“, the 16px value is not what is inherited by child elements.  What is inherited is medium, but web inspectors will never show you that as a computed style.  You can see it in the list of declared styles, which so far as I can tell lists “specific values” (as per section 6.1 of CSS2.1).  When you look to see what’s actually applied to the element in the “Computed Styles” view, you are being misled.

We can’t totally blame the inspectors, because what they list as computed styles is what they are given by the browser.  The inspectors take what the browser returns and prettify it for us, and give us ways to easily alter those values on the fly, but in the end they’re just DOM inspectors.  They don’t have a special line into the browser’s internal data.  Everything they report comes straight from the same DOM that any of us can query.  If you invoke: 

var obj = document.getElementsByTagName('body')[0];
alert(getComputedStyle(obj,null).getPropertyValue('font-size'));

…on a document being given the rule I mentioned above, you will get back 16px, not medium.

This fact of inspector life was also demonstrated in “Rounding Off“.  As we saw there, browsers whose inspectors report integer pixel values also return them when queried directly from the DOM.  This despite the fact that it can be conclusively shown that those same browsers are internally storing non-integer values.

Yes, it might be possible for an inspector to do its own analysis of properties like font-size by checking the element’s specified values (which it knows) and then crawling up the document tree to do the same to all of the element’s ancestors to try to figure out a more accurate computed style.  But what bothers me is that the browser reported computed values that simply aren’t accurate in the first place.  it seems to me that they’re really “actual values”, not “computed values”, again in the sense of CSS2.1:6.1.  This makes getComputedStyle() fairly misleading as a method name; it should really be getActualStyle().

No, I don’t expect the DOM or browsers to change this, which is why it’s all the more important for us to keep these facts in mind.  Web inspectors are very powerful, useful, and convenient DOM viewers and editors, essentially souped-up interfaces to what we could collect ourselves with JavaScript.  They are thus limited by what they can get the browser to report to them.  There are steps they might take to compensate for known limitations, but that requires them to second-guess both what the browser does now and what it might do in the future.

The point, if I may be so bold, is this:  never place all your trust in what a web inspector tells you.  There may be things it cannot tell you because it does not know them, and thus what it does tell you may on occasion mislead or confuse you.  Be wary of what you are told — because even though all of it is correct, not quite all of it is true, and those are always the lies that are easiest to believe.

Browse the Archive

Earlier Entries

Later Entries