Callum Anderson

Well here we are, one week down already! Technically, it's more than one week because we were given plenty of pre-course work to do; to make sure we were all ready for the starting line. That consisted of:

• How to use a Mac (loads of us are Apple newbies, including myself). This includes learning keyboard shortcuts, which are vital.
• UNIX commands (ie. how to type stuff into a terminal to work with files/folders, instead of using the mouse). It's faster.
• Using Git/Github - which is a version control system to track changes to files you, or your colleagues, are working on.
• Getting your typing speeds up - normal and coding speeds. You need to use all those other symbols on the keyboard when coding, the ones you'd normally never touch.
• Completing courses on Codeacademy - mainly the HTML, CSS and Ruby tracks.

If you don't ask, the answer is no.

The actual lessons are quite engaging and interactive - questions are encouraged; and I certainly take good advantage of this. We also get a quick 5-10 minute break every hour which does help to "cool the brain". It's really unlike any other classroom environment I've ever been in - including college and university. The instructors are super chilled, and approachable. It almost feels like they're volunteering to do this, rather than it being their paying job. There are 3 instructors in the room as well, with 1 leading at any time while the other 2 chip in occasionally from the back of the room.

We are assigned homework at the end of the day, which consists of a MVP (Minimal Viable Product - a term used in the industry) and Extensions (going that bit further). The Extensions are optional, but I managed to complete them all in the first week. In the mornings, we have a "stand up" first thing, where we all stand in a circle, pass a ball around (only the person with the ball can speak), and share what went well or didn't go well the previous day. This is something that is done in Agile software development companies, and you're encouraged to share any issues you have. I haven't really brought any problems to the table yet, but I've no doubt I will in future. I like it, it's a great way to start the day. This is followed by a homework review, which is really about addressing any problems anyone had, rather than going over all of it.

Friday was a bit of a break from coding. We had a lesson about active learning, which was very interesting and definitely useful going forward. Then we had a talk from a previous student (Kate), as mentioned earlier, who has gone on to work in a local tech startup. She was fantastic, very down to earth and has a great sense of humour. She also allayed a lot of fears some of us had. She is the only "junior" developer in her firm, and I asked her if she was intimidated by that. She said she wasn't really, because her manager simply doesn't expect the same level of output from her. I guess that makes sense.

We are issued our weekend homework in the afternoon, and some of the guys do it before going home (or as much as they can), and some of us decided to do it all at home. I did the latter this week, but mainly because my stomach was a bit iffy from the previous night's activities! The homework wasn't too bad though. On to week 2!

We started on Monday with a "stand up" as always, and generally everyone felt the homework was manageable. It wasn't quite how I anticipated it to be, after reading other CodeClanners' blogs. I got the impression that homework would be 2-3 hours per night, and maybe 5-10 hours over the weekend. I shouldn't speak too soon - that might be still to come! We were then given 1 to 1 sessions with an instructor (out on the comfy seats!) to go over the homework and talk through any problems we might have. That took up most of the morning, and to be honest, it was nice to have a gentle start to the week. I didn't sleep so well on Sunday night, and I was thankful for the free coffee supply at CodeClan.

We had another lab in the afternoon with a similar real world scenario - this time it was a bus picking up passengers from a bus stop. The number of people at the bus stop changes at every pickup, as does the number of people on the bus. That one was kind of fun actually, and we were to continue with it in the homework. A comfortable week, up to this point...

Wednesday was a bit different, as we were given an all-day lab following the homework review. Again, we were paired up, and had from 11am until 3:30pm to complete our task. We had to manage our own breaks, and I must say I'm not great at taking breaks when I'm focused on something. We did both agree that we should take a proper time-out for lunch, to eat and get some fresh air to clear the head. On that point - that is something I've resolved to do throughout. I've taken to walking down to Princes Street gardens to get away from the noise and pollution, and to just empty the mind of all thoughts. It really works - I come back into class refreshed and ready to go again!

Do you want to build a Snowman?

Anyway... back to the lab - we were given the choice of two tasks. The first was to create a pub, which obviously has drinks, food, and customers. We had to include a check to make sure the customer is over 18 before serving drinks, and to refuse to serve them if they're drunk (their "drunkenness" level goes up each time they buy a drink, and down if they buy food).
The other task was to build a Snowman game, which is essentially about guessing a hidden word. We had to output a word to the screen in asterisks, and each time the player guessed a letter, it would be uncovered. If they guess wrongly, they'd lose a life. I think it's called Snowman because the snowman melts a bit at each wrong guess... I've always known it as Hangman, but maybe that's no longer politically correct? So again, the premise sounds very simple, but it was much more difficult than the pub task. We wanted a challenge, so opted for the Snowman task.
By 3:30, we had the crux of the game down, but we were still about 15 minutes away from putting it together into a functioning programme. Argh!! When we returned to class, we were surprised to find that we had to present our workings to the class. It was so frustrating not having the final result there to demo, but that's the way the cookie crumbles.

We were handed our homework after stand up on Friday, and started on that at about 10:30. Most of us headed out to the lounge area, it just makes for a nice change of scenery from the classroom. The task this weekend was to create a sort of karaoke club management system. So, the club would have a bar, private rooms, guests/punters, songs/playlists and drink/food. So, similar to the pub task on Wednesday in many ways, but ramped up a bit. I got the core part of it (Minimum Viable Product) done before heading home. It's strongly recommended that you make a good start on the homework on Friday before leaving, as the instructors can't really help you if you're at home. Makes sense!

A developer from a company called AIRTS came in to give us a talk at lunchtime, which is apparently a regular thing on Fridays. His company have employed about 5 CodeClan graduates to date, and he was really encouraging, and gave good insights into the industry. Very down to earth too.

Over the weekend, I worked on advanced elements of the Karaoke Club task. I thought about bringing it alive, and making it into a text-based menu system, but decided against it! I thought I'd use the remaining time over the weekend to look at other learning support sites that have been recommended to us. Namely Exercism and Code Wars. Both are community based sites that provide coding challenges, which can be completed in various ways. It's great to see the alternative solutions, they could come in handy in future! So that's it, on to week 3 of the long and winding code!

Into week 3 and admittedly the novelty has worn off a little, but I'm still enjoying it a great deal. When I got in on Monday morning, we had our usual catch up before the instructors arrived. Most of us agreed that it was so much easier getting out of bed in the mornings; we all chose to be there and have the same desire to learn.

We started the week with an introduction to database queries, in the form of PostgreSQL. For those unfamiliar with the concept of databases, it's essentially like a collection of data tables that connect with each other. SQL (Structured Query Language) is the set of instructions you give to the database to get data back. Up to this point, everything we've coded has only lived in memory. In other words, you can run the program and make changes, but it's all reset/lost once you close it. Now, we're able to save information into the database to call on again later. This is known as data "persistence". OK, the database is stored on our laptops and only we can get to it; but it's still an important milestone!

The task for the lab on Wednesday was to create a music database. Right up my street! I'm hoping to learn how to build an app to help manage my music collection - which is all in MP3 format - after this course. I don't tend to stream music from services such as Spotify, just because I like to listen to exactly what I want and where I want; with or without an Internet connection. I don't like the idea of Spotify (other streaming services are available) suddenly removing music from a playlist I've taken the time to create. So that's a bit of a personal goal for "later".

The Logical Songs

Anyway, the lab task was to create a music database containing artists and albums. We had to write methods (otherwise known as functions - which is just a piece of code that "does something") to add, update, display or delete artists or albums. The tricky part here was that if you delete an artist, all albums by that album would have to be deleted automatically too. The same goes for albums - if you delete all albums by an artist, that artist had to go. This is why the tables have to talk to each other, because otherwise they'd become horribly out of sync! When I got home, I decided to import a portion of my music collection into the database to test it out. That took longer than I thought it would. I suppose I wanted to validate it, by giving it a real world use.
I might add that it took me twice as long to get home because there was a concert on in Princes St gardens, as part of the Edinburgh Fringe festival. Rag 'n' Bone Man, I'm told. I usually cut through the gardens to get to CodeClan, but they were closed off. The buses also struggled to get through because Princes Street was mobbed. It made for a very long day.

