When my manager asked me, “what else would you want to work on other than Ruby,” I started looking for a new job outside Microsoft …. a year ago the team shrunk by half and our agility was severely limited. I’m omitting the internal reasons for this, as they are the typical big-company middle-management issues every software developer has. In short, the team is now very limited to do anything new, which is why the Visual Studio support for IronPython took so long. IronRuby’s IDE support in Visual Studio hasn’t been released yet for the same reasons. While this is just one example, many other roadblocks have cropped up that made my job not enjoyable anymore. Overall, I see a serious lack of commitment to IronRuby, and dynamic language on .NET in general … I invite the Ruby and .NET communities to come help us figure out how to continue the IronRuby project, assuming that Microsoft will eventually stop funding it.

The dynamic language work at Microsoft is very interesting and has done a lot to persuade the world that .NET is not just a C# and Visual Basic story. Personally I’d add my voice to those encouraging the company to re-invigorate its investment in IronRuby and IronPython.

A couple of other observations though. Schementi is talking about efforts to continue work on IronRuby irrespective of Microsoft’s funding, and if that succeeds it could bring the project to a better place rather than a worse one.

Second, one thing I learned in talking to Don Syme, the F# man at Microsoft, is that functional programming is in high demand in financial institutions, one of Microsoft’s most important markets. IronRuby and IronPython win Microsoft plenty of kudos, but the benefits in terms of revenue are presumably harder to identify.

Whatever happens to these languages, the impact of dynamic languages on the .NET platform has been significant, and C# now also has dynamic capability.

Related posts:

1. Why F# rather than IronPython in Visual Studio 2010?
2. Programming language trends: Flash up, AJAX down?
3. C# 4.0 goes dynamic

FOWA has been at London Excel recently, but this event was back to its earlier venue of Kensington Town Hall, more crowded but a better atmosphere and easier to get to. I suspect a little downsizing, but much prefer it. Organizer Ryan Carson has his heart set on enabling start-ups, proffering business advice and uniting developers, designers and money folk, though many attendees are not in the start-up category at all. When revealing the results of a survey showing that many web app hopefuls had less then 1000 site visitors a month he shook his head despairingly “you’re never gonna build a business on that kind of traffic”.

Carson has excellent contacts and the day kicked off with Digg’s Kevin Rose on how to get those visitor numbers up – he should know if anyone does. Rose exceeded my expectations with tips on massaging your visitor egos, avoiding analysis paralysis, hanging round event parties to meet influencers even when you can’t afford to attend the event, and even how to hack the press.

After that the day was disappointingly low-key, at least until midday. Then we got Francisco Tolmasky from 280 North and it all changed. Tolmasky’s line is that we should use pure web technology but with the richness of desktop applications, and to enable this he’s put forward cappuccino, a JavaScript framework inspired by Apple’s Objective C and Cocoa – Cappuccino uses Objective-J. This now has a visual development tool (web-based of course) called Atlas, and in Tolmasky’s demo it looked superb. See here for more details.

The surprising twist is that after developers told Tolmasky that they (or their companies) were not willing to trust code to the web, 280 North came up with a desktop version of Atlas with the added ability to create desktop applications as well. I am not clear about all the runtime details, though it no doubt involves webkit, but Tolmasky’s differentiator versus alternatives like Java or Adobe AIR is that Atlas uses only web APIs.

We heard a lot at FOWA about social media, how to use it for marketing, and how to integrate it into applications. Cat Lee from Facebook gave us a breathless presentation on how simple it is to hook into Facebook Connect. It was OK but it was a sales pitch, and that never goes down well at FOWA. 

The later afternoon sessions were excellent. Bruce Lawson of Opera gave us an entertaining overview of how HTML 5 would make life easier for developers. There was nothing new here, but nevertheless a revealing moment. He showed some rich media working in HTML 5 and made the comment, jabbing at Adobe Flash and Microsoft Silverlight, that the web was too important to place control in the hands of any one vendor. A loud and spontaneous cheer went up.

This was echoed later when Aza Raskin of Mozilla gave us a browser-centric view of social media, suggesting that the browser could broker our “social graph” by integrating with multiple identity providers. Raskin’s line: social media is too important to be in the hands of any one vendor.

