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.

Asynchronous I/O in Programming (and Chickens)

Gloria, you're always on the run now...

Today we're looking at how input and output operations can be handled on a computer. But because I spend all my days sat at a laptop I will instead use a chicken to explain this process. Because why not?

See our chicken up there ↑, let's call her Gloria. Gloria is hungry and is looking for something to eat. She finds a tasty worm and gobbles it up. Now would Gloria then come to a complete standstill until said worm has worked its way through her little chicken body? Oh no! That could take ages and Gloria has much to do with her day. Maybe laying the odd egg or two, doing some laundry for the little chicks, I don't know? But the point is she just gets on with chicken related things, and later on when her little worm meal has been digested she's all ready to poop it out (come on, surely you'd realised by now this was not going to be a high-brow blog post!).

This is an example of asynchronous input/output (I/O) processing, or non-blocking I/O, as Gloria can do many other things whilst her worm meal is being 'processed'. The alternative approach would be called, unsurprisingly, synchronous I/O, or blocking I/O, which would prohibit Gloria from doing anything at all after chowing down on that tasty worm until it had been fully processed and returned to the grass where it first came from (all be it in a little chicken poop form). This approach might be OK in some situations, but it's not the right thing for Gloria! What if the Colonel turns up at the farm and Gloria needs to hide behind a tree or something? She'd be rooted to the spot whilst her little chicken tummy digests the worm, the Colonel spots an easy picking and before you can say "Bargain Bucket", she's being served up in gravy and enjoyed with a hot butter biscuit.

Poor Gloria.

Chickens and computers have an awful lot in common. Which is something I never imagined myself typing at any time but honestly they do! Just like Gloria and her digestive system, input and output operations on a computer can be really slow, especially when compared to the processing of data. Take for example an I/O device like a hard drive seeking a track to read or write, or something that has to physically move. That request for a particular operation could take ten milliseconds to perform, which doesn't sound like a long time but when compared to the simple switching of an electric current in a one gigahertz processor it's snail pace. In fact, in that time the processor could've performed ten million instruction-processing cycles! That's a lotta worms!

Leaving Gloria behind now and returning fully to the world of computing, let's clarify asynchronous and synchronous I/O in practice. As we know, with asynchronous I/O processing your code continues executing after one element sends a particular message/calls a function/whatever. Whereas with synchronous I/O your code sends a message/calls a function/whatever but then it is blocked until an answer/response/whatever arrives. This could be seconds, minutes, hours, days.......you get the idea!

But you likely want your asynchronous I/O request to perform a certain task after it has received the answer/response/whatever, right? So to do this we can include a callback function which will only execute when the answer/response to the message/request/function/whatever arrives. This could be seconds, minutes, hours, days......

Here we have a button which after it has been clicked will execute the callback function on line 2. The rest of your code can carry on and do what it wants to do, but after you click that button the callback function will come into play.

It is also possible to use a timeout function in your asynchronous request, this would call a function or execute some code after a specified delay. In JavaScript we could use 'setTimeout', like this...

...which will display 'Boom!' after 2000 milliseconds have passed. With JavaScript built into browsers this could be a useful tool to display a pop-up to a webpage visitor after they have been browsing the page for a certain amount of time.

Now, anyone fancy KFC?

Functional JavaScript: Scope and Hoisting

JavaScript: putting the fun in functional since 1995!

With so much function going down it's hardly surprising that JavaScript is a functional language.

But what do we mean by that?

Well a function is kinda like an independent mini-program within a program. And so any variables you create inside a function only have meaning inside that function. When the function finishes, the variables disappear - as in they will not be carried over into subsequent functions. This is actually a really good thing as a JavaScript program could have hundreds or thousands of variables and would become very difficult to keep track of if they all carried over into the other functions. It means we can re-use variable names within other functions and it won't cause problems elsewhere. These variables are known as local variables.

There's also another type of variable known as a global variable. Unsurprisingly these global variables are defined at the main script level and are available to use inside each function.

The concept of local vs global variables is referred to as scope.

Slightly confusingly, in JavaScript a variable can used before it's been declared. This is because JavaScript moves all declarations to the top of the current function - this is called hoisting.

Hoisting is often an overlooked area of JavaScript, and just because something can be done doesn't mean it necessarily should. And, indeed, the example above will return an error. This is because only the declaration (var y), not the initialization (= 7) is hoisted to the top. So you could put var y lower in the script, but you can't initialize it with, in this case = 7, and expect a result.

And really, for anyone reading your code surely it would be better to declare your variables before calling them? And since this is how JavaScript interprets the code (after it has 'hoisted' the variable) then it's always a better rule to follow!

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....

Wasted Days?

I want to share my experience of the last couple of days on the Makers Academy Ronin course. It's been a very difficult time and I hope by putting this out there I may be able to help others who hit that wall of frustration and feel it's just not worth it. 

Because it really, really is!

The last 48 hours of the Makers Academy Ronin course have been the most frustrating couple of days I've experienced. By Tuesday afternoon the constant barrage of problem after problem finally got the better of me, and I admit I was pretty pissed off with the whole Makers approach to teaching/learning.

I'm not going to go into all the issues apart from to say I've spent two days STUCK!

Of course I'd been stuck before, but nothing like this. Most, well really all of the problems came about because I am doing the course on Nitrous - coding in the cloud. It hadn't really been an issue so far. I usually have to google a few additional steps to get things to run, but I was used to that. I really like Nitrous, having everything on the one screen works for me.

But this week Nitrous didn't want to play. And it wasn't just me who was having trouble. The guys doing the course on Linux were experiencing similar issues.

Two days of  - Googling. Trying. Failing. Googling. Trying. Failing. And repeat to fade...

Two days without getting past Step 0 of the week's challenge. Very very frustrating.

