Lowdown is now free and open-source
Lowdown was a Rails Rumble project in 2009, aiming to help business owners that want custom software work with developers and designers to get on the same page.
We continued to maintain Lowdown after Rails Rumble, but it’s time to let it go live its own life.
So, as of today:
- Lowdown is now 100% free with unlimited projects and unlimited collaborators. All current and paid subscribers have been converted to the free plan.
- Lowdown is now Open Source Software. For more information please visit: http://github.com/databasically/lowdown
- Support for the free hosted version has moved to Github issues. Please see #2 for more information.
- We’ve migrated Lowdown to Heroku. All current projects will be intact, although there may be minor (if any) disruption in service as DNS propagates. Thanks for your patience.
Thanks for trying/using Lowdown! If you’re interested in participating in the OS version, please contact us: @databasically
Bundler 1.1 vs 1.0 install speedup
Bundler 1.1 went official yesterday. One of the big improvements is speed. Previous versions of bundler would need to download all of the rubygems information in order to build a dependency tree.
Whenever you see Fetching source index for http://rubygems.org/ when you do a bundle install, that’s bundler downloading the file with all of the gems’ information.
Now, bundler 1.1 is smarter about this. It can ask rubygems.org directly to give it the dependencies for a list of gems (see this post for a better explanation of the actual rubygems bundler API calls) and use that to start downloading the gems.
Here are my results, for a project with a brand new empty gemset:
$ gem install bundler -v=1.0.18 && time bundle install Installing ... Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed. real 48.174s user 38.411s sys 19.535s $ gem install bundler -v=1.1.0 && time bundle install Fetching gem metadata from http://rubygems.org/....... Fetching gem metadata from http://rubygems.org/.. Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed. real 22.015s user 28.377s sys 18.442s
Speedy!
Check out the bundle install --verbose option if you want more insight into what bundler is doing, too.
Kansas City Ruby: What’s New in Ruby – February 2012
Posted by Wes in Blog, Kansas City, Kansas City Ruby User Group, Ruby, Ruby on Rails 
No comments 22
At the beginning of each Kansas City Ruby meeting, I do a quick presentation on some new neat things from the last month in Ruby news.
What’s New In Ruby
February 2012
Ruby on Rails 3.2 released
http://weblog.rubyonrails.org/
- Faster development mode
- End of Ruby 1.8.7
-
puts Person.active.limit(5).explain
- Automatically shows when > half a second
- TaggedLogger
ActiveRecord Store
class User < ActiveRecord::Base store :settings, accessors: [ :color, :homepage ] end
u = User.new(color: 'black', homepage: '37signals.com') u.color # Accessor stored attribute
# Any attribute, even if not specified with an accessor u.settings[:country] = 'Denmark'
RubyMine 4.0 released
http://blog.jetbrains.com/ruby/2012/02/rubymine-4-is-here-to-make-you-feel-the-productivity/
RubyMine is a popular Ruby and Rails IDE by JetBrains (the folks behind IntelliJ IDEA).
A focus has been put on improving its performance and UI, but it now also supports all of Rails 3.2 features, including CoffeeScript compilation right from the IDE.
Spree 1.0 Released
Spree is almost certainly the most popular, fully featured Rails-based e-commerce system and its creators are proud to announce the release of version 1.0.0.
Strano
https://github.com/joelmoss/strano
The Github backed Capistrano deployment management UI.
Guard::RSpectacle
https://github.com/netzpirat/guard-rspectacle
Guard::RSpectacle automatically tests your application with RSpec when files are modified.
Lightning Talks
Configuration for mailjet email delivery with Ruby on Rails
Setting up mailjet.com to deliver your mail via Ruby on Rails? Here’s how, because their Getting Started is nothing but placeholder headers right now.
Gateway timeout with nginx/passenger standalone
I needed to run Rails apps with both ruby 1.8.7 and 1.9.2 on the same server.
Passenger Standalone to the rescue! Setting up my 1.9.2 app as a standalone server and setting it up as proxy to it worked great.
Until we had to upload and process some files. Turns out, the gateway server would timeout, even though the process was still processing on the app server.
The proxing nginx server would reply with “Gateway Timeout 504″.
The fix from the nginx documentation: proxy_read_timeout
My proxy config after this:
location / {
proxy_pass http://127.0.0.1:3010;
proxy_read_timeout 240s;
}
Thebes, profiling spork, backup rubygem
Thebes, a new minimal sphinx gem for Rails
Thebes is a wrapper around Sphinx, the search engine we use on most of our projects. Thebes differs from other solutions by staying as far away from your Rails code as possible. Instead of hiding the Sphinx configuration file behind a domain-specific language, this library assumes you will write Sphinx config files by hand. In Thebes, you edit an ERB template of your Sphinx configuration and populate it with variables at generation time. For developers needing the most flexible or fastest solution possible, this is a great way to work with Sphinx.
We’ve been doing some interesting things with search and reporting that are going to require faster lookups than directly querying the database. From the article “the [Thinking Sphinx project] has a lot of complexity and ties to ActiveRecord 2.x code. Consequently, the porting of TS to Rails 3 isn’t turning out to be the smooth road we hoped for. So, for Rails 3 projects, this looks like a good way to go if you’re willing to get your hands dirty and build some sphinx files yourself.
Profiling Spork for faster start-up time
Spork allows you to preload Rails environment files into a process, then it forks that process and runs your tests against the new process. In essence, your tests will start faster because they’re not loading everything. You can specify files you want to be reloaded each time (for instance, model files).
The code:
This prints out everything being loaded up, so you can move files that don’t change into the preload block for that extra bit of snappiness.
Backup, a rubygem for database and file backups
Backup is a RubyGem (for UNIX-like operating systems: Linux, Mac OSX) that allows you to configure and perform backups in a simple manner using an elegant Ruby DSL. It supports various databases (MySQL, PostgreSQL, MongoDB and Redis), it supports various storage locations (Amazon S3, Rackspace Cloud Files, Dropbox, any remote server through FTP, SFTP, SCP and RSync), it can archive files and folders, it can cycle backups, it can do incremental backups, it can compress backups, it can encrypt backups (OpenSSL or GPG), it can notify you about successful and/or failed backups (Mail or Twitter). It is very extensible and easy to add new functionality to. It’s easy to use.
Check out the README for all the details, but this allows you to backup your app via command line, pushing to S3 or rsync’ing to another server. You can schedule it with the fantastic Whenever gem too.
A :limit of Rails’ Migrations
Migrations in Ruby on Rails use the “:limit” symbol to set the maximum length of the underlying field’s data type. Take for example, the following example migration:
create_table :things do |t| t.string :name, :limit => 32 t.string :description t.timestamps end
By default, Rails will create :description as data type “varchar(255)” and :name as “varchar(32)” in a MySQL database. But did you know you can set :limit to be greater than 255?
For whatever reason, many of us have gained the impression that 255 is the longest :string can be, but that just isn’t the case. If I wanted the :description field in the example above to be greater than 255, I could just define it as follows:
t.string :description, :limit => 1024
In fact, strings (i.e. varchars) in MySQL can hold up to 65,535 bytes of data.
The opinionated nature of Ruby on Rails is a great asset in most instances, but we have to be careful not to let its opinions :limit us.
Note: I’m pretty sure Rails sets the default limit of strings to be 255 for two reasons: 1) cross database compatability, and 2) MySQL’s InnoDB (utf-8) engine can’t index varchar fields exceeding 255 characters.
Further Reading
default_scope: Use Cases, Caveats, and Work Arounds
In Ruby on Rails, named scopes are class methods used to restrict and organize the data searched for. In SQL terms, a named scope adds to the conditional (WHERE) and sorting (ORDER) sections of a query. See Railscast #108 for more information.
In Rails 2.3.x, a new type of scoping was added to the API: the default_scope. By using “default_scope”, one could restrict the data retrieved by every query without the need for extra method calls; it would just happen by “default”. If you wanted to have your data sorted in a particular manner, you could add “default_scope, :order => ‘created_at DESC’” to your model. From then on, all data retrieved would be ordered by “created_at” in a “descending” manner.
Caveats
In general, default_scope should be avoided if possible. Here are a few reasons:
- Out of site, out of mind: Because you don’t see that you are scoping your data as you query it, it’s easy to forget that it is in actuality being filtered. This can lead to a lot of head scratching until you remember the default_scope.
- default_scope is inherited: All subclasses of the original model will inherit the default scoping. This may not be the behavior you desire.
- Extra overhead: It’s one thing if you need your data sorted every single time, it’s quite another if you don’t. By using default_scope, you may be unnecessarily burdening your database.
Use Cases
Like curry, default_scope is not inherently evil (obscure Phineas and Ferb reference), and there are instances where using it makes good sense. As an example, here at Databasically, we use default_scope to limit data retrieved by one application to a subset of what is available in a table. There will never be an instance where all the available data will be required, and so we limit it by default.
Here are the two use cases:
- When only a subset of the data is ever required
- When the data must be returned in a specific order every time
Work Arounds
I highlighted the words “only” and “every” in the section on use cases to make a point: default_scope should be used with caution. The fact is, however, that it’s not an “only” and “every” world, and as such, we need work arounds. In our case, it’s by using “with_exclusive_scope” and the undocumented “unscoped” (Rails 3.x only)
with_exclusive_scope example:
Article.with_exclusive_scope { find(:all) }
unscoped example (Rails 3.x only):
Article.unscoped
Conclusion
In general, we like to keep our code as DRY as possible, but in cases like default_scope, we prefer to be more explicit. We recognize the value of default_scope, but only use it when we absolutely need to, and even then we try to think of alternative methods.
How about you? We would really like to hear from you about your experiences with default scopings. What considerations do you take into account when choosing whether or not to use default_scope?
Further Reading
What time is it? Or, handling timezones in Rails.
As a followup to a stack overflow answer, I thought I would give some examples of working with time zones in rails.
What does Rails timezone support do for me?
- Stores everything in UTC in the database
- Allows you to set an application default timezone and/or timezones for your users
- Automatically converts UTC in the database to the correct zone and back
What zones are available?
You can get a list of timezones with rake tasks:
# Displays names of all time zones recognized by the Rails TimeZone class, grouped by offset. rake time:zones:all # Displays names of time zones recognized by the Rails TimeZone class with the same offset as the system local time rake time:zones:local # Displays names of US time zones recognized by the Rails TimeZone class, grouped by offset. rake time:zones:us
Setting the default time zone
In your environment.rb (Rails 2) or application.rb (Rails 3) file, you can set the default timezone:
config.time_zone = 'Central Time (US & Canada)'
What does this do? By setting an application-wide timezone, any datetime will be stored in UTC in the database, but will be translated when we access it.
Set a timezone for a user
You can use time_zone_select to get a list of timezones for a user to pick from. The third argument is a list of “priority” zones that will appear first.
time_zone_select( "user", 'time_zone', TimeZone.us_zones, :default => "Pacific Time (US & Canada)")
Once the value is saved in the database, you’ll want to set it for each request, per user:
before_filter :set_timezone
def set_timezone
# current_user.time_zone #=> 'Central Time (US & Canada)'
Time.zone = current_user.time_zone || 'Central Time (US & Canada)'
end
[UPDATE: You'll need a field 'time_zone' in your user table!]
[UPDATE: You probably want to stay DRY and refer to the configured value instead of specifying the timezone value in both places:
Time.zone = current_user.time_zone || MyAppName::Application.config.time_zone]
Let me know if you have questions or improvements and I’ll integrate them into the article. Thanks!
Getting the Runaround
Yesterday was my third day on the job and to be honest, it wasn’t a lot of fun. I’m learning a lot of things right now: a new project, new methodologies, and new technologies. Combine all of that with a seemingly useless RSpec error and you can imagine where my blood pressure was reaching.
I had just added a new association to a FactoryGirl factory. I’ve not used FactoryGirl before, but it’s easy enough to copy and paste from other factories in the directory. So far, so good. I wasn’t watching the test output, but it was just one line, what could go wrong?
Several updates and commits later, I thought I’d better make sure we were still “Green”. Eh, not so much. Here’s the output I was seeing repeated over and over again.
Failure/Error: Unable to find matching line from backtrace stack level too deep # /home/user/.rvm/gems/ruby-1.9.2-p0@xxx/gems/activerecord-3.0.0/lib/active_record/locking/optimistic.rb:62
I’ll not bore you with the details of my fruitless search to track this down. Suffice it to say, Wes – that would be my new boss – helped me back out my changes and track down the error.
It turns out that my “simple” addition to the “facility” factory wasn’t so simple. It actually resulted in a never ending loop of weeping and gnashing of teeth.
There are three models which were being dealt with: Facility, User, and Department. Departments have many users; facilities have many departments, and a facility can have a user who is defined as a contact. The schema looks like this:
In my “facility” factory, I was making an association to the “users” table. Unbeknownst to me, the “user” factory was making an association to “department”, which was in turn making an association to “facility”, which was making an association to “user”, ad nauseum. The result: a “stack level too deep” error.
The solution was to just create the user association with the “department” set to nil.
Before:
t.association :contact, :factory => :user
After:
t.association :contact, :factory => :user, :department => nil
Hopefully this will make someone else’s first week on the job go a little smoother and keep them from getting the runaround.