I arrived fully recharged and full of vigor on Friday. No need for coffee, so I had some mint tea while the homework was handed out. There is a whiteboard at the back of the classroom where we can write down anything we'd like to go over again on Friday, but so far we haven't needed to do that.

There was a talk at noon from National Records of Scotland, which was very interesting. They handle birth, death and marriage certificates; as well as the national census which takes place every decade. They hold records dating back to the 12th century, so you can imagine digitization is high on the agenda for them these days.
There were a couple of questions asked by students at the end, which sparked a discussion about the pros and cons of working in the public sector; as opposed to the private sector. Their director of IT was there, and he told us that he took a considerable pay cut when he left Tesco to join them, and that he has no regrets because he enjoys his job more now. That's very much how I feel - I want to do something I'm passionate about.

Homework for the weekend was similar to what we've been doing for most of the week. This time we had to build a cinema, with films and customers. We'd use cinema tickets to connect the two, and the homework extensions involved adding screening times. That was the most challenging part because - for the first time - we were using more than 3 tables in the database. And that's a wrap for week 3!

Monday was a break from the norm this week. Our laptops were cast aside and replaced with a notepad and pen, to learn all about "UX". UX means "User Experience", and it's about considering what the user, well, experiences when using your software. The most obvious part of that is the usability - is it clear what to click on, how to find things etc. It should be intuitive.

Beyond that - and perhaps more importantly - is the consideration of people who might have a disability. The most common example would be sight. So, make sure font sizes aren't too small (or that there is some way for the user to increase the size). It's common sense, really.
Then there are other important accessibility concerns. Blind or partially sighted users might use a screen reader, which is software that reads out what's on the screen. If there is no order or structure to your content, it will make no sense to them when read out loud. Deaf people can't hear audible alerts or messages. People with reduced motor functions might take a longer time to type things or move the mouse. One of the examples we were given was prompting the user to enter their password or email address twice. It's annoying for most users, but much worse than that for others.

The final message of the day was that everyone in the software development chain should be thinking about UX - not just the design team. I completely agree!

There was a bit of a change in the air on Thursday, as everyone knew we were to receive our project brief by the end of the day. I must admit I was a little excited, to put into practice everything we'd learned over the first 4 weeks. Before we got to that, we were shown a simple "Zombies" web app which listed zombies, victims, and who bit who. You could add a "biting" as well, by selecting a zombie and a victim. Isn't that what everyone wants in a web app?!

The reason we were shown that was to give us an idea of what we're aiming for on our projects. It wasn't so much what you could see or do on the webpage, but what was going on beneath the bonnet.
And then, finally, we were assigned our projects! Well, I say assigned, but we were given choices and got to pick one. The choices were:

• A shop stock/inventory management app
• A museum or art gallery exhibition management app
• A gym members management app
• A personal spending tracker app

I opted for the gym members management app, partly because my brother is thinking about opening his own gym. I already had a rough idea of what to include in the app.

As much as we were all keen to get started on Friday, we were strongly encouraged to avoid coding anything until we had spent at least a day planning the project. Apparently 1 hour of planning saves 4 hours of coding. We decided to split into groups for the initial planning, so I sat with the other 3 students who picked the gym project and we thrashed out the basic outline together.

We also had a quick lesson on managing change, which was interesting. It revolved around the terms "success" and "failure", and what they mean to you. We were shown this video, and the gist of it is that you shouldn't think you've failed. You should think you haven't succeeded yet.

After that, I disappeared into the weekend with my project, which is shaping up pretty well at this point. In fact, Im posting this blog entry a day later than usual, because I prioritised the project. More on that very soon!

Week 5 was solo project week, which I had been looking forward to. It was a chance to put everything together in one fully functional app. Well, that was the aim, at least. I'd spent the weekend getting the crux of it together, and I was well on schedule by Monday morning. The objective was to create a web-based app which would allow a gym manager to manage the members and classes running at the gym. More specifically, they'd need to see a list of all gym members and a list of all classes. They should also be able to update details for any member or class, delete them entirely, or add/remove a member from a class.

On Wednesday, we all had a 1 to 1 with the UX (User Experience) instructor. This was largely informal, and the purpose was to receive guidance and a few pointers on our apps. The advice given to me was to simplify it a bit. I had tried to maximise the use of horizontal screen space to avoid scrolling, but apparently that shouldn't be a concern at this stage. I'm not sure I entirely agree with that, but I put my faith in the resident expert!

We all had another 1 to 1 with an instructor on Thursday too, which was a code review this time. This would have been a bad time to find out if anything was drastically wrong with it. Fortunately, it was all approved, but I did receive a few tips about using validation at the front end. More specifically, when a user completes a form on the app, there should be checks to make sure the data they're entering makes sense. Even more specifically, this includes ensuring there are no blank fields, numbers are within a specified range, and that a valid email address has been entered (although it only really checks for "@" in the middle).

Always explain, never feign

On Friday, it was time to present our projects to the rest of the class. We had 10 minutes to talk through the project and demo the app, and 5 minutes to answer any questions. There are 18 students in the class, so it took the best part of the day. To add a bit of fun to proceedings, we were allowed to pick a song to play as we got up to present. I picked the theme tune to Curb Your Enthusiasm, just to lighten the mood a bit! Those who didn't choose a song were assigned random kids TV show themes - I think "Thunderbirds" and "Bananas In Pyjamas" were chosen for them.

I was up second from last, and by that time everyone looked a little weary and less questions were being asked at the end of the presentations. I'm not sure whether this was a good thing or not! I do have presenting experience so I was quite prepared and confident, but I've never had to demo code before. It was quite a challenge switching between the working app and the code behind it, to demonstrate what was actually going on. I couldn't really gauge whether everyone understood what I was showing them; they were all very quiet by this point for reasons mentioned previously. Anyway, I believe we are going to be taught "how to present tech" soon, so that should be of great help.

The final app is up and running at https://urgym.herokuapp.com/, if you'd like to take a look.

And that was it for another week, and that was also the final week working with Ruby. Next week is Javascript, which I'm really looking forward to.

In week 6, we really started to pick up the pace. It was a fresh start and an introduction to Javascript; which I do have some experience in. We covered the basics on Monday - namely variables, loops, arrays, objects and functions. These are essentially the core building blocks of most programming languages. It makes it easier to pick up a new language once you know the principles behind them, as you just need to learn how these principles are applied. I guess it's similar to linguistics - most languages use verbs, nouns, adjectives. You just have to know how to use them and string them together.

On Tuesday, we learned about constructors and prototypes, which sound complicated but are really Javascript's implementation of "classes". I mentioned before that classes are like blueprints, which define what an object should do. We also learned about Behaviour Driven Development (BDD), which is very similar to Test Driven Development (TDD). The concept is quite simple - you start with a behaviour that your program should have. For example - "it should return the square root of a number". You then write the code to satisfy that condition. We used a framework called Mocha to achieve this. I've no idea why it's called that, I'm guessing the developers who created it were fans of the drink!

The task for the homework was to write code for a dinosaur park. This would determine the most popular dinosaurs, daily and annual revenue etc. We were given the behaviour tests - such as "it should calculate the total visitors per year". Then we were to write the code to achieve that.

