Category Archives: Random Rants

The beauty of e-mail aliases and vanity domains

I use the domain as my own personal domain (as you can see by visiting this site).  I also use it for e-mail.  When providing an e-mail address through an online form, I typically create an e-mail alias for that site.  Doing so enables me to track if that site sells my e-mail address or, as happened the last couple weeks, starts sending out a ton of advertising.  Just today I deleted two e-mail aliases because the sites have become more aggressive when trying to solicit their wares.  I won’t bother to mention the sites or companies; they did nothing wrong other than start sending out multiple e-mails per week.

Could I have unsubscribed?  Sure, probably, maybe?  It’s not clear that I would’ve received less garbage from them though and doing so would’ve required more time than simply deleting the e-mail aliases.

Lesson learned for me (and you):  Use e-mail aliases liberally when signing up for services or filling out forms.

Lesson learned for companies:  Stop sending so much junk mail.  You may really, really think that what you’re offering is important and, if you send just one more e-mail, I might come back to your site.  But get some self-control.  Sending out an e-mail every now and again is fine.  Sending multiple e-mails in the same week over the course of a couple weeks is too much.

iOS 7: First Impressions

After getting through some unexpected activation issues last night I spent some time with iOS 7 today and this evening.  First impression:  If this is the UI that Jony Ive designed then he should be fired and be sent to a deserted monochrome island.  There is simply not enough contrast for, well, anything in the UI. The tiles blend together and the new fonts don’t do anything to help the situation.

Everything seems to blend together, there’s no texture or feel for any of the buttons or any of the UI within apps.  It’s not even clear which way to slide to unlock – the arrow/slider is missing (or at least I can’t see it).  What is clear is that Apple has taken minimalist somewhat too far.  If this is an evolution in minimalist then I expect the next iteration will just be a blank white screen where you poke at the UI with the hope that it will do something.

For now, I’ve reverted back to iOS 6.  I’m sincerely hoping that this early beta doesn’t capture the true iOS 7 look and feel or user experience.  I hope I can write an update to this post later saying how wonderful iOS 7 is (and some of the features appear to be nice).  But for now, the UI needs fixing.  Tempted to file a bug about the UI…

Reading the Preface

Before I started writing, I never spent much time reading a book’s Preface or other front matter, I just skipped right into the book and went from there.  After writing my share of books for a variety of skill levels, I find the Preface and other such introductory material to be of great importance.  The Preface can be used to tell the reader what skill level they need in order to read the book and what they can expect in the book.

After reading some reviews, it’s clear there are a lot of people who don’t read the introductory material.  If they did, they’d find out that a book is above their skill level (or below their skill level in some cases).  My favorite example is a review for a beginner-level programming book.  By beginner-level, I mean someone who has never programmed anything before, in any language, anywhere.  The book’s introductory material makes it clear that the book is for newbies and only newbies.  However, the reviewer rates the book poorly because it doesn’t contain a certain type of programming structure.  Obviously, if the reviewer knew programming structures, there’s a great chance they were well beyond a beginner-level book already!

In any event, introductory material is indeed important.  I needed to write several books to realize that; hopefully others won’t have to write books to extract the same lesson.

Revising Books

This post is somewhat difficult to write. I’ve been involved in a few book revision projects over the past 10 years where I’ve picked up another author’s book and had to revise it for a new version of $widget or just to update it. When doing so, I notice that my writing approach is different than some authors. I can’t or won’t claim that my writing approach is better, in fact it may be worse, but it’s the approach that I use nonetheless.

When revising books I quickly become frustrated with what I view as oversimplification because it leads inevitably to incorrect information. Unfortunately, I can’t provide a real-world example because that would compromise the projects I’m working on.  However, an anecdotal example is around DNS, where many authors don’t seem to understand the most basic things about DNS and therefore gloss over the details in such a way as to provide incorrect information for the reader.

I find myself completely gutting entire sections of books and having to rewrite them when the intention was to merely revise.  A side-effect of this is that the section comes out shorter which some publishers don’t like; they like an increased page count.  I like correct, accurate information, explained in the clearest manner possible.  The funny thing is, (funny to me), I’ve done this to my own revisions too, where I’ve picked up something I wrote 5 years ago and think “what is this garbage?”.

Additionally, with books I revise or write from scratch, I tend to try to explain not only how something works but also why it works.  Sometimes I’m successful at providing this explanation while at other times I fail miserably in both the how and the why.  I feel that you, as the reader, are looking for more than just a tutorial on a subject; the web is full of tutorials. When you take the time and spend the money to read one of my books I hope to provide you with more insight than you would get from a tutorial or even a tutorial-based approach.

My approach to book writing should also serve as a warning to those readers who want a quick-and-dirty tutorial on a given subject.  You won’t get that in my books.  Sure, you’ll see the how, the tutorial, but you’ll hopefully also learn why you need to do it that way. This is how I learn, by seeing how to do something but then having it explained why it should be done that way. Like many people, I get paid to solve difficult problems on computers and with computer systems.  My experience  leads to being able to envision multiple solutions to any given problem.  Therefore for me, it’s helpful to see a problem solved and then see why the problem was solved in that particular way.

