November 2007 - Posts
Over Thanksgiving, I had the task of setting up of a new PC for my mother-in-law over the holidays, a task which I was happy to do, but gave me another chance to get up close with Vista. At home, I have reverted to running XP, for reasons which I discussed in the last post of this series.
I had higher expectations for this new machine as my plan was to basically set it and forget it, since it will mostly be a web-browsing, email and photo machine. Sure enough, when I kept my tinkering to a minimum, I was rewarded with a much smoother experience. This was also helped by the lack of pre-installed trial/adware on this new Dell Vostro.
The only bumps along the road were the old printer not working, which is more Lexmark's fault than Vista's and the typical UAC behavior of asking me to confirm twice the heinous act of renaming a desktop shortcut. Then there was Windows Update, which after helpfully updating the Word/Excel Viewers, also helpfully set them to be the default file handlers for those types. A nice gesture, although it ignored the fact that I had set Open Office to be the default.
So beyond the fear that the next auto update from Windows Update will knock out the file associations, I have a tenuous hope that this PC will be able to perform the basic tasks of email, web browsing, light photo editing, office document editing, printing and scanning, with a minimum of maintenance.
These are modest expectations for a modern computer. Recently I have been seeing more attempts to make computers like appliances, with limited functionality, but increased reliability. For me, being a computer enthusiast, it is the general and not limited nature of computers that make them so interesting. However, for the majority of those who probably don't really care about the details as long as they can complete task x, y and z, an appliance approach could make sense.
I'll see how Vista fares in this role, but in the meantime, I fired up the old virtual machine and have been testing out gOS, the Ubuntu derivative installed on the low cost gPC from Walmart. Look for my impressions, an overview of its functionality and a possible explanation for the following clip art in the next installment of "OS Chasing".
In his blog, author Jonah Lehrer relates the story of several experiments run around wine tasting. One experiment involved coloring a white wine red, the other involved putting the same wine in two different bottles. In both experiments, expectations overrode the reality of the wines. So the same wine in the more expensive bottle tasted better and the white wine that was colored red tasted like a red wine.
In his post, The Subjectivity of Wine, Lehrer presents the argument that the exterior factors, the context of an object and our expectations towards it, have just as much influence on our perception of that object as its inherent qualities:
As the philosopher Donald Davidson argued, it is ultimately impossible to distinguish between a subjective contribution to knowledge that comes from our selves (what he calls our "scheme") and an objective contribution that comes from the outside world ("the content").
Lehrer's post may make you feel better if you ever felt snubbed at a wine tasting by a know it all, but it also has important implications for software development. The context of a piece of software can matter just as much as its content. Meaning that there is an explanation behind the common complaint you hear from developers than that an "inferior" product is displacing their preferred and technically superior one.
Defining the context of a piece of software is tricky. The user interface is so inherent to software that it isn't really fair to call it the context. A more valid definition of the context of software would focus on the soft factors around it. Is the producer of the software seen as a reputable and reliable vendor? Was the software coded by senior developers or junior interns? Is it free or does it cost money? Is it a much anticipated upgrade or a forced one?
A lot of these questions are good ones to ask. Since most of us don't have the time or access to evaluate the software we use at the code level, it is a useful mental short-cut to feel more comfortable about a product coming from someone you trust (since they have a proven track record) or a product you paid a lot for (surely they would not be able to get away with charging a lot for something that wasn't good). Like all short-cuts though this approach is not full proof. There are innumerable examples of the free products that are superior to their commercial ones. Not everything from Apple will help harness your creativity, etc.
Of course a product that fails utterly at its purpose will not be able to disguise its flaws from its users. However, it is worthwhile to note that part of the experience of using a piece of software is how you feel about it; how you feel about the software depends not only on functionality, but on the context of it. So, if you have spent the time it takes to make a quality technical solution, take some extra time to think about how you can put that solution into the most favorable context. Having the best code isn't always enough.
Amazon.com has been around for what seems like an eternity in Internet time; it was launched in 1995 as on online bookstore and now sells videos, music, groceries and pretty much anything else you can think of.
Amazon.com and its aggressive business plan of high volume, low (or no) margin sales off of a deep book list have been blamed for the downfall of the small, local bookstores. I won't dispute that from an economic standpoint, but I think it unfortunately obscures the interesting things that Amazon.com does as a book retailer. In fact, I would argue that even without the price and depth advantages it enjoys over brick and mortar retailers, Amazon.com provides a superior book buying experience.
How so? Let's take a look how your experience might shake out if you are thinking about buying the popular new book, Age of Turbulence, by former Fed chairman Alan Greenspan. If you go into a local bookstore you will almost surely find a copy available sitting in a central display. At that point, if you are determined to buy that book, then you go ahead and purchase it, easy enough.
However, if you are not really sure, what do you do? You can ask an employee of the store and probably get a decent review that way, but in general you are left to ponder the dust jacket of the book and perhaps a cut-out of a New York Times review that has been placed in the display.
On the other hand, let's say you point your browser over to Amazon.com and bring up Greenspan's book. You are now confronted with a torrent of information. You can see a quick "star" rating, watch a video of people's reactions to the book, read a few editorial reviews, numerous customer reviews and blog posts by Alan Greenspan. The book is further placed in context as you can see what other customers who looked at this book bought or viewed and what users' top books lists it made.
Whichever way all this information sways you, you are certainly making a more informed decision that you were at the local bookstore. Also, even if you don't purchase anything, you can learn by clicking around and following the links to other related content. In effect, this linked content lets you browse the online book store in a somewhat analogous way to browsing the shelves of a brick and mortar store.
In other words, buying the book on Amazon.com is a much richer experience than going to your local store. Amazon.com may not be a "sexy" brand, but it perfectly illustrates the promise of Internet applications, which takes something we are used to, buying books, and adds online features to make it better. If you then add back price and the depth of available books as points of comparison, Amazon.com becomes even more appealing.
As an avid reader, while I enjoy walking around my local book stores, I can also appreciate the features Amazon.com have brought to the book buying experience. Putting on my other hat as a software consultant, I can learn a lot by studying what Amazon.com has done to enhance the user experience of their product by leveraging uniquely online features.
In case all this Erlang code and exposition has you feeling glum, check out this video from the past, featuring the Erlang master himself, Joe Armstrong, and some really excellent phones:
http://video.google.com/videoplay?docid=-5830318882717959520&hl=en
Once again proving Paul Graham's point that programmers are artists at heart...
I recently posted about how I used code simulation to understand a piece of Erlang code by explicitly writing out the expansion of a function with a given input. That was truly a manual effort and while it was useful to me, there are of course ways of following the flow of a program without all that writing.
The technique I'll focus on in this post is using console output statements. Like writing out a function expansion by hand, using this technique is not going to convince anyone of your coding prowess. However, if like me, you often learn best by seeing a program work, then this approach can be a great learning tool. If you use them wisely, your output statements become annotations, like a mini set of CliffNotes for your program.
So far this is a pretty vanilla point that I'm making. So, let's narrow the focus a little bit with a concrete example, another Erlang program, also from Programming Erlang. The point of this program is to create a ring of linked processes and send a message around the ring various numbers of times. By timing the execution and varying the number of processes in the ring and the number of times the message goes around you presumably gain some insight into Erlang's proficiency at handling a large number of processes at once.
The author, Joe Armstrong, does not provide a solution in the book. After some hacking around, I got pretty close, then looked online and found a solution that I could understand, kindly provided on drc's blog, Halfbaked Ideas. It is actually pretty well commented code, but even with the comments, I was not totally comfortable with it. So I created my own "annotated" version by adding a few more output statements:
-module(ring).
-export([start/2, foo/1, bar/1, timer/0]).
%%----------------------------------------------------
%% Create N processes in a ring.
%% Send a message round the ring M times,
%% so that N * M messages get sent.
%% Time performance for different values of N and M.
%%----------------------------------------------------
foo(Next) ->
receive
{0, Any} ->
io:format("foo process ~p sending stop message to process ~p~n",[self(),Next]),
Next ! {0, Any}, %% send the 0 to tell everyone to shut down
io:format("foo process ~p stopped itself~n",[self()]);
{N, Any} ->
io:format("foo process ~p sending message to process ~p~n",[self(),Next]),
Next ! {N, Any},
io:format("foo process ~p back in receive loop~n",[self()]),
foo(Next)
end.
bar(Timer) ->
receive
{0, Next} ->
io:format("bar process ~p stopping timer~n",[self()]),
Timer ! done,
io:format("bar process ~p stopped itself~n",[self()]);
{N, Next} ->
io:format("~nbar process ~p starting a round of messages by sending to process ~p~n",[self(),Next]),
Next ! {N-1, Next},
bar(Timer)
end.
timer() ->
statistics(runtime),
statistics(wall_clock),
receive
done ->
{_, RT} = statistics(runtime),
{_, WC} = statistics(wall_clock),
io:format("Total time=~p (~p) milliseconds~n", [RT, WC])
end.
%%----------------------------------------------------
%% construct a chain of processes
%% process J-1 routes msgs to process J for all J < K
%%----------------------------------------------------
chain(0, Pid) -> Pid;
chain(K, Pid) ->
chain(K-1, spawn(ring,foo,[Pid])).
%%—————————————————-
%% N is the number of processes in the ring
%% M is the number of times msgs circle the ring
%%—————————————————-
start(N, M) ->
%% N-1 processes are of type foo, one is of type bar
A= spawn(ring, bar, [spawn(ring, timer,[])]),
B= chain(N-1, A),
A ! {M, B}.
As I said in my previous posts, I can't hope to teach everyone Erlang and I assume most visitors here are unfamiliar with it. So this code still probably doesn't make sense to most of you. With that in mind, take a look at the output from running this program with a ring of 5 processes and the message going around twice:
>ring:start(5,2).
{2,<0.10079.0>}
bar process <0.10075.0> starting a round of messages by sending to process <0.10
079.0>
foo process <0.10079.0> sending message to process <0.10078.0>
foo process <0.10079.0> back in receive loop
foo process <0.10078.0> sending message to process <0.10077.0>
foo process <0.10078.0> back in receive loop
foo process <0.10077.0> sending message to process <0.10076.0>
foo process <0.10077.0> back in receive loop
foo process <0.10076.0> sending message to process <0.10075.0>
foo process <0.10076.0> back in receive loop
bar process <0.10075.0> starting a round of messages by sending to process <0.10
079.0>
foo process <0.10079.0> sending stop message to process <0.10078.0>
foo process <0.10079.0> stopped itself
foo process <0.10078.0> sending stop message to process <0.10077.0>
foo process <0.10078.0> stopped itself
foo process <0.10077.0> sending stop message to process <0.10076.0>
foo process <0.10077.0> stopped itself
foo process <0.10076.0> sending stop message to process <0.10075.0>
foo process <0.10076.0> stopped itself
bar process <0.10075.0> stopping timer
bar process <0.10075.0> stopped itself
Total time=16 (16) milliseconds
This may seem like an almost trivially basic technique, but that criticism is only half right. It is a basic technique, but it is not trivial to examine a program this way. Just think of it as a whiteboard session without the smell.