Clarity recently held its 15th Tech Challenge (TC). TCs are recurring coding competitions amongst the consultants here. Oftentimes the problems are released weeks in advance, such as developing an AI for a card game, and at the deadline the various solutions are tested against each other. TC 15 was the third time that we’ve done a Top Coder style tech challenge, where we compete to solve as many short coding problems in 90 minutes as possible.
I like this type of TC because it requires virtually no prep time to compete in (maybe some prep time to win) and it gives me a chance to work on some pure logic puzzles, the likes of which I don’t see every day during client work. I had a respectable finish, but was a little upset over one of the problems I missed.
The problem was an “easy” one, but in my rush to get through as many problems as possible, I made a mental modeling mistake. The problem statement was:
Southern China is suffering from a heavily snowy winter. The heavy snow even causes the closure of an important highway connecting southern and northern China. You've got several reports containing the start and end points of highway segments covered by heavy snow. Given those reports as two int[]s startPoints and endPoints, you are to return the total length of highway segments covered by snow. Note that the reported segments may overlap.
Some further constraints were given, basically allowing me to dispense with any error handling and then some test examples were given:
Example 1: {17,85,57}; {33,86,84}
Returns: 44 (these segments don't overlap)
Example 2: {45,100,125,10,15,35,30,9}; {46,200,175,20,25,45,40,10}
Returns: 132 (There are 3 segments covered by snow: 9-25, 30-46 and 100-200)
<-- and so on -->
My solution was able to pass all the given test cases, except for the first one. I ran out of time before I fixed it, but it turns out my overlap code was a bit off, and in the first example I was counting the segment between 84 and 85 as being snowy, when it was actually a gap.
Beyond a dish of humble pie for myself, the reason to bring this up was that it got me thinking about how much graphical visualizations can help to model a problem. For example, I am pretty sure I would have gotten this problem right on the first try if the examples had looked a bit more like this:
I’ve been studying dependency injection and inversion of control after seeing them mentioned, referenced and praised in too many places to ignore. From Martin Fowler’s years’ old hand wave of approval, to the more cutting edge of seemingly everyone involved in ASP.NET MVC, this pattern has gotten a lot of good press. Microsoft has even issued its an application block for it called Unity. All of which is not to say that this must be good because x said so, but I was curious to take a deeper look.
I took a look at a simple example provided by Oren Eini aka Ayende Rahien, prolific blogger and Rhino.Mocks driving force, in a post from late 2007, Building an IoC container in 15 lines of code. He notes in later posts that this is definitely a proof of concept, but it was helpful for me to see how simple dependency injection could be. In essence his container is just a wrapper over a dictionary of constructors, keyed by type.
The container knows which concrete implementation goes with which type, but the code that uses the type does not. Therefore, the code that uses the type is not directly dependant on its concrete implementation, instead this dependency is “injected' at run time by the container. So dependency injection helps you nip a large dependency tree in the bud, which is a pretty strong argument in its favor.
I’ll have more to say on this topic later, and while I won’t copy and paste all of Ayende’s code into my post, I did want to use a trimmed down version of his code to point out an interesting bit of C# behavior I didn’t know about before:
//cut down version of IoC container class
public class DemoContainer
{
public delegate object Creator(DemoContainer container);
private readonly Dictionary typeToCreator
= new Dictionary();
public void Register(Creator creator)
{
typeToCreator.Add(typeof(T), creator);
}
public T Create()
{
return (T)typeToCreator[typeof(T)](this);
}
}
//calling code
DemoContainer container = new DemoContainer();
//registering dependencies
container.Register(delegate
{
return new NHibernateRepository();
});
//using the container to get back the NHibernateRepository
IRepository myRepository = container.Create();
The part of this code that I found hardest to grasp at first was that the Creator delegate is declared with a signature that expects one argument of type DemoContainer, but the anonymous delegate used to create the NHibernateRepository is actually a no argument delegate.
The usual behavior is that a delegate has to match the signature to be bound. However, as Ayende’s post demonstrates, and was confirmed by some work in Visual Studio myself, anonymous delegates with no arguments are a special case in C# that can bind to any delegate with the same return type.
This is explained by an MSDN article as follows:
However, if you omit the empty parens after the delegate keyword altogether, you are defining a special kind of anonymous method, which could be assigned to any delegate with any signature
So an interesting feature of C# 2.0 and beyond that I didn’t know about another benefit of reading other people’s code. Even in a 15 line example, you might learn something new.
* Ayende’s code also provides a nice example of the use of closures. So I’ll give him credit for using two lesser known C# features in just 15 lines.
While we’re still processing all the news to come out of this year’s PDC it is worth looking back to remember that it was only 8 years ago at the 2000 PDC that C# and .NET was formally introduced. As we approach C# and .NET 4.0, hot on the heels of .NET 3.0/3.5 and the alphabet soup of WPF, WCF, WF and Silverlight, it can be tempting to complain that it is hard to keep up.
On the flip side, it is not too surprising to see all this growth when we remember that we’re still in the relatively early years of this language and platform. For comparison’s sake, Python was introduced in 1991 and Ruby in 1996, neither of which are popularly considered to be particular old or staid languages.
While Microsoft itself has the reputation for being slow and lumbering, the .NET community is amazingly vibrant as this young platform continues to grow and change. As much as I’ve worked with Python and Ruby in my spare time, that has fallen off as I find more and more opportunities to learn in .NET.
A great example of this is the ASP.NET MVC project, which has helped provide an easy avenue for traditionally outside of .NET concepts to filter into the ecosystem ranging from official support to specific libraries like JQuery, to API level constructs that better support TDD methodologies.
Without knocking other languages or environments, it is easy for me to say that I work with one that is dynamic, stimulating and forward looking. While software is only part of my job, liking the software I work with certainly makes that job more enjoyable. Of course, this doesn’t help with the perennial problem of convincing many outside of this line of work that enjoying it is even possible.
A Good Presentation
Two weekends I went to a San Diego Dot Net User Group meeting that featured two presentations by a speaker Jeffery Palermo about ASP.NET MVC and more specifically about how it and other tools enable Test Driven Development (TDD) and separation of concerns.
Jeff was a great speaker and his presentation was inspiring. He extolled the virtues of Onion Architecture, an architecture that through the use of interfaces and dependency injection, enables you to isolate your core business logic away from the infrastructure code that enables interaction with that logic.
Beyond isolating your core business logic, which is almost tautologically a “good thing”, Onion Architecture makes it easy to follow the principles of TDD. For Jeff’s purposes, TDD was defined as accompanying the check-in of any new code with corresponding and covering unit tests.
Jeff also briefly covered the technology that makes this all possible: NUnit for unit tests, NHibernate for a decoupled, testable data access layer, StructureMap for dependency injection, Rhino.Mocks for enhanced unit testing and ASP.NET MVC for a testable web UI layer.
Jeff was persuasive in describing the benefits of the Onion Architecture and TDD, but I was left wondering if his point was too abstract. All other things equal, I think it is a no brainer to prefer a set of code with a bunch of unit tests around a flexible architecture over a set of code with no tests and an architecture that actively resists changes.
However, when this statement of abstract preference intersects with the real projects I’ve been involved in, the picture becomes much fuzzier. In order to keep this somewhat short, I’ll stick with discussing just TDD for now.
What Makes Code Better?
A core principle of TDD is that code with unit test coverage is better than code without unit test coverage. Or as it sometimes phrased, code without unit tests is “legacy”, i.e. bad code. These kinds of statements are fun to debate, but ultimately good/better/quality in code itself is a subjective judgment that I’m unlikely to resolve on this blog. More apropos is to ask, does TDD allow you to better produce software that solves its users’ problems?
TDD = Better User Satisfaction and Experience?
If you develop software for a living, you certainly care about the quality of your code, but more importantly you should care about how your end product meets your users’ needs. Is there any evidence, beyond anecdotal reports, that applications developed using TDD have more satisfied users? I haven’t seen any (feel free to correct me with relevant links), and my intuition is that the answer is no.
TDD enables you to automate your testing and heavily suggests testable architectures to enable TDD. Both of these can be nice, but it is not like software without TDD goes out untested and with no architectural planning. Whether it is ad-hoc developer tests and/or formalized Quality Assurance testing, only a fool deploys code that has not been tested at all. And just as you can have QA testing that is inadequate, unit test coverage is only as useful as the tests providing the coverage.
More importantly then just defect control, does TDD make you better understand your users’ needs or think of ways to address them? The users of your application are unlikely to care if you used TDD or any other technique; they want results. With that in mind, it is clear that TDD is not a silver bullet.
Department of Fairness
In fairness to Jeff and other advocates of TDD, I don’t think most of them would claim TDD to be a silver bullet, but rather one technique in the greater ecology of agile development, a discipline that leads to (not predicates) successful outcomes. Granting this, it still leaves unanswered the question of whether or not this discipline leads to more successful outcomes.
Premature Optimization?
Having been on many successful projects that don’t use TDD, my impression is that TDD is a form of premature optimization. Meaning that if I had a highly skilled, highly competent team that consistently delivered quality software, I’d experiment with it and see if we got even better. However, in my experience, people trump process and procedures. More specifically, a team of bright, creative and dedicated individuals with good management will produce quality software no matter what techniques or processes it is using. Conversely, if your team is in trouble, TDD is just a way to avoid addressing the core issues or deficiencies amongst your team.
With all that said, I plan to spend a lot more time investigating TDD and the technologies Jeff mentioned because I think they have good potential to help me deliver more quality software. I do that keeping in mind that as software developers we are apt to put false hope in finding technology solutions for every problem we encounter.
Email is fast, convenient, and asynchronous, all of which make it a wonderful means of communication. Email is also impersonal, lacking context and verbal and non-verbal cues, making it a sometimes surprisingly poor means of communication.
The downsides of email are exasperated by one of its strengths, speed. When you write an email you have the situation in your mind, as well as your intent and that is not always what makes it onto the screen. To mitigate the risk of problematic emails, the best approach is intentionality, or phrased more crudely, to think twice before you say something.
I’ve noticed that the time you think most clearly about something stupid that you just said is right after you say it, so I’ve been using a rule in Outlook that holds items in my outbox for a minute after I click send.
Not really the stuff of legends, but since it is not obvious how to do this in Outlook 2007, here’s how to set up a rule like this:
- Go to Tools -> Rules and Alerts
- Click “New Rule”
- Step 1: Select “Check messages after sending”
- Step 1: Don’t select any conditions, and click “Next”
- Step 1: Select “defer delivery by a number of minutes”
- Click on the “a number of” minutes hyperlink and select 1
- “Next” twice
- Name your rule and your done
One caveat for this rule; you can really confuse someone by sending an email, walking over to their desk, commenting on how you’ve been practicing speed walking and then watching your email arrive in their inbox as you stand there.
Recently I mentioned Inbox Zero, a method of keeping your email inbox organized and uncluttered. Another useful organizational method I practice is what I call “Paper Zero”. Paper Zero is not using zero paper; instead it is a commitment to:
- Organize the papers you have
- Throw away transitory papers (recycle if possible)
- Transcribe important papers into an electronic format (and then throw them away)
I use a good amount of paper at work while doing such tasks as taking notes during meetings, jotting down mental reminders while debugging or marking up project schedules. So I am not anti-paper; until we all have take anywhere, instant on tablet computers with the visceral feedback of pen on paper, I will not abandon my notepad and trusty Pilot G-2 Gel pen (size 07 usually). Sometimes ad-hoc notes, sketches and diagrams are a necessity. In addition, for the sake of my eyes, I don’t like reading long documents on the screen. So printouts can be handy as well.
There are however, many problems with paper. First, its physical dimensions. Papers quickly pile up, cluttering your desk and closing your workspace in around you. Second, paper is inherently volatile. Papers can be torn, ripped, spilled on and just plain lost. Third and perhaps most importantly, papers are inherently information silos when compared to electronic documents. Papers are hard to organize, hard to search, hard to relate to other documents and for the most part single user experiences.
Digitizing your notes is not a revelatory suggestion and the benefits of having your information in an electronic format should be pretty apparent. A typical objection to applying this idea to notes at work is that as notes they are not important enough to spend the time transcribing into digital documents. My response is that they if they are so unimportant, why don’t you toss them and save yourself the desk/filing space? If they are important enough not to toss, then they are important enough that someone else should be able to know about them. Based on my handwriting at least, that implies electronic format.
Another way of looking at that question is to ask could someone pick up on your tasks where you left off from if you were unexpectedly sick or out of the office? No such transition is ever perfect, but it would certainly be helped if the other person doesn’t have to try and decipher your hand writing and filing system. If you are deliberately keeping important information to yourself to be more powerful or save your job, well then you need more than Paper Zero to help you. At least in my field, we value problem solving and effective information sharing, not hoarding.
The final benefit of transcribing important notes into an electronic format is not immediately obvious. When you transcribe notes, which were written while you were thinking about a certain situation with the entire context already loaded into your mind, you are forced to lay out your thoughts logically, exposing your assumptions and gaps in knowledge.
So even if you don’t care about anybody else, by transcribing your notes you can be more effective and have a better grasp of your subject material. In fact, this technique was frequently suggested to me by various college professors as a way to better understand and retain material prior to an exam. I didn’t always follow this advice, but the concept of it stuck with me and has proved useful outside of the classroom, in the quotation mark surrounded “real world” of the workplace.
If you’ve worked on a software development project, there is a good chance you’ve either used or done everything to avoid using Microsoft Project. I avoid MS Project when I can and have developed my own Excel-centric task management system. However, as my system grows to meet the needs of my projects it is eerily converging on Project itself. Is there any escape or I am bound to run so far away from Project that I run right back into it again?
A complete project in MS Project is in many ways a thing of beauty to behold. Tasks are joined to resources, timelines and other tasks as dependencies. You can adjust someone’s allocation and watch the timeline warp and wriggle in response. You also have the comfort of being able to produce solid, comforting diagrams which show your progress and plans to your non-Project blessed co-workers. Then your project moves along just as you planned, with satisfying milestones along the way to the anticipated successful solution.
With these happy sentiments in mind, why did I spin up my own system for task management and project planning? There are 2 major problems I see with Project, the “buy-in” cost and adaptability. Buy-in cost is the amount of time and effort it takes to get your project into MS Project. Project planning is important, but the mechanics of entering your tasks, setting up resources and linking up dependencies is quite clumsy. By itself however, the buy-in cost would be a reasonable investment if it were not for the second major problem with Project, adaptability.
Changing out resources, redefining tasks and dependencies, adding or deleting entire chains of tasks happens all the time during projects, yet represent great pain points in Project. I remember a specific project I was on where a failed attempt to change a few dependencies cost my project manager literally days to recover from.
Beyond changes to the project itself, Project is restrained in the meta and supporting information you can easily attach to tasks. If you really dig into Project, you can set a lot of this up, but again, based on past experiences, Project does not end up being the definitive source of information about a task. So you have other documents, spreadsheets, etc. which all then try to refer to the tasks in Project, leading to synchronization head-aches and disconnects.
One possible answer to these problems is to spend the time to really learn Project, to deep dive into it and hope to mediate the pain points with your newfound guru status. However, at this point you are likely to be stuck (consciously or not) running your actual project in such a way that matches up with the constraints (and capabilities) of your project management tool.
To avoid this inversion of priorities, I have been experimenting with my own system of task management and project planning. The foundation of my system is Excel and so far it is quite primitive in comparison with Project. Nevertheless, I have enjoyed growing my system to create capabilities I find lacking, rather than growing my project to use capabilities I received by default.
I haven’t had to test how my system scales to a large project yet, but even with a small to medium sized project, I do look at parts of Project with envy. I have to laugh when I see my spreadsheet layout inching closer and closer to a Project style look. While MS Project is over weight for my current purposes, it was not developed out of the blue, but in response to certain scenarios that occur while on a project. The problem lies in trying to solve every one of these at once and in the process making solving any of them individually that much more difficult.
I’ve been reading an excellent book, Head First Design Patterns, which covers many of the Gang of Four’s famous design patterns for software engineering from the Head First series own irreverent and creative perspective.
Design patterns are great; they are a useful shared vocabulary for discussing software design and a source of inspiration for your day to day programming. However, as the GoF and the Head First book point out, design patterns are not invented, they are discovered by working with real world applications whose unfettered complexity has lead to unexpected problems. Or more succinctly, they emerge out of encountering and solving pain points.
The danger with design patterns is that you learn them, apply them liberally and then complain about the extra overhead and up front design time. This danger lessens the more and more you’ve actually experienced the pain of clunky and obtuse code. As with most of life, experience is the best and most bitter teacher.
I was further reminded of this when I was recently talking to a friend who mentioned GTD or getting things done, a time management philosophy that encourages creating and executing to-do lists, among other productivity tips. I am not a strict adherent to GTD, but I discovered I did follow one of its most well known off shoots, the idea of a clean email inbox or “Inbox Zero.”
As the name suggests, the idea behind Inbox Zero is to have no emails sitting in your Inbox. This does not mean automatically deleting every email or anything that dramatic, but instead it means expediently applying one of the following actions to every email that comes in:
- Delete
- Delegate
- Respond
- Defer
- Do
There are plenty of resources available online to more fully explain this, but it boils down to making a decision about every email that comes in (even if the decision is to defer your decision) so you never get overloaded with too many emails.
I began following my own form of Inbox Zero after going through a period of time in a project where I got at least 100 emails a day and was going crazy trying to keep up with them all, alternating between frantically trying to respond to each one immediately and a kind of exhausted “benign neglect” of any email without at least a few exclamation points or priority flags.
So, like a design pattern, out of a pain point emerged a general approach to me organizing my inbox. Also like a design pattern, the point of a clean inbox is not to follow Inbox Zero techniques for its own sake, it is help manage complexity and reduce pain points. Process does not exist for its sake, but to alleviate a certain problem.
In some ways it would be much easier if this were not the case. If we could create great software solutions every time by using the Decorator and Factory patterns or never get behind in a project by sticking to Inbox Zero, our jobs would be a lot easier.
However, we certainly cannot. Our primary job is to identify problems and then develop solutions for them, whatever the techniques along the way. This is why we sometimes struggle to identify a clear methodology that we use or a strict definition of what we are looking for in an employee. On the flip side, this is also what makes our work so interesting and rewarding.
A few weeks ago, I attended 2 sessions of the SoCal Rock & Roll Code Camp at the USCD Extension campus. This is an event I’ve attended before and always enjoyed. This year was no exception, as the event was well organized, the schedule was well communicated and the two presenters I saw were good.
The two sessions I attended were Integrating Silverlight 2.0 into an Existing Web Application and Using ASP.NET MVC to Build a Blogging Engine in 60 Minutes or Less. The Silverlight presentation covered some general ideas on how to take an web application you already have and add Silverlight content to it. In particular, I appreciated that the presenter, Robert Atland, emphasized thinking carefully about where to use Silverlight so it is not just a gimmick, but actually enhances the user experience.
The ASP.NET MVC presentation was more of a mixed bag. I didn’t start my programming career in .NET, instead I started in Java where MVC is a much more common paradigm. So MVC as a concept is not new or difficult for me, especially after spending some time recently with Ruby and Python web frameworks. For ASP.NET MVC, Scott Gu provides a brief overview here.
However, a lot of the attendees were new to MVC and used to .NET’s postback model. I think this tripped up Adnan Masood, the presenter, and he spent most of the session valiantly trying to explain the Model View Controller architecture, as well as defend the idea that anything could be better than the postback model. Nevertheless, I thought he did a good job and the ASP.NET MVC framework is worth checking out.
More recently, somewhat inspired by this positive experience, I attended a user group meeting for a non .NET language and had quite a different experience. There is no point in me going into great detail, but the group, although full of what seemed to be very nice people, was incredibly disjointed and vague in it is direction. Almost no content was presented and no particular agenda was followed.
I was more excited about the content I thought would be presented at that user group than the content at the code camp, but the code camp was a far more satisfying experience. So kudos to the folks at the SoCal code camp; it is tough to carve out time outside of work for activities like this and they made me feel like my effort was more than reciprocated.
My previous post, How To Get Really Distracted and Not Learn Any Python, generated enough interest (or at least comments) that I wanted to follow up with some comments of my own.
I have been learning Python in my spare time for quite a while and I am no expert, but I am at least fairly comfortable in it by now. I was reflecting back on what I saw as some missteps I took along the way. The mistake I made was to try and take on too much at once. Instead of just trying to learn Python, I was mixing in learning Linux, a new IDE, a new source control system, etc. All of these are certainly good things to learn, but learning them was not essential to my main task of learning Python.
For the curious, I found the following to be useful activities for actually learning Python:
- Read the official Python Tutorial – I’m not kidding, the official docs are good
- Study Core Python by Wesley Chun – The weight of this book may damage your wrist, but the quality of the information is superb. I read a chapter at a time, then reread the chapter and make notes
- Download and install Django, complete the first tutorial and then try to trace the flow of the code so you can see where the default Django page comes from – I used Wing IDE Personal edition to set up breakpoints and step through
- Read and try to understand the code in a Python standard module – for example, if you are looking at Django or other web frameworks, take a look at the HTTP/TCP/SocketServer family of classes
And MOST importantly, write some code! Writing code is best because it is so humbling; you are not just nodding along to an example in a book, you have to be a creative participant. Sometimes though, it can be tough to know what code to write. To avoid “coders block”, I need to have a goal to work towards. Things like the Django tutorials are a good place to start if you have no ideas. However, things really started clicking for me when I came up with a project idea: write some Python code to read barcodes from books/DVDs via a webcam and then use the resulting barcode to look up information about the book and store that information somewhere; basically a Delicious Library knock off. Kind of silly, but motivating.
And speaking of silly, but motivating (this is begging for a sequel), I present (for the second time) the following Erlang video: on Google video (with longer introduction) and YouTube (slimmed down version). The pinnacle of the driest humor or just unintentionally hilarious? You decide.*
* In anticipation of angry comments from Erlang partisans, I would note that for the last paragraph of this post tongue was back in cheek.
The following is a graphical breakdown of how I spent the first 40 hours or so “learning” Python, plus an excuse to show off the Google Visualization API:
As you can see, based on these extremely scientific measurements, I spent the majority of this time not writing Python code, reading about it or watching screencasts, but instead fiddling around the edges. These are important edges; as a .NET programmer by trade, I know well the importance of a good IDE. Source Control is a given, while Test Driven Development (TDD) is a staple of many non-corporate programming environments. And of course you cannot write any code if your environment is not set up correctly.
So why do I call this time spent “fiddling”? Because of the way I approached it. I took having a good IDE to mean finding a Visual Studio for Python. This meant installs and brief trials of Wing IDE, IronPython Studio, Eclipse and E-Text Editor. TDD was slow sledding when the test was really writing anything that worked. Environment setup became an brief foray into Linux followed by endless tweaks of Windows settings to come up with the perfect Python environment.
I approached getting started with Python as I would setting up a new machine for .NET development, except I have years of experience with .NET and know exactly what I want, whereas I was grasping in the dark with Python. Once I got past these obstacles and got rolling (in Vista, with SVN and Eclipse for the curious), I actually began making some progress. While I learned a lot from the process, it was also needlessly frustrating. If learning Python was my number one goal it would have been better to just take others’ advice, get set up by following a laundry list of instructions and try to end up with a more distraction free allocation like this:
&chl=Python%7CEnv.%20Setup%7CSource%20Control%7CTDD%7CIDE&chdl=Percentage%20of%20Time&chd=s%3A9BBBB&chco=CC6600&chly=85%7C42.5%7C0)
Of course, far be it for me to take my own advice, and I have not been able to resist taking some time to brush up on my JavaScript, which lead me to the Google Visualization API, which is responsible for the oh so orange graphs in this post. The Visualization API is one of many JavaScript libraries which Google hosts on its servers, allowing you to load them onto your own page hassle free. Not all the libraries are Google-made, the impressive jQuery is another library you can import off of Google’s servers. I did not do much more with the Visualization API then you can see in the “Hello World” examples, but the magic is there in the source of this page if you are curious. <Updated post to display better in RSS readers>
(This is not a gadget blog, but occasionally a new piece of technology is interesting enough that I want to write about it.)
The Netflix Player is Roku's 5" deep by 5" wide by 2" tall set top device that allows Netflix subscribers to easily watch any "Instant Watch" content on their TV. I mentioned the Instant Watch feature before, and I have been enjoying it, watching shows and movies on my laptop or occasionally hooking my laptop up to my TV.
I was enjoying it so much that I was about to buy a wireless keyboard and mouse to make using the hooked up laptop easier when I saw that the Netflix Player had come out. For $100 that's not all that much more than a decent wireless keyboard and mouse, so I decided to give it a try.
I've only had this device for a few days, but my initial impression of it is that this is a breakthrough device, with the possibility to do what Tivo did for DVRs, but for streaming content.
The initial setup is easy; the Player has built in wireless or you can use a wired connection. The Player has most any audio/video connections you would want; I am using HDMI for the picture and regular old RCA cables for the audio.
Once you've the Player hooked up to your TV and plug it in, it boots up and asks for a 5 digit activation code that you can get from the Netflix web site. Enter the code and the device jumps right into a nice display of the contents of your Instant Watch Queue. Using the small remote I had no trouble moving through what was available and selecting what to play. I had to tweak the display output to be widescreen in the configuration menu (up arrow from the main menu), but beyond that I was up and running in under 10 minutes.
Once something has started playing, you can fast forward and rewind or skip around to different parts of what you're watching. Because it is streaming, Roku came up with an interesting "chapter" system where you can skip around in 5 second intervals, demarcated by a screenshot of the action at that point in time. TV show episodes of the same series are grouped together logically so you can easily watch through a series in sequence (tested officially via season 1 of 30 Rock.) To summarize, navigation is easy and usability is high: it passed the "non-geek user" test with flying colors as my wife needed no help from me at all when she tried it out.
2 limitations of the Player are that it only shows you content that you have placed in your Instant Queue, via the Netflix web site and it currently has no HD content, although that is on its way. The playback quality is not outstanding, but it is definitely better than regular TV and around DVD quality.
These limitations do not detract from the appeal of the Netflix Player. In fact, based on the easy setup, relatively low cost and excellent usability, the Player is in good position to do what Tivo did for DVRs, which is to not be the first to do something (in this case streaming content), but the first to do it in a way that is intuitive and easy for mass consumption. Netflix's millions of subscribers have a real winner on their hands.
I've written many times before about my trial runs of various Linux distributions and I feel like I've said most of what I have to say about the matter. However, I recently saw a post entitled, Is Ubuntu Useable Enough For My Girlfriend? and I decided to have one more go at explaining my ambivalent feelings towards Linux.
First, a brief summary of the post for the link-impaired; relatively experienced Linux user sets up his girlfriend (Windows user, not super technical) with an install of the latest version of Ubuntu, gives her a set of mundane tasks (watch a YouTube video, Google something, do some photo editing) to achieve while he takes notes and hilarity ensues.
I tend to cringe when highly technical users try to predict what a non-technical user will find easy or difficult; there is just so much background knowledge that someone who is passionate about computers takes for granted, that I think we are uniquely ill suited for the task. So, I try to rely more on colloquial evidence, such as this post.
His girlfriend is able to accomplish many of the tasks, but is stymied by a few, mostly due to poor naming or lack of clear instructions on how to install the necessary application or plug in. The conclusion is that Ubuntu is heading in the right direction, but is still not ideal for your "average" non-power user.
This line of argument has been around since Linux on the desktop became a reality, so at first glance it can seem old, stale, whiny or just plain obvious. If you get beyond that initial reaction, it is an amazing commentary on the state of Linux on the desktop. How is it possible that so many talented individuals have labored so long and yet still been unable to produce a desktop system on which these type of basic tasks are as straightforward as they are on Windows or Mac?
I'll answer that question with another question; could you see Ubuntu declaring a one year new feature freeze, refusing any new graphical bells and whistles, new processor extensions or file system upgrades and instead focusing the next release of Ubuntu entirely on making it as simple as possible for non-technical users to accomplish simple general computing tasks? Imagine the brain power of that many talented contributors all working just towards usability. I think you'd have your killer desktop in way under that one year timeline.
However, my question is flawed. What is Ubuntu? There is an organization around it for sure, but it is not a monolithic one that can give orders to the entire Linux development community. Also, while usability is a stated goal of Ubuntu, it is not necessarily a goal that is shared by many of the elite programmers in the Linux development community. Or more accurately stated, many elite Linux developers are quite comfortable in Linux and don't feel excited about spending time making it "easier".
Quite to the contrary, many technical people are attracted to Linux due to the rapid pace of technological advancement. So in essence, you'd be asking the very people who innovated so much to get Linux to where it is now to stop innovating and focus on the unglamorous task of noob babysitting. Or as the author of the post puts it, "The main issue with the desktop experience is that the geeky programmers and designers assume too much from the average user."
In fairness there are plenty of developers who buck this stereotype and pour effort into usability. Otherwise we wouldn't have distros like Ubuntu at all. Recognizing the good work that the Ubuntu (and other distros such as PCLinuxOS and Xandros) have done with usability, what's left to explain the persistent gap?
I think the often overlooked part of this discussion is that Windows and Mac (OS X) set the norms. Whether or not it is fair or just, most people are exposed first and most often to Windows or OS X and from that initial experience, their expectations are set for how interacting with a computer should take place.
This behavior can be maddening and seem foolish, but is not surprising, at least as explained as Dan Ariely describes in his book Predictably Irrational. Ariely calls this type of behavior "anchoring" and anchoring can explain such oddities as how black pearls suddenly became sought after (they were once relatively unknown and then were introduced first only in high end jewelry stores for high end prices) and how we can feel like we are getting a great deal on a car when we buy it for significantly below the MSRP, despite the MSRP being a somewhat arbitrary number.
So, to come back on topic, even if desktop Linux were easier to use based on some kind of scientific figuring, as long as it remains close enough to our anchor ideal of computer interaction without quite being the same, it will seem inferior and less desirable.
The baseline has to be that either desktop Linux does at least everything as easily as Windows/OS X does plus more or that it presents such a different and satisfying experience that a new anchor is established. A concrete example of this is the iPhone; by offering such a tightly knit and innovative take on the interface of a cell phone it was able to define a new standard for what cell phone UI's should be.
There is movement within the Linux community to develop new desktop interface experiences such as Symphony One and mainstream distros using KDE and Gnome are inching ever closer to matching the out of the box Windows/OS X experience while still offering the power and variety that make Linux fascinating. I am not sure which approach if either will ultimately win out because the final elephant in the room is that Microsoft and Apple are not just standing still, they are trying to take the best bits they see from their competitors and improve their own products.
After 2 months of dormancy, I am starting back up the easy way, with some short notes on topics of interest:
1. Windows Home Server: 2 Months In
The best compliment I can give is that I just don’t think about my Home Server anymore. I let it do its thing and don’t worry about it. I am anxiously awaiting the Power Pack 1 additions, along with the data corruption bug fix (which has not affected me at all yet). In hindsight, I should have just gotten a prebuilt solution, avoided the install pain and had a machine with a smaller footprint, but my custom build does get the job done.
2. Microsoft OneNote: Better than TXT?
I’m still using OneNote at home to take notes on Core Python Programming (my current Python resource of choice), but at work I’m back to using mostly NotePad2 and other plain text editors. Even though OneNote does not fight you as much as Word, it still has the annoying AutoCorrect behaviors that sometimes make plain old text much less of a hassle. The feature to publish your notes to a web page format is nice, although Microsoft’s decision to use the obscure .MHT format is confusing. So after a few months of use, my opinion of OneNote is far more mixed.
3. Netflix Impresses
One of my favorite new technology toys is Netflix “Watch Instantly” feature. The quality is very good, and although the available content is mostly TV shows, seeing what you want, streaming, when you want it, is really an amazingly satisfying experience. If Netflix can integrate this into a set top box, watch out.
4. Indexed
I was going to draw a clever graph showing the inverse relationship between work load and my blogging frequency, but it seemed too obvious, so I’ll just plug the real Indexed site, which is far cleverer. I have been exploring the Python web framework Django, so work load non-withstanding, I hope to share the rare sight of some code on this blog in the near future.
If you use Outlook, Word and Excel frequently, there is a good chance you actually have the entire Microsoft Office suite, which includes some well known applications, like PowerPoint and some not so well known ones, such as Microsoft's OneNote. OneNote has been around since 2003 (the year and MS Office version), but I only started using it when I installed Office 2007.
OneNote is, as the name suggests, primarily a note taking application. Free form pages are organized by the note taker into notebooks. Notes are not just text, they can be images, links, sounds and videos. Notes and notebooks can be published as PDF documents and shared with other OneNote users. This may not sound like the most exciting application, but I've found it to be a surprisingly effective way to keep information organized.
I use OneNote (in addition to a paper journal) to organize ideas and research for blog posts. I use it at home with my dual monitor setup to take notes while watching screencasts and working my way through programming books. At work, I'm experimenting with using it to organize the many small notes to myself I make about projects that usually end up on notepads and then in the recycling bin.
OneNote's interface features tabs across the top for notebook sections, with tabs down the side for pages within the notebook, making it natural and quick to create a nested structure for the information. OneNote also includes its own screenshot tool to facilitate capturing snaps into notes.
Finally, when I open up OneNote it doesn't come with the heavy mental baggage that Word does. I've used Word for years and years, so when I open it up, I think of essays, reports, specs; pretty much all more formal documents. OneNote encourages me to be informal, which is what these notes should be. OneNote also fights against me far less often than Word does; so far I've yet to encounter the frustrating Word behavior where Word just won't let you type in anything until you adjust your formatting.
Long time readers of this blog will remember that I once discussed my somewhat unique diet of more, but smaller meals during the day. The book that explained this relies heavily on sports analogies, one of which is the "undervalued prospect", used in the book to highlight certain foods which lacked the reputation for being healthy, but were actually great things to have in your diet. I think the undervalued prospect is a good analogy for OneNote's place within Office. I never really see it get hyped, but if you take the time to get to know it, OneNote has a lot to offer.
More Posts
Next page »