When you’re running a Rails application in development mode, you might notice that it takes a little longer for requests to get processed and this is somewhat intentional as the framework is was designed to allow you to run the application and make live changes to it. This way you can do some basic functional tests from your web browser, work on HTML/CSS changes, or anything else that might need to be done in development mode.
Anyhow, this can be slow from time to time and if you’ve done much Ajax work, you might be familiar with how slow this can feel when performing some basic tasks. Well, thanks to Josh Goebel, we can speed up things with a new plugin he just released.
To install via piston:
cd vendor/plugins; piston import http://svn.techno-weenie.net/projects/plugins/dev_mode_performance_fixes/
To install via
./script/plugin install http://svn.techno-weenie.net/projects/plugins/dev_mode_performance_fixes/
Josh has posted some benchmarks and in my totally basic tests… shows about four times (4x) speed improvement for reqs/sec!
How does it work? From what I can tell, it works somewhat like autotest, in that keeps things cached and when it sees files modified, it re-caches the changes. He’s made it so that the stack doesn’t need to reload for each request, which is quite slow.
Since it’s development-mode only, I’d encourage you to install it and give it a whirl.
Like many… I’ve been using del.icio.us for several years and so have some of my closest colleagues. A few of us at PLANET ARGON have been using the
for:username tag to send each other links, which has been a great productivity hack as we don’t need to copy URLs and paste them into emails, IMs, or IRC channel windows anymore. One of the things that del.icio.us doesn’t have a totally perfect implementation is sending to a group. There are people in your network, but to my knowledge, there isn’t a way to send everyone in a network the same link without selecting everyone individually. This was adding more time to the process of saving a link for ourselves and our fellow team members. So, we came up with a clever hack… a new delicious user account.
Over the past four months, our team has bookmarked almost four hundred links on topics ranging from Rails plugins, Interaction Design, Business processes, cool new web applications, to any variety of things that we find relevant to our team.
So, all of the links are being sent to a fake user. How do we see the links for that user without having to logout of our current user and into the planetargon account? Well, what we’ve done is take the delicious RSS feed and pipe it through feedburner and given everyone the URL that feedburner provides. Now, we’re all able to subscribe to the same feed and check out links when each of us has time for it.
...and this is what I get to see show up in my RSS reader. :-)
How is your team managing bookmarks? :-)
Yesterday afternoon, we were helping our newest employee, Paige Saez, get setup with new accounts across all of our applications. She uses Google Reader and couldn’t understand why her Basecamp RSS wasn’t working in it. We explained that Google doesn’t provide any way to subscribe to authenticated feeds (yet)... so it wasn’t something she could do. (I still use NetNewsWire because of this problem…)
During the discussion, I said that it probably wouldn’t take much effort to build a proxy for an authenticated feed… and Andy said he’d give it a shot.
10 minutes later… he had an initial version of a RSS proxy application, written in Ruby.
15 minutes after that, we had it up and running on a private server for all of us at PLANET ARGON to begin using.
...and here is the proof!
Wee! Authenticated Basecamp RSS feeds in Google reader. It even works with the openid authentication.
You can grab the code from Andy’s blog post and finally make the switch off of desktop RSS readers to Google Reader, because you know you want to. ;-)
There are a few things that we’re going to push out in near future, such as an API and a new RubyGem.
Chris volunteered to work on the new design and I did most of the programming in Ruby on Rails. When we worked on this, we really wanted to keep the process as simple as possible, despite some of the problems that the site has been having.
In the end, we have a Rails application that is only 85 lines of code and has a 1:2.3 code-to-spec ratio. I wanted to keep it under 100 lines of code. This means that there is some breathing room for further development.
We also tried out a beta account that I was given for RoundHaus for Subversion hosting. We had a really good experience using their service and were impressed by the plethora of useful features that came with the repository, such as continuous integration, rcov/code coverage stats, and twitter integration!.
If you find a bug, be sure to submit a ticket on the RubyURL bug tracker.
On a side note, we deployed this on a brand new Rails Boxcar, our new hosting solution that will be launched in the very near future. ;-)
Older posts: 1 2