Ruby on Rails Love-In

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Ruby on Rails Love-In

Magicmat: Aug 14, 2000; I've got the worst fucking attorneys

I used to be a decent Rails coder around the 1.x days, but I left it (and all web programming) for a while. Now I want to create a new web project with Rails, but I'm at a loss because things changed so much.

Back when I was last programming, jEdit was the IDE I used on Windows (Eclipse had just gained support, but it was weak,) SVN was the version-control system of choice, and there had yet to be any major changes to either Rails or Ruby 1.8.

So where do I start? What's the IDE of choice these days on Windows? Does Git's windows support still suck? (Mercurial was the windows guys' distributed versioning system when I last checked, do Rails and Mercurial play nice?) When is Rails 3.0 coming out? If I'm embarking on a moderate-sized project, should I wait to jump back in or just go with the current 2.x version?

Any other gotchas or tips I need to know before starting back with Rails again?

(I know the answers are probably sprinkled throughout this thread, but it's 27 pages, the first half of it is so old as to be out of date, and no search.)

# ¿ Jun 25, 2009 04:15

Adbot: ADBOT LOVES YOU

# ¿ Apr 30, 2024 23:33

Magicmat: Aug 14, 2000; I've got the worst fucking attorneys

long-shot, but does anybody happen to have one of those 50% off coupons for Jetbrains' RubyMine that they were giving away during beta? If so, would you be willing to part with it?

# ¿ Jul 25, 2009 00:19

Magicmat: Aug 14, 2000; I've got the worst fucking attorneys

Also, while I'm here, what is the most recommended Ruby interpreter to deploy? I know Ruby Enterprise Edition is supposed to be 1.8.6 but not suck so much, but 1.9.1 is supposed to be hella fast, and Rails just got updated for it. However, I also know that other items apparently don't yet support Ruby 1.9. Assuming I'm not using a whole pile of weird plug-ins and gems, is there anything in the standard Rails ecosystem or commonly used 3rd party code/plug-ins that does not like 1.9? I've also seen good speed results from JRuby (which apparently Rails also supports, I think?) Same questions there, too.

# ¿ Jul 25, 2009 02:08

Magicmat: Aug 14, 2000; I've got the worst fucking attorneys

I know ruby 1.8 but never so much as glanced at 1.9 until I saw how god damned fast it was and that rails now supports it. I know 1.9 has some major, incompatible changes with 1.8, so what's the best way to learn it? Is there a webpage out there with a list of changes, and is that enough to learn 1.9? Or should I get the new 1.9 pickaxe to compliment my 1.8 pickaxe? What about O'Reilly's 'The Ruby Programming Language'? A lot of people are saying it's better than the pickaxe, and it says it covers both 1.8 and 1.9, but it was published 18 months ago, is the 1.9 info still accurate?

# ¿ Aug 21, 2009 00:48

Magicmat: Aug 14, 2000; I've got the worst fucking attorneys

Don't listen to these guys. Ruby users happens to largely be Mac users and they'll waste no opportunity to try to tell you a Mac is better for everything ever done. While it's true that a Mac may have more support for RoR, Windows certainly isn't impossible by any means (installing cygwin? really? that's like some windows admin not knowing how to work with OS X, so he installs VMWare with Windows.)

If you want Ruby 1.8, go grab InstantRails and update the gems to whatever you want. The version of ruby in there, 1.8.6, is a little old, but RubyEE is the same version so you'll live. If you want Ruby 1.9, go here to get the One Click installer for Windows and then just install the gems by hand (just remember to install it in a directory path with no spaces, such as C:\Ruby19.) I've had no problems getting all the gems I need, although I did need the development kit from the One Click installer link above in order to get ruby-debug-ide for my IDE. Even Mongrel worked right the first time.

Yes, you will need to use the command line for a lot of stuff, but it's not a big deal. I personally use my IDE, RubyMine, to do a lot of the stuff I would normally do at the command line, but there's no reason you couldn't just use the command line itself. The Windows command line does suck a bit, though. Maybe check out that Console2 app linked above?

And if you're feeling envious of TextMate on OS X, try out the e text editor on Windows. It's a pretty close analog of TextMate -- it can even use TextMate bundles.

Really, the only world of suck I've found on Windows is using git. There is a version of git for Windows, but there's no good GUI for it yet, and using a VCS from the command prompt (even in Linux or OS X) always annoyed me to no end.

Obviously you wouldn't want to deploy on Windows, and perhaps if you get to the level where you need complicated scripts for running tests and other production work then Windows would start to lose its luster. But I figure by the time you get to that point you won't have a problem dropping $2k on a second computer.

Magicmat fucked around with this message at 09:01 on Oct 23, 2009

# ¿ Oct 23, 2009 00:42

Magicmat: Aug 14, 2000; I've got the worst fucking attorneys

atastypie posted:

What thread are you reading magicmat it sounds much more interesting and fictional than the one i am in

haha, perhaps. It just seems that every time someone asks about Windows stuff, there are 3-4 posts of people trying to dissuade him or her from even using Windows for Ruby stuff at all. And worse, it seems that the people dissuading the poster are not Windows users themselves, and don't have a good grasp of the ins-and-outs of using Ruby on Windows.

Like I said, it takes a bit of work, and there are some downsides, but it's not so horrible that someone should ditch their entire OS, or even computer, just to do some RoR development.

# ¿ Oct 23, 2009 04:18

Magicmat: Aug 14, 2000; I've got the worst fucking attorneys

Operation Atlas posted:

I see nothing wrong with encouraging people to use better tools. A Unix-based environment is undeniably better for running most programming language environments. We only suggest Macs because we love Textmate and they're the best vendor of Unix-based laptops.

If you want to put Ubuntu on your desktop or buy one preloaded with it from Dell, more power to ya! It'll work great and it is just as easy to find support as it is for OS X. You'll spend less time setting up a dual-boot Ubuntu setup than you will trying to track down windows versions of gems with compiled components.

Really, I evangelize Ubuntu/Debian as much as I do Apple. I might say a similar thing to someone running CentOS, for instance.

See, this is what I'm talking about. If this were an OS thread, you would be completely warranted in your evangelism. But when somebody asks "how do I get RoR set up on Windows?" the correct response is never "change your entire OS" or "buy a new computer" unless they're specifically looking to install a new OS or buy a new computer centered around RoR development.

Turn the tables. Imagine if every time somebody asked something about TextMate or getting Ruby 1.9 from apt-get or something I would come in and post "ugghhh you really should be using Windows for this. It does nearly everything your computer does but has way better general application support and is cheaper/easier to use." True or not (ps: don't argue whether that is true or not I don't care it was just an example of a troll) that probably wasn't the answer the person was looking for.

NotShadowStar posted:

C-based Ruby extensions on Windows.

True, they can be if the C extension are very specifically coded just for *nix. But I've found most pretty cross-platform (or at least POSIX compliant.) And after unzipping the ruby devkit linked above, compiling these extensions is a no-brainer. To install mongrel from source, even in Ruby 1.9, I just typed "gem install mongrel" and Ruby Gem grabbed the source and compiled the whole thing for me. All of this without having to do anything other than unzip an archive -- no messing about with setting up my own C dev environment or setting up environmental variables or anything.

Yes there will be C extensions that don't work. I'm sure you could easily find half a dozen right now. But so far, at this admittedly early stage in my game, I've yet to encounter one in my everyday work.

So if there's one take-away from this, it's to stop turning Ruby on Rails into a vector for OS evangelism, and if you don't know how to do something on Windows you should probably refrain from answering someone's Windows question instead of telling them to switch to an OS you do know how to do it on.

Magicmat fucked around with this message at 21:52 on Oct 23, 2009

# ¿ Oct 23, 2009 21:47

Magicmat: Aug 14, 2000; I've got the worst fucking attorneys

NotShadowStar posted:

Except we're not evangelizing. It really does suck poo poo still on Windows, and Ubuntu is still terrible unless complied from source. Your example is terrible because the Ruby community pretty much uses Macs or some form of Linux, and kinda offhand does Windows whenever they care (nobody does). So the fact of the matter is that it's going to work much better on non-Windows because that's how the community works.

So really, you can gently caress around on Windows, download some weird Ruby pre-compiled stuff that hasn't been updated in 9 months, gently caress Around Endlessly to try and get the goddamn thing to function, maybe, and then you maybe start learning Rails. Getting Ruby and cohort working on Windows for someone who has never really worked with it is an exercise in pain, even today.

Or on a decent Linux distro, all you have to do is 'gem install rails' and 'gem install mysql' and 'gem install sqlite3'. Done, you're ready for Rails. On OSX, you need to install the Dev Tools CD and the do the same (or not even, OSX comes with Rails but it's typically outdated).

Working with Ruby and Rails on Windows is like equivalent to doing iPhone development on Windows, or .NET on Linux. Yeah, you probably COULD do it, but you better know how first because it's not going to be pleasant.

But that's my point: you're wrong. It isn't as big a pain as you make it out to be.

You want to know how to get a fully working version of Ruby 1.9, Rails and MySQL? Here, read this. 12 plainly-laid-out steps to getting the whole shebang. The blog post you linked to was simply a retelling of the exact blog post I linked to, but retold by someone for whom English isn't his primary language, and with code typos. In fact, when you Google "ruby 1.9 mysql windows", the blog post I linked to is the second result, meaning you had to dig to purposefully find a poorly-written version. So kudos on that, I guess?

And, of course, if you only want Ruby 1.8 (which most people are still using these days anyway) then there's one simple GUI installer that installs Ruby, Rails, MySQL and a ton of other extras, configures them, and even gives you a nice GUI to manage all of them from. (By the way, this method is laid out right in the opening chapters of the Rails book.)

Is installing Ruby 1.9 on Windows more complicated than OS X? Yeah, probably. But if having to follow 12 steps to install a dev environment is enough to make you change OS's, then maybe programming isn't for you?

Windows will have quirks, sometimes things won't work as easily, and sometimes you'll have to google stuff. And, yes, I'd recommend keeping a Linux VM around for production testing and the like (nginx and Phusion Passenger still don't have Windows support.) But for someone who simply wants to get started in RoR programming, making them ditch their entire OS to save 12 steps of work is a completely lopsided equation.

Doing all you dev work inside a VM is a lot more palatable, but I think the segregation of a VM makes things harder to use daily than taking the up-front time to get Ruby working on Windows in the first place. That's just me, though; others may like that option better.

# ¿ Oct 24, 2009 03:10

Magicmat: Aug 14, 2000; I've got the worst fucking attorneys

Not perfectly on-topic, but I figure a lot of people would know the answer to this:

In textmate, is there a way to auto-insert a closing 'end' when I open a block? I know I have snippets for things like "def[tab]", which will insert a closing 'end' and a blank line in between.

But TM clearly knows when I open a block, by increasing indentation, and when I end a block, by decreasing indentation. Is there a way to make it auto-insert the code for the end of the block?

# ¿ Feb 1, 2011 22:48

Magicmat: Aug 14, 2000; I've got the worst fucking attorneys

NotShadowStar posted:

do[tab]

Yeah, but is there a way to do that without snippets, like TM does with parentheses or quotes? The problem with snippets is that, a), I need to retrain my fingers to use tab instead of return and, b), the snippet isn't always what I want. For example, with 'do', it always has a "|variable|" statement after the "do". I can just backspace over this, but that's still an extra keystroke and branch in my thought pattern that I'd rather not have.

