Burning out on Capistrano (Jamis Buck)(groups.google.com)
groups.google.com
Burning out on Capistrano (Jamis Buck)
http://groups.google.com/group/capistrano/msg/f5213577eaeadc47
37 comments
"I recently had an e-mail from a Windows developer in the Ruby community who pointed out how opaque many Ruby projects are regarding Windows."
I guess my response to that would be that Microsoft is quite opaque regarding Ruby. By being such a closed system, Windows doesn't do anything to help developers improve Ruby library compatibility.
Compare this to Apple. Apple builds Ruby into its operating system, contributes patches upstream, and is even supporting the development of MacRuby, which more tightly integrates Ruby into the Mac OS X operating system.
So the opaqueness goes both ways in my opinion.
Due to this, I am very impressed that Ruby even has the level of support in Windows that it currently enjoys. I would say that Windows hackers should keep up the good work and submit substantive patches as often as possible.
I guess my response to that would be that Microsoft is quite opaque regarding Ruby. By being such a closed system, Windows doesn't do anything to help developers improve Ruby library compatibility.
Compare this to Apple. Apple builds Ruby into its operating system, contributes patches upstream, and is even supporting the development of MacRuby, which more tightly integrates Ruby into the Mac OS X operating system.
So the opaqueness goes both ways in my opinion.
Due to this, I am very impressed that Ruby even has the level of support in Windows that it currently enjoys. I would say that Windows hackers should keep up the good work and submit substantive patches as often as possible.
I switched from Vista to OS X this year. I made the stupid mistake of trying to develop Rails on a Windows machine. And it was not worth the trouble at all. If you're going to devote your life and livelihood to building software on Rails, do NOT do it on Windows.
I switched to OS X and I'm happier with my computer than I ever have been in my life.
And Rails works awesome.
I switched to OS X and I'm happier with my computer than I ever have been in my life.
And Rails works awesome.
I write my Ruby on Windows Vista and deploy on Ubuntu. And I've run into the usual set of headaches with doing this. Sometimes this results in me having to make fairly simple changes to, e.g., older versions of Capistrano to get them to work on my machine -- not too terrible because, after all, it is OSS Ruby code.
(I'm still running Cap 1.4.2 because it only took one line to make compatible. If I upgraded I would have to fix everything again.)
What flavor are the bugs? Usually, it ends up being a weak link in filesystem paths, SVN integration, or SSH integration. What causes these issues? Much respect for the folks who code them, I understand you do not owe anybody anything, but any honest assessment points to platform chauvanism.
"I do not use Windows, nobody I know uses Windows, true Ruby hackers are too cool to use Windows, begone ye Microsoft-infested slimeball"
The community (which I generally like and, let me note, actively contribute to) positively drips with this sentiment. DHH mentioned that 37signals wouldn't hire a Windows programmer (though he later backed down, somewhat), and the reasons were essentially tribal more than anything else.
And a big -1 to everyone who says that the Windows API is getting in the way of compatibility. Really folks? The Windows API being opaque made you hard code the path separator? The Windows API being opaque made parsing the results of a call to ls the more obvious choice than using the built-into-the-standard-library cross-platform way to get the contents of a directory? (To name just two implementation choices I've seen in Ruby libraries.)
(I'm still running Cap 1.4.2 because it only took one line to make compatible. If I upgraded I would have to fix everything again.)
What flavor are the bugs? Usually, it ends up being a weak link in filesystem paths, SVN integration, or SSH integration. What causes these issues? Much respect for the folks who code them, I understand you do not owe anybody anything, but any honest assessment points to platform chauvanism.
"I do not use Windows, nobody I know uses Windows, true Ruby hackers are too cool to use Windows, begone ye Microsoft-infested slimeball"
The community (which I generally like and, let me note, actively contribute to) positively drips with this sentiment. DHH mentioned that 37signals wouldn't hire a Windows programmer (though he later backed down, somewhat), and the reasons were essentially tribal more than anything else.
And a big -1 to everyone who says that the Windows API is getting in the way of compatibility. Really folks? The Windows API being opaque made you hard code the path separator? The Windows API being opaque made parsing the results of a call to ls the more obvious choice than using the built-into-the-standard-library cross-platform way to get the contents of a directory? (To name just two implementation choices I've seen in Ruby libraries.)
> What causes these issues? Much respect for the folks who code them, I understand you do not owe anybody anything, but any honest assessment points to platform chauvanism.
An awful lot of developers are just writing a library or application to solve a problem they have, and they write it to function on the platforms which they deploy to. They don't own Windows licenses, and don't have the time or the desire to test their work on Windows. I imagine that usually it simply doesn't occur to them! And why should it? They're not writing code that doesn't work on Windows; they're writing code that does work on the platforms they develop on and deploy to. That it doesn't work on Windows is merely an unfortunate (and probably accidental) side-effect.
Clearly you have a big problem with the attitude of many members of the community towards Windows developers and the Windows environment. This may not be unjustified. But to claim that "any honest assessment points to platform chauvanism [sic]" seems short-sighted and unfair.
An awful lot of developers are just writing a library or application to solve a problem they have, and they write it to function on the platforms which they deploy to. They don't own Windows licenses, and don't have the time or the desire to test their work on Windows. I imagine that usually it simply doesn't occur to them! And why should it? They're not writing code that doesn't work on Windows; they're writing code that does work on the platforms they develop on and deploy to. That it doesn't work on Windows is merely an unfortunate (and probably accidental) side-effect.
Clearly you have a big problem with the attitude of many members of the community towards Windows developers and the Windows environment. This may not be unjustified. But to claim that "any honest assessment points to platform chauvanism [sic]" seems short-sighted and unfair.
1. The relative quality of many new Ruby libraries is extremely low. There are a lot of affected idiot hipsters who want to be the next DHH and think releasing every module they write will help with that.
2. Just run a headless VM to run your development in, since you don't have to deploy on Windows.
2. Just run a headless VM to run your development in, since you don't have to deploy on Windows.
Yes it couldn't be easier to just run ubuntu. Once you do, you'll never go back to dealing with windows paths (Better for Java dev too).
http://wubi.sourceforge.net/
http://wubi.sourceforge.net/
Unlike most Rubyists, I do a fair amount of Win32 dev work on projects. I heard all the warnings about Windows being a second-class platform for Ruby, but it really hasn't played out that way for me. Things that work fine on Win32 Ruby:
* EventMachine for network I/O
* Win32API for FFI
* ActiveRecord for persistence
A lot of 3rd party Ruby libs won't work on Windows, of course, because they're build around Unixisms. But that's true of every other language too; it's just less obvious in Python because it has such a sprawling stdlib.
* EventMachine for network I/O
* Win32API for FFI
* ActiveRecord for persistence
A lot of 3rd party Ruby libs won't work on Windows, of course, because they're build around Unixisms. But that's true of every other language too; it's just less obvious in Python because it has such a sprawling stdlib.
For what it's worth, these issues affect users of alternate implementations generally, such as JRuby.
Not updating changelogs is one thing that might be forgivable, but deliberately breaking things so that a specific platform isn't supported is pretty serious and a pretty serious alegation. Which projects are these, and how was Windows support broken?
Alas, I can't point fingers regarding things that I don't fully understand (I'm not a Windows developer or related to the projects claimed) - commentary is as good as I can do on the Windows side and I cannot quote e-mails without permission. One project that was mentioned, however, was DataMapper.
However, once I've investigated the claims, have permission, and got more of a story together, I'll be posting on Ruby Inside about it. There may or may not be a story, of course :)
However, once I've investigated the claims, have permission, and got more of a story together, I'll be posting on Ruby Inside about it. There may or may not be a story, of course :)
Ouch, are you speaking about the 0.9.8 update? I have on fairly good confidence that there was nothing deliberate, but I'd be interested to hear what has been said on your end.
I can't betray confidence by quoting, but no specific malice was claimed, simply that the quality of the process behind some releases was nowhere near that which you'd expect from a popular project.
Although lots of comments are about the Ruby language, I think this post can be applied to just about any open source project out there. It's always easier to complain to the maintainer than to try to fix the problem yourself and distribute the fix as a patch to others. Open source doesn't work well if there's only one person who fixes all the problems. I think it could also be a newbie developer mentality. Newbie developers are more likely to use libraries that are completely plug-and-play; if something doesn't work right, they'll complain rather than try to fix it themselves.
It's also a problem with Windows itself. It really is a nasty environment for coding non-MS-based software on.
If I want to support Windows I have to setup a (virtual) machine with a license code just to have any basic functionality. As someone who doesn't work with Windows anywhere, this is a huge hurdle. Then there's the hoops I'd have to jump through just to get a decent shell and a compiler ready.
Oh, but the fun doesn't end there. Which version of Windows are we talking about? More than one? Ah, well, each of these will require its own machine (virtual or otherwise). With matching keys, of course.
Supporting Windows is a pain and when it's not required for what I want to do, I'm simply not going to do it. Period. I have better things to do with my time.
Letting people who want this code running on Windows do it themselves and having them submit patches upstream is a perfectly valid choice.
If I want to support Windows I have to setup a (virtual) machine with a license code just to have any basic functionality. As someone who doesn't work with Windows anywhere, this is a huge hurdle. Then there's the hoops I'd have to jump through just to get a decent shell and a compiler ready.
Oh, but the fun doesn't end there. Which version of Windows are we talking about? More than one? Ah, well, each of these will require its own machine (virtual or otherwise). With matching keys, of course.
Supporting Windows is a pain and when it's not required for what I want to do, I'm simply not going to do it. Period. I have better things to do with my time.
Letting people who want this code running on Windows do it themselves and having them submit patches upstream is a perfectly valid choice.
What if I'm an anything else coder and I want to support Mac? Forget license, I need to buy a new machine. Linux is the only really painless platform to support if you're not using it.
But if you support any sort of *nix, then you quite possibly work on OS X already. If not, there's still probably minimal work to do.
It's not like going from Unix to Windows, where you have an entirely different access control mechanism, system API, filesystem structure and path separator, etc.; it's just going from one Unix to another. So the author only has to accept a couple patches from his Mac-using colleagues, and then he's basically set for OS X. On the other hand, debugging a Unix app on Windows can become a full-time job, and may be more work than you can reasonably expect a few random patch contributors to accomplish.
It's not like going from Unix to Windows, where you have an entirely different access control mechanism, system API, filesystem structure and path separator, etc.; it's just going from one Unix to another. So the author only has to accept a couple patches from his Mac-using colleagues, and then he's basically set for OS X. On the other hand, debugging a Unix app on Windows can become a full-time job, and may be more work than you can reasonably expect a few random patch contributors to accomplish.
I think this is related to Ruby in the sense that there aren't that many Ruby coders. The whole "scratch an itch" thing is a numbers game - maybe %1 of the people who have a problem would actually contribute a patch that fixes it, so the more people use a language/project the higher the chance the original author would get some outside help.
As for newbie devs, I'm not sure I agree... as a non-newbie, I still like to get a solution that works. I might be able to dive into the code and fix it, but I don't want to do this - I prefer to focus on my app rather than figure out why certain libraries don't work.
(For some reason this view seems to be common in Ruby. A prominent example was the web server - until Passenger came along (surprising everyone) you were supposed to figure out how to deploy with lighttpd, then mongrel - instead of simply working with Apache which most of the world already knew how to install, scale and tune.)
As for newbie devs, I'm not sure I agree... as a non-newbie, I still like to get a solution that works. I might be able to dive into the code and fix it, but I don't want to do this - I prefer to focus on my app rather than figure out why certain libraries don't work.
(For some reason this view seems to be common in Ruby. A prominent example was the web server - until Passenger came along (surprising everyone) you were supposed to figure out how to deploy with lighttpd, then mongrel - instead of simply working with Apache which most of the world already knew how to install, scale and tune.)
I think the reason it's a Ruby problem is the c - extensions to Ruby are hard to cross compile across platforms. Windows is a particular problem because the c compiler situation is not consistent. There are still a lot of people using Visual Studio 6 to compile this stuff....
As far as deployment goes, when you can run Windows services for the mongrels, do you even need capistrano? I've been doing Rails for years without it and don't feel like I need help deploying....
As far as deployment goes, when you can run Windows services for the mongrels, do you even need capistrano? I've been doing Rails for years without it and don't feel like I need help deploying....
Isn't the C extension issue the same for other languages, eg Python or PHP? (I really don't know, I'm not that familiar with Ruby internals)
I think this issue, like Capistrano's, would benefit from having more Ruby coders, which in itself might require a more newbie-friendly approach from the community.
(BTW I hope it doesn't seem like I'm criticizing Jamis' choice - actually I think he's doing the right thing in the current situation, just that if there were more Ruby coders around he might not be forced into choosing this path)
I think this issue, like Capistrano's, would benefit from having more Ruby coders, which in itself might require a more newbie-friendly approach from the community.
(BTW I hope it doesn't seem like I'm criticizing Jamis' choice - actually I think he's doing the right thing in the current situation, just that if there were more Ruby coders around he might not be forced into choosing this path)
The C extension issue in Ruby is the same as Python afaik. There probably aren't as many windows developers using Ruby though.
People who receive free software really have no right to complain about it, if it isn't working as they want it to. They didn't pay dime for it. Either donate money to the project or scratch your own itch. It's not the job the the original developer to spend all of his/her time fixing other people's problems.
This is a terrible attitude and one that I'm fairly certain is not shared by the best open source developers.
If you publish some code and go around claiming it does this and that, you are absolutely responsible for making good on those claims. Your reputation is at stake. How much you are getting paid is irrelevant. Besides, there are plenty of indirect ways to profit from making free software.
Also, there are implicit claims in every piece of software that doesn't say otherwise, namely that it is secure, won't trash your data, follows best practices, is not full of bugs, etc.
If you want to publish "as is" software, that's fine, but it should be made explicity clear to what degree you stand behind the quality of your code.
Users have no business complaining because you won't add some feature they came up with or your pre-release version isn't solid. But it is quite reasonable to complain if an open source project does not live up to its own pretenses.
If you publish some code and go around claiming it does this and that, you are absolutely responsible for making good on those claims. Your reputation is at stake. How much you are getting paid is irrelevant. Besides, there are plenty of indirect ways to profit from making free software.
Also, there are implicit claims in every piece of software that doesn't say otherwise, namely that it is secure, won't trash your data, follows best practices, is not full of bugs, etc.
If you want to publish "as is" software, that's fine, but it should be made explicity clear to what degree you stand behind the quality of your code.
Users have no business complaining because you won't add some feature they came up with or your pre-release version isn't solid. But it is quite reasonable to complain if an open source project does not live up to its own pretenses.
I think you point it out well. Users have no business complaining because you won't add some feature they came up with. What if that feature is something the user believes is very important to the software, but you think it's a complete waste of your time to even bother to add or maintain it?
That's what this whole Capistrano situation seems like to me (sadly, I didn't even think cap worked on windows). People are irate because a project is dropping support for a platform it never seemed to work well on to begin with. Have the developers ever promised windows support? I always thought their main claim was that it's a tool to automate deploying (mostly rails) apps, and I think it works well in that regard. I didn't think those promises extended to platform support as well.
That's what this whole Capistrano situation seems like to me (sadly, I didn't even think cap worked on windows). People are irate because a project is dropping support for a platform it never seemed to work well on to begin with. Have the developers ever promised windows support? I always thought their main claim was that it's a tool to automate deploying (mostly rails) apps, and I think it works well in that regard. I didn't think those promises extended to platform support as well.
Given the informal nature of software development, there are going to be a lot of grey areas when it comes to implicit standards and best practices. But it's the principle that matters. Some people believe that open source can do no wrong. I think that belittles open source.
As for this case.. well, Capistrano is a Ruby lib and Ruby libs tend to work on any platform Ruby does, unless otherwise specified. Plus, it used to be supported, which means people invested their time, thinking it would continue to be. It's a weak complaint but it deserves at least a little recognition.
But the attitude bothers me more than the action. Read that message again and then look at this sunshine enema: http://www.capify.org/
Can you put that site online and then claim you're not beholden to anyone? Questionable.
As for this case.. well, Capistrano is a Ruby lib and Ruby libs tend to work on any platform Ruby does, unless otherwise specified. Plus, it used to be supported, which means people invested their time, thinking it would continue to be. It's a weak complaint but it deserves at least a little recognition.
But the attitude bothers me more than the action. Read that message again and then look at this sunshine enema: http://www.capify.org/
Can you put that site online and then claim you're not beholden to anyone? Questionable.
Maybe this is a difference in expectations, but I don't expect a platform to be supported forever, nor do I expect support for a platform when not specified, by anyone. When I looked at the "sunshine enema", I saw a tool for a specific purpose and not much else, certainly not anything about what platform the tool supported which could wait until I read the install/download pages. What I read in the message was someone who was stuck doing something he didn't like, and he was asking for people to do precisely what he did with Capistrano: step up and scratch their own itches, something further helped by Capistrano being an open source project with a current release that still works fine with Windows. I didn't see someone who should have been beholden to anyone otherwise. I also don't see that as an OSS project doing wrong, I think it's reasonable given the situation and this certainly does not have to end here in this way.
For what it's worth, what would bother me is if this wasn't explicitly announced and the dev just didn't feel like working on the project anymore, or if it was a core feature of the tool that was going to be ignored in the future. Now that's something to complain about, and then go do something about if it mattered that much to me.
I've personally been in a similar hellhole of a situation (who hasn't?) doing some dev work for a nonprofit where less than 5% of the users both by number and usage completely wasted my time trying to convince me I should bring back support of older browsers and platforms for absolutely no legitimate reason other than a lack of willingness to upgrade on their part, even though the nonprofit had existing volume and discounted licenses that would effectively make the software free for them. Make a lazy <5% happy by doing LOTS of extra work possibly eschewing working on features for the other >95%, and still deliver what may be a subpar experience (think windows 98 when everyone else is running Vista) while billing them for it at the same time? No thank you.
For what it's worth, what would bother me is if this wasn't explicitly announced and the dev just didn't feel like working on the project anymore, or if it was a core feature of the tool that was going to be ignored in the future. Now that's something to complain about, and then go do something about if it mattered that much to me.
I've personally been in a similar hellhole of a situation (who hasn't?) doing some dev work for a nonprofit where less than 5% of the users both by number and usage completely wasted my time trying to convince me I should bring back support of older browsers and platforms for absolutely no legitimate reason other than a lack of willingness to upgrade on their part, even though the nonprofit had existing volume and discounted licenses that would effectively make the software free for them. Make a lazy <5% happy by doing LOTS of extra work possibly eschewing working on features for the other >95%, and still deliver what may be a subpar experience (think windows 98 when everyone else is running Vista) while billing them for it at the same time? No thank you.
It's really surprising how many people don't understand this. I hang out in a support channel for an open source app, and people are downright offended when I tell them that whatever feature they want they'll have to implement themselves because all the people capable of working on the project are uninterested or too busy to do anything, and there's a longer list of more important fixes/features that are wanted. Not just a "oh, I understand", but an outright "what the fuck? I don't know how to code", "this 'community' is BS", "what a frigid bitch..." and more. All because I told them that the app was open source so they should consider doing it themselves.
(Funnily enough, there's a competing app that is not open source or free, and they're still not doing a great job of updating the app and adding requested features for paid customers either..)
Anyway, my two cents is that people shouldn't expect donations to make the developer(s) scratch their itches. A donation is a donation. Maybe some devs and projects would be more willing to look into things for you after one, but unless they explicitly have such a policy, I wouldn't expect it to happen.
(Funnily enough, there's a competing app that is not open source or free, and they're still not doing a great job of updating the app and adding requested features for paid customers either..)
Anyway, my two cents is that people shouldn't expect donations to make the developer(s) scratch their itches. A donation is a donation. Maybe some devs and projects would be more willing to look into things for you after one, but unless they explicitly have such a policy, I wouldn't expect it to happen.
I have an honest question: Why does anyone want Ruby to run on Windows? The cost of switching to Ubuntu and running Ruby there is probably way, way cheaper than rewriting all the libraries to work on Windows.
I don't understand why this is even an issue.
I don't understand why this is even an issue.
You know, not to flame, but this attitude is exactly why Ruby isn't where it could be.
I love Ruby, do most of my work in it now and haven't owned a Windows machine since 2001, but if Ruby's answer to Windows users is "just switch to Ubuntu" it's not surprising they decide to just choose another language.
I love Ruby, do most of my work in it now and haven't owned a Windows machine since 2001, but if Ruby's answer to Windows users is "just switch to Ubuntu" it's not surprising they decide to just choose another language.
Because for ruby, asking a developer to convert not only to your language, but his whole platform as well is going to seriously hinder your adoption rates.
Not caring about adoption rates is another story altogether.
Not caring about adoption rates is another story altogether.
Many developers have no choice but to use windows thanks to corporate policy ... I am not saying that is a good thing, but its the way it is (at least where I work). I resorted to doing Rails dev using Emacs + Putty, which was easier than developing the app on windows!
Even better, run andLinux inside of Windows
I can't give up Photoshop for the type of work I do and I can't afford a macbook yet so I just installed andLinux and have all of the abilities of Rails and Linux while still using Windows. All you really need for Rails is the command line, I use Intype in Windows for my editor and I am cruising. andLinux only uses about 100mb of a RAM at any given time so it's barely noticeable when it's running in the background.
I can't give up Photoshop for the type of work I do and I can't afford a macbook yet so I just installed andLinux and have all of the abilities of Rails and Linux while still using Windows. All you really need for Rails is the command line, I use Intype in Windows for my editor and I am cruising. andLinux only uses about 100mb of a RAM at any given time so it's barely noticeable when it's running in the background.
I don't think RoR is that bad on Windows. I've used InstantRails on Windows quite successfully for over a year now with only occasional problems with plugins (like Paperclip, though it's fine now).
It seems the incompatibilities come from things like capistrano which are quite close to the metal. And that seems reasonable to me. However, expecting new users of your language/framework to delve into the internals just to make their basic app work isn't going to happen. Maybe it should, but it isn't.
It seems the incompatibilities come from things like capistrano which are quite close to the metal. And that seems reasonable to me. However, expecting new users of your language/framework to delve into the internals just to make their basic app work isn't going to happen. Maybe it should, but it isn't.
Isn't it kind of obnoxious how Google requires a login to read public group archives? (Or am I mising a way to read these without logging in?)
I don't understand why people on windows just install Wubi. It dual-boots into Ubuntu (a MUCH better OS anyways) and the whole database is stored as a file so you don't have to fiddle around with hard drive partitioning. Or you can just pop VMWare on your computer and have linux running in no time flat.
If you're using Windows to develop for RoR, you're just lazy and you don't deserve to be supported.
If you're using Windows to develop for RoR, you're just lazy and you don't deserve to be supported.
At Euruko (European Ruby conference) earlier this year, I raised the topic of Windows and.. most of the audience couldn't care less. They were mostly of the opinion that if Windows people wanted to use Ruby, they had to do the legwork. (FWIW, I'm an OS X user who doesn't care too much for Windows either, but I recognize there's a massive userbase there)
Windows is in the third-world of operating systems when it comes to Ruby - so Jamis' standpoint is less than surprising.