two bit fool

what is software engineering?

2010-11-02T23:43:00.000-07:00

It is rare to come across a conference video that talks about the history of the technology and craft of building software.

http://confreaks.net/videos/282-lsrc2010-real-software-engineering

This talk gives an interesting look at the history of the software industry, and talks about how the waterfall method -- now widely regarded as a failure -- was inspired by a gross misreading of a paper that was trying to explain why such a ridiculous method would never work. As a bonus, you can have a good cry when you learn that Agile methods were being discussed decades ago, until they were pushed aside by broken academic theories, like waterfall.

book review: coders at work

2010-06-15T04:29:00.000-07:00

I just finished Coders at Work this past weekend, and it was a everything that Beautiful Code wasn't.

The concept is simple: Peter Seibel sat down with 15 different programmers (including such greats as Brendan Eich, and Don Knuth) and asked them the kind of questions that a fellow developer would ask. The interviews were insightful, and in-depth: giving a glimpse into the history of each person, and exploring their personal views on everything from the dangers of C to the usefulness of debugging tools more advance than simple print statements.

Software is often a solitary and opaque profession, and this is the next best thing to personally sitting down with these computer legends to pick their brains. If you are involved in software development (programmer, architect, analyst, whatever), I highly recommend this book.

iPhone app economics: HTML5 vs native

2010-03-13T12:11:00.000-08:00

I don't develop iPhone apps, but I found Peter-Paul Koch's article so ridiculous that I decided to respond. He tries to make the case that there is no money in developing native apps for the iPhone, and he recommends making HTML5 apps instead.

In the article, he suggests that iPhone app developers fall into 3 buckets:

paid by clients
don't care about the money
lone guns expecting to get rich

But this is an artificial division, it's not about the developers, it's about the economics of the apps -- what matters is how much money the app makes, not the developer. An app that doesn't make enough money to pay for the development (and ongoing costs) is a failure, or a hobby. Whether you are a lone developer or paid by someone else, making apps that lose money is bad business. The real question is...

If the goal is to make money selling an iPhone app, which one will have better profit margins: a native app or an HTML5 app?

The thing that Apple has done exceedingly well is to make the process of finding, purchasing, and installing an app dead simple. This is in stark contrast to an HTML5 app -- as Peter-Paul says:

The counter-argument is that the HTML5 app route doesn't allow developers to get paid. That's true -- for now.

He makes some wild guesstimates on the economics of the app store -- numbers that don't agree with what other people have found -- to show that there isn't much money in distributing apps through the App Store...but compared to what?!? He says that an HTML5 app is a better option a fait accompli, but he makes no attempt to calculate the economics of it. Even if he could successfully discredit the idea of making money on native iPhone apps, that doesn't automatically make HTML5 apps a better option.

If you ever wondered what confirmation bias looks like, this quote is from the start of his article (emphais mine):

In response to my HTML5 apps argument a few people came back to how the payment thingy is missing from my idea, and how it will (apparently) be worthless because of that. I've been thinking about that a lot in the past few days, and I'm increasingly of the opinion that the payment argument is nonsense.

I'm a proponent of open standards and platforms, and I hope a day will come when developers can make money without making native iPhone apps. But that idealism is tempered by the reality of the present, and Mr Koch has given no compelling evidence that HTML5 apps would make a better profit than a native iPhone app. At best, he's made the case that iPhone app development might not make enough money for the lone developer, and that is a risk for any type of software development.

HTML5 apps have tough competition on the iPhone, because in general, native apps:

are more performant
work better offline
leverage iPhone capabilities (camera, gps, etc)
are easy to find, buy, and install

The internet has a culture of freedom, and with such a variety of free services, consumers don't often need to pay for online applications -- most are supported by advertising dollars or hoping for the big buyout. However, like most iPhone/iPod Touch users, I have no problem dropping a few bucks in the App Store jar from time to time. Apple has created an environment where it is easy to buy apps, and when it is easy and inexpensive, people don't mind paying -- the same lesson that iTunes taught us about music. If purchasing apps online was as simple as the App Store, people would be more willing to pay, and services would be more willing to charge.

So, if someone wants to make the case for HTML5 apps, develop an app both ways (HTML5 and native), track the costs and revenue, and let's compare some real numbers.

screen resolutions...is 1024 the standard?

2010-02-19T06:54:00.000-08:00

While trying to figure out if it was still important to support screen resolutions of 800x600, I pulled up several of the most visited websites to see where they fall. Here are the ones that work in a width of 800 or less:

baidu
blogger
go
google (also: gmail, google calendar, google reader)
rapidshare
skyrock
twitter
wikipedia

And here are the sites that aim for 1024px and require horizontal scrolling at 800px:

amazon
aol
bbc
bing (aka live.com)
cnn
craigslist
dailymotion
ebay
facebook
flickr
friendster
imdb
linkedin
microsoft
msn
myspace
orkut
photobucket
wordpress
yahoo

And w3schools says it is at about 1% for their visitors. Sure seems like support for 800px wide displays has gone out of style. Guess those iPads will spend most of their time turned sidways.

removing a file when the filename starts with a dash

2010-02-18T07:25:00.000-08:00

When you royally goof up a command, you may end up with some strange filenames.

$ echo "hi" > -oops.txt

And filenames that start with a dash can be tricky to delete.

$ rm -oops.txt
$ rm \-oops.txt
$ rm "-oops.txt"