The Guardian’s Chris Thorpe gave a bold presentation about how the Guardian wants to embed itself in the web through its open platform. Like most print media, the Guardian has many challenges around its future business model (disclaimer: I write for the Guardian from time to time); but Thorpe’s presentation shows that his newspaper is coming up with an intelligent response, promoting interaction and building out into the wider web rather than erecting paywalls. Having said that, maybe the Guardian will try other business models too; it is a journey into the unknown.

Overall a day for social media and the open web, and a good antidote to the more vendor-centric conferences at which I often find myself. Next week, for example, it is the Flash-centric Adobe MAX; and having heard very little about Flash at FOWA that will make an interesting contrast.

Related posts:

1. Future of Web Apps 2008 Day One: Web is DVD, desktop VHS
2. Facebook, Comet, FireEagle at Future of Web Apps
3. Web identity, Facebook, iPhone debated at Future of Web Apps conference

Notable facts and speculations:

C# is the number one language, overtaking Java (which is down 12%), and was consistently so throughout 2008. Although the .NET platform is no longer new and exciting, I’m guessing this reflects Microsoft’s success in corporate development, plus the fact that the language is changing fast enough to stimulate book purchases. Absolute growth is small though: just 1%.

Objective-C is growing massively (965%). That’s probably stimulated by iPhone app development more than anything else. It’s a perfect topic for a programming book, since the platform is important and popular, and attracting developers who were previously ignorant of Objective-C.

ActionScript is growing (33%). That’s Adobe’s success in establishing Flex and the Flash platform.

PHP is up 3%. I’m not surprised; it’s usually the P in LAMP, everyone’s favourite free and open source web platform. That said, the online documentation and community support for PHP is so good that a book is less necessary than for some other languages.

