Going Off The Track On Rails

Hey, Doc, we better back up. We don't understand enough about Rails to get this project running.

...But we do need Rails. Because Rails is magic!

Well, OK, not exactly magic, but on first look Rails appears to be a very *magic code wand* style of framework for Ruby.

Rails (or Ruby on Rails) is a model–view–controller (MVC) framework, which provides default structures for database, web service, and web pages. It encourages and facilitates the use of web standards such as JSON or XML for data transfer, and HTML, CSS and JavaScript for display and user interfacing. All often from the input of one line of code. Magic!

Because of it's design, and its emphasis on the use of software engineering patterns and paradigms, Rails encourages you to build RESTful (Representational State Transfer, a software architecture style for building scalable web services) applications. So if you make use of the facilities inside of Rails, like Scaffolding which can automatically construct some of the models and views needed for a basic website, all the code generated in Rails is building a RESTful application. Rails has even been described as "REST out of the box".

We could look at Rails as being a little bit like the default factory settings offered to you when you install software. Of course you always have the option of picking and choosing which files you want, and manually configuring your install - but really, who has the time for that? So when it comes to setting up your new application Rails will do the job for you thanks to it's use of Convention over Configuration, this also means that generally Ruby on Rails conventions lead to less code and less repetition.

And that's gotta be good, right?

OK, so Rails has now set everything up for you nicely, let's take a look 'inside the box' and discover how Rails processes an incoming request.

We'll break it down into stages:

1. The client requests the page.
2. The request is parsed (divided into parts and analysed) by the router to identify a particular method (action) somewhere in the controller code.
• The router takes the first part as a controller name.
• The router takes the second part as a method name (action).
3. The action might look at data in the request itself or interact with the model or may invoke another action. Eventually, the action prepares information for the view.
4. The rendered view is sent to the client.

And voila, we have our request processed thanks to the *magic* of Rails.

What is an ORM?

What is an ORM?
Orm was a worm, featured in the popular British CITV show, Orm and Cheep..... But we're not talking the puppet variety here, instead we're concentrating on the computer science version of ORM. It stands for Object-relational mapping, and is sometimes also abbreviated as O/RM or O/R mapping.

ORM is a programming technique for converting data between incompatible type systems in object-oriented programming languages, such as Ruby. This creates, in effect, a "virtual object database" that can be used from within the programming language.

In short, it's like a translator.

In our Makers Academy Ronin course we are coding with Ruby, and this week we want to be able to use a Postgres database. The problem is Ruby doesn't want to communicate directly with the database, and I still don't have a magical code wand that will fix all issues! So we use an ORM. Depending on your coding platform there are a variety of different types of ORM available (I'd actually had some experience of CakePHP when using a MySQL database before, although I hadn't really thought of it how it functioned until now). For Ruby there is ActiveRecord (which is part of the Rails environment), iBATIS, and our ORM of choice for this weerk, DataMapper.

DataMapper, like any ORM, can be a bit tricky to set up initially (although I suppose like everything the more you do it the easier it will become), especially if you're using a Linux system (but we won't go there today!). But once done it allows us to write code in a Ruby-ish style that will be fed through the ORM to the database. Bish-bosh, minimal coding headaches.

Another big plus for using an ORM is that it keeps your databases separate from your actual code, which means multiple users can connect to multiple databases.

We like a good ORM!

Now if only Cheep could fly....

Week 4 and all is well.

Week 4 of the Makers Academy pre-course has really been a continuation of week 3. Ruby, ruby, ruby, ruby. And a good thing too, as there's so much to learn.

I'm mildly dyslexic. My father and eldest daughter struggle a lot with it. I've learnt a lot of tricks to help over the years, and spell check is a good friend of mine, but for me it mainly manifests in reading. I'm quite slow at it, but can usually cope OK. However this week I have really struggled to read The Well-Grounded Rubyist in pdf form and, in a separate browser window, do the exercises or challenges included. I need a physical copy for both speed and ease of use. I ordered one a week ago, unfortunately there has been a delay in delivery and it won't arrive until this coming Monday (estimated), meaning I've only got through 3 chapters in four days. I'm a little upset with this as I feel it's been hugely beneficial, and although I will carry on over the weekend, I wish I'd started sooner and done more. It's a great enlightening book, and I recommend it to anyone thinking about learning Ruby or becoming a developer.

