Categories
Innovation

Ricky, Ruby and Rails (hypothetically speaking)

In the bits of spare time I get here and there, I’ve been continuing my hypothetical hunt for a language and web framework in which to implement my hypothetical "web 2.0" idea. It occurs to me that if all these little bits of spare time were clumped together so that I could, hypothetically, do some actual coding as opposed to “investigating”, hypothetically I’d be well on my way to having a hypothetical working system by now. But, alas, little bits of time here and there is all I’ve got at the moment.

chunky bacon

Anyway, after having checked out Python and Django and deciding that I’d be happy enough with that set of tools, I thought I’d better check out Ruby and Ruby on Rails to see what all the fuss is about. Well, I have to say, so far I really like the Ruby language. I’ve been helped along by what has to be the weirdest, but coolest, guide to programming that has ever been written for any language (what other programming guide comes with cartoon foxes and its own soundtrack?). I’m still learning the ins and outs of Rails, but there are some very helpful tutorials online for this, too. The fact that Ruby, like Python, comes pre-installed in Leopard was a pleasant surprise. Ruby comes with a command shell environment called irb (Interactive Ruby), which enables you type Ruby code at the command prompt (again, just like Python’s python command line tool). This makes it very easy to experiment with the language.

One of the things I like about Python is list comprehensions. They’re a very neat and convenient way of mapping a list to a new list by applying a function to each element of the original. It kind of works like the map function in many other languages, except you can include conditional statements. The heavy use of list comprehensions in Programming Collective Intelligence tells me that there’s a good chance they’ll come in handy for me later on. Here’s a trivial example:


>>> list1=[1,2,3]
>>> list2=[x**2 for x in list1 if x%2==1]
>>> list2
[1, 9]

In Ruby there’s no syntactic sugar for list comprehensions, but it turns out you can pretty easily implement the required behaviour:


>> list1=[1,2,3]
=> [1, 2, 3]
>> list2=list1.map {|x| x**2 if x%2==1}.compact
=> [1, 9]

Furthermore, since classes are never “sealed” or “final” in Ruby, it means that you can do something like this:


>> class Array
>>   def comprehend( &block )
>>     block ? map( &block ).compact : self
>>   end
>> end

We’ve just added another method to the (existing) Array class which works very much like a list comprehension:


>> list1.comprehend {|x| x**2 if x%2==1}
=> [1, 9]

That’s a little of what I’ve learned about Ruby in the past week or so. Anyway, I can say that I’ve narrowed down my search to two candidates. Python has the lead in terms of being a mature technology. But Ruby really is fun to program in, and I like its syntax better than Python’s. Furthermore, I spent a while faffing around with Django and mod_python for my Mac. But getting Rails up and running was a breeze using the Mongrel web server – a production quality web server for Ruby applications, used by many web sites including Twitter. Ultimately, my (hypothetical) first hire gets the final say. :-)

Categories
Innovation

Programming Collective Intelligence

Programming Collective IntelligenceI’ve been reading a fantastic book written by Toby Segaran called Programming Collective Intelligence: Building Smart Web 2.0 Applications. I’m about two thirds of the way through, but it’s so good that I’m not going to wait until I finish reading it before blogging it. Essentially, it’s a recipe book for machine learning algorithms that you’re likely to find under the hood of many successful modern web sites: clustering, support vector machines, decision trees, simulated annealing, Bayesian classification and so on. The AI course at uni was a bit light on in terms of statistical machine learning techniques, but this book makes up for it. All the code in the book is written in Python and can be downloaded from the author’s website. The algorithms in the book may prove to be highly useful for my work in ubiquitous computing, too.

Coincidentally, according to the most recent entry in his blog, Toby will be giving a talk on a topic sort of related to one I’ve been thinking about as a possible project at NICTA: Creating Semantic mashups: Bridging Web 2.0 and the Semantic Web.

It turns out that Toby is also a fan of GTD, and he’s written his own web based GTD tool. It doesn’t look much, but it’s gained some favourable reviews.

Categories
Innovation

Startup: what you said

