You''ve probably heard the phrase before... maybe even used it. What I want to know is what does it mean to you? What should a professional rails programmer know? I''m going to spend the next 6 months learn Rails in depth and I want to prioritize what I learn. Here are some things that have come to mind so far that I want to learn: * Shopping Cart + Checkout * Substruct * Subversion * Capistrano * Attachment_fu * Caching o MemCache o Page Caching o Fragment Caching * ActiveMerchant * Acts as paranoid * RSpec * Git * Action Mailer * RJS o Prototype o Effects o Scriptaculous * subdomains as account + payment plans * SSL * Acts as taggable * Authentication o Restful Authentication o Role-based authentication o Open ID authentication * Testing o Unit o Functional * Design o Lightbox helper o Redbox o Creating helpers * Flex + Rails * Flash Charts * RMagick * Liquid * GeoKit * Google Maps * Restful Development Anything I miss? For those that consider themselves pros at Rails, what do you know that makes you valuable? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Honestly, most of that is stuff that''s too specific. You need to spend more time understanding concepts instead of libraries. What powers a shopping cart? Is RMagick the best solution? How do you tell? How do acts_as_paranoid or ActiveMerchant work? These are the things you need to focus on because they will make you a better developer instead of a better Rails user. To pare down your list: * Subversion * Capistrano * Attachment_fu * Caching * RSpec * Git * Action Mailer * RJS * jQuery * SSL * Authentication * Testing * Restful Development To that I would probably add a lot of things about how the web works, how to profile Ruby, and a ton of Ruby education. --Jeremy On Feb 3, 2008 10:49 PM, mel ram <melvin-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote:> > You''ve probably heard the phrase before... maybe even used it. What I > want to know is what does it mean to you? What should a professional > rails programmer know? I''m going to spend the next 6 months learn > Rails in depth and I want to prioritize what I learn. > > Here are some things that have come to mind so far that I want to > learn: > > * Shopping Cart + Checkout > * Substruct > * Subversion > * Capistrano > * Attachment_fu > * Caching > o MemCache > o Page Caching > o Fragment Caching > * ActiveMerchant > * Acts as paranoid > * RSpec > * Git > * Action Mailer > * RJS > o Prototype > o Effects > o Scriptaculous > * subdomains as account + payment plans > * SSL > * Acts as taggable > * Authentication > o Restful Authentication > o Role-based authentication > o Open ID authentication > * Testing > o Unit > o Functional > * Design > o Lightbox helper > o Redbox > o Creating helpers > * Flex + Rails > * Flash Charts > * RMagick > * Liquid > * GeoKit > * Google Maps > * Restful Development > > Anything I miss? For those that consider themselves pros at Rails, > what do you know that makes you valuable? > > >-- http://www.jeremymcanally.com/ My books: Ruby in Practice http://www.manning.com/mcanally/ My free Ruby e-book http://www.humblelittlerubybook.com/ My blogs: http://www.mrneighborly.com/ http://www.rubyinpractice.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Specifics is what I am asking for. What things (plugins/technologies/ methods/etc) does a pro rails developer use often to build real world apps? It will differ based on projects you are involved with... but if various people answer with specific things they need to do their build their apps, I''ll get a good idea of what I should know to build the apps I want to build. BTW, Thanks for adding jQuery to the list. I''ll look into what that is. On Feb 3, 7:54 pm, "Jeremy McAnally" <jeremymcana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Honestly, most of that is stuff that''s too specific. You need to > spend more time understanding concepts instead of libraries. What > powers a shopping cart? Is RMagick the best solution? How do you > tell? How do acts_as_paranoid or ActiveMerchant work? These are the > things you need to focus on because they will make you a better > developer instead of a better Rails user. > > To pare down your list: > > * Subversion > * Capistrano > * Attachment_fu > * Caching > * RSpec > * Git > * Action Mailer > * RJS > * jQuery > * SSL > * Authentication > * Testing > * Restful Development > > To that I would probably add a lot of things about how the web works, > how to profile Ruby, and a ton of Ruby education. > > --Jeremy > > On Feb 3, 2008 10:49 PM, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > > > > You''ve probably heard the phrase before... maybe even used it. What I > > want to know is what does it mean to you? What should a professional > > rails programmer know? I''m going to spend the next 6 months learn > > Rails in depth and I want to prioritize what I learn. > > > Here are some things that have come to mind so far that I want to > > learn: > > > * Shopping Cart + Checkout > > * Substruct > > * Subversion > > * Capistrano > > * Attachment_fu > > * Caching > > o MemCache > > o Page Caching > > o Fragment Caching > > * ActiveMerchant > > * Acts as paranoid > > * RSpec > > * Git > > * Action Mailer > > * RJS > > o Prototype > > o Effects > > o Scriptaculous > > * subdomains as account + payment plans > > * SSL > > * Acts as taggable > > * Authentication > > o Restful Authentication > > o Role-based authentication > > o Open ID authentication > > * Testing > > o Unit > > o Functional > > * Design > > o Lightbox helper > > o Redbox > > o Creating helpers > > * Flex + Rails > > * Flash Charts > > * RMagick > > * Liquid > > * GeoKit > > * Google Maps > > * Restful Development > > > Anything I miss? For those that consider themselves pros at Rails, > > what do you know that makes you valuable? > > --http://www.jeremymcanally.com/ > > My books: > Ruby in Practicehttp://www.manning.com/mcanally/ > > My free Ruby e-bookhttp://www.humblelittlerubybook.com/ > > My blogs:http://www.mrneighborly.com/http://www.rubyinpractice.com/--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Mel, An old school professor of mine once said: "We don''t teach you how to use tools, we teach you how to reason"! I fully agree with Jeremy. Focus on learning the basics, the concepts, the core of Ruby and RoR. The rest will come easy after that. After all, tools change... Cheers, Sazima On Feb 4, 2:06 am, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote:> Specifics is what I am asking for. What things (plugins/technologies/ > methods/etc) does a pro rails developer use often to build real world > apps? It will differ based on projects you are involved with... but if > various people answer with specific things they need to do their build > their apps, I''ll get a good idea of what I should know to build the > apps I want to build. > > BTW, Thanks for adding jQuery to the list. I''ll look into what that > is. > > On Feb 3, 7:54 pm, "Jeremy McAnally" <jeremymcana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Honestly, most of that is stuff that''s too specific. You need to > > spend more time understanding concepts instead of libraries. What > > powers a shopping cart? Is RMagick the best solution? How do you > > tell? How do acts_as_paranoid or ActiveMerchant work? These are the > > things you need to focus on because they will make you a better > > developer instead of a better Rails user. > > > To pare down your list: > > > * Subversion > > * Capistrano > > * Attachment_fu > > * Caching > > * RSpec > > * Git > > * Action Mailer > > * RJS > > * jQuery > > * SSL > > * Authentication > > * Testing > > * Restful Development > > > To that I would probably add a lot of things about how the web works, > > how to profile Ruby, and a ton of Ruby education. > > > --Jeremy > > > On Feb 3, 2008 10:49 PM, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > You''ve probably heard the phrase before... maybe even used it. What I > > > want to know is what does it mean to you? What should a professional > > > rails programmer know? I''m going to spend the next 6 months learn > > > Rails in depth and I want to prioritize what I learn. > > > > Here are some things that have come to mind so far that I want to > > > learn: > > > > * Shopping Cart + Checkout > > > * Substruct > > > * Subversion > > > * Capistrano > > > * Attachment_fu > > > * Caching > > > o MemCache > > > o Page Caching > > > o Fragment Caching > > > * ActiveMerchant > > > * Acts as paranoid > > > * RSpec > > > * Git > > > * Action Mailer > > > * RJS > > > o Prototype > > > o Effects > > > o Scriptaculous > > > * subdomains as account + payment plans > > > * SSL > > > * Acts as taggable > > > * Authentication > > > o Restful Authentication > > > o Role-based authentication > > > o Open ID authentication > > > * Testing > > > o Unit > > > o Functional > > > * Design > > > o Lightbox helper > > > o Redbox > > > o Creating helpers > > > * Flex + Rails > > > * Flash Charts > > > * RMagick > > > * Liquid > > > * GeoKit > > > * Google Maps > > > * Restful Development > > > > Anything I miss? For those that consider themselves pros at Rails, > > > what do you know that makes you valuable? > > > --http://www.jeremymcanally.com/ > > > My books: > > Ruby in Practicehttp://www.manning.com/mcanally/ > > > My free Ruby e-bookhttp://www.humblelittlerubybook.com/ > > > My blogs:http://www.mrneighborly.com/http://www.rubyinpractice.com/--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Well, I am hoping the series " Monkeying around with a Rails 2 Development Environment" on my blog (http://there.thruhere.net/ randy_gordons_blog) will cover all those areas. The idea is that I am starting with a basic Eclipse RDT installation and adding support for , well, the kitchen sink, using Eclipse Monkey and Remote Systems Explorer.. The first couple of articles cover setting up a serious development environment on Windows. I am hoping to use the code from the book "RailsSpace" as the base since I think that is the best book for beginners out there, but I am still trying to contact the authors for permission to do so. Once I have support for the basics, later articles will cover customizing Eclipse for the advanced topics you are describing. I am hoping it will also explain the concepts behind each application/technology. On Feb 3, 9:49 pm, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote:> You''ve probably heard the phrase before... maybe even used it. What I > want to know is what does it mean to you? What should a professional > rails programmer know? I''m going to spend the next 6 months learn > Rails in depth and I want to prioritize what I learn. > > Here are some things that have come to mind so far that I want to > learn: > > * Shopping Cart + Checkout > * Substruct > * Subversion > * Capistrano > * Attachment_fu > * Caching > o MemCache > o Page Caching > o Fragment Caching > * ActiveMerchant > * Acts as paranoid > * RSpec > * Git > * Action Mailer > * RJS > o Prototype > o Effects > o Scriptaculous > * subdomains as account + payment plans > * SSL > * Acts as taggable > * Authentication > o Restful Authentication > o Role-based authentication > o Open ID authentication > * Testing > o Unit > o Functional > * Design > o Lightbox helper > o Redbox > o Creating helpers > * Flex + Rails > * Flash Charts > * RMagick > * Liquid > * GeoKit > * Google Maps > * Restful Development > > Anything I miss? For those that consider themselves pros at Rails, > what do you know that makes you valuable?--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 4 Feb 2008, at 12:40, Sazima wrote:> > Mel, > > An old school professor of mine once said: > > "We don''t teach you how to use tools, we teach you how to reason"! > > I fully agree with Jeremy. Focus on learning the basics, the concepts, > the core of Ruby and RoR. The rest will come easy after that. After > all, tools change... >I''m definitely 100% on that. I would add javascript of some flavour (prototype, jQuery etc..) to the list: rjs is nice, but it''s not the be all and end all. There are times when you should just write some javascript (and with prototype that can actually be quite nice). Rails has been a full time job for me for not far off 2 years and I''ve not touched quite a few of those initial things, because I just haven''t needed to. The important thing is to be able to pick up new things when they come up (although a general awareness of what sort of thing is available is useful) Fred> Cheers, Sazima > > On Feb 4, 2:06 am, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: >> Specifics is what I am asking for. What things (plugins/technologies/ >> methods/etc) does a pro rails developer use often to build real world >> apps? It will differ based on projects you are involved with... but >> if >> various people answer with specific things they need to do their >> build >> their apps, I''ll get a good idea of what I should know to build the >> apps I want to build. >> >> BTW, Thanks for adding jQuery to the list. I''ll look into what that >> is. >> >> On Feb 3, 7:54 pm, "Jeremy McAnally" <jeremymcana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> wrote: >> >>> Honestly, most of that is stuff that''s too specific. You need to >>> spend more time understanding concepts instead of libraries. What >>> powers a shopping cart? Is RMagick the best solution? How do you >>> tell? How do acts_as_paranoid or ActiveMerchant work? These are >>> the >>> things you need to focus on because they will make you a better >>> developer instead of a better Rails user. >> >>> To pare down your list: >> >>> * Subversion >>> * Capistrano >>> * Attachment_fu >>> * Caching >>> * RSpec >>> * Git >>> * Action Mailer >>> * RJS >>> * jQuery >>> * SSL >>> * Authentication >>> * Testing >>> * Restful Development >> >>> To that I would probably add a lot of things about how the web >>> works, >>> how to profile Ruby, and a ton of Ruby education. >> >>> --Jeremy >> >>> On Feb 3, 2008 10:49 PM, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> >>> wrote: >> >>>> You''ve probably heard the phrase before... maybe even used it. >>>> What I >>>> want to know is what does it mean to you? What should a >>>> professional >>>> rails programmer know? I''m going to spend the next 6 months learn >>>> Rails in depth and I want to prioritize what I learn. >> >>>> Here are some things that have come to mind so far that I want to >>>> learn: >> >>>> * Shopping Cart + Checkout >>>> * Substruct >>>> * Subversion >>>> * Capistrano >>>> * Attachment_fu >>>> * Caching >>>> o MemCache >>>> o Page Caching >>>> o Fragment Caching >>>> * ActiveMerchant >>>> * Acts as paranoid >>>> * RSpec >>>> * Git >>>> * Action Mailer >>>> * RJS >>>> o Prototype >>>> o Effects >>>> o Scriptaculous >>>> * subdomains as account + payment plans >>>> * SSL >>>> * Acts as taggable >>>> * Authentication >>>> o Restful Authentication >>>> o Role-based authentication >>>> o Open ID authentication >>>> * Testing >>>> o Unit >>>> o Functional >>>> * Design >>>> o Lightbox helper >>>> o Redbox >>>> o Creating helpers >>>> * Flex + Rails >>>> * Flash Charts >>>> * RMagick >>>> * Liquid >>>> * GeoKit >>>> * Google Maps >>>> * Restful Development >> >>>> Anything I miss? For those that consider themselves pros at Rails, >>>> what do you know that makes you valuable? >> >>> --http://www.jeremymcanally.com/ >> >>> My books: >>> Ruby in Practicehttp://www.manning.com/mcanally/ >> >>> My free Ruby e-bookhttp://www.humblelittlerubybook.com/ >> >>> My blogs:http://www.mrneighborly.com/http://www.rubyinpractice.com/ > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I agree here. Learn Ruby first. The "Ruby for Rails Programmers" (Black) is a great way to start since it uses the Rails platform as an example of good Ruby. Most of the things that you''ve listed are helpful tools but they''ll be useless if you don''t thoroughly understand the language in which the framework is implemented and the core concepts (MVC, REST) and specific implementations (ActiveRecord, ActiveResource, ActionController, etc) then you''re completely wasting your time with plugins and gems. On Feb 4, 7:40 am, Sazima <rsaz...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Mel, > > An old school professor of mine once said: > > "We don''t teach you how to use tools, we teach you how to reason"! > > I fully agree with Jeremy. Focus on learning the basics, the concepts, > the core of Ruby and RoR. The rest will come easy after that. After > all, tools change... > > Cheers, Sazima > > On Feb 4, 2:06 am, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > Specifics is what I am asking for. What things (plugins/technologies/ > > methods/etc) does a pro rails developer use often to build real world > > apps? It will differ based on projects you are involved with... but if > > various people answer with specific things they need to do their build > > their apps, I''ll get a good idea of what I should know to build the > > apps I want to build. > > > BTW, Thanks for adding jQuery to the list. I''ll look into what that > > is. > > > On Feb 3, 7:54 pm, "Jeremy McAnally" <jeremymcana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Honestly, most of that is stuff that''s too specific. You need to > > > spend more time understanding concepts instead of libraries. What > > > powers a shopping cart? Is RMagick the best solution? How do you > > > tell? How do acts_as_paranoid or ActiveMerchant work? These are the > > > things you need to focus on because they will make you a better > > > developer instead of a better Rails user. > > > > To pare down your list: > > > > * Subversion > > > * Capistrano > > > * Attachment_fu > > > * Caching > > > * RSpec > > > * Git > > > * Action Mailer > > > * RJS > > > * jQuery > > > * SSL > > > * Authentication > > > * Testing > > > * Restful Development > > > > To that I would probably add a lot of things about how the web works, > > > how to profile Ruby, and a ton of Ruby education. > > > > --Jeremy > > > > On Feb 3, 2008 10:49 PM, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > > You''ve probably heard the phrase before... maybe even used it. What I > > > > want to know is what does it mean to you? What should a professional > > > > rails programmer know? I''m going to spend the next 6 months learn > > > > Rails in depth and I want to prioritize what I learn. > > > > > Here are some things that have come to mind so far that I want to > > > > learn: > > > > > * Shopping Cart + Checkout > > > > * Substruct > > > > * Subversion > > > > * Capistrano > > > > * Attachment_fu > > > > * Caching > > > > o MemCache > > > > o Page Caching > > > > o Fragment Caching > > > > * ActiveMerchant > > > > * Acts as paranoid > > > > * RSpec > > > > * Git > > > > * Action Mailer > > > > * RJS > > > > o Prototype > > > > o Effects > > > > o Scriptaculous > > > > * subdomains as account + payment plans > > > > * SSL > > > > * Acts as taggable > > > > * Authentication > > > > o Restful Authentication > > > > o Role-based authentication > > > > o Open ID authentication > > > > * Testing > > > > o Unit > > > > o Functional > > > > * Design > > > > o Lightbox helper > > > > o Redbox > > > > o Creating helpers > > > > * Flex + Rails > > > > * Flash Charts > > > > * RMagick > > > > * Liquid > > > > * GeoKit > > > > * Google Maps > > > > * Restful Development > > > > > Anything I miss? For those that consider themselves pros at Rails, > > > > what do you know that makes you valuable? > > > > --http://www.jeremymcanally.com/ > > > > My books: > > > Ruby in Practicehttp://www.manning.com/mcanally/ > > > > My free Ruby e-bookhttp://www.humblelittlerubybook.com/ > > > > My blogs:http://www.mrneighborly.com/http://www.rubyinpractice.com/--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Humor me and gemme specifics please. On Feb 4, 5:40 am, AndyV <a...-HmMyXyqgL2CVc3sceRu5cw@public.gmane.org> wrote:> I agree here. Learn Ruby first. The "Ruby for Rails > Programmers" (Black) is a great way to start since it uses the Rails > platform as an example of good Ruby. Most of the things that you''ve > listed are helpful tools but they''ll be useless if you don''t > thoroughly understand the language in which the framework is > implemented and the core concepts (MVC, REST) and specific > implementations (ActiveRecord, ActiveResource, ActionController, etc) > then you''re completely wasting your time with plugins and gems. > > On Feb 4, 7:40 am, Sazima <rsaz...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Mel, > > > An old school professor of mine once said: > > > "We don''t teach you how to use tools, we teach you how to reason"! > > > I fully agree with Jeremy. Focus on learning the basics, the concepts, > > the core of Ruby and RoR. The rest will come easy after that. After > > all, tools change... > > > Cheers, Sazima > > > On Feb 4, 2:06 am, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > Specifics is what I am asking for. What things (plugins/technologies/ > > > methods/etc) does a pro rails developer use often to build real world > > > apps? It will differ based on projects you are involved with... but if > > > various people answer with specific things they need to do their build > > > their apps, I''ll get a good idea of what I should know to build the > > > apps I want to build. > > > > BTW, Thanks for adding jQuery to the list. I''ll look into what that > > > is. > > > > On Feb 3, 7:54 pm, "Jeremy McAnally" <jeremymcana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > Honestly, most of that is stuff that''s too specific. You need to > > > > spend more time understanding concepts instead of libraries. What > > > > powers a shopping cart? Is RMagick the best solution? How do you > > > > tell? How do acts_as_paranoid or ActiveMerchant work? These are the > > > > things you need to focus on because they will make you a better > > > > developer instead of a better Rails user. > > > > > To pare down your list: > > > > > * Subversion > > > > * Capistrano > > > > * Attachment_fu > > > > * Caching > > > > * RSpec > > > > * Git > > > > * Action Mailer > > > > * RJS > > > > * jQuery > > > > * SSL > > > > * Authentication > > > > * Testing > > > > * Restful Development > > > > > To that I would probably add a lot of things about how the web works, > > > > how to profile Ruby, and a ton of Ruby education. > > > > > --Jeremy > > > > > On Feb 3, 2008 10:49 PM, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > > > You''ve probably heard the phrase before... maybe even used it. What I > > > > > want to know is what does it mean to you? What should a professional > > > > > rails programmer know? I''m going to spend the next 6 months learn > > > > > Rails in depth and I want to prioritize what I learn. > > > > > > Here are some things that have come to mind so far that I want to > > > > > learn: > > > > > > * Shopping Cart + Checkout > > > > > * Substruct > > > > > * Subversion > > > > > * Capistrano > > > > > * Attachment_fu > > > > > * Caching > > > > > o MemCache > > > > > o Page Caching > > > > > o Fragment Caching > > > > > * ActiveMerchant > > > > > * Acts as paranoid > > > > > * RSpec > > > > > * Git > > > > > * Action Mailer > > > > > * RJS > > > > > o Prototype > > > > > o Effects > > > > > o Scriptaculous > > > > > * subdomains as account + payment plans > > > > > * SSL > > > > > * Acts as taggable > > > > > * Authentication > > > > > o Restful Authentication > > > > > o Role-based authentication > > > > > o Open ID authentication > > > > > * Testing > > > > > o Unit > > > > > o Functional > > > > > * Design > > > > > o Lightbox helper > > > > > o Redbox > > > > > o Creating helpers > > > > > * Flex + Rails > > > > > * Flash Charts > > > > > * RMagick > > > > > * Liquid > > > > > * GeoKit > > > > > * Google Maps > > > > > * Restful Development > > > > > > Anything I miss? For those that consider themselves pros at Rails, > > > > > what do you know that makes you valuable? > > > > > --http://www.jeremymcanally.com/ > > > > > My books: > > > > Ruby in Practicehttp://www.manning.com/mcanally/ > > > > > My free Ruby e-bookhttp://www.humblelittlerubybook.com/ > > > > > My blogs:http://www.mrneighborly.com/http://www.rubyinpractice.com/--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
OK, for your first salt, learn and explain the differences, advantages, and tradeoffs among: has_many has_many :through has_and_belongs_to_many associations. What problems does one solve that another does not? Why have three when one more general one might do? Any Rails programmer worth his or her salt should be able to do this. Extra points for a discussion of eager loading and its impact on memory consumption, object instantiation and potential performance issues. Is that specific enough? On Feb 4, 2008, at 10:59 AM, mel ram wrote:> > Humor me and gemme specifics please. > > On Feb 4, 5:40 am, AndyV <a...-HmMyXyqgL2CVc3sceRu5cw@public.gmane.org> wrote: >> I agree here. Learn Ruby first. The "Ruby for Rails >> Programmers" (Black) is a great way to start since it uses the Rails >> platform as an example of good Ruby. Most of the things that you''ve >> listed are helpful tools but they''ll be useless if you don''t >> thoroughly understand the language in which the framework is >> implemented and the core concepts (MVC, REST) and specific >> implementations (ActiveRecord, ActiveResource, ActionController, etc) >> then you''re completely wasting your time with plugins and gems. >> >> On Feb 4, 7:40 am, Sazima <rsaz...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >>> Mel, >> >>> An old school professor of mine once said: >> >>> "We don''t teach you how to use tools, we teach you how to reason"! >> >>> I fully agree with Jeremy. Focus on learning the basics, the >>> concepts, >>> the core of Ruby and RoR. The rest will come easy after that. After >>> all, tools change... >> >>> Cheers, Sazima >> >>> On Feb 4, 2:06 am, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: >> >>>> Specifics is what I am asking for. What things (plugins/ >>>> technologies/ >>>> methods/etc) does a pro rails developer use often to build real >>>> world >>>> apps? It will differ based on projects you are involved with... >>>> but if >>>> various people answer with specific things they need to do their >>>> build >>>> their apps, I''ll get a good idea of what I should know to build the >>>> apps I want to build. >> >>>> BTW, Thanks for adding jQuery to the list. I''ll look into what that >>>> is. >> >>>> On Feb 3, 7:54 pm, "Jeremy McAnally" <jeremymcana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >>>> wrote: >> >>>>> Honestly, most of that is stuff that''s too specific. You need to >>>>> spend more time understanding concepts instead of libraries. What >>>>> powers a shopping cart? Is RMagick the best solution? How do you >>>>> tell? How do acts_as_paranoid or ActiveMerchant work? These >>>>> are the >>>>> things you need to focus on because they will make you a better >>>>> developer instead of a better Rails user. >> >>>>> To pare down your list: >> >>>>> * Subversion >>>>> * Capistrano >>>>> * Attachment_fu >>>>> * Caching >>>>> * RSpec >>>>> * Git >>>>> * Action Mailer >>>>> * RJS >>>>> * jQuery >>>>> * SSL >>>>> * Authentication >>>>> * Testing >>>>> * Restful Development >> >>>>> To that I would probably add a lot of things about how the web >>>>> works, >>>>> how to profile Ruby, and a ton of Ruby education. >> >>>>> --Jeremy >> >>>>> On Feb 3, 2008 10:49 PM, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> >>>>> wrote: >> >>>>>> You''ve probably heard the phrase before... maybe even used it. >>>>>> What I >>>>>> want to know is what does it mean to you? What should a >>>>>> professional >>>>>> rails programmer know? I''m going to spend the next 6 months learn >>>>>> Rails in depth and I want to prioritize what I learn. >> >>>>>> Here are some things that have come to mind so far that I want to >>>>>> learn: >> >>>>>> * Shopping Cart + Checkout >>>>>> * Substruct >>>>>> * Subversion >>>>>> * Capistrano >>>>>> * Attachment_fu >>>>>> * Caching >>>>>> o MemCache >>>>>> o Page Caching >>>>>> o Fragment Caching >>>>>> * ActiveMerchant >>>>>> * Acts as paranoid >>>>>> * RSpec >>>>>> * Git >>>>>> * Action Mailer >>>>>> * RJS >>>>>> o Prototype >>>>>> o Effects >>>>>> o Scriptaculous >>>>>> * subdomains as account + payment plans >>>>>> * SSL >>>>>> * Acts as taggable >>>>>> * Authentication >>>>>> o Restful Authentication >>>>>> o Role-based authentication >>>>>> o Open ID authentication >>>>>> * Testing >>>>>> o Unit >>>>>> o Functional >>>>>> * Design >>>>>> o Lightbox helper >>>>>> o Redbox >>>>>> o Creating helpers >>>>>> * Flex + Rails >>>>>> * Flash Charts >>>>>> * RMagick >>>>>> * Liquid >>>>>> * GeoKit >>>>>> * Google Maps >>>>>> * Restful Development >> >>>>>> Anything I miss? For those that consider themselves pros at >>>>>> Rails, >>>>>> what do you know that makes you valuable? >> >>>>> --http://www.jeremymcanally.com/ >> >>>>> My books: >>>>> Ruby in Practicehttp://www.manning.com/mcanally/ >> >>>>> My free Ruby e-bookhttp://www.humblelittlerubybook.com/ >> >>>>> My blogs:http://www.mrneighborly.com/http:// >>>>> www.rubyinpractice.com/ > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thats what I''m talking about! On Feb 4, 11:07 am, "s.ross" <cwdi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> OK, for your first salt, learn and explain the differences, > advantages, and tradeoffs among: > > has_many > has_many :through > has_and_belongs_to_many > > associations. What problems does one solve that another does not? Why > have three when one more general one might do? > > Any Rails programmer worth his or her salt should be able to do this. > Extra points for a discussion of eager loading and its impact on > memory consumption, object instantiation and potential performance > issues. > > Is that specific enough? > > On Feb 4, 2008, at 10:59 AM, mel ram wrote: > > > > > Humor me and gemme specifics please. > > > On Feb 4, 5:40 am, AndyV <a...-HmMyXyqgL2CVc3sceRu5cw@public.gmane.org> wrote: > >> I agree here. Learn Ruby first. The "Ruby for Rails > >> Programmers" (Black) is a great way to start since it uses the Rails > >> platform as an example of good Ruby. Most of the things that you''ve > >> listed are helpful tools but they''ll be useless if you don''t > >> thoroughly understand the language in which the framework is > >> implemented and the core concepts (MVC, REST) and specific > >> implementations (ActiveRecord, ActiveResource, ActionController, etc) > >> then you''re completely wasting your time with plugins and gems. > > >> On Feb 4, 7:40 am, Sazima <rsaz...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > >>> Mel, > > >>> An old school professor of mine once said: > > >>> "We don''t teach you how to use tools, we teach you how to reason"! > > >>> I fully agree with Jeremy. Focus on learning the basics, the > >>> concepts, > >>> the core of Ruby and RoR. The rest will come easy after that. After > >>> all, tools change... > > >>> Cheers, Sazima > > >>> On Feb 4, 2:06 am, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > >>>> Specifics is what I am asking for. What things (plugins/ > >>>> technologies/ > >>>> methods/etc) does a pro rails developer use often to build real > >>>> world > >>>> apps? It will differ based on projects you are involved with... > >>>> but if > >>>> various people answer with specific things they need to do their > >>>> build > >>>> their apps, I''ll get a good idea of what I should know to build the > >>>> apps I want to build. > > >>>> BTW, Thanks for adding jQuery to the list. I''ll look into what that > >>>> is. > > >>>> On Feb 3, 7:54 pm, "Jeremy McAnally" <jeremymcana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > >>>> wrote: > > >>>>> Honestly, most of that is stuff that''s too specific. You need to > >>>>> spend more time understanding concepts instead of libraries. What > >>>>> powers a shopping cart? Is RMagick the best solution? How do you > >>>>> tell? How do acts_as_paranoid or ActiveMerchant work? These > >>>>> are the > >>>>> things you need to focus on because they will make you a better > >>>>> developer instead of a better Rails user. > > >>>>> To pare down your list: > > >>>>> * Subversion > >>>>> * Capistrano > >>>>> * Attachment_fu > >>>>> * Caching > >>>>> * RSpec > >>>>> * Git > >>>>> * Action Mailer > >>>>> * RJS > >>>>> * jQuery > >>>>> * SSL > >>>>> * Authentication > >>>>> * Testing > >>>>> * Restful Development > > >>>>> To that I would probably add a lot of things about how the web > >>>>> works, > >>>>> how to profile Ruby, and a ton of Ruby education. > > >>>>> --Jeremy > > >>>>> On Feb 3, 2008 10:49 PM, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> > >>>>> wrote: > > >>>>>> You''ve probably heard the phrase before... maybe even used it. > >>>>>> What I > >>>>>> want to know is what does it mean to you? What should a > >>>>>> professional > >>>>>> rails programmer know? I''m going to spend the next 6 months learn > >>>>>> Rails in depth and I want to prioritize what I learn. > > >>>>>> Here are some things that have come to mind so far that I want to > >>>>>> learn: > > >>>>>> * Shopping Cart + Checkout > >>>>>> * Substruct > >>>>>> * Subversion > >>>>>> * Capistrano > >>>>>> * Attachment_fu > >>>>>> * Caching > >>>>>> o MemCache > >>>>>> o Page Caching > >>>>>> o Fragment Caching > >>>>>> * ActiveMerchant > >>>>>> * Acts as paranoid > >>>>>> * RSpec > >>>>>> * Git > >>>>>> * Action Mailer > >>>>>> * RJS > >>>>>> o Prototype > >>>>>> o Effects > >>>>>> o Scriptaculous > >>>>>> * subdomains as account + payment plans > >>>>>> * SSL > >>>>>> * Acts as taggable > >>>>>> * Authentication > >>>>>> o Restful Authentication > >>>>>> o Role-based authentication > >>>>>> o Open ID authentication > >>>>>> * Testing > >>>>>> o Unit > >>>>>> o Functional > >>>>>> * Design > >>>>>> o Lightbox helper > >>>>>> o Redbox > >>>>>> o Creating helpers > >>>>>> * Flex + Rails > >>>>>> * Flash Charts > >>>>>> * RMagick > >>>>>> * Liquid > >>>>>> * GeoKit > >>>>>> * Google Maps > >>>>>> * Restful Development > > >>>>>> Anything I miss? For those that consider themselves pros at > >>>>>> Rails, > >>>>>> what do you know that makes you valuable? > > >>>>> --http://www.jeremymcanally.com/ > > >>>>> My books: > >>>>> Ruby in Practicehttp://www.manning.com/mcanally/ > > >>>>> My free Ruby e-bookhttp://www.humblelittlerubybook.com/ > > >>>>> My blogs:http://www.mrneighborly.com/http:// > >>>>>www.rubyinpractice.com/--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> Anything I miss? For those that consider themselves pros at Rails, > what do you know that makes you valuable?Learn how to optimize queries in your choice of database. A lot of ''rails scaling'' issues I''ve seen are from slow or needlessly frequent database queries. Doing this goes a long way towards writing a good web app in any language. -- Rick Olson http://lighthouseapp.com http://weblog.techno-weenie.net http://mephistoblog.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
This sounds like a good one. Thanks, I''ll look into it. On Feb 4, 11:12 am, "Rick Olson" <technowee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Anything I miss? For those that consider themselves pros at Rails, > > what do you know that makes you valuable? > > Learn how to optimize queries in your choice of database. A lot of > ''rails scaling'' issues I''ve seen are from slow or needlessly frequent > database queries. Doing this goes a long way towards writing a good > web app in any language. > > -- > Rick Olsonhttp://lighthouseapp.comhttp://weblog.techno-weenie.nethttp://mephistoblog.com--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Steve Ross wrote:> OK, for your first salt, learn and explain the differences, > advantages, and tradeoffs among: > > has_many > has_many :through > has_and_belongs_to_many > > associations. What problems does one solve that another does not? Why > have three when one more general one might do? > > Any Rails programmer worth his or her salt should be able to do this. > Extra points for a discussion of eager loading and its impact on > memory consumption, object instantiation and potential performance > issues. > > Is that specific enough?has_many has_many :through has_and_belongs_to_many These are ActiveRecord associations. I would call them methods except that they seem to *generate* methods. class Project < ActiveRecord::Base belongs_to :portfolio has_one :project_manager has_many :milestones has_and_belongs_to_many :categories end generates the following methods: Project#portfolio, Project#portfolio=(portfolio), Project#portfolio.nil? Project#project_manager, Project#project_manager=(project_manager), Project#project_manager.nil?, Project#milestones.empty?, Project#milestones.size, Project#milestones, Project#milestones<<(milestone), Project#milestones.delete(milestone), Project#milestones.find(milestone_id), Project#milestones.find(:all, options), Project#milestones.build, Project#milestones.create Project#categories.empty?, Project#categories.size, Project#categories, Project#categories<<(category1), Project#categories.delete(category1) has_many :through is shorthand for a through association, whose continued syntax is: :through => :catalogue_items This association appears to have implications for polymorphism. -- Dan Ford -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
You''re right, inasfar as these methods generate other methods, a.k.a., metaprogramming (code that generates other code). Now your task is to figure out how all that works. :P And where else Rails uses metaprogramming (there''s a lot). If you can master metaprogramming (and know when and not to use it [the hardest part]), then you''ll be a number of steps ahead of most developers. --Jeremy On Feb 4, 2008 7:25 PM, Dan Ford <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Steve Ross wrote: > > OK, for your first salt, learn and explain the differences, > > advantages, and tradeoffs among: > > > > has_many > > has_many :through > > has_and_belongs_to_many > > > > associations. What problems does one solve that another does not? Why > > have three when one more general one might do? > > > > Any Rails programmer worth his or her salt should be able to do this. > > Extra points for a discussion of eager loading and its impact on > > memory consumption, object instantiation and potential performance > > issues. > > > > Is that specific enough? > > has_many > has_many :through > has_and_belongs_to_many > > These are ActiveRecord associations. I would call them methods except > that they seem to *generate* methods. > > class Project < ActiveRecord::Base > belongs_to :portfolio > has_one :project_manager > has_many :milestones > has_and_belongs_to_many :categories > end > > generates the following methods: > > Project#portfolio, Project#portfolio=(portfolio), Project#portfolio.nil? > Project#project_manager, Project#project_manager=(project_manager), > Project#project_manager.nil?, > Project#milestones.empty?, Project#milestones.size, Project#milestones, > Project#milestones<<(milestone), Project#milestones.delete(milestone), > Project#milestones.find(milestone_id), Project#milestones.find(:all, > options), Project#milestones.build, Project#milestones.create > Project#categories.empty?, Project#categories.size, Project#categories, > Project#categories<<(category1), Project#categories.delete(category1) > > has_many :through > is shorthand for a through association, whose continued syntax is: > :through => :catalogue_items > This association appears to have implications for polymorphism. > -- > Dan Ford > -- > Posted via http://www.ruby-forum.com/. > > > > >-- http://www.jeremymcanally.com/ My books: Ruby in Practice http://www.manning.com/mcanally/ My free Ruby e-book http://www.humblelittlerubybook.com/ My blogs: http://www.mrneighborly.com/ http://www.rubyinpractice.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
These are all excellent suggestions! Thanks for your guidance. Anything else? On Feb 4, 6:20 pm, "Jeremy McAnally" <jeremymcana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> You''re right, inasfar as these methods generate other methods, a.k.a., > metaprogramming (code that generates other code). > > Now your task is to figure out how all that works. :P And where else > Rails uses metaprogramming (there''s a lot). > > If you can master metaprogramming (and know when and not to use it > [the hardest part]), then you''ll be a number of steps ahead of most > developers. > > --Jeremy > > On Feb 4, 2008 7:25 PM, Dan Ford <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: > > > > > > > Steve Ross wrote: > > > OK, for your first salt, learn and explain the differences, > > > advantages, and tradeoffs among: > > > > has_many > > > has_many :through > > > has_and_belongs_to_many > > > > associations. What problems does one solve that another does not? Why > > > have three when one more general one might do? > > > > Any Rails programmer worth his or her salt should be able to do this. > > > Extra points for a discussion of eager loading and its impact on > > > memory consumption, object instantiation and potential performance > > > issues. > > > > Is that specific enough? > > > has_many > > has_many :through > > has_and_belongs_to_many > > > These are ActiveRecord associations. I would call them methods except > > that they seem to *generate* methods. > > > class Project < ActiveRecord::Base > > belongs_to :portfolio > > has_one :project_manager > > has_many :milestones > > has_and_belongs_to_many :categories > > end > > > generates the following methods: > > > Project#portfolio, Project#portfolio=(portfolio), Project#portfolio.nil? > > Project#project_manager, Project#project_manager=(project_manager), > > Project#project_manager.nil?, > > Project#milestones.empty?, Project#milestones.size, Project#milestones, > > Project#milestones<<(milestone), Project#milestones.delete(milestone), > > Project#milestones.find(milestone_id), Project#milestones.find(:all, > > options), Project#milestones.build, Project#milestones.create > > Project#categories.empty?, Project#categories.size, Project#categories, > > Project#categories<<(category1), Project#categories.delete(category1) > > > has_many :through > > is shorthand for a through association, whose continued syntax is: > > :through => :catalogue_items > > This association appears to have implications for polymorphism. > > -- > > Dan Ford > > -- > > Posted viahttp://www.ruby-forum.com/. > > --http://www.jeremymcanally.com/ > > My books: > Ruby in Practicehttp://www.manning.com/mcanally/ > > My free Ruby e-bookhttp://www.humblelittlerubybook.com/ > > My blogs:http://www.mrneighborly.com/http://www.rubyinpractice.com/--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Feb 05, 2008 at 12:23:05AM -0800, mel ram wrote:> These are all excellent suggestions! Thanks for your guidance. > Anything else?There''s a general sort of attitude one should have towards libraries and frameworks, though I''m hesitant to bring it up because it''s too easy to take it its illogical extreme. The idea is that one should be capable of implementing any framework/library one uses. That doesn''t mean that it''s worth your time to do so, just that you understand it well enough that nothing seems "magical" to you. Importantly, this should not be taken to mean that one should not use a framework/library one couldn''t have come up with independently, or implement equally well, or anything like that. I''d be hard-pressed to implement a dependable 3D rendering library, much less an optimized OpenGL renderer. That said, I feel comfortable using OpenGL (and ruby-opengl) because I understand it well. What that understanding does for you is that you spend less time guessing at configuration/methods/whatever because your first guess is usually right and, if not, you can read the source to quickly find out what you need. For Rails in particular, reading the source is very instructive. It is likely to teach you things about Ruby you didn''t know, and enlighten you about what functionality Rails actually provides and how it does it. I would love to see a book on the Rails source in the same vein as the Lions book on the Unix source <http://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th_Edition%2C_with_Source_Code>. Anyway, I''d say that a "Rails programmer worth his salt" understands Rails to the point that it holds no magic or mystery, not merely in its use but in its implementation. --Greg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Monday 04 February 2008, Rick Olson wrote:> > Anything I miss? For those that consider themselves pros at Rails, > > what do you know that makes you valuable? > > Learn how to optimize queries in your choice of database. A lot of > ''rails scaling'' issues I''ve seen are from slow or needlessly frequent > database queries. Doing this goes a long way towards writing a good > web app in any language.Rick, can you be more specific and provide an example, please. To me it is not clear what you are suggesting. It could be (a) to learn how to write custom, optimized SQL queries, or it could be (b) learning how to avoid unnecessary database accesses using eager loading, caching etc. Regarding (a), writing optimized SQL queries, I''m curious as to the performance improvements that can be gained. I have no doubts that there are huge potential improvements when changing algorithms so that they are expressed in a single SQL statement rather than in Ruby intermingled with multiple DB queries. I''m more cautious when it comes to one to one substitution of Rails-generated SQL with handwritten SQL. I''d expect that in such a case optimization is more a matter of providing the DBMS with suitable access paths, i.e. indexes, that are necessary regardless how the SQL of the query is created. Michael -- Michael Schuerig mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org http://www.schuerig.de/michael/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Feb 5, 2008, at 10:28 AM, Michael Schuerig wrote:> > On Monday 04 February 2008, Rick Olson wrote: >>> Anything I miss? For those that consider themselves pros at Rails, >>> what do you know that makes you valuable? >> >> Learn how to optimize queries in your choice of database. A lot of >> ''rails scaling'' issues I''ve seen are from slow or needlessly frequent >> database queries. Doing this goes a long way towards writing a good >> web app in any language. > > Rick, can you be more specific and provide an example, please. To me > it > is not clear what you are suggesting. It could be (a) to learn how to > write custom, optimized SQL queries, or it could be (b) learning how > to > avoid unnecessary database accesses using eager loading, caching etc. > > Regarding (a), writing optimized SQL queries, I''m curious as to the > performance improvements that can be gained. I have no doubts that > there are huge potential improvements when changing algorithms so that > they are expressed in a single SQL statement rather than in Ruby > intermingled with multiple DB queries. I''m more cautious when it comes > to one to one substitution of Rails-generated SQL with handwritten > SQL. > I''d expect that in such a case optimization is more a matter of > providing the DBMS with suitable access paths, i.e. indexes, that are > necessary regardless how the SQL of the query is created. > > Michael >I''m not Rick, but I can give you a couple of concrete examples: Counter caching can be a huge win. Say every blog page says: This entry has (3) comments. With counter caching, you can avoid the database hit each time the post is shown. By default, Rails does a SELECT *. On a table with many fields, this can get pretty darn expensive. Instead, for critical queries, use: @person = Person.find :all, :select => ''first_name, last_name'' I guess I wouldn''t do this unless you were doing full-table scans of bulky tables, but I have (in some cases) been able to measure significant improvements when there was a complex table and all I needed was a small subset of the information for a given query. The DataMapper people claim (and I have no reason to doubt this) that large text or blob fields can be expensive if loaded for each object. I''m not sure how they do this, but they lazy-load text fields so you incur the database hit as late as possible (and for the smallest number of rows required). Also, AR does query caching. That''s cool, and I suspect it solves many problems, but it''s a single-machine solution. If you are looking to offload some of the burden from your primary app server, running a memcached server on a separate box to cache queries can help. I''m sure Rick has cooler examples. This kind of stuff is pretty far in front of the original "worth his salt" question. I believe one can do a workmanlike job constructing a Rails app just knowing that some of this stuff *can* be done, without ever having done it. Oh, one other note: textile and markdown are relatively expensive operations (not SQL related, however), so if you store a preformatted version of text in your database on create or update, the render will happen faster. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
http://docs.google.com/Doc?id=dg4nzw3x_139hkpwmpf7 Based on all the ideas you guys have put out there as well as going through some books, here is my check-list of things to learn in rails. The order will change as my needs change and I''ll keep things updated as I go. I figured it might be helpful to other newbies like me. ~ mel On Feb 5, 11:25 am, "s.ross" <cwdi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Feb 5, 2008, at 10:28 AM, Michael Schuerig wrote: > > > > > > > On Monday 04 February 2008, Rick Olson wrote: > >>> Anything I miss? For those that consider themselves pros at Rails, > >>> what do you know that makes you valuable? > > >> Learn how to optimize queries in your choice of database. A lot of > >> ''rails scaling'' issues I''ve seen are from slow or needlessly frequent > >> database queries. Doing this goes a long way towards writing a good > >> web app in any language. > > > Rick, can you be more specific and provide an example, please. To me > > it > > is not clear what you are suggesting. It could be (a) to learn how to > > write custom, optimized SQL queries, or it could be (b) learning how > > to > > avoid unnecessary database accesses using eager loading, caching etc. > > > Regarding (a), writing optimized SQL queries, I''m curious as to the > > performance improvements that can be gained. I have no doubts that > > there are huge potential improvements when changing algorithms so that > > they are expressed in a single SQL statement rather than in Ruby > > intermingled with multiple DB queries. I''m more cautious when it comes > > to one to one substitution of Rails-generated SQL with handwritten > > SQL. > > I''d expect that in such a case optimization is more a matter of > > providing the DBMS with suitable access paths, i.e. indexes, that are > > necessary regardless how the SQL of the query is created. > > > Michael > > I''m not Rick, but I can give you a couple of concrete examples: > > Counter caching can be a huge win. Say every blog page says: This > entry has (3) comments. With counter caching, you can avoid the > database hit each time the post is shown. > > By default, Rails does a SELECT *. On a table with many fields, this > can get pretty darn expensive. Instead, for critical queries, use: > > @person = Person.find :all, :select => ''first_name, last_name'' > > I guess I wouldn''t do this unless you were doing full-table scans of > bulky tables, but I have (in some cases) been able to measure > significant improvements when there was a complex table and all I > needed was a small subset of the information for a given query. > > The DataMapper people claim (and I have no reason to doubt this) that > large text or blob fields can be expensive if loaded for each object. > I''m not sure how they do this, but they lazy-load text fields so you > incur the database hit as late as possible (and for the smallest > number of rows required). > > Also, AR does query caching. That''s cool, and I suspect it solves many > problems, but it''s a single-machine solution. If you are looking to > offload some of the burden from your primary app server, running a > memcached server on a separate box to cache queries can help. > > I''m sure Rick has cooler examples. > > This kind of stuff is pretty far in front of the original "worth his > salt" question. I believe one can do a workmanlike job constructing a > Rails app just knowing that some of this stuff *can* be done, without > ever having done it. > > Oh, one other note: textile and markdown are relatively expensive > operations (not SQL related, however), so if you store a preformatted > version of text in your database on create or update, the render will > happen faster.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Tuesday 05 February 2008, s.ross wrote:> On Feb 5, 2008, at 10:28 AM, Michael Schuerig wrote: > > On Monday 04 February 2008, Rick Olson wrote: > >>> Anything I miss? For those that consider themselves pros at > >>> Rails, what do you know that makes you valuable? > >> > >> Learn how to optimize queries in your choice of database. A lot > >> of ''rails scaling'' issues I''ve seen are from slow or needlessly > >> frequent database queries. Doing this goes a long way towards > >> writing a good web app in any language. > > > > Rick, can you be more specific and provide an example, please. To > > me it > > is not clear what you are suggesting. It could be (a) to learn how > > to write custom, optimized SQL queries, or it could be (b) learning > > how to > > avoid unnecessary database accesses using eager loading, caching > > etc.[snip]> I''m not Rick, but I can give you a couple of concrete examples: > > Counter caching can be a huge win. Say every blog page says: This > entry has (3) comments. With counter caching, you can avoid the > database hit each time the post is shown. > > By default, Rails does a SELECT *. On a table with many fields, this > can get pretty darn expensive. Instead, for critical queries, use: > > @person = Person.find :all, :select => ''first_name, last_name'' > > I guess I wouldn''t do this unless you were doing full-table scans of > bulky tables, but I have (in some cases) been able to measure > significant improvements when there was a complex table and all I > needed was a small subset of the information for a given query.The noteworthy thing about all these examples is that they remain at API-level, nowhere do you manually write SQL with the express purpose of optimization. That doesn''t dimish the value of these techniques, of course, however, I''m wondering whether they are what Rick had in mind. Michael -- Michael Schuerig mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org http://www.schuerig.de/michael/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Melvin Ram wrote:> http://docs.google.com/Doc?id=dg4nzw3x_139hkpwmpf7 > > Based on all the ideas you guys have put out there as well as going > through some books, here is my check-list of things to learn in rails. > The order will change as my needs change and I''ll keep things updated > as I go. I figured it might be helpful to other newbies like me. > > ~ melhey, that''s a nice list. how about allowing people to vote for what they think is important and order the list by votes? instead of making a shopping cart (boring anyway) -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Feb 5, 2008, at 1:01 PM, Michael Schuerig wrote:> The noteworthy thing about all these examples is that they remain at > API-level, nowhere do you manually write SQL with the express purpose > of optimization. That doesn''t dimish the value of these techniques, of > course, however, I''m wondering whether they are what Rick had in mind.I think that 1) There''s a fair distance you can go without tying yourself to a given databases by using a particular SQL dialect; and 2) If you''re really getting bogged down in your database queries, maybe examining your algorithms to see whether so many queries are necessary is in order. That said, there are occasions when a subselect is just what the doctor ordered. I, too, am curious what Rick had in mind. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hey thats a good idea for a simple app. I''ll build it out and let you know when it''s live. On Feb 5, 1:06 pm, Thorsten Mueller <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Melvin Ram wrote: > >http://docs.google.com/Doc?id=dg4nzw3x_139hkpwmpf7 > > > Based on all the ideas you guys have put out there as well as going > > through some books, here is my check-list of things to learn in rails. > > The order will change as my needs change and I''ll keep things updated > > as I go. I figured it might be helpful to other newbies like me. > > > ~ mel > > hey, that''s a nice list. how about allowing people to vote for what they > think is important and order the list by votes? instead of making a > shopping cart (boring anyway) > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I think you''re missing my point. I''m suggesting that you _don''t_ try to get specific on "cool Rails toys", but get down and dirty with Ruby. That''s why I mentioned "Ruby for Rails" (David Black, Manning Press). Understanding that book will put you a long way towards being a "Rails programmer worth his salt." From there you should move on to the recently released "The Ruby Way" by Obie Fernandez. I''ve come to like it more than ADWR. What I fear you''re going to do is grab a bunch of buzz words, hack with them for a while, and call the job done. For your own sake, don''t. On Feb 4, 1:59 pm, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote:> Humor me and gemme specifics please. > > On Feb 4, 5:40 am, AndyV <a...-HmMyXyqgL2CVc3sceRu5cw@public.gmane.org> wrote: > > > I agree here. Learn Ruby first. The "Ruby for Rails > > Programmers" (Black) is a great way to start since it uses the Rails > > platform as an example of good Ruby. Most of the things that you''ve > > listed are helpful tools but they''ll be useless if you don''t > > thoroughly understand the language in which the framework is > > implemented and the core concepts (MVC, REST) and specific > > implementations (ActiveRecord, ActiveResource, ActionController, etc) > > then you''re completely wasting your time with plugins and gems. > > > On Feb 4, 7:40 am, Sazima <rsaz...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Mel, > > > > An old school professor of mine once said: > > > > "We don''t teach you how to use tools, we teach you how to reason"! > > > > I fully agree with Jeremy. Focus on learning the basics, the concepts, > > > the core of Ruby and RoR. The rest will come easy after that. After > > > all, tools change... > > > > Cheers, Sazima > > > > On Feb 4, 2:06 am, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > > Specifics is what I am asking for. What things (plugins/technologies/ > > > > methods/etc) does a pro rails developer use often to build real world > > > > apps? It will differ based on projects you are involved with... but if > > > > various people answer with specific things they need to do their build > > > > their apps, I''ll get a good idea of what I should know to build the > > > > apps I want to build. > > > > > BTW, Thanks for adding jQuery to the list. I''ll look into what that > > > > is. > > > > > On Feb 3, 7:54 pm, "Jeremy McAnally" <jeremymcana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > Honestly, most of that is stuff that''s too specific. You need to > > > > > spend more time understanding concepts instead of libraries. What > > > > > powers a shopping cart? Is RMagick the best solution? How do you > > > > > tell? How do acts_as_paranoid or ActiveMerchant work? These are the > > > > > things you need to focus on because they will make you a better > > > > > developer instead of a better Rails user. > > > > > > To pare down your list: > > > > > > * Subversion > > > > > * Capistrano > > > > > * Attachment_fu > > > > > * Caching > > > > > * RSpec > > > > > * Git > > > > > * Action Mailer > > > > > * RJS > > > > > * jQuery > > > > > * SSL > > > > > * Authentication > > > > > * Testing > > > > > * Restful Development > > > > > > To that I would probably add a lot of things about how the web works, > > > > > how to profile Ruby, and a ton of Ruby education. > > > > > > --Jeremy > > > > > > On Feb 3, 2008 10:49 PM, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > > > > You''ve probably heard the phrase before... maybe even used it. What I > > > > > > want to know is what does it mean to you? What should a professional > > > > > > rails programmer know? I''m going to spend the next 6 months learn > > > > > > Rails in depth and I want to prioritize what I learn. > > > > > > > Here are some things that have come to mind so far that I want to > > > > > > learn: > > > > > > > * Shopping Cart + Checkout > > > > > > * Substruct > > > > > > * Subversion > > > > > > * Capistrano > > > > > > * Attachment_fu > > > > > > * Caching > > > > > > o MemCache > > > > > > o Page Caching > > > > > > o Fragment Caching > > > > > > * ActiveMerchant > > > > > > * Acts as paranoid > > > > > > * RSpec > > > > > > * Git > > > > > > * Action Mailer > > > > > > * RJS > > > > > > o Prototype > > > > > > o Effects > > > > > > o Scriptaculous > > > > > > * subdomains as account + payment plans > > > > > > * SSL > > > > > > * Acts as taggable > > > > > > * Authentication > > > > > > o Restful Authentication > > > > > > o Role-based authentication > > > > > > o Open ID authentication > > > > > > * Testing > > > > > > o Unit > > > > > > o Functional > > > > > > * Design > > > > > > o Lightbox helper > > > > > > o Redbox > > > > > > o Creating helpers > > > > > > * Flex + Rails > > > > > > * Flash Charts > > > > > > * RMagick > > > > > > * Liquid > > > > > > * GeoKit > > > > > > * Google Maps > > > > > > * Restful Development > > > > > > > Anything I miss? For those that consider themselves pros at Rails, > > > > > > what do you know that makes you valuable? > > > > > > --http://www.jeremymcanally.com/ > > > > > > My books: > > > > > Ruby in Practicehttp://www.manning.com/mcanally/ > > > > > > My free Ruby e-bookhttp://www.humblelittlerubybook.com/ > > > > > > My blogs:http://www.mrneighborly.com/http://www.rubyinpractice.com/--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Andy, I hear ya loud and clear. You''re saying learn Ruby. Get down and dirty with Ruby. Point taken. I picked up the Ruby for Rails book last weekend. Just assume I will be doing that. Beyond that, I would appreciate any specific recommendations... specific methods/plugins/techniques/etc that you use often when you''re building real world high-quality apps? On Feb 5, 1:42 pm, AndyV <a...-HmMyXyqgL2CVc3sceRu5cw@public.gmane.org> wrote:> I think you''re missing my point. I''m suggesting that you _don''t_ try > to get specific on "cool Rails toys", but get down and dirty with > Ruby. That''s why I mentioned "Ruby for Rails" (David Black, Manning > Press). Understanding that book will put you a long way towards being > a "Rails programmer worth his salt." From there you should move on to > the recently released "The Ruby Way" by Obie Fernandez. I''ve come to > like it more than ADWR. > > What I fear you''re going to do is grab a bunch of buzz words, hack > with them for a while, and call the job done. For your own sake, > don''t. > > On Feb 4, 1:59 pm, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > Humor me and gemme specifics please. > > > On Feb 4, 5:40 am, AndyV <a...-HmMyXyqgL2CVc3sceRu5cw@public.gmane.org> wrote: > > > > I agree here. Learn Ruby first. The "Ruby for Rails > > > Programmers" (Black) is a great way to start since it uses the Rails > > > platform as an example of good Ruby. Most of the things that you''ve > > > listed are helpful tools but they''ll be useless if you don''t > > > thoroughly understand the language in which the framework is > > > implemented and the core concepts (MVC, REST) and specific > > > implementations (ActiveRecord, ActiveResource, ActionController, etc) > > > then you''re completely wasting your time with plugins and gems. > > > > On Feb 4, 7:40 am, Sazima <rsaz...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > Mel, > > > > > An old school professor of mine once said: > > > > > "We don''t teach you how to use tools, we teach you how to reason"! > > > > > I fully agree with Jeremy. Focus on learning the basics, the concepts, > > > > the core of Ruby and RoR. The rest will come easy after that. After > > > > all, tools change... > > > > > Cheers, Sazima > > > > > On Feb 4, 2:06 am, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > > > Specifics is what I am asking for. What things (plugins/technologies/ > > > > > methods/etc) does a pro rails developer use often to build real world > > > > > apps? It will differ based on projects you are involved with... but if > > > > > various people answer with specific things they need to do their build > > > > > their apps, I''ll get a good idea of what I should know to build the > > > > > apps I want to build. > > > > > > BTW, Thanks for adding jQuery to the list. I''ll look into what that > > > > > is. > > > > > > On Feb 3, 7:54 pm, "Jeremy McAnally" <jeremymcana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > Honestly, most of that is stuff that''s too specific. You need to > > > > > > spend more time understanding concepts instead of libraries. What > > > > > > powers a shopping cart? Is RMagick the best solution? How do you > > > > > > tell? How do acts_as_paranoid or ActiveMerchant work? These are the > > > > > > things you need to focus on because they will make you a better > > > > > > developer instead of a better Rails user. > > > > > > > To pare down your list: > > > > > > > * Subversion > > > > > > * Capistrano > > > > > > * Attachment_fu > > > > > > * Caching > > > > > > * RSpec > > > > > > * Git > > > > > > * Action Mailer > > > > > > * RJS > > > > > > * jQuery > > > > > > * SSL > > > > > > * Authentication > > > > > > * Testing > > > > > > * Restful Development > > > > > > > To that I would probably add a lot of things about how the web works, > > > > > > how to profile Ruby, and a ton of Ruby education. > > > > > > > --Jeremy > > > > > > > On Feb 3, 2008 10:49 PM, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > > > > > You''ve probably heard the phrase before... maybe even used it. What I > > > > > > > want to know is what does it mean to you? What should a professional > > > > > > > rails programmer know? I''m going to spend the next 6 months learn > > > > > > > Rails in depth and I want to prioritize what I learn. > > > > > > > > Here are some things that have come to mind so far that I want to > > > > > > > learn: > > > > > > > > * Shopping Cart + Checkout > > > > > > > * Substruct > > > > > > > * Subversion > > > > > > > * Capistrano > > > > > > > * Attachment_fu > > > > > > > * Caching > > > > > > > o MemCache > > > > > > > o Page Caching > > > > > > > o Fragment Caching > > > > > > > * ActiveMerchant > > > > > > > * Acts as paranoid > > > > > > > * RSpec > > > > > > > * Git > > > > > > > * Action Mailer > > > > > > > * RJS > > > > > > > o Prototype > > > > > > > o Effects > > > > > > > o Scriptaculous > > > > > > > * subdomains as account + payment plans > > > > > > > * SSL > > > > > > > * Acts as taggable > > > > > > > * Authentication > > > > > > > o Restful Authentication > > > > > > > o Role-based authentication > > > > > > > o Open ID authentication > > > > > > > * Testing > > > > > > > o Unit > > > > > > > o Functional > > > > > > > * Design > > > > > > > o Lightbox helper > > > > > > > o Redbox > > > > > > > o Creating helpers > > > > > > > * Flex + Rails > > > > > > > * Flash Charts > > > > > > > * RMagick > > > > > > > * Liquid > > > > > > > * GeoKit > > > > > > > * Google Maps > > > > > > > * Restful Development > > > > > > > > Anything I miss? For those that consider themselves pros at Rails, > > > > > > > what do you know that makes you valuable? > > > > > > > --http://www.jeremymcanally.com/ > > > > > > > My books: > > > > > > Ruby in Practicehttp://www.manning.com/mcanally/ > > > > > > > My free Ruby e-bookhttp://www.humblelittlerubybook.com/ > > > > > > > My blogs:http://www.mrneighborly.com/http://www.rubyinpractice.com/--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
For example, I learned how to upload an image file, resize it, crop it, save various versions of it... and then I discovered attachment_fu. And life was good. On Feb 5, 9:22 pm, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote:> Andy, > > I hear ya loud and clear. You''re saying learn Ruby. Get down and dirty > with Ruby. Point taken. I picked up the Ruby for Rails book last > weekend. Just assume I will be doing that. > > Beyond that, I would appreciate any specific recommendations... > specific methods/plugins/techniques/etc that you use often when you''re > building real world high-quality apps? > > On Feb 5, 1:42 pm, AndyV <a...-HmMyXyqgL2CVc3sceRu5cw@public.gmane.org> wrote: > > > I think you''re missing my point. I''m suggesting that you _don''t_ try > > to get specific on "cool Rails toys", but get down and dirty with > > Ruby. That''s why I mentioned "Ruby for Rails" (David Black, Manning > > Press). Understanding that book will put you a long way towards being > > a "Rails programmer worth his salt." From there you should move on to > > the recently released "The Ruby Way" by Obie Fernandez. I''ve come to > > like it more than ADWR. > > > What I fear you''re going to do is grab a bunch of buzz words, hack > > with them for a while, and call the job done. For your own sake, > > don''t. > > > On Feb 4, 1:59 pm, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > Humor me and gemme specifics please. > > > > On Feb 4, 5:40 am, AndyV <a...-HmMyXyqgL2CVc3sceRu5cw@public.gmane.org> wrote: > > > > > I agree here. Learn Ruby first. The "Ruby for Rails > > > > Programmers" (Black) is a great way to start since it uses the Rails > > > > platform as an example of good Ruby. Most of the things that you''ve > > > > listed are helpful tools but they''ll be useless if you don''t > > > > thoroughly understand the language in which the framework is > > > > implemented and the core concepts (MVC, REST) and specific > > > > implementations (ActiveRecord, ActiveResource, ActionController, etc) > > > > then you''re completely wasting your time with plugins and gems. > > > > > On Feb 4, 7:40 am, Sazima <rsaz...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > Mel, > > > > > > An old school professor of mine once said: > > > > > > "We don''t teach you how to use tools, we teach you how to reason"! > > > > > > I fully agree with Jeremy. Focus on learning the basics, the concepts, > > > > > the core of Ruby and RoR. The rest will come easy after that. After > > > > > all, tools change... > > > > > > Cheers, Sazima > > > > > > On Feb 4, 2:06 am, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > > > > Specifics is what I am asking for. What things (plugins/technologies/ > > > > > > methods/etc) does a pro rails developer use often to build real world > > > > > > apps? It will differ based on projects you are involved with... but if > > > > > > various people answer with specific things they need to do their build > > > > > > their apps, I''ll get a good idea of what I should know to build the > > > > > > apps I want to build. > > > > > > > BTW, Thanks for adding jQuery to the list. I''ll look into what that > > > > > > is. > > > > > > > On Feb 3, 7:54 pm, "Jeremy McAnally" <jeremymcana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > Honestly, most of that is stuff that''s too specific. You need to > > > > > > > spend more time understanding concepts instead of libraries. What > > > > > > > powers a shopping cart? Is RMagick the best solution? How do you > > > > > > > tell? How do acts_as_paranoid or ActiveMerchant work? These are the > > > > > > > things you need to focus on because they will make you a better > > > > > > > developer instead of a better Rails user. > > > > > > > > To pare down your list: > > > > > > > > * Subversion > > > > > > > * Capistrano > > > > > > > * Attachment_fu > > > > > > > * Caching > > > > > > > * RSpec > > > > > > > * Git > > > > > > > * Action Mailer > > > > > > > * RJS > > > > > > > * jQuery > > > > > > > * SSL > > > > > > > * Authentication > > > > > > > * Testing > > > > > > > * Restful Development > > > > > > > > To that I would probably add a lot of things about how the web works, > > > > > > > how to profile Ruby, and a ton of Ruby education. > > > > > > > > --Jeremy > > > > > > > > On Feb 3, 2008 10:49 PM, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > > > > > > You''ve probably heard the phrase before... maybe even used it. What I > > > > > > > > want to know is what does it mean to you? What should a professional > > > > > > > > rails programmer know? I''m going to spend the next 6 months learn > > > > > > > > Rails in depth and I want to prioritize what I learn. > > > > > > > > > Here are some things that have come to mind so far that I want to > > > > > > > > learn: > > > > > > > > > * Shopping Cart + Checkout > > > > > > > > * Substruct > > > > > > > > * Subversion > > > > > > > > * Capistrano > > > > > > > > * Attachment_fu > > > > > > > > * Caching > > > > > > > > o MemCache > > > > > > > > o Page Caching > > > > > > > > o Fragment Caching > > > > > > > > * ActiveMerchant > > > > > > > > * Acts as paranoid > > > > > > > > * RSpec > > > > > > > > * Git > > > > > > > > * Action Mailer > > > > > > > > * RJS > > > > > > > > o Prototype > > > > > > > > o Effects > > > > > > > > o Scriptaculous > > > > > > > > * subdomains as account + payment plans > > > > > > > > * SSL > > > > > > > > * Acts as taggable > > > > > > > > * Authentication > > > > > > > > o Restful Authentication > > > > > > > > o Role-based authentication > > > > > > > > o Open ID authentication > > > > > > > > * Testing > > > > > > > > o Unit > > > > > > > > o Functional > > > > > > > > * Design > > > > > > > > o Lightbox helper > > > > > > > > o Redbox > > > > > > > > o Creating helpers > > > > > > > > * Flex + Rails > > > > > > > > * Flash Charts > > > > > > > > * RMagick > > > > > > > > * Liquid > > > > > > > > * GeoKit > > > > > > > > * Google Maps > > > > > > > > * Restful Development > > > > > > > > > Anything I miss? For those that consider themselves pros at Rails, > > > > > > > > what do you know that makes you valuable? > > > > > > > > --http://www.jeremymcanally.com/ > > > > > > > > My books: > > > > > > > Ruby in Practicehttp://www.manning.com/mcanally/ > > > > > > > > My free Ruby e-bookhttp://www.humblelittlerubybook.com/ > > > > > > > > My blogs:http://www.mrneighborly.com/http://www.rubyinpractice.com/--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Learning Ruby first is the right route, but if I had to do it over, here are some resources I would use: Pragmatic Programmers, Learning Ruby The Rails Way (This book is just awesome) Also, I didn''t see TzTime mentioned on here, or maybe I missed it. But I would be comfortable working with timezones... its a small thing, but it will come up fast in a production Rails project. As for testing, I would focus most of your time on RSpec. I just started blogging so you can check out my blog http://matthewcarriere.com I am going to put up an RSpec tutorial this weekend as well as start a group of learning Rails/Ruby posts, mostly for my .NET friends who haven''t seen the light yet ;) Good Luck On Feb 5, 9:22 pm, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote:> Andy, > > I hear ya loud and clear. You''re saying learn Ruby. Get down and dirty > with Ruby. Point taken. I picked up the Ruby for Rails book last > weekend. Just assume I will be doing that. > > Beyond that, I would appreciate any specific recommendations... > specific methods/plugins/techniques/etc that you use often when you''re > building real world high-quality apps? > > On Feb 5, 1:42 pm, AndyV <a...-HmMyXyqgL2CVc3sceRu5cw@public.gmane.org> wrote: > > > I think you''re missing my point. I''m suggesting that you _don''t_ try > > to get specific on "cool Rails toys", but get down and dirty with > > Ruby. That''s why I mentioned "Ruby for Rails" (David Black, Manning > > Press). Understanding that book will put you a long way towards being > > a "Rails programmer worth his salt." From there you should move on to > > the recently released "The Ruby Way" by Obie Fernandez. I''ve come to > > like it more than ADWR. > > > What I fear you''re going to do is grab a bunch of buzz words, hack > > with them for a while, and call the job done. For your own sake, > > don''t. > > > On Feb 4, 1:59 pm, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > Humor me and gemme specifics please. > > > > On Feb 4, 5:40 am, AndyV <a...-HmMyXyqgL2CVc3sceRu5cw@public.gmane.org> wrote: > > > > > I agree here. Learn Ruby first. The "Ruby for Rails > > > > Programmers" (Black) is a great way to start since it uses the Rails > > > > platform as an example of good Ruby. Most of the things that you''ve > > > > listed are helpful tools but they''ll be useless if you don''t > > > > thoroughly understand the language in which the framework is > > > > implemented and the core concepts (MVC, REST) and specific > > > > implementations (ActiveRecord, ActiveResource, ActionController, etc) > > > > then you''re completely wasting your time with plugins and gems. > > > > > On Feb 4, 7:40 am, Sazima <rsaz...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > Mel, > > > > > > An old school professor of mine once said: > > > > > > "We don''t teach you how to use tools, we teach you how to reason"! > > > > > > I fully agree with Jeremy. Focus on learning the basics, the concepts, > > > > > the core of Ruby and RoR. The rest will come easy after that. After > > > > > all, tools change... > > > > > > Cheers, Sazima > > > > > > On Feb 4, 2:06 am, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > > > > Specifics is what I am asking for. What things (plugins/technologies/ > > > > > > methods/etc) does a pro rails developer use often to build real world > > > > > > apps? It will differ based on projects you are involved with... but if > > > > > > various people answer with specific things they need to do their build > > > > > > their apps, I''ll get a good idea of what I should know to build the > > > > > > apps I want to build. > > > > > > > BTW, Thanks for adding jQuery to the list. I''ll look into what that > > > > > > is. > > > > > > > On Feb 3, 7:54 pm, "Jeremy McAnally" <jeremymcana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > Honestly, most of that is stuff that''s too specific. You need to > > > > > > > spend more time understanding concepts instead of libraries. What > > > > > > > powers a shopping cart? Is RMagick the best solution? How do you > > > > > > > tell? How do acts_as_paranoid or ActiveMerchant work? These are the > > > > > > > things you need to focus on because they will make you a better > > > > > > > developer instead of a better Rails user. > > > > > > > > To pare down your list: > > > > > > > > * Subversion > > > > > > > * Capistrano > > > > > > > * Attachment_fu > > > > > > > * Caching > > > > > > > * RSpec > > > > > > > * Git > > > > > > > * Action Mailer > > > > > > > * RJS > > > > > > > * jQuery > > > > > > > * SSL > > > > > > > * Authentication > > > > > > > * Testing > > > > > > > * Restful Development > > > > > > > > To that I would probably add a lot of things about how the web works, > > > > > > > how to profile Ruby, and a ton of Ruby education. > > > > > > > > --Jeremy > > > > > > > > On Feb 3, 2008 10:49 PM, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > > > > > > You''ve probably heard the phrase before... maybe even used it. What I > > > > > > > > want to know is what does it mean to you? What should a professional > > > > > > > > rails programmer know? I''m going to spend the next 6 months learn > > > > > > > > Rails in depth and I want to prioritize what I learn. > > > > > > > > > Here are some things that have come to mind so far that I want to > > > > > > > > learn: > > > > > > > > > * Shopping Cart + Checkout > > > > > > > > * Substruct > > > > > > > > * Subversion > > > > > > > > * Capistrano > > > > > > > > * Attachment_fu > > > > > > > > * Caching > > > > > > > > o MemCache > > > > > > > > o Page Caching > > > > > > > > o Fragment Caching > > > > > > > > * ActiveMerchant > > > > > > > > * Acts as paranoid > > > > > > > > * RSpec > > > > > > > > * Git > > > > > > > > * Action Mailer > > > > > > > > * RJS > > > > > > > > o Prototype > > > > > > > > o Effects > > > > > > > > o Scriptaculous > > > > > > > > * subdomains as account + payment plans > > > > > > > > * SSL > > > > > > > > * Acts as taggable > > > > > > > > * Authentication > > > > > > > > o Restful Authentication > > > > > > > > o Role-based authentication > > > > > > > > o Open ID authentication > > > > > > > > * Testing > > > > > > > > o Unit > > > > > > > > o Functional > > > > > > > > * Design > > > > > > > > o Lightbox helper > > > > > > > > o Redbox > > > > > > > > o Creating helpers > > > > > > > > * Flex + Rails > > > > > > > > * Flash Charts > > > > > > > > * RMagick > > > > > > > > * Liquid > > > > > > > > * GeoKit > > > > > > > > * Google Maps > > > > > > > > * Restful Development > > > > > > > > > Anything I miss? For those that consider themselves pros at Rails, > > > > > > > > what do you know that makes you valuable? > > > > > > > > --http://www.jeremymcanally.com/ > > > > > > > > My books: > > > > > > > Ruby in Practicehttp://www.manning.com/mcanally/ > > > > > > > > My free Ruby e-bookhttp://www.humblelittlerubybook.com/ > > > > > > > > My blogs:http://www.mrneighborly.com/http://www.rubyinpractice.com/--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Master the debugger and you will be the king ! Specifically if you can easily debug from your favorite IDE. That can be very interesting. I am using Aptana, it is not yet doing what I am dreaming of (easily opening an IRB in the debug stack.). I will check Netbeans sometime. Mastering a good old break on exception makes a huge difference between programmers. This is true for quite a lot of languages. I am not myself mastering the debugger, I regret it so it is one of my priority. H On Feb 6, 6:22 am, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote:> Andy, > > I hear ya loud and clear. You''re saying learn Ruby. Get down and dirty > with Ruby. Point taken. I picked up the Ruby for Rails book last > weekend. Just assume I will be doing that. > > Beyond that, I would appreciate any specific recommendations... > specific methods/plugins/techniques/etc that you use often when you''re > building real world high-quality apps? > > On Feb 5, 1:42 pm, AndyV <a...-HmMyXyqgL2CVc3sceRu5cw@public.gmane.org> wrote: > > > I think you''re missing my point. I''m suggesting that you _don''t_ try > > to get specific on "cool Rails toys", but get down and dirty with > > Ruby. That''s why I mentioned "Ruby for Rails" (David Black, Manning > > Press). Understanding that book will put you a long way towards being > > a "Rails programmer worth his salt." From there you should move on to > > the recently released "The Ruby Way" by Obie Fernandez. I''ve come to > > like it more than ADWR. > > > What I fear you''re going to do is grab a bunch of buzz words, hack > > with them for a while, and call the job done. For your own sake, > > don''t. > > > On Feb 4, 1:59 pm, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > Humor me and gemme specifics please. > > > > On Feb 4, 5:40 am, AndyV <a...-HmMyXyqgL2CVc3sceRu5cw@public.gmane.org> wrote: > > > > > I agree here. Learn Ruby first. The "Ruby for Rails > > > > Programmers" (Black) is a great way to start since it uses the Rails > > > > platform as an example of good Ruby. Most of the things that you''ve > > > > listed are helpful tools but they''ll be useless if you don''t > > > > thoroughly understand the language in which the framework is > > > > implemented and the core concepts (MVC, REST) and specific > > > > implementations (ActiveRecord, ActiveResource, ActionController, etc) > > > > then you''re completely wasting your time with plugins and gems. > > > > > On Feb 4, 7:40 am, Sazima <rsaz...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > Mel, > > > > > > An old school professor of mine once said: > > > > > > "We don''t teach you how to use tools, we teach you how to reason"! > > > > > > I fully agree with Jeremy. Focus on learning the basics, the concepts, > > > > > the core of Ruby and RoR. The rest will come easy after that. After > > > > > all, tools change... > > > > > > Cheers, Sazima > > > > > > On Feb 4, 2:06 am, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > > > > Specifics is what I am asking for. What things (plugins/technologies/ > > > > > > methods/etc) does a pro rails developer use often to build real world > > > > > > apps? It will differ based on projects you are involved with... but if > > > > > > various people answer with specific things they need to do their build > > > > > > their apps, I''ll get a good idea of what I should know to build the > > > > > > apps I want to build. > > > > > > > BTW, Thanks for adding jQuery to the list. I''ll look into what that > > > > > > is. > > > > > > > On Feb 3, 7:54 pm, "Jeremy McAnally" <jeremymcana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > Honestly, most of that is stuff that''s too specific. You need to > > > > > > > spend more time understanding concepts instead of libraries. What > > > > > > > powers a shopping cart? Is RMagick the best solution? How do you > > > > > > > tell? How do acts_as_paranoid or ActiveMerchant work? These are the > > > > > > > things you need to focus on because they will make you a better > > > > > > > developer instead of a better Rails user. > > > > > > > > To pare down your list: > > > > > > > > * Subversion > > > > > > > * Capistrano > > > > > > > * Attachment_fu > > > > > > > * Caching > > > > > > > * RSpec > > > > > > > * Git > > > > > > > * Action Mailer > > > > > > > * RJS > > > > > > > * jQuery > > > > > > > * SSL > > > > > > > * Authentication > > > > > > > * Testing > > > > > > > * Restful Development > > > > > > > > To that I would probably add a lot of things about how the web works, > > > > > > > how to profile Ruby, and a ton of Ruby education. > > > > > > > > --Jeremy > > > > > > > > On Feb 3, 2008 10:49 PM, mel ram <mel...-IA9i2KS8NFBpEKysQ+xqfPpXobYPEAuW@public.gmane.org> wrote: > > > > > > > > > You''ve probably heard the phrase before... maybe even used it. What I > > > > > > > > want to know is what does it mean to you? What should a professional > > > > > > > > rails programmer know? I''m going to spend the next 6 months learn > > > > > > > > Rails in depth and I want to prioritize what I learn. > > > > > > > > > Here are some things that have come to mind so far that I want to > > > > > > > > learn: > > > > > > > > > * Shopping Cart + Checkout > > > > > > > > * Substruct > > > > > > > > * Subversion > > > > > > > > * Capistrano > > > > > > > > * Attachment_fu > > > > > > > > * Caching > > > > > > > > o MemCache > > > > > > > > o Page Caching > > > > > > > > o Fragment Caching > > > > > > > > * ActiveMerchant > > > > > > > > * Acts as paranoid > > > > > > > > * RSpec > > > > > > > > * Git > > > > > > > > * Action Mailer > > > > > > > > * RJS > > > > > > > > o Prototype > > > > > > > > o Effects > > > > > > > > o Scriptaculous > > > > > > > > * subdomains as account + payment plans > > > > > > > > * SSL > > > > > > > > * Acts as taggable > > > > > > > > * Authentication > > > > > > > > o Restful Authentication > > > > > > > > o Role-based authentication > > > > > > > > o Open ID authentication > > > > > > > > * Testing > > > > > > > > o Unit > > > > > > > > o Functional > > > > > > > > * Design > > > > > > > > o Lightbox helper > > > > > > > > o Redbox > > > > > > > > o Creating helpers > > > > > > > > * Flex + Rails > > > > > > > > * Flash Charts > > > > > > > > * RMagick > > > > > > > > * Liquid > > > > > > > > * GeoKit > > > > > > > > * Google Maps > > > > > > > > * Restful Development > > > > > > > > > Anything I miss? For those that consider themselves pros at Rails, > > > > > > > > what do you know that makes you valuable? > > > > > > > > --http://www.jeremymcanally.com/ > > > > > > > > My books: > > > > > > > Ruby in Practicehttp://www.manning.com/mcanally/ > > > > > > > > My free Ruby e-bookhttp://www.humblelittlerubybook.com/ > > > > > > > > My blogs:http://www.mrneighborly.com/http://www.rubyinpractice.com/--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---