We just added a Rails application dashboard to FiveRuns Manage that summarizes high-level application metrics. If you are a current user of FiveRuns Manage, you can now easily assess your Rails application’s health with a quick glance. If you are not currently a FiveRuns Manage user, it’s easy to start a free 30-day trial by clicking here.

Here’s how it works. This single-page view presents what we consider the most relevant data about any monitored Rails application. It highlights important metrics for sysadmins and also provides starting points for developers to improve an application’s performance, if necessary.

On the left “Performance” column, users find average global metrics and associated sparkline graphs for the selected time period. The page default is 6 hours but can span a range from 1 to 24 hours. Following any of these metrics takes users to the detailed, interactive metric graphs in Manage.

As a complement, the right “Analytics” column lists the ten slowest actions and the ten most invoked actions of this application. Combined, both tables provide developers valuable indicators where to spend their energy to improve the overall application performance.

Following these links sends users to the application analytics page that breaks down action performance into more granular detail. For example, developers can learn how much time an action spends using specific models or rendering specific partials. We published a popular Rails application performance optimization post a while ago that explains in detail how to debug typical performance bottlenecks with the application analytics pages in FiveRuns Manage.

Developers need to evaluate the priority of performance issues of particular actions. That’s why both average response time and the number of invocations together are important. The below screenshot shows an example scenario where the slowest action of an application is not even listed in the list of most frequently called invoked actions. Here, the index action of the MetricGraphsController is the slowest one. However, it only gets invoked twice during this 6 hour time window. In order to improve overall Rails application performance, engineering resources might be better applied to another actions that get called much more often.

As a FiveRuns Manage user, you will see the new app health pages whenever you select an application or cluster from the application map. They are the new starting points for exploring the performance of your Rails applications in production and will greet you whenever you check on your Rails applications.

If you’re not yet using FiveRuns Manage to monitor and tune your production Rails applications, please check out our free 30 day trial.

[Announcements Rails rails Rails ]
View original post | Add to del.icio.us| Updated 4 months ago | Share

One of the critical components FiveRuns Manage allows you to monitor is the memory usage of your Rails application server. Memory usage is one of the metrics that can provide insight into the availability and responsiveness of your Rails system. These measurements are global to the operating system and independent of your individual Rails application processes.

Which Metrics To Track?

To accurately gauge memory resources, Manage correlates the relative metrics. In the example below, a low percentage of free system memory does not necessarily indicate a resource constraint. The operating system may allocate the bulk of available physical memory to optimize server performance.

Sustained contention for RAM however, can generate swapping to your virtual memory system. This is a good indicator the physical memory is constrained and you are paying a performance penalty by swapping out to disk. Manage tracks both physical and virtual memory statistics like swap in, swap rate and page file usage.

Threshold Triggers

Browsing memory metric graphs is exciting and all, but maybe you’ve got some other things do? No problem. Manage allows you to configure custom alerts using your Rails environment’s baselines and important metrics. The memory example above could be built into a trigger with two simple conditions to provide a more accurate notification of a system problem. When conditions meet your criteria, an email alert is generated with a synopsis of the situation and a link back to the FiveRuns console where you can investigate in more detail.

FiveRuns Manage leverages the full stack of your Rails server metrics, to keep you informed of your application’s status. What are the other important metrics you depend on to keep your production Rails applications online? Let us know and we’ll cover them in future blog posts!

[Rails Tips memory metric monitor ]
View original post | Add to del.icio.us| Updated 12 d and 20 h ago | Share

In order to scale our service, a large portion of our Manage service runs asynchronously from the http://manage.fiveruns.com website. We use Starling, the fantastic queuing system behind Twitter, to manage jobs to be processed. One interesting twist to Starling is that it uses the memcached client API so any memcached client library can access Starling without any extra effort.

Since our service is 24/7, we needed fault tolerance, high availability and other such high-falootin’ ideals. Our plan was to have two Starling servers, one on each app server, with the job processors using the local Starling server on their own machine by default, falling back to the server on the other machine if the local Staring daemon died.

Seattle.rb’s memcache-client 1.5.0 library supports multiple servers and does make an effort to switch between them but it has three known problems:

1. set() fails when the socket has been disconnected (via Twitter)
2. it does not retry if a socket operation fails (via Will Bryant)
3. it does not retry the current operation on another server if a server dies

The latter issue means that data will be lost when a server dies. We’ve fixed all three issues in our Github repository for memcache-client and Zachary Pinter is working on getting our updated code pushed into Edge Rails. Hopefully we’ll see an updated memcached client in Rails soon. In the mean time, please feel free to fork or clone our repository and use it in your own project!

[Open Source memcache memcached rails Rails scalability Scalability starling ]
View original post | Add to del.icio.us| Updated 5 months ago | Share

Welcome to this week’s edition of Rails TakeFive, our ongoing interview series of insight and commentary from notable members of the Ruby and Rails community. This week, we’re happy to welcome Jacques Crocker, a Rails developer from Palo Alto and the man behind RailsJedi.com.

FiveRuns: Welcome Jacques, and thanks for joining us! Let’s kick it off by talking a bit about Rails 2.1, which was recently released with the help of over 1400 contributors. What about the new release excites you the most? And as a follow-up, what are the most important things in your mind to get done for the next major release?

Jacques Crocker: Rails 2.1 was an amazing point release. One of my biggest pain points for a long time has been gem dependencies. 99% of all my Capistrano deployment failures up until recently were because one gem or another was installed on my local machine but not on the server. In fact, I was halfway done writing my own little gem dependency management plugin that was in use on several of my sites before I saw the edge Rails announcement and subsequently ripped out all traces of my version of the code.

Also, named_scope was a very nice addition to the core. I was already using the excellent scope_out plugin on all my projects, however it had some quirks that have all been smoothed out after switching over to named_scope.

The most immediate need I see for the next release of Rails is to be able to split up large rails projects into separate projects that can easily share code. As soon as any Rails project gets up to 25-30 controllers, it starts to lose a lot of the fun it had when it was 5-6 controllers. But if your Rails project was instead maybe 4 independent but related applications, each with 5-6 controllers then I think development would be a lot more enjoyable for large projects. The trick is allowing these projects to reuse common functionality without becoming too interconnected so they can be swapped out and shared easily. Rails Core needs to address this if they want to take on the real scalability problem, that is scaling a large code-base.

I’d also love for them to ditch migrations altogether and integrate PJ’s auto_migrations plugin.

FiveRuns: You’ve recently written about Phusion Passenger. Tell us a little about your experiences with it so far.

Jacques Crocker: Yep, I’ve been using mod_rails extensively since RailsConf. Given the meager amounts of memory most virtual servers provide, I see Phusion Passenger as a massive benefit since you no longer have to worry about running X numbers of mongrels, and can rely on Passenger to scale up and down as needed. In addition, the use of Enterprise Ruby has decreased memory usage on my servers fairly dramatically (20-30%).

Deployments with Passenger have been a big improvement over the old mongrel/nginx process. It cut my Capistrano config in half, as I used to have all the nginx load balancing config, and mongrel setup as part of my deploy.rb. Now it’s just a simple git update, gem install, migration, and server restart. I’m even exploring the possibility of running any pending migrations automatically as part of the application initializer.

I’m also really excited about the Rack support, giving us an easy way to deploy other Ruby frameworks (like Merb). Rails 2.2 should bring Rack compatibility as well. That should enable a consistent deployment platform for all Ruby web frameworks.

FiveRuns: On that note, let’s talk about Merb – they are all about being agnostic—ORM-agnostic, JavaScript library agnostic, and template language agnostic – what does this mean? And what does it mean to be “thread-safe”? Is there promise in implementing Merb alongside of Rails, say, for processing?

Jacques Crocker: I think Merb is a natural response to some of the wrong choices the Ruby on Rails team made in picking libraries to promote. While Rails initially got me into Prototype and Scriptaculous, I quickly grew frustrated with the framework and made the switch to JQuery. In fact, every time I fork my base Rails project, by default it has JQuery for Javascript, HAML for views, and Sass for stylesheets. I have a suspicion that within a year, it might also include DataMapper as a replacement for ActiveRecord.

I was extremely happy to see that Merb decided to implement “slices”, which is similar to Rails Engines, a hugely mistreated Rails plugin. Engines could have been revolutionary had it been encouraged and integrated by the Rails Core. I’m hoping that merb-slices will demonstrate to the Rails Core team that pluggable, self-contained apps are really the only way we’ll be able to manage our applications’ rapidly growing complexity.