That was pretty much it for the week. We got our homework on Friday morning, followed by a presentation from the Codeclan CEO about "how to present tech". This was reasonably useful, although most of it was centred around how to present in general. Knowing who your audience are is vital, in any case.
As things weren't too hectic, I took a trip up to Morningside to have lunch with my old workmates in the Astley Ainslie canteen. It was great to see them, it somehow seems like longer than 6 weeks since I saw them last. I got back to Codeclan in time to see the graduation presentation for Cohort E22. I was impressed by the camaraderie within their group, they seem to have bonded well. Our cohort hasn't reached that level yet, I wondered if we would by the end of the course.

The homework for the weekend involved making a one page app which presented the user with a form, and then output everything on that form to a window. It was to be a list of items with a dropdown menu of some sort. I decided to create a "playlist maker", which allows you to submit a music playlist and each playlist would be added to the page. It was relatively easy, to be honest.

That was it for the week, although I got the distinct impression that things were starting to ramp up in difficulty. Which is, of course, a good thing.

We didn't realise it on Monday, but we were about to embark on one of the most difficult weeks of the course. "Notoriously difficult", we were told later! Incidentally, I don't think I've mentioned that we are the first cohort to be taught Javascript before Java - every other cohort to date has been taught Java first (that's 30 cohorts prior to us, in case you're wondering). I'm not sure why it was changed, but I actually don't mind as I've used Javascript before.

So, the first thing on the agenda was a modular pattern known as "PubSub". We covered "events" in the previous week, which are things that happen on the webpage - such as a click or scroll event. The idea behind PubSub is to split your code up into areas which publish events, and areas which subscribe to published events. Let's say you had a text input that you fill out, click a button, and then that text appears on the page. PubSub allows you to publish that text as an event, which your code can subscribe to and output it to the page. It involves splitting your code up across multiple files, all of which have to talk to each other. We were wondering if it was worth the effort; when we could easily do the same thing in a single file! We were assured that when you scale up your apps into more complexity, the PubSub pattern really starts to pay off.

Things got a little more exciting on Wednesday, when we were introduced to APIs. API stands for Application Programming Interface. I think the last word - interface - describes them best. Basically, that's what they are - interfaces provided for you to connect to another application. In actual fact, most people will be more familiar with them than they might think. If you've ever been on a webpage and noticed a Facebook or Twitter feed integrated into it - that's achieved by using an API.
Our first attempt at connecting via an API involved retrieving information about the countries of the world, and then filtering through it to find regions, continents etc. This information is provided for free at https://restcountries.eu/. I have no idea why it's provided for free, but we were all as grateful as we were impressed. There are actually loads of free APIs you can use, as we were to discover later. Anyway, we were able to connect to the API, retrieve the full list of countries; and then filter that on the webpage in order to display a particular country and the associated information. We even managed to get the flag of that country to display as an image. One of my classmates told me that she showed it to her grandchildren when she got home, and that they were thoroughly entertained by it! That's actually quite something, in this world full of apps and on-demand content.

By Thursday, we were all fairly well acquainted with both PubSub and APIs, I think. There was one more topic to cover this week, which was a fairly new Javascript feature called "promises". These are related to requests made to APIs, and are quite aptly named. They're used to execute code once a response has been received from an API. Clearly, a response won't be received instantly, unless you have a super fast connection. Even then, there will be a small delay. Javascript is an asynchronous language, which essentially means that it doesn't wait for one line of code to complete before moving on to the next. This is, of course, a good thing. As Javascript is mainly used for webpages, you can imagine how slow pages would load if it only processed one line of code at any one time before moving on to the next. This is also known as a non-blocking language. As I said, it is a good thing, but it does make it tricky if you need lines of code to run in a specific and timed sequence. That's where promises help - as the next line of code related to that API request will run when the response from the request is received. I suppose it is exactly as it sounds - "I promise to do this when I get the response".

I can move.repeat(3) any mountain

The afternoon lab was a bit tricky. We were to connect to an API returning a collection of all the Munros (ie. mountains in Scotland over 3000 feet tall). That wasn't the tricky part; the challenge lay in trying to filter by region and being able to return to the unfiltered list again. We were paired up for this lab, and unfortunately we didn't quite complete the entire exercise. In fact, I don't think anybody did. It was really bugging me though, because we were so close.
I forgot to mention that a new cohort started this week - E24 - so we were no longer the newbies! As per our first week, we were all invited to the local pub (The Chanter) to get to know each other at the end of the day. I had hoped to speak to some of the new guys, but unfortunately we were assigned three big tables and the new cohort congregated around one table; so it was difficult to chat to them. Never mind, I found myself sitting next to some of the instructors, and inevitably found myself in the middle of a debate about which methods performed best when sorting data. Just your usual pub chat! I didn't stay long though - I wanted to get home to have another go at the Munros task. I did manage to complete it this time, which was quite satisfying.

Our homework issued on Friday morning involved researching and choosing an API, and then creating a webpage which connects to that API. I had a quick look over a list of free APIs, before heading out to the main area to attend a talk from The List. If you're not familiar, they essentially provide a "list" of events taking place in Edinburgh and Glasgow mainly, but have expanded out across the UK in recent times. The gentleman presenting (I didn't catch his name) was one of the original founders in 1985, and I was very impressed by his passion and enthusiasm. There was more to it than simply listing events too. For example, the police and transport services subscribe to them to receive information about which events are taking place, and the numbers expected to attend. Hotels are also interested, to manage yield. That probably explains why hotel prices shoot up whenever something is happening in that area on a particular date.
He mentioned that they're looking for staff who would be a good fit there (ie. "List-y"). Apparently, one of the questions they ask at interviews is which event you last attended.

Onwards to week 8 then - nearing the halfway point! I believe we're going to look at Javascript databases, in order to make our apps "full stack".

Week 8, and I should start by saying it's been such a busy week! As mentioned previously, we started on Monday by looking at "back-end" Javascript functionality. In other words - the database and associated components that allow the app to save and load data. Everything we've done so far with Javascript exists in the browser only. If you refresh or close the page - everything is wiped and reset.

We began the day with an introduction to Express. This is a Javascript web app framework, which, in a nutshell, enables us to easily connect the front-end (everything in the browser) and the back-end (database - more on that shortly!).
Express allows you to "listen" for requests on your server. This is what happens on all web servers - they are in a permanent state of listening for requests from clients (ie. users navigating to a webpage in the browser). This wasn't too taxing, so we quickly moved on to the database lesson. We'd be using MongoDB, which - I'm reliably informed - stands for "humongous database". The biggest difference between this and SQL-based databases is that this one isn't relational. Everything in it is stored as a key-value pair, such as "name: Deborah" or "colour: red" etc. I'm over-simplifying it of course, but that's the principle behind it.
I should add that when I mention running a database and server - it's all running on the same computer in this case. You just configure your browser to point to it locally. This is for learning purposes only - it wouldn't make much sense to do that in a real-world scenario!

The homework for the night was to review a sample codebase for an app, which uses Express and MongoDB to connect a front-end webpage. A lot of it was new and quite daunting. I had to do a bit of research to try to figure out what some of the code was doing.

On Wednesday, we had another lab. This one would last all day, and again it was a paired lab. The task was to build a full-stack app from scratch - front-end and back-end. This was a big ask, and the difficulty depended on whether you challenged yourselves to do it from memory or refer to notes. Well, it was impossible to do it all from memory, but we decided to refer to notes only when we got stuck. Which was quite often, as it turned out!
The objective was to build a "Bucket List" app. It should allow you to create or delete bucket list items, and mark them as complete if they'd been done. We decided to go a step further, and allow the details of the bucket list item to be updated too. This proved to be a very difficult thing to achieve, as it involved making each item a form rather than just a read-only section. We didn't quite get it finished within class time, and my lab partner persuaded me to hang back afterwards to finish it. I was quite anxious to get home because there was a heavy storm outside. Roads were being closed and trains cancelled. I found out later that an entire windscreen blew off the front of a bus too! However, the draw of finishing the app proved too much; so I stayed behind and we managed to finish it.