So it turns out that quite a few readers of this weblog use Bloglines. For some reason, Bloglines stopped sucking down the RSS feed for this weblog after March 19 until three days ago. Did other feed readers experience similar difficulties with my blog? I know Google Reader continued to work, as did the RSS screensaver on my Mac. Anyway, that partially explains why I had no feedback on my hypothetical question about startups.

Thanks to those who did end up responding. Here’s some snippets of what you said, along with some feedback I got via e-mail in no particular order:

  1. My 2c – I don’t believe there’s that much inherent difference between the major web platforms – in my opinion you’re best off going with what you have the most experience with (and what the people you can get have experience with). You could probably lose 2-3 months learning a new platform (primarily learning it’s idioms and gotchas) and it’s not clear that you’re ever going to get that back. Having said that, I would tend to recommend against the embedded scripting languages (PHP, ASP, etc) on any project of significant size – it’s not so much that they can’t scale, but they strongly encourage non-scalable design by their nature (and it can be harder to find developers who understand the difference). A ‘well-designed’ PHP application will often actually include it’s own sub-templating language (e.g. Smarty), and treat PHP as a pure programming language.
  2. Now you have the prototype you pretty much know the functionality – “recoding” is all about achieving the chrome and non-functional requirements. So, maybe Erlang – excellent for reliability/uptime (incl. for hot-upgrading and failover) and scalability – the two most important -ilities for webapps. Frontend “yaws”, plus some javascript library, and/or maybe an web framework like “erlyweb”Backend – hand-coded erlang apps. Database – “mnesia” or maybe “couchdb”
  3. Thing is, there are big sites being run on all combinations of your options. If you just need *something*, write it in what you feel comfortable in, if it needs to scale later you can use your first iteration as a learning experience. Personally, I think you’d be crazy to write anything in java, you can’t be nimble in java. I also think php is a dead end, it’s just too bodgy. Python/Ruby is the only way to go imho. Funnily enough I saw no mention of javascript for your web 2.0 site :) I would suggest that none of the backend stuff matters at all, and that the only thing that matters is which javascript library you use in the front end.
  4. I assume that this is for a “friend” :-). But I shouldn’t assume.I’m afraid to say I can’t add that much. Just don’t have the knowledge. For this kind of thing, being able to easily tinker with and evolve the system seems an important critiera, if just one of the relevant criteria.
  5. it doesn’t matter what technology you use, because you’ll rewrite the whole thing several times anyway. pick what’s fastest to explore the idea and the market now. time to market, and reaction time once you’re there, cost far more than another 100 servers while you’re in the early stage.who are your partners (or your VC’s partners)? do they have an affinity with any particular technology? what are your friends best at? you’ll need a pool of expertise (and employees), so choose something to maximise that opportunity.
  6. I was going to answer but my intial answer seemed too stupid and it was going to take too long to come up with an intelligent well thought out answer for a hypothetical that did require me to stretch my imagination to the extreme. It’s sort of like what I am finding with some of my 1st years. In one the subjects I am teaching they have to do a lot of hypothetical work and most of the time, the results are utter disasters because they simply, simply can’t stretch their brains into comprehending scenarios so outside their sphere of “being”. Since founding a startup is far, far outside my sphere of ‘being’ I decided I would much rather play pokemon. Now if you ever want to know which pokemon is best to use against a ground-type pokemon….

Mostly very useful feedback, and amusing otherwise. It’s interesting how similar most of the feedback was. Agility, ability to tinker and swiftness of development were common themes. For at least the alpha and beta, I think it would be best to go with tools/platforms where you can put something together fairly quickly, and make changes quickly if your users tell you they’re looking for something a bit different. I’m not sure Java fits that description (although I’ve always been a Java nut). There’s at least a compile step and possibly a deploy step, depending upon your development environment, between making a small change in the code and seeing the result in your browser. Ruby looks cool, but it is still lagging way behind the other serious contenders in terms of performance. PHP could be a contender, but if the system ever got really big and you had new graduates working on the application, I’d bet you’d soon end up with a mess, with business logic stuck in the presentation code and so forth – I really do agree with the first comment above on that point. So I’ve got to say that Python is looking good right now, despite its Makefile-like treatment of white space. Coupled with Django, it might be a winner. There’s also the fact that Google have provided a nice playpen for Python-based web applications.