The whole “thread-safe” concern, for me, has been rendered mostly irrelevent. With Mongrel clusters (and now Passenger), the core threading issues have been fairly easy to work around. As for mixing Merb and Rails on the same application, it’s probably a bad idea. If you need an alternative for some fast processing alongside Rails, Sinatra would be an even lighter, faster alternative.

FiveRuns: Beyond Merb, you mentioned Sinatra, but there are a great number of alternative frameworks for Ruby, including Nitro, Waves, Ramaze, Camping, ... What have you seen so far that you really like? Dislike?

Jacques Crocker: After Erik Kastner’s excellent session at RailsConf this year, I starting using Sinatra on some toy projects and have been impressed with it.

Just being able to create all your controller actions in one file is great for small projects, as you don’t have to explore your project directories whenever you need to find something. Plus I love the fact that I can still use HAML and Sass, which drastically reduces the size of the HTML and CSS needed in the view.

The major downside of course is the lack of Rails plugins, which can save a lot of time implementing complex features like tagging and S3 file uploads and can be extremely time saving for even really small projects. However I think the Sinatra community is growing fast and will eventually have stable ports of all the most popular Rails plugins.

FiveRuns: Obie Fernandez’s startup Hashrocket, which has been blogged about extensively, is all about being ultra-productive in 3 days. Obie has written about ultra-productivity, but we have to ask – what are your own tips around, to paraphrase Obie and 37Signals, getting real—on steroids?

Jacques Crocker: Obie has been a huge inspiration for me. I’ve been involved in rapid startup bootstrapping for a few years now, and it was great to see Hashrocket succeed in delivering rapid development projects as a packaged service.

I took part in last year’s Rails Rumble (building PubBud) and I think the capability is there for anyone to be able to build a significant web application in a few days time, given the right vision and tools. This year there are going to be way more teams, and a lot of excitement as people have been getting much better at building Rails apps fast. I’m looking forward to competing again.

The single best tip I can offer for “ultra-productivity” is to create and continuously improve upon your own Rails new project skeleton. In that skeleton app, collect all the most useful rails plugins, stabilize them, and make them your own. Add in base stylesheets and ui components (I use blueprint) so the views don’t slow you down. Also add in common helper methods that you frequently use.

They key is to use this skeleton often, that is use it to create a new web app. I try to start a new Rails project from my base project at least once a week. Most of the time I leave it after hacking for 3-4 hours, but each time I end up improving on the base project and extracting pieces of functionality into my asset library.

This was one of the ways I was able to implement OpenSourceRails in a single weekend. All the major features – file uploads, tagging, bookmarking, ratings – were stuff I’ve implemented before and were part of my library. Having a collection of tried and true pieces of functionality along with a well structured and familiar base project will be a big time saver on any new project.

Jacques Crocker is a Rails developer from Palo Alto and blogs at RailsJedi.com. He also runs OpenSourceRails.com, a gallery for open source ruby on rails web apps.

[Rails TakeFive Tips interview jacques crocker rails Rails takefive ]
View original post | Add to del.icio.us| Updated 4 months ago | Share

We are excited about the release of mod_rails for Apache. Its innovative approach brings another promising Rails deployment option to the community. The Phusion team behind it has taken an open approach to developing and educating the community. This first release not only looks solid and well tested, it is also well documented.

After using mod_rails in a test environment for a couple of days, I see two typical usage scenarios:

1. As a Mongrel replacement on dedicated servers: If you run a Rails application on a dedicated server or virtual slice with a pack of Mongrels, you can simplify your deployment and remove an indirection. This especially applies if you already use Apache with mod_proxy_balancer. Instead of juggling all Mongrels and their respective ports, you can configure your environment exclusively through Apache’s httpd.conf file. Need more Rails instances to handle the load? Just increase RailsMaxPoolSize and restart Apache. Done.
2. As a new infrastructure for shared hosting: If you are a shared hosting provider that wants to offer reliable Rails application hosting, you now have a real option with mod_rails. FCGI never reliably worked in shared environments for Rails hosting. That situation inspired the development of mod_rails in the first place.

Rails Instrumentation

So, how does mod_rails work in conjunction with our Rails instrumentation? The short answer is: “It just works.” Since our instrumentation is written in Ruby, it is independent of the actual Rails container. Whether it’s Mongrel or mod_rails doesn’t matter.

The long answer has to distinguish between the two usage scenarios above. If you have a dedicated system, like in the first scenario, you can just switch from Mongrel to mod_rails and the FiveRuns instrumentation continues to run. We have one suggested configuration adjustment (see below) but that is optional.

Technically, our instrumentation still works in shared hosting environments, as described in the second scenario, but our current client architecture has not yet been enabled for these setups. The FiveRuns client not only collects Rails data but also other metrics from the operating system, web servers and databases. As a system service it initially needs root privileges for installation to become a system service (during runtime it operates with lowered privileges). However, in shared hosting environments users typically cannot install system services and execute long running processes. We plan to address this in the future.

Suggested mod_rails configuration adjustments

As a Mongrel user, I’m used to long running Rails processes. For example, in my test environment I run four Mongrel instances. I typically start those four processes up and then they continue running, under optimal conditions, until I deploy an application update or have to conduct general system maintenance.

Unlike Mongrel, mod_rails handles Rails instance creation and destruction much more dynamically. With its default settings you can observe mod_rails spawning and destroying Rails process instances within minutes. To me, this approach allows to dynamically allocate server resources in a memory efficient way. This seems especially important to shared hosting environments but not so much to dedicated server environments.

That being said, if you are moving from Mongrel to mod_rails and use FiveRuns Rails instrumentation, you might want to change the following mod_rails default option:

RailsPoolIdleTime 120

This parameter describes after how many idle seconds mod_rails will shut down a Rails instance. The default is 120 seconds. We recommend increasing this option to at least 600 seconds to streamline operations with the FiveRuns client. If you desire more Mongrel-like behavior in your dedicated environment consider increasing this option up to 3600 seconds or more.

Another default configuration parameter you will want to adjust is the following:

RailsMaxPoolSize 20

It defines the maximum number of Rails instances mod_rails will create. In my test environment I typically use four. However, this number will be different for any environment. When moving from Mongrel to mod_rails you should initially use the same number as in your Mongrel environment. Please also note that RailsMaxPoolSize is a global configuration option. If you host multiple, distinct Rails applications with Apache this maximum will apply to all Rails instances across all applications.

Who is switching?

For us as a Rails management provider the interesting question is who will switch to mod_rails in their production environments? Please leave us a comment why you would switch to mod_rails or why you wouldn’t leave Mongrel.

[Rails Tips rails mongrel mod_rails ]
View original post | Add to del.icio.us| Updated 7 months ago | Share

2.0.3 is a minor release containing non-intrusive bug fixes and optimizations.

Changes Vendor Rails optimization Some people vendorize Ruby on Rails. In previous versions, Phusion Passenger creates a new framework spawner which caches the code for the vendorized Rails framework. This step has now been removed because it’s redundant. As a result, Phusion Passenger now uses less memory when serving applications that have vendorized Rails. It is therefore especially adviced that shared hosts upgrade to this version. ‘passenger-memory-stats’ now works on non-Linux systems The ‘passenger-memory-stats’ didn’t work correctly on non-Linux platforms. This has been fixed. However, ‘passenger-memory-stats’ is only capable of displaying the real memory usage of processes when running on Linux. Other operating systems don’t provide a way to query the real memory usage, unfortunately. So on non-Linux platforms, ‘passenger-memory-stats’ will display the Resident Set Size instead. WSGI fixes WSGI support in Phusion Passenger is mostly a proof of concept. Nevertheless, we find it worthwhile to fix any WSGI-related bugs that we may encounter. 2.0.3 fixes Python 2.4 compatibility (previous versions require at least Python 2.5), and fixes some WSGI compliance bugs. Thanks to Weyert de Boer for contributing the latter fix. How do I upgrade to 2.0.3? Via a gem

Please install it with the following command:

gem install passenger

Next, run:

passenger-install-apache2-module

Please don’t forget to copy & paste the Apache config snippet that the installer gives you.

Via a native Linux package

Neil Wilson from Brightbox has kindly provided an Ubuntu 8.04 package for Phusion Passenger. The package is available from the Brightbox repository which you can find at:

http://apt.brightbox.net

Add the following line to the Third Party Software Sources:

deb http://apt.brightbox.net hardy main