By Thursday, there was an air of anxiety, excitement and anticipation setting in ahead of project week. I must say I was surprised when other members of my cohort told me that they were getting nervous, I couldn't really understand that. There is no "pressure", as such, and no minimum standard or benchmark - you just do the best you can. I don't know if they were perhaps considering that the project may be part of their final portfolio.

On Thursday morning, we re-visited Git and advanced Git commands. We've been using Git since day 1 as a version control system, and our daily homework is pushed up to Github so that the instructors can review it there. However, we are going to be working in groups over the coming week, so we'd need to learn how to use Git collaboratively. We have to avoid overwriting changes made to the project by our team members, and we have to keep a stable version of the project which we can revert back to if it all goes wrong!

There's an app for that...

Following the Git lesson, we were ceremonially sorted into our groups. We were asked to stand at the back of the classroom, and the instructors marked 5 tables for the groups. Our names were read out one at a time, along with which group we were to go to. There are 18 students in our class, so we ended up with groups of 3 or 4. I was in a group of 4, which might sound like an advantage but I'm not sure that it necessarily is! It would require a larger degree of coordination and communication, as we were to discover very soon...

The project briefs were announced next. We were to choose one as a team, although we could deviate from it slightly if approved by an instructor. The available briefs were:

• Education app - an interactive web app which displays information about a topic
• CO2 Calculator app - an interactive app which generates a carbon footprint score
• Browser game - an interactive game based on a traditional board or table game
• Stocks/shares app - an interactive app which shows stock or share values

After lunch, we got together as a group to decide what we were going to do and how we were going to achieve it. I was open to any of the briefs really, but probably a little more keen on the game or CO2 calculator. They were a little different from any of the previous labs we'd worked on. My teammates were in agreement, and we voted unanimously to take on the browser game. One of the teams in the previous cohort (E22) had attempted a version of Scrabble, and we all agreed that it was impressive!

Then we had to decide on which game to code. I suggested Play Your Cards Right (based on the TV show), and my teammates suggested Minesweeper, Snakes and Ladders, and Trivial Pursuit. We settled on Trivial Pursuit, largely because we knew of a quiz questions API which could provide the questions for us. The challenging part would be to create an interactive board, and then integrate that with the quiz questions and overall game flow.

At this stage, we needed a proof of concept so that we knew we would be able to achieve it. If we were biting off more than we could chew, we had to know before the weekend so that we could switch to something else. With that in mind, I went home and spent the evening working on the board logic. Without it, the game was literally a bust!

We decided to meet again on Sunday at a local coffee shop, as the Codeclan building is usually closed on Sundays. We hit our first snag at that point. When we parted on Friday, we hadn't been clear enough about which tasks we were all picking up over the weekend. This led to both myself and one of my teammates working on the board, which was time wasted. Never mind! Time was still on our side....

It didn't feel like a new week on Monday, as we'd all been working through the weekend and it was a continuation of the previous week. By this point, we had a working board which a single board piece could move around (clockwise only), and a question set of 6 different categories - books, history, music etc. We also had a graphic of a "pie", which is a circle with 6 triangles inside it. The intention was to use this as a representation of the player's score. The game will be won when a player has 6 pieces of pie.

I attempted to work this out programmatically, but I couldn't find a reliable and suitable algorithm to do it. I decided instead to map the board out, with each square assigned coordinates. These coordinates could then be used by the board piece to set the position. I also wanted to give the player the available board "move options" after rolling the die. I achieved this by mapping routes to each square, for a given number between 1 and 6. This was a very laborious and painstaking task. There are 33 squares, with 6 sets of routes to define for each one. Once it was done, doors would be opened to further functionality. The knowledge of this spurred me on!

We were well placed by Tuesday, with a semi-working game in the bag. It had to be finished by Thursday though, so I was conscious of time. We had to figure out how to make it multiplayer (2/3/4 players), and we still didn't have any way for a player to actually win. We also wanted to add a timer in, so that one player couldn't stay at the board indefinitely if they kept answering the questions correctly. If truth be told, I was against this idea! It happens in other games such as snooker; if a player is good enough to stay at the table and clear up. I relented to the will of my team though.

I spent Tuesday evening working on the addition of 3 and 4 player functionality. This was quite challenging. Up to now, the game logic worked by assuming that if player 1 isn't at the board, then player 2 is. It now had to be re-written to cycle through the players. I also had to put a block on someone entering player 1, 2 and 4 at the start screen. I'm not sure why they would, but if they did it would break it!

Pie in the Sky

I managed to get that done by Wednesday, and my teammates had added the timer as well as jazzing up the look of the game. I'd also added an instructions/"how to play" dropdown to the game, which could be toggled open or closed by clicking on a button. When I showed it to the rest of the team, they voted against that being available "in-play"; so I moved it to the start screen. One of my teammates had also added some cool fade-out and fade-in effects to the start screen and end screen, and a database connection was made later in the afternoon to include a highscores/leaderboard table on the end screen.
And that was it! We were all quite pleased with the final result.

My teammates decided to prank me by telling me that the presentation was a disaster as the quiz questions API went down. This would break the game, and I fell for it because it had gone down once or twice while we were developing the app. In fact, we'd discussed making an offline backup version, but didn't have time to implement it.
They eventually put me out of my misery - the presentation was a success!

If you'd like to take a look, the final version (minus database) is here:

     PIE IN THE SKY

It currently only works in Chrome at full screen resolution (ie. not mobile), but I may look into making it playable at all resolutions.
Edit 07/10/18: it now works OK in most devices and browsers!

Amazingly, we're into week 10 already. The last few weeks have flashed by, especially in comparison with the first few weeks which were relatively slow paced. This week, we'd be taking a step back from coding and preparing ourselves for life after CodeClan. In other words - thinking about getting a job.

We had a later start on Monday, which suited me as I was down south over the weekend visiting friends and family; and had only travelled back on Sunday afternoon/evening. We started with an "industry insights" lesson, which centred around what to expect from a typical interview for a tech-based job. We didn't go into general interview techniques, and instead discussed technical interviews and what might be asked of you. Apparently, it's not unusual to be given a task to carry out. You might even be paired up with someone on the interview panel, to assess how you work as part of a team. This might have seemed a little odd before I started this course, but it's not a strange concept now as we're often paired up in class to complete lab tasks.

In the spirit of that, we were split into small groups, assigned a task and given about 15-20 minutes to complete it. The task was to draw up plans to code the board game "Monopoly". I immediately thought back to our group project the previous week - Trivial Pursuit - which would help with the movement around the board. However, upon re-familiarising ourselves with the Monopoly rules, we quickly realised how complex the game is! There are little caveat rules in there - such as going to jail if you roll a double 6 twice in a row. Despite that, I think we made a decent attempt at mapping it out.

We spent the rest of the lesson going through some technical questions you might be asked at an interview. I realised that we didn't really cover much of the computer science "theory" in the course, as it's more about hands-on programming. This was an area I knew I'd have to improve on by myself in my spare time.

Gis a job, I can do that

We spent Tuesday going over our CV prep, and talking about LinkedIn. We discussed the pros and cons of LinkedIn, and concluded that it's largely down to how you use it. The more active you are, the more visible you are. Not all of us are entirely comfortable with self-marketing. I was pleased to hear that writing a blog can be helpful - I'm glad I took the time to do it now!

Wednesday was short and sweet, as it consisted mainly of an industry insights talk from the CodeClan CEO. She'd asked everyone on Friday to pick a local tech company and then do some research on them. Specifically - find out about their staffing, turnover/profits, funding, where they're based and what they do. I wasn't in on Friday, so I observed the findings of my classmates. The underlying lesson here was to do your homework on a potential employer, to find out if you're a good fit for each other. There's a big difference between a local startup company with just a few employees, and a large organisation with several branches and hundreds or thousands of employees on their books. There are potentially advantages and disadvantages for both - it depends what is important to you.

