I''m still relatively new to rails myself but have been using it now for about 6 weeks. I''ve read 3 rails books, performed thousands of google searches, saved everything important to my current work scope, and want to make it easier for those that come after me. If you are reading this then you probably already realize that it''s sometimes difficult to find information on certain topics. To make it easier to find things you need, please look below: **========= Direct Tutorials/Walkthroughs ==========** http://www.buildingwebapps.com/learningrails Summary: This is one of the best learning rails sites I''ve come across. Everything works with Rails 2.3.2 and both persons that teach on this site are very experienced with rails. I can personally attest to Christopher Haupt who has on numerous occassions, personally answered my emails to assist me with questions. The entire site is free and will walk you through creating a custom content management system from start to finish. In addition, it goes through a lot of core foundations and these guys are really good at explaning things. **========== SCREENCASTS ==========** http://railscasts.com/episodes/archive Summary: This is the home of Ryan Bates, a very masterful rails programmer that has created an extremely large archive of screencasts (all free) that take you through many core rails fundamentals (basic and advanced). Ryan is a great all around guy and will teach you things you never thought possible. **========== GUIDES ==========** http://guides.rubyonrails.org/ Summary: The often unnoticed guides are the ones perhaps the easiest to find, but people tend to miss them. The guides listed at rubyonrails.org are very informative and will teach you many nuances of rails. http://www.fortytwo.gr/ Summary: Another really good guides site is fortytwo. They house many informative articles and tips for rails that will help you when you feel a bit lost. **========== DATABASE ==========** http://databases.about.com/lr/database_normalization/24903/1/ Summary: Many people, including myself, forget to normalize their rails databases. Because rails works with a lot of associations, it is very important to first make sure your databases are normalized. Most people will agree that if you want to use relationships like HABTM, you need to normalize to a minimum of 3NF (3rd Normal Form). This site will showcase exactly how to normalize your database and is fairly easy to follow. **========== BOOKS ==========** Agile Web Development with Rails 3nd Edition Beta Foundation Rails 2 Enterprise Rails Summary: A lot of books are either out of date, or no longer workable with Rails 2.3.2. These books still are effective learning tools. Foundation Rails 2 teaches you things in order of importance. Agile Web is a very good read. Enterprise Rails is important because it gives you the database/model associations and how to use them effectively in your projects. ===================================== If anyone wants to add important links, tips, or other comments that might help someone new to Rails, please do so here. Thanks. -- Posted via http://www.ruby-forum.com/.
Thanks for this post. I too am coming into this new (except for a heavy Java background) and the onyl thing I would add to your list is this newsgroup. My personal goal here is to keep learning, hopefully, be able to answer other people''s questions on this newsgroup. -Janna B.
Testing Rails can be cumbersome but it''s also very necessary. You can hand-test all your code and do the greatest job possible but in the end, it won''t be enough. So, you should become familiar with a few testing platforms you can use with rails. By default, whenever you create anything new with rails 2.3.2, test files are automatically created for you. These tests, called Unit Tests are the very barebones basic test platform you can use with Rails. ** UNIT TESTS ** You can find information about Unit Tests here: http://guides.rubyonrails.org/testing.html ** RSPEC ** But, Unit Tests may not be enough for you and you will find that there are some more popular methods of testing available. One of the more common testing platforms is called Rspec. http://wiki.github.com/dchelimsky/rspec Screencast tutorial from Ryan http://railscasts.com/episodes/71-testing-controllers-with-rspec The tutorial screencast is a little old but it gives you an idea of how to test with rspec.. ** AUTOSPEC ** A lot of people refer to autotest and autotest became Autospec. Autospec is very simple to use (it''s also referred to as ZenTest, because of the gem name). You can also use Autospec with Rspec to add a more complete testing platform for rails: http://ph7spot.com/articles/getting_started_with_autotest http://www.nateclark.com/articles/2008/09/17/_autotest_-is-now-_autospec_-how-to-set-up-autospec-for-rspec-and-rails-with-zentest ** SHOULDA ** Another new kid on the block is Shoulda. It is actually a very interesting testing platform and it might not be as famous as RSpec but it''s really easy to use and I''m starting to lean towards using shoulda over rspec, personally. However, go with what platform you feel is best for "YOU"... http://wiki.github.com/thoughtbot/shoulda/rails http://wiki.rubyonrails.org/testing/shoulda http://thoughtbot.com/projects/shoulda/tutorial? Enjoy! -- Posted via http://www.ruby-forum.com/.
Älphä Blüë wrote: [...]> ** AUTOSPEC ** > > A lot of people refer to autotest and autotest became Autospec. > Autospec is very simple to use (it''s also referred to as ZenTest, > because of the gem name).Almost. AFAIK, autotest used to work with both Rails'' built-in tests and RSpec, but at some point the script was split. So now you use autospec for RSpec and autotest otherwise. Autospec and autotest are part of the ZenTest package, but ZenTest is more than just those scripts: it contains the logic necessary for autotest to do incremental testing. So it''s a bit of an oversimplification to say that autospec is referred to as ZenTest. [...]> ** SHOULDA ** > > Another new kid on the block is Shoulda. It is actually a very > interesting testing platform and it might not be as famous as RSpec but > it''s really easy to use and I''m starting to lean towards using shoulda > over rspec, personally.I''ve noticed a lot of people going this way. Why? What are Shoulda''s advantages over RSpec? I like what you''re doing with this thread, BTW! Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
> Almost. AFAIK, autotest used to work with both Rails'' built-in tests > and RSpec, but at some point the script was split. So now you use > autospec for RSpec and autotest otherwise. > > Autospec and autotest are part of the ZenTest package, but ZenTest is > more than just those scripts: it contains the logic necessary for > autotest to do incremental testing. So it''s a bit of an > oversimplification to say that autospec is referred to as ZenTest. >Thanks for the reply Marnen - great to see the differences between those two. I personally did not realize this.>> ** SHOULDA ** >> >> Another new kid on the block is Shoulda. It is actually a very >> interesting testing platform and it might not be as famous as RSpec but >> it''s really easy to use and I''m starting to lean towards using shoulda >> over rspec, personally. > > I''ve noticed a lot of people going this way. Why? What are Shoulda''s > advantages over RSpec?I''ll set aside some links that would do a better job at explaning the pros/cons or the opinionated versus arguments between the two. Please note that I like Rspec and I also like Shoulda. I haven''t gained enough knowledge of both to reply with my own opinions unfortunately. My attempt was to bring more of an awareness to the different testing platforms out there and allow others to make their own educated guess as to which one works well for them. Rspec vs. Shoulda http://kylebanker.com/blog/2008/08/from-rspec-to-shoulda/ http://www.vimeo.com/3296561 -- Posted via http://www.ruby-forum.com/.
Today''s post revolves around communication and SME appreciation. SME''s are Subject Matter Experts and every language or platform discussion groups have them. These are generally people that have a great deal of experience and house a wealth of knowledge that they share with others in the community. There are numerous SMEs that assist with answering questions by the minute and it would do well to thank them and be appreciative of their help. However, how do you communicate your topic and readily obtain answers from different SMEs? =====================**-------**: Rule One: ===================== Make certain that your topic is descriptive enough to highlight your issue. Having trouble with queries or models - simply say so. Example of a bad topic thread: "I''m having trouble, please help" -- this doesn''t describe anything and your topic might be avoided. Example of a good topic thread: "Need assistance with model/query issue" -- this describes the problem as being related to models/queries. =====================**-------**: Rule Two: ===================== Make certain that your topic contains all of the pertinent information surrounding your issue. More information is always better than less information. If you were having a model/query issue you would want to post a general idea of what both your controller method initiating the query looks like, and the model method being called looks like. You would also want to make sure you tested that query in a console so you could see what the output is. Supplying these three things would make it much easier for someone to assist with a model/query issue for instance. =======================**-------**: Rule Three: ======================= Always make sure you try the simple things first before posting on an issue. A lot of issues stem from a simple restart of a server because some changes never took effect. Make sure your syntax looks appropriate in the editor you are using. Make sure you at the very minimum try to test or debug the code in the console. Doing this will make it easier when adding information to your topic. ========================Lastly, Thank the people that helped you resolve your issue. Patience, understanding, reflection on the way a person helps you and your end response goes a long way. These SMEs are giving their own volunteer time and knowledge to help you. Make sure you show them the respect they deserve. =================================================Channels and Communication Forums / MIRC: ================================================= http://www.ruby-forum.com http://railsforum.com Start here to choose the forum that best describes your needs. Ruby on Rails is my choice each and every day. Mirc Channels: Ruby Language: #ruby-lang on the irc.freenode.net server Ruby on Rails: #rubyonrails on the irc.freenode.net server There are a lot of people on the ruby on rails channel. There are a great many SMEs there that assist by the second. Please be patient when asking for help on IRC. If you need help with IRC chat and you need some code looked at, make sure you go to Pastie.org before asking for help: http://pastie.org/ You can put all of your code that needs help with on here and it will give you a nice neat link. You can link that into IRC chat and anyone can see the code and assist you. It''s also properly formatted automatically for you! -- Posted via http://www.ruby-forum.com/.
Just a few more comments and nitpicks, in the hope of keeping this thread as useful as possible... Älphä Blüë wrote: [...]> > There are numerous SMEs that assist with answering questions by the > minute and it would do well to thank them and be appreciative of their > help.Indeed. (I think Frederick Cheung may very well be superhuman...)> > However, how do you communicate your topic and readily obtain answers > from different SMEs? > > =====================> **-------**: Rule One: > =====================> > Make certain that your topic is descriptive enough to highlight your > issue. Having trouble with queries or models - simply say so. > > Example of a bad topic thread: > > "I''m having trouble, please help" > > -- this doesn''t describe anything and your topic might be avoided. > > Example of a good topic thread: > > "Need assistance with model/query issue"Thank you, thank you, thank you! I recently saw a subject line that was something like "Rails problem" -- which, when you think about it, probably describes 2/3 of the posts on this list, so it''s not terribly helpful. :) I *do* think that your "good" subject could be made even a bit more specific, but it''s a great place to start. [...]> =================================================> Channels and Communication Forums / MIRC:The chat medium is called IRC. mIRC is the name of one client program. [...]> If you need help with IRC chat and you need some code looked at, make > sure you go to Pastie.org before asking for help: > > http://pastie.org/Great idea -- although Gist ( http://gist.github.com ) might be even better than Pastie. Again, thanks for taking the time to write all this! Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
So yes, it''s important to write your topic with something specific and interesting so that the experts want to read and help. But with some luck, you''ll still get views with a poorly written topic. There''s a better (in my opinion) reason to be specific -- to help the people who have the same issue tomorrow. I try to write a topic such that if it had already existed (started by someone else last year, for example) my google searches would have revealed this based on title alone. In light of that, something along the lines of "How can I make Model.find use a SQL WHERE clause?" is even better than "Need assistance with model/query issue" (possibly you agree and were just trying to keep the example generic). Sometimes if I''m not familiar with terminology I''m tempted to be vague, but think of it this way: if I''m specific and inaccurate, hopefully someone corrects me. Maybe my problem is well understood, and I just didn''t know how to search for it. The next person who is equally confused benefits from my specific topic title. On Jul 13, 10:17 am, "Älphä Blüë" <rails-mailing-l...@andreas-s.net> wrote:> Example of a bad topic thread: > > "I''m having trouble, please help" > > -- this doesn''t describe anything and your topic might be avoided. > > Example of a good topic thread: > > "Need assistance with model/query issue" > > -- this describes the problem as being related to models/queries.This is a great thread, by the way! I''ve been using primarily: Programming Ruby: The Pragmatic Programmer''s Guide for a solid understanding of the language, Agile Web Development with Rails, and the guides at rubyonrails.org. I''ll try out some of your other suggestions tonight. Found anything good on Rails + Ajax yet? I can''t decide whether to order Scott Raymond''s book or not since the abstract seems to indicate I can learn the same things reading script.aculo.us reference material.
Don''t forget the official Rails Wiki - http://wiki.rubyonrails.org. Lots of good info there. On Jul 13, 2:09 pm, Brian <butler.bria...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> So yes, it''s important to write your topic with something specific and > interesting so that the experts want to read and help. But with some > luck, you''ll still get views with a poorly written topic. There''s a > better (in my opinion) reason to be specific -- to help the people who > have the same issue tomorrow. I try to write a topic such that if it > had already existed (started by someone else last year, for example) > my google searches would have revealed this based on title alone. In > light of that, something along the lines of "How can I make Model.find > use a SQL WHERE clause?" is even better than "Need assistance with > model/query issue" (possibly you agree and were just trying to keep > the example generic). > > Sometimes if I''m not familiar with terminology I''m tempted to be > vague, but think of it this way: if I''m specific and inaccurate, > hopefully someone corrects me. Maybe my problem is well understood, > and I just didn''t know how to search for it. The next person who is > equally confused benefits from my specific topic title. > > On Jul 13, 10:17 am, "Älphä Blüë" <rails-mailing-l...@andreas-s.net> > wrote: > > > Example of a bad topic thread: > > > "I''m having trouble, please help" > > > -- this doesn''t describe anything and your topic might be avoided. > > > Example of a good topic thread: > > > "Need assistance with model/query issue" > > > -- this describes the problem as being related to models/queries. > > This is a great thread, by the way! I''ve been using primarily: > Programming Ruby: The Pragmatic Programmer''s Guide for a solid > understanding of the language, Agile Web Development with Rails, and > the guides at rubyonrails.org. I''ll try out some of your other > suggestions tonight. Found anything good on Rails + Ajax yet? I > can''t decide whether to order Scott Raymond''s book or not since the > abstract seems to indicate I can learn the same things reading > script.aculo.us reference material.
> Found anything good on Rails + Ajax yet? I > can''t decide whether to order Scott Raymond''s book or not since the > abstract seems to indicate I can learn the same things reading > script.aculo.us reference material.Well, I''m really glad you asked this particular question. I''m still going through a ton of resources on ajax/rails. So, what I find wonderful about rails is that rails + ajax is like having a perfect marriage. They work so well with each other, it''s wonderful to implement both in a project. By default, rails uses prototype and scriptaculous but I''m looking into jQuery at the moment. jQuery seems to be really solid. Here''s a link which will "create" an up-to-date trend chart when you click on it using google trends: http://www.google.com/trends?q=jQuery%2CPrototype+ajax%2Cscriptaculous%2Cmootools%2Cdojo&ctab=0&geo=all&date=all&sort=0 jQuery Prototype Scriptaculous Mootools Dojo You also have jMaki but that uses jQuery, but jMaki also has great support in certain IDE environments like netbeans. But, IDEs are another subject altogether. If you notice by the trends chart, jQuery is heavily on the rise. -- Posted via http://www.ruby-forum.com/.
To add another book to the three initially mentioned ( which are all very good ! ) Ruby on Rails Bible ( released late last year ! ) http://www.amazon.com/Ruby-Rails-Bible-Timothy-Fisher/dp/0470258225 http://www.rubyonrailsbible.com/ cheers, Dave Porter On Jul 14, 4:44 am, "Älphä Blüë" <rails-mailing-l...-ARtvInVfO7m5VldFQK4jKA@public.gmane.orgt> wrote:> > Found anything good on Rails + Ajax yet? I > > can''t decide whether to order Scott Raymond''s book or not since the > > abstract seems to indicate I can learn the same things reading > > script.aculo.us reference material. > > Well, I''m really glad you asked this particular question. I''m still > going through a ton of resources on ajax/rails. > > So, what I find wonderful about rails is that rails + ajax is like > having a perfect marriage. They work so well with each other, it''s > wonderful to implement both in a project. By default, rails uses > prototype and scriptaculous but I''m looking into jQuery at the moment. > > jQuery seems to be really solid. > > Here''s a link which will "create" an up-to-date trend chart when you > click on it using google trends: > > http://www.google.com/trends?q=jQuery%2CPrototype+ajax%2Cscriptaculou... > > jQuery > Prototype > Scriptaculous > Mootools > Dojo > > You also have jMaki but that uses jQuery, but jMaki also has great > support in certain IDE environments like netbeans. But, IDEs are > another subject altogether. > > If you notice by the trends chart, jQuery is heavily on the rise. > > -- > Posted viahttp://www.ruby-forum.com/.
== Tutorial Injection #1 = Normally I would just pass some links but at times it''s a little refreshing to add some very simple tutorials that many people ask about. This tutorial is about RESTful routing and mapping resources. === RESTful Routing and Mapping Resources (advanced) == By default, whenever you create a scaffold, 7 methods are automatically created for you. These are index, new, edit, show, update, create, and destroy. In order to map all paths to these resources a simple map resources line is automatically created for you in your routes.rb file using the pluralized name of the controller. E.g. scaffold name product produces a controller called products map.resources :products This one little line now maps all of your RESTful resources for this controller. However, what if you had something like this? E.g. scaffold name users_allowed produces a controller called users_alloweds Now you wouldn''t want people to see http://yourdomain.com/users_alloweds would you? That would look very strange or peculiar. So, you can do something as simple as this: map.resources :users_alloweds, :as => ''users_allowed'' Now your url will look like http://yourdomain.com/users_allowed which is a little better. But, what if you want to group certain resources by a particular category. Say for instance you want to group this particular url in a category called members. Well, you can use a nifty prefix command: map.resources :users_alloweds, :as => ''users_allowed'', :path_prefix => ''members'' Now your url will look like http://yourdomain.com/members/users_allowed which gives you a nice category grouping and a singular path name. And, lastly, for this very simple tutorial, what if you wanted to take this further and just allow only the index method/view to be accessed and the rest of the resources not. A simple way: map.resources :users_alloweds, :as => ''users_allowed'', :only => ''index'', :path_prefix => ''members'' (acceptable) http://yourdomain.com/members/users_allowed/ (not allowed) http://yourdomain.com/members/users_allowed/*anything =================================== If you need to understand more about routing, please visit: http://guides.rubyonrails.org/routing.html -- Posted via http://www.ruby-forum.com/.
=====Ruby and Ruby on Rails==== Perhaps I neglected to open with a proper introduction to Ruby and Ruby on Rails. Therefore, I feel it''s appropriate to separate and explain the two in a very minimalist format. ==What is Ruby?= Ruby is a programming "language". It is the very backbone upon which rails was built. Understanding Ruby is, IMHO, more important than understanding Rails. Without a proper understanding of the core programming language that Rails itself is built upon, many trivial things can become complicated things. This is why it''s important to remember to read up on your Ruby programming language resources. There is a wealth of knowledge all around the web for Ruby. http://www.ruby-lang.org/en/ http://www.ruby-forum.com/forum/4 ==What is Rails?= Rails is a "platform". It is easy to confuse and mistake apples for oranges but Rails is "not" a programming language. It is a development "platform". It is also still a very young platform, roughly 5 years old. It was released as open source in July 2004. ==Making proper comparisons= When performing research, please make sure you compare apples to apples and not apples to oranges. For instance: PHP vs. Ruby on Rails (incorrect) -- PHP is a language and Ruby on Rails is a platform You can compare various "platforms" that PHP might use to Rails, but you can''t compare a language to a platform. Many people make this mistake. -- Posted via http://www.ruby-forum.com/.
And, correcting my own self,.. It might be better to say that Rails is a "framework".. :) .. or more precisely, a web application framework.. Ruby = language Rails = framework -- Posted via http://www.ruby-forum.com/.
===== GitHub ====http://github.com http://github.com/guides/home Github is a great place to host your project(s) while you develop. You can get a free subscription but your projects will be public and open source (viewable to everyone) or you can get a paid subscription (costs very little) and have a large storage area, multiple repositories and you can keep your work private. Github can be used to commit/add new changes while you work on your project, much like subversion. This allows you to track changes and because it''s hosted online, you can add authors and other members to work on projects with you, if desired. Github, along with Capistrano, can be used to help you with migrations and updates from development to production phases. Develop on your own machine, commit changes to Github and further commit changes to your server. It''s seamless and once working, very smooth and efficient. The only drawback is there is a bit of a learning curve with Github and if you develop on windows, an even bigger learning curve exists. Check out the guides for more information. ----- Building a Repository and Uploading Your Project ----- 1. Signup and register your account in Github 2. Download/install the latest Git release ----- For windows this is http://code.google.com/p/msysgit/downloads/list 2a. See the guides section if you use linux or mac. 3. Configure your SSH key for git by opening git bash and typing: ssh-keygen -C "your-zuv13RyHHZkAvxtiuMwx3w@public.gmane.org" -t rsa 4. Configure your profile by typing: git config --global user.name "Your Name" git config --global user.email Youremail-9IKiO1iGCm/QT0dZR+AlfA@public.gmane.org 5. Make your rails project directory or go to an existing rails project. 6. Right-click (if windows) and Git Bash Here. 7. Type "git init" to configure git inside your project directory. 8. Type "touch README" and enter. 9. Type "git add README" and enter. 10. Type "git commit -m ''first commit''" and enter 11. Type the following command to set your origin: git remote add origin git-9UaJU3cA/F/QT0dZR+AlfA@public.gmane.org:username/YourProjectName.git 12. Type "git push origin master" to push the readme file to your repository. ----- Updating any new changes ----- This is where at times it can get confusing. Several times you might encounter errors when trying to push to origin. Here''s a pretty fail safe way of doing it. If anyone else would like to add to this or change it, please feel free. 1. Modify your rails project, add new code, etc. 2. git bash here at your project directory. 3. Type "git pull origin master" and enter. 4. Type "git add . " and enter. (yes that is a period) 5. Type "git commit -m ''some message describing your changes'' and enter. 6. Type "git push origin master" and enter. ======== Now if you go to your git repository online you will see all the changes and notes. There is a lot more that you can do with Git and I''m just touching on the basics and hoping to help anyone who has trouble getting an initial repository going. Take care. -- Posted via http://www.ruby-forum.com/.
Perhaps worth mentioning what git is: a distributed version control system. So, independent of github, software version control is an important practice. On Jul 14, 2009, at 5:35 PM, Älphä Blüë wrote:> > ===== GitHub ====> http://github.com > http://github.com/guides/home > > Github is a great place to host your project(s) while you develop. > > You can get a free subscription but your projects will be public and > open source (viewable to everyone) or you can get a paid subscription > (costs very little) and have a large storage area, multiple > repositories > and you can keep your work private. > > Github can be used to commit/add new changes while you work on your > project, much like subversion. This allows you to track changes and > because it''s hosted online, you can add authors and other members to > work on projects with you, if desired. > > Github, along with Capistrano, can be used to help you with migrations > and updates from development to production phases. Develop on your > own > machine, commit changes to Github and further commit changes to your > server. It''s seamless and once working, very smooth and efficient. > > The only drawback is there is a bit of a learning curve with Github > and > if you develop on windows, an even bigger learning curve exists. > Check > out the guides for more information. > > ----- Building a Repository and Uploading Your Project ----- > 1. Signup and register your account in Github > 2. Download/install the latest Git release > ----- For windows this is > http://code.google.com/p/msysgit/downloads/list > 2a. See the guides section if you use linux or mac. > 3. Configure your SSH key for git by opening git bash and typing: > ssh-keygen -C "your-zuv13RyHHZkAvxtiuMwx3w@public.gmane.org" -t rsa > 4. Configure your profile by typing: > git config --global user.name "Your Name" > git config --global user.email Youremail-9IKiO1iGCm/QT0dZR+AlfA@public.gmane.org > 5. Make your rails project directory or go to an existing rails > project. > 6. Right-click (if windows) and Git Bash Here. > 7. Type "git init" to configure git inside your project directory. > 8. Type "touch README" and enter. > 9. Type "git add README" and enter. > 10. Type "git commit -m ''first commit''" and enter > 11. Type the following command to set your origin: > git remote add origin git-9UaJU3cA/F/QT0dZR+AlfA@public.gmane.org:username/YourProjectName.git > 12. Type "git push origin master" to push the readme file to your > repository. > > ----- Updating any new changes ----- > > This is where at times it can get confusing. Several times you might > encounter errors when trying to push to origin. Here''s a pretty fail > safe way of doing it. If anyone else would like to add to this or > change it, please feel free. > > 1. Modify your rails project, add new code, etc. > 2. git bash here at your project directory. > 3. Type "git pull origin master" and enter. > 4. Type "git add . " and enter. > (yes that is a period) > 5. Type "git commit -m ''some message describing your changes'' and > enter. > 6. Type "git push origin master" and enter. > > ========> > Now if you go to your git repository online you will see all the > changes > and notes. There is a lot more that you can do with Git and I''m just > touching on the basics and hoping to help anyone who has trouble > getting > an initial repository going. > > Take care. > -- > Posted via http://www.ruby-forum.com/. > > >
9 Resources for New Ruby on Rails Developers: http://charlesmaxwood.com/9-resources-for-new-ruby-on-rails-developers/ Cheers, Sazima On Jul 9, 4:59 pm, JannaB <mistressja...-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org> wrote:> Thanks for this post. I too am coming into this new (except for a > heavy Java background) and the onyl thing I would add to your list is > this newsgroup. My personal goal here is to keep learning, hopefully, > be able to answer other people''s questions on this newsgroup. -Janna B.
Sazima wrote:> 9 Resources for New Ruby on Rails Developers: > > http://charlesmaxwood.com/9-resources-for-new-ruby-on-rails-developers/ > > Cheers, SazimaNice - bookmarked. -- Posted via http://www.ruby-forum.com/.
=================================================Ruby Platforms, Rails Versions, and Other Notables ================================================= With any language, there are always multiple versions (platforms) that you can use. Ruby is no different when it comes to this. In addition, there are specific OS (Operaing System) distributions for those platforms. Installation of each platform type, based on the OS type can be entirely different and at times confusing. Rails also houses many different versions and each one has specific nuances versus the other. So, trying to find a good combination of the two for your development/testing/production projects can be a bit difficult, considering how much information we become inundated with over the course of documentation and help searches. Here is a solid rule of thumb: Don''t upgrade Ruby platforms OR Rails versions for (production). Don''t ever do it unless you enjoy some amount of pain, hardship, and reaching for Tylenol and Motrin. Conrad Taylor offered me some great advice when I thought about doing the former. I''m going to add these thoughts because they do help: Ruby/Rails platform upgrades: 1. Download and Install your Ruby version upgrade for non-production purposes only. 2. Optionally install any relevant gems or write a Ruby/Bash script to switch between the different implemented platforms. 3. Read the README file and execute any tests of the gem(s) you need for your Rails application against any of the relevant Ruby implementations. 4. Test against the new implementations. 5. You now have a test harnass in place for your rails application. -- Posted via http://www.ruby-forum.com/.
Älphä Blüë wrote:> =================================================> Ruby Platforms, Rails Versions, and Other Notables > =================================================> > Ruby/Rails platform upgrades: > > 1. Download and Install your Ruby version upgrade for non-production > purposes only. > 2. Optionally install any relevant gems or write a Ruby/Bash script to > switch between the different implemented platforms. > 3. Read the README file and execute any tests of the gem(s) you need > for your Rails application against any of the relevant Ruby > implementations. > 4. Test against the new implementations. > 5. You now have a test harnass in place for your rails application.Or adopt some sort of virtualization technology, like VMware. I run an Ubuntu virtual machine for my Rails development. When it was time to test out migrating Ruby and Rails to newer versions, I cloned the existing VM, and upgraded the clone, then pulled in the application from the source repository. Parallel environments with few headaches, and allows straight up comparative testing. -- Posted via http://www.ruby-forum.com/.
On Thu, 2009-07-23 at 18:38 +0200, Ar Chron wrote:> Älphä Blüë wrote: > > =================================================> > Ruby Platforms, Rails Versions, and Other Notables > > =================================================> > > > Ruby/Rails platform upgrades: > > > > 1. Download and Install your Ruby version upgrade for non-production > > purposes only. > > 2. Optionally install any relevant gems or write a Ruby/Bash script to > > switch between the different implemented platforms. > > 3. Read the README file and execute any tests of the gem(s) you need > > for your Rails application against any of the relevant Ruby > > implementations. > > 4. Test against the new implementations. > > 5. You now have a test harnass in place for your rails application. > > Or adopt some sort of virtualization technology, like VMware. > > I run an Ubuntu virtual machine for my Rails development. When it was > time to test out migrating Ruby and Rails to newer versions, I cloned > the existing VM, and upgraded the clone, then pulled in the application > from the source repository. Parallel environments with few headaches, > and allows straight up comparative testing.I, too, have moved to running Windows VMs inside VMware on Ubuntu. Works like a champ, but if VMware is not in your budget, Before that, I used InstantRails for the same purpose. Same results.
=============================Rescue and Redirects ============================= There are a lot of times that you''ll find when you perform a query on your database that no records are found. Some people that are new to rails might do something like: if model.find(:all).empty? .. do something else else .. continue with our program .. end But, this doesn''t really help you when you have a very extensive routine. It also doesn''t really handle ActiveRecord returns or even logging the errors to your logs. This is where rescue is a great feature that rails has implemented into it. How do you use it? Here''s an example: def get_products(product_id) begin @products = Product.find(product_id) rescue ActiveRecord::RecordNotFound logger.error("#{product_id} in products wasn''t found from get_products." redirect_to :action => :index else .. continue with your routine end end So, what did we do here? Pretty simple when you look deeply at it. We have a routine that tries to find a product by a product_id. Rescue occurs if no record is found from ActiveRecord and a logger error is placed in your log telling you what occurred, so you can later review and fix (if it needs fixing) the error. It then redirects your user back to the index (or you can specify some other redirect (redirect_to root_url OR redirect_to controllername_path, etc.). If the rescue doesn''t occur, the method continues on and processes your routine. By using rescue you don''t have to interfere greatly with your model''s core methods. Adding too much logic to your model methods might not be a good thing. There are times when it might be necessary (methods that involve rake tasks etc. come to mind) but overall, rescue is something everyone new to rails should learn and implement into their apps. I hope this helps. Thanks. -- Posted via http://www.ruby-forum.com/.
Alpha Blue wrote: [...]> This is where rescue is a great feature that rails has implemented into > it.Actually, it''s a basic Ruby feature.> How do you use it? Here''s an example: > > def get_products(product_id) > begin > @products = Product.find(product_id) > rescue ActiveRecord::RecordNotFound > logger.error("#{product_id} in products wasn''t found from > get_products." > redirect_to :action => :index > else > .. continue with your routine > end > endIn most cases, this would not be worth logging. Even if it is, exception handling may not be the best way to do it. (Also, the method is badly named, since it will only ever get one product.) [...]> By using rescue you don''t have to interfere greatly with your model''s > core methods. Adding too much logic to your model methods might not be > a good thing.Um, WTF? That''s where logic is supposed to go. Exception handling supplements that logic; it doesn''t replace it. There are times when it might be necessary (methods that> involve rake tasks etc. come to mind) but overall, rescue is something > everyone new to rails should learn and implement into their apps. > > I hope this helps.Many developers (including me!) perhaps don''t use exceptions quite as often as they should, but I am afraid that you are encouraging the opposite extreme -- a style of programming where exceptions are used for everything. I understand that this is not a great idea for a number of reasons: it is said to be inefficient and hard to follow and test.> > Thanks.Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
Marnen Laibow-Koser wrote:> Um, WTF? That''s where logic is supposed to go. Exception handling > supplements that logic; it doesn''t replace it. > There are times when it might be necessary (methods that >> involve rake tasks etc. come to mind) but overall, rescue is something >> everyone new to rails should learn and implement into their apps. >>I didn''t use the right wording here. What I meant was there are different types of logic to use with your model. In otherwords, for every method created there are probably 3 people that will do them completely different but achieve the same result. Remember for loops? Which logic is better to do in the model? A for loop or an each loop? Which is better practice? This is what I was after. You can go to an extreme on one thing and never use the simpler approaches.> Many developers (including me!) perhaps don''t use exceptions quite as > often as they should, but I am afraid that you are encouraging the > opposite extreme -- a style of programming where exceptions are used for > everything. I understand that this is not a great idea for a number of > reasons: it is said to be inefficient and hard to follow and test. >I''m not sure I follow you completely on this particular response. Are you saying that rescue is a bad thing when you need a routine to continue moving forward? Or, are you saying that there''s another way (besides rescue) that should be used to do the same thing? I like rescue. I don''t use it for everything but there are some core areas in my app that I do use it. -- Posted via http://www.ruby-forum.com/.
Hello-- On Aug 3, 2009, at 12:50 PM, Alpha Blue wrote:> > Marnen Laibow-Koser wrote: >> Um, WTF? That''s where logic is supposed to go. Exception handling >> supplements that logic; it doesn''t replace it. >> There are times when it might be necessary (methods that >>> involve rake tasks etc. come to mind) but overall, rescue is >>> something >>> everyone new to rails should learn and implement into their apps. >>> > > I didn''t use the right wording here. What I meant was there are > different types of logic to use with your model. In otherwords, for > every method created there are probably 3 people that will do them > completely different but achieve the same result. > > Remember for loops? Which logic is better to do in the model? A for > loop or an each loop? Which is better practice? This is what I was > after. You can go to an extreme on one thing and never use the > simpler > approaches. > >> Many developers (including me!) perhaps don''t use exceptions quite as >> often as they should, but I am afraid that you are encouraging the >> opposite extreme -- a style of programming where exceptions are >> used for >> everything. I understand that this is not a great idea for a >> number of >> reasons: it is said to be inefficient and hard to follow and test. >> > > I''m not sure I follow you completely on this particular response. Are > you saying that rescue is a bad thing when you need a routine to > continue moving forward? Or, are you saying that there''s another way > (besides rescue) that should be used to do the same thing? I like > rescue. I don''t use it for everything but there are some core areas > in > my app that I do use it. >I bring a fair amount of dated knowledge to this -- the "why not use exception handling for everything" answers from the days of C++ and the like. I learned to steer clear of exception handling in cases where I could fairly predict an outcome. Ruby may have a slick implementation of exception handling and certainly does not have the baggage of unwinding through destructors that C++ had, but an exception is a non-local jump, not to be confused with scope exit caused by a flow of control structure. That means someplace things like multiple scopes need to be recognized so stale objects can be marked for garbage collection, etc. Additionally, in the presence of a begin/rescue block, when an exception occurs, the interpreter has to look for the closest scoped exception handling block that declares itself as handling the specific type or generic superset of the exception in question. This means maintaining an ordered searchable list of these scoped blocks, thus taking up memory for a case which is supposed to never happen, right? So here''s my way of deciding whether to use exceptions. I ask the questions: "Is the result of this operation predictable?" If yes, then I test for it, and don''t use exceptions. "If this operation fails, is there anything I can do about it?" If the answer is no, then I let Rails'' rescue_action_in_public take care of things for me and get my exception_notification email. Then I fix the bug. "If this operation fails and there is it important and something I can fix programatically (e.g., would financial data be corrupted or something equally disasterous and will I have information to mitigate the damage)?" If the answer is yes, then I''ll use a begin/rescue block. All of this said, there is a reason exception handling is in the language, but it''s not (IMO) the one you cite. Exception handling is made to wrap very important operations that simply can''t fail without at least an honest retry strategy. You know, like "user stepped on anti-lock brake pedal and braking computer raised an exception." What exceptions were not specifically designed for was to facilitate non- local jumps out of scope. I know there will be disagreement on what I''ve said here, so I must re- emphasize that my habits with respect to use of exception handling are based on avoidance rooted in a pretty dated technology, C++. Additionally, this is something of a religious issue, where you either hate exceptions to the extreme or see no harm in them and use them liberally. I''ve put my opinion out here in hopes it will be useful.