If you’re a developer, but have never touched Ruby on Rails, we understand how you feel. We were there once! Sometimes diving into a new language and codebase can make you feel like this: The good news is that Discourse has a wonderfully supportive community and we’re here to help. Here’s our first guide on…
This topic is for comments on the original blog entry, at http://blog.discourse.org/2013/04/discourse-as-your-first-rails-app/
I have seen some twittering by @robconery that I would like to respond to here as opposed to on twitter.
https://twitter.com/robconery/status/321772134366056449
https://twitter.com/robconery/status/321772327266291712
https://twitter.com/robconery/status/321772408468013056
Getting started with Rails on Windows is hell, there, I said it. People often have this delusion that there is this magical Ruby installer you can install, it installs Ruby, you can use that develop Rails.
The reality is that Ruby, as used by most Rails apps is full of unixism, performance of Ruby MRI (the default Ruby) on Windows is abysmal, Rails load times are hellish, sooner or later (more likely sooner) you are going to hit gems that simply do not work properly on Windows.
So … if you are on Windows (Disclaimer: my primary Dev machine is Windows 8) and would like to play with Rails you are must install a Linux VM.
Getting a VM from 0, to ready to rock-and-roll with Rails is a tedious task. You need to install Ruby (preferably rbenv or rvm). You need to configure a database. You need to install a whole bunch of weird and wonderful packages you never knew you needed, like libreadline or libyaml.
The article presents a very simple way to get a bootstrapped VM ready for Rails and Discourse development. It takes care of a bunch of things for you that you probably never even knew you needed, including GC tuning.
You can use that VM to develop other Rails apps if you wish, its bootstrapped and ready to go. This series of tweets is merely criticising the title, the beef of the article is about giving a simple way for Windows users to get started with Discourse.
In response to some of the particular points:
Discourse is highly tuned for performance
Hell yeah, and we are playing nice with the community helping tune Rails with stuff we find.
I have personally built flame graph support for MiniProfiler, we are finding all sorts of wonderful things and making sure we share all this love with the community.
There is this complete misconception out there that Discourse does not use Active Record idiomatically, the reality is that the majority of Discourse is idiomatic Active Record and idiomatic well tested Rails with the odd performance exceptions. Sure, you can point your finger at a few exceptions, but look through all the code, not only at the exceptions.
Discourse uses pretty idiomatic Active Model Serializers for persistence, we made a few contributions to help turbo boost them.
Our test suite contains over 2000 tests. Our code base has been heavily scrutinized due to our high profile and heavily refactored since launch.
uses a heavy Single-Page App approach
Like it or hate it, Discourse is an Ember app, we work with @tomdale @wycats and team to make sure our Ember code is as idiomatic as possible. A lot of ground has shifted under our feet in the last year, keeping up with best practices can be hard. Nonetheless, we are not afraid of making big changes, like shifting our code from CoffeeScript to JavaScript or doing major refactoring so the code flows better. We are totally open to contributions from the community.
If you don’t want to touch the Ember bits and still want to hack on Discourse, there is plenty to do.
Which brings me to my final points:
The sentiment of the tweets, is move along, nothing to see here, if you are new to Rails avoid at all costs. I think that sentiment is completely wrong.
If you are a Windows dev and want to get started hacking on Discourse, this is the easiest way for you to get going.
It gives you a VM where you can hack on the Discourse CSS and get live reloads as you are hacking, allowing you to easily contribute style changes to us.
Plenty of areas of Discourse could do with help and don’t require extensive Rails knowledge, like building new oneboxes
If you are a JavaScript dev there is plenty to hack on that does not involve even looking at Rails code.
If you would like to get started with some Rails bits, you could look at amending models, controllers, or libraries.
As an added advantage, you will have a VM that you can use for hacking on many other Rails apps.
Its still early days, but we intent to have a very simple mechanism of building plugins, and this will be an excellent bootstrap for it.
Yes, Discourse is huge, I would probably not learn how to program or how to build Rails apps just by reading Discourse source code. That was never the intention. There is plenty to learn from the code, there is plenty to hack on for a wide variety of backgrounds. Looking at our code is not going to make you a bad Ember or Rails developer. Reading lots on lots of different bits of code is the way you become a better developer.
And, as always this vagrant image is simply a service to the community. Make it easier for Windows developers to get started hacking on Discourse. As an added bonus they can use the image to hack on any Rails project.
Thanks for the reply Sam. Let’s have “Civil Discourse”!!
Completely agree on all points RE Rails on Windows. I usually recommend to people to use a VM, as do you. In this we agree.
It would be lovely if the title of the article reflected what was written in the article.
I think the work you’re doing with the Rails team is exemplary, kind, and outstanding. Hopefully you’re not taking my thoughts and applying to the help you’ve given.
I’m sure you have your reasons to do what you’re doing with ActiveRecord - but using the term “idiomatic” under the headline of “First Rails App” is a bit muddled when you have a look at this:
I didn’t say to “avoid it at all costs”. Not exactly fair of you.
I agree with this. That’s not the title of the article.
And that’s my point. We don’t disagree after all :).
It would be lovely if people responded to articles instead of titles of articles 
There are 5 bits of inline SQL there, one of them can not be written in AR others there for perf, which I would be happy to factor into AR if performance remains the same.
The majority is scopes, has_many, belongs_to, callbacks, AR updates, transactions and various rails idioms. Admittedly, this model is too big and should be split down some.
I’m responding to all of it :). Some suggestions:
First: if you’re trying to show “how to get your windows box setup for Discourse” - perfect. I think the VM approach and other things are great advice.
Second: “Idiomatic” is probably not the best way to put what you’re doing, as “idiomatic” means “adopted best practice”. In your case, you’re squeezing the last bit of perf that you can out of Rails which I think is great, but that’s not what people do “idiomatically”.
As nicely as I can put it: the perf tweaks you’ve put in are premature optimization in practice. That’s going to sound rather negative and you have good reason to assume that Discourse will get hammered. But the practice in Rails is that “it’s not a problem until it’s a problem” and … well optimizing before you need to is… well premature optimization.
Please don’t get me wrong: inline SQL is just fine for the need. It is not idiomatic Rails.
Finally: yes all projects under first release are rough around the edges (which again I think we agree on) and I think it’s wonderful to reach out to the community and ask for help (which I believe is what this post is all about). It might be nice to have a bit more clarity on these posts - especially for .NET devs who’ll wonder if it’s “idiomatic” to have a 500 line model.
I kind of agree with Rob, we are a highly specialized app, an example of a super JavaScript heavy, single page app – in the true sense of the word “app”. I don’t disagree with anything said in those tweets.
However, if you believe like I do that the future of the web looking 5 years out is JavaScript heavy, single page apps for almost everything, then it might be wise to take a look. 
You know, Atwood’s Law and all that. 
But right now today, sure, there are a lot of traditional websites and traditional multiple page JS enhanced apps that (mostly) work with JavaScript disabled.
I think we are mostly in agreement, though keep in mind, most our optimisations are not premature, they usually came in as a result of profiling. The premature optimisation mis-quotation often rubs me the wrong way.
That said, I think the title of the blog post could have been clearer. “Getting started with Discourse development on Windows.” would be way more correct, but has so much less of a ring to it.
Is it… is it… possible we’re agreeing? Even on Atwood’s Law? Oh wow.
That argument usually resolves down to which threshold you want to honor. One of the worst things as a dev lead is when someone gets clever writing code to shave millies - tripling the overall code required.
In some cases one could make that argument here. Do you know that you’ve gained anything over naked ActiveRecord and Memcached? You could easily say “yes I’ve profiled it” and “we have a write-heavy app so I need that extra 10 millies” - and you might be right.
Then again, you might not be right. This is the subject for another thread - of course - but the ultimate question is “did you write that code in response to a real problem”? My opinion is that a benchmark/profile squeeze is not a real problem.
Speaking as a non-developer (I know, I know, throw bottles at the drooling IT guy), I see traces of my own Ruby frustrations in this blog post and the replies here. I’m interested in running Discourse, but I don’t necessarily have the time or ability to contribute code to the core project.
I sort of kind of WAS under the impression there was some kind of magical “install Ruby” command I could run—I’m spoiled by APT and the magic of Debian packages. When setting out to get Discourse up and running, I thought it would be as easy as “sudo aptitude install ruby” with maybe some config file tweaking—I mean, I set up php-fpm without any problems. Hell, I even got bind9 and isc-dhcp working together so I could do DNS & DHCP the right way on my LAN! After fighting through that mess, how the hell hard could it be to set up Ruby?!
Yeah.
A weekend later, I have a functional Discourse install, but there were so many steps involved (and so much backtracking) that I’m not terribly sure I could repeat the install if I had to. I know that the way around that would have been to simply deploy all of this in a VM and lean on the automated processes, but as a Ruby Newb I truly had no idea that installing Ruby + the gems I needed in the way necessary to make it all work would be quite so much like upending a toy chest on the nursery floor…except instead of a toychest and a floor, it’s a whole shitload of ruby things and gems and bundles and stuff all over my drive.
It’s apparent that Discourse is being crafted with care and that you guys are driving toward a great package, but do keep it in mind that non-devs want to play too! You don’t have to be issuing pull requests left and right to enjoy deploying and hacking around with FOSS, and us casual users with a penchant for deploying half-tested software in production want to be included in the journey
I haven’t looked at those bits, myself, yet; but have you looked at the Squeel gem? I found that it eliminated a lot of really ugly things I was having to do to work around things Active Record doesn’t really want to do, and without needing inline SQL to do it… Just a thought.
It’s worth pointing out that once you have installed Github for Windows, you now also have various traditional *nix utilities, including ssh that you can then use for vagrant ssh. In fact, I’m not sure it’s possible to get git without an ssh client if you don’t already have one. (G4W is a portable git mingw install).
Putty is nice, but it’s not essential.
What’s the actual path to that SSH client, the one installed with GitHub for Windows?
On Mac it’s
vagrant ssh
what’s the equivalent for the GitHub SSH client from GitHub for Windows?
Ok great thanks @zogstrip and @factormystic I updated the blog post, that is definitely cleaner and simpler!
I believe the vagrant halt command is better suited for shutting down the machine.
The vagrant destroy command should be used to completly remove the VM from the computer.
Good catch, @zogstrip, I’ve updated the post with this.
So, my goal with titling the article as such was to try to succinctly convey to non-Ruby folk, who’ve been contemplating Ruby, to take the plunge. As @sam’s pointed out, there really is no easy way on Windows, and it’s been my experience with some developers, confusing and terse instructions on a myriad of components tend to turn them away.
This next sentence is going to suck to hear, so I apologize in advance:
Some developers simply do not know what ‘bootstrapping’ means.
I wanted the approach to this to be as straightforward as possible, with as few barriers to frustrate and/or confuse users as possible. My strategy here is that a much larger chunk of folks:
Thus, the title of the article.
By any chance, is the image available in Hyper-V format? Do you plan to support Hyper-V in the future?
See
If you want to lobby the Vagrant team to support Hyper-V. I believe they support VMWare but not on Windows at the moment.