Of course we asked our tutor for help, and some came, but not instantly and not anywhere near as much as I felt I should be getting. We were always asked to theorise why the problem was happening. But I didn't want to offer a theory as to why things weren't working - I just wanted them working!!! I wanted to get on with the challenge and not fall behind. We were constantly reminded that problem solving is a major part of web development, and we should be pleased that we were solving some issues. But the mindset I was in, I couldn't see that at all. I just felt that I'm paying for this course and I can't do the bloody thing as I can't install the gems/software needed, and if I do I can't get then to talk to each other or work properly, and we're largely being left on our own to find out why.

We were told that the offline guys were not having these issues - mainly because they are all using macs! Well bully for them! It was no consolation, and I think it just pissed me off a little bit more. I can't afford to rush out and buy a mac so this is the only option I have.

By the time of the Tuesday afternoon standup I'd just about had it, and by 5pm I checked out still at Step 0! Feeling I'd wasted two days.

After dinner I sat back at my laptop. Still a bit pissed, I had no intention of coding instead I thought I'd catch up on my woefully neglected blog as I have half a dozen posts scribbled on paper that I needed to write up. Once opened I looked back at a blog post I'd written on Day 1 of the course. I re-read something that really hit home. It was something we were told...

For the vast majority of this course we will be stuck!

And that's OK. Because a developer spends his day solving problems, some of which have likely never been tackled by anyone else before. It's the job.

I realised that for the last two days I'd basically been working more in line with how, I assume, an actual web developer would most likely be working. He hasn't got anyone there to hold his hand through a challenging issue, all he has is his ability to search for answers by offering the correct questions.

Here's the real challenge though. And it involves changing your mindset towards this unique learning experience.

As I said I'm paying for this course, so naturally you want to get as much out of it as you can, and naturally if you aren't progressing it's easy to feel as if you're wasting both your time and money. I think that's where all my frustrations were coming from, as if I'd been working for a company I'd have come out of the previous 48 hours feeling as if I'd really really earned my pay, as even though new problems arose, I had fixed multiple issues that were absolute bastards!


I suddenly got it. Being able to theorise the exact nature of the problem, being able to break it down into smaller issues (rather than googling a specific error message which is likely not going to offer results) and methodically attack them one at a time is a huge step towards success. Makers aren't getting us ready for an exam, they are getting us ready for a career as a web developer. And I knew that, or at least I'd read and been told that. But again, it's quite natural to get frustrated with the system if you feel that the person you're paying to teach you something isn't actually teaching you something. But Makers is not traditional learning. Our tutor would be doing us no favours by constantly jumping in, waving a magic coding wand (I want one of them) and fixing things, because in a couple of months time when the course is finished who would we call then? What do I say in an interview when asked how I'd solve a problem? "Er, I'd call Sam?".

If anything my two "wasted days" had potentially been the two most important days of the course so far.

I willfully neglected my blog again and spent three hours problem solving. Maybe it was my switch in mindset, I don't know, but I ended Tuesday night with everything set-up and working. I completed all of the first stage of the challenge. The program racked up fine, and I deployed to Heroku.

Heroku didn't want to play. And I was stuck again!

And you know what? That's fine. I went to bed looking forward to solving it in the morning. (And I did).

I'm approaching every day now with the philosophy that there will be problems. Many of them will be utter bastards. But I'll end each day having beaten some of them in to submission. Whether that's here on the Makers Academy Ronin course or in a career as a web developer.

If It Looks Like A Duck....

See that ^ .

Yeah, that duck up there typing. It's not some abstract visual metaphor for how I'm getting on with the Makers Academy Ronin course, rather a term we've been asked to look into.

What is 'Duck Typing'?

Well someone who knows what they're talking about might respond that in computer programming with object-oriented programming languages, duck typing is a layer of programming language and design rules on top of typing. Typing is concerned with assigning a type to any object. Duck typing is concerned with establishing the suitability of an object for some purpose.

Although I'm more partial to the description - if it walks like a duck and swims like a duck and quacks like a duck, I'll call it a duck!

Simply put the term Duck Typing in coding refers to the fact that you don't need a type in order to invoke an existing method on an object - if a method is defined on it, you can invoke it.

So how does this work in Ruby?

Say we have a class Duck

And a class Person

And we define these methods

If we call 'game' what will we see?

You may think that 'in_the_forest john' will not work as we've only defined the method 'in_the_forest' with '(duck)' as an argument. But Ruby doesn't care what the argument is, and so if, in our case, the new Person can quack and has feathers then Ruby goes with it - if it looks like a duck and quacks like a duck it must be a duck, right?

So our output reads -

Quaaaaaack!
The duck has white and gray feathers.
The person imitates a duck.
The person takes a feather from the ground and shows it.

Duck Typing saves time on writing code, as we only need to be concerned with ensuring that objects behave as demanded of them in a given context, rather than ensuring that they are of a specific type.

It's OK To Be Stuck

So the first day of my Makers Academy Ronin course, which will see me undertake an intensive 12 week coding course, involved........ absolutely no coding!

And you know what?

That was fine with me!

The pre-course had been quite intense, I think more so than was advertised, and so today was kinda perfect. To step back, think about what we had learned on our own(-ish), and find out how that will be applied in the coming weeks.

We also got a good chance to meet (virtually) all the other Ronin cohorts, and the off-line students in London. Several introduction/team-work/bonding games we're played - one involving spaghetti and marshmallows (which resulted in my laptop covered in marshmallow goo - nice!) - and we were told something really important.

For the vast majority of this course we will be stuck!

And that's OK. Because a developer spends his day solving problems, some of which have likely never been tackled by anyone else before. It's the job.

Our coding course is really just 12 weeks of problem solving, but solving those problems through writing code. And I can't wait to get started...