Hi,
I thought that was quite an interesting discussion. I made some notes, but they are incomplete. Can anyone fill it out a bit?
Topic: Learning - with some emphasis on resources for beginners
===================================================
Book recommendations
———————————————
Eloquent Ruby by Ross Olsen,
http://eloquentruby.com
The Ruby Programming Language by Matz and David Flanagan,
http://shop.oreilly.com/product/9780596516178.do
Practical Object Oriented Design in Ruby by Sandi Metz,
http://www.poodr.com
What Gems to use? What to use and what not to use in Ruby.
==============================================
I particularly missed taking notes on a lot of things discussed in this section.
http://awesome-ruby.com is a resource which exists, but that no-one present had used.
pry-byebug for debugging
https://github.com/deivid-rodriguez/pry-byebug
source_location, for finding the actual source of a method.
http://ruby-doc.org/core-2.1.2/Method.html#method-i-source_location
Avoid excessive metaprogramming, and method_missing capers.
https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debuggerer.html contains great debugging techniques.
Use fetch to access Hashes, as it will error if the key is not found.
http://ruby-doc.org/core-2.1.2/Hash.html#method-i-fetch
Deployment
=========
Plaudits for Heroku - expensive but saves a lot of hassle and paying salary for someone to mostly do sysops.
No-one present did anything with Docker and friends. Capistrano was still used.
FreeAgent take servers offline (ie off the load balancer) for deployment and then back up when deployed. This is done in a phased way, as they have so many. As the database is so large, any changes must be carefully applied, with SQL rather than migrations; can’t have a change that takes a long time to apply. New code must be able to deal with its new fields having not been created yet. Changes must not affect old code.
Splitting up a (Rails) application
========================
Rails tends to monoliths. Much consensus is to roll with this and for most cases it will be fine. Some have witnessed large Rails applications that have got wildly out of hand, as startups have become rapidly successful.
As a counterpoint, FreeAgent is (essentially?) a very large monolith but has not got out of hand. This was attributed to the quality of the initial work done by Olly Heady and the early programmers on the project, and continuing to apply a disciplined approach as the application grew.
Building an application from Rails Engines, then combining in a monolith, is a reasonable approach to this. There are some headaches, but they are surmountable. Note that this can be started within a repository (typically by pointing to a path under lib/ in the Gemfile).
> To post to this group, send an email to
sco...@googlegroups.com.