All the above commands treat the -o as an option, and return the following error: rm: invalid option -- 'o'. Luckily, Ubuntu returns some extra help in the error message.

rm: invalid option -- 'o'
Try `rm ./-oops.txt' to remove the file `-oops.txt'.
Try `rm --help' for more information.

So all you need is a path on the front of that nasty filename.

$ rm ./-oops.txt

book review: designing visual interfaces

2010-02-17T18:04:00.000-08:00

Designing Visual Interfaces: Communication Oriented Techniques

This book gives (what I can only assume is) a thorough treatment of the design of visual interfaces, with a focus on computer interfaces. I can only assume it is thorough because I skipped or stumbled over several sections with dense and confusing wording. For example:

The triadic structure of the sign permits the sign process (semiosis) to be considered at three levels. Syntactics addresses the internal structure of the representamen itself, particularly in terms of the relationships among its parts. Semantics addresses the tacit relation between representamen and sign object (that is, the intended meaning of the sign). Pragmatics considers the effect of the syntactic and semantic aspects in relation to a particular interpreter in their personal psychological context.

There were plenty of gems in this book, and the way illustrations (and screenshosts) were employed to explain the different concepts was very useful. However, the style of the writing often made it unpleasant to read, and I came away feeling like I had missed as much as I had learned.

The thoughts I came away with:

be consistent with the surroundings (OS, app, form, controls, etc)
align elements along vertical horizontal grid lines
use the same (or multiples of) height and width for all controls
make clear visual representations of grouping and hierarchy

book review: beautiful code

2010-02-14T17:38:00.000-08:00

It's always disappointing when a book with such a great potential falls short, and sadly Beautiful Code: Leading Programmers Explain How They Think (Theory in Practice (O'Reilly)) is a victim of a great idea with a poor execution.

The basic idea was to get a bunch of great programmers together and have them tell stories about their experiences in the real world: developing a new system, learning the value of reading other people's code, squeezing every ounce of performance out of some critical code, or being inspired to implement some clever new algorithm. This would had worked wonderfully if they had just limited the number of people that contributed to the book. Instead they crammed over 30 people into 500 plus pages, and ended up with about 16 pages each.

Conclusion

This book tried to soar to such great heights and suffered the fate of Icarus. If only they had picked 10 programmers and given them each 50 pages, this could have been a book with some real meat. Instead the brief chapters feel like a series of taste tests collected while wandering around the supermarket -- too brief and unsatisfying to call a meal. Sorry, but this one is not worth reading.

sudo PATH fix for Ubuntu

2009-11-12T06:04:00.000-08:00

Photo by gumuz

Passenger is fantastic way to run Rails apps. The installation is nothing short of awe inspiring, and the thing just works. If you are using Rails, you should be using it along with Ruby Enterprise Edition.

Rails deployments used to be a nasty mix of different software with configuration nightmares that would make a sysadmin weep. The Phusion folks deserve a huge round of applause, and some donations on their very funny "Enterprise License" page.

sudo PATH bug in Ubuntu

The only annoyance I've had, and this is no fault of Passenger, is with running the passenger-status tool. It requires some extra permissions, but running it with sudo does not work "out of the box."

$passenger-status
Permission denied

$sudo passenger-status
sudo: passenger-status: command not found

The problem here is that although I've modified my PATH to include the path to the passenger-status command (/opt/ruby-enterprise/bin), my PATH does not include it when using sudo. A quick glance at the sudoers man file reveals the env_keep option, but this totally doesn't work on ubuntu.

the "fix"

The workaround for this bug is incredibly low-tech, but works like a champ. Just add the following line to your .bashrc file.

alias sudo='sudo env PATH=$PATH'

To test it without logging out and back in, just reload that file...

source ~/.bashrc

Not pretty, but it does the job.

syntax and style of programming languages

2009-08-28T20:25:00.001-07:00

When picking a programming language, there are several factors to consider:

syntax/style
supported platforms
previous experience with the language
size of and activity of the community
language features, libraries and frameworks
how well it fits the problem domain
dynamic/static typing
and much more...

The style and syntax of the language has a big impact on the decision when picking a new language, more so than the overall constructs of the language. A developer is much more likely to accept a language with a similar syntax -- if you want to test that theory, ask a ruby developer to pick between smalltalk and python.

Style and syntax are important for a few reasons:

efficiency of writing code
how easily it can be: read, understood, and maintained
effect to the structure and design of the program

Some of these choices have been made by the language designers through the syntax, and others have been made by the community that uses the language. If you want to have code that is maintainable, it has to be easily read and understood, and style/syntax has a big impact on the readability your of code.

examples

Let's take a look at some JavaScript (v1.5):

function allGreetings(people) {
  var firstName, lastName, message, person;
  var greetings = [];
  for(var i = 0; i < people.length; i++){
    person = people[i];
    name = person.firstName() + ' ' + person.lastName();
    if (person.isBirthday()) {
      greetings.push("Happy Birthday, " + name);
    } else {
      greetings.push("Have a Great Day, " + name);
    }
  };
  return greetings;
}

There are certain elements of this code that are required by the language: the "function" and "return" keywords, the curly braces, and the parenthesis on function calls. However some things -- like the camelCase names and whitespace -- are the style elements that have been generally adopted by the javascript community.

Let's take a look at the same code written in Ruby:

def all_greetings(people)
  people.map do |person|
    name = "#{person.first_name} #{person.last_name}"
    if person.birthday?
      "Happy Birthday, #{name}"
    else
      "Have a great day, #{name}"
    end
  end
end

This comparison is not intended to pick on JavaScript, but the Ruby version has some clear wins: such as the "map" method, and implicit return. Most people would agree that the Ruby syntax is "cleaner" or "easier to read" -- and a lot of that comes from the decrease in the amount of punctuation (semicolons, curly braces, and parenthesis).

Note: there a lot of different ways that we could write each of the above examples to help improve the style, but I think that each of these generally reflects the style of code typically written in each language.

There is plenty of debate about syntax and style, so let me fan the flames with my wild claims about what makes for better style...

camelCase sucks

someLanguagesLikeJavaHaveAdoptedTheCamelCaseStyle
doYouFindThisStyleOfNamingEasyToRead

The only advantage that I can see for using camelCase naming is fewer characters. Otherwise, it's generally harder to read, and there is confusion about what to do with acronymns in the name -- should they be TitleCase or ALLUpperCase? I'm looking at you, XMLHttpRequest!!!

languages_such_as_ruby_use_underscores_instead
but_fall_into_the_camel_case_trap_with RubyClassAndModuleNames

Need I say more?

use punctuation sparingly

Punctuation is a powerful and terse tool. Imagine writing a book with only a single non-alphanumeric character...

Wouldn#apostrophe#t it be tough#end of sentence# You could use the special character to start and end #quote# blocks #quote# with special meaning #ellipsis#

###or you would have to assume that the punctuation had different meanings# based on its context # which would be ambiguous# right#

If you rely too heavily on a small set of punctuation, you get Lisp:

((defmethod problem-successors ((prob binary-tree-problem) state)
 (let ((n (* 2 state)))
   (list n (+ n 1)))))

So, we clearly need a little variety in the punctuation, but if we overuse it (cough...Perl...cough) we will write code that we have almost no hope of understanding a few weeks later. How long does it take to figure out what the following code does?

#!/usr/local/bin/perl

$count = 0;
while (<stdin>) {
    @w = split;
    $count++;
    for ($i=0; $i<=$#w; $i++) {
 $s[$i] += $w[$i];
    }
}

for ($i=0; $i<=$#w; $i++) {
    print $s[$i]/$count, "\t";
}

print "\n";

language keywords

Most keywords in a language will be used a lot, and should be kept short because they will be typed so often. For example: def is better than function and var is better than local.

And if you are using a dynamic language (which you should be, by the way), it's also better if your keywords can be runnable commands that obey the same rules as the rest of the code. For example, many languages have a way to import an external library. However that is usually a compile-time feature of the language.

Let's look at importing in Python:

# here we can use "import"
import SomeLibrary

# but here we have to call "__import__"
module_name = "SomeLibrary"
module = __import__(module_name)

And in Ruby:

# because require takes a string
require "foo"

# it works when passed a variable containing a string
mod = "foo"
requrie mod

conclusion

I've only scratched the surface here, but it should give some sense for the importance that a language's syntax (and style) have on writting readable code.

There are an outrageous number of programming languages, with more popping up all the time, and with this variety of languages comes a variety of syntax and style choices. If you are picking a new language (or, heaven forbid, creating a new language), choose carefully.

pptp problems with ubuntu intrepid ibex

2009-01-26T21:49:00.000-08:00

Photo by lightmatter

There have been some networking bugs introduced in Intrepid Ibex.

One that I found particularly difficult to resolve was a problem with the pptp connection. Thanks to the power of Google and the collective wisdom of other Ubuntu users, I found a workaround. I am posting it here in hopes that other people may be able to find it a little easier, and if I eventually reinstall Ibex, I don't want to have to go looking.

First, you need to test to see if your problem is the same as mine. Fire up your pptp vpn connection, and run the following command (in the terminal):

ifconfig

In the output, look for the "ppp0? section, a few lines into that section you will see the MTU size.

ppp0

Link encap:Point-to-Point Protocol
inet addr:xxx.xxx.xxx.xxx P-t-P:xxx.xxx.xxx.xxx ...
UP POINTOPOINT ... MTU:1416 Metric:1

Now you can try to change that MTU size (to something smaller) with a command like this:

sudo ifconfig ppp0 mtu 512

You will want to try some different values to find the sweet spot, but I recommend starting low and working your way up. Once you find a good value for the mtu, you can make the change permanent by editing your /etc/ppp/options file. Search that file for the mtu section, and you will find a line that looks like this:

#mtu <n>

Just uncomment that line and change <n> to your desired MTU size...

mtu 512

...save it, then restart your pptp vpn connection. If you want to confirm that the new MTU size stuck, just run ifconfig again. Hope that helps

ECMAScript 4 breakup hurts (Adobe) Flash

2008-08-16T21:42:00.000-07:00

Now that ECMAScript 4 is dead, the rationalizations begin, and Adobe is doing the breakup-was-a-good-thing speech.

The most common response goes something like this:

This doesn't affect ActionScript 3. If anything, this gives Adobe more freedom to innovate.

But that, quite frankly, is a total load of crap.

Adobe was a major force behind ECMAScript 4, and they've been banging the open source drum very loudly -- they even gave away the Tamarin VM in hopes that it would one day become the de facto implmentation.

Adobe was doing this for three reasons:

Silence critics who disliked the Flash player for being proprietary.
Become the market leader for the ECMAScript 4 language and VM.
Gain support/contributions from a broader developer community.

So now that ECMAScript 4 has derailed, what is the impact on Adobe?

They gained some new developers who saw ActionScript 3 as a "real language," and they lost some existing developers/designers who think ActionScript 3 is too complex. Meanwhile, the rest of the Web shrugs its shoulders and continues its distrust of Adobe's proprietary Flash player. In short, they are back where they started.

Or as Hank Williams brilliatly puts it:

In essence, Adobe has shown up to the prom, but its date has stood it up. ActionScript is now not based on any standard. It is its own, proprietary, albeit open source language. Adobe is on its own island as the rest of the industry moved to some watered down version of what it could have been.

And yes, there are many things that Flash can do which are hard or impossible with open source web technologies. However, the same used to be true when comparing Windows and Linux on the desktop, but today Ubuntu is competing (and often winning) on: features, applications, sex appeal, and ease of use.

Eventually the open community wins because it has an limitless supply of free talent and a collective ability to filter the good ideas from the bad. Adobe can go off on its own and innovate like crazy, but their failure to align themselves with the standards community is going to hurt them in the long run.

tom - August 21st, 2008 3:46 pm

I think Flash's days are numbered, but not due to the derailed ES4 work. The new functionality and innovation appearing in the minority browsers is already giving developers an alternative to flash for some things, and the IE team's reawakening from its long slumber could seal the deal if they start implementing these features too in their run-up to better standards compliance (obviously nobody is holding their breath on that though).

Specifically I'm talking about SVG, CSS extensions, the canvas element, and video/audio elements. I'm not suggesting that those are as simple and integrated to use as flash, but the gap is narrowing very quickly.

But I really don't see the ES4 derailment hurting Adobe in any meaningful way for a while. Not with their huge market share at least. And their only real competition (except for the built-in stuff I mentioned above) is silverlight at this point, which sure ain't any more "open" than flash.

two bit fool - August 25th, 2008 8:47 pm

@tom: There are two reasons that I expect Microsoft will continue to lag behind on the standards necessary to put Flash out of business:

Silverlight -- Any work to improve IE's support of web standards may compete with (or at least, distract from) work on Silverlight.
Backwards Compatibility -- Microsoft learned a hard lesson with IE7, and the desire to "breaking the Web" again could dilute the support for standards.

Hopefully the push from things like Firefox will eventually put enough pressure on them to force the change. But I wonder who will deliver the first serious blow to Flash's dominance: wide adoption of more powerful web standards, or Silverlight?

ECMAScript v4 derails…finally

2008-08-14T21:38:00.000-07:00

ECMAScript v4 was bound to fail. It was making a drastic departure from the current standard, ECMAScript v3, by adopting ideas like: packages, namespaces, early binding, and optional static typing.

ECMAScript is best known for the Javascript dialect, a language that is availble in nearly every web browser. Javascript is powerful because it has a relatively simple syntax, and the flexibility of a dynamic language. The low barrier to entry has turned it into one of the most widespread lanugages in use today. It seems that the pioneers of ECMAScript v4 had lost sight of those benefits as they tried to turn ECMAScript into a "real" progamming langauge.

For whatever reason, Adobe (the company that ate Macromedia) drank the ES4 (ECMAScript v4) cool-aid, and they created AS3 (ActionScript v3). AS3 is based on early drafts of ES4, and it is the language for the latest versions of the ubuquitous Flash player. Adobe open sourced their Tamarin VM to help encourage the adoption of ES3. Then they marketed their "more mature" language so aggressively that Flash developers started convincing themselves that they were better off with static typing and no eval.

When I first tried Flex, Adobe's poster child of AS3, I was stunned. It felt like I had stepped back into the early days of Java. I was contantly fighting the syntax and the framework, interrupted by frequent "breaks" as I waited for the lathargic compiler. After countless expeditions into the nested maze of class documentation, I gave one final laugh at its ridculous verbosity, and walked away. Some other Flash developers noticed the same trend, and they wondered if Adobe was headed in the wrong direction.

Now, much to my relief, the ECMAScript folks have come to their senses, leaving Adobe out in the cold. So, while the ES4 fans look for a scapegoat, the rest of us will breath a sigh of relief and go back to using programming languages that get out of our way.

always encrypt passwords

2008-06-26T21:34:00.000-07:00

Let's pretend that you run a website or newsletter. For fun, let's call it: Gizmo's Tech Support Alert...

Subscriptions to your newsletter are free, but you also have a premium edition which costs $10 per year. You don't want to worry about the security hassles of storing financial information, so you off-load all the financial transactions to a third party.

Since you're not storing any "confidential" information in the user accounts, you assume that the worst thing that an attacker could do with login information is cancel an account. So, you decide to make life a little easier for you and your subscribers.

If someone types in their email and hits the "forgot my password" button, you email them their current password. And, to encourage your premium subscribers to renew, when their subscription is almost over, you send them a friendly email reminder with:

a link to the login page
their username
their password

All seems well. The users don't have to remember their login information, because as long as they remember their email, you can send it to them. This is a nice user experience, but it is ABSOLUTELY the WRONG thing to do.

If you don't encrypt your passwords, you will eventually make some nerd angry enough to write an article about it, and he will use your newsletter as an example (wink).

Unencrypted Passwords are Evil

Even if you don't store confidential information on your site, it is still negligent to store (or email) unencrypted passwords. To make matters worse, if you send an email to your paying subscribers to encourage renewal, that exposes account information in unsolicited emails.

If an attacker gets access to the database or emails, they would have the login information for your subscribers. At the very least, an attacker could start canceling people's subscriptions to the newsletter, and that will be a problem for you; but your users will have a much bigger problem if they used the same password for the newsletter subscription as they did for another (more important) account.

While you may be savvy enough to have a different password for every website, lots of other people look at their limited time and memory, and don't realize the risks of reusing passwords. Even if you advise them to have unique passwords, the majority of users will continue to use the same password on multiple sites. So it is the responsibility of the website developers and operators to keep passwords safe, by not storing them and by not emailing them.

How to Handle Passwords

First off, assume that you don't know how to safely manage passwords -- even the smart folks at Mensa seem to have gotten it wrong. There are a lot of hard won lessons in website security that you don't want to repeat. So hop on to your favorite search engine and start reading (search for things like: secure hashing passwords). Then find and use existing tools and libraries for your website's security.

In case you can't find any existing security solutions, or if you still want to brazenly create your own, here is a list of the things your website should do...

When a user creates a new account:

require an email address and send a link to that email address to activate the account
- make it clear that you will never sell or give away their information unless required by law
store a hash of their password using bcrypt (or at least sha-1)
use salt to prevent rainbow table attacks
use a turing test (e.g. captcha) to prove your new user is an real person
- note: captcha is not 100% reliable (and getting less so)
- consider alternatives like word puzzles and image identification

When a user tries to login:

apply the hashing algorithm to their submitted password and compare it to the stored hashes
give the same error message when the username is wrong or the password is wrong
- if you tell them which part of the login was wrong, they can guess to find usernames
when the login is invalid, insert a short delay before displaying an error, to slow down bots
lock an account if it fails on several consecutive login attempts
- this lock can: be self-expiring, require administrative action, send an email to the user, or require captcha to unlock
after several consecutive login attempts from a single IP address fail (on one or more usernames), block that IP
- this block can be self-expiring, require administrative action, or require captcha to unblock

When a user forgets their password:

have them submit their email address
then show them a message explaining how long it may take to get the email
don't tell them if the email is invalid (or an attacker could keep guessing to search for valid email addresses)
- just say: "if you don't get the email, check the spelling of your email address and try again"
send the email: it should explain why they received it and contain a link to a Reset Password page
- the link should NOT include any account information, like email address or username
- the link should include a UUID to guarantee that no one can guess it
- after a certain amount of time (e.g. 15 minutes) the link should expire
- clicking the link after the time expires will open a page with a link to the Forgot Password page and a message explaining the expiration
don't send the forgotten password email to a single user more than once until the previous "forgot password" link has expired

These requirements are tricky, and I've probably screwed up some and entirely omitted many others. This is a wheel that doesn't need reinventing. So I'll say it again, find and use existing tools and libraries to handle the security on your website.

You don't want your site be some nerd's example of a security faux pas.

my brief affair with a mac book pro

2008-05-15T21:32:00.000-07:00

It finally happened. Last week, I got a MacBook Pro for work.

I’ve been a proponent of Apple products for a while now. Years ago, my wife and I bought a PowerBook, and when it needed to be replaced, we didn’t hesitate to get a MacBook. I’ve been very happy with both machines: no fighting viruses/trojans, great bundled software, simple, usable, and no-hassles.

When people ask for my recommendation on a new computer (as if using computers at my job makes me somehow qualified), I ask if it is for personal use: email, internet, and such. If so, I say: get a Mac, because a Mac makes for a great personal computer.

So, it may be a little surprising to hear that I am trading in my new MacBook Pro for a run-of-the-mill MPC laptop. Why? Three reasons…

#1: Apple Store

I was eager to get my new laptop, so I ran over to the Apple store. As it turns out, if you are looking to make a quick purchase of an Apple product, the Apple store is the wrong place to go. It’s an interesting idea to remove the cash registers while hiding all the stock in the back room, but it is not practical for two very important reasons:

First-time customers don’t know where to pay
You have to wait for (or go find) an employee for any purchase

After waiting about 10 minutes, I finally had to interrupt two employees to ask for help. They were too busy chatting (probably about how cool their iPod-ish name tags were) to ask me why I was patiently standing there looking helpless. Then, I had to endure several minutes of smarmy Q&A before he understood that all I wanted him to do was go in the back and get a MacBook Pro.

#2: Walled Gardens

The robust and seamless nature of the Mac (and iPhone) is largely due to the control that Apple has over the entire process: hardware, software, distribution, etc. It’s hard to imagine that equally compelling products could come from a more open ecosystem, and if they did, it would take much longer.

To me, it’s a design vs evolution (or craftsman vs committee) debate. The OSX vs Linux comparison makes for a great example…

With OSX, there is a small group in charge, and they exert their control to create a very consistent and stable platform. The focus is narrow, so the details get taken care of. Also, with lots of control, it is easier to have a high level of integration between the parts (a.k.a. seamlessness). The downside is that potential good ideas from the outside are often locked-out.

Linux, on the other hand, is more open and has less filtering from the top. This means that you get an amazing diversity of ideas, which allows innovation that can’t happen in a closed environment, but it also creates a ton of mediocre and crappy ideas too. So it becomes a survival of the fittest for Linux features/apps. The downside to the open system, is the dilution of effort. There is so much diversity that it takes longer to get enough people focused in the same direction to make significant progress.

In the long run, bet on the open system, because walled gardens don’t last.

#3: Old Habits

When I’m working, I want efficiency, and if I have to hesitate because the keyboard shortcut is different or because I need to reach for my mouse, time is lost. Not only do I lose time because it physically takes longer, I lose time because I have to focus on the keyboard/mouse and then return my focus back to the actual work. A good tool should become “invisible” so I can focus on the work, not on the tool.

My old laptop was a dual-boot machine with Ubuntu Linux v7.10 and Windows XP, and I spent 95% of my time in Ubuntu. I’m a keyboard maniac, so when I originally transitioned from Windows to Ubuntu, it was a very easy transition because the keyboard shortcuts in Ubuntu are so similar to Windows.

True, if I had been using a Mac all along, then I would be used to its keyboard shortcuts, but that is just a “walled garden” argument design. The Mac has a small percentage of large market, and when they don’t conform to the defacto standards, they get punished by the fact that consistency is one of the strongest contributors to usability.

The Break Up

Mac, I’m afraid that this is goodbye. You are sexy, and we had some good times. Playing with photos and movies was fun, but I want to get serious, and you just weren’t as open as I had hoped. I know you’ll do fine without me; there are lots of designers and trendy people out there to make you happy.

I wish you the best, and remember: It’s not you. It’s me.

e4x to the rescue (sort of)

2008-05-08T21:30:00.000-07:00

Note: This is the follow up to a old, poorly-written, rant on e4x where I used the wrong terms and left huge holes in my arguments. I can only hope to do so poorly this time.

A simpler DOM

Many developers (myself included) tried to scab together our own object-ish XML processing. Usually this meant converting the XML into a big "object tree" where the names of the object properties were the same as the XML nodes. This would allow us to turn:

<root><foo>hello</foo></root>

into:

root.foo // returns "hello"

And when we did this, we quickly ran into problems:

Attributes: What if an attribute had the same name as a child node?
Collections: It would be nice to skip array-like access for nodes that only have a single child, right?
Naming collisions: How do we make sure that the properties and methods that we need to have on a node don't conflict with the names of the child nodes? For example, what if a node is named "children?"

e4x bring object traversal to the masses

So e4x comes along, and it looks a lot like that stuff that developers had been scabbing together. It added some nice syntax for "querying," and they prefixed the attributes with an @ symbol -- so we don't have to worry about attribute names and node names colliding -- but otherwise it's mostly the same.

The two places where they dropped the ball were on collections and the naming collisions. Let's ignore the collection problem for now and talk about their "solution" to the naming collisions that can occur between methods/properties and node names. They decided that all methods/properties of a node (children, length, toString, etc.) would be accessed as methods, requiring parentheses, and all the child nodes would be accessed as properties; no parentheses.

It's too bad that they didn't just use a prefix to distinguish between traversing xml nodes and methods/properties. Much like the attributes are prefixed with the @ symbol, I wonder why they didn't use some prefix (a # sign, perhaps) for xml nodes.

This is a big problem because it creates an inconsistency with most languages, because they follow a rarely discussed rule-of-thumb (see the When to Use Properties vs. Methods section)...

* methods/functions are verbs: perform an action
* properties are nouns/adjectives: read/write values

Let's look at some Javascript for example:

* String.length
* Document.links
* Window.parent
* String.toUpperCase()
* Document.write()
* Window.close()

Now let's see if e4x follows that same rule:

* XML.name()
* XML.length()
* XML.parent()
* XML.replace()
* XML.insertChildAfter()
* XML.contains()

Nope.

And what happens when you try to implement e4x in a language like Ruby? Ruby has no properties and parenthesis on method calls are optional.

In case you missed it, I had a bug where I called node.children, instead of node.children() because I relied on that rule-of-thumb. It served as another fine example of why consistency is so critical to usability.

Random light switch trivia:
In the United States it is universal for the "on" position of a toggle switch to be "up", whereas in the UK, Australia, and New Zealand it is "down." -wikipedia

Tom - May 9th, 2008 9:51 am

Good points. As you pointed out, the issue comes down to XML element name mapping in the object graph. Since they went down the road of using the exact names from the XML, they needed to make the built-in properties be methods to avoid name collisions with elements that might be named "parent" or "name", etc. (which are probably commonly found in XML).

e.g. given <foo><name>bar</name></foo>, x.name is different than x.name().

But you could also make the argument that constantly writing x.#foo.#bar is less convenient (and hence less usable) than x.foo.bar. It's really more of a trade-off for consistency in attribute/method conventions vs. the readability of the code/API.

the pains of xml processing

2008-01-27T21:25:00.000-08:00

This is part one of my xml/e4x ramblings...

XML is all the rage these days. But, like many over-hyped technologies, it has become a victim of its own success, leading to all sorts of crazy ideas. If you find yourself using XML for anything other than document markup or data transport, worry.

The most common challenge you will face when dealing with XML is extracting the data. This is known as XML processing has often been accomplished by using XSLT, DOM, or SAX.

Do you speak XSLT?

XSLT is a bit like learning a foreign language:

declarative programming
strange and complex syntax
templates, patterns, and rules

The easiest way to scare you away from XSLT is with a tiny example. That's crazy, right? Using XSLT on XML looks a lot like "fighting fire with fire." Let's be honest, despite all the hype, XML is no joy ride; it can be so aggravating that it makes the Linux guy almost use the F-Word. Add XSLT to the mix, and who wouldn't start cursing like a sailor?

The dark days of DOM

So, with XSLT out of reach for most sane people, many turned to DOM (Document Object Model). The great thing about DOM is the consistent mapping between the structure of the XML and the structure of the DOM objects. Start at the root node, get the child nodes, then get the children of those child nodes. And on it goes.

Unfortunately, the DOM syntax almost encourages ugly code. Even the more respectable sites were putting out crap examples like this:

document.getElementById("to").innerHTML=xmlDoc. / getElementsByTagName("to")[0].childNodes[0].nodeValue;

If you've spent any time in DOM-land, you probably carry the shame of writing at least one of these brittle nuggets:

xml.firstChild.childNodes[2].lastChild.childNodes[4]. / getAttribute('i_hope_this_xml_never_changes');

SAX player

Now let's contrast the declarative style of XLST with the event-based approach of Serial API for XML (SAX). Using SAX reminds me of those old music boxes. The ones with the metal drums that turn, making the bumps pluck the metal forks to produce each note. In SAX, you create callback functions (the metal forks), and as the SAX parser (the metal drum) reads through the XML, it fires events (the bumps).

How was that for a strained analogy?

So, SAX has big problems:

the burden it puts on the programmer to keep track of their location within the document
the event-based model can be off-putting to programmers who are more comfortable with the typical step-by-step procedural coding

Stay tuned next week for...e4x to the rescue (sort of)

why adobe flex makes me want to cry

2008-01-09T21:21:00.000-08:00

Adobe Flex can be used to create some impressive UIs that can be delivered over the most established plugin in the universe. For this and other reasons, I am forcing myself to use it on my current project. It is a love/hate relationship, with very little love.

For a moment, let's ignore the pain of super-verbose static typing, and the crushing weight of a class hierarchy that makes the Java class libraries seem thin . . . let's focus on the basic inconsistencies in the API. We'll start with some of the widgets that you would use on an edit form: TextInput, DateField, NumericalStepper, and ComboBox.

You may have noticed that TextInput and DateField lack some basic naming symmetry. And if you forget, and use a TextField, well that is a Class too, but it's not at all what you want. Why they couldn't call it DateInput is a mystery to me. But it gets worse...

All of these edit controls have properties (or functions) to set the value that shows up in the UI control. It seems like we could take advantage of a little ad-hoc polymorphism and name the property something like: "value" for all those different classes. So, then it wouldn't matter if I had a TextInput or a DateField, I could just call:

uiComponent.value = something

Instead they've given us:

DateField.selectedDate
TextInput.text
NumericalStepper.value
ComboBox.selectedItem

. . . awesome. But we are not done yet. I've saved the best for last, because this one just bit me . . . again.

Since we are dealing with UI classes, hierarchy abounds, and we need to get at the parent and children of most objects. Well, if we are using any of the UI containers we call getChildren(). If we are using a class like CompositeEffect, we need to call the children property. And if we want to get the children of an XML node we need to call the children() function, not the children property!!!

I just wasted 20 minutes (plus another 30 on this rant) because I was calling .children instead of .children(). And now for the best part . . .

The super-strict compiler, with all the help from the carpal-tunnel-inducing variable-typing information that I had to hammer into the code, didn't even throw a warning.

Are you @&#$ kidding me?!?

So, I write a rant that no one will read, say 'calm blue ocean' a couple hundred times, and dream of a day when I will be back in the comforting embrace of languages like Ruby.

By the way, Ruby has a solution so simple (and elegant) to the "is it a property, or is it a function?" problem: There are no public properties. It's always a method. But, the parenthesis are optional.

xml.children
- or -
xml.children()

. . . it's all good in Ruby-land.

Here's my guess as to why we ended up with XML.children():

Flex dev #1: an XML object has to be dynamic to allow traversing the names of the nodes, so we can't do any compile time checks on properties.
Flex dev #2: yeah, if someone had xml like this:

xml = <root><foo>hello_world</foo></root>

. . . then xml.foo should refer to the "foo" node.
Flex dev #1: so we'll have to make children a function call instead, otherwise it will get confused with the node name in xml like this:

<root><children><foo></foo></children></root>
Flex dev #3: Wait, if xml.children will return the "children" node, isn't that the same as calling the children method? But more importantly, if it's going to be a function shouldn't we rename it to getChildren() so it's clear that it's a function call and not a property?
Flex dev #1: shut up, rookie!

Ugh.

Paul B - January 9th, 2008 7:10 am

I was thinking about moving to Flex from Flash 8. Now I'm not so sure. I'm not the best developer in the world to begin with, so fighting through this chaos may not be a good option.

Thanks for the insight.

BTW, Flash 8 has it's own set of frustrations as I'm sure you know. Maybe someday Adobe will get on the ball and clean up this mess.

Tom - January 9th, 2008 7:13 pm

based on your example and some googling, it looks like flex implements e4x, so you can blame more than just adobe engineers for children().

I think you were on the right track with your theoretical conversation between flex engineers as to why the compiler can't catch your error, too. Flex/ActionScript/JScript.NET/Javascript2 all allow for more strict type checking, but they also must allow for old-style vars and "expando" dynamic properties. That's actually the beauty of e4x:

var el = <foo><bar/></foo>;
alert(el.foo.bar);

You don't need to use the chilren() property, you can just access the XML DOM like a javascript Object.

But sometimes the compiler can't figure out what you've done is wrong at compile time:

var x:XML = read_from_somewhere();
alert(x.foo.bar); // valid????

I think this can only be caught at runtime, if read_from_somewhere() doesn't return xml that matches the properties specified.

And while getChildren() might make it less likely you'll accidentally use it incorrectly, the compiler would still need to allow x.getChildren to be accessed as a property in the event that you define xml like <getChildren/&gt

I definitely hear you on the inconsistency with the "value" properties of widgets though. Nearly all toolkits suffer that.

two bit fool - January 10th, 2008 6:38 pm

Paul,

Flex isn't all bad. It has some very respectable UI components. And the availability of the source code is nice.

But it does have a definite "Java smell".

two bit fool - January 12th, 2008 7:03 pm

Tom,

Good call. e4x definitely deserves some "credit" for my headaches. So much so, that I'll probably write a separate post about it.

mzx - June 24th, 2008 7:30 am

first learn than blame..
flex is working fine for me. When i feel i have troubles with some say DateInput, im welcome to extend and override whatever i need in few lines of code. So add method value() to each uicomponent u need, or create getMyChildren for XML class this is not big deal imho

two bit fool - June 26th, 2008 10:46 am

mzx,

I wasn't saying that we can't "fix" the naming problems. I'm just lamenting the fact that the Flex designers failed to be consistent in such an obvious case -- a "value" property for UIComponents.

As for extending the XML class, you can't. The XML class is final and can't subclassed. Even if you could, it still wouldn't resolve the problem that all property access on an XML object is DOM traversal. So, you can't create a getter called "children" to allow this: node.children

It would have to be a function, called like this: node.children()

Then programmers are faced with the "is it a property or is it a function?" problem because "children" is named like a property but called as a function. This is a problem that I talk more about in another article.

Dylan - June 27th, 2008 10:24 am

Your post actually uncovered some answers to the .value, .text, .children .getChildren() and .children() I was looking for. Obviously I'm having the same frustrations you did and it's reassuring to see that I'm not alone.

Thanks for your post.

two bit fool - June 28th, 2008 7:55 am

Dylan,

It's nice to know that my rant actually helped someone.

ECMAScript v4 derails...finally - August 14th, 2008 9:55 pm

[...] When I first tried Flex, Adobe's poster child of AS3, I was stunned. It felt like I had stepped back into the early days of Java. I was contantly fighting the syntax and the framework, interrupted by frequent "breaks" as I waited for the lathargic compiler. After countless expeditions into the nested maze of class documentation, I gave one final laugh at its ridculous verbosity, and walked away. Some other Flash developers noticed the same trend, and they wondered if Adobe was headed in the wrong direction. [...]

Mike - October 14th, 2008 11:52 am

...but thats not all: Flex have memory leak issues, too. I thought about develop my next whole project with Flex or just use a component from Flex.

By testing my application, I found out, that there are many memory leaks, so you cant use it for a long running applications.

e.g. the following two line will cause a memory leak:

private function httpServiceResult(evt:ResultEvent):void {
xmlDatasource.removeAll();
xmlDatasource = new XMLListCollection(XML(evt.result).children());
}

Jovi - March 19th, 2009 10:26 am

I am pissed for almost an hour now, that there is no such thing as the JS getElementsbyTagName in Flex. I am probably too confused to see the easy solution, but say i wanna reset all textinputs somewhere, how can I get a list with all of them, no matter how deep they are nested in containers?

I must write my own recursive function for that, i guess.
Unfortunately , I am the total recursion noob and cannot even think the solution in my had.
Meh.

apple dropped the ball with iTunes on Windows

2007-03-06T21:05:00.000-08:00

Let me start by saying that I own a Mac -- a PowerBook to be specific. I like it, and I like Apple; they've got a lot going for them:

iPod/iTunes mania
fantastic marketing
sleek-looking, high-quality hardware
ravenous fans that would happily buy iPoop

But there are two things that make me curse Apple:

DRM
iTunes on the PC.

I'm not going to rant about DRM, because that song has been sung too many times already. Yes, DRM sucks, but it's the cost of working with the music and movie folks, and Apple has done a decent job of hiding the headaches associated with DRM. Sure, they have to own hardware, software, and the entire purchasing process to make DRM transparent, but they did it, and better than anyone else.

So let's talk about iTunes on the PC. No other piece of software from Apple has such a big potential for impact in the PC world (with the possible exception of Quicktime, but that honeymoon ended years ago). iTunes is the ultimate "why you should switch to Mac" marketing opportunity for Apple. A chance to show these poor PC users what they have been missing out on for all these years...and Apple dropped the ball, big time.

If you don't believe me, get a PC (I'm using a WinXP laptop with a1.7GHz Intel Centrino and a gig of RAM) and use iTunes. Import lots of music, subscribe to podcasts, and just use it for a while. What you will find is that the UI will often become horribly unresponsive.

It's not just that it takes too long to do the hard stuff, it fails to show basic feedback to user input. I'll click a button and the button won't depress, click on a menu and get nothing, grab the scroll bar and find that it is frozen in place. This is unforgivable, especially from a company that has been an industry leader in software usability.

The fans will cry, "but iTunes runs fine on a Mac!" Well, it's better on the Mac, but it is not perfect. And if you, like me, got one of those pre-Intel Macs -- the ones that Steve Jobs swore were "the fastest computers in the universe" -- you have probably seen some of those same UI gaffs on the Mac.

Sure, I'll give Apple a little slack, because they are writing software on someone else's platform, but they didn't even satisfy the most basic response time requirements of a GUI. If, you think that the platform can take the majority of the blame, then try Picasa; it makes iPhoto look slow and simple.