The talk ended with a video about combatting "imposter syndrome", and how to improve your confidence. That's not something that has or will affect me I shouldn't think, but it definitely did when I was a little younger and less experienced. I'm one of the (slightly) older students in the class - most are in their twenties.

There was a lot going on on Friday. First of all, it was CodeClan's 3rd anniversary - cue oodles of balloons and banners. There was a party planned that evening in a local bar to celebrate, which I immediately ruled myself out of going to because I had a 40th birthday party to go to on Saturday; two parties in a weekend would be too much for me at this moment in time!

Besides that, we all had our PDA exams to sit on Friday morning. I haven't really mentioned the PDA yet, which is the Professional Development Award. It's included as part of the course, and most of it involves collecting evidence to demonstrate that you understand software development principles. It typically consists of a screenshot of some code, including an explanation of what the code does. I'm not sure if the PDA is widely recognised to be honest. The way I see it, employers would rather see evidence of what you can do - and the PDA only really covers the very basics. Still, it's nice to have, and I believe you can use it as a base for further education - possibly at a college or university.

We had some more PDA tasks to complete for the weekend's homework, relating to unit testing and integration testing. Unit testing involves isolating a small section of code, whereas integration testing is about testing how two (or more) pieces of code work together. On to week 11 then, where we'll be starting on Java...

Week 11 was to be the first week of Java, and we made a start on Monday by going over the differences between Java and other languages we'd used; such as Ruby and JavaScript. Java is a statically typed language, which means that you have to declare the types of variables as well as the values. That is to say, if you want to use an integer - you have to state that it's an integer before using it. Ruby is a lot more forgiving as it determines the type of something for you.

After that, we spent some time setting up IntelliJ, which is an IDE (Integrated Development Environment). Up to now we'd been using Atom, which is essentially a jazzed up text editor adapted for coding. An IDE is a bit more than that - it has built-in tools such as debugging, testing and built/compile tools. You need an IDE to get the best out of Java because Java code needs to be compiled. The compiler translates the source code (the code you've typed) into code which can be executed by the computer (assembly code, or machine code).

We spent the rest of the day going over the basics of Java. Again, the principles are much the same as other languages. It's becoming a familiar pattern!

Our homework consisted of some fairly basic tasks involving setting up classes, for a water bottle, calculator and printer. The bottle and printer have properties (capacity, toner, paper etc), whereas the calculator only has methods (add, subtract, multiple, divide). It was all straight forward enough. In fact, I got most of it done on the bus journey home.

We moved on to more familiar concepts on Tuesday - collections. Again, much the same as in other languages. Arrays, hash maps and array lists. Arrays are fixed collections of things in a specific order. Hash maps are collections of things in key-value pairs, where you'd look up the values using the key. Array lists are slightly more flexible arrays. Basic arrays are a bit more rigid in Java.

The afternoon lab was a repeat of a lab we'd done before in Ruby. It involved setting up a bus, bus stop and passengers. It was another paired lab, which I do quite enjoy. If you're paired with someone, they often pick up on some things that you don't, and vice versa. We had to replicate a bus picking up passengers from a bus stop, which increases the number of passengers on the bus whilst decreasing the number of people at the bus stop. This all sounds very easy, but it's that little bit harder to reproduce this scenario in code. I say a little bit harder, but I think we all managed it comfortably enough.

For the homework, we had to build a library in code, which allows people to borrow books. The library would keep track of which books were out on loan, and each book would have its own properties such as its title and author. One of the challenges with object-oriented programming is deciding which class or object is responsible for what. For example, is the library responsible for loaning the book; or is the borrower responsible for borrowing it? Quite often, there isn't a right or wrong answer. So long as it works, and other coders can understand what you're doing.

Don't mention the war

Wednesday was a little strange, as we were assigned an all-day lab. I say it's strange because I didn't think we'd covered enough at that point in the week to justify spending a whole day practicing in a lab. I guess it was still useful though. The brief for the lab was to build a hotel, which enabled you to book guests into rooms, and check them in upon arrival etc. It was another paired lab, and I think we made a good attempt at it. We found out afterwards that we made things more difficult than necessary, by trying to ensure a guest had booked before checking in. It seemed logical to do that, otherwise the hotel would be something like Fawlty Towers! However, the solution revealed after the lab finished made no differentiation between booking and checking in.

We didn't have any homework as such, other than watching a video about IntelliJ. IntelliJ was the IDE application I mentioned previously. We had to learn about the debugging features built into it. It allows you to pause the code at any point, which is extremely useful to pinpoint any errors you might be receiving. Without it, you can only really look at the start point and end point of a piece of code. It might help to compare it to a stopcock and a tap. If you know the stopcock and tap are working, yet the pressure is low; you know there is probably a leak somewhere in between. IntelliJ would allow you to inspect any part of the pipework.

Thursday morning was interesting. We looked into the basics of algorithms, which is generally not something we'd be covering in the course as it's a computer science thing. An algorithm is a set of steps designed to achieve an output. You could write an algorithm to make a cup of tea, for example. It gets far more complex than that, of course, but you have to start somewhere. It is an area I'd like to explore after the course, if possible.

We spend the afternoon learning about Enums, which are basically used as "fixed" data sets in Java. If the values are never going to change, you'd consider assigning them as Enums. For example - all of the planets of the solar system, and their respective sizes. I realise as I'm typing this that it might not be the best example, as Pluto was fairly recently declassified as a planet!

Friday was a busy day. We got our homework as usual in the morning. It involved creating an airport, with a hangar and a collection of planes. You had to create flights, and assign passengers to the flights. I immediately thought of my Mum when I saw the assignment, as she is a bit of a plane spotter! I actually have a bit of knowledge about different airports and plane models from listening to her talking about it. I knew it would pay off at some point...

It felt like the Java section of the course was going relatively slowly as we entered week 12. I'm sure weren't covering anywhere near the same amount of content as we did when we started on JavaScript. My theory is that since they switched the order of the course around - Java used to be before JavaScript - they haven't refactored the course content to increase the complexity of Java as being the "final module".

I didn't make it in on Monday, unfortunately, as I had bathroom/DIY issues at home. I decided to work through the class notes from home, which thankfully didn't take too long. We were introduced to the concepts of inheritance and abstraction. They form two out of the four pillars of object-oriented programming. Inheritance is much as it sounds. You create a class which inherits methods and properties from another class. You might have a car class and a motorbike class, which both inherit from a vehicle class. You would set the properties and methods which are common to all vehicles on the vehicle class, which would be inherited by the car and motorbike. They can add their own specific car and motorbike properties after that. The advantage is that you don't have to keep re-typing all the same "common" properties for a car, motorbike, van, truck etc.

Abstraction is in principle very simple. It's really just abstracting the complexity of an app so that you only see the basic input and output. Of course there is a lot more to it than that; but that's it in a nutshell.

I was back in at CodeClan on Tuesday to learn about polymorphism and interfaces. Polymorphism translates from latin and means "something with many forms". In the context of programming, it means that you can use an object as more than one type. Following on from the example above, you can use a car as a vehicle or a car. That doesn't really make much sense in real terms, but it's useful when you want to group up a lot of vehicles as a collection rather than having separate collections of cars, motorbikes, trucks etc.

As I said, it is a bit tricky, and there were a few questions about why you'd use an interface at all. That would become clearer as the week progressed.

We had a paired lab to practice inheritance next, which was based on the model of a hi-fi stereo system. The system is built upon a central amplifier, with every other component connecting to it. You might have a CD deck, radio tuner, cassette deck, record deck and whatever else you can think of. The idea was to consider which components shared common properties and methods. For example, most components would have a "play" and "stop" method. I think the only one which technically doesn't is the radio tuner. It makes sense then to create a top-level component class, and have all components inherit the shared properties and methods from it.

