Kickstarter: rails.app
kickstarter.com
kickstarter.com
What the hell has happened to "I want to build something, so I'll build it"? Now you have to [1]pay $100 for the privilege of reading the mailing list for an open source project? And some guy needs $25,000 just to start it?
Guys this is...not good. Can you imagine if apache's kickstarter never got funded? If the linux kernel's didn't? What if MySQL didn't properly manage their prize levels? Now it's "I want to build an alternative social network. Bootstrap me with $200,000" or whatever that was.
Kickstarter is really cool for a lot of things, I see it [and contribute to it] for large-scale art projects (burning man), but now every hacker I know has got a $25,000 wall in front of them called "kickstarter" and they don't want to start working until they scale it.
Stop this. This is really bad.
[1]: From the page: > [$100 gets you] access to the internal list for the project, where I'll be soliciting feedback about how to nail this. Great open source projects rarely come from the ideas of just one person, and your input will guarantee that Rails 4 is as great for beginners as it is for experienced developers.
What the hell is this? I have to buy a ticket to "help steer the project"? What happened to community? We're charging a cover at the door now?
It's like charging a cover at the door to help write the songs for the band you want to hear.
The alternative to stuff like this is Yehuda Katz writing code for some startup that you will never see. Here's Katz finding a way to make a business out of writing open source...
... and this is a bad thing? What's wrong with you?
(not that I disagree with this project or method, I think he should do the same as what Google Appengine does with its installer - it is seriously awesome)
I myself struggle with the concept of asking $25k to build what he wants to build. But at the end of the day what I think doesn't matter what I think or how many people disagree. If enough people agree with him and support him, then the project will happen. If you don't like the idea, just don't give your money. If you are worried this attitude becomes a trend then be active and release your stuff differently.
Are you of the opinion that people should only be paid to do things that they don't want to do?
Sure you can fork an open source project and request a pull, but if the core team disagrees with it then its all the same as the above.
Kickstarter is simply a marketing technique to raise the funds from an eventual corporate sponsor I bet.
Who says OSS has to be all about altruism and self-sacrifice?
Btw.. http://railsinstaller.org/ was funded by EngineYard... I'm not sure I see the difference?
Another point worth making is this: let the market decide. If the market will bear $25K (one-time payment) for a Rails.app, then so be it. Your opinion doesn't matter, frankly neither does mine.
I don't really see this affecting open source projects either. You've always been able to make money from free (as in beer) open source projects (directly or indirectly), even for projects that are not widely used.
I don't see why it's a bad thing that in modern times, skilled and famous artists continue to do work for hire. The fact that Yehuda is asking for crowd funding instead of funding from an individual is just in the details.
< I see it [and contribute to it] for large-scale art projects
...What in the world is the difference?
If anything it makes more sense to fund work that is actually useful than work that is simply beautiful or interesting.
What if Yehuda's company gave him 25% of his time to work on open source - would that be different? He'd get that same $25k (or whatever), and the software would get built (and open sourced). Only difference I can see is the source of the money, so are you against the idea of companies letting their devs work on open source?
There's this attitude in the open source world that somehow developers getting directly paid for open source is evil. This is -- excuse me -- fucking bullshit. I can't think of anything better than the idea of developers getting paid to write open source software. We need to grow the hell up and understand that paying developers to write open sourced software is a good thing -- open source devs get money, and the community gets software. Again, who loses?
I don't use Rails, and I probably never will, yet I kicked in some money to help see this through. I can think of about a million worse ways I could have spent that cash.
Again, we gotta grow up. Yehuda's contributions to Rails 3 were important. What's wrong with taking credit for that? I'm often critical of the Rails community for an excess of ego, but this is not one of those cases.
It seems pretty clear that the idea of an open source developer asking for money seems vaguely filthy to a bunch of people. I think this is unhealthy and poisonous. It condemns open source to be the provence of academics, the unemployed, those able to snatch free time away from their friends and familier, or those working at the largess of their corporate employers. That's a shitty limit on the scope of free software.
With kickstarter I get an assumption that if for some reason he won't raise enough money - he won't work on the project. That, in my opinion, is wrong. It shouldn't matter if one raises money or not, as long as you like what you're doing. Otherwise why bother in the first place?
It's not like we're investing $25k of angel funds to have him build something that he is then going to sell for $500k without sharing the profits. We're simply paying the living expenses of someone who wants to solve a perceived need for the development community.
Especially since this is coming from Yehuda Katz. I've seen several people using things like Gun.io to fund patches and small additions to open source libraries, but it always seems to come from people you never see in the community - outsourcers, or people who just aren't that into coding but still code. But once a leader in the community does this... It's up in the air what this will do long term.
Here's one possible outcome. It becomes "cool" to crowd fund open source projects, so a few of the up-and-coming coders with new open source projects start doing this too. In a year or two, a big chunk of the top coders are charging to do open source work. It's a badge of worthiness... Coderwall.com get's it's "$25k+ achievement" badge.
Then one of two things can happen. The unlikely thing is, it evens out, there's a happy balance - some people charge, some people don't. Much more likely is people either start charging ridiculous amounts, the quality of free open source projects drastically decreases, or people start keeping their projects to themselves. This eventually leads to rebellion, and the true ones left start ANOTHER Free Software Foundation that gets back to the roots.
This kind of stuff happens, out of seemingly innocent and well-intentioned moves.
Like everyone's said, companies like 37signals and all the companies we work at fund open source projects, so one way or another we're getting some sort of payment. It's totally cool to make money off your open source work like this, nobody really sees it even though we all know. It's this indirectness that keeps the community healthy. It creates a feeling of open-ness. A culture. Asking for money directly like this doesn't make things feel open anymore, and like everything it will spiral.
a) $25k is not a lot of money for very well-known programmers. There are fairly straightforward methods to get that much in a month (a salaried job), a week (contracting+), or a day (training event, $500 a head).
+ Stipulate that in addition to Rails he has at least one talent which makes money and this is not unreasonable at all.
b) There was no time at which OSS was not predominantly the work product of the global rich employed at corporations. This is observably true for Rails, since the list of contributors since DHH extracted it is both public and short. The Rails core team works on Rails like it is their job because...
c) ... Rails was designed to, and succeeds at, making companies great piles of money by increasing the efficiency at which they can churn out CRUD apps. Please note that is in no way a criticism. Apps running on Rails go from BCC (five figures a year) to Basecamp (eight figures a year and will probably hit nine eventually unless they already did).
d) OSS developers making money by it - I.e. The traditional accepted way to write it - does not make you personally worse off, because it increases software available to you. You may perceive that people will listen to you less because monied interests will drown out your voice. This is irrational: since the $100 you think is a lot of money only buys maybe 30 minutes of programmer time anyhow, the opinions that mattered in OSS were already those of companies which coul actually pay salaries, and someone freer with their last $100 than you are will only have epsilon more impact on "the community" than you when compared to IBM (a consulting company which staffed most Linux development) or Google (an advertising company which directly or indirectly pays the salaries of the majority of programmers working on either of the two big OSS browsers.) apache's Kickstarter was IBM realizing that they'd happily pay a billion dollars to have IIS not become the dominant server platform so they proceeded to do so.
What if Linus said, "I have this great idea for a version control system, but I need the community to raise $100k to make it happen"? Of course he would never do that. The reason for making git was to give the kernel project what it needed for a version control system. Linus' time is at least an order of magnitude more valuable than Yahuda Katz' time. Just as git arguably makes the kernel project more successful, rails.app ought to make Rails more popular. Wide deployment of Linux in turn makes Linux developers' skills more valuable, just as wider deployment of Rails enriches Ruby developers.
c) ... Rails was designed to, and succeeds at, making companies great piles of money
d) OSS developers making money by it
That can be said for just about any popular open source project used in the business world.
Why? Maybe he was paid by the linux foundation during that time? Other sources of income? The gratuit "of course" is not clear to me.
Maybe I'm misunderstanding what you try to say, but: " rails.app ought to make Rails more popular [...] wider deployment of Rails enriches Ruby developers". Are you saying that Yehuda should not make money from his efforts, but the Ruby developers in turn can use the results naturally for their gain?
And Rails is sponsored by 37Signals. You'd be hard pressed to find very many large open source projects without commercial backing.
Are you saying that Yehuda should not make money from his efforts, but the Ruby developers in turn can use the results naturally for their gain?
That is generally how things work. Companies specializing in open source technologies have a business interest in their specialty software(s) becoming more popular. A core Rails developer will command the highest speaking and consulting fees.
I think the reservation many people have about all of this is that it feels backwards. Asking for sponsors is one thing, but making the open source project pay-to-play flies in the face of the spirit of FLOSS.
Ah, maybe I just do not agree with that spirit. The SBCL compiler fared well with Nikodemus Siivola's crowdfunding: http://random-state.net/log/3523852985.html
At the same time I do not get how this is a problem for people to accept wrt software, while it is the common suggestion to artists in copyright questions on HN: go crowdfunding!
In any event, it is better than Katz should work directly for people who are going to use his software than that he work for some giant company that incidentally finds it valuable to task him with something useful.
As far as I can remember open source always has been a sponsored or subsidized undertaking as far as it concerns meaningful or central projects.
Without it, the linux kernel would be only teaching material on Finnish universities, MySQL would not exist, Erlang would be a Danish mathematician and a waiting cue formula. The basis for the ASF is the web server which was developed at the NCSA. So you're on the right track with the "Can you imagine..." question.
Whats wrong with someone who want to make a meaningful addition to OS and asks money to be able to give full attention to the project? Isn't that more realistic than to hope for loosely coordinated efforts of spare time developers?
[note: I use this term not to criticize the persons in question but to point at the focus of the contribution. Also scratching-own-itch projects can easily err on the wrong side of the pareto ratio]
If open source work is not paid for directly, it is paid for by corporations. Even when people do work in their 'spare time', it is being subsidized by the corporate job that puts food on their table.
Arguing against directly funded open-source is tantamount to arguing that developers should only be able to make a living working for a corporation.
There's nothing wrong with choosing to work for corporations, but what's wrong with having alternative economic mechanisms as well?
> [$100 gets you] access to the internal list for the project, where I'll be soliciting feedback about how to nail this. Great open source projects rarely come from the ideas of just one person, and your input will guarantee that Rails 4 is as great for beginners as it is for experienced developers.
That is a non-starter.
This is also not a $25,000 project.
I admire and am thankful for Yahuda's contributions and I'd have no problem funding a "Yahuda should get paid" Kickstarter but this particular project is lame.
Installing Rails on a Mac is largely trivial. It's literally 5 shell-commands, depending on the current level of breakage of rubygems (but that's a different story). Write a tutorial in your blog if you really feel this is hard for newbies.
The hard part is installing the exact same Rails on multiple Macs and deploying the exact same Rails to production servers that are not Macs. And when I say "Rails" then I mean the entire dependency chain which reaches far beyond Rails and Mysql. The hard part is having controlled service startup/shutdown scripts that work locally and across any number of servers in your production deployment. The hard part is configuration management and safely toggling dev/production/staging modes across all involved services. There's lots of hard parts; bootstrapping a vanilla rails is not one of them.
In fact: Naive bootstrapping can be harmful, just like the still virulent code-generator brain-rot in rails itself.
I make a living managing these things and have evolved multiple approaches ranging from chef/puppet, over canonical git-repositories that work cross-platform, to VMs. There is no one-size-fits-all once your stack outgrows Rails+MySQL, and it always outgrows that.
If you wanted to solve the real problems surrounding all this then a single-platform bootstrapper is nowhere near cutting anything.
For that you'd have to start writing a better chef/puppet, which are indeed more than ripe to be superseded. But this is far beyond the scope of a kickstarter project and I hope Yehuda will rather keep his focus on Ember...
Also, it's way more than 5 shell commands and even if it were only 5 it would be worthwhile to make it easier.
Seriously?
1. Install XCode and homebrew
2. sudo brew install {postgresql,rbenv,ruby-build}
3. Close terminal. Open terminal.
4. mkdir proj && cd proj && rbenv install 1.9.2-p290 && rbenv local 1.9.2-p290
5. gem install rails && rbenv rehash
6. rails new foo
Honestly, we can argue if this was 5 steps or 8. We can also argue if 'rbenv rehash' should be necessary (I'm not even sure it really is, wrote that down from top of my head).
But if someone fails on these instructions that fit on a Post-It™ then they should overthink their ambitions towards a programming career.
And if they run into bugs during that procedure then these bugs must be fixed. Because this is (and should be) the canonical way to install a vanilla Rails on OSX.
Your list is far from canonical even at this very moment and hasn't even been common for very long. To figure out your list, I have to:
1) know that homebrew is the "right" way to install software that rails depends on, rather than MacPorts or Fink, or the Mac app store, or download.com, and oh yeah, there is this thing called sudo, and I should install homebrew recipes using it, or should I??,
2) know that rbenv and ruby-build are things that exist and that they are competitors to RVM but are either more or less in vogue depending on who I talk to,
3) understand that rbenv doesn't just work in the current shell without closing and re-opening it,
4) know that the "right" version of ruby to use is 1.9.2-p290 (I have to know the patch-number?!) and that I need to install it and set it as my local version (wait, what does that mean, why do I need a local version?),
before I can get around to actually installing rails and using it.
Now, I could just blindly follow someone's list from a blog post (randomly chosen presumably, because the theory here is that I don't know enough about these things to make an informed decision). Maybe I would even get lucky and find a list that works properly with the version of rails that the official documentation is talking about, but it would still be a much better experience by far to go to the official rails site and be told: "hey, download this all-inclusive, up-to-date, guaranteed to work disk image straight from us!".
If you are someone who doesn't know what it means you should learn. Isn't that what a programmer needs to do?
No. You have to know none of that. You just have to copy/paste the steps from the rails-homepage (where they should be prominently listed, the lack thereof is the real bug).
"hey, download this all-inclusive, up-to-date, guaranteed to work disk image straight from us!"
Wait, how is that different from above?
Yes, you may be done 2 minutes faster. But you just deprived yourself of at least getting a glimpse on which parts are involved, even if you don't understand them yet. That means you're now even more hopeless when stuff breaks later (and stuff always breaks later).
And as a fun fact: Any sane bootstrapper would use the exact same script behind the scenes anyway. There simply is no other way unless you plan to re-invent homebrew and rbenv along the way.
I'm really troubled to understand who we're trying to care for here. It sounds like you want to make this Really Easy for absolute beginners who can barely setup a printer.
That is a noble goal (for a printer driver), but if you want to teach someone programming then there's a point where you have to stop dumbing it down artificially. And that point is as early as possible.
The worst you can do to a newbie is to put him into an opaque sandbox with different behaviors and errors from what the "big guys" are using.
2. sudo brew install {postgresql,rbenv,ruby-build}
3. Close terminal. Open terminal.
4. mkdir proj && cd proj && rbenv install 1.9.2-p290 && rbenv local 1.9.2-p290
5. gem install rails && rbenv rehash
6. rails new foo
-------------------
"hey, download this all-inclusive, up-to-date, guaranteed to work disk image straight from us!"
Wait, how is that different from above?
-------------------
Really? You really have to ask how those two processes are different?
"stop dumbing it down artificially"
If (sometimes competing) complexities weren't continually added, there wouldn't be a need to 'dumb it down'.
"(and stuff always breaks later)"
Wow. Most other web framework communities don't have that much problems with 'stuff always breaking later'. Maybe Rails has reached a tipping point?
"There simply is no other way unless you plan to re-invent homebrew and rbenv along the way."
Or until someone else does 'reinvent' one of those, and all the cool kids start using it, leaving everyone who learned the 'legacy' way out in the cold without an upgrade path beyond "start over".
with different behaviors and errors from what the "big guys" are using
I think part of the purpose of the kickstarter project is having one of the 'big guys' behind it. Supposedly that would mean at least one (or more) of the 'big guys' would indeed be using the same process as the 'newbs', reducing this chasm.
Sounds like you're threatened some by this - it was hard for you, therefore it should always be hard for everyone for now and forever.
Yes, I'm threatened by this. But not in the way you think, because as shown above, it's not really hard. It's 5 lines. What's wrong with kids these days?
I'm threatened because I'm the guy who comes in to clean up after "junior programmers" who couldn't even be bothered to learn 5 lines to install their dev-environment and who consequently also don't have the slightest clue about basic realities such as "diskspace is finite" or "No, /Users/Bob/rails/tmp is not a valid path in production".
At least give the kids a chance to learn. Don't lure them with shortcuts that result in unsustainable habits that cause great frustration in the long run. Unlearning is harder than learning.
Rails with its false sense of simplicity is breeding plenty diletantes already as it is. We need less of that, not more.
Would you mind scrolling up to my original comment where I posted the exact 5 lines?
My designers need to work with my Rails apps
Then you should have noticed that installing rails is the least of your worries. Database seeds, missing dependencies, test-users, broken fixtures, broken mocks, missing external APIs, version control conflicts, gem screw-ups, failing migrations, rails upgrades, differences to the production setup. Those are the daily timesinks over here in the real world.
The initial rails installation doesn't even register in the grand scheme of things.
1) The rails.app project wants to solve a problem that doesn't exist. There are a lot of comments here from other people who think getting started with rails is confusing, and who point out that your much-touted five steps are not complete, canonical, or easy, so I won't further beat that dead horse.
2) There are many harder problems you'll come across when doing rails professionally. This is incredibly true, nobody disagrees, but it's irrelevant to the rails.app project.
Reading your short list triggered a flashback. I struggled with everything you listed, probably more.
When I made a run at getting an existing RoR project running on my Mac (~1 year ago), there was no shortage of howtos and advice. The problem was resolving all the contradictory information.
As moe points out, the project home page should have the single source of validated truth on how to get RoR running on a Mac. Minimally.
That such a source of truth didn't exist led me to conclude that Rails was run by amateurs and to not be taken seriously.
Install Xcode; 1) Install in App Store 2) Still not actually installed, start it, that finished the installation 3) You still don't have what you need, find where they've moved "install command line tools" to and install that 4)The compiler you have isn't the right one as Lion no longer has GCC as its default compiler and you want to use RVM 5) ......
Once you've done it a few times it's not that hard and you get used to knowing where to look for problems but the first few times it can easily be half a day lost just trying to get the environment working.
The above steps are reasonably robust and implicitly teach you things about your programming environment that you must learn (or at least have seen) as early as possible.
We should decidedly not dumb that down. There must be one canonical installation procedure for everyone and it must be as easy as above. There must not be "an easy way" and "a hard way". The above is as easy as you can make it without hiding crucial information from the user.
Rails has plenty of harmful padding already, we need less of that, not more.
The complexities of setting up a system so you can develop rails on it exist to solve problems that experts have discovered through years of working with the system, but which people coming to it fresh don't, and shouldn't need to, know that they have yet.
But, they break.
Would you like to start a pool on how long it will be until this recipe breaks, or becomes hopelessly obsolete because some portion of it is now out of date?
Hint one: To get an idea, one could try the problem in reverse: How far back in time can you go before you reach a time when this script would not have worked yet? (Hint one, sub-hint A: The first commit to Homebrew's Git repo was in May of 2009.)
Hint two: Homebrew formulae aren't guaranteed to build at all times. They sometimes have bugs, especially when any of their dependencies (including the version of OS X itself) has recently changed. Those bugs tend to manifest as scary messages from (e.g.) the linker.
Hint three: Better get that version number out of the recipe before placing the bet. 1.9.2-p290 could become hopelessly obsolete at literally any minute; we're always just one zero-day away. It would be more reliable to pull that number from some canonical source like… um, any ideas? What is the answer to the question "how can I reliably determine, at any time over the next five years, the latest, least-buggy version of Ruby that is compatible with the version of Rails that I've got installed on my machine?" I don't know what your answer might be, but mine would be "pay someone like Yehuda Katz or the Rails core team to continuously recompute the answer, and to maintain the website that hosts the answer".
But, they break.
The rails-answer would be "so is life". My answer is: Then fix it, damnit. Not you personally, but the maintainers. We must stop accepting constant wreckage as an inherent property of the rails-ecosystem. It is not inherent. Other systems such as debian APT work pretty flawlessly under significantly more complex conditions (thousands of packages on multiple architectures, for starters).
Isn't rails the one with the 17 different testing frameworks and TDD kool-aid? How about adding structured tests for the installation procedure, too?
Keeping a ruby/rails installation procedure functional is not rocket science. And in defense of the actors: I do consider the current state-of-the-art (rbenv, bundler) to be fairly close to something that one could call reasonable.
Hint one, two, three
The exact same applies to any installer that you may come up with. It either has to perform the famous 5-steps behind the scenes, or it has to re-invent all the tooling that is only now barely stabilizing (square 1 again, really?).
answer to the question "how can I reliably determine, at any time over the next five years, the latest, least-buggy version of Ruby that is compatible with the version of Rails that I've got installed on my machine?"
That is the wrong question. The correct question is "how do I install a self-contained rails runtime environment on my current machine" (which includes ruby and all core-dependencies).
The current answer is the above script. If the preferred tools change for a platform then update the procedure accordingly. Keep the current procedure in plain view in the documentation (Section 1: Installation).
It's not as hard as you make it out to be, really.
IDK. The barriers to entry for RoR on the Mac are pretty high.
I was keenly interested in an open source open government project (Sunlight Foundation). I tried to get it running on my Mac, on my personal time. I had direct expert help (friends who dev using Ruby, Rails, etc.). I understand the tool stack was churning, something about mismatched versions, runtimes, whatever.
I gave up after three weeks.
I don't care care how "awesome" Rails is. If it doesn't work out of the box, like all the LAMPs distros, devs will find something that does.
I hate Spring, Maven, ORM and all the other webby enterprisey Java crap with the passion of a billion burning suns. But the RoR nonsense was a whole 'nother level of insanity.
I'd rather take a bat to the face, or use PHP, than try RoR again.
(I should add that my bad experience was ~1 year ago. Maybe things have improved. Alas, I've moved on to greener pastures.)
Would be a win-win for the user and hosting provider.
To me the elephant in the room is simply would people do this for free like most open source? The Rails community is large and dedicated. If the core team started this as an official Rails project would the result be at least the same, possibly taking a little longer?
Does anyone here have specific problems? From my experience, it really has been a matter of "gem update --system; gem install rails".
But then again, all this seems easy to me, can't speak for people entirely new to development.
That is, except for Lion and XCode 4.2/4.3, which caused me about three lost days. 'rvm get head' and 'rvm install 1.9.3-head' fixed that, though.
Perhaps part of the confusion is that there are a number of old blog posts that you'll dig up via google, and if you make the mistake of following an older one, you'll run into problems. I made this mistake trying to get rails set up on Ubuntu before I knew about rvm, and it was pretty painful.
That'll throw a permissions error on a default OS X install-- and your Rails newbie will definitely not know that that means "you should really use rvm".
With that said-- a shell script that installs homebrew, git, rvm, the latest ruby, the latest rails, and a handful of useful gems, then drops you right into a shell of you brand spankin' new Rails (and Heroku!) project seems... pretty straightforward. Dealing with the common edge error cases and making it look nice and user friendly might take a couple hours. I'm curious to see where the time gets spent on this project.
In fact, it was so messed up, it motivated me to go out and buy a new Macbook (I needed a new computer anyway, but it provided a major impetus to go out and get one).
And that's just me. Even worse is the fact that I work on a lot of Rails projects with a designer who lives in Montreal, which is a good six hour drive from where I live. I've helped him get Rails set up on his computer, but it has not been easy - far from it. As a non-techie his computer is prone to all sorts of weird shit, he hates the CLI, he needs to be walked through, line-by-line, any situation involving some weird gem dependency nonsense - it's a horrible waste of my time. Imagine trying to debug someone's effed-up gem environment via a laggy screen-sharing connection while you're on deadline - it's awful!
To sum it up: this is a project worth supporting and I'm going to support it as soon as I click the 'reply' button on this comment form.
Generally speaking, you now need a compiler. If not to install something other than a quite old system ruby, then to install common gems like nokogiri.
XCode seems to change significantly every release. Not long ago, you had to download it, or get it from your system CDs. Then you had to buy it from the app-store. Then you got it for free from the app-store. Then you got the installer for free from the app-store, and had to run the installer. And today I think you get the installer, which you run, and then you go through a series of menus to get to "install command line tools" (like gcc).
Once gcc is there, then you need a ruby. There's RVM and rbenv. Those need to be found, installed (by running a curl command piped through bash), and then a ruby needs to be installed. I use RVM, which is easy enough for me, and it does install bundler by default (which is good).
Once you have a modern ruby, you probably want a database other than sqlite. For that, you usually need homebrew. Again, install homebrew, and then have homebrew install postgresql/mysql.
At this point you are almost ready to install the rails gem.
Oddly, a lot of the newer complexity has less to do with Rails, and has more to do with the Ruby ecosystem getting both older and more complex at the same time.
Every time I help a new developer get started with the rails environment, I too am amazed at how much has changed since I setup my own laptop one year ago.
It is a different story for someone completely new. When I have time to sit down and help my brother and friends interested in getting started building websites, I recommend Rails (or Sinatra these days). The entire first session is usually devoted to helping configure their environment, and explaining the various tools they may need to know about when they are on their own. This is before even getting to the bit about learning HTML, CSS, Javascript, and Ruby. All of this is usually a complete waste of time because they have most likely lost me after typing in "cd" or "mkdir" for the first time. Yehuda's proposal nicely solves the configuration step for a beginner (the only class of developer for whom I think it is a seriously debilitating problem), but that is really the least of worries for someone new to web development in this day and age.
Step 1: Download the "Command line tools for Xcode" here
https://developer.apple.com/downloads/index.action
Step 2: Install homebrew with this command
/usr/bin/ruby -e "$(/usr/bin/curl -fksSL https://raw.github.com/mxcl/homebrew/master/Library/Contribu...
Step 3: gem install rails
Lowering the Rails entry bar is a good thing, making things simpler is a sign of maturity for a product. To address your bit about concurrency and websockets in Rails, people are working on the issue, see the talks given by Ilya Grigorik for example, concurrency will be coming to Rails at some point. And so will the integration with client-side framworks like Backbone or Ember. It just takes time.
A year or two back if you ask, "how do I built my bleeding edge web application" the answer normally was 'use Rails'. My point is the Rails has been sorely lagging behind other invitations.
This just feels like a waste otherwise.
brew install rbenv
brew install ruby-build
rbenv install 1.9.3-p125
rbenv global 1.9.3-p125
gem update --system
gem install rails
gem install bundler # optional, recommended
brew update
brew upgrade
Gimme one .app and a directory structure I can just throw into /Applications (and later throw away if my experiments come to naught), gimme a nice control panel to stop and start Rails. Let me get it up and running on my system without hassling with the Terminal. Because I really really avoid the Terminal as much as possible.
pledges ten bucks
I don't mean to sound condescending, but if you're interested in using Rails (or any similar web platform), you need to be comfortable with the command line. It's not hard to learn, and there's even a good Peepcode video called "Meet the Command Line" that serves as a gentle introduction.
If you're really adamant about staying away from the terminal, you should look elsewhere.
PLEDGE $100 OR MORE
The previous rewards, plus access to the internal list for the project,
where I'll be soliciting feedback about how to nail this.
Exactly the opposite of the self-contained mini-framework (if not micro-) it started as.
And again, the problem with Rails 3 today isn't the install. Instead it's that:
1. There is a shit-ton of old Ruby/Rails documentation out there that confuses the living shit out of people, and this is a duck-typed language, which is fine, but it means that people are even less likely to know what the fuck is going on when the code they are trying to use from someone's blog doesn't work.
2. Most of those using Ruby on Rails are not new as they once were, so since the majority know a little more about what the fuck they are doing, they are less likely to write things for those that don't know what the fuck they are doing.
But, writing an .app won't solve that. Instead, spend that time trying to take bundler, Gemfiles, rvm, the more complex Rails directory structure, asset pipeline, etc. and simplify the whole damn thing to create Rails 4, and chalk 3 up to an oops. A lot of the changes in Rails 3 were warranted, but the additional complexity will drive people away, and that is against the soul and original intent of Rails.
Want something that people would be really interested in? A framework that makes both development and scaling EASY. Development was easy with Rails years ago, but scaling was nearly impossible because that wasn't the intent. Now people scale Rails, but it is still hard, and development has gotten much harder. That's bad, because there are already ways to learn to develop quickly, and other solutions for scaling well. Being halfass at both is a sure way to fail miserably over the long-term, and Ruby and Rails is awesome; it shouldn't fail like this.
You never know what kind of things people are doing on their machines, don't deal with that, use vagrant.
P.S. I'm sure a rails script exists for vagrant so he could just improve that with whatever he's going to do.
git push to heroku
and that's been heralded as the best thing ever, so people don't have to futz with all the server setup/management.
But with regards to people looking for similar ease of use on the desktop for local development, they're all blithering idiots who shouldn't be allowed to touch a computer because they don't understand the intricacies of rvm vs rbenv.
There seems a bit of a disconnect here. Most people are proud of all the hard-won knowledge (sometimes through months or years of experience), and feel that everyone else should have to go through similar hell to attain some magic level of guru-ness. But... don't take away my heroku account!
"The use of the logo is restricted as it always is when talking about a trademark. When the logo is used in a commercial setting, such as part of the promotion of a book, it legally requires that the trademark holder has been involved and stands behind the quality of the book. If that's not the case, you're on the way to lose your trademark. So I only grant promotional use for products I'm directly involved with. Such as books that I've been part of the development process for or conferences where I have a say in the execution."
http://www.rubyinside.com/david-heinemeier-hansson-says-no-t...
Open source is amazing! But people have to eat. If people with great ideas and the ability to execute have to pull a contracting gig to pay their rent which takes away from important side-projects, I think that's a shame.
I'd like to see more things like this. If it means more high quality open source that helps people and saves them time, then great! I have donated $25 to this project. The direct impact it will have on me when it's complete is:
* I will be able to get designers/front-end developers up and running on a reliable rails setup without much hassle to myself. * It's very likely they'll be able to set it up themselves. * Programmers from other environments might be playing with Rails in 10 minutes on a weekend, enough to whet an appetite that will potentially give us a broader pool of developers to hire from.
This is great! Crowdsourcing is great! I hope he raises the cash required to focus on this and I can't wait for the result.
The tutorial made it extremely easy. I was up in running in an hour or two, and it only took that long because I am taking it rather obsessively slow, following all reference links, and brand new to Ruby.
I, for one, do not see the need for this.
Similar to the Svbtle drama, this is yet another post lingering on the front page that has no business here.
I thought this was hacker news. Seems more like "check out my super cool project that you can't use unless you're awesome or you pay me" news. :(
http://www.kickstarter.com/projects/sferik/hubcap-a-github-c...
Why shouldn't this turn out the same way? The person who started the HubCap project is a prolific open source contributor. I'm glad he didn't drop everything else to work on HubCap, as he made many great contributions to API client development last year.
I hope Yehuda changes his mind about this sooner rather than later. I really like seeing what Yehuda comes up with and this doesn't interest me at all. I use the command line, and I recommend homebrew to anyone on OS X who's serious about learning ruby, and so far it hasn't failed me. I've seen the Google App Engine launcher and I think it's pretty good but I still prefer the command-line tools.
But if people desire to become programmers is it really that bad to have them come in contact with a little bit of configuration and head scratching.
There's also a GUI for RVM called Jewelry Box which makes handling gem sets and ruby versions easy: http://unfiniti.com/software/mac/jewelrybox
I think the money would be better spent on creating a comprehensive beginners guide since the 4th edition of Agile Web Development with Rails is lacking.
I would be much more interested in that.
Making a Rails.app for Mac is different though, because everything would be isolated in your .app, while a .deb would install the files to the system and track them in the package management database, so trying to modify them outside of apt-get/dpkg just b0rks everything.
Yehuda's approach reminds me of the early days of webdevelopment where you could install a WAMP stack with one click on your windows systems. I never liked those one-click-installers—you don't know what happens to your system and deinstalling was a nightmare with still running db servers somewhere for years.
You can't wipe away Rails complicated entry with such an one click-installer. After you installed Rails with one click things aren't getting easier your still have to figure out next steps and which frameworks to choose (i.e. ERB or HAML, SCSS or LESS, MySQL or Postgre, etc.). Or something breaks within rvm: with an yehuda's approach you are completely clueless because you don't know anything about rvm, gemsets because the installer did all the work for you.
Sometimes there is even too much magic in Rails. I am still wondering if ActiveRecord is too much abstraction and if there are better more direct ORMs like DataMapper, I am used to ActiveRecord but still I can not fluently create data models, there's always something I forget, using the plural or singular, saving the updated migration, rolling back the migration, etc. Otherwise it's far beyond any ORM from other Frameworks I have ever seen in terms of speed. And its usage in Ruby is very consistent. Also Rails shell commands are very consistent, once you understand the rails syntax (like rails generate or destroy something you can quickly build anything in minutes), I tried several times to find something similar with python/django but there the entries seemed to me even more complicated, don't follow any system and felt restricted, i.e. Django's automatic Backend (no offense, i know not enough about django and python to say anything serious but that was just my first impression).
Another last great example of Rails: once you managed to install Rails, just put haml, less, less-bootstrap-rails and simple_form in your gemfile and run bundle. with this setup you can build web apps in minutes with perfect design and they are fully customizable. some years ago you needed hours or days to get to similar results. It takes time to get there but once you are there you have the power.
this pace and variety in the rails ecosystem comes from so many talented people who contribute. trying to set one standard for how things are done would slow down this pace.
finally, I think that Yehuda doesn't want to raise money, he just wants to get attention and the approval that he had the right idea.
The second is personal, so please take it with a grain of salt. I pointed out that Yehuda's Bundler gem has an automated condescension feature; if you try to use it without saying 'source :rubygems,' it heckles you and mockingly asks you 'did you mean to say source :rubygems? if so please go back and type it in.' this is pretty anti-Rails in my opinion, insofar as Rails is about sane defaults and programmer happiness. But I raised this issue, and the only response I got was 'fuck you.'
If I've had that kind of interaction with you, and you want my money, you better have an absolutely rock-solid plan for world peace. This is something other than an absolutely rock-solid plan for world peace, I've had that kind of interaction, he's not getting my money.
Not proud of taking the conversation there, but I do at least want to be honest. I gave Ze Frank $600 on his Kickstarter, but this project isn't getting a dime from me. I had in fact been thinking of contributing some amount in that range but after a brief attempt at talking to Yehuda spent it instead on a music class I wanted to take. :-)
Anyway, another objection: I've never heard of him doing anything with Objective-C and have no idea if he's ever even used the language before.
(If you follow @jm on Twitter you know where I'm stealing a lot of these ideas from.)
Another objection goes back to the first one, the XKCD 'standards' thing, and comes from a @jm tweet as well as from an undervalued comment buried way, way, WAY the fuck down at the very bottom of this page: we already have several projects of this nature. For instance:
https://github.com/thoughtbot/laptop
http://bitnami.org/stack/rubystack
https://github.com/joshfng/railsready
So yeah. There are too many competing standards. What to do? I know! Create a new standard!
I think a much better and simpler solution is to tell people to read http://railstutorial.com/
But the best objection comes from @patmaddox on Twitter:
http://mobile.twitter.com/patmaddox/status/18513425005033472...
Step 1: make Rails hard
Step 2: ask for $25K to make Rails easy
Step 3: PROFIT
> (By the way, for those of you who follow the arcane but politically-charged world of blog syndication feed formats, you can see the same thing happening over there. RSS became fragmented with several different versions, inaccurate specs and lots of political fighting, and the attempt to clean everything up by creating yet another format called Atom has resulted in several different versions of RSS plus one version of Atom, inaccurate specs and lots of political fighting. When you try to unify two opposing forces by creating a third alternative, you just end up with three opposing forces. You haven't unified anything and you haven't really fixed anything.)
I don't think that installing rails got any harder relative to where it was in the 1.0 days. vanilla rails locked to one version with globally-installed gems is just as easy as it ever was, so I don't know if its quite fair to say step one is "make rails hard"; the current state of the ruby world is a lot more enterprise-ready and that comes at a complexity cost and automating that away is inconvenient.
edit: The RubyRouges podcast has a great episode with the maintainer of Bundler where a lot of the difficulties with Bundler are discussed in depth. That's the "talk" I was referring too.
I say at best because obviously in my case I did not see a whole lot of debate. the GitHub issue for it is likewise extremely not-discussion-y. wherever the discussion for this incredibly controversial idea is taking place, I haven't seen it.
the idea in Ruby, and especially in Rails, is that if you know what the default is which most people are going to expect or try, you should support it. to say "we know you thought source :rubygems was the default, but it's not, you have to type it explicitly" is a little un-Ruby and a whole bunch un-Rails.
Ah, I think I know what you're talking about. I wasn't using Python back then, and I know exit() was added after that (the only way to leave the console before that was to Ctrl-D), but when you type "exit" in the console, Python responds:
Use exit() or Ctrl-D (i.e. EOF) to exit
git config –-global alias.statsu status
I have mine aliased to 'st'.
git config --global alias.statsu statusSome other good ones:
I can tell you one thing: there are many, many people who have benefited from the fact that Bundler fixes a boatload of issues for developers and in general makes my life, and their lives, better, even if we have to type "bundle exec", which I have conveniently aliased to "be" (try it).
I'm also willing to bet that a lot of people would benefit from this project if Yehuda takes it on. I don't know if he knows Objective-C either, and I don't care. Why? Because this is a guy who knows how to produce useful software. No, it doesn't let you produce music in your browser, or program beats in Ruby. But it is useful.
Archaeopteryx was the first time I came across you in the Ruby world and I thought it was really cool when I tried it out. Then again, I didn't find it particularly useful. I find Bundler useful every day, and I'm willing to bet lots of other people would too.
I realize I'm making this personal, and I'm sure that opens up a great opportunity for you to disparage my own accomplishments, or perhaps engage in some deliberate heckling and mockery, as opposed to the mockery you mistakenly perceive in a program's error message. I'll save you some time: I suck at programming compared to Yehuda, and I'm probably not as good as you are at it either. But one thing I'm far better at than you is appreciating people for their contributions instead of behaving like a jerk. So give it a rest, it's tiresome and juvenile.
I'm not saying Bundler should be destroyed and it's a thing of evil. I said it was super useful but had very aggravating flaws which indicate that Rails went off the rails. If you guys can back off from all the making things personal about me for five minutes you might actually notice that "Rails went off the rails and is no longer entirely true to its original principles" is not such a vicious thing to say.
But is "fuck you giles" a response which is going to prevent you from getting my money? Yes, of course it is.
Well, that's reasonable enough. I'll be honest, when I read that, I assumed it was hyperbole. If it was a literal "fuck you", well yeah, that would bother me too.
In the php world, MAMP on osx is one of the reasons so many newbie jump into php. a simple app, abstracting away apache, php and mysql. you simply create a new vhost and click start.
This is the target audience - not the people who know how to clone a git repo and run a script in terminal.
He is trying to make it easy for new users and programmers. I know high school teachers that would use this to teach ruby web programming without all the error prone manual configuration.
https://github.com/carlhuda/bundler/commit/abdc6374bd18488d0...
you had an issue open for this on GitHub but it was closed with very little explanation. mind if I reopen it?
i‧ro‧ny - Incongruity between what might be expected and what actually occurs.
co‧in‧ci‧dence - A sequence of events that, although accidental, seems to have been planned or arranged.