(The simplest way to do that is to create a file in /etc/apt/sources.list.d/ containing the deb instruction, and then run ‘apt-get update‘).

Once you’ve done this then you can install Phusion Passenger by running:

apt-get install libapache2-mod-passenger

(Note that Neil is currently packaging 2.0.3, so it might take a while before this release shows up in the apt repository.)

[General ]
View original post | Add to del.icio.us| Updated 3 months ago | Share

Welcome to this week’s Rails TakeFive interview, our weekly discussion about Ruby on Rails with noted developers from throughout our community. This week, Mike Subelsky, co-founder of OtherInbox, hacker, Ruby on Rails developer, SproutCore neophyte, and improv theater director based in Baltimore, Maryland joins us to share his thoughts on Ruby + Rails.

FiveRuns: Welcome, Mike! And thanks for taking the time! Let’s start by talking about GitHub. Now that the Rails repository has been moved over, can you talk a little bit about the benefits of Github and how SCM and agile development go hand-in-hand?

Mike Subelsky: Agile development is greatly enhanced by elegant tools that enhance collaboration and reduce mental friction, and that’s how we view SCM. Knowing you have every past revision of your code available, and being able to create experimental branches means it’s very easy to try new techniques and throw away what doesn’t work. We keep our code trunk pristine, with all tests always passing, and we deploy that code daily to an alpha server meant to host the bleeding edge version of our app. Our users can even login to that server if they want to try out the latest code. We also always have a tagged branch of our code representing the stable release currently in production. If we need to make a bug fix in between releases, we always have that tagged branch ready for commits, while the rest of the team can continue contributing to trunk. If a major piece of work is in progress, it goes into its own separate branch until its ready to be merged into the trunk.

We use Subversion and Git simultaneously, so we’re in a good position to compare the two approaches. We started OtherInbox before GitHub came to the fore, and are still using Subversion for our server code. We decided to experiment with Git and GitHub while rewriting the browser client as a SproutCore application. The learning curve has been a bit steeper than expected, but I am definitely a Git believer. We have people working on this in three different time zones, all able to share code branches and patches very easily, pushing and pulling code all along.

FiveRuns: Bruce likes to talk about “backpacking” through other languages. What others have you dabbled in and/or are you learning right now? How have these travels impacted your work in Ruby? Your overall approach?

Mike Subelsky: Most web development requires you to dabble in Javascript, but this summer marked my conversion from Javascript dilettante to Javascript veteran. It turns out there is a beautiful, functional, prototypal language wrapped inside Javascript. I discovered this for myself while building a full-blown desktop app for OtherInbox that runs inside the browser. In order to make it perform quickly and reliably, I had to learn to think in Javascript, using functional programming techniques, and not think like a Ruby guy writing Javascript.

This has impacted my Ruby work by teaching me how to better use closures and functional programming techniques to full advantage. As one example, in several places in our app, we pass around Javascript functions intended for lazy execution, whenever an AJAX call succeeds. That’s a pretty common technique these days, but in order to take full advantage of it, I had to make subtle but powerful change in my thinking that will reverberate across all the languages I use.

FiveRuns: Let’s switch gears a little and talk about Merb – they are all about being agnostic—ORM-agnostic, JavaScript library agnostic, and template language agnostic – what does this mean? And what does it mean to be “thread-safe”? Is there promise in implementing Merb alongside of Rails, say, for processing?

Mike Subelsky: I love Merb and think there are many applications where people are using Rails but should be using Merb, because they don’t need the entire Rails stack, or because they are doing something too custom and unconventional and end up having to fight with Rails. The agnosticism simply means that Merb leaves more decisions up to you, though there are still plenty of conventions available if you want them in Merb—more and other gems.

Thread-safety means one process can perform multiple tasks concurrently, via threads, without one thread disrupting another. This can yield much more efficiency in many applications. We are considering rewriting a key part of our application as a separate Merb app to run alongside the main Rails app. Right now, we have a lightweight read-only API that the SproutCore client uses to get updates from the server. The code for this uses almost no Rails conventions (we make raw SQL calls and marshal the results into JSON ourselves) so there’s no reason we have to use Rails. If we serve it up via Merb, we’ll get a performance boost and more efficient use of memory, at the cost of extra complexity.

FiveRuns: Switching to the deployment side of things, Amazon + Rails seems to be a prevalent choice right now for developers looking to quickly deploy their apps in the cloud. Can you talk a little bit about the benefits and challenges here?

Mike Subelsky: We are 100% hosted on Amazon Web Services (AWS), except for our outbound SMTP service, and we’ll probably move that onto AWS soon. There’s an immediate business benefit from the greatly reduced costs compared to conventional providers, and how easy it is to launch new instances when scaling horizontally, but to me the biggest benefits accrue to our productivity and imagination. We can fire up servers for experimental reasons, setup copies of our production environment to try out new features, and so on, which make our development processes extremely agile, because servers are a commodity for us, not some precious, limiting resource.

It can be difficult to manage a cloud of servers, though. If you are planning on launching an app of any moderate scale you will end up having to write a lot of tools to launch and provision servers, monitor their health, and consolidate their logs. As our development team grows, we’re outgrowing the home-brew approach I outlined at the Lone Star Ruby Conference. We’re switching our server management over to RightScale, though there are many other services I would recommend. I think they have the best Ruby gem out there for talking to SQS, S3, and EC2, called Right-AWS.

We use S3 for message storage and it has been very reliable.

FiveRuns: Obie Fernandez’s startup Hashrocket, which has been blogged about extensively, is all about being ultra-productive in 3 days. What are your own tips around, to paraphrase Obie and 37Signals, getting real—on steroids?

Mike Subelsky: This may be very trendy to say, but as a developer, I’ve really learned to appreciate the value of having great test coverage. Our app has a lot of moving parts and a very high availability and integrity requirement. We simply cannot and will not ever lose anyone’s email, and we know our customers won’t tolerate even a moment of time without being able to access their email, so the tests help prevent us from ever putting unreliable code into production. It takes extra time to write them, but having a well-tested app means we spend an order of magnitude less time on debugging and troubleshooting, and more time building new features. It also helps us sleep better at night. This summer I made some major schema changes to our app, and I was able to implement them with a minimum of pain because the tests were there to back me up.

As a manager, I always try to keep in mind that our people and what they know are the real platform for our company, not Ruby, Rails, SproutCore, AWS, or any other particular technology choice you could name. I try hard not to dictate the answers to things, or mandate the use of any tool or practice, because often what the team comes up with organically is much better than what I would think of. Except the testing thing, that’s an organizational standard we have that I’m a pretty strong proponent of.

I don’t hear enough about code review. I’d like to figure out a way to inject more code review into our processes in a way that would be agile and not onerous. I think a lot of common bugs could be killed by requiring multiple programmer eyes on production code, and I think it would help developers on a complex project get familiar with more of the codebase.

Mike Subelsky built a variety of Ruby-on-Rails applications as a freelance developer for two years before co-founding OtherInbox with Austin entrepreneur Josh Baer. He is the author of random-data, an open-source Ruby gem used for prototyping new Ruby applications, and wrote two recipes in the recently-released book Advanced Rails Recipes. Prior to becoming a full-time Rails hacker, he served as a U.S. Navy information warfare officer with overseas assignments around the world, including counterterrorism operations during Operation ENDURING FREEDOM. He has also worked as a civilian cybersecurity analyst for the Department of Defense and private industry. He holds Bachelor and Master of Information Systems Management degrees from Carnegie Mellon University, and is a Certified Information Systems Security Professional. He blogs about open-source technologies such as Ruby on Rails and SproutCore at subelsky.com.

[Rails TakeFive Tips ]
View original post | Add to del.icio.us| Updated 73 d ago | Share

This is the first week that FiveRuns is at its new downtown Austin location. Leading up to the move, many of us were talking about how we’d be modifying our commutes to either use public transportation, carpool, or just flat out enjoy the fact that our office is more centrally located. These are my before and after calculations, and I’m hoping that others on the FiveRuns team join in and post their figures. I’m going to include my wife’s mileage also because carpooling factors into the equation. I’m also doing quite a bit of rounding.

Before:
Me: 38 miles round-trip x 5 days / 32mpg = 6 gallons of gas/week
My wife: 19 miles round-trip x 5 days / 25mpg = 4 gallons of gas/week

Fortunately the new office is close to where my wife works and we are going to shoot for carpooling every day.

After:
Both of us: 25 miles round-trip x 5 days / 32mpg = 4 gallons of gas/week