The homework was a similar task, this time a theme park. The park would have attractions (rides, playground and a common park/picnic area), food and drink stalls, and visitors of course. It was fairly straight forward at first, to simply group the attractions and stalls together. However, the advanced extensions asked for restrictions on the visitor's height and age depending on which attraction or stall they visited. It also asked for a pricing structure, with the visitor having a limited budget. That threw up a few challenges which called for the use of interfaces. An ITicketed interface for the attractions/stalls which included a charge, and ISecurity for those with age/height restrictions. I found that it was the most challenging homework task we'd had for a long

We started on Wednesday with a homework review, and I have to say there were a few grumblings in the classroom (including some from myself). The homework solution included techniques which we were advised not to use. I think that's why the homework was so challenging - because we were all trying to complete it by using the best practices that we were taught. To be fair, the instructors acknowledged this and said that they would review that particular homework assignment. At the very least, it would make it fairer for the cohort after us.

Following that, we moved on to another concept known as composition. This was very simple, and we'd actually covered it the previous day in the stereo components lab. Composition means that you construct objects using other objects as components wherever possible. The advantage of this is fairly clear - you can swap components in and out without having to re-write the entire "container" object code.

Here in my car, I feel safest of all

It makes sense if you think of a real-world object such as a car. If a component fails, you replace it. You don't scrap the entire car and create a new one! The other important aspect of composition is something known as the single responsibility principle. In the car analogy, each component would be responsible for its own function. The air filter would filter air, and the fuel tank would hold the fuel. I suppose that sounds very much like common sense, but when coding, it's tempting to combine functionality into a class or object to avoid creating another one.

Talking of cars, the afternoon paired lab involved setting up a car dealership. We had to have different types of cars, the option to rent or buy, and customers with budgets. We also had to service or repair cars, as well as refuel them. We got hung up on the refueling part actually, as we weren't sure how to handle hybrid cars. This stemmed from a lack of knowledge about exactly how hybrid cars worked! We planned to use an IFuel interface which the petrol, diesel, electric and hybrid cars would all use. They would implement it in slightly different ways - the petrol and diesel cars would re-fuel, and the electric cars would re-charge. However, we weren't sure if hybrid cars needed to be re-fuelled and re-charged. If they did, you probably wouldn't do both at the same time. After a bit of research, it seems that they get charged from the alternator anyway; so in our model they'd be no different from petrol or diesel cars. We're not just learning about code!

The homework was a bit lighter on Wednesday night. We had to research a bit more about polymorphism and composition. We'd be quizzed about it in the homework review the following morning. It was all easy enough.

Thursday was an all-day lab, and this time we were in trios. The task was a challenging one to say the least. We had to create a fantasy/adventure game. You could play as a knight, barbarian or dwarf; all of whom should have a hand-wielded weapon and armour to protect them. You could also play as a wizard or warlock, who can cast spells and also have some form of creature to protect them - such as a dragon. Finally, you could play as a cleric, who has armour but no weapon. The cleric can heal other players. You would progress through rooms, with each room containing either some treasure to collect or an enemy to fight. You should be able to defeat the enemy, and the enemy should be able to defeat you.

We spent a good couple of hours on planning this out, as it was important that we didn't start going down the wrong path and then have to scrap the whole thing and start again. It made sense to create a top-level player class, with all player characters inheriting from that. We then created two classes on the next tier for the "spellcasters" and the "fighters", with the third class tier including all the specific character types.

After getting the basic setup coded, we decided to branch off separately to work on different areas, then merge together again later. We had to do this really because we'd been taught to make the whole process test-driven. Every character should have a test for every property and method that they have. For example, the wizard had tests for "has name", "has health", "has spell", "has defence", "can cast spell", "can change spell", "can change defence", "can collect treasure", "can inflict damage", and "can take damage". We had to repeat all of those tests for every character!

We didn't finish the lab, but we were relatively happy that we'd worked out the best way forward and with what we'd written so far. It turns out that noone completed the lab, but that wasn't all that surprising.

It was really good fun, and I was taken aback by how smart the kids were! The student I was paired, along with one of my classmates, had been taught some Python at school, which is a language that we don't cover in the course. By the end of the session, we'd managed to code a dice, a game, and a temperature sensor. The game was rock, paper, scissors, which generated and displayed a random symbol when you shook the device. The temperature sensor displayed a symbol when the temperature reached 30 degrees, so it would only work if you held it in your hands for a while.

After that, I was talked into going round to the local pub for a few drinks. This was in celebration of a new cohort starting (E26), and once again CodeClan had put up a tab. However, this was long sunk by the time we got there at about 8pm. In fact, the bar staff informed me that it was gone in under half an hour!

I was pretty tired on Friday to be honest, but there wasn't much going on anyway. We got our homework after stand-up, which involved coding a "music shop". It should sell instruments and non-instruments, with each item for sale having different properties and price points. You can see where this is going - you'd have a top-level instrument class, which all instruments would inherit from, and so on.

I didn't start on the homework straight away, although I did hang around to shoot the breeze a bit before lunchtime. I decided I would get an early night and hit the homework when I was fresh on Saturday morning...

Week 13 was to be a relatively tough week. The first two weeks of Java were fairly easy going, but we were about to dive into a powerful toolkit called Spring. Monday started with an introduction to Spring and what it was about. It's actually very difficult to describe what it does, because it does so much. It's like a massive toolkit, and you pick small parts of it that you want to use. We would be combining it with another framework called Hibernate, which is used to connect to a database. For the database, we'd be using PostgreSQL (ie. Postgres), which we'd used earlier in the course when we were working with Ruby.

What does all of this mean? Well, put simply, it allows us to easily connect our Java code to a database; and output data to a webpage. It would also allow us to post data to the database, which we'd do by conforming to a Restful routes pattern. Again, we'd covered this in the course previously. The upshot of all of this is that we'd quickly move from pure Java code to full-stack - in other words, a complete web app which can connect to a database.

The homework was a research task. We were asked to research the concept of relational databases, and the types of relations. We'd covered this briefly earlier in the course. There are one to one (rarely used), one to many and many to many relationships. As examples, a one to one relationship might be a husband and wife. The husband has one wife, and the wife has one husband - all being legal of course! One to many might be branches on a tree. The tree has many branches, but each branch belongs to just one tree. And for many to many, that might be students and classes. Each student has many classes to attend, and each class has many students enrolled.

We built upon this on Tuesday, as we learned how to create database links using Spring. I still wasn't fully on board with it. I got the gist of what we were doing, and was able to follow along, but at this point it felt like I would only be able to reproduce what we were doing by looking at a working example and copying the code line by line. It wasn't an enjoyable experience. I had a chance meeting with one of the instructors in the kitchen, and he assured me that I would get used to this feeling. When starting a new job, or even a new project, you might be presented with an existing code base which might be built using various frameworks and toolkits. You need to research and learn them, to understand what is going on before working on them.

I persisted with it, and I should say that I found the power of Spring very impressive. It allowed you to manipulate tables in a database with very little code. You just point it to the tables in the database, and it pretty much does the rest for you. You just need to tell it how the tables relate to each other, which is why you need a good understanding of database relations (ie. one to many, many to many).

The homework for the night involved creating a User/Folder/Files model. Each user would have multiple folders, with each folder containing multiple files. So, the user to folders and folder to files relationships are both classed as "one to many".

A bleak winter leads to a joyful Spring

I still wasn't entirely comfortable going into Wednesday, and I mentioned it during the morning stand-up. The stand-up is meant as an opportunity to open up about any issues or "blockers" you're having, as well as what is going well. I'm not convinced everyone is always completely honest though, but to be fair, not everyone is comfortable speaking out in groups. I don't mind though, so if I have issues I let it be known!