Granted, this isn’t always the case, not every example has a multi-page explanation, but many do, and many sections within my books contain best practices learned from years and years of experience in the areas in which I write.

I’m involved in 4 book projects this year, at least two of which will be released this year while the remainder will come out in the first quarter of 2013.  All told, this will likely account for somewhere just short of 2,000 pages (+/- 20%) of writing over the course of 8 months.  The approach described in this post is being applied, as best I can, to each and every one of those 2,000 pages.

HTML5 is a Specification

I read some articles, which I won’t cite for lack of wanting to start a small war, that refer to HTML5 as a collection of technologies that describe how the new web works, in much the same way that the term Web 2.0 was used for years to describe a collection of technologies including AJAX to provide higher interactivity to web pages. In these specific articles, HTML5 was referred to as including HTML, CSS, and JavaScript. This is horribly confusing to a non-technical user and leads to some seriously awkward conversations about HTML5.

When a technical person hears “HTML5” they think, “Oh, the W3C Spec for HTML5.” However, in reality the non-technical person has been misled into thinking that HTML5 includes other technologies like CSS and JavaScript and therefore “HTML5” can do all these neat things.

HTML5 is the specification put forth by the W3C for HyperText Markup Language. The version of the specification is number 5. That’s what HTML5 is, nothing more. HTML5 is most definitely not CSS or JavaScript and does not include those technologies. CSS is defined by its own specification and so is JavaScript and neither of them like to be called HTML.

HTML5 is not video and does not make video better. HTML5 has a video element, yes, but browsers still need to support that element and the programmer/site operator still needs to encode the video in multiple formats. Will this change? Probably. I’m looking forward to the day when I can upload my video file in whatever format and have it play across all browsers, like magic. But that day is not today. Today we encode in multiple formats, sometimes use the video tag and sometimes use the object tag. We’ll get there but it’s not now.

[[Ad: Backup your PC Now! ]]

HTML5 is not more secure than HTML4, stating such is nonsense, it’s a markup language. Are browsers better, arguably more secure? Yes. But those same browsers are better at rendering HTML4 too and their security applies equally to all versions of HTML5. It’s actually plausible to say that HTML5 and a browser’s implementation thereof makes users less secure due to as yet undiscovered exploits in the way those browsers interpret the new specification. Think: Web Storage.

Please, I beg of you, stop referring to HTML5 as a set of technologies including CSS and JavaScript. If you’d like to make up some buzzword or buzzphrase then do so but HTML5 is taken. The term Web 3.0 seems too cliche but at least it wouldn’t muddy conversations between technical and non-technical people.

Top Listing in Google

I’m amazed by the amount of spam that I receive that just doesn’t make sense.  Okay, I shouldn’t be amazed by that, but here’s a good example:  I have a couple web sites, one for myself and one for one of my books, JavaScript Step by Step.  On the JavaScript Step by Step web site there’s a contact form for readers to let me know about errata and other such niceties.

It seems as though a spam bot must’ve found the form through a search engine and now someone, somewhere, thinks it’s a good idea to try to advertise SEO services by filling out the form they found using a search engine.  See the fallacy?  If the site wasn’t already ranked high enough in the search engines then their spam bot wouldn’t have found it.  However, since the site is high enough in the rankings they found the site.

Moral of the story:  If you want to market SEO services, don’t use a search engine to find potential clients.

Project Methodology: What’s the Goal?

I’m struck by the number of times that people make the wrong decisions when it comes to application development as it relates to the ultimate goal.  The ultimate goal of application development is to support the business, so that the business can leverage that application to streamline processes, beat a competitor, or whatever the business need.  To that end, it seems worthwhile to deliver the best application possible.

A competing approach says that the application needs to be delivered by a certain date, regardless of the features (or failures) of the application.  Setting dates for deliverables makes sense, especially when those dates are tied to reality.  Too often though, dates are chosen without regard for the needs of the business; the dates are chosen out of thin air, using a dartboard, roulette wheel, or some other method less accurate than the aforementioned.

When due dates are chosen arbitrarily it only hurts the business.  Sure the application gets out there faster and some project manager somewhere can mark that as a completed project, but features go missing, bugs go unfixed, and the people who suffer the most are the ones who need the solution most.  That’s an important point that seems to go missing:  Business users suffer the most when arbitrary deadlines are set.  The ultimate goal, delivering a product to support the business, gets sacrified when dates are not based on reality or requirements.

Does Agile fix this?  With an agile process, more software is delivered, but that software is not necessarily better software.  And even with an agile process, deadlines are set.  However, now those deadlines are set based on even less information than other project methodologies.

Keep in mind the ultimate goal of delivering better software and supporting the business when setting deadlines.

Wordy today

