Rails organization / patterns

Been summarizing some of my studies – note none of this is confirmed by an official Ruby on Rails historian …

I started out looking for where code was supposed to be placed.  Why?  Because I read about DRY.  I really liked the idea of not wasting time redoing code – it’s one of the reason I got into Rails, which I will call RoR from here forward.

So people divide the RoR apps up according to MVC philosophy, which the short version is the model of the database logic, the view you see & is’ logic, and the controller with its logic to tie the two together.

In this MVC design, when I entered RoR’s world most posters were talking about Fat Model / Skinny Controller.

I started reading a lot about this stuff … Justin Weiss has a great breakdown summary of different patterns & where they get placed in the RoR app – Link.  I also like the description of the process on Stackoverflow from ‘Jason‘ & Mike Woodhouse – Link.

 

From what I can gather from posts there was a development of programming as people moved along.  Notice I’m not numbering these…there’s a reason…

  • model / controller / views
  • helpers (with special visibility to only their views)
  • custom classes anywhere
  • app/lib as “the spot” which at one point in RoR history auto loaded (not anymore)
  • modules / mix-ins to include the classes/methods
  • gems – which
  • plugins – which were discontinued in Rails 4, but the command used to make engines now – Hawkins had a good break down if somewhat biased – Link
  • concerns – which even had a special activesupport::concerns for including classes added
  • rails engines which improve on the modules>gems by encapsulating the database too … often these are wrapped in gems when created with mountable option – this might be part of the micro-services movement…

Trouble shooting reminders for me…

Trouble shooting

  • Did something actually break?
    • Is it perspective/perception thing instead of a solid problem?
    • Is it that you don’t have data/values or they aren’t being connected?
    • What does tail’ing the test/development log files show?
  • State changes
    • Does a reload / restart of server / using other device fix it
  • Where is the break at based on what is affected?
    • Can you output flags or sentences to help identify where firing?
  • Scope
    • How many things  affected?
    • How deeply or totally were things affected?
  • What was your last change?
    • What was your last commit to that branch?
  • Similarities / Shared in the systems / characteristics of  the affected systems / components
  • Can you comment stuff out until it works?
  • Does changing test coverage or stubbing work?
  • Does using the code in isolation work?

The difference between a Jr & Senior programmer at Gitlabs

https://about.gitlab.com/jobs/build-engineer/

 

Junior Build Engineer

Junior Build Engineers are developers who meet the following criteria:

  1. Technical skills
    • Is able to write code in required languages but needs guidance in writing modular and maintainable code
    • Has less experience to no experience with containers
    • Proposes default configuration to reduce the need for configuration by customers
  2. Code quality
    • Leaves code in substantially better shape than before
    • Is able to write clear documentation
  3. Communication
    • Needs help with time management
    • Is able to follow technical conversations within the team
  4. Performance & Scalability
    • Needs help writing production-ready code
    • Has little to no experience writing large scale apps

Senior Build Engineer

Senior Build Engineers are experienced developers who meet the following criteria:

  1. Technical Skills
    • Are able to write modular, well-tested, and maintainable code
    • Know the domain really well and radiate that knowledge
    • Contribute to one or more complementary projects
  2. Leadership
    • Begins to show architectural perspective
    • Proposing new ideas, performing feasibility analyses and scoping the work
  3. Code quality
    • Leaves code in substantially better shape than before
    • Fixes bugs/regressions quickly
    • Monitors overall code quality
    • Reacts efficiently to build failures
    • Creates test plans
  4. Communication
    • Provides thorough and timely code feedback for peers
    • Able to communicate clearly on technical topics
    • Keeps issues up-to-date with progress
    • Helps guide other merge requests to completion
    • Is able to help with recruiting
  5. Performance & Scalability
    • Excellent at understanding the cost of a change
    • Excellent at writing production-ready code with little assistance
    • Able to write complex code that can scale with a significant number of users