It feels pretty awesome to think about eliminating 60% of our fuel usage, saving us about $25 dollars a week. Granted, this is pretty much an optimal situation, being lucky enough to move both closer to home and within range of a carpool situation.

Personally, I like the idea of free markets showing us pain in the pocketbook when it comes to fuel. Eventually, people will start making changes in their life and we can start to affect the demand side of the supply/demand equation.

[Miscellaneous ]
View original post | Add to del.icio.us| Updated 4 months ago | Share

Harris Jacob has started working on Solaris support for Phusion Passenger, and he’s looking for testers. Please lend him a hand if you have a Solaris machine and would like to run Phusion Passenger in the future.

[Phusion Passenger ]
View original post | Add to del.icio.us| Updated 5 months ago | Share

Coming off an awesome RailsConf, we’re picking back up the FiveRuns TakeFive interviews, our ongoing series of insight and commentary from notable members of the Ruby and Rails community. This week, we’re pleased to have Jeff Cohen, co-founder of Softies on Rails share his views on Ruby on Rails with us.

FiveRuns: Welcome Jeff, and thanks for taking the time to join us. Let’s get started with a question spurred from the recent Ruby Hero Awards. Who is your own personal Ruby hero, and why?

Jeff Cohen: Without hesitation my vote goes to Geoffrey Grosenbach. The official Ruby on Rails podcast had a big influence on me when I first started learning Rails. It was one of the few sources of information I had available to me when I was trying to understand what Rails was all about, and the podcasts just hit the spot every time. His innovative approach with PeepCode screencasts has set the standard again. He’s also one of the living examples of the “Matz is nice, so we are nice” standard that the Rails community would do well to emulate more often.

FiveRuns: Obie Fernandez’s startup Hashrocket, which has been blogged about extensively, is all about being ultra-productive in 3 days. Obie has written about ultra-productivity, but we have to ask – what are your own tips around, to paraphrase Obie and 37Signals, getting real—on steroids?

Jeff Cohen: I’ve found two danger areas where my productivity curve begins to like that deep chasm Gandalf fell into. The first is overdesigning. It’s too easy to build more than you really need. I think I’m being smart, but I’m just wasting time. So I recommend: write tests (or specifications, whatever you want to call them) first. You’re less likely to get too clever. However, you should write them at the highest level of abstraction that you can get away with. High-level tests are good. They give you the freedom to innovate. Testing at too low a level tends to lock me into the “usual” way of solving the problem. The more high-level the tests are, the more creative the solution code can become.

The second productivity gravity well is any UI design work that doesn’t involve coding. Draw on a napkin or photoshop something all you want, but it really means nothing until you see it on the screen. So don’t prototype anything paper if you can avoid it. Start with simple, raw HTML. Inline the styles if you have to. The goal is to go from idea to browser as fast as possible. Make it ugly, just make it work. You can refactor it later into real HTML/CSS/ERB templates once you’re happy that you’re on the right track.

FiveRuns: What was your first “ah-ha” moment with Ruby on Rails and when did you know that the framework was a good fit for you?

Jeff Cohen: It was the fall of 2005, and my friend Brian Eng in the next cube over asked me if I had ever heard of this new thing called Rails. Now, this was back before there was even a 1.0 of Rails - I think it was version 0.13. We were both working as .NET developers at the time. I enjoyed .NET development for desktop applications, but didn’t really get the hang of ASP.NET so I always kind of shied away from web development, even though that was what I really wanted to learn how to do. Anyway, we started learning some Ruby on Rails to see what the buzz was all about. We helped each other figure things out, and pretty soon I had a simple one-model web application running in my browser. It was eye-opening. I used the Ruby One-Click Installer for Windows, the Rails gems, and about 10 lines of code in Notepad. The whole convention-over-configuration thing was just awesome. Rails was easier, more logical, and simply more enjoyable for me than ASP.NET. Within a year, I walked away from my 12-year-long Microsoft-based career to accept a full-time job doing Rails development. But the thing was, I was lucky to have someone like Brian introduce Rails to me, and to learn from. I would never have made the switch alone. So nowadays I try to spend time helping others when they decide to switch to Rails, too.

FiveRuns: Along those lines, do you have any specific recommendations for people switching to Rails from another language or framework?

Jeff Cohen: First, they should learn Ruby apart from Rails. When I see ugly Rails code, a shallow understanding of Ruby is often to blame. The better you get at Ruby, the better your Rails code will automatically become. Second, learn how to model your domain properly. I know Ajax is fun to do, and it’s also easy to put all your logic into your controllers. But the best Rails apps also have a rich, cool domain model. Their models are the gears for the application. The controllers decide which gear needs a nudge, and wonderful things seem to happen. Finally, read! Get a couple books, read blogs, and read other people’s code. Don’t just Google for code snippets and then ask for help when you get stuck two minutes later. You really need to learn the basics first. And once you’ve starting to get your feet under you, start helping others who are just starting out. You inevitably learn something yourself, and it’s a way you can immediately begin to give back to the community.

FiveRuns: Let’s talk a bit about Rails 2.1, which was recently released with the help of over 1400 contributors. What about the new release excites you the most—and as a follow-up, what are the most important things in your mind to get done for the next major release?

Jeff Cohen: I was glad to hear from people who went to RailsConf that Jeremy Kemper spoke about how the core team is focusing less on new features these days, and more on security and scalability. I think the overall feature set of Rails is quite strong. If anything, I want less. I cringe a bit when I see pleas for more configurability. I don’t think that’s what we need right now. Rails must remain good at its core purpose: database-backed web applications. I want it be very opinionated. I love conventions that make things really easy for the 80% case. But one thing I do wish for, is an easier way to share code among Rails applications. Plugins work well up to a point. I think most people would like an easier way to share an entire MVC “molecule”: a model-view-controller capsule that can be shared among applications. It’s not an easy problem to solve, and it’s not like I have a solution for it yet, either.

Jeff Cohen has worked with object-oriented programming languages and frameworks for more than 15 years. A former MCSD, he co-founded the SoftiesOnRails blog at www.softiesonrails.com in 2005. He is the founder of Purple Workshops, and is currently writing a book with Brian Eng titled Rails for .NET Developers to be published by Pragmatic Bookshelf this fall.

[Rails TakeFive Tips interview jeff cohen rails Rails takefive ]
View original post | Add to del.icio.us| Updated 5 months ago | Share

Welcome to this week’s Rails TakeFive interview, our ongoing interview series featuring insight and commentary from notable members of the Ruby and Rails community. This week, we’re happy to be joined by Reuven Lerner, noted developer, Web/database consultant, author, and writer at GigaOm’s Ostatic open source blog.

FiveRuns: Welcome Reuven! Let’s get started by talking a bit about Rails 2.1. What about the new release excites you the most? Gem dependencies? UTC migrations? Better caching? And as a follow-up, what are the most important things in your mind to get done for the next major release?

Reuven Lerner: I must say, I’ve been very impressed with the Rails 2.1 release. I had read through a number of blog posts describing new features before the release itself, so I wasn’t that surprised to see what was in there.

But there’s a difference between reading about the new features and using them, and I’ve generally been quite impressed with the additions. Some of the features that you mentioned are quite useful. For example, I really like the gem dependencies, and have used them to help me when installing an application on a new server. UTC migrations seem like such an obvious feature in retrospect, but I guess it took a while for the community to realize what might happen when you have more than one developer hacking on the database.

Hands down, though, my favorite new feature in 2.1 is the improved caching support, and particularly the integrated support for memcached. I had been using memcached with Rails 2.0, and it worked well — but only after I spent many hours reading through the documentation for various versions of cache_fu, acts_as_cached, and memcached-client. My favorite part of the caching support is the “cache” method, which looks in the cache for a particular piece of data. If the data isn’t already in the cache, you can provide a block that tells Rails what database query to use to get the data; that value is then stored in the cache for the next time around. This feature should make it a no-brainer for everyone to use memcached in their applications.

What would I like to see in the next version?

