Skip to content

Instantly share code, notes, and snippets.

@markyv18
Last active April 20, 2017 07:13
Show Gist options
  • Save markyv18/179d31eb2baaa87c8d088ddf16ed5d7a to your computer and use it in GitHub Desktop.
Save markyv18/179d31eb2baaa87c8d088ddf16ed5d7a to your computer and use it in GitHub Desktop.
Technical blog post

Blog of 13+ years is all racing/coaching focused... i've yet to start one up that's more code/professional-interest focused... till that time i'll have this live here.

Progressing from Sinatra to Rails was a bit tricky for me. There was an ordered simplicity to both the build out process and functionality Sinatra provides you that when stepping up to Rails my head started to spin a bit. With Sinatra and the CRUD process everything is quite literal and straight forward. You are in control of assigning processes (routes/actions/controllers/etc) and tend to remain fairly aware of what you've built because you've basically been doing it by hand from scratch. Furthermore, database integration (as far as we have used it in this framework) is light and fluffy. Not a whole lot of intertwining of tables. While you get a little bit of an intro to ActiveRecord you do have the ability (oops) of completely bypassing it (NOT recommended) and querying the database with ruby methods (super slow, BAD idea). Moving on to Rails and suddenly everything just gets much more involved, but to make it easy for the developer rails takes so much of the responsibility for this and hides it away. Rails Auto-Magic is a real thing. Understanding those unstated magically qualities and coming to rely on them without ever having touched them takes time. No longer are you setting up routes one by one, now, with a single line of code and abracadabra, you've got full routing functionality. In place of this route set ups you now have table joining and relationships to steal your attention away. Making sure models know who they are talking to and what databases belong to whom, where in the views you are putting, patching, creating and editing. If your application is straight forward and simple, not relying on overly intricate and complex database table relationships, go right in with rails, but if you there's going to be extensive back end cross table talking functions that you will be relying heavily on than looking to Rails may be in your best interest.

MVA

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment