Thursday 12th January 2017 = Next meeting
22 views
Skip to first unread message
Kelly
Jan 9, 2017, 9:12:19 AM1/9/17
to Scottish Ruby User Group
According to http://scotrug.org/ the next meeting is on Thursday at 6pm at CodeBase on Castle Terrace.
James Bell
Jan 9, 2017, 6:05:19 PM1/9/17
to sco...@googlegroups.com
Indeed Kelly, thanks for pointing it out!
We're meeting up this Thursday, and I missed updating the mailing list
from my checklist when I put the details out yesterday. As you'll be
able to see from the link, this month we're planning on having an
informal discussion about whatever you would like to chat about. If
you have a Ruby or vaguely Ruby related topic that you've been wanting
to talk about, come along and we may talk about it.
As always, newcomers are welcome and I look forward to seeing some of you there!
James
--
Make a man a fire and he'll be warm for the night.
Set a man on fire and he'll be warm for the rest of his life.
On Mon, Jan 9, 2017 at 2:12 PM, Kelly <scot...@mclellans.org> wrote:
> According to http://scotrug.org/ the next meeting is on Thursday at 6pm at
> CodeBase on Castle Terrace.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Scottish Ruby User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scotrug+u...@googlegroups.com.
> To post to this group, send email to sco...@googlegroups.com.
> Visit this group at https://groups.google.com/group/scotrug.
> For more options, visit https://groups.google.com/d/optout.
We're meeting up this Thursday, and I missed updating the mailing list
from my checklist when I put the details out yesterday. As you'll be
able to see from the link, this month we're planning on having an
informal discussion about whatever you would like to chat about. If
you have a Ruby or vaguely Ruby related topic that you've been wanting
to talk about, come along and we may talk about it.
As always, newcomers are welcome and I look forward to seeing some of you there!
James
--
Make a man a fire and he'll be warm for the night.
Set a man on fire and he'll be warm for the rest of his life.
On Mon, Jan 9, 2017 at 2:12 PM, Kelly <scot...@mclellans.org> wrote:
> According to http://scotrug.org/ the next meeting is on Thursday at 6pm at
> CodeBase on Castle Terrace.
>
> You received this message because you are subscribed to the Google Groups
> "Scottish Ruby User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scotrug+u...@googlegroups.com.
> To post to this group, send email to sco...@googlegroups.com.
> Visit this group at https://groups.google.com/group/scotrug.
> For more options, visit https://groups.google.com/d/optout.
mr.eddi...@gmail.com
Jan 10, 2017, 12:38:39 PM1/10/17
to Scottish Ruby User Group
Hi,
As a new inmate in Argyle House I'd be interested in popping in occasionally. I'll aim for this Thu.
Partly though, I'm trying to find out about other employers around Edinburgh that use Ruby as I'm rather keen to get away from my current one :(
Hopefully that's within scope!
Cheers
Eddie
James Bell
Jan 10, 2017, 4:05:13 PM1/10/17
to sco...@googlegroups.com
Hi Eddie,
Welcome to the ScotRUG mailing list! We'd love to see you this
Thursday. The room that we'll be in hasn't been confirmed yet, but is
likely to be either The Meadows or Bruntsfield Links. If you can't
find us, pop out to reception and someone there will be able to point
you to us.
I for one will be happy to chat to you about where I work in
Edinburgh, and I'm easy to spot: I'll be wearing shorts.
Hopefully see you later this week,
James
--
Make a man a fire and he'll be warm for the night.
Set a man on fire and he'll be warm for the rest of his life.
Welcome to the ScotRUG mailing list! We'd love to see you this
Thursday. The room that we'll be in hasn't been confirmed yet, but is
likely to be either The Meadows or Bruntsfield Links. If you can't
find us, pop out to reception and someone there will be able to point
you to us.
I for one will be happy to chat to you about where I work in
Edinburgh, and I'm easy to spot: I'll be wearing shorts.
Hopefully see you later this week,
James
--
Make a man a fire and he'll be warm for the night.
Set a man on fire and he'll be warm for the rest of his life.
Paul Wilson
Jan 13, 2017, 3:08:17 AM1/13/17
to Scotrug
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.
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).
Paul Wilson
Jan 13, 2017, 3:09:30 AM1/13/17
to Scotrug
s/Heady/Headey/
Sorry Olly.
Sorry Olly.
Reply all
Reply to author
Forward
0 new messages