For the last week Twitter has been mostly unusable.  While it's been possible to "tweet" it hasn't been possible to view replies, and now you can't see "older" posts.  While twitter hasn't become a staple in my life yet, I can see with some recent changes in my life me relying on it, or something similar, for communicating with others.  Twitter has proven time and time again that it isn't up to the challenge of being a service that we can rely on for much of anything.  I've given some other services a try to see what might be able to take the place of twitter, and I'm starting to form an opinion on what I think may be our best path forward.

I've developed a 6 step plan for removing twitter from our lives.

Step 1: Sign up for friendfeed, and add all the online services you use to your account
Step 2: Sign up for tumblr (or some other microblogging service) where you can post the things you normally post to twitter.  Another option would be to just use the "share something" feature of friendfeed for what you normally use twitter for.
Step 3: Take advantage of all the other services friendfeed supports and use those services for what they're good at.  For links use delicious or magnolia, for photos use flickr or smugmug, in short use the services that you like the most and use friendfeed as the central hub where you can view everything you and your friends are doing online.   
Step 4: Use friendfeed for viewing your "friends" activity stream, and allow it to become the central place that you communicate with your "friends".
Step 5: If you've become reliant on desktop client for interacting with twitter, download twirl or AlertThingy and set it up with your friendfeed account.
Step 6: Enjoy life without twitter

Sound good?

I'm in the process of deploying a Rails app, and up until a few minutes ago I was having problems getting acts_as_attachement and attachment_fu to work.  I originally started development with acts_as_attachement since I was naive and didn't know there was something better.  After looking for a fix for the issue I was seeing, I came across attachment_fu and came to see that it was superior and would undoubtedly solve my issue.  It didn't....however, the upgrade process was painless and I got some extra goodies so all was good.  For those interested, the extra goodies include pluggable image processors (RMagick, MiniMagick, and ImageScience) as well as an option to store files with Amazon S3.

With attachment_fu installed, I was sure my problem would be resolved.  I suspected the issue I was having was related to RMagick image resizing since I'm deploying to a shared hosting account on TextDrive, and RMagick has quite a reputation for hogging up lots of memory and causing havoc on shared accounts.  After switching over to attachment_fu and to MiniMagick as my image processor I was still seeing my issue, so I realized it had to be something else.

Before going onto the solution, let me explain the problem that was occuring.  When I was submitting a form for an attachment_fu model I was immediately being redirected back to the index page.  Every once in a while the form would appear to be submitting, hang, and eventually hose the lighttpd process.  As I mentioned above, I first suspected the problem was related to image resizing being done by RMagick but I was able to reproduce the problem on a non image attachment_fu model object.  After digging around on the web and coming up empty, I ended up checking out the Rails log file to see if I could figure out what was going on.  Examining the production.log showed that I was going from the :new action, directly to the :index action.  Since I was submitting a form, I should have seen a hit on the :create action for my controller.  This led me to search google for a slightly better phrase which eventually landed me at this "Form doesn't trigger create in production" forum post, as well as this related post on Ruby Forum.

It turns out the problem is due to the way that attachment_fu stores the files uploaded on the file system.  attachment_fu stores the files in a folder with the same name as the model within the public folder.  This causes issues since the url for the controller, as well as the directory for storing files have the same URL.  Fortunately the fix is as simple as adding the following to your application.rb file.

def default_url_options(options)
{ :trailing_slash => true }
end

Deployment is such fun, isn't it! :)

One of the things that I've missed about using FeedDemon as my RSS Newsreader is the ability to sync my unread items locally and read them while offline.  Since my current RSS Reader is a web app, Google Reader, I had accepted the fact that syncing unread items to read on the train ride home or elsewhere was something I would have to live without.  Apparently, I'm not very forward thinking because with Google Gears I can now sync locally and use Google Reader while offline!  In fact, with Google Gears, any web app can now add offline support and thus open a whole new world of possibilities.  Gears provides a client side relational database that can be accessed via Javascript.  Under the covers Gears uses SQLite.

What's even more interesting is the thought of how Microsoft might respond, or perhaps how they've already responded.  Imagine being able to write Silverlight applications in managed code, ruby, or whatever language tickles your fancy and persist data to a local SQL Server Compact edition using the common ADO.NET programming paradigms that we're all used to.  Next imagine ADO.NET Synchronization Services thrown into the mix so that local data in the SQL Server compact edition database can be synced back to the server. 

While the advancements made by Google Gears excites me, I'm not real big on being limited to programming against it with javascript.  The idea of building web apps that can now work offline, and use local databases that can sync back with the data center using Sync Services, all within the nice managed environment provided by Silverlight would be a sweet deal.  Heck, even if that doesn't happen we should be able to write a managed wrapper on top of Google Gears so that our managed code within Silverlight can take advantage of it.