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.