My notes as I listened to the audio recording of a presentation by David Heinemeier Hansson, lead developer of Ruby on Rails, at the Future of Web Apps summit.

He starts off saying that motivation is the key ingredient for developer productivity and tools should be optimized for "happiness" of the developer. Later he demo-ed some of the cool features of Rails.

• How to "optimize for happiness"?
  "For me, beautiful code makes me happy"
  
  
• For most of the time, for most of the programmers, what they do is not unique
  Most of our work revolves around the same mundane details as every body else. "You are not a snowflake". With RoR, we're optimizing for this common 80%. It's not possible to optimize for rare use cases.
  
  
• Convention over configuration
  To avoid repeating oneself. So that there's no need to explain to one part of the system how the other part works or is set up. He explains the RoR convention of mapping plural table names to singular class names.
  (I'm not too convinced of this example.)
  He says it's clearer..But Isn't this in opposition to Python's "explicit is better than implicit"
  
  Convention using "id" for the primary key..so on. Goes to the foreign key
  relationships expressed in Rails. I didn't like repeating my foreign key relationships in the Ruby code.
  
  Continues with RoR conventions for URL to controller mapping, and controller to View mapping (this I like!)
  
  
• Flexibility is over-rated
  "You trade flexibility for readability and productivity".
  "Constraints are liberating" - You get systems which are consistent and where other developers can jump in.
  
  
• On PHP
  "I tried very hard to make clean, separated systems in PHP..I learnt that PHP is the devil (applause there)..
  It encouraged me to be a slob"
  
  
• Many-to-Many relationships
  Eg: Book-Author..how do you store info about when an author wrote a book. Does that go to the book or author table?
  The solution is to treat Book Authorship as a first class entity by itself, and not as a many-to-many relationship." I'm not sure I follow this too well. He's basically playing around with the relational model.
  
  
• Transactions
  "Rollbacks are easy to implement in Ruby with blocks."
  
  
• Validation
  "We are trying to extend Ruby to create small DSL's.."
  He gives an example of validation code written using Rails' DSL for validation.
  
  
• Associations
  "If you are referring anything down the association chain, it will be automatically scoped within that association".
  Eg: post.comments.search will search only for comments within that post."
  Again, looks like some alternative to SQL.

(The recording ended abruptly at this stage :( )

Check out this demo video showing how Microsoft's new Atlas Framework can be used to develop Ajax-enabled pages using ASP.NET. This was at the ongoing Mix06 Conference - a 3-day MS event focusing on web technologies.

The first half of the video is the usual ASP.NET stuff - binding a HTML table (grid component) to a database table with a few ASP tags, and enabling sorting upon the columns and paging.

After about 12:15 minutes into the demo, he shows the new Ajax-related ASP wrapper tags for the Atlas framework: atlas:UpdatePanel and atlas:UpdateProgress.

Any content required to be updated without page refresh is wrapped in atlas:UpdatePanel tags, which also has a "Mode" attribute to enable Conditional refresh of data. An UpdatePanel can contain "Trigger" tags which define when the browser should try to update the content.

The atlas:UpdateProgress is used to provide the "Loading..." image or content during updates.

The result works in Firefox too, as he shows!
Very slick, very declarative

What's most interesting is that he never once bothers to show the generated HTML; that could be a little unnerving for current web developers. From what I could see, most of the links in the page are actually Javascript functions, with very few "proper" hyperlinks, even where they could have been used. But that's always been the case with ASP(.NET) generated code, and seems to be becoming more common with the new style of web apps.

The Visual Studio IDE he uses has a long list of components in the left, from which he picks a few (There's a free Lite version of VS IDE if you are really interested)

I listened to a talk by Cal Henderson, the architect of Flickr, today. This was at the Future of Web Apps summit.

He says we are moving from an age of web sites to web applications. Soon it could be web-services (pure data) that could be important. But of course he tempers his predictions saying that we won't have a pure "XML web" any time soon, and things are going to be messy for a while to come.

The talk was called "Top 10 Reasons to Love Web 2.0". He said it's basically "10 Things You Can Learn from Flickr" when developing new applications. Let me try summarize his ideas now.

1. Collaboration
   Flickr is big on allowing a group of people to annotate some data. Flickr started off as an online multi-player game called "Gave Never Ending", but they gradually changed it into a photo-sharing application. He says tagging public or contacts' photos and making notes on them was the main differentiator for flickr. Otherwise online photo sharing has been "around for 15 years".
2. Aggregation
   This refers to connecting data across users, along the axes of popularity, tags, "interestingness" (using a proprietary algorithm), geo-location etc. Contrast to the old approach where data was "boxed into silos" of different users.
3. Open web service API-s
   He lays great stress on this, saying people will go and build cool applications using them if your data is interesting enough.
   Eg: fastr: A game which picks up flickr photos matching a random tag and asks you to guess the tag.
   Interestingly, he said that the API was first written to help implement the AJAX parts of their UI.
   He warns that if you don't build an API, people would scrape the web pages for such applications - that puts great load on the service.
4. Clean URLs
   The usual del.icio.us style URLs. Some of the older URLs on flickr had filetypes and disk paths included, and they had to struggle hard not to break them as the system changed.
   He says URLs have to be permanent, and also, ""There is no reason to expose the physical structure of the application through
   URLs. We need to expose the logical structure."
5. Ajax
   "Could be called just 'A'" ! He means that it's not necessarily the technologies like Javascript or XML, but the pattern of asynchronous refresh and partial page re-load. They used Ajax only to enhance parts of the interface, and there was explicit intention to have a lot of Ajax.
6. Unicode
   From the start, you can store all your application data and presentation layer in a format suitable for internationalization. He says UTF-8 is now supported well by all modern desktop browsers and even most of the mobile ones.
7. Desktop Applications Support
   Quite early on they wrote a photo uploader desktop software, because they realized uploading bunches of files is painful from within HTML forms. Again, he says the presence of API-s (either web-service style or RPC style) helps a lot here.
8. Mobile devices
   For mobiles, use XHTML mobile profile. Just putting a different skin is not enough. You need to send much smaller subsets of data, organized differently.
9. Open data
   Give people the feeling that we don't own their data or lock them in.
   Not just the primary data, the metadata is what needs to be exportable - tags, comments etc.
   Eg: Someone used flickr apis to generate a DVD of a user's flickr's photos, browseable and searchable.
10. Open content
    When user uploads stuff, it still belongs to the user, with all rights reserved. And they can pick a different license if they choose to, like the Creative Commons Licenses.

Overall, that was quite a good talk. Since every individual point above seems fairly obvious to anyone in this field for a while, I guess Flickr has scored in combining all of them together and putting them into practice very well in a timely manner.

Oh yeah, if you are thinking "what about user feedback", he explains right in the beginning that he agrees with Joshua Schachter of del.icio.us that "Users only tell you what they think they want. You need to figure out what they need".

Wise words those!

For some time now I've been using closures quite a bit in my Javascript, and I've been intrigued by the concept since I first encountered it (might have been in one of Sidharth's talks). I feel like exploring closures in a couple of other languages too.

Simply put, a closure is a function pointer which contains one or more references to some state (typically variables) contained outside the function definition itself. This combination of function + state can be looked at as a simple object. Thus a closure is an object which implements the "call" interface (the "()" operator) and refers to some external state variables while implementing that interface.

An example in Python

def func(x):
         y = 5
         def closure():
               return x + y
      
          return closure
      
    //let's instantiate and invoke the closure
    closureFunc = func(5)
    print closureFunc()
    > python closure.py 10

Here, the function func() creates a closure by defining a function closure() which refers to an external variable "y", and returning a reference to that function. The invocation of the closure later, returns 10, since y=5 when the closure was defined.

A restriction of closures in Python is that you can modify the state of the enclosing scope only if they are global variables or instance variables of a class. This is because Python does not offer a way to refer to an enclosing context which is neither global state nor instance variable. Paul Prescod explains the issue on a newsgroup.

In Javascript, however, the enclosing context is looked up in a closure. So we can modify the value of "y" in the closure.

function func(x){
           var y = 5;
           function closure(){
                var returnValue = x + y;
            
                //let's change the value of "y" here
                y = y + 1;
                return returnValue;
          }
          return closure;
   }
   var closureFunc = func(5);
   closureFunc()
   10
   //y is now 6. This is something you can't do in Python
   closureFunc()
   11

I don't see much need for changing the state in the enclosing context though. So in general you wouldn't miss it in Python.

One issue that crops up in closure creation is the binding of the referenced context variables. The variables are lexically scoped, but dynamically bound, i.e., the variables looked up are those declared in the enclosing scope of the closure, but the values of these variables are not necessarily the same as when the closure was created. They could have been changed by the time the closure is invoked.

Below I create a series of closures in a for-loop, each of which reference the loop index variable. You can see that all the closures get the final value of the index variable when invoked.

function func(){
           var closures = new Array();
           for(var i=0; i < 3; i++){
               var newClosure = function(){
                   return i;
               }
               closures.push(newClosure);
           }
           return closures;
  }
  var closures = func();
  closures.length;
  3
 
  closures[0]();
  3
  closures[1]();
  3
  closures[2]();
  3
 

This is actually a useful feature, but a potential pitfall in cases like this.

• Wikipedia entry on closures
• Martin Fowler - Closure
• Ivan Moore - closures in Python
  

I just listened to Joshua Schachter's talk at the Future of Web Apps summit.
I've listed the points I found significant.

Implementation

• Know your database engine very well. He also says the tags don't map well to SQL/relational model at all.
  
• Leverage HTTP to the full - Apache modules (mod_rewrite), running proxy servers, caching data (esp. RSS Feeds)
• Supporting a lot of browsers and their quirks goes with the territory. Realize that you'll be spending a lot of time on this.
• Scaling: It's hard to predict which features will be used most and where performance bottlenecks will arise. So try not to optimize before hand, but react fast to problems: "You have to know the performance implications of each and every query you are running"
• Monitor how the system is being used (He mentioned "nagios"). How many users are actively using it over time, how frequently do people log in etc.

User Experience

• Speak the user's language (delicious uses "Favorites" instead of "Bookmarks" on the homepage, as that's what IE has).
• When users ask for a feature, find out why they are asking for it. Get the entire usecase or story. And then try to solve their real need.
• Keep registration simple. Make *as much* of the system usable without registration.
• It's better if the system solves a real problem you are facing, that leads to more passion.
• Keep URL's nice. He calls the location bar the "prime piece of real estate in the middle of the page".
• Don't replicate features found elsewhere. He says that's the reason delicious doesn't have commenting and private messages, but also adds that was an oversight in retrospect. 

Avoiding abuse

• Exposing system-generated sequential identifiers can lead to bot attacks.
• After you block a channel of spam attack, don't give any error message. Just accept and silently drop spam input.

Viral vectors (How to increase the userbase)

• Provide RSS everywhere, that way people can use system without logging in. And more people will be using the system regularly.
• Service should make people want to tell others about the site.
• It's nice if the system offers benefits if there are more users (network effect). But that shouldn't be a necessary factor. Design for "selfish users". "If user no.1 doesn't get any value out of the system, why would he show it user no. 2"