First of all, I’d like to see even better integration of memcached. The “cache” function is, as I wrote above, useful and powerful. But while I find the syntax to be logical, it’s also a bit ugly. I’ve been thinking that it might be easier to integrate the memcached support into ActiveRecord, such that I can do a Foo.find(:cache…), with the :cache symbol indicating that I want to retrieve the value from the cache if possible. Most of my uses of memcached are with the database, and I’m going to assume that this is true for others, as well. The one fly in the ointment with memcached support is the weird restriction that memcached imposes on keys: They may not contain spaces. One of my main uses for memcached is to cache parameter values that have been set by a site administrator. Because the parameter name is simply a text field in the database, it can include spaces. (I find that this greatly improves usability for my non-technical clients.) I managed to get around this problem by monkeypatching the String class, adding a String#to_mkey method that replaces space characters with underscores. I would think that memcached could perform this search-and-replace operation on its own — but if it can’t or won’t, then I would like to see Rails take care of it. Another weird problem with memcached is that you sometimes need to invoke “require_dependency” if you’re unmarshalling cached objects. This seems to be a well-known problem in the Rails community, and so I was able to find and solve the problem in relatively short time. But I shouldn’t encounter such weird problems at all, and I’d like to think that Rails is smart enough to deal with this automatically.

I would also like to see better support in migrations for foreign keys and other constraints that PostgreSQL groupies like myself take for granted. It’s nice to say that you can execute raw SQL commands from within migrations, but it always seems like cheating when I have to go outside of a DSL.

Finally — and I know that I’m beating a dead horse here — I would really like to see some built-in support for users, roles, and permissions in future versions of Rails. I realize that there are many in the Rails community, including the core team, who argue that by leaving out such functionality, it lets everyone implement users and groups in a way that’s effective for their needs. But I find this to be a fairly unconvincing argument: Nearly every application needs to deal with users and groups in some way, and it would be a tremendous relief to have it built in. Even if Rails doesn’t include actual functionality for users, groups, and roles, perhaps it could include a standard API for working with plugins that handle this functionality.

That is, Rails itself wouldn’t come with a user-role-group system. But it would have a standard plugin interface that would allow a variety of different authentication schemes to connect to it. And this standard interface would also allow developers to write to a common API. Rails loves to describe itself as “convention over configuration,” but for anyone who has to deal with user registration and authentication, there’s a heckuva lot more configuration than convention.

FiveRuns: Bruce likes to talk about “backpacking” through other languages. What others have you dabbled in and/or are you learning right now? How have these travels impacted your work in Ruby? Your overall approach?

Reuven Lerner: I’ve worked with many different languages over the years, and my feet are firmly in the high-level language (known to some as “scripting languages”) camp. I could work in C or C++, but I’ll do almost anything I can to avoid such work — and I’ve successfully done it for more than 10 years, so I’m pretty happy.

For a long time, Perl was my default language. I wrote lots of code in Perl, wrote columns about Perl, spoke at Perl conferences, and even wrote a book about Perl called Core Perl, which was published by Prentice Hall back in 2000. I disliked the Perl inclination for clever, terse code, particularly when it came at the expense of readability. My Perl code was pretty readable, and CPAN meant that you could jump in and start to write an application immediately.

As time went on, though, I began to sour a bit on Perl. First of all, I really wanted “real” objects. And while the Perl object model is good enough for many things, it’s not nearly as completely integrated as Ruby’s objects. Secondly, I feel like Perl 6 is going in a direction that I don’t really like — not that it matters, given that Perl 6 is taking a heckuva long time to develop. It’s always possible that I’ll work in Perl 6 at some point, but I am really wondering who is going to use Perl 6 outside of the small community of Perl 6 developers. Then again, I was skeptical that Perl 5 would catch on, so perhaps I’m wrong on this front, too. I also became increasingly frustrated with Perl’s hazy typing system, in which numbers become strings and vice-versa. For many years, I thought that this was a feature. But I’ve come around on this, increasingly liking the strict typing that Ruby and Python demand. Indeed, I think that Ruby and Python do the right thing: Variables don’t have to be declared, and can contain any value you want. The value has as type, though, and that type won’t change. I don’t think that Perl is going to change anytime soon on this front, a we can see from the recent “smart match” operator, which really gives men pause.

I actually spent a year or two doing a lot of work in Python, convinced that I would switch much of my work to that language. I did a big project in Python, and I decided that while I like Python quite a bit, it’s a bit too formal and stilted for my taste. If I hadn’t discovered Rails, I’m guessing that I would be a Django developer.

But as it happens, I discovered the one-two punch of Ruby and Rails, and immediately felt like I had come home. I think that the Ruby community has swung the object-oriented pendulum a bit too far, with too much emphasis on metaprogramming. But the language, attitude, and community are more in tune with my development interests and style than Perl. Indeed, the syntax of Ruby is enough like Perl for me to be able to write many things automatically, something that I can’t say for Python.

This might come as a surprise, but I have also been doing a growing amount of PHP work in the last few months. (Yes, I would love to work exclusively in Rails. But being an independent consultant doesn’t always guarantee you the freedom that you might imagine!) I have always pooh-poohed PHP, and I still think that there are a number of serious problems with the language. PHP is growing up, and has learned from at least some of its mistakes. I wouldn’t say that its object model is as powerful as Ruby’s, and there is still a long way to go. But it is now possible to write PHP code that can be taken seriously. Moreover, the PHP community has managed to make the language execute quickly in a minimum of RAM, something that I know the Ruby community is working hard to attain. Working with PHP has given me a greater appreciation for Ruby — but it’s not nearly as bad as what you might think, and it’s even possible to create useful and interesting applications with PHP.

Like all Web developers, I’ve been reading and working a great deal with JavaScript in the last year or two, more than I ever imagined would be possible. I was never a big fan of JavaScript, and I still think that functions within functions within functions can get a bit hard to read, as well as tiring to write. But libraries like Prototype have made JavaScript not only palatable, but fun to work with, allowing me to ignore most browser dependencies. The browsers have also improved their support for JavaScript — increasing execution speed, improving standards compliance, and just making the language more stable.

Even if I could ignore JavaScript nowadays, I’m increasingly inclined to say that I wouldn’t want to. I never really imagined myself as a client-side or GUI programmer, but JavaScript is making all of us do client-side work in some way or another, and I don’t think that this a bad thing.

Finally, I’ll mention a language that most readers have probably never heard of: NetLogo. I’m biased, since NetLogo is developed by the research group at Northwestern University where I’m working on a PhD in learning sciences. And it’s not meant to be a general-purpose programming language, although it is Turing-complete, and you can do all sorts of neat things with it. No, NetLogo is a modeling language, meaning that you are expected to use it to create computerized simulations — typically of scientific, mathematical, or social phenomena. NetLogo’s programming model has a distributed feel, even though it’s not distributed; you create various types of “turtles” on the screen that represent different types of agents, and then tell the turtles how they should move and otherwise interact with one another. It’s a very different type of programming than anything else I’ve ever done, and the models library that comes with NetLogo is itself highly instructive and interesting, offering hours (or even years!) of discoveries.

FiveRuns: We’ve blogged a little bit about this recently, but do you have any experience that you can share playing around with Phusion Passenger?

Reuven Lerner: I downloaded and began to use Phusion Passenger several weeks ago, and I’m extremely impressed and pleased. I’m using it on an application that’s about to go live, and while I can’t tell you whether it’s really faster than lighttpd or Mongrel, it just feels comfortable and nice to be back in the Apache world. I’ve been using Apache since before it was released, and the last few years of working outside of Apache have been interesting, but also frustrating. The fact that I can now use Apache on my server, and configure it in the “usual” way is not only comforting, but also helps me to organize my server under a single configuration directory (for Apache), rather than multiple directories and software configuration files, each of which is responsible for a set of ports on my server. I don’t know if I’m the best person to speak about “best practices” for deployments. I feel like I’ve come full circle in the last few years; I spent several years working with Time Warner’s Web sites, where we had very established development, staging, and production servers. That disappeared from my life for a few years, as I either worked on internal projects that didn’t have different servers, or with small organizations that couldn’t or didn’t set them up.

The fact that Rails has built-in support for development and production servers, and even lets me configure the environment differently for each environment, has been a dream come true. And Capistrano has certainly been a huge help on this front, allowing me to deploy to multiple servers with little or no effort. But as for a true best practice? Well, aside from develop-test-deploy, I’m not really sure if there’s a better way to go about things. The tools could be a bit smoother, and perhaps Capistrano could warn me if I’m trying to deploy something that doesn’t pass all of my tests. But I think that for most of my needs, the tools do the right thing at the right time, allowing me to focus my attention on application development, rather than the ugly and annoying aspects of deployment.

FiveRuns: On that note, let’s talk about Merb. They are all about being agnostic – ORM agnostic, JavaScript library agnostic, and template language agnostic – what does this mean to you?