JavaScript is down 24%. I’m a little surprised, as JavaScript is still a language everyone has to grapple with to some degree. It may be a stretch; but I wonder if this is a symptom of AJAX losing developer mindshare to Flash/Flex (ActionScript) and maybe Silverlight (C#)? Another factor is that JavaScript is not changing much; last year’s JavaScript book is still good enough.

Visual Basic is down 15%. Exactly what I would expect; slow-ish decline but still popular.

Ruby is down 51%. This is a surprise; though it was well up in 2007 so you could be kind and describe this as settling. The problem with Ruby though is lack of a major sponsor; plus the migration from PHP to Ruby that seemed possible a couple of years ago just has not happened. It may be intimidating to casual developers who find PHP more approachable; plus of course, Ruby probably is not installed on your low-cost shared web hosting package.

Python is down 14%. Google sponsors Python, in that it is the language of App Engine, but apparently this has not been enough to stimulate grown in book sales. I guess App Engine is still not mainstream; or maybe there just aren’t enough good Python books out there.*

It will be interesting to see the 2009 report in a year or so. Meanwhile, I’m off to write an Objective C tutorial (joke!).

*Update: I was reading the charts too quickly; it looks as if the percentages above are only for the last quarter; the annual figures are similar except that Python actually grew over the year as a whole.

Related posts:

1. Technology trends: Silverlight, Flex little use says Thoughtworks as it Goes Google
2. Adobe’s Flex Builder to Flash Builder name change does not go far enough
3. Amethyst from SapphireSteel: Develop Flex in Visual Studio, an alternative to Tofino

The first is a built-in ability to publish your Force.com data as a public web site. The service is currently in “developer preview” and set for full release in 2009. Even in preview, it’s priced per page view on your site. For example, if you have the low-end Group Edition, you get 50,000 page views free; but if you exceed that limit, you pay $1000 per month for up to 1,000,000 further page views. It would be unfortunate if you had 50,001 page views one month.

The second announcement relates to Facebook integration. This is a set of tools and services that lets you use Facebook APIs within a Force.com application, and create Facebook applications that use force.com data. Sheryl Sandberg, Facebook COO, says this is “Enterprise meets social”. The problem: Facebook is consumer-focused, more play than work. Sandberg says this deal will launch Facebook into the Enterprise. This will be an interesting one to watch.

Third, there are new tools linking Force.com with Amazon’s S3 and EC2. Tools for S3 wrap Amazon’s API with Apex code (Apex is the language of Force.com) so you can easily add unlimited storage to your Force.com application. Tools for EC2 delivers pre-built Amazon Virtual Machines (AMIs) that have libraries for accessing Force.com data and applications. The first AMI is for PHP, and simplifies the business of building a PHP application that extends a Force.com solution.

Interesting that Salesforce.com is providing two new ways to build public web sites that link to Force.com – one on its own platform, the other using PHP and in future Ruby, Java (I presume) etc.

It’s worth noting that you could already do this by using the SOAP API for Force.com, and there are already wrappers for languages including PHP. This is mainly about simplifying what you could already do.

More information is at developer.force.com.

Related posts:

1. Salesforce.com partners with Adobe for Flash Builder for Force.com
2. Amazon, eBay, FaceBook: the risk of building your business on a third-party platform
3. Facebook, Comet, FireEagle at Future of Web Apps

Digg’s Kevin Rose spoke briefly about his site’s new recommendation engine, which has been active since July or so. The idea is that Digg learns a user’s profile by examining clicks and votes, using it to customize what the user sees. He spoke about a forthcoming feature, where third-party sites will be able to call the Digg recommendation engine to get profile information that it can then use to customize its own site.

An interesting idea; though it raises several questions. How does it work – would logging out of Digg be sufficient to disable it? Will users opt-out or opt-in? How much of this kind of customization do we want anyway?

This whole theme of contextualization is a big one here; it ties in closely with social networking, and Google’s OpenSocial API is getting quite a bit of attention.

Blaine Cook (ex Twitter now Yahoo, Ruby guy and inventor of OAuth) gave a though-provoking session on scalability along with Joe Stump from Digg (and a PHP guy). They took the line that languages don’t matter – partly a reflection on Twitter’s scaling problems and whether it was Ruby’s fault. Other factors make language efficiency unimportant, they said, such as disk I/O and network speed; and the secret of scaling is multiple and redundant cheap boxes and apps which are segmented so that no one box  is a bottleneck. The case was overstated but the main points strike me as sound.

I’m wondering how many of the developers here are actually having to deal with these kinds of scalability problems. Many web apps get only light use; the problems for everyday developers are different.

I attended a session entitled "The future of Enterprise Web Apps" by Googler Kevin Marks. It turned out to be a plug for the OpenSocial API; not what I was expecting.

Francisco Tolmasky of 280slides.com evangelised his Objective-J and Cappucino JavaScript framework, based loosely on Apple’s Cocoa framework. Hmm, bit like SproutCore.

I give Tolmasky credit for the most striking analogy of the day. The Web is DVD is says, and the desktop VHS. Adobe’s AIR is a combo player. He is talking about transition and leaving us in no doubt about what he sees is the future of the desktop.

Best sessions of the day (that I attended) were Blaine Cook on Jabber and its XMPP protocol, and David Recordon from SixApart on the evolving Internet "open stack". In this he includes:

• OpenID + hCard for identity
• XRDS-Simple for discovery (http://is.gd/3M53)
• OAuth for authentication
• ATOM and POCO  ( or PorC) – Portable contacts)
• OpenSocial

I put these two sessions together because they both addressed the "Web as platform" topic that is really the heart of why we are here. Spotting which APIs and protocols will win is tricky; but if consensus is reached on some or all of these, they will impact all web developers and bring new coherence to what we are doing.

I’ll be covering today on Twitter again – see here if you want to follow.

Related posts:

1. Notes on the Future of Web Apps
2. Future of Web Apps cheers the independent Web
3. Web identity, Facebook, iPhone debated at Future of Web Apps conference

Multiple vulnerabilities in Ruby may lead to a denial of service (DoS) condition or allow execution of arbitrary code.

More discussion here and here. The community is fixing the problems energetically; but they do appear serious, and some are struggling with compatibility issues.

Since these seem to be bugs in the interpreter, it strikes me that this makes a good case for JRuby or in due course IronRuby, on the grounds that the Java and .NET runtimes are more mature. When I spoke to ThoughtWorks about its extensive Ruby work, I was told that JRuby is almost always used for deployment, partly because enterprises are more comfortable with it.

Related posts:

1. ThoughtWorks Mingle: is JRuby always this slow?
2. Ruby on Rails on .NET
3. Microsoft Ruby