I started to learn a bit about Rails while considering joining a software start-up (in the non-profit space). I spent a month hammering away with a few O’Reilly books and a sample project, then got pulled away by real world concerns like starting up my new career fast so my family won’t starve. I got far enough to get the concepts and philosophy, master the innovative database management (activerecord), and start an app that I plan to finish and publish as part of Techcafeteria someday. Along the way, I loved the rapid development features and recognized Rails as a bit of a conceptual leap in programming/scripting, that values efficiency of following conventions over coding. Being oriented toward finding the fastest paths to the best results, I was also intrigued by how Rails builds Ajax functionality into the code (I just never bothered to get beyond the basics of Javascript, preferring server-side programming, I bias I now regret…) But I also grew concerned about the platforms speed and scalability, concerns that my friends at Social Source Commons (SSC) would second, I suspect.

So, the four areas that the conference could have helped me with, and how it did:

1. Learning more of the scripting language. Not so much—maybe a referral to the book I’m missing that will glide me right over that hump.


2. Ajax intro – pretty good. I attended a few sessions on Prototype and Scriptaculous that gave me a far better handle on how they work .


3. Ruby Scaling—an awesome session on the proxy cache and other options out there to speed up Rails, with pointers to what bottlenecks it. This was likely the most valuable thing, and I’ll be contacting Gunner to offer to take a look at the SSC platform and see if we can apply some of what I learned.


4. Where it’s going, as I reported on yesterday. Among web scripting languages, PHP and ASP/.NET are the kings today. My prediction is that Ruby on Rails will eclipse them, and gain broad adoption among web 2.0 developers and corporations looking for in-house app development tools. The main limitation – performance – is being addressed and will be fixed, no question.

The benefit of having a functional application roughly 60 seconds after you think of a name for it is phenomenal, and the developers are completely geared toward continuing to make it the out of the box solution for speedy delivery of standards-based, current tech web applications.Similar Posts:

• The Rails Thing
• Instant Open API with Rails 2.0
• OpenID Enabled
• Salesforce Show and Tell
• A Day of Joomla (live)

This is an interesting event – an “un-conference” as Ryan calls it, which falls somewhere in the territory of a traditional conference, a town hall meeting, and, maybe, the Phil Donahue show, as emceed by the always entertaining Gunner (of Aspiration fame).

It’s about halfway through the day, and continuing through tomorrow, but I won’t be able to come back, because that would incur the justified scorn of my son’s mother, who expects me to not be a computer geek on her day. There are 100 or so people here from many corners of the earth (well, the Americas and Europe are healthfully represented) and associations to Joomla that range from a tiny non-profit thinking about using it to the core development team. Joomla, for those who don’t know, is a popular open Source Content Management System (CMS) with a huge developer community, making it very powerful and popular. It has it’s roots in a CMS called Mambo.

The big topics are:

• The upcoming Joomla 1.5 release, which is a dramatic rewrite of the application that will make developers (like me) very happy. They have exposed a programming framework that could develop into an environment all it’s own, and they’ve made changes to the templating that allow for powerful customizations.


• The move to more strictly enforce GPL compliance. The GNU General Public License is designed to offer users of GPL applications much freedom,with restrictions on how the code can be redistributed that insure that the community will share in all enhancements. The Mambo/Joomla developer community apparently includes many add-ons that aren’t compliant with this, and the Joomla team hopes to (appropriately) bring them back to compliance.

This is a seriously fun event with group activities intersperced with break out sessions, and a kind of “this is being made up as it goes along” agenda. Next up: speed geeking! which Gunner describes as “like speed dating, but completely different”.Similar Posts:

• NTEN Connected
• From Zero to Sixty: What type of Project Management tool is appropriate?
• The Rails Thing
• Pop Quiz: PCI Compliance
• What I’ve been up to

The conversation really focused on two very different questions, and what was interesting was seeing where they might connect.

As it stands, SSC is a user-developed online database of software applications. A new feature allows users to make “community toolboxes”, so that you can design a list of, say, your favorite fund-raising apps; all the text editors for the Mac; or hosted software with the best Ajaxy interfaces. But the feature isn’t fully implemented. It’s easy to make the lists, but a bit of a challenge to find the lists that others have made. So my critique is that what is missing was context. I don’t want to just list my favorite Mac text editors – I want to discuss the pros and cons. If you program in Ruby, you might prefer Textmate to BBEdit – there’s no place in the database for that kind of nuanced information. SSC provides the tools, but not the context, except in a limited fashion with the partially-deployed Community Toolboxes.

Dan had a completely different question. Given that the tiny non-profits and the communities they work with tend to be lacking in technical expertise, how can they use a very Web 2.0 interface to help themselves out? Is SSC designed to help those in the most need of software and advice, or those who are already well-resourced and conversant? (And I’m paraphrasing intensely here – Dan should comment if I’ve really missed his point!)

I think the answer to that either/or question is mostly yes. SSC is an interface for the geeks. Even if the user interface were customized for non-technical users, they would likely still be overwhelmed by the software data itself. This is a tool for the people who are tech-savvy and work in those communities to use in their research. So, getting back to the context question—which is huge, because it’s just not enough to have the data without the wisdom of the community—who can provide that?

And here’s what excites me about where Social Source Commons might be going. We can. NPTech bloggers. Non-Profits doing digital divide work. Community activists. If SSC develops middleware – widgets and APIs that allow us to interact more meaningfully with those feeds and toolboxes – the blogging community can provide the context. SSC moves into a more del.icio.us role, as a data intermediary.

Say you’re doing a project that involves using media players in low income communities to support education and communication, and you’ve built a good list of podcasting tools and mobile rss readers art SSC. You’ll be able to link to it from your website or blog, and write the how-to’s with detailed application data provided by SSC. This is useful.

These tools are under development – I’ll be beta-testing them at techcafeteria. Stay tuned.Similar Posts:

• Paving the Road – a Shared Outcomes Success Story
• Losing Facebook
• Shlock and Oh! Facebook’s social dysfunction
• Tweaking Twitter
• One Size Fits