Reuven Lerner: I’m not really that familiar with Merb, other than downloading it, playing with it a tiny bit, and reading about it. The premise is an interesting one, offering developers a toolkit with which they can create their own Web framework, rather than a complete and ready-to-go framework. In some ways, it seems to me that just XML is a language that can be used to create markup languages, Merb is a framework that can be used to create frameworks.

In some ways, this is a highly attractive option: While I like Prototype and script.aculo.us quite a bit, I have sometimes wanted to work with YUI or Dojo, either because they had some useful widgets or just on a lark. Using a non-Prototype JavaScript framework with Rails is theoretically possible, but I don’t think that it’s really practical. Merb, by contrast, seems to really encourage such experimentation.

I’m also a bit fascinated by the idea of using a different relational-object mappers. I happen to like ActiveRecord, but I recognize very well that it’s slow, and that another mapper might work better for my purposes. I’ve been using SQL for a long time, and it’s still sometimes easier for me to express my ideas in raw SQL. And yes, ActiveRecord lets me do that with find_by_sql, but it’s just not the same. I thus see Merb as a “what if?” sort of framework—a kind of edge-edge Rails, allowing us to explore alternatives without being constrained by the decisions that were already made by the Rails core team.

Merb might grow to be popular for actual application development, but I have to wonder if its impact will really be felt by developers, who will be able to compare different pieces of functionality in ways that would be unthinkable with Rails.

Finally: One of the reasons why I so enjoy working with Rails is the fact that it comes with almost everything I need to start working, right out of the box. If I need something, then it’s often (usually) available as a gem or a plugin. I have so much to do that I’m willing to give up a bit of speed if it means greater convenience and time hacking. So I don’t see myself as the ideal audience for Merb.

However, I do think that the people who are developing Rails, and thinking about what should be included in version 2.5, and even version 3.0, should be playing with Merb a great deal, using it to find the best ideas and practices so that the mainstream Rails community can take advantage of what they find.

FiveRuns: Obie Fernandez’s startup Hashrocket, which has been blogged about extensively, is all about being ultra-productive in 3 days. What are your own tips around, to paraphrase Obie and 37Signals, getting real—on steroids?

Reuven Lerner: Oh, how I wish that I could really give advice on how to be hugely productive! People seem to think that I accomplish a lot, and I guess that this is sort of true. (For those who don’t know, I’m the father of three young children, a full-time Web/database consultant and trainer, and a PhD student at Northwestern University. As if that weren’t enough, I’ve been working on an e-learning startup over the last year or so.)

So if I have any “secret” to share about my productivity, it’s a combination of doing things that I do quickly and well (i.e., programming and writing), and sleeping very little at night. I started to sleep very little back when I was in college, editing the student newspaper at MIT. Except for a few years of 9-to-5 work, I’ve been pushing my limits ever since.

But enough about me. What can I suggest that people do to become more productive, or even “ultra-productive”?

I think that the key is to be good at learning new things, and at synthesizing those ideas into an established practice. A lot of classic learning studies have shown that experts — that is, people who have done a task, or seen a problem, hundreds of times — can understand, describe, and solve the problem more quickly and accurately than novices. So in many ways, you can become ultra-productive by seeing the same sorts of problems, again and again. When I first speak with a consulting client, it’s not unusual for me to say, “Ah, I’ve done this many times before.”

The thing is that Web development means learning new skills all of the time. If you’re just going to try to become really good at one set of skills, or at solving one set of problems, then you’ll soon find that the world passes you by. The key to being a good developer is to constantly be improving your skills, learning new languages, frameworks, and techniques and then fitting those into your established work habits.

A key element of being ultra-productive is thus getting really good (and really fast) at learning new technologies, and assimilating them into what you already do. It’s not at all unusual for me to learn about a new technique on a Monday, try it on a Wednesday, and find myself mentioning it to a client on a Friday.

Being able to turn on a dime like that has been extremely helpful in my work, and makes me (I think) a better consultant, as well as a better programmer. How do you become good at learning new technologies? Like any other skill, it’s something that you need to practice a lot. The Pragmatic Programmers say that you should learn a new programming language every year, to keep yourself thinking in new ways. I don’t know if I’d go quite as far as that, but I do agree that you should constantly be challenging yourself to learn new programming techniques, libraries (gems), and other ideas. After a while, you’ll get to the stage in which you can read about a new technique and know how to integrate it not just into a generic program, but into your actual work. But in order to get to that point, you need to read and learn a lot. I read a lot of books and blogs; my kids know that I’m never without a book in my hand, or 2-3 in my backpack (in case I get stuck somewhere).

If you work hard at learning new things, then each new nugget that you learn becomes that much easier for you to integrate, which makes you a more productive person, as well as a more interesting and well-rounded one.

Reuven M. Lerner has been an independent Web/database consultant for 13 years, offering development and training services to companies in North America, Europe, and Israel. For more than three years, his platform of choice has been Ruby on Rails with PostgreSQL, although he uses other languages and technologies as necessary.

He co-founded one of the first 100 Web sites in the world, has written the monthly Web/database developer column “At the Forge” in Linux Journal since 1996, and wrote Core Perl for Prentice-Hall back in 2000. He currently writes for GigaOm’s Ostatic open source blog.

Reuven lives in Modi’in, Israel (halfway between Jerusalem and Tel Aviv) with his wife and three children. He is also a PhD candidate in learning sciences at Northwestern University, creating a collaborative online learning community for authors and users of computer-based simulations.

When not hacking, writing, teaching, or playing with his children, Reuven enjoys making ice cream, walking, and reading.

[Rails TakeFive Tips rails Rails reuven lerner takefive ]
View original post | Add to del.icio.us| Updated 3 months ago | Share

The development version of Ruby on Rails has cool new internationalization features. Although the framework itself doesn’t provide a lot of I18N functionality, it does provide the necessary hooks for plugins to implement I18N however they see fit. Simon Tokumine has written an I18N demo application to show you what Rails is capable of, when used in combination with the localized_dates plugin.

We’ve deployed the demo application at http://i18n-demo.phusion.nl/. Check it out.

[Ruby on Rails ]
View original post | Add to del.icio.us| Updated 3 months ago | Share

Phusion Passenger’s development continues on. A few bugs have been found and fixed. These fixes are deemed to be important enough to backport to the 2.0.x series, so today we present you with Phusion Passenger 2.0.2.

Changes Fixed a file descriptor leak If a system error occurs while receiving the response data from a Rails application, then the file descriptor that connects Apache to the Rails application is not properly cleaned up. This has been fixed. Thanks to TonyLa for reporting and analyzing this problem. Fixed a memory leak Due to an unfortunate little mistake, each time a client disconnects from the ApplicationPoolServerExecutable will result in a small memory leak. In practice, it means this: if your Apache is configured to restart* worker threads or worker processes often (say, every 10 requests or so), then each time that happens, a small memory leak will occur. For most people this is not a problem, because by far most Apache servers are configured to never restart worker threads/processes, or only restart a worker thread/process after several hundred thousand requests. This leak didn’t catch our attention because we used a standard Apache configuration (Ubuntu default).
Once again, many thanks to TonyLa for reporting and analyzing this problem.
(* = This has got nothing to do with the ‘apachectl restart’ or ‘apachectl graceful’ command. These commands restart Phusion Passenger entirely, and will not result in any memory leaks. We were only referring to Apache’s internal process of restarting worker threads and worker processes.) Fixed a compilation problem for some people This has been fixed. How do I upgrade to 2.0.2? Via a gem

Please install it with the following command:

gem install passenger

Next, run:

passenger-install-apache2-module

Please don’t forget to copy & paste the Apache config snippet that the installer gives you.

Via a native Linux package

Neil Wilson from Brightbox has kindly provided an Ubuntu 8.04 package for Phusion Passenger. The package is available from the Brightbox repository which you can find at:

http://apt.brightbox.net

Add the following line to the Third Party Software Sources:

deb http://apt.brightbox.net hardy main

(The simplest way to do that is to create a file in /etc/apt/sources.list.d/ containing the deb anstruction, and then run ‘apt-get update‘).

Once you’ve done this then you can install Phusion Passenger by running:

apt-get install libapache2-mod-passenger

(Note that Neil is currently packaging 2.0.2, so it might take a while before this release shows up in the apt repository.)

[Phusion Passenger ]
View original post | Add to del.icio.us| Updated 4 months ago | Share