Once again, thanks all for your input. Please keep the advice and opinions coming if you have more to add. It’s much appreciated.

Update (06:49 19/04/2008): I’m not sure my comment about Ruby performance is entirely fair. The performance difference between Ruby and Python is nothing (Python is a few times faster on most tests) compared to the difference between Python/Ruby and Java, for example (where Java is one and sometimes several orders of magnitude faster). By this reasoning, if one is happy to sacrifice some runtime performance and use Python instead of Java, one presumably wouldn’t be too worried that Ruby is slightly worse than Python. And Ruby doesn’t do too badly in terms of memory usage. Besides, if one was really worried about performance, one would use C.

Categories
Innovation

An underwhelming response

So, after waiting a few weeks, I still have no responses on this blog entry. Okay, I got one reply by e-mail, not including the advice I received from friends before posting the blog article. Was I silly to think people might actually respond? (Chorus: “Yes, Ricky, you’re very silly!”)

Categories
Innovation

Startup: a hypothetical scenario

Picture yourself in the following situation. You’ve come up with what you think is a cool idea for a so-called web 2.0 site. Furthermore, you’ve managed to convince some VC types to invest some (pre-)seed funding – enough to develop a public beta. You developed a quick and dirty proof-of-concept to show the VCs, but now it has to be thrown away. You have to start development on the real thing from scratch.

The question is, what technologies, programming languages, tools and platforms are you going to use to implement your idea? Language-wise, do you go for Python, Java, PHP, Ruby, or something else? If you take the PHP route, how do you ensure maintainability in the long term? If decide on Java, do you use JSP, Velocity or Freemarker? Would you use Struts or Spring? Do you need any of these frameworks at all? Do you run on Linux, Free BSD, Windows or Mac OS X Server? Why?

To make this question at least partly answerable, imagine for the moment we’re just considering the presentation tier, and not any of the back end magic. Also imagine that what you’re developing is similar to one of today’s social networking sites (Facebook, Bebo, MySpace or something), and that visualisations (e.g., of directed graphs) might need to be generated dynamically from data in the back end. You can assume that the beta version will have a small number of types of dynamically generated pages (less than 10, say) but later versions will end up with many more.

Answers along the lines of “It’s much of a muchness, so I would choose X, Y and Z because they’re what I know”, “I’d choose X, Y and Z because the newly graduated computer science students I’d have to hire are most likely to be comfortable with those” and “X, Y and Z are nice but too expensive for my startup, so I’d choose A, B and C instead” are completely acceptable.

I’ve already got some great input from my closest friends (at least the programmers among them), but I’d like to get some responses from a wider audience. I’m hoping some ex-DSTC engineers/researchers might have an opinion on this; you don’t need to have worked at a startup to give useful feedback!

I’m asking this question out of pure curiosity, nothing more, and I have my own feelings on this (represented by the sample answers above). Please leave your answer as a comment below.

Categories
Innovation

Death by bigness

Big companies will slowly suck the life out of you. That’s one way of summarising Paul Graham‘s latest essay. To maximise your freedom, he says, join a start-up or start one yourself. It’s a theory that I find very appealing.

Categories
Innovation

Another tangible user interface

The GroupLab at the University of Calgary has published a technical report describing Souvenirs, a tangible user interface for sharing digital photos in the home environment. It is very similar in spirit to Bowl, which I’ve previously blogged. Souvenirs will be formally published in the Proceedings of the 2008 ACM Conference on Designing Interactive Systems.

Souvenir - the tagged rock and the image it is associated with

Image credit: Nunes, M., Greenberg, S. & Neustaedter, C. (2007) Sharing Digital Photographs in the Home through Physical Mementos, Souvenirs, and Keepsakes. Research Report 2007-875-27, Dept Computer Science, University of Calgary, Calgary, Alberta, Canada T2N 1N4. July.

