Terribly Techie
I wonder if OpenSocial might be interesting for us
- 10 October 2008
I can imagine that it’s analogous to how we currently use xml/rss feeds: Whereas rss feeds are componentized content, our own opensocial apps would be componentized pieces of functionality. I’m looking at the getting started page to see what it’d imply.
For writing apps: http://code.google.com/apis/opensocial/gettingstarted.html
For hosting apps: http://code.google.com/apis/opensocial/container.html
There are also at least two offers out there for free high-end hosting for any open social or facebook projects that I’ve seen, for example, here are Joyent’s offers. Sun also has offers directly with them.
http://www.joyent.com/developers/facebook
http://www.joyent.com/developers/opensocial/
Filed Under
Making AJAX Ro(a)R
- 15 August 2008
Since McAfee is offline due to some construction, Robb and I took ourselves off to a cafe and are taking the opportunity to continue learning a new web development technology called Ruby on Rails, or RoR for short. (If you’ve used any 37Signals product, or Twitter, you’ve been using a webapp developed on RoR.)
Both of us learn best by doing, so we are each building some smaller sites using RoR, in addition to actually developing a new web service for Lewis & Clark using it. Beyond all the CS technical jargon, like MVC, the best thing about RoR is that for us doing the coding on the back end, it creates an environment which automatically handles a lot of the messy technical details (like talking to databases) for us, allowing us to focus instead on the experience we want to give our users. What a concept.
And, since the best thing since sliced-toast on the web is AJAX, or the ability to update a portion of the web page without reloading the whole thing, I thought I’d quickly outline how really easy that is to do with RoR.
First of all, I’ll assume you’ve already created a RoR app and done all your setup to create your first controller, say myajax. (A simple way to think about the controller is that it is the thing that “answers” when you ask for a web page at a particular address.) And, I’ll assume you’ve also used the scaffold command to create your default views. (Views are the templates for the web pages that you receive in your browser.)
So, that all sounds like a lot, but like I said above, once you’ve got RoR setup, it took about three commands and thirty seconds to complete all of that.
To do some AJAX, you start by including the standard prototype libraries in your view layout, all with a single method in the <head> of the web page:
<%= javascript_include_tag :defaults %>
Then, in the view template that you want to have the ability to be updated by the AJAX request, include one of the two primary remote call methods — form_remote_tag or link_to_remote — as the action that will initiate the update. (I’m new to this, so I’m sure that there are more, but these two cover most of it.) Naturally, you have to supply the :url parameter and perhaps some additional information for your request. That could look something like this:
<%= link_to_remote("Test AJAX!", :url =>{ :action => "hello" } ) %>
Elsewhere in the index view, I’ll also drop in a little html to demonstrate the update, say something like:
<div id="myinfo"><p>Update this!</p></div>
Then, close that file and create a new file called hello.js.rjs in the same myajax view folder. (Here, the proper thing to do would be to add a “hello” method to the myajax_controller, but it works without for this example, so we’ll move ahead.) In the new file, write a single line of code such as the following:
page.replace_html "myinfo" "<div><p>I've been updated!</p></div>"
Which, in all it’s glory, essentially says go replace the item on the page with the id of “myinfo” with this new stuff.
And now the big moment, fire up your app in mongrel (Ruby’s webserver) and load the index page. You’ll see the “Test AJAX!” link and the “Update this!” text, and if you click the link, you should see the text change to the new message “I’ve been updated.”
Admittedly, this example is really basic, but if you do a little investigation into RoR’s page method, along with everything you might learn about formats in the controller, you’ll see how easy this really is. (And I’m not even getting to the easy visual effects.) And don’t even think of comparing this to the “old way,” like writing your own javascript implementations, and the back-end database hooks.
Happy coding.
Filed Under
Best places I’ve found for learning Rails
- 28 July 2008
I’ve found some excellent online resources that I’ve been using — and these are pretty much all I’ve needed.
Screencasts
These two are awesome. I subscribe through iTunes, but that’s not necessary. Take the earlier ones (pre-2008) with a small grain of salt because they may not be 100% Rails 2 compatible. (In practice, though, I’ve found that 99% of the advice here is still accurate, and where Rails 2 differs, it’s in new facilities provided.)
This is a huge collection of short, focused screencasts, most around 7 or 8 minutes long. Some are indispensable —they’re the only source of info I’ve found on several advanced topics. A couple examples that I’ve watched and found really helpful are #106 — Time Zones in Rails 2.1, #115 — Caching in Rails 2.1, and #63 — Model Name in URL.
Learning Rails — Free Online Course in Ruby on Rails
This screencast series is more traditional; the episodes are closer to a half-hour in length and they walk through the example of building a complete application. All the same, though, I jumped in at the middle, and made good use of Testing Your Site Part 1 & 2. (I couldn’t find an easy way to link to these.)
Webpages
Amazingly, I’ve found the Rails API pages to be the best resources; both when I was just learning, and still now. I’d always use Google as my point of entry to find which one was appropriate, but once there, many of them have excellent descriptions that put all the pieces in perspective. I wish I had known to look here first, when I was learning Rails.
Here are a few of my favorites for good reading:
ActiveRecord — The “Model” in the MVC architecture
Validations — How a model protects its integrity
Associations — Descriptively setting up the relationships between models
UrlHelper — A utility that’s really good to know about
Filed Under
Rails IS the portal platform
- 18 July 2008
I was researching ways to solve the newest, latest technical problem: With any of these cool Rails applications we have, or are considering making, how do we do something like add a forum or a blog?
Usually, one might integrate these into an existing web app by installing onto the same webserver something like Wordpress, doctoring up its theme to look like the original app, and then… the real work begins. :-( For example, sessions are probably handled entirely differently, and Wordpress has a particular and heavy conception of what a user is. Even though Wordpress is open and easy to work with, there’s probably little chance of a 100% seamless, single-sign-on integration.
But in the Rails world, well, Rails is the platform, not the webserver per se. So I wondered if there was more hope for a solution, and it looks like there is.
First of all, there’s Beast, “a small and light-weight forum in Rails with a scary name and … around 500 lines of code”. And then, the end of a discussion yielded this great advice:
Single sign on is very easy. All you have to do is set your session domain to be the same by typing (for rails 2.0)
config.action_controller.session = {:session_key => “_session_id”,:secret => “secret_session”,:session_domain => “.mydomain.com” }
Makes perfect sense. And that takes care of the hardest part. I envision Rails acting like a portal platform: allowing us to add in a third-party blog, forum or other common, modular application.
Filed Under
One person has made the whale happy; will you?(Go ahead, make a comment…)
![The WhiteBoard [home]](http://www.lclark.edu/global/images/transparent.gif)




