'The Rails 4 Way' is the latest edition of the most comprehensive, authoritative guide to delivering production-quality code with Rails 4.
Pow is great. The single thing that bothered me was problems with using debugger while pow'ing away.
Did you ever put a debugger into your controller, connected with rdebug, hit refresh but it didn't stop?
The problem is most probably with POW_WORKERS setting. You see, by default, pow will start 2 ruby processes per application.
Since direct console access is not available when using pow, you have to use rdebug instead. Usually it means something like this added to config/environments/development.rb:
# to use ruby debug with Pow do the following: # echo export RUBY_DEBUG_PORT=20000 >> ./.powenv # # to connect: # rdebug -c -p PORT_NUMBER if ENV['RUBY_DEBUG_PORT'] Debugger.start_remote nil, ENV['RUBY_DEBUG_PORT'].to_i end
Then you can restart your pow application and run the following command line:
rdebug -c -p 20000
Once you get "Connected." back you know that your rdebug has connected to some ruby process and is awaiting breakpoint hit.
The problem is that pow by default starts 2 ruby processes per application, and so only one of them will be able to bind to the port 20000. Which in turn means that only requests being processed by this process will get a chance to be stopped in debugger. So on average only about 50% of your requests will hit the debugger.
The solution is fairly simple. Just add the following line to your ~/.powconfig file:
Then restart pow.
Note: I mean the whole pow server, not just your current application. I'm using the excellent powify gem for this:
gem install powify powify server restart
From now on you will get only one pow process per application and never miss a breakpoint again.
About half a year ago Vitaly posted a post about how simple it is today to use ruby patches bundled with rvm installation to dramatically reduce big rails app loading times and make your dev environment a much happier place.
Since then Ruby advanced with new patchlevels and there are new patches to use, so let's go over this once again.
First, we start with upgrading the rvm to latest and hopefully greatest
rvm get head
Since Vitaly wrote his post it seems that the railsexpress patch superseded the falcon one. At least that what i got from browsing over the patches repository.
So, next step is to compile our Ruby version with railsexpress patchset applied
rvm install 1.9.3-p392-railsexpress --patch railsexpress
Ok, now for some trivial benchmarking to ensure we made things better and not the other way around. Now, note that the say in the interwebs goes that the bigger your application and amount of gems it has to load the more happy you will be. Also, the usual disclaimer about those performance things, YMMV.
I took a random application from my dev folder. It loads 147 gems. Let's check out some numbers
✗ rvm use 1.9.3 Using /usr/local/rvm/gems/ruby-1.9.3-p392 ✗ time rails runner "puts :OK" OK rails runner "puts :OK" 16.28s user 1.70s system 98% cpu 18.185 total ✗ rvm use 1.9.3-p392-railsexpress Using /usr/local/rvm/gems/ruby-1.9.3-p392-railsexpress ✗ time rails runner "puts :OK" OK rails runner "puts :OK" 8.56s user 1.22s system 99% cpu 9.820 total
Just to make a comparison to the previous blog post, here are the numbers for the same application with ruby 1.9.3-p327 with falcon patches set:
✗ rvm use 1.9.3-p327-falcon Using /usr/local/rvm/gems/ruby-1.9.3-p327-falcon ✗ time rails runner "puts :OK" rails runner "puts :OK" 9.89s user 1.34s system 98% cpu 11.374 total
So, comparing to falcon patches it's not that big of an improvement, but still, another 1.5 seconds win.
And yes, i know that both before and after times are slow. But still, i see a nice around 50% time save on any environment loading. And what i really like is that this improvement demanded the whole 7 minutes of my time.
Rails Conference 2012, first time in Israel, was a great deal of fun. Lot's of presenters both local and from all over the world, well, more like from all over the world of Rails. There were talks from Github, Heroku, Engine Yard, Gogobot, Get Taxi and lots and lots of others. Solid organization from Raphael Fogel People and Computers guys. Hordes of interesting people to talk to, nice and abundant food and coffee, lots of great content from the speakers and to sign off the day Github guys invited everyone to an open bar drinkup event.
We gave 2 talks, Vitaly's "Performance - When, What and How" and Boris' "Rails Missing Features". Check out slides and videos of those talks.
"Performance - When, What and How"
"Rails Missing Features"
I knew that there are various Ruby patches available but I've never tried them as I didn't want to waste time for something that I thought I don't really need.
Then I found out that rvm comes bundled with patches ready to be applied, so I'm just a simple command line away from having a patched Ruby. Don't know how I missed that before.
One particular patch that worth trying is falcon. It improves startup time of big Ruby applications. And the bigger your Gemfile is the bigger the improvement.
Try it right now for yourself. It will only take a couple of minutes.
First upgrade rvm to make sure you have the latest
rvm get head
Then the actual Ruby build
rvm install 1.9.3 --patch falcon -n falcon
Note that this command can fail with the following error: Patch 'falcon' not found. The reason is that falcon patch is not yet supported on the latest Ruby patch level, in which case you will need to specify older patch level to make it work.
Find out what patchlevels have falcon support
✗ ls $rvm_path/patches/ruby/1.9.3/*/*falcon* | sort /usr/local/rvm/patches/ruby/1.9.3/p0/falcon.patch /usr/local/rvm/patches/ruby/1.9.3/p125/falcon.patch /usr/local/rvm/patches/ruby/1.9.3/p194/falcon.diff /usr/local/rvm/patches/ruby/1.9.3/p286/falcon.diff
So latest patch level with falcon support is 286 at the time of this writing.
Install specific patch level with falcon support
rvm install ruby-1.9.3-p286 --patch falcon -n falcon
Congratulations, you now have a patched Ruby installed.
Lets test how much improvement it is. The following is for one of my current projects with about 50 gems:
✗ rvm use default Using /usr/local/rvm/gems/ruby-1.9.3-p194 ✗ time bin/rails runner "puts :OK" OK bin/rails runner "puts :OK" 6.47s user 0.60s system 99% cpu 7.106 total ✗ rvm use ruby-1.9.3-p286-falcon Using /usr/local/rvm/gems/ruby-1.9.3-p286-falcon ✗ time bin/rails runner "puts :OK" OK bin/rails runner "puts :OK" 2.79s user 0.52s system 98% cpu 3.354 total
Nice! Startup time decreased from 3.354 to 1.106 seconds. More then twice faster.
I'm going to use this Ruby by default now
rvm use ruby-1.9.3-p286-falcon --default
And while we are on the "lets improve rails startup times" subject, lets do one more change. Add the following to your shell startup file. i.e. ~/.bashrc or ~/.zshrc
export RUBY_HEAP_MIN_SLOTS=1000000 export RUBY_HEAP_FREE_MIN=500000 export RUBY_HEAP_SLOTS_INCREMENT=1000000 export RUBY_HEAP_SLOTS_GROWTH_FACTOR=1 export RUBY_GC_MALLOC_LIMIT=100000000
This will tune Ruby GC settings to be better suited for running big apps (as it seems to be tuned for small Ruby scripts by default).
Lets see how much improvement that is
✗ time bin/rails runner "puts :OK" OK bin/rails runner "puts :OK" 2.27s user 0.58s system 98% cpu 2.890 total
Total improvement from 7.106 to 2.890 is almost 60%.
Now, stop fiddling with the environment and go back to creating something great! :)
I had a lot of things to do last Thursday, Feb-17. I met a friend from abroad 3am at Ben Gurion Airport and spent several hours talking before we went to sleep, signed a contract for developing killer web app at 1:30am, and finally gave a presentation at The Junction at 4:30pm.
I was working on tests for blender when I came upon a need to mock or stub a back-tick operator e.g.:
Apparently this is just a shortcut for calling Kernel method :`.
I just recently reinstalled my MacBook Pro, this time with Snow Leopard.
So I'm again going through various installation problems I already forgot about from few years back when I installed Leopard.
Anyway, just had to hunt down a problem with mysql gem installation on Snow Leopard.
Supports ERB and HAML for now, vote on site for more formats.
Beautifully crafted, totally free and it's kinda fun.
I've just read "Do You Believe In Magic?" and the following quote resonated particularly well:
"It's not magic. There is no magic involved. It's just, if you never learnt Lisp, then you never learned to program, and Ruby's power is exposing a deficiency in your skills."
Yeah, I know, MVC is the "Only True Way". But sometimes, just sometimes, you need your link_to or html helpers working in the model.
For example, sometimes the cleanest way to implement something is to have to_html in the model (widgets anyone?).
Doing this will most probably require generating some urls, and you need a controller for that. Usually I solved this by passing controller to the to_html function, but it always felt wrong.
And those two are getting along just fine, until the user logs in. After that clicktale service is cut out of the html pages this user gets and can't record the session. But it just started to get interesting...
Thanks a lot to Amit Hurvitz for providing a file of Virtual Disk Image (VDI) of VirtualBox, containing an up and running JRuby on Rails on Glassfish with Mysql. Image also contains some examples (actually solutions to the code camp exercises), all running on top of an OpenSolaris guest OS (can be run on many host systems).
Grab the image ~1.5GB archive.
Grab the exercises ~9.7MB archive.
We participated in JRuby on Rails with GlassFish Code Camp hosted by Sun Microsystems Inc. I was speaking about the framework in general trying to infect Java developers with Ruby On Rails. Slides are available.
I was the last person in our company working with ERB to render templates. While all the rest switched to HAML. At the beginning it was quite hard for me to read HAML comparing to ERB. HAML looked for me like some completely alien thing with weird percent marks all over the place and the significant whitespace never did it for me. On the other hand ERB felt like warm home after years we spent together.
Until I did the switch.
Recently we looked for video transcoding/hosting solution to use in one of our client's projects.
Using amazon has many advantages. no contracts, pay as you go, easy and fast scaling in case your site explodes :)
Unfortunately the image that is refered in the Getting Started (ami-05d7336c) is not safe for production - it has openssh version with a serious security bug, but don't worry, we will explain how to fix it.
This blog-post is mostly targeted at non-Rails developers. Rails devs should know all this by heart :) Many times we need to explain to our customers what is 'proper deployment' and why their current one sucks :) Now we'll be able to just point them to this post...
On one of our projects we needed to do some caching for an action with an expensive db query. Fragment caching took care of the rendering but we needed a way to skip the db if we have a cache hit. And checking for an existence of the fragment file in the controller just didn’t seem right.