We continued with our Spring lessons (there have been many jokes about the first/second/third day of Spring etc), and we learned about JPA (Java Persistence API). This is a specification really, which states how Spring and Hibernate should connect the Java code with the PostgreSQL database. We don't really go into too much depth on this - we just implement it and customise it a little. These things are very difficult to describe without going into a lot of detail, and I appreciate my blog posts are long enough as it is!

Our final homework for the week was to create a whisky and distillery tracker. One of my classmates is a bit of an expert, so this was right up his street. In fact, his very first web app on the course was a whisky itinerary tool named "Ctrl Malt Delete" - genius!

Anyway, the homework task was to create a whisky and distillery web app. It would technically be full stack, but... not really. A database and API were already set up for us in the homework start code. If you entered your computer's address into the web browser ("localhost") followed by "/whiskies", it would display a list of all whiskies. If you entered "/distilleries", it would display all distilleries. Our task was to create custom routes. For example, you could enter "/whiskies/age/12" to display all 12 year old whiskies. I didn't find it too difficult, which was a good sign that I was overcoming the difficulties I experienced at the start of the week.

It's all part of the learning, although I have no idea whether I'll be working on front-end web stuff in future. The working version is up here if you'd like to take a look:

     Play Your Cards Right

No homework night on Thursday - so I popped round to the local for a couple of drinks after we'd gone over the lab exercise. Thankfully, we were back at The Chanter (£3 per pint) this week as opposed to Bar 4042 (£4.50 per pint) last week. These things matter a lot more when you have no income and you don't know where your next wage is coming from!

Well that's it for another week - only 3 to go...

Week 14 started exactly as it ended - contemplating the end of the course and making the leap into employment! A few of my classmates have been applying for jobs already, and some have had interviews too. As I mentioned previously, I decided against jumping into job applications too early. I want to put one final effort into the last part of the course - and the final project.

We'd be learning the REACT framework this week, which is a JavaScript-based front-end framework which allows you to quickly build up webpages out of components. In "traditional" web design, the structure of the page is created (HTML), then one or more separate stylesheets are created to change the look of the page (CSS). Finally, further separate JavaScript files can be created to add functionality/interactivity to the page. REACT brings the HTML and JavaScript together into each component, and also automates a lot of tasks that you'd otherwise have to type out yourself.

So that's how Monday kicked off. We discussed the principles behind REACT, one of which is that it's one-way data flow. You have a top-level component, and nested components within that. Any data which is to be displayed on the page flows down from the component above it. It's not technically true, as far as I'm concerned, because we all know that when you click on something on a page it can make something happen elsewhere on the page. That can't happen without two-way data flow. Perhaps I'm being pedantic, but I think that you need to question things to completely understand them and how they relate to the bigger picture.

We also learned about how REACT creates a "virtual DOM". The DOM is the Document Object Model, and it basically lists every element on the webpage. Making changes to the DOM - such as adding or removing an image from the page - can be quite intensive in terms of computing power used. So, REACT creates a virtual copy of the DOM, and only interacts with the "real" DOM when necessary. We were told that this is more efficient; but again I questioned that. I didn't have to look very far to confirm my suspicions, that REACT is in fact slower than "vanilla" JavaScript - but only really on complex webpages. In the vast majority of cases it's about the same speed. However, performance isn't really why you'd use it. You'd use it to create webpages faster and more efficiently. That's pretty much the case with any framework or library.

We had a relatively small homework assignment, which was to build a basic REACT-based webpage which displayed film releases. There wasn't an awful lot to it, but it still took me twice as long as it would have done if I weren't using REACT. I'm guessing that these tables will turn once I get over the learning curve.

The next couple of days were largely about practicing with REACT, and building up the complexity of the webpages we were creating. We returned to API connections again on Tuesday, which in this context are connections you make to a server to receive "raw" data back. You'd then output it on your webpage.

It was another all-day paired lab on Wednesday, which followed on from the idea behind the homework. The task involved creating a web app which connected to an API and displayed some information. We've had this task a number of times now, but it was really all about practicing with REACT. There were quite a few staff members and students roaming around in Halloween costumes as there was a party in CodeClan that night, so we were a little distracted from the task at hand! I didn't have time to sort out a costume, but planned to go to the party for a bit anyway.

Back to the lab task - we chose to use the NASA API, with the idea being that you could select a country or coordinate (by using latitude and longitude) to display a satellite image of that area. We got a bit excited about this, having previewed the images returned by the API. We managed to get some clear images of Edinburgh, and we thought that it allowed you to specify the zoom level too. It turned out that we were mistaken about that, and also that we'd just been very lucky getting the clear images. Most other images returned were just clouds! By that point, we were too far along to consider switching to a different API. It was still quite a good result though. Sometimes I think I'm a little too harsh on myself - I look at what I haven't achieved rather than what I have.

It was essentially our last homework of the course that night, and it's fair to say it was one of the hardest assignments we'd had to date. It involved dissecting the code of a REACT app which used a "router". This was to be the last piece of the puzzle to connect the back-end/database with the front-end, and I was surprised that we'd only be spending a day on such an important topic. To be fair, we were the first cohort to go through this part of the course in the new format (Java following JavaScript, rather than Java first), so we can't expect it all to be planned out meticulously.

I planned to do the homework on site in CodeClan as I was hanging about for the Halloween party later. However, after spending an hour on it I thought I'd better head off to give it more attention. Shame really, as there was free beer! Study comes first though. So, the "router" part of REACT is a little difficult to explain, but it involves channeling requests on the webpage to the database. If the website was about budgies, and you clicked on a link to show all budgies, the router would make the call to the database to pull out all budgies and display them on the page. If you clicked on one budgie, it would pull that specific budgie from the database. If you filled out a form to add a budgie to the page, and maybe upload an image, the router would handle adding the data to the database. As always, it's not as simple as that, but that's the basic premise.

The suggested project assignments included:

• A "Jurassic Park" management app. The idea is to manage attractions, as well as which dinosaurs can go into which paddocks.
• A news feed app, which fetches and sorts live news feeds via an API.
• A restaurant booking system, to manage customers and tables, as well as tracking spending.

We could use our own idea too, so long as we had it approved by an instructor. It was also up to us whether we decided to work alone or team up, but I was particularly keen on working with someone. I've found that it increases the quality of output. Some teams seemed to form spontaneously - I suspect that these were pre-planned alliances! Others were biding their time before committing to a team, or even which app to create.

I provisionally agreed to work with two other classmates on a "pet" app. The idea was that you could log in as a pet owner, or a service provider such as a vets or grooming service. I thought it sounded interesting enough, and it had potential to expand into other areas.

I committed to both the team and pet app idea on Friday, but we wouldn't have time to start planning until the afternoon. This was because we had a talk scheduled first, to go over the speed networking event the following Friday. There are to be representatives from 9 companies, all of which are actively recruiting and considering CodeClan students. We would get 6 minutes with each company, and a chance to "mingle" with the reps afterwards at lunchtime. More on that next week, I guess!

Following that, we had another lesson about our PDA. I mentioned this previously, it's the SQA Professional Development Award that's pretty much included with the course (although it is optional). We have to gather "evidence" from our coursework to submit, which tends to be screenshots or photos of diagrams etc. I'm slightly behind with this, so will need to make time for it. Somehow!

There was another talk at lunchtime from Dwayne Pascal of Skyscanner. You may be familiar with the name. They have been one of Edinburgh's biggest tech success stories in recent years. They were founded by just 3 people in 2004, and have grown exponentially since. They were acquired a couple of years ago by a Chinese firm for the best part of £2bn. I did notice that CodeClan seemed to be pushing this talk a lot more than the others I've been to, the proverbial red carpet was rolled out! They're not actively recruiting CodeClan students until at least September next year either.

Into the penultimate week then, with two things on the agenda - the final project and speed networking. I had to put speed networking to the back of my mind, as most did, in order to get on with the project. A project that was to prove to be more difficult than it needed to be.

