Entries Tagged 'rails' ↓

I’m finally recovered after a really exhausting week that included SocialDevCamp and the wild ride of Twitter Vote Report.

SocialDevCampEast2 went off without a hitch on Saturday at University of Baltimore.  Once again, some of the best and brightest developers, entrepreneurs and social media gurus gathered to trade ideas and talk about the future of the web.

One thing we try to do at SocialDevCamp is vote on the sessions, to make sure they are things that people really want to hear about, or at least size the discussions to the right rooms.  We ran 5 rooms all day in 5 sessions plus lunch, for a total of 25 sessions! Check out the wiki to see the sessions that were held.

Personally, I enjoyed the conversation on location technology, and why location-based social networks have yet to reach critical mass.  Most folks felt that there was a technological barrier — it’s just too hard to continuously update your location with current device and battery constraints — and others questioned what incentives people have to update their locations.  We decided that those incentives probably needed to be tuned in order to see a successful location-based service emerge, and that there may also be benefit for people sharing location-related information anonymously.  Great talk, and I’m still thinking about what incentives might make LBS actually work.

We did a session on Twitter Vote Report, which was awesome because we were actually able to recruit some members of the crowd to do some work on the project!  Bryan Liles and John Trupiano contributed some great work to the codebase, some while sitting in the session!  We talked about the overall architecture of the project, and the fact that it was put together in just two short weeks of coding!

There was a good conversation about iPhone development, introducing people to the platform and answering questions about the platform.  Many seemed to be glad to get a feel for Cocoa and I wouldn’t be surprised if several of the folks there end up working on the platform!

Alex Hillman of Philadelphia’s Indy Hall helped to lead a discussion on co-working in Baltimore, and by the end of the session, we had actually launched co-working in Baltimore, with a mailing list and a set of great ideas for taking things forward.  Yesterday, we held our first “official” co-working meetup at Bluehouse in Baltimore; I’ll write more about the co-working initiative separately.

Because I wasn’t in the other sessions, I can’t say what all was said in them, but I heard good things about the conversations on data portability, source code management with Git, and crowdsourcing. If you were in one of the sessions, feel free to leave some comments here or links to your own blog!

Ann Bernard helped put together an awesome party for SocialDevCamp at Metro Gallery with great food from Tapas Teatro and an open bar.  And live music from Natasha El-Sergany, KADMAN, and Ra-Ra-Rasputin… A great way to end the day, and I can say that by the time it was all over, I had talked to a few hundred people and was completely exhausted!

This morning, Mike Subelsky, a friend and one of the organizers of the recent and fabulous Ignite Baltimore said via email, “It is not an exaggeration to say that SDCE has totally changed my life,” referring to the first SocialDevCamp held in May. Not to sound self-congratulatory, but the same is true for me.

SocialDevCamp is one of a few things sparking a renaissance here in the Baltimore/Washington area, giving rise to events like Ignite and to movements like co-working.  With the social media tools available now, this sort of thing is finally possible to do, and it’s hugely gratifying to see it happening!

See you next spring for SocialDevCampEast3!

An hour or so ago I launched Twittervision Election View, allowing viewers to see posts to Twitter about the 2008 election in their original geographic context.

Twitter launched something similar this morning, and the idea to do a political view of Twittervision has been around for a while, so it seemed natural to try to do this now and especially in advance of tonight’s debate.

We have some enhancements planned, and right now the site is getting a ton of traffic as people discover it… we should be able to put some more server capacity on it which should keep things steady.

Let me know what you think!

When we first launched Twittervision in early 2007, Twitter was still a pretty small community of users (around 200,000) and only the press and the digerati were paying much attention to it.

Today, with just over 1M users, Twitter is still pretty small by Internet standards, but a lot of people are paying attention to it.

Our API was designed to allow individual users to use the Twittervision location features. A lot of people are using it. We also had a fair number of people who were using our API as an alternative to the Twitter API and trying to harvest vast amount of data using our free API.

Sadly, this was restricting service to others, so we are making some changes to the API that make this kind of use no longer possible. Those of you using the API for your individual projects or in support of client-side apps will see no changes for now — keep doing what you’re doing.

We do sometimes engage in licensing agreements, however, so if you are interested in licensing our data, please contact me at dave at twittervision.com.

Judging by the fact that there are several posts about this topic out in the wild, and that I have come across a need for it more than once, I thought it would be helpful to wrap up this functionality into a plugin and put it out into the world. Give a warm welcome to ActsAsRenderer!

Before you go off on a tirade about the evils of violating MVC, let me first say I know the arguments and I agree with you. However, in a world of complex systems where not everything is done via full-stack HTTP, there are legitimate reasons to output data directly from models, and ActsAsRenderer helps you do it.

With ActsAsRenderer, you get four cool new functions.

For your model class, you get render_file and render_string. For your instances, you get render_to_file and render_to_string.

Probably the most common (and legitimate) use of this kind of functionality is for rendering data out of a Rails script (say with script/runner). Since that environment is not a full-stack HTTP view of the world, it’s a real pain to render any kind of structured output. Not anymore! With acts_as_renderer in your model, you can render your views and give your model the voice it’s been lacking!

I’ve had this need come up several times. Most recently, I built a server configuration management system using Rails. While it is nice to preview the rendered configuration files using Rails-over-HTTP, it is also essential to be able to write those same configuration files out to the filesystem. In another case, I had a background DRb process that needed to be able to render templated output to the filesystem. I had to go build a mock-controller and do some pretty unsavory things; all of that would have been obviated with acts_as_renderer.

Now, I can simply say:

class Server < ActiveRecord::Base  acts_as_renderer

  def build_configuration    CLIENT_CONFIG_FILES.each do |f|      render_to_file("configs/#{f}", "#{config_dir}/#{f}.conf")    end  endend

The render_to_file function renders the templates located in configs (under app/views by default) and writes them to the files specified in the config_dir; it’s also smart enough to know that render_to_file is being called from a ‘server’ instance and sets @server accordingly. So my templates in configs are simply:

; Configuration Snippet for Server <%=@server.description%>

<%= render :partial => 'configs/queue', :collection => @server.queues %>

Please do think before using this plugin. It can be used for some seriously evil violations of good MVC design practice, and you are responsible for your own actions. However, this can also be used to make your existing designs *much* more robust and elegant, and I encourage you to use it where that is true.

It’s ready to drop in. Everything is there, including tests. Enjoy!

NOTE: Version 1.0 only supported Rails 2.0; I just added version 1.01 which will work with either Rails 1.2.x or 2.0.x. Please feel free to ping me with any questions.

acts_as_renderer at RubyForge