I’m writing a review for a book and while rereading some of the paragraphs I noticed that I’m having one of those wordy writing days; one of those days where I write several words to express one thought when one or two words would do.  A symptom of such a malady is the use of semi-colons (oops, already used one in this post).   I wonder as to the source of this wordiness.  It may be from having to obtain a higher page count for certain unnamed publishers or it could be from reading old (1800’s and early 1900’s) writing where the sentence structure was much more formal.

Either way, it’s making editing a more difficult task.  It’ll be interesting to see how the final review ends up.  I should leave it unedited, take a word count, and then edit it down and compare the word count.  Bah.  That’s too much work.

Version Numbers Matter

After participating in a Slashdot thread about Mozila End-of-Lifing Firefox 4 already (just a few months after it came out), and then thinking about a discussion a few months back about WHATWG ditching version numbers for the HTML specification, I got to thinking more about version numbers and why they matter.

Version numbers (or even names), such as HTML5, Firefox 3.6, Windows 7, Mac OS X Lion, and iOS 5, matter.  They indicate a point in time and provide a reference to the featureset supported.  For example, mention Internet Explorer 6 to any web developer and they may cringe.  IE6 is as notorious for its lack of standards compatibility as it is for its longevity.  When a developer knows that he or she must support IE6, they automatically know that they can’t support many of the features available in newer versions and also have to provide workarounds for several bugs and anomalies inherent in IE6.

Previously, Firefox released major versions when there were major changes to the browser.  So a change from Firefox 2 to 3 brought major interface and UI changes.  Following along that model, when there were minor tweaks to the UI or the underlying web standards supported, Firefox might release a minor version, such as 3.1, 3.5, or 3.6.  Finally, when there was a bug or security fix, it was bundled into a point release such as 3.6.1.

This model worked quite well for years and helped Firefox to gain significant market share.  Several years ago, corporate web sites didn’t support Firefox, meaning that the site either wouldn’t render properly or wouldn’t work at all in Firefox.  With the increased market share came increased corporate support for Firefox.  No longer could a business turn away 10% or 20% of its visitors simply due to their browser.

Along came Chrome which began making version numbers irrelevant.  Google releases Chrome versions much more rapidly than Firefox, currently on version 12.  However, unlike Firefox, Chrome does not have the widespread adoption rate and thus the widespread explicit support from major corporations.  Granted, sites work well in Chrome but try calling your bank’s tech support line and telling them that you’re having a problem with their site using Chrome.  You’ll be told to get a supported browser.

Somewhere along the way, Firefox decided that it needed to compete with Chrome and to do so it needed to not only decrease its time between releases but also increase its major version numbers.  Decreasing the time between releases makes sense; keep adding new features and improving speed and support for web standards.  Incrementing the major version number does not make sense every six weeks.

When designing a web site, organizations need to determine what browsers will be supported.  What experience will the visitor have in a particular browser and what will happen if they visit using an older browser?   This means making choices about what browsers to support and then what features can be used based on the requirements for support.

Somewhere, right now, an IT architect or developer is talking to his manager indicating that they now need to support Firefox 5 because Firefox 4 is out of date.  And Firefox 6 is coming in 6 weeks.  Businesses, with limited resources, need to test their sites in these new versions in order to keep claiming support for them.  Sooner or later, businesses won’t be able to keep up with this rapid release cycle and will have to make a choice to either stop supporting Firefox or keep devoting resources to testing in the browser.

Granted, not much changed between versions 4 and 5 of Firefox.  But at some point, something major *will* change between versions.  Previously, it was easy to tell if something major was changing because the major version number changed.  Without being able to use the major version as an indicator of change, IT departments will need to  test the sites in each version, read release notes, and otherwise spend time that they shouldn’t need to spend.

Users are also hurt because add-ons with Firefox can and do break between major version numbers or at least aren’t listed as being compatible between the new versions.  So now users are left to either run potentially incompatible add-ons or not run the add-on at all.  This doesn’t even take into account the add-on author’s time testing the compatibility.

Version numbers simply matter.  They let us know what to expect when choosing to spend resources to support the technology, when programming for the technology, and when using the technology.

When to Retire an Old Bookmark

I have an app that I use to manage my web bookmarks.  The app enables me to categorize bookmarks and use them cross-device, from anywhere (it’s hosted).  I’ve been using the application for several years and each time I click one of the bookmarks, that click gets recorded into a database.  As time goes by, the most popular bookmarks in each category rise to the top as they are used more and more.

However, this means that less popular bookmarks sink to the bottom.  In looking at the 76 bookmarks (only 76, seems like more) that I have in the list (and are active), there are some that I haven’t used in a year and one that I haven’t used in nearly two years.  So the question becomes when should I delete the bookmark or inactivate an unused bookmark?  I’m thinking that bookmark to a weather site that hasn’t been used since July 25, 2009 is a candidate to be inactivated.

For my own reference (filing this under “Useful Items that I Forget”) here’s the query that I ran:

select b.title,from_unixtime(max(p.dateclicked)) from p_bookmarks b, p_clickstats p where p.bmrkid = and = ‘1’ group by order by from_unixtime(max(p.dateclicked)) desc;