One clarification of what it means to "develop" on a TextDrive server

There have been some discussions about “developing” on our servers and I realized that most people don’t know my relatively narrow and specific view of what it means to develop on one of our servers.

And that the issue isn’t really about “developing”, the issue is general sloppiness and the lack of a thoughtful development workflow (most likely because of a lack of experience). When you live by yourself, you can be as sloppy as you want to be, but when you live with others and sometimes they want to be presentable, you can’t be. And once money is injected into the entire situation, then that becomes ever more important.

Most of the current development going on (including at TextDrive proper) is in Rails, and we’re hosting well over a thousand rails-based sites (many also using lighttpd). One view of developing can be defined by this:

“Developing” could mean persistently running in the development environment and leaving those processes around when you aren’t using them.

That’s pretty much it.

On more than one occasion, we’ve had to rescue someone from a huge log file that took over their space (huge = up to a 150GBs). And in my opinion, there’s no reason to actively log a perfectly functioning site.

Then running in the development environment is slower, exposes your app (people see rescue pages for example) and the problem server-side is that there is a degree of memory leakiness: everyone’s apps get bigger and bigger and bigger until we essentially have to reboot a machine to claim back GBs worth of RAM.

Running your app under the production environment with lighttpd’s fastcgi is easy, it takes adding a bin-environment line to fastcgi.server:

fastcgi.server = (
               ".fcgi" =>
                    ( "localhost" =>
                        (
                            "min-procs" => 1,
                            "max-procs" => 1,
                            "socket" => "/home/manuals/tmp/manuals-hieraki.socket",
                            "bin-path" => "/home/manuals/hieraki/trunk/public/dispatch.fcgi",
                            "bin-environment" => ( "RAILS_ENV" => "production" )
                        )
                    )
)

It can also be done by wrapping the dispatch file or by changing from “development” to “production” in environments.

The main reason I’m pointing this out is that a clean Rails install defaults to the development environment, so switching is an active step you have to take.

Now is the development environment absolutely forbidden?

Of course not.

Deploying on a server follows the same model as Rails, when you’ve pushed something up that’s going to be running and getting traffic, run it in production mode. If something makes you say “hmm?” and you’d like to switch over to dev mode to see, that’s fine, just don’t leave it in development mode, turn on adaptive fcgi spawning and start telling people about the site.

Then if you’re staging and it’s not public, running it in development mode all the time is fine. But it’s the same thing, don’t leave it running: there’s no need. If no one is hitting the site and you’re going to be out, turn it off.

That all said, we’re all about developing (for example, the first version of things like subversion that we hosted was 0.3.8 …) and we’re a “hosting” company founded by developers.

So go out and make something cool, go out and make the Next Big Thing, go out and make something that’ll make everyone else go “damn, that’s nice”.

And by all means, do it here.

·:· Posted 18 June 2005, 23:52 by Jason Hoffman to Scripting  |  

  1. Actually a couple more steps might be useful :
    the first is to remove color from the log file. To do this, add this line to your production.rb env file:

    ActiveRecord::Base.colorize_logging = false

    The next step is to admit that you really don’t need to log sql queries and the like, or anything that isn’t stricly erroneous.

    To do this simply add this line at the end of your config/environment.rb (after the line that says : # Include your app’s configuration here: )

    RAILS_DEFAULT_LOGGER.level = Logger::ERROR

    For the curious ones, no you can’t add it in the production.rb since RAILS_DEFAULT_LOGGER is not yet initialized yet. There might be an option I am unaware of to achieve the same result in a tidier way, but this should be good start.

    — Jean    9 June 2005, 06:33    #
  2. Beautiful, thank you for the input Jean.

    — Jason Hoffman    9 June 2005, 07:06    #
  3. Jason,

    I assume there’s no easy way for you to just ‘default’ RAILS_ENV=production site wide?

    We default to development, but only if ENV[‘RAILS_ENV’] is nil

    — Michael Koziarski    9 June 2005, 22:56    #
  4. No, because under Apache that’s stripped by suexec unless it’s in a wrapper file that sets that ENV and exec’s dispatch.fcgi.real, and then under lighttpd, it has to be set in that app’s fastcgi config.

    But that’s okay.

    I LIKE the fact that people have to do this on purpose.

    — Jason Hoffman    10 June 2005, 04:13    #