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

Pangs of guilt

Tomorrow morning, 9am, I start a 12 week intensive course in coding.

Oh my god!

I've just completed a 4 week pretty-intensive pre-course, where weeks 3 and 4 were especially full-on, but the enormity of the upcoming task is only starting to really hit me now, and I've been feeling terribly guilty about it these past few days.

I'm 44, married with three wonderful daughters. They are my life, and everyday there is something amazing about them. I'm with them all most of the time, and there are so many things I'm going to miss. Just simple things like sharing a story with my youngest when she's sleepy in the middle of the afternoon, or picking my 8 yr old up from school and singing Uptown Funk in the car on the way home (I haven't reached the 'embarrassing dad' stage yet so I'm making the most of it), or attending a sports day (which I'm going to miss - ouch), or playing LEGO Star Wars with my eldest on a rainy day. Not doing these little things is going to be the hardest, I think.

Their school holidays are around the corner, and I'm going to miss most of it as I'll be locked away coding. It's obviously my choice, and I really do want to do this. I also want to get the most out of it, but I guess I'm only just starting to feel the weight of the huge sacrifices I always knew were coming. We're going to have to fit a lot of fun into the weekends. I'm going to have to get as much as I can out of the early mornings and 'bedtimes' with them. It's going to be very hard.

On a much less guilty note, but upsetting in a different way, I've also had to hand over the reigns to my other baby. I've been running WarpedFactor for the last 18 months, and as well as being ultra proud of the success the site has had, I've also made some good friends through it. People I talk to most days, but I suspect I won't have time to chat much over the next three months - well at least not about anything but coding! It'll be very strange not having that geek outlet in my life. I guess it's radical changes all round.

I'm sure I'm not the only person who has felt like this when starting something as completely insane as learning to become a web developer in just 12 weeks (every time I say it - madness!), and I won't be the last. But in this instance I don't care about anyone else, it's a personal thing and these new-found pangs of guilt just add to the difficulty of the task ahead.

It's an old cliche but the last few days really have been a roller-coaster of emotions. I'm excited. It's scary. I can't wait to get started. What the hell am I doing? This is the greatest thing ever! I feel guilty. All of this, and rinse and repeat. But I'm also quietly confident that I'll come out of it the other side and realise it was absolutely all worth it, and very likely the best thing I've ever undertaken career wise. That is what I have to keep telling myself.

So here we go. Head first into the abyss...

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

Excursion on the Version!

I've found week 2 of the Makers Academy pre-course has been a lot more straightforward than week 1, mainly because 90% of the issues I had last week were caused by 'not having a mac'. After I'd sorted all the ins and the outs of using Nitrous as a coding platform it's all been going OK (famous last words!!!). I mean, it's still a challenge, but I feel less stressed with it all and am really enjoying the learning process.

So what have we been learning about? Well, Version Control, which is the management of changes to code, documents, computer programs, and other collections of information. We've been using Git locally on our computers and the web service GitHub to push/pull our code to - which is essentially backing it up and accessing it remotely.

Version Control is something I'd never used before, or even heard of, so it's been very enlightening. One of the most useful things this week was the Git Immersion course in which we found out all about Branching, using Alias', and being able to collaborate on each others codes via GitHub.

In short, I'm no expert but I'm finishing the week feeling quietly confident that I understand what we're supposed to right now. Which must be good, right? Plus with pretty much everything we've done this week I can see how useful it'll all be for any future projects (and hopefully career).

Roll on week 3...

A Journey Into Coding - The Beginning

Hello

It's Friday. 5 days into the Makers Academy pre-course. It's been a week where at times I've stared at the screen wanting to pull my hair out. It's been a week where at times I've thought about smashing my laptop against the wall. It's also been a week where I've punched the air with delight as a challenge I thought I'd never complete comes together nicely. It's also been a week where every single day I've woken up and the first thing I've thought about is coding. 5 days into the Makers Academy pre-course and I'm an addict.

I've always been fascinated with what goes on behind the scenes of computer games and apps. I'd mastered Sinclair Basic, on my old ZX Spectrum, what feels like 150 years ago now! Life then got in the way of computing, but when I had the chance I taught myself HTML just because it was something I wanted to learn. I mainly used the Dummies guide books, but also started looking at the page source of various websites to figure out how they achieved certain things. I then took that knowledge and adapted it for my own purposes, and although at no point in time have I ever considered myself to be anywhere near professional, I have built several sites for myself, family members and friends.

After discovering Scratch I lost weeks coding with it, and followed several online guides to learn as much as I could about it. I've moved onto several other languages, including dabbling in a little Java programming, some Visual Basic, and PHP/MySQL, and again this was all from reference guide books. I loved it all, and wanted to learn more. More than that though, I felt this was something I could see myself doing for the remainder of my working days.

My wife had mentioned Makers Academy to me some time back, someone she knew had quit their well paying job to go on a three month coding course, and they loved it. I knew Makers Academy was based in London, and I didn't realistically think that I could be there 5 days a week for three months, but they recently launched an online coding course, Makers Academy Ronin, and it seemed perfect for me.

It's not a qualification course. There are no certificates upon completion. They don't teach you to pass exams. Instead they teach you the skills you need to become a developer. You are immersed in an intense 60 hour week (and the rest) for 12 weeks, getting you where you need to be as an entry level developer.

Makers Academy are super selective too. I guess you need the right mindset for both coding and this kind of intense course. After applying I was sent about 20 hours worth of material to go through, and about 3 days to do it in. Turns out I knew a lot less than I thought I did, but I got there and loved every minute. I then had my interview and was over the moon when I was accepted onto the July 2015 Ronin cohort.

 

As I said at the beginning, it's day 5 of a 4 week pre-course. I thought it would be a nice gentle introduction to how things are done. I was wrong. You can kiss your old life goodbye, you belong to coding now.

This week has largely been about learning how to use the command line, something I'd never really used until I received the interview material. To say I've learned a lot is an understatement. The course itself, from what I've seen of it so far, is really well designed. Increasing in difficulty gradually, with tasks that get you referring to earlier segments, meaning that you really do start to understand areas which at first seemed baffling. 

However, I am already a little concerned about falling behind. I've encountered so many issues because, unlike most other people on the course, I don't have a mac. I think half of my time this week has been lost to troubleshooting problems like this. But I guess it's good to get all these things out the way at the beginning.

I'm now coding in the cloud on Nitrous, which in itself took some time to get the hang of. I've set up and connected my github, and started pushing commits to it (I'm still getting the hang of much of the terminology, so forgive me if I get it wrong).

I've learned more in these 5 days than I ever could've believed possible just a week ago. I've certainly not mastered everything from the materials, but I'm quite determined to. 5 days in and I am absolutely hooked.

Now I must stop. There is coding to be done...