Ruby on Rails
-
Out of curiosity, why did you choose Msys2 rather than RailsInstaller?[^] I've been using RailsInstaller for over a year now and have never had problems with it. Marc
I ended up hitting a bunch of errors with Msys2, so I am now just going to use RubyInstaller (2.0.0-p353) and install Rails on that. I am using RubyMine as the IDE (it is good).
Getting information off the Internet is like taking a drink from a fire hydrant. - Mitchell Kapor
-
I ended up hitting a bunch of errors with Msys2, so I am now just going to use RubyInstaller (2.0.0-p353) and install Rails on that. I am using RubyMine as the IDE (it is good).
Getting information off the Internet is like taking a drink from a fire hydrant. - Mitchell Kapor
Brisingr Aerowing wrote:
so I am now just going to use RubyInstaller (2.0.0-p353) and install Rails on that.
It has Rails already pre-installed.
Brisingr Aerowing wrote:
I am using RubyMine as the IDE (it is good).
Indeed it is! Good luck, let me know if you run into any problems. Marc
-
Brisingr Aerowing wrote:
so I am now just going to use RubyInstaller (2.0.0-p353) and install Rails on that.
It has Rails already pre-installed.
Brisingr Aerowing wrote:
I am using RubyMine as the IDE (it is good).
Indeed it is! Good luck, let me know if you run into any problems. Marc
RubyInstaller, not RailsInstaller. Last time I looked, RailsInstaller was out of date (I like to use the latest stuff when I can)
Getting information off the Internet is like taking a drink from a fire hydrant. - Mitchell Kapor
-
RubyInstaller, not RailsInstaller. Last time I looked, RailsInstaller was out of date (I like to use the latest stuff when I can)
Getting information off the Internet is like taking a drink from a fire hydrant. - Mitchell Kapor
Brisingr Aerowing wrote:
RubyInstaller, not RailsInstaller.
Ah, my bad. Yes, RubyInstaller isn't up to version 2 of Ruby and Rails yet, but for my purposes, neither is my client's code, and at least in Rails, there are some significant breaking changes. Marc
-
I don't know what value posting a link to something that large would be, but the steps, things to look-out for would make a great article :-) 'g'
:thumbsup:
Signature construction in progress. Sorry for the inconvenience.
Damn you have the perfect signature - CBadger
-
In my quest to learn Ruby on Rails, I am installing a Rails development environment using Msys2[^]. It contains all the base packages (other than Rails and its dependencies) I need, such as Ruby, a compiler toolchain (GCC), and various libraries and utilities. I can post a link to the system I set up here if people want (I will have to find a place to upload it first, as it is very, very large, almost a Gigabyte in size!)
Getting information off the Internet is like taking a drink from a fire hydrant. - Mitchell Kapor
Give a try to a vagrant box. There is one ready for RoR development here[^]. It runs a small linux server on a virtual box and forwards all needed ports to your computer, so you can keep your browser, your text editor (are you using Sublime?), git and so on on your machine. It is tricky to compile some gems on Windows, so it is much better to have a linux environment to handle it all. Hope this helped :)
-
Sampath Lokuge wrote:
why you have decided to learn Ruby on Rails instead of ASP.net MVC ?
I thought I'd answer that, as it's a question I keep asking myself as to whether I want to continue with RoR and/or include ASP.NET / MVC as well in my toolbox of technologies. I started with RoR over a year ago because that's what my client uses and I was taking over the web development. Looking at ASP.NET / MVC, it looks like Microsoft "borrowed" most of the concepts from RoR (who borrowed the concepts probably from somebody else), but anyways, it seems like it would be very easy to learn one once you know the other (and of course are familiar with the language itself.) That said, there is a huge base of developer support for RoR, and I'm not sure that places like NuGet have the same level of community contribution. Most of the stuff is of decent quality too. Because RoR is interpreted, it means that I don't have to recompile the app to see changes -- I can make changes to the model, controllers, and of course the views without having to restart the server. Makes development a breeze. Ruby is a cool language too, it's fun to work in, but it can also be seriously abused--things you just won't find in C# code, such as returning two completely different types from a function call. Marc
Marc Clifton wrote:
Because RoR is interpreted, it means that I don't have to recompile the app to see changes -- I can make changes to the model, controllers, and of course the views without having to restart the server. Makes development a breeze.
I'm about 70 coding hours into a RoR/AngularJS/Coffeescript project (all 3 new to me); and am finding about 2/3rds of my debug time is being spent on issues that a compiled/strongly typed language would've called me out on immediately; even ignoring that VS (or even Eclipse) >> Sublime my dev rate's a lot slower than on other platforms.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
Brisingr Aerowing wrote:
a compiler toolchain (GCC)
I'm confused. I thought GCC was a C++ compiler. :confused:
The difficult we do right away... ...the impossible takes slightly longer.
GCC = GNU compiler collection. Not GNU C compiler.
-
Marc Clifton wrote:
Because RoR is interpreted, it means that I don't have to recompile the app to see changes -- I can make changes to the model, controllers, and of course the views without having to restart the server. Makes development a breeze.
I'm about 70 coding hours into a RoR/AngularJS/Coffeescript project (all 3 new to me); and am finding about 2/3rds of my debug time is being spent on issues that a compiled/strongly typed language would've called me out on immediately; even ignoring that VS (or even Eclipse) >> Sublime my dev rate's a lot slower than on other platforms.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
Dan Neely wrote:
and am finding about 2/3rds of my debug time is being spent on issues that a compiled/strongly typed language would've called me out on immediately;
Absolutely. Duck-typing is a productivity-killer in my opinion. Type inference is another killer in an interpreted context. At least in F#, the IDE detects issues even before you compile the code, though it is possible to fool it. To help with that, what I do is the following: * I use very descriptive function names, variable names, and parameter names * I write very small functions that do just one thing * I comment every single function, describing the input and output types so I know how to use the function later on * I heavily comment the code * I refactor constantly -- as soon as I see some duplicate code, I refactor it into a single function * I step through every line of code (I tend to do that in C# as well, so it's not really a development hit) * I explicitly specify the return value, even if it's redundant. * Liberal use of white space. Notice I didn't say that I write tests or work in a TDD paradigm. The main reason is that it takes a while to fire up the unit tests, which is yet another hit on development time, not to mention writing the tests. Lastly, there's a lot of "idiomatic" Ruby which is really cool and sexy and geeky but is totally incomprehensible at first glance. I always refactor those into functions that explicitly state what's going on. The idea is that the high level code should tell me what it's doing, and the low level code tells me how it's doing it. Here's an example: How:
Given comma separated values in a string, returns an array of strings, stripping leading
and trailing whitespace.
def csv_to_array(csv)
array = csv.split(',').collect{|s| s.strip}arrayend
What:
Adds children (given in csv format) to an entity.
def add_children(entity, csv_children)
child_list = csv_to_array(csv_children)
entity.add_children(child_list, self.project_id)
endHope that helps! (And gee, I think I'm going to copy this reply and post it on my blog!) Marc
-
A more unixy environment, actually. Also has a ton of other useful packages for development.
Getting information off the Internet is like taking a drink from a fire hydrant. - Mitchell Kapor
-
Dan Neely wrote:
and am finding about 2/3rds of my debug time is being spent on issues that a compiled/strongly typed language would've called me out on immediately;
Absolutely. Duck-typing is a productivity-killer in my opinion. Type inference is another killer in an interpreted context. At least in F#, the IDE detects issues even before you compile the code, though it is possible to fool it. To help with that, what I do is the following: * I use very descriptive function names, variable names, and parameter names * I write very small functions that do just one thing * I comment every single function, describing the input and output types so I know how to use the function later on * I heavily comment the code * I refactor constantly -- as soon as I see some duplicate code, I refactor it into a single function * I step through every line of code (I tend to do that in C# as well, so it's not really a development hit) * I explicitly specify the return value, even if it's redundant. * Liberal use of white space. Notice I didn't say that I write tests or work in a TDD paradigm. The main reason is that it takes a while to fire up the unit tests, which is yet another hit on development time, not to mention writing the tests. Lastly, there's a lot of "idiomatic" Ruby which is really cool and sexy and geeky but is totally incomprehensible at first glance. I always refactor those into functions that explicitly state what's going on. The idea is that the high level code should tell me what it's doing, and the low level code tells me how it's doing it. Here's an example: How:
Given comma separated values in a string, returns an array of strings, stripping leading
and trailing whitespace.
def csv_to_array(csv)
array = csv.split(',').collect{|s| s.strip}arrayend
What:
Adds children (given in csv format) to an entity.
def add_children(entity, csv_children)
child_list = csv_to_array(csv_children)
entity.add_children(child_list, self.project_id)
endHope that helps! (And gee, I think I'm going to copy this reply and post it on my blog!) Marc
every time I've tried breaking most/all of my code into methods that small I found myself spending more time chasing up/down the call stack than anything else and with productivity even lower than when trying to wade though multi-hundred line method failure. I've never been a fan of test first coding; but enough tests to catch regression failures has always been something I've liked. The problem I'm having here, and why I started a thread about a ruby CI server, is people being sloppy about remembering to update tests when they did change something: Did you break it? Did merging your changes with mine break it? Did git hork up the auto merge badly? ... is my second biggest pain point on the project atm.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
every time I've tried breaking most/all of my code into methods that small I found myself spending more time chasing up/down the call stack than anything else and with productivity even lower than when trying to wade though multi-hundred line method failure. I've never been a fan of test first coding; but enough tests to catch regression failures has always been something I've liked. The problem I'm having here, and why I started a thread about a ruby CI server, is people being sloppy about remembering to update tests when they did change something: Did you break it? Did merging your changes with mine break it? Did git hork up the auto merge badly? ... is my second biggest pain point on the project atm.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
Dan Neely wrote:
when trying to wade though multi-hundred line method failure
Ugh, sounds like you've inherited some really bad code. I tend to find that myself, which has led me to develop my own "best practices" when writing Ruby code.
Dan Neely wrote:
Did git hork up the auto merge badly? ... is my second biggest pain point on the project atm.
Don't even get me started regarding Git. X| Marc
-
Dan Neely wrote:
when trying to wade though multi-hundred line method failure
Ugh, sounds like you've inherited some really bad code. I tend to find that myself, which has led me to develop my own "best practices" when writing Ruby code.
Dan Neely wrote:
Did git hork up the auto merge badly? ... is my second biggest pain point on the project atm.
Don't even get me started regarding Git. X| Marc
Marc Clifton wrote:
Dan Neely wrote:
when trying to wade though multi-hundred line method failure
Ugh, sounds like you've inherited some really bad code. I tend to find that myself, which has led me to develop my own "best practices" when writing Ruby code.
Yeah. The prototype, will be replaced once we figure out what it needs to do, excel/VBA code written by a very junior dev ended up lasting almost a decade in production before we could afford to rewrite it. And even there timing pressure meant we had to bring on a few devs who didn't have the domain knowledge needed to do anything other than literalport some modules from VBA to C#; and I'm probably 2 years from having enough time to finally finish refactoring the last into something minimally sane.
Marc Clifton wrote:
Dan Neely wrote:
Did git hork up the auto merge badly? ... is my second biggest pain point on the project atm.
Don't even get me started regarding Git. X|
...I think if I really got going I'd end up needing a Nagy's worth of gin, a Dalek's worth of beer, and MM's worth of rum, and a few bottles of Rodger's scotch before I finished; and probably a liver transplant too. :doh:
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
Marc Clifton wrote:
Dan Neely wrote:
when trying to wade though multi-hundred line method failure
Ugh, sounds like you've inherited some really bad code. I tend to find that myself, which has led me to develop my own "best practices" when writing Ruby code.
Yeah. The prototype, will be replaced once we figure out what it needs to do, excel/VBA code written by a very junior dev ended up lasting almost a decade in production before we could afford to rewrite it. And even there timing pressure meant we had to bring on a few devs who didn't have the domain knowledge needed to do anything other than literalport some modules from VBA to C#; and I'm probably 2 years from having enough time to finally finish refactoring the last into something minimally sane.
Marc Clifton wrote:
Dan Neely wrote:
Did git hork up the auto merge badly? ... is my second biggest pain point on the project atm.
Don't even get me started regarding Git. X|
...I think if I really got going I'd end up needing a Nagy's worth of gin, a Dalek's worth of beer, and MM's worth of rum, and a few bottles of Rodger's scotch before I finished; and probably a liver transplant too. :doh:
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
Dan Neely wrote:
...I think if I really got going I'd end up needing a Nagy's worth of gin, a Dalek's worth of beer, and MM's worth of rum, and a few bottles of Rodger's scotch before I finished; and probably a liver transplant too.
Oh, that is SO quotable! Probably would be easier re-writing Git to something that was usable. Oh wait, we have usable source control systems already! Marc
-
Dan Neely wrote:
...I think if I really got going I'd end up needing a Nagy's worth of gin, a Dalek's worth of beer, and MM's worth of rum, and a few bottles of Rodger's scotch before I finished; and probably a liver transplant too.
Oh, that is SO quotable! Probably would be easier re-writing Git to something that was usable. Oh wait, we have usable source control systems already! Marc
Marc Clifton wrote:
Probably would be easier re-writing Git to something that was usable. Oh wait, we have usable source control systems already!
Yup. At my employer git (instead of Hg) appears to've snowballed as the dvcs of choice for no other reason than it being the personal favorite of the first person to decide the risk of something without any corporate IT support was worth avoiding the performance misery of trying to use SVN over the VPN. :sigh: Ruby appears to've won out for buzzword compliant webdev for the same reason; and VS has just announced support for node.js too. :((
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
In my quest to learn Ruby on Rails, I am installing a Rails development environment using Msys2[^]. It contains all the base packages (other than Rails and its dependencies) I need, such as Ruby, a compiler toolchain (GCC), and various libraries and utilities. I can post a link to the system I set up here if people want (I will have to find a place to upload it first, as it is very, very large, almost a Gigabyte in size!)
Getting information off the Internet is like taking a drink from a fire hydrant. - Mitchell Kapor
-
Can you tell me, why you have decided to learn Ruby on Rails instead of ASP.net MVC ? :confused:
My Tech Blog : Sampath Lokuge Tech Blog Nothing is Impossible for Willing Heart.
I see someone's had a similar experience as I. Coming into Ruby-on-Rails (RoR) after working with Python/Django, and C# ASP.NET-MVC, my productivity really schlowed to a crawl with RoR. The duck-typing is one factor: I much, much prefer to just have things explicit within the code structure so I can know what's going on. C# catches most of the errors that RoR happily lets slide and condemns you to hours of guessing and troubleshooting. Another huge factor is - with RoR, things rarely actually work. It seems there's a wealth of online information that is incorrectly typed, or that just doesn't work as claimed. Things break with various versions, or are incompatible with, or there're way too many ways to accomplish the same thing. I came to the conclusion that the reason we see more online activity with RoR is: nothing's working, and everyone is still googling trying to find something that does! It is probable that I'd have had a better RoR experience had it been my very first development platform: I got so spoiled with C# and ASP.NET-MVC that RoR is a horror-show of incompatible, non-working madness. James Hurst
James Hurst "The greatness of a nation and its moral progress can be judged by the way its animals are treated."
Mahatma Gandhi