Categories
Innovation

Finding a human need

I’ve been reading over old ubicomp papers in preparation for a new project at NICTA. So it was that I found myself reading “Charting Past, Present, and Future Research in Ubiquitous Computing“, by Gregory Abowd and Elizabeth Mynatt (whom, incidentally, should surely be listed among those ubiquitous computing researchers who inspire me – particularly Abowd, whose work I’ve followed since my Honours year in 2000, and whose books were often referenced in the HCI course I took a couple of years before that). One of the most important passages in that paper, to my mind, was tucked away in section 6.1.1, Finding a Human Need (the emphasis is mine):

It is important in doing ubicomp research that a researcher build a compelling story, from the end-user’s perspective, on how any system or infrastructure to be built will be used. The technology must serve a real or perceived human need, because, as Weiser [1993] noted, the whole purpose of ubicomp is to provide applications that serve the humans. The purpose of the compelling story is not simply to provide a demonstration vehicle for research results. It is to provide the basis for evaluating the impact of a system on the everyday life of its intended population. The best situation is to build the compelling story around activities that you are exposed to on a continuous basis. In this way, you can create a living laboratory for your work that continually motivates you to “support the story” and provides constant feedback that leads to better understanding of the use.

Designers of a system are not perfect, and mistakes will be made. Since it is already a difficult challenge to build robust ubicomp systems, you should not pay the price of building a sophisticated infrastructure only to find that it falls far short of addressing the goals set forth in the compelling story. You must do some sort of feasibility study of cutting-edge applications before sinking substantial effort into engineering a robust system that can be scrutinized with deeper evaluation. However, these feasibility evaluations must still be driven from an informed, user-centric perspective—the goal is to determine how a system is being used, what kinds of activities users are engaging in with the system, and whether the overall reactions are positive or negative. Answers to these questions will both inform future design as well as future evaluation plans. It is important to understand how a new system is used by its intended population before performing more quantitative studies on its impact.

It strikes me that too few ubicomp research groups heed this, seemingly obvious, advice, including our own. Though we might occasionally attempt to build a story, it is not often compelling, and I’ve read far too many papers that suffer from the same problem (caveat: I specifically exclude Karen‘s work from this blunt introspective analysis because her work is typically very well motivated, and compelling; and she read the paper I’ve just quoted early on in her Ph.D. and took note of it). I don’t think it’s a coincidence that the most successful ubiquitous computing researchers have taken this advice to heart. I want to make sure that the new project at NICTA does do these things properly.

Categories
Innovation

Cool projects by Johnny Lee

Johnny Lee from CMU’s HCI Institute has done some pretty cool things with the Wiimote. His Ph.D. project has also yielded some way cool stuff. Here’s just a few of the things he’s done on his own and with his colleagues.

Truly inspiring.

Categories
Innovation

Bowl: token-based media for children

Ben delicioused me a link to an interesting paper called “Bowl: token-based media for children“. It describes a media player that is controlled by placing various objects (tokens) into a bowl. The idea was to create a control interface that is easy for children to use and which establishes links between particular physical objects and digital media. Aside from being a really cool means for interacting with a media player, it would have to be one of the neatest uses of RFID that I’ve come across so far. The bowl (or rather the platform that the bowl sits on) is augmented with an RFID reader. The various objects are augmented with RFID tags. When an object is placed in the bowl, an associated piece of media plays on the screen. For example, when a Mickey Mouse doll is put into the bowl, a Mickey Mouse cartoon plays. In theory, various combinations of objects might also have meaning. The system might be configured so that if Mickey Mouse and Donald Duck are placed in the bowl, a cartoon featuring both these characters starts playing. The system becomes very social and conversational when homemade objects are augmented with RFID and linked to, say, home video clips or family photos, as demonstrated by the experiment reported in the paper.

I wonder what sorts of casual, natural interactions such as those induced by Bowl might make sense in the domain I’m working in? What are the relevant artefacts that could be augmented to create new meanings for the people who interact with them?