I need to constantly remind myself that sinatra is a stepping stone for rails in the curriculum because its hard to appreciate it otherwise. Although a low-level one, sinatra is the first web framework I worked with. I would say the biggest takeaway is understanding application file structure. The MVC framework is something that I think i’ll end up carrying with me accross most other frameworks and languages. We have our models that inherit from activerecord (more on this later) which exist so that we can detail intermodel relationships and have some ruby objects to play around with in our controllers. Our controllers handle web routes and http requests and render views which are just webpages visible to the user. Creating view files is where I learned about erb or embedded ruby. Here we can draw up some ruby code within an html file and use erb tags to show or not show something to the user. This structure is very important to understand application flow.
There are many analogies made to help people understand the flow of an application within the MVC. One of my favorite is the restaurant example. An order is taken by a waiter. That order is sent to a kitchen. The kitchen then grabs raw food from within its fridge to then now turn the order into something appetizing and desirable that the waiter can then bring to a patrons table. This is essentially a game of catch except the ball gets manipulated/altered every time it passes through another person. There are a lot of moving parts even in a sinatra web application. As long as you know where the ball goes or is going to end up you can clearly manage application flow. Another thing that offers even more clarity? RESTful routing.
REST is an acronym that stands for — “Representational State Transfer. (It is sometimes spelled “ReST”.) It relies on a stateless, client-server, cacheable communications protocol — and in virtually all cases, the HTTP protocol is used. REST is an architecture style for designing networked applications.” This just means that we can look at a URL and get a decent sense about what sort of activity is going on in a web page. Using the naming conventions of “new” “edit” “login” “signup” etc we can create more forms, more erb files, and more routes while still maintaining clarity in the structure of our program. As it pertains to my project, which is a virtual medical cannabis pharmacy, my “new” route renders a simple form where the user is asked to simply enter a mood. They have five options — happy, creative, relaxed, euphoric, and uplifted. After entering a mood they would like to feel, they click “request prescription.” This will auto generate a new prescription that the user can edit only by adding notes or giving the prescription a rating after they have tried it. Pretty simple and pretty neat. However, to safeguard against this not fufilling the project requirement where the user engages in the “create” CRUD function there is another route “custom” for uploading a strain of cannabis that the patient has grown themselves. A patient would want to upload a strain that they grew and are now trying so that (at some point down the line when i add this funcitonality) an admin or pharmacist can keep tabs on what their patients are consuming. In this route a patient uploads a custom prescription from scratch where nothing is autogenerate. They fill in all the attributes for that prescription and that prescription is added to their list of prescriptions. This is the only place where I break from convention altough my route is still technically “restful.” If a user is at the “/custom” route we know that they are uploading a custom prescription. So we are still able to easily identify the activity on the page just by the URL.
For this module, before actually delving into sinatra we learn about SQL — structured query language and databases. We painstakingly wrote out SQL queries to manipulate our database. Just when we had enough we learned about activerecord. Activerecord is essentially hundreds of free methods that have CRUD functionality and allow us to manipulate our database. The methods most used for our project were .create, .update (for when a user wants to edit something), .delete ( for when a user wants to delete something). Within each controller action you would create an instance variable to call into memory a row from the database. This row could be a user or something that a user owns. That instance variable can then be used in the view files with erb tags. Thus, allowing the user to see something within the database.
Even though a lot of new concepts were introduced in this module, it was easy to get acquainted with them once you started a local server and get to see your code in action. I still believe that is the best way to learn anything new — put it to use. Shotgun is an awesome gem that allows you to make changes to your files without needing to restart your server once the changes are made. Tux and rake console are awesome ways to load an irb session with all the code youve written right behind it. This made testing out code and becoming intimate with your code very straightforward and easy. I look forward to what rails has to offer!!
Here is a video demo of my sinatra portfolio project.
Thanks
