4 Problems with Google Docs

1) Cursor displacement bug
Google recently changed the way page breaks work. Instead of one continuously scrolling page, you now see distinct predetermined page breaks. This feature is vital for competition with Word. It’s expected behavior for a word processor and it’s far more convenient than rendering a PDF every time you want to see where page breaks occur or placing them manually.  Unfortunately, this feature introduced an annoying bug that places text a line behind where the cursor should be.
Short term fix: avoid page breaks.

2) No tab leaders
Ever since high school debate I absolutely have to make my tables of contents with the rows of dots between the section names and page numbers. As far as I can tell, Google Docs doesn’t tab leaders, the standard way of doing this.
Short term fix: manually type out dots

3) No dashed lines in drawings
This is really a nitpick, but it would be nice to be able to draw dashed lines. I’ve created a couple diagrams where it would have been handy to delineate collections of components. The solid line doesn’t work well because it’s the same thickness as the arrow tails.
Short term fix: don’t worry about it

4) Weird collaboration behavior on presentations
When I last tried to collaboratively edit a presentation (April 2011), the editor was very sluggish when reflecting the changes of others and repeatedly threw errors about conflicting edits. The chat in the right sidebar did not correctly list others as viewing the document.
Short term fix: Temporarily designate one person as an editor for  a group slideshow

Whining aside, Google Docs is still my go-to solution. Real-time collaboration and universal access rock so hard that Word’s extra features aren’t alluring anymore.

Ruby on Rails: A first look

I’ve been writing PHP apps for about 5 years, but it’s time to learn Ruby and its popular framework, Rails. Since there is already great documentation available, I’ll only cover the trouble spots that I’ve encountered.

I began with Ruby itself and followed this quick introduction to Ruby’s data types, object orientation, and iteration methods. It’s a lot to swallow if you’ve spent most of your time writing in C-style languages, but I can understand the appeal of the syntax. If you’re just starting out it’s probably a good idea to spend more time with Ruby proper. Later it can be easy to conflate Ruby with Rails if both are foreign.

To get up and running with Rails on Arch Linux I followed the guide on the official Arch wiki. I ran into a little trouble at the database section. The sqlite package is called sqlite3-ruby package has been renamed to sqlite-3. A proper install requires a
# pacman -S sqlite3
and then a
#  gem install sqlite3

I opted to use the Passenger Apache module rather than WEBrick because I plan to host production applications on this server eventually and it makes sense for Apache to serve everything. If you just want to play around with Rails, it’s probably a better idea to go ahead with WEBrick because Apache requires a little configuration.

Pacman will spit out some configuration information for Passenger and it’s important to get it right. Rails’ official Getting Started guide is specific to WEBrick so it doesn’t tell you that the Document Root line in your httpd.conf should point to the public folder of your rails application. I wasted some time staring at an Apache index trying to figure out why the app wouldn’t execute. Just do something like this:

<VirtualHost *:80>
ServerName rails.trillworks.com
DocumentRoot /path/rails/application/public
RailsBaseURI /path/rails
<Directory /path/rails/application/public>
AllowOverride all
Options -MultiViews

Don’t forget these lines either:

LoadModule passenger_module /usr/lib/ruby/gems/1.9.1/gems/passenger-3.0.7/ext/apache2/mod_passenger.soPassengerRoot /usr/lib/ruby/gems/1.9.1/gems/passenger-3.0.7PassengerRuby /usr/bin/ruby
RailsEnv development

That last line is vital to get the blog example from the Getting Started guide working smoothly. Passenger runs your app in production mode by default, but that won’t work because the migrate command in the guide creates tables in the development table.

The blog app in the guide has a decent introduction to Ruby’s take on MVC and how to wire up the various components. Stay tuned for some real apps.