Hacker News Reader

Comment by chrismealy | Hacker News Reader

I love ruby and rails, but yeah, I'd switch to any framework in any language that made deployment stress-free. Except php.

View on HN

Play's deployment process is more or less:

$ play dist

$ unzip app-name.zip

$ cd app-name

$ ./bin/start

Can dist on build server and copy archive to prod if that option is available (or upload from local dev machine).

It's ridiculously simple, and all generated at compile time.

I don't understand hand wringing deployments, is Rails _that_ good?

I mean, outside of MVC, RESTful routing, form validation, AR, migrations, etc. functionality that exists in other frameworks/libraries, what does Rails actually bring to the table that is unique?

Is it the gem ecosystem, where you can find x,y,z functionality that exists nowhere else, or some cutting edge Rails feature? I don't know, just asking, spent a year on a Rails clone, Grails, and was not really taken, tracking runtime MOP errors is no joy, give me a static compiler any day over that.

I live Play, but that deployment only works for the simplest solutions.

Need versioned assets? Need multiple versions of assets in prod? Play doesn't do it out of the box.

Need a specific version of the JVM? Play can't help you there.

Need to change your start script to do something different (ports, SSL, JVM config). Play can't do it.

Play is very far from deploy script.

> Need versioned assets? Need multiple versions of assets in prod? Play doesn't do it out of the box.

Just turn off assets entirely as the Capistrano author does with Rails. Running Bower + GruntJS here, snappy fast, well happy working with tools designed for the job.

Not sure about multiple asset versions, I just have front end web server handle inbound /assets/img/foo.timestamp.png request as /assets/img/foo.png. It's not too difficult to create an asset helper trait to append timestamp at container start up to asset paths.

> Need a specific version of the JVM? Play can't help you there.

This is hardly a strike against Play, installing Java is not exactly an overwhelming task ;-)

> Need to change your start script to do something different (ports, SSL, JVM config). Play can't do it.

Excuse me?

./bin/start -server -Xms128m -Xmx512m -Dhttp.port=9001 -Dhttp.address=172.16.53.1 -Dlogger.file=${HOME}/logger.xml -Dconfig.file=conf/prod.conf

The JVM has a lot of tools that make SysAdmins happy (or at least not grumpy) to deploy projects. Some cost a fair amount, but the list of JVM languages is pretty nice.

Heroku, EngineYard, etc? Unless you're also adding "cheap" into the equation too.

Me I run Rails on Linode and it's fine, but yes, it's unfortunate Ruby/Rails never reached LAMP-level simplicity on virtual hosts.

Go's static binaries are pretty fantastic- though there are other details that you may care about more.

I'm starting to wonder if all this developer time we're saving by using Ruby is leaking out in other places (chiefly, deployment and performance optimization). I'm new to Go, but it seems to me that deployment and optimization are considerably less of a problem while also not costing me much on the development side of things.

I'm not sure, I just think it's worth discussing.

Ruby is uniquely awful on the deployment side, I have to say.

I think most of these development worries are more likely related to language independent deployment issues, mostly static assets processing: optimizing images, minifying Javascript, running CSS preprocessors, versioning everything to prevent caching, generating and copying configuration files, other necessary file/folder transformations for creating a running application. Sure the dependency worries are bothersome too, but I'm not sure they're the whole problem.

Really, the core of this is about the asset pipeline. A valuable feature that does not exist in other frameworks. It sucks having to write that plumbing code yourself.

php is really simple to deploy, you know ;)

Python with virtualenv and pip has been fairly stress free in my experience.

I feel Python apps is quite a pain to install. I had to deal with a Graphite installation, and it consists of 50% packages from apt-get and 50% of packages from easy_install.

https://gist.github.com/kaspergrubbe/5792356

Is this an issue with Graphite? Because I feel this setup is quite elaborate compared to using Rubygems and bundler.

That's a rather alarming install script, especially things like:

    sudo apt-get --assume-yes upgrade

in it. But to your point, I think most of the easy_install packages could be handled by pip. The apt packages look like almost all non-python major components like rabbitmq, apache, sqlite, etc which are best provided that way.

I'm not sure about Graphite itself, but at a quick glance it's not clear why it's all 'sudo python setup.py' rather than in a package.

From experience with both python/django and ruby/rails, I think python is generally simpler. Start with the fact that python itself is usually pre-installed on most distros, and usually a recent-enough version to get you started. Ruby on the other hand is much harder to just get installed, choosing the right (minor)version, rvm/rbenv choices etc. I tend to compile my ruby, but it's a lengthy and rather fragile process.

Graphite is both a good and bad example. Good because it is really complex and documentation is a little sketchy. I've written a fabric script[1] that automates the process, and it's far from trivial. Bad example, because it's not really a single app, but a system - a collection of tools with dependencies. Even if we discount the web server (nginx or apache?), it includes things like the core "database" (whisper), the event listener (carbon, which in itself is complex depending on your setup), the graphic and processing libraries, and then graphite which is a pretty involved django app with its own sub-components.

So when you say graphite, it's really a full-blown system with lots of moving parts that need to fit in together. I can't think of an equivalent example in the rails world, but any rails app with a db, caching layer, and a few other external components won't be much easier to get set up and running.

[1]https://github.com/gingerlime/graphite-fabric

This is an issue with Graphite. There is no way that Python can fix Graphite's install breakages unless Graphite wants to fix them.

I guess that's because you can't pip install system packages, only Python packages.

I've generally had the same experience, although that particular toolchain only solves part of the deployment problem. The other caveat is that you will eventually run into a situation where, say, pip doesn't quite make it to the finish line, and you're left wondering why. If my memory serves me, the last time this happened to me was while I tried to install a project that used ipython (=zmq+readline+pyglets+..+..+) and needed a numpy that was properly linked to the intel MKL. It failed at the 'pip level' but I didn't arrive at a solution wasn't clear until I dove much deeper (python build, MKL build, ZMQ build, setuptools interactions, autoreconf incantations, etc.) There are definitely times when it pays to understand things like the differences betweening pipping and easy_installing.

However, when dealing with projects that are closer to pure python, and/or less complicated, workon proj && pip install < requirements.txt has almost never failed me.

More and more I find myself moving to Ansible. So good.

Reply on news.ycombinator.com