Plus, there are blocks (using the general use of the term rather than specific Ruby do/end blocks) that TM doesn't have snippets for. For example, Cucumber "Scenario: " blocks, which are ended with a line containing the same indentation as the start of the block (which is a whole other problem right there.)

# ¿ Feb 1, 2011 23:15

Adbot: ADBOT LOVES YOU

# ¿ Apr 30, 2024 23:33

Magicmat: Aug 14, 2000; I've got the worst fucking attorneys

I'm having some trouble with Nokogiri.

I have a HTML::Builder to create a new HTML document, and inside it I'm looping over a collection with the #each method. Basically, if the current loop item has some attribute, create a new div in the document to contain some HTML, and have that div contain all subsequent loops' HTML until we hit another loop item that fulfills our requirements, where we create another div, etc.

Hard to explain, but imagine I have the following array of array:

code:

[['one', true],
['two', false],
['three', false],
['four', true],
['five', false]]

I would then want an HTML doc looking like this:

code:

<html>
<head></head>
<body>
  <div>
    <span>one</span>
    <span>two</span>
    <span>three</span>
  </div>
  <div>
    <span>four</span>
    <span>five</span>
  </div>
</body>
</html>

I'm currently trying to do something like,

code:

...
# 'doc' is the HTML::Builder object passed into the block of HTML::Builder.new()
container_node