I got in early as usual on Monday, which was wise as cohort E25 were working on their JavaScript projects this week too. There are a limited number of whiteboards and monitors available in the main area, which are very useful when working in teams. As we hadn't exactly made a flying start, I wanted to secure a monitor so that we could output our code to it, and work through it together.

Fortunately, I returned on Tuesday with a fix for our database problem. I say "fortunately", because I don't really know why it fixed it. Not a great position to be in. Again, the instructors weren't able to enlighten us either - other than to say "that shouldn't have fixed it". In saying that, I should add a couple of things here. Firstly, this part of the course (Java with Spring and REACT) has only just been added. One of the Glasgow cohorts have completed it, but we were the first cohort in Edinburgh to be taught these frameworks. Secondly, based on what I've just said; I would stress that I'm not criticising the instructors here. They've been fantastic throughout the course. It's just that the instructor who was leading on this particular part of the course wasn't around at this point (presumably in Glasgow), and he seemed to be the only one with in-depth knowledge of the Spring framework. He helped us a great deal the following day when he returned.

I guess the other thing to consider is that in a real-world scenario, you'd often have to use your initiative and work these things out yourself. Up to a point. If you're on the clock, I doubt that your employer would be pleased if you wasted several hours when a colleague may be able to remove your block in 10 minutes.

In any case, we kept at it and didn't get disheartened. We actually worked really well as a team - there were no conflicts between us. At this point, we knew we weren't going to achieve everything we wanted from the project within the week, so we provisionally agreed to continue working on it the following week.

By Wednesday, we had a basic web app prototype. You could "log in" (click on a link) as a pet owner, and view a list of your pets and any bookings they had with pet services (vets, dog walking etc). As a pet service owner, you could view all bookings with your services. We'd initially hoped to achieve this by Monday morning, so we were a full two days behind schedule.

We'd picked up a bit of pace now though, and quickly added in the ability to create, edit and delete bookings as both a pet owner or service provider. I'm not sure if I mentioned this before, but these basic functions are known collectively as CRUD (create, read, update, delete).

That's as far as we got. I decided to spend the evening adding a bit of styling to the web app. You might say that this was papering over the cracks! Although not really - the app was pretty solid, and thoroughly tested. It's just that it was a bit limited in terms of functionality. We made sure that what we had worked flawlessly, knowing that we'd be presenting it to the rest of the class the next day. "That wasn't supposed to happen" are words you should never say when demoing your app.

I got in on early again on Thursday to put together a few slides for the presentation, which were approved by my team members when they arrived. They didn't have much choice really - there was only about 5-10 minutes before the presentations were due to start! We'd decided between us that our "walk-on" music would be Who Let The Dogs Out. A little predictable, I know.

The presentation went well, we were fairly relaxed about it. It turns out that most of the class struggled a bit with this project too. In fact, if you only looked at the final product, the previous projects (JavaScript) looked more impressive. There was just a little less complexity behind them.

Talking of JavaScript projects, E25 were presenting theirs in the main area after lunch. I stuck around to watch them, it's always good to see what people come up with. I wasn't disappointed - there were a few really good ideas in there. They included a Blackjack game, an adventure game and two carbon footprint calculator apps.

I headed off after that, fully intending to get an early night ahead of the speed networking event in the morning...

There were 14 companies confirmed for the speed networking event on Friday, and we were to be split into 2 groups of 9. I was in the second group, which I didn't mind as I wasn't at all nervous about it. I have attended my fair share of interviews over the past few years, and this event was a lot more informal. And shorter - we only had 6 minutes at each table.

On a sidenote - there was filming taking place at the CodeClan main entrance on Friday too. Apparently this was to be an adaptation of "The Sopranos". Not the HBO TV show as I initially thought, but rather the book, about a group of rebellious teenage choir girls. There is some info on the filming here. Some big names are involved, and another big name popped in too - you might recognise him! He was in town for the Edinburgh Comic Con event...

Anyway, enough of the name-dropping and back to the speed networking. There was a last minute drop-out, which narrowed it down to 13 companies. That was still much more than there normally is, apparently. We were told that some companies had to be added to a waiting list, so there might even have been more than 14 if it was feasible.

The first group overran a bit, so our group didn't start until nearly 12. Some of the representatives said they were tired from all the talking! That's understandable - they had to repeat the same pitch to 18 students. I say "pitch" deliberately - there was a competitive feel between some of the companies there, which I found surprising.

I also found 6 minutes to be far too short, to be honest. I understand it used to be 10 minutes, but they cut it down to 6 following feedback from previous students. I think 8 minutes would be ideal. Despite taking... quick maths... about 80 minutes; it was over in a flash. We were whisked back into the classroom for a debrief and a catch-up with the first group, to share feedback about who impressed us, and just generally how we felt about it.

We were then allowed back out to mingle with the representatives over lunch, which was a little strange as most of them remained at their tables. I didn't want to go over to speak to them whilst carrying a plate of food! I took the time to have a couple of sandwiches first, which in hindsight was a mistake. I didn't realise that some of the representatives were about to shoot off, so I should have made made a bee-line for the ones I was most interested in. Although in all honesty, most of them sounded like great places to work. I had my top choices though, which I won't disclose here! I will say that one of the companies is based in Dundee, which isn't feasible for me at the moment.

The next step was to email CodeClan with a list of the companies we were interested in, and the reps from the companies would do the same. We're all hoping to get one or two interview offers out of it, but we were told that it isn't the end of the world if we don't.

I headed along to the pub with some of the others afterwards, but there weren't many of us because everyone was exhausted! There was also a CodeClan "alumni" meetup at 6pm, which was a chance to meet with some CodeClan graduates. In the end, only 4 of us made it back to CodeClan for the meetup. It was worthwhile - there were students there from cohorts E16 and E17. They graduated at the beginning of the year and both got jobs pretty quickly. A good omen!

Into the final week then, which is more about tying up loose ends as far as the course goes. I think I mentioned previously that I'd booked myself onto another course to learn C# (similar to Java). It's far from over yet!

The final week has now been and gone, and it's all over... sort of. There wasn't much officially on the agenda for week 16, it was really largely up to us what we did with it. Personally, I had the following to contend with:

• Continue to learn C#
• Finish the PDA evidence
• Apply for jobs!

I was lagging somewhat behind with the PDA material, but I was relieved to find that what I had included so far was OK. I'd need to find time over the next few weeks to finish it, or face a £50 forfeit. Despite that, securing a job was my main priority; followed by continuing to learn C#. It's a bit of an odd situation when you think about it. The course is essentially finished, and yet that part of the course (PDA) is hampering my efforts to continue to learn to code, and find a job. Which are ultimately the two main objectives of the course...

We had a talk from Origo on Thursday, who I believe were keen to meet us at the speed networking event but that didn't happen for some reason. They are a not-for-profit organisation who produce shared software solutions/services for the financial industry. I was quite impressed by what they do, and they sound like a nice company to work for too.

There was only one thing left to do on Friday, and that was graduate! I knew the script here, having watched the ceremonies for the last two cohorts (E22 and E23). We had a guest speaker, Lizzie from Kindaba. She had some really interesting things to say, with the overarching message of believing in yourself and your abilities. I want to say "inspiring", even if it is a little clichéd!

One of our instructors, Colin, couldn't be there on the day unfortunately, but he had pre-recorded a video message for us which was shown on the big screen. It was really heartfelt, and quite touching. It had extra significance because we were the first cohort he'd been with from start to finish, so it was a learning experience for him as much as it was for us. We wanted him to do well as much as he did us.

And that was that... it's all over. Well, not quite. I still need to find a job! And not just any job, but one which is suited to me and allows me to apply what I've learned and build upon it. I've had a couple of interviews today (20/11/18 - so actually in week 17 now), and they went quite well. I think. I will update this again when I do find a job - hopefully in the not too distant future...