RVM is not beginner friendly because it has dependencies, it compiles stuff on your machine and there are dozens of problems waiting to happen because of that.
If wanting an easier way to install Rails for beginners makes me an idiot, then I'm proud of it ;)
I wouldn't say that rvm is not beginner friendly, but I grant that it has other requirements and compilation can break down due to specific library issues on different systems. To my mind, a better solution, however, would be a compromise: (1) write a script to automate the installation of all the prerequisites (packages and specific library versions) in one step using APT, but then (2) recommend using rvm after that.
Note that this solution also compiles stuff on your machine, and in this case it uses system-wide installation locations. One advantage of rvm is that everything is done as a regular user and sandboxed in $HOME/.rvm. Easy to find and remove, if anything goes wrong or you change your mind later.
My thoughts exactly...I'm sure he'll be carrying extra weight but I still don't see how this is possible given a certain terminal velocity, like you said.
*Edit...wikipedia says current world record is 614 mph set by Joseph Kittinger. He used the head down method in high altitude, less dense air. That's still not supersonic though.
As mentioned in the article, Kittinger "only" jumped from 102,800 feet. Baumgartner will jump from 120,000. Also, Kittinger was in a "rocking chair" position, not head-down. (http://en.wikipedia.org/wiki/Joseph_Kittinger)
The author isn't factoring in HOW the company writes software...it's not just about what language a company uses. That's a small piece of the puzzle.
What if the company uses an agile approach to development? Maybe they pair program. That would be a little tough for someone to participate in while telecommuting...sure, technically it can be accomplished but that's not really how pair programming is done.
But this broad brush used to paint companies that simply say they don't telecommute as "not getting it" is a little lame.
I've tried pair programming in person, and it's almost impossible for me. I have vision problems, and I just really need my own monitor, configured how I want it, with me sitting squarely in front of it. But even beyond that issue, I'm enough of an introvert that I have a whole set up thoughts running through my head when I'm in a social situation, monitoring myself for the image I'm presenting, and the other person for how they're reacting. I can still work, but it definitely takes up some bandwidth, kind of like if I'm working while speaking a foreign language.
But the experience of remote paired work has been surprisingly good, for more than just the vision reason. I'm started recently on a completely-remote development job, with the team spread across multiple continents. No pair programming yet, but I just got off a call a few hours ago where I worked with another developer for more than an hour, troubleshooting build issues.
- Whoever is driving shares their screen, but we both still have access to our own computers, so there's no "hang on, lemme run back to my PC to double-check my notes there...".
- You're never forced to code with someone else's computer/keyboard/monitor/mouse/system setup/chair/etc.
- No awkwardly bumping knees or elbows, no worries about the other programmer having overpowering coffee breath or odd physical tics, being distractingly unattractive or attractive, etc..
So YMMV, but personally I'd rather do pair programming this way even if I was at the office.
Side note: I am simply unavailable for jobs that don't allow telecommuting; that's been the case for years now.
I disagree here (obviously). Hiding behind agile (in any flavor) as a reason to not allow telecommuting is just that, hiding. I've known plenty of teams who have successfully pair programmed trans-continent.
It can be done. Maybe it is more challenging, but I don't think "agile" automatically rules it out.
> It can be done. Maybe it is more challenging [...]
The only thing that's challenging about it is that you have to take some time to meet in person so people get a feeling for each others sense of humor, etc. We do this 3-4 times a year--rent a vacation home for a week and work in person for a while just to gel the team. Once you have a team that knows each other it works great.
Completely agree. A lot of MBA types (sorry for the overly broad generalization here) seem to have gotten the idea that every day should be a team building exercise and you can obviously only do those on site where you can take foam bats to each other and have the best ideas rise to the top.
Seriously though, that's what a lot of these arguments sound like to me.
The author isn't factoring in HOW the company writes software...it's not just about what language a company uses. That's a small piece of the puzzle.
Did we read different articles? Because I didn't see any arguments based on what language a company uses having anything to do with the ability to telecommute.
> What if the company uses an agile approach to development? Maybe they pair program.
I pair program every day over voip and tmux. It works great; there's absolutely nothing about being remote that precludes pairing as long as you have a stable 'net connection.
If your company is obligated to follow regulations like those set forth in something like PCI standards, then devs will certainly not have access to production.
Otherwise, good practice could be to have everything automated in the production env...whatever you're doing on production, make it as scripted/automated as possible. That way, you're forced to examine your processes ahead of time.
Kinda, but no. You can do simple things quickly with Rails. That means you get to the harder things faster. You very quickly discover that you have to learn Ruby if you want to do anything beyond scaffolding. I think that's what he means by being a "productive" Rails programmer.
But a person who has done Rails development for 6-9 months, ad has used Git, and knows how to deploy an application to Heroku... they will really be able to do a lot of cool things very quickly. Just watch what happens in October during the Rails Rumble.
You're asking this question on a site that is "startup focused" which means they aren't going to have a team of 20 developers churning out java byte code...they're going to be using more modern, dynamic languages like Python and Ruby because the popular full-stack frameworks that are behind Python and Ruby are better suited to get ideas off the ground as opposed to the monolithic JEE stack.