A few days ago, the Ruby core team has announced several newly discovered security vulnerabilities. Ruby versions prior to 1.8.6-p285 and 1.8.7-p70 are vulnerable. The previous version of Ruby Enterprise Edition is also vulnerable because it’s based on 1.8.6-p114.

Earlier Ruby releases had some crash bugs and incompatibility problems. It goes without saying that such problems are unacceptable in production environments, so we’ve been careful and took the time to test 1.8.6-p286 against various test suites:

• We tested it against the Ruby on Rails test suite (edge). All tests passed.
• We tested it against the RubySpec test suite (git HEAD from yesterday). All tests passed. In fact, Ruby 1.8.6-p114 fails a few tests, so p286 is more Ruby-compliant.
• We tested it against Typo 5.0.3’s test suite. All tests passed.
• We tested it against the test suite of various of our internal applications. All tests passed.

So our conclusion is that Ruby 1.8.6-p286 is indeed stable and compatible. Kudos to the Ruby core developers for this excellent release!

We’ve prepared a new Ruby Enterprise Edition release, based on Ruby 1.8.6-p286. The official Ruby on Rails wiki has been running on this Ruby Enterprise Edition version since yesterday (in addition to Phusion Passenger git HEAD), and everything seems to be rock-solid so far.

This Ruby Enterprise Edition release not only includes upstream Ruby’s security vulnerability fixes and other bug fixes, but also some Ruby Enterprise Edition-specific improvements and fixes:

MySQL headers are autodetected Many people have problems installing the MySQL gem, especially on non-Linux platforms. That’s because the gem cannot find the MySQL development headers. The Ruby Enterprise Edition installer now autodetects the MySQL headers, for much better MySQL gem installation success rate. Bug fix: don’t overwrite shebang lines for non-Ruby scripts Normally, the installer changes the shebang lines of all scripts in $PREFIX/bin to the correct location of the Ruby Enterprise Edition binary. ($PREFIX is the location that one installs Ruby Enterprise Edition to) However, this would change all shebang lines, even for non-Ruby scripts. This has been fixed: only the shebang lines of Ruby scripts will now be changed. sqlite3-ruby gem permissions fixed The sqlite3-ruby gem installed itself with the wrong permissions. Its files would be world-writable by default. The installer now fixes this problem. ‘PassengerRuby’ instead of ‘RailsRuby’ The installer used to instruct the user to change the ‘RailsRuby’ option for Phusion Passenger. ‘RailsRuby’ has been deprecated since Phusion Passenger 2.0 in favor of ‘PassengerRuby’, so the installer now instructs the user to change ‘PassengerRuby’ instead. Upgrade instructions Via the source tarball

Please download the source tarball from the download page and run the built in installer, as instructed on the download page. To upgrade, please install Ruby Enterprise Edition to the same location that you specified last time.

Via the Debian package

Please install the Debian package by downloading it from the download page. (click on the “Linux” tab)

[Ruby Enterprise Edition ]
View original post | Add to del.icio.us| Updated 3 months ago | Share

Just in case you missed it…

In the latest Ruby on Rails Podcast, FiveRuns Rubyist/Raconteur Adam Keys interviews Geoffrey Grosenbach of Nuby on Rails and Peepshow.

Click here for a listen.

And remember, please don’t show the whale.

[Events Rails ]
View original post | Add to del.icio.us| Updated 4 months ago | Share

One of the lingering issues we’ve had to deal with over the last year in the Manage service is ActiveRecord’s reluctance to talk to more than one database. It’s really quite stubborn in that regard and while there are a few solutions out there, none of them worked quite like we wanted. Some required intrusive application-level code changes, some didn’t offer the features we needed, so we bit the bullet and wrote what we needed.

Specifically we needed two features to scale our mysql database: application-level sharding and master/slave replication. Sharding is the process of splitting a dataset across many independent databases. This often happens based on geographical region (e.g. craigslist) or user account (e.g. flickr). Replication provides a near-real-time copy of a database which can be used for fault tolerance and to reduce load on the master node. Combined, you get a scalable database solution which does not require huge hardware to scale to huge volumes. DataFabric extends ActiveRecord’s standard connection handling to provide these two features.

To install, invoke the usual magic:

gem install data_fabric

Add DataFabric to your Rails 2.1 gems listing in config/environment.rb:

config.gem "data_fabric"

Annotate your sharded models with your desired sharding and replication setup:

class Auction < ActiveRecord::Base data_fabric :shard_by => :city, :replicated => true

Let’s assume we are sharding based on the city associated with the request (i.e. the Craigslist model). You’ll need to add the necessary database connections to your config/database.yml for each city based on the naming convention DataFabric uses. See the README for details.

Finally your application controller will activate the city’s shard for each request:

class ApplicationController < ActionController::Base around_filter :select_shard private def select_shard(&block) DataFabric.activate_shard(:city => @current_city, &block) end end

Now, whenever you do anything with the Auction model, it will only affect the current shard. Auction.find(:all) will find all auctions within that shard. The converse is also true: you can’t do anything with the Auction model until you set a shard. Note that you can just set the replicated flag without the shard_by flag; DataFabric will act just like Rick Olson’s Masochism plugin.

We’re releasing DataFabric on github for others to use as they see fit. Take a look at the README on github for technical details and code samples. We’ve used it successfully with ActiveRecord 2.0.2 and 2.1. There are some areas which can be painful to deal with, notably migrations and fixtures, but we have both working in production here so you can overcome. :-) I’ll give you a hint: the example application might help.

Good luck and let us know what you think!

[Open Source Rails activerecord connection database multiple databases rails Rails ]
View original post | Add to del.icio.us| Updated 4 months ago | Share

FiveRuns developer Eric Falcao gave a talk on Client Side Performance Measurement and Optimization with Rails at this week’s Austin on Rails meeting.

In the talk, Eric discussed his new Clientperf project and some tricks for client-side Rails application performance optimization in the typical Rails/Mongrel/nginx stack.

You can find the slides here.

Enjoy!

[Events Rails ]
View original post | Add to del.icio.us| Updated 4 months ago | Share

So, RailsConf was awesome. Portland was great. But, you’re still wanting more? Hmmm, RailsConf Europe is right around the corner… But, how to get there?

We’d like to help. FiveRuns wants to send you and a guest to RailsConf Europe, September 2 -4, 2008 in Berlin! Entering the contest is easy.

Just download FiveRuns TuneUp, our new, free Rails application profiling tool and upload an application profile (a “Run”) to the FiveRuns TuneUp service between now and August 8, 2008. Current TuneUp users are free to upload Runs, too. We’ll conduct a random drawing out of all the Runs submitted, and if your name is chosen, you and a friend will be on your way to Berlin – airfare, hotel and RailsConf passes included!

So, download TuneUp now, and start Running your way to RailsConf Europe! Hope to see you in Berlin!

Official Rules. Contest open to existing or new users of FiveRuns TuneUp. Download FiveRuns TuneUp at tuneup.fiveruns.com and post a run between July 10 and August 8, 2008 at tuneup.fiveruns.com. On or about August 8, 2008, FiveRuns will conduct a random drawing from all of the users who submitted Runs. The winner will receive two coach class roundtrip tickets to RailsConf Europe 2008, accommodations in Berlin, Germany, and two full conference passes to RailsConf Europe 2008. Airfare accommodations will be roundtrip from the international airport closest to the winner’s home to Berlin, Germany. Flight must depart winner’s international airport on August 31, 2008 and depart Berlin, Germany on September 5, 2008.

[Announcements Events Rails ]
View original post | Add to del.icio.us| Updated 4 months ago | Share

Hot on the heels of the ‘Run Your Way to RailsConf Europe’ contest announcement, we’ve released version 0.8.11 of FiveRuns TuneUp. Since our last publicly-announced release, we’ve made a few substantial fixes and improvements. Most notably, these include:

• Signup and login for the TuneUp service is now only required if you want to share a run. If you just want to use TuneUp locally for your own personal development, you don’t need to sign up at all. If, however, you decide that you’d like to use the (free) TuneUp service to share your runs with colleagues or the Rails community, registration is simple.
• Instrumentation for partial rendering under Rails 2.1 now works properly.
• Fixed some lingering issues with XHTML Strict 1.0 compliance.

Grab the latest gem and get to tuning up your Rails application!

[Announcements Open Source rails Rails tuneup ]
View original post | Add to del.icio.us| Updated 4 months ago | Share

Hi guys.

RailsConf 2008 was great, and our talk on Phusion Passenger and Ruby Enterprise Edition went really well. Fabio Akita has some pictures of our talk. For other pictures, see Fabio’s .mac gallery!