item.each do |foo|
  if(foo[1]) then
    container_node = doc.div
  end

  Nokogiri:::HTML::Builder.with(container_node) do |bar|
    bar.span foo[0]
  end
end
...

But the results of doc.div don't appear to be a regular XML::Node I can use with Builder.with(). I also considered trying to create a new node without a document, then attaching it to the container_node at the end of every loop, but the results of doc.div is Nokogiri::XML::Builder::NodeBuilder, and I'm not sure if I can attach a child node to that easily. Plus, I'm not sure the proper way to go about building a new node without a Builder method.

Edit: If anybody cares, I figured it out.

container_node = doc.div always returns the NodeBuilder object that was just used to add a node to your document. NodeBuilders are pretty useless and I have no idea why they are returned; they're an internal Nokogiri class used mainly to set attributes on the new node (so things like foo.div.my_css_class_name work) and setup child blocks (which I guess answers my question.) However, if you do

code:

doc.div {
  container_node = foo.doc.parent
}

Then you'll be able to get the XML::Node that you want. Kinda roundabout and unintuitive, but there you go.

Also, stay away from using XPath and, worse, CSS selectors in Nokogiri if speed is a concern -- they're horrendously slow. I mean, Nokogiri is probably a lot faster than other Ruby alternatives, but still, I literally sped my application up by almost 4x by refactoring the code to walk the DOM manually rather than using selectors. Of course, the trade-off is that the code is a lot more fragile now (if the document structure I'm parsing changes even a bit, it stops working) but it was worth it for me. I used to do 2-3 CSS selects a loop iteration, times 50 iterations per file (on average), times 500 files -- it took 120 seconds; now it takes about 30 sec.

Magicmat fucked around with this message at 13:38 on Feb 16, 2011

# ¿ Feb 15, 2011 14:16

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Ruby on Rails Love-In