31–40 of 80 posts
This is how Heroku got started and they quickly figured out that the editor in the browser was an issue. No one liked it.
This is how Heroku got started and they quickly figured out that the editor in the browser was an issue. No one liked it.
This is how Heroku got started and they quickly figured out that the editor in the browser was an issue. No one liked it.
Hm. This is one of the rare times where a product actually does too much for me. If it gave me the ability to build and manage virtual envs for testing and development with ssh access (and maybe the ability to download them in say... vagrant box format) and nothing more, I would be sold immediately. With the glossy IDE finish: not my thing :/.
I'm very excited about the possibilities that action.io provides. Additionally, I think integration between the two would be the best of both worlds, providing a CLI based interface and possibly non-web based development through my virtualization providers (VirtualBox for now, many more coming soon), as well as web-based development should you want it using the fantastic tools that action.io is building.
We'll talk and see if we can come to a mutual agreement/vision. :)
Serious question from Python-land, that I think may illuminate the difference in mindset. Why are Rails people so obsessed with accelerating the trivial? I mean, the other end of the spectrum is to be focused purely on the obscure and utterly advanced, like category theorists trying to harness Haskell. I've always felt the strength of the Python community is that it was able to let the idioms and cleanliness of Pytho…
The point is that managing 5 Rails apps, one on Mysql, two on Postgres, two on CouchDB, one with Redis, one with Memcached... (and so on so forth) gets non-trivial soon if you don't grow beyond managing it all on your development machine.[1] Suddenly, all that trivial development stuff becomes a question of configuration management.
What the Ruby community understands is that trivial things can pile up into something non-trivial. This is why Heroku solves a trivial problem (deploying a process on some defined environment using git) and takes it to a big scale. Github does the same for repositories (arguably one of the "trivial" tasks for sysadmins) and provides it for a good amount of money. All those services started in the Ruby community for a reason. We love the mundane, as everything else is based on that.
[1] Alternatively, if you are not consulting, multiply the trivial problem by 20 developers and a growing code-base.
Serious question from Python-land, that I think may illuminate the difference in mindset. Why are Rails people so obsessed with accelerating the trivial? I mean, the other end of the spectrum is to be focused purely on the obscure and utterly advanced, like category theorists trying to harness Haskell. I've always felt the strength of the Python community is that it was able to let the idioms and cleanliness of Pytho…
This is their first iteration. For a simple Rails app, setting up Ubuntu an RDBMS and Redis is trivial, thats true. The point is that managing 5 Rails apps, one on Mysql, two on Postgres, two on CouchDB, one with Redis, one with Memcached... (and so on so forth) gets non-trivial soon if you don't grow beyond managing it all on your development machine.[1] Suddenly, all that trivial development stuff becomes a questio…
I just got done proselytizing the benefits of automation.
I'm not arguing against myself. I'm concerned with why everything Rails people promote and celebrate seems to be along the lines of what originally popularized the framework.
"Make a blog in 15 minutes!" --- you remember this one? Were you programming back then? It's exemplary of what I'm talking about.
Why are they accelerating the trivial? How many times do you really need to deploy a vanilla Rails app over and over in 1,000 different ways? There's much more to deployment than that, and if that's all your needs are, then there isn't much to say.
We should be learning new and advanced ways to manage complexity with Capistrano or Vlad the Deployer or some non-Ruby deployment tool like Puppet, CFEngine, or Chef.
Partly because they can help deal with things other than just the Rails app itself, which is the easy part generally speaking.
Serious question from Python-land, that I think may illuminate the difference in mindset. Why are Rails people so obsessed with accelerating the trivial? I mean, the other end of the spectrum is to be focused purely on the obscure and utterly advanced, like category theorists trying to harness Haskell. I've always felt the strength of the Python community is that it was able to let the idioms and cleanliness of Pytho…
Though this project is interesting, it's not really going to make much of a dent in my daily workflow. There is a metric shit-ton of work being put into things that do. Over the past few years:
* The Rails queuing API (so you all queuing methods e.g. via Resque or DelayedJob have a common client interface).
* The asset pipeline (css/js concatenation + dependency management, plus precompilation for prod).
* Profoundly, bundler. I dread doing anything without having bundler there to declare, manage and allow me to browse the code of all my dependencies.
So yeah, the stuff that makes the news on HN isn't where the goodies are at in Rails.
> I've always felt the strength of the Python community is that it was able to let the idioms and cleanliness of Python stand for themselves while they advance of the state of the art for the work-a-day programmer.
:%s /Python/Rails/g
Serious question from Python-land, that I think may illuminate the difference in mindset. Why are Rails people so obsessed with accelerating the trivial? I mean, the other end of the spectrum is to be focused purely on the obscure and utterly advanced, like category theorists trying to harness Haskell. I've always felt the strength of the Python community is that it was able to let the idioms and cleanliness of Pytho…
Serious response from Rails-land. Though this project is interesting, it's not really going to make much of a dent in my daily workflow. There is a metric shit-ton of work being put into things that do. Over the past few years: * The Rails queuing API (so you all queuing methods e.g. via Resque or DelayedJob have a common client interface). * The asset pipeline (css/js concatenation + dependency management, plus prec…
I'd seen the Resque/DelayedJob stuff. The equivalent in Python-land are Celery and Carrot. They're probably not much different.
>* The asset pipeline (css/js concatenation + dependency management, plus precompilation for prod).
Creating defaults for this stuff is definitely cool, but OTOH, it's something we solved at my company with a single bash script ;)
>:%s /Python/Rails/g
Vim user. Pffffft. ;) All hail the hypno-Emacs!
>it's [action.io] not really going to make much of a dent in my daily workflow
I would hope not. I would think most serious programmers have a pretty smooth/fine-tuned pipeline for "save file, run script, see changes in $SERVER(s)"
This is how Heroku got started and they quickly figured out that the editor in the browser was an issue. No one liked it.
I see it as they made an early exit and focused on the half of their system that seemed more promising income-wise. There is still a space for the all-in-one market, and frankly it's wide open. Environment + IDE + Deployment in one place definitely has a niche.
Earlier quoted context omitted.
This is their first iteration. For a simple Rails app, setting up Ubuntu an RDBMS and Redis is trivial, thats true. The point is that managing 5 Rails apps, one on Mysql, two on Postgres, two on CouchDB, one with Redis, one with Memcached... (and so on so forth) gets non-trivial soon if you don't grow beyond managing it all on your development machine.[1] Suddenly, all that trivial development stuff becomes a questio…
http://news.ycombinator.com/item?id=4135058 I just got done proselytizing the benefits of automation. I'm not arguing against myself. I'm concerned with why everything Rails people promote and celebrate seems to be along the lines of what originally popularized the framework. "Make a blog in 15 minutes!" --- you remember this one? Were you programming back then? It's exemplary of what I'm talking about. Why are they…
Actually: Yes. I was even programming Ruby before that, after it won in a flip-coin-contest against Python. :)
We might be on the same page here, but with different mindsets: http://news.ycombinator.com/item?id=4138088
I am a happy Puppet/Vagrant-user and would give away a substantial amount of money for a build/management/hosting-service for all that. Still, you need a hook, and the (in)famous 15-minute-blog was a tremendous hook, as is a "setup a clean dev env in 2 minutes". Immediate usage is the greatest hook you can get. I remember using frameworks where the setup took hours and was closely bound to the machine you were using unless you built your own tooling on top of the whole thing.
Also: there is a lot of stuff around in the Ruby world that can advances the state of the community as you say, even by salvaging Rails. I have not written a Rails App in around 2 years, yet I constantly use parts of it. Rails became a much better community citizen over the last few years.
If the 15-minute-hookiness is all you complain about: well, let them have it, if its fun :). I don't care about it a lot, but it is fun to get started.