We promised to release Passenger 2.0 and Ruby Enterprise Edition on the same day. Unfortunately we’ve been too optimistic about Internet access. We’re currently at the airport and we have limited internet access until we are back in the Netherlands (which should be in about 4 days or so), but in the meantime, the Passenger version with Rack and WSGI support has already been pushed to github, so feel free to tinker around with it. We’ve also put the latest Users Guide (with Rack support) online.
Thanks for the support Chad!

We’re trying our best to find a way to push out Ruby Enterprise Edition as well, and ask the hardcopy guys to not release it prior to the moment that we’re able to push it (which should be in about 4 days). This launch will also be accompanied by a site etc… Feel free to blog about it though, and the reason why we’re asking this is because we want to keep the support at Phusion related places. This will prevent any ‘noise’ in communication.

Thanks for the support mateys!

Cheers,
Hongli Lai
Tinco Andringa
Ninh Bui

[Phusion Passenger RailsConf Ruby Enterprise Edition ]
View original post | Add to del.icio.us| Updated 6 months ago | Share

It’s a little bit late (this should have been done during RailsConf, sorry), but it’s finally here. We’re pleased to announce Phusion Passenger 2.0, release candidate 1. If no major issues are found, this will become version 2.0.1. We’re also pleased to announce the long-awaited Ruby Enterprise Edition.

RailsConf 2008 presentation

Our RailsConf 2008 presentation about Phusion Passenger and Ruby Enterprise Edition went extremely well. The sheets are available in the following formats:

• PDF (15 MB)
• Flash, with animations (32 MB)

The presentation includes a screencast (23 MB) created by Soocial.

Some people have been distributing our old, outdated sheets, which contain lots and lots of bullet points and almost no graphics. Please download the sheets on this page instead: these are the sheets that we used during the presentation.

Introducing Rack support

2 months after the release of Phusion Passenger 1.0, we present you with Rack support. It is now possible to host arbitrary Ruby web applications (e.g. Merb and Camping) on Phusion Passenger! We provide this feature with the same ease of use that many people have come to love.

The following screencast, created by Ryan Bates of RailsCasts fame, demonstrates the ease of deploying a Rack application on Phusion Passenger:

But that’s not all. We’ve done our homework. Our Users guide provides a comprehensive list of Rackup specifications for all Ruby web frameworks that we could find, so that you don’t have to hunt this information down yourself!

We received some Rack-related contributions shortly after Rack support had been pushed to the public git repository. We’d like to thank _why and remi for contributing documentation and full Rackup DSL support.

Introduction Python WSGI support

Not only do we support Rack, we now also support Python WSGI! In theory, Phusion Passenger can now run Django.

Don’t get us wrong. Phusion Passenger’s main focus is still on Ruby and Ruby on Rails. WSGI support is meant to be a show case of Phusion Passenger’s flexible architecture.

Optimizations Much better stability This new release is much more stable than the 1.0.x series. Many stability issues have been fixed. In fact, Dreamhost and iLike are using this version in production environments. So if you were experiencing stability problems, please upgrade to this version, as it may solve your problem. Much faster graceful restart Some hosts gracefully restart Apache often, so to them, high graceful restart speed is essential. Phusion Passenger 2.0 RC 1 is much, much faster at graceful restarts. Less memory usage: reduced VM size

Process monitoring tools tend to use the “VM size” of a process as an indication of the actual memory usage. This is not correct, because the VM size only indicates the amount of memory that a process can access, not the amount of memory that it actually uses.

Nevertheless, having a large VM size poses problems. Some servers, virtual private servers in particular, have artificial VM size limits in order to prevent processes from using too much memory. Phusion Passenger 1.0 makes Apache’s VM size very large (more than 100 MB), even though the actual memory usage is only several MB.

In Phusion Passenger 2.0, the VM size has been reduced by ten fold, as shown by the following diagram:

Fair load balancing (as opposed to round-robin load balancing)

One of the traditional problems of Mongrel Cluster behind Nginx is, in Ezra’s words:

“My only complaint was that the proxy modue was round robin only. This means that if you had 3 mongrels and one of them performed and action that took say 20 seconds, for that 20 seconds every 3rd request would get stuck in line behind the mongrel doing the long blocking request. This is because nginx was merrily doing round robin and didn’t care if a mongrel was busy or not.”

Phusion Passenger now supports fair load balancing. It will forward a request to the Rails instance with the least number of requests in its queue. Fair load balancing is turned on by default, without the need to configure anything.

See also page 53 of the presentation sheets.

Upload buffering

In Phusion Passenger 1.0, a (long) file upload will block a Rails application instance. Usually this is not a big problem, because Phusion Passenger will spawn more Rails instances if existing ones are blocked. But it becomes a problem if your website handles many simultaneous file uploads (read: more than 10 concurrent file uploads at any time).

Phusion Passenger 2.0 supports upload buffering. File uploads that are sufficiently large, are stored into a temporary file. Only when the file upload is done, will it be forwarded to the Rails application. This means that your Rails applications will not be blocked while a large file upload is in progress.

See slide 86 of the presentation sheets.

Default timeouts changed, in favor of virtual private servers

The default timeout values in Phusion Passenger 1.0 were optimized for shared hosts, which host many applications and need to free resources quickly. But most of our users seem to be using virtual private servers. These servers usually don’t get a lot of traffic, so the default timeouts are easily reached. So we’ve changed the default timeout values in favor of virtual private servers. Shared hosts and people running Phusion Passenger on dedicated servers should adjust the timeouts.

What Default in Phusion Passenger 1.0 Default in Phusion Passenger 2.0

RailsMaxPoolSize	20	6
RailsPoolIdleTime	120	300
ApplicationSpawner server idle time	120	600

Other improvements Ruby on Rails 1.0 compatibility Phusion Passenger is now compatible with Rails 1.0 applications as well. Improved application compatibility: conservative spawning

By default, Phusion Passenger preloads the Ruby on Rails framework and application code. This allows Phusion Passenger to reduce the startup time of Ruby on Rails applications and to save memory. Using this technique, startup time can be decreased by as much as 90%!

Unfortunately, some applications and/or plugins don’t expect to be preloaded, and even assumes that no code is being preloaded. soap4r is one such plugin. Until recently, these applications/plugins didn’t work with Phusion Passenger.

Phusion Passenger 2.0 implements so-called conservative spawning. In conservative spawning mode, Phusion Passenger will not preload any code. In other words, it will emulate the way Mongrel loads Rails applications. Conservative spawning allows Phusion Passenger to be 100% compatible with all Rails applications.

Conservative spawning is less efficient than the default spawning strategy, though no less efficient than Mongrel Cluster. You should only use conservative spawning if you’re experiencing compatibility problems.

‘RailsEnv’ is now per-virtual host The RailsEnv configuration option used to be a global option. It’s now a per-virtual host option, so you can define a different environment for every Rails application. New resource control option: ‘PassengerMaxInstancesPerApp’

The PassengerMaxInstancesPerApp option allows you to define the maximum number of pool slots that a single application may use. This will prevent a single application from getting out of control and taking over the entire server.

Many thanks to Jochen Tuchbreiter for contributing this feature.

Support for worker MPM The Apache worker MPM is now supported. Analysis and system maintenance tools Phusion Passenger 2.0 includes new analysis and system maintenance tools. If you’re experiencing stability problems with Phusion Passenger or your Rails application, then please try these tools. How do I upgrade to 2.0 RC 1? Via a gem

Please download the 2.0 RC 1 gem, then install it with the command:

gem install passenger-1.9.0.gem

Next, run:

passenger-install-apache2-module

Please don’t forget to copy & paste the Apache config snippet that the installer gives you.

Via a native Linux package

Neil Wilson from Brightbox has kindly provided an Ubuntu 8.04 package for Phusion Passenger. The package is available from the Brightbox repository which you can find at:

http://apt.brightbox.net

Add the following line to the Third Party Software Sources:

deb http://apt.brightbox.net hardy main

(The simplest way to do that is to create a file in /etc/apt/sources.list.d/ containing the deb anstruction, and then run ‘apt-get update‘).

Once you’ve done this then you can install Phusion Passenger by running:

apt-get install libapache2-mod-passenger

Finally, run the following command. This will tell you how to configure Apache.

passenger-install-apache2-module Ruby Enterprise Edition

Ruby Enterprise Edition has been officially launched. Check out http://www.rubyenterpriseedition.com/

<