I had some good advice this week - don't be my own bottleneck, which I know I can be. We have a lot of resources available to us where we can get/find help. I don't know, maybe it's pride or something, but I'd shied away from using them. However, once I took the plunge and asked for help it felt good. There are no stupid questions, and everyone who knows the answer has been stuck on something simple at some time in the past, so I need to understand this more and ask for help sooner rather than spending too long stubbornly trying to solve an issue myself. Essentially, I gotta get over my own pride - and not be my own bottleneck.

I'm starting to grasp certain areas of Ruby a lot more than I did, there's still a heck of a lot to come to terms with but no-ones gonna become fully competent in 2 weeks are they? That's almost as ridiculous as signing up to become a web developer in 12 weeks!

I'm know I'm not the only one who's equally excited and terrified about the main course beginning in just a few days. The Makers Academy Slack channels have been brilliant in sharing this experience with the other members of the cohort, and realising that I'm not in this alone.

So, roll on Monday, when the fun starts for real...

'Cause there's so little else occupying my head....

Ruby, Ruby, Ruby Ruby....

Last night I had a dream. I was trapped in a binary world and was being made to dig my own grave by a giant hashtag.

It wasn't the first coding dream I'd had this week, but all the others have been about problems I'd been stuck on and possible solutions for them, whereas this was obviously a lot more abstract. I shared the dream on our Makers Academy Slack channel and got a brilliant response -

"Don't worry, in this course we execute the code and not the other way around."

I wish I'd thought of that.

---

Week 3 of the Makers Academy pre-course has been all about Ruby - the coding language we will largely be studying. It's really flexible, certainly more so than any other coding language I've used. I struggled a bit with the whole object orientated aspect of the language, having being more used to top-down programming, but I'm getting the hang of it.

I decided to go back to the beginning of Chris Pine's Learn To Program book, which was something we were asked to read up to chapter 8 before our interview. I figured it had been a couple of months and in going over it all again I'd get a better understanding. I think it's helped as I'm starting to understand how to do things, or at least feel as if I'm getting there, but I'm really struggling to remember all the terms (as in method, variable, argument, etc etc). This can be problematic when trying to understand a question and I find myself referring to multiple notes and taking much longer to get things done. So there's been a lot of late nights.

The challenges in the Learn To Program book started to get much much harder, and so I decided to go for the alternative option of Ruby-Kickstart - so far so good. Ruby-Kickstart seems a lot more user friendly and I'm working through it at a nice pace.

And then...

Our Friday Challenge was to sign up for Codewars, where you earn points by solving coding challenges and problems. Our task was to get 60 points before the weekend was out, and 125 before the course begins for real (in 8 days now, argh!). The prize? A sticker! Oh man, I love me a sticker!!

Getting a 125 points is not the biggest problem with this challenge (well, it's still a problem as there's a lot of tricky stuff on Codewars), oh no! The biggest problem is that nobody mentioned how ridiculously addictive Codewars is. It's like coding cocaine. Very moreish.

I'm just going to attempt one more, then I'll stop. Just one more, then I'll go to bed. I could stop anytime I wanted to. Honestly...

...10 hours later.

So by the end of week 3, sleep is a thing of the past, I'm having bizarre Codewars infused dreams, and I'm loving every minute of it!

I know at this stage my code is not always 'pretty'. Most of the time I'm getting there and it runs, but I know I need to stop repetition and work on easier more concise ways of doing things. I also know there are many areas of Ruby I just don't understand at all - Blocks, Procs, Lambdas etc etc, but I'll get there...



Oh, and by the way.

Currently, at the end of the day today, I check out of Codewars with 178 points! Now where's my sticker... (mic drop).