Tuesday, 17 October 2017

Makers Week Eleven: Final Project - Lets Try 2 Build Atom!

So as I'm writing this on the Monday I'm officially starting Week 12, and Friday will be the end of the course. We will present our projects to a crowd a few employers, plus the mid and junior groups, and possibly some family and friends.

Its weird after watching about 4 of those that we'll actually be the next ones up there!

I will be sad when its over, as much of a roller coaster it has been I've loved it and the coaches are amazing, and they've really done a great job of creating an awesome community.

Geeking out, putting the big screen to good use after a hard day's work of coding!


The project actually started last week when I was writing about the tech tests. In fact, we got given our groups and had decided on the project the Friday previous, so we had already gotten in some weekend studying.

From the previous project, I had decided that since I was bursting with so many ideas lol, that any time I would have a thought I'd write it down on my phone for the ideas workshop.

So since I was 'prepared', it meant that I had pretty much taken up a lot of the whiteboard of potential ideas. I think I ended up with about ten ideas that made the board.

All our ideas were collated into groups and then we voted our first and second preferences. Groups were made of first choices, if it was possible.

Some crazy and/or ambitious ideas, focusing on being general for tech flexiblity

Final groupings of ides were Games, Product, Learn to Code, Build Your Own, and 'Other'
Learning from my success of the Pokemon Game for the iPhone, I decided that it was a good idea to keep my ideas general and that they would be based on what I wanted to try out.

In the end, I decided that it would be cool to try to build something from scratch. I've always wondered what it would be like to build a program, so this is a fantastic chance to find out!

My ideas in caps and mega black, ambitious enough? lol


After a discussion with our assigned "Build Your Own" categorized group, we decided that we would try and build the famous (in the coding community anyways) code editor Atom! And in case that was too easy, we also wanted to have multi user live functionality. We R madddd!

One of the cool things we found out was that Atom was open source, meaning that their code was freely available for anyone to use and learn from.

Another awesome thing that we found out was that Atom was built using something called Electron. Electron, we found out built other apps such as our messenger app Slack which we use extensively at Makers, my favourite Streaming site Twitch, Wordpress, and so much more!

So how does Electron work? Well, in simplemens terms, build you app as if it is a website, and then it will convert it!

Chromium is Google open source front end app, Node JS is a back end server side framework.

If you wanted a button that would go to another part of your app, make a webpage that does exactly that. This means that anyone that works with websites has the ability to make some apps!

This means that the language is in HTML, and logic is in Javascript. Simples.

However, testing was another matter. We found its official testing framework called Spectron, which runs the app as if it is a user to test out our various features. We had quite a lot of trouble working out how the language worked, as it was a little different to Javascript.

Anyways I'm quite tired now, its been quite a roller coaster so far. I'll keep trying to post on Mondays... it might be harder to find topics to talk about, but we'll see. For now enjoy our buzzword dinosaur... hopefully soon we will find developer jobs but I hope we don't end up at workplaces where they talk like that all day in meetings!

Tuesday, 10 October 2017

Makers Week Ten: Top Quality Code Innit!

This post might be a bit more technical then my usual, but I will try and explain things as layman's as possible. Also to the current or potential Makers this might need a spoiler alert, but don't worry in true Makers style I wont give you guys the answer lol.


This was the task we were given to do. Once our coach approved our code, we moved onto the next one;

You can go to your terminal in a mac, gem install ruby, type in irb and copy and paste this code in if you feel like checking it out...

Ok, lets have a go;

class Bank

  def initialize
    @transaction_history = []
    @balance = 0

  def deposit(date, credit)
    @balance += credit
    transaction = Transaction.new(date, credit, 0, @balance)

  def withdrawal(date, debit)
    @balance -= debit
    transaction = Transaction.new(date, 0, debit, @balance)

  def print_balance
    puts 'date || credit || debit || balance'
    @transaction_history.each do |log|
      puts "#{log.date} || #{log.credit} || #{log.debit} || #{log.balance}"

class Transaction

  attr_accessor :date, :credit, :debit, :balance

  def initialize(date, credit, debit, balance)
    @date = date
    @credit = credit
    @debit = debit
    @balance = balance

With every new Bank we create, we create an array (essentially a list) called transactions history that will hold our data stored in the Transaction class. Every time a deposit or a withdrawal happens, a new transaction is added to the array with the relevant information.

Our balance is always updated by having the deposit/withdrawal number add or deducting to it.

When we go for the printing of the balance, we look loop through each transaction in our transaction history array, and output all the relevant information.

Ok, so lets call our methods;

bank = Bank.new
bank.deposit("10/01/2012", 1000)
bank.deposit("13/01/2012", 2000)
bank.withdrawal("14/01/2012", 500)

pry(main)> bank = Bank.new
=> #<Bank:0x007fca05119488
bank.deposit("10/01/2012", 1000)
=> [#<Transaction:0x007fca050e9c60
bank.deposit("13/01/2012", 2000)
=> [#<Transaction:0x007fca050787e0
bank.withdrawal("14/01/2012", 500)
=> [#<Transaction:0x007fca0612c280

date || credit || debit || balance
14/01/2012 || 0 || 500 || 2500
13/01/2012 || 2000 || 0 || 3000
10/01/2012 || 1000 || 0 || 1000

Seems like it works, but that's not enough... this is actually low quality code!


Extra software tools were given for us to try and pass them, to assure high quality code.

There are multiple things wrong with this code, so what are they?

Testing - Well yeah, there is no testing on this code whatsoever. Testing is super important as not only does it help you work out what is wrong with the code, but for refactoring (rearranging the code for improvement) it makes it much less confusing!

The quality of the tests are important too. Do they properly test what you set them out to do? A way of testing if the tests are solid are by either slightly changing them to see if they fail, or just adding things to the code that should make them fail.

Ruby Testing Tool - RSpec

It is also important that the coverage is over 95%. This means that the tests you do, cover 95% or more of the code that is written.

Coverage Tool - SimpleCov

Linting - This is looking at the formatting of the code and to see if it is consistent. This can be anything like the spacing of words, upper or lower casing, or even preferred coding conventions for a particular job of a bit of code. The lint checker Rubocop also has a feature to auto correct fails if its sure it doesn't effect the function of the code.

Linter Tool - Rubocop

Inbalanced Classes - The main problem with the code above is that there are only two classes and that basically all the functionality is in one. It is important to spread of the responsibility of the code into multiple classes, with each class making it clear what its role is.

Having code spread out also makes it better for debugging, and it makes sure that the classes aren't too reliant on each other, meaning if something broke then it shouldn't effect to many things.

We used Flog to check our complexity (in terms of the structure), and aimed for a score of no higher then 15 for classes and no higher then 6 for each method.

Code Structure Assessment Tool - Flog

Extras - There are a lot of small things to do as well for good coding practice. Things like;

  • Methods should only have one sole function
  • Avoid Repetition "DRY" (Don't Repeat Yourself)
  • Naming Conventions - Classes should be nouns, methods as verbs
  • Setting some methods to not be allowed to be accessible by the user, making them "private"
It was also good practice to use Github with quality in mind;
  • Lots of commits!
  • Detailed descriptions on the commits.
  • A detailed Readme file.
In the end, I managed to refactor my code into 6 classes, linter passing and had 16 passing tests at 100% coverage! It was frustrating at times, but a great exercise none the less to making myself go back and rethink about how my code could be improved. I learned so much last week!


So we have two weeks left of the course and now I'm doing my final project. My group and I all had an interest to build a desktop app from scratch, and so we have been checking out and learning how to use Spectron. It seems like an amazing framework and has tons of potential for future projects. 

More about that next week. I cant believe its nearly over!! I'm gonna be really sad... For now I'll leave you guys with what should have definitely been our final project, an Augmented Reality Mario remake!

Tuesday, 3 October 2017

Makers Week Nine: We Built an Iphone Game in 5 Days with No Prior Knowledge

This is a long ass post, so if TL; DR scroll to the bottom, check out the gif of our game.

Last week it was our mini mock final project. We came up with a bunch of ideas, rounded them down and then got given our our groups, and then within it we picked one of them to do;


I've always prided myself on being an ideas guy. Its the execution i'm lacking in. So when the time came for us to submit our ideas I kinda felt that I should be able to get one through. Each student picked 3 and then they got rounded down.


My 'strategy' was to pick something that was general enough to be open, but also have a specific thing in mind that could be cool. I think good ideas at this stage can be broken down by answering the following questions;

  • Is there a particular thing you'd like to try out and explore?
  • At the end of it, is it possible to have something tangible to show for it?

Two outta three of my ideas got picked to the final choices, and our group unanimously agreed that we wanted to make a iPhone game. Here's my ideas anyways, with those criteria in mind;

  1. iPhone game using the tilting motion - We wanted to try out making a phone app, and a game and use the gyrometer feature. And we'd have a cool app on our phone to show for it afterwards.
  2. Chrome extension which funks up the pages 80s style - Could be cool to try and make a Chrome extension plugin. The Chrome extension could branch out into any other idea. At the end of it you could have something that you could share with others and let them download and install it to see for themselves what it does.
  3. Machine learning pathfinder for London Underground - My weakest idea tbh, as I had already seen it done before, but thought it could be a cool thing to expand upon. But machine learning is a hot topic these days, but this idea for sure doesn't seem to have the accessibility or fun of the other two. 


Starting out projects like this always seems pretty overwhelming at the beginning. The important thing is to identify what needs to be done and plan for the future;

Make a Plan! - Super important to get things going. What programs are we going to use? What is our testing framework? The first aim is to get a MVP completed, ie a Minimum Viable Product. For us, this would be a ball on the screen that would move around due to tilting the phone.

Original planning page from Day 1

Ironically, Swift was chosen by our group in no time at all. It was either that or React Native, and with our coach's advice that's what we went with.

Setup The Environment - We want to get our Github repository setup, download all the relevant softwares and set it up ready to be used. This can take a lot longer then anticipated especially when working with stuff that we've never used before.

The super intimidating user interface of XCode!

Agile Setups - Set up a plan of when to do morning stand ups and end of day retros. These are plans for the day and end of day evaluations. These are super useful to keep things in perspective and take a step back to remind ourselves what we're doing. Direction can be easily lost sometimes when members are super immersed in their work.

Day 2 Retrospective - The Good, The Bad, and the Confused?

Setting up XCode is a pain in the ass. You have to go to the Apple Developer page, sort out sign ins, and fill out forms. Once done with those, you have to do more downloads and then select an extra option on your phone to activate it once it downloads.

For some reason, my developer account had issues where it'd never save my sign in, so I'd have to do it like every time! Super annoying...

Bane of my existence this week

On day 2 we made an executive decision to switch from Swift 3 to Swift 4. Swift 4 had just been released the week before, so we thought it would be better to work with Swift 3 because there'd be more documentation on it.

However, after a few of us realising that our newly updated OS11 iPhones weren't compatible with Swift 3, we decided to go for Swift 4. Another incentive was also the fact that after this project, if we decided to try out more apps we would have to learn Swift 4 anyways, so its more beneficial.

End of day 2 we managed to finish our MVP. We found a good spaceship tutorial which used the gyroscope movement and adapted that code into ours. We found a Pokeball sprite that we could use, and so that was the beginning of our Pokemon themed game...


From my limited experience of checking out maybe five(?) testing frameworks, XCode's XCTest was by far the worst.

  • Interface - XCode is pretty UI intensive, meaning that you have to use their software to do everything. I found it pretty overwhelming, as they had gone completely nuts with the amount of options for everything. I'm not talking options for properties of things that you create, but the actual user interface itself! This means its not intuitive at all and just finding the tests themselves was confusing enough, let along knowing how to run them!
The tiny diamond button shows your tests! Hovering mouse over test icons reveals play button to run your tests!

  • Speed - Every time you ran a test, XCode built the app. This meant every time you ran a test it would take at least 20 seconds, which is just insane if you compare it to the instant results you get from other testing frameworks.
  • Visibility - We did not realise there was a console that outputted messages until day 3! The console was also quite random too, sometimes displaying a message when there was an error, and other times not showing anything. We never understood this in the end.
  • Testing Games is Hard - Since the other groups also did games, this became a common theme in the groups. Most groups worked with looping frames to get the animations to interact, and so once their game started, you cannot simulate what is going on within a controlled environment. This is especially true because most games have a ton of randomness in them.
  • Testing Tilt Motion is Hardest - So super how do you test tilting a phone motion? XCode has a simulator phone that you can use, but after some research it was discovered that simulating the tilt on your computer is just not possible.

  • Record Button Saved the Day - We found a record button on day 4 lol, and that wrote down in the code what was being pressed etc. This was great because it finally gave us some insight into what the objects were called for the testing framework. With this feature, we managed to pull off some tests finding elements in our game.


Looking back at the Acebook week, I think we learned a lot from it actually. Adding in smaller features at a time and refactoring the code was super helpful, especially for splitting up the work between different people in the group.

When adding the enemy Team Rocket, in typical fashion they caused complete mayhem. For some reason when they appeared on top of our border, the game would instantly be over and we just couldn't work out why.

Typical Team Rocket causing tons of trouble for us!

So as a purely coincidental decision nothing to do with that at all, we decided to get rid of the borders and make it an Astroids style thing where if you go left off the screen you would appear on the right, and vice versa for up and down. This actually made the game more fun!

Outtakes showing our bugs!

I looked at previous presentations and wrote a rough outline for the group to participate in. Structures are basically the same, so it was pretty easy to prepare.

I had also overheard that doing live tech demos are basically banned for final projects, they're always videos, as too many times things have gone wrong. So I insisted that we include a video.

It was also kinda weird to think about how one would go about presenting a game which involved tilting. Showing a screenshot of the game (great timing for that new feature, Apple) would be good, but it wouldn't show the physical tilting of the phone.

I kinda thought about having a split screen and after some quick googling I realised it was pretty easy to do in iMovie. Just needed to synch things up and it'd be great. It worked like a charm...

Its POKEBALL RUN! Coming to the App Store soon!

Our presentation went really well, and we achieved so much within 5 days. This was one of my favourite projects so far. I hope that with the final project it will be similar in trying something new and interesting.

Check out the Github Repo, there are instructions to play the game yourself but be warned you will have to go through all the Apple Developer stuff, as well as downloading XCode etc!

Tuesday, 26 September 2017

Makes Week Eight: Acebook & The Home Stretch

The past four weeks have flown by, and I've enjoyed it a lot more then the first month. I'm really enjoying the group projects that the second part of the course throws at us. It has been especially interesting to see the cohort grow and improve together, and see us handle the new struggles that we have when working as a team in project work.

I love seeing what can be achieved (or not?) by the end of these projects. These are the things that cannot be experienced at home by yourself in front of a YouTube tutorial, and I expect will be great practice for the real working world when we will be working in development teams.


Part One: Grouped!

The task was to make a Facebook clone using Ruby on Rails. We were split into different groups to focus on features. The teams were profile, photos, newsfeed, and dev-ops. I was in the dev-ops team which was essentially a code review final check before features are implemented.

What is it?

We managed to get Travis CI to work which was an online simulator which tests if a project passes their tests and works ok. This ended up being linked to Heroku which meant that once we merged the features in, it would automatically update to our website.

Part Two: Paired!

It seemed that the groups ended up working on rather big/a lot of features which meant that it was taking a long time to do, which meant updates to our site were far and in between. So our coach decided to put us into pairs, and specify the [small] features we would work on. My pair and I ended up doing automatic link recognition meaning if one was added, then the wall would display it as a clickable hyperlink.

Can you translate our coach's "interesting" handwriting? :D

Part Three: Free for all!

Come the end of the week we soon realised that we had a misunderstanding about the merging of the features to our website. We were meant to do it after our coach approved it, but maybe because of the previous structure when there was a dev ops team, for some reason we just didn't merge our changes.

So come Friday we were in a bit of a frenzy to get all of those features up and running. We kinda missed the step of the extra checks by our stand in coach at the time and at one point that ended up with a messed up master branch! Opps. Rooolllback!

Agile vs "Dictator" Style?

It was an interesting retro afterwards, looking back on our mistakes and the structures we chose to go with. I think one of the biggest downfalls was that we didn't have our pages setup as a template so that we could work on different areas without needing to wait for certain teams to finish those features.

There was some discussion on whether having a dev-ops team that approved of the [small] features, as well as code reviews was agile. Agile believes that if communication is strong, the need for old school "dictator" style approval processes shouldn't be needed.

Rails is really weird in that you can generate so many files, and find so many gems that can do things for you. It almost seems that you can end up hardly writing any code, but end up with a project that has tons of files in it.

Here's our Acebook!

Features that we managed to implement were;

  • A signing up feature
  • A login feature
  • A wall to post messages and links. These features are only accessible once logged in
  • Ability to like and unlike the posts on the wall
  • Friending and unfriending users
  • Adding photos from your computer
  • Display all the photos in a gallery
  • A random cat image generator, with Amazon ads (wtf?). There's no link to this you need to add /random_images to get here


This is my fourth(?) graduation I have attended and it was the last one for the remote course. Again, its bitter sweet since I know these guys a bit and its sad that they wont be in the same room as us, but cool to see them presenting like a boss and moving on up!

Projects were;

Remote Groups;

  • Catastrophie - A web platform game built using HTML Sketch, Matter.js and Jasmine testing.

  • Terminal Commando - A plugin to your terminal that makes it give out useful tips and advice whilst using the terminal
Onsite Groups;
  • Squirrel - An app which uses your location to remind you of cool places that you always mean to visit but forget
  • UnorthoDucks - An augmented reality game stylized like minecraft, where you have to shoot the zombie ducks and protect the normal ducks. Built with Unity.

  • Reign of Terra - A live territorial game where users "conquer" sections of a map based on their real time location
  • iDo - Challenging the traditional concepts of marriage by making a blockchain contract that cannot be forged

Really great projects, very inspiring. And for the first time out of all of the graduations, I start to have a vague idea of how one could possibly approach these ideas.

This week we're doing the "mock" final project. Our group has chosen to do an iPhone game involving the tilting movements (gyroscope). We're learning Swift. We know zero about Swift. So GL us! But checking out apps is something I've always wanted to do, so either way I think I'll learn loads. Anyways, more on that next week!

Monday, 18 September 2017

Makers Week Seven: Single Page App & iPhone X!


Last week we focused on building a one page app without any frameworks or libraries in Javascript. We also had to find a way of setting up a testing environment for it, and writing it ourselves. Amazingly its not that hard, basically just comparing elements on the page using the DOM to see if they're there/working properly.

However, since I haven't really been that interested in the front end, it has been lacking. So this weekend I brushed up my knowledge with HTML, CSS, and Bootstrap. It was also a great excuse to catch up with my friend in NYC since that was his specialty.

I learned loads, but I'm not too tempted by it. I'm glad I found Bootstrap since its basically a massive library of templates which means I don't have to spend too much time on that, since I'm more interested in the creating of things rather then the look of it.

When you know how tough things are to make its special to us, but looks so basic to others!

I quite like the idea of the one page app. It seemed a fast and quite reliable way of making a quick website that could do some stuff. I'm not too confident with using the controller, which is a file where you direct where everything goes. It gets rather confusing with GETS/POSTS requests, redirects, and passing information between the pages.


Last week Apple finally announced the much anticipated iPhone X in their keynote. It was their special "but there's one more thing" line, but unfortunately it was pretty obvious what it was, which kind of makes me think that they don't really understand how that twist is meant to work.

With Steve Jobs, it would genuinely be a surprise, and the main products would be shown off normally. It seems quite apparent to me that they are quite lost without him, for some choices during the presentation really do seem off;

  • Selling off (I'm assuming?) airtime to show Spiderman trailers and what not.
  • More developers showing their games which are cool, but mostly somewhat unrelated to the product.
  • Spending a good 5 minutes on showing face ID with masks and emojis. I mean, how many people are really sending animated texts really?
Does anyone actually use those animated emojis and finger painting in their messages?

Apple used to be known for its innovation. With a roller button on iPods, a much more responsive iPad touch screen, and Macbook Airs so slim they fit in an envelope, it seems they have lost their flare and presentation skills.


One of the biggest surprises to me was that they released the iPhone 8.... completely identical to the iPhone 7! I mean, it has wireless charging now and better memory/camera/battery life but literally no new design or anything at all!

For £800, if you were gonna spend that much on a phone you might as well pay another £200 and get the iPhone X. I mean your spending £800 on a phone anyways, that £200 isn't gonna be that big of a weight in your pocket!

Anyone who buys an iPhone 8...

My iPhone 6 is most likely gonna upgrade to the 7. Ironically with all my ranting its still not gonna be enough for me to want to even consider moving.


When the iPhone first came out, people were saying that it was a crazy price. But with that revolutionary responsive touch screen, it made all the difference and Apple stormed into the phone market and has never looked back.

This new model is everything we expected, flush end to end screen, gone is the home button, wireless charging, and faceID.

Even though its everything we expected, still lookin' swaaaag!

I'm not sure how the industry realised how prevalent the faceID was going to be, it seemed to be the surprise of the night. It looks pretty amazing, but its hard to believe that it is more safe then a fingerprint. I think the quote was that it was a one in one million for a false positive sign in.

It seems that Apple is gonna be going in this direction of using facial recognition. I've always wondered how the ApplePay would work without the fingerprint button, and well you use your face. Yes, you heard it right, you pay... with literally your face! Weird...

Whether this becomes more mainstream, only a matter of time will tell. I personally quite like using the fingerprint and was expecting a reader on the back like other phones. I just wonder how many fringe situations are going to happen of accidental payments or unlocking!

What seems great though is that the wireless charging has finally arrived. Apple has chosen "Qi" wireless chargers which means that third party manufacturers can go nuts with producing these before Apple's official overpriced version comes out next year. Since Apple has chosen it, should mean that others will follow suit and we will see it become more of a common thing. It has been a slow and painful journey towards the dream of never seeing a tangled wire ever again.

One grand IS crazy, but its gonna sell out especially with all the monthly plans that people will join to get it. Its crazy to think that a phone that can sit in someone's pocket is going to be more expensive then the laptop I am blogging on right here!

I look forward to checking it out when it comes out in the Apple stores, but its unlikely I will get it. Maybe the next one?

Here's a pretty cool close look at the iPhone X with Marques Brownlee. I really love this guy's tech videos, super clean and to the point!

Monday, 11 September 2017

Makers Week Six: NP Just Making a Website w/ Database in Five Days

Another week passes at Makers and its crazy to think that we're half way there wtf! What a shock to the system!


Sounds ez right? Especially with limited experience! lol

Last week we did our first project as a group, and with our weird prime numbered cohort my group became a five, whilst all others were put into fours. I'm not sure if that gave us a significant advantage, but it was a bit of a hindrance splitting the group up, it was either a 3 - 2 or a 2 - 2 - 1 formation. But like any football manager (I assume?) we were flexible according to what was needed on the "pitch".

Our first white board! Tons of planning and working out what to research.

The task was to build a replica of an Air BnB website. This meant having a sign up/login page, and once in users were able to put up their room for rent, and book existing rooms on the feed.

We had a choice to use Javascript or Ruby, and surprisingly only two people wanted to use Ruby. So far we've had 9 weeks of using Ruby, one week of Javascript, and it seems Ruby didn't stand a chance. For me Javascript is very familiar to me, and I like the flexibility it has with the web, so its popularity surprised me.


Right from the get go our team was super organised, we were very open to the morning stand ups, and the retros. A stand up is a reflection on the previous day, a plan for the current day, and a way to bring up any concerns to the group. A retrospective is a meeting that happens at the end of the day to write on the whiteboard things that were good, bad and confusing.

Our first retrospective!

Spending some time put aside for these things really made things clearer for the group. It was also a great way to make sure that we had good communication.

Early on we identified the things we needed to do, and delegated other things we wanted to research. A priority was working out what we needed to use, then set up the environment with those softwares, and then set up a skeleton file structure that can be pushed to github that everyone could access.

File setup planning

Page direction planning

It was clear that we needed to have a database for our users to sign in with, as well as for the rooms to be rented or put up to rent. We already has used Postgres for database stuff before so that seemed like a good obvious choice. However, we had heard bad things about the ORM, which is used to link the database to our website. I had heard the name MongoDB floating around and after some research we realised that it works with hashes, which makes it more adaptable to Javascript (which is essentially hashes).

Using Trello is a great project management tool


As well as having meetings at the beginning and the end of the day, we also chose to do one after lunch. This was to check in on everyone and see how things were going. On multiple occasions we decided to switch strategies from looking at one thing, and then prioritizing something else. Or if a group member wanted to change up and get more stuck in then we would mix it up. Our group was fantastically open about being flexible which was awesome.

Major points of contentions;

The Lows;
  • First day is naturally a lot of reading, watching tutorials, and research. Very little coding!
  • Still getting stumped by the most basic things, like setting up the environment.
  • Taking ages to know that we had to run a server for our headless testing framework.
  • Learning Zombie, feature testing seemed to take a long time.
  • Getting our router forwarding to work which took ages. But so essential, as once this was done we were able to split up the work much more effectively without having to worry about it effecting each other because it wasn't all in the same section anymore...
  • Linking the sign in page to the database took a looot longer then expected, probably a day or two then what we set the goal out to be
The Highs;
  • Getting the router forwarding to work!
  • Having the sign in page and the rooms page functionality working both pretty much at the same time with different teams within our group.
  • Amazing team spirit, the highs and lows were experienced together.
  • Hanging out together, table tennis and a great final day lunch.
Here's some totally unimpressive (aesthetic-wise) pictures of our fully functional website! I'm super happy with our progress and it was probably my best week at Makers so far.

Signing in page

View rooms available, but can't book any until signed in

Filling in a form to advertise room, when signed in

Even though my other cohort members were in the same room, it did feel as if I didn't see them much. It was an amazing experience to see it all come together on the Friday.  My cohort was a dream to work with, so patient, so open and fully adaptable! This gave me a taste of what it was like to be in a development team and I loved it.

The last retro w/my anime wannabe style faces!

This week we get a choice for groups or pairs and I choice more group work. I think it will be groups until the end now, apart from Tech Test week.

Today my mentor got a job! Its pretty incredible considering that she just graduated two weeks ago. Its very inspiring and I hope to be as successful as her when I get to that stage. She has been really supportive to me and it helped me tons. Congrats! :)

Monday, 4 September 2017

Makers Week Five: Javascript, We Meet Again!

Last week we switched it up to Javascript and linked that to some elements on our webpage and build an interactive thermostat with buttons and stuff.

It seems that the switch up was done to show us that learning another language isn’t as hard is its made out to be. However, I was already learning Javascript before the course started, so I guess this lesson wasn’t as applicable to me.

There's a looooot of brackets and curly braces in Javascript!

However, comparing what I assumed was going on, having that debunked and then finding out what actually is happening really blew my mind. It kinda is like seeing this language in a whole new light. Pretty cool.

It has been interesting observing my fellow cohort members approach this. Some did extra online courses, others used youtube videos and/or looked at various documentation. Most of my classmates decided to rewrite previous projects in Javascript before moving onto the main task.

In all coding languages, they do the same core things. Store data in variables, have functions that do things, have true or false statements… and so on. Some of the newly graduated students had interviews in languages that they learned over there weekend, and still got through to the next stage. This is vs other applicants who have had years of experience in those languages… what a pisstake innit!

Our weekend challenge was to design the code for the scoreboard of ten pin bowling. Its a very confusing thing to explain, let alone code for. A strike where you clear all ten pins with one bowl is ten points plus the next two bowls, and a spare where you clear them all in two bowls you is ten points plus the next first throw. You can try it here.

See? Told you! Its like explaining the off-side trap and/or the insanely weird tennis scoring!

Check out Kingpin! Weird and funny movie

I have come to terms with testing first, then writing code. In this instance it became really helpful later on when dealing with strikes and spares. I have been totally obsessed with coding this weekend, literally getting out my laptop whenever I can on the train to London there and back, even when visiting a good friend on Sunday.

Being strict with yourself in trying to resolve problems before moving on is really tough to do, but I have been getting better at reading errors and keeping to good coding practice.

This week we’re working in groups now until the end. No more weekly challenges with pairing. We are organising ourselves with tasks each day, and making sure we have great communication. I have been looking forward to this part of the course since I love the people in my cohort so much. 

Its funny that we have had 9 weeks (including the pre-course) with Ruby, one week of Javascript and when given a choice our whole cohort pretty much chose to do this week’s project in Javascript! Poor Ruby…

It will be interesting to see how far we can push ourselves. I’ve had a positive day so far, and next week I’ll report on it fully.


On Tuesday, I was on the way home and as I was walking into Euston station, a businesswoman in front  of me had her bag suddenly did a mini explosion. She dropped her handbag and started running off. The handbag did a much smaller burst then stopped and it just lay there smoking.

I was pretty chill at that point thinking, “oh… that’s a weird thing… maybe its a note 8 or something”. Then I think someone shouted out bomb and everyone started running. I was pretty surprised at this and so backed off with them. It was weird how the atmosphere changed so suddenly.

It was at this point it really made me question what I saw. I was pretty saw that this wasn’t a terrorist attack or anything, but it happened so quickly that it made me question that.

The station closed down pretty promptly and I made other arrangements instead of going home, for who knows how long it would take for it to reopen.

In the end, it was reported that it was a faulty that e-cig that exploded. I had no idea that they can just spontaneously ignite like that. My friend told me that it happens quite a lot and people get some pretty bad injuries. How the hell are these things managing to pass approval for health and safety??


Sunday I went down to London to meet a good friend I hadn't seen in ages. He is a reporter for South Korean news, but done in English for an international audience. It was a really great catch up, also hanging out in "west [end" again. 

The west end is like Picadilly Circus area which has a lot of theatre shows around. But we used to hang out there because there were arcade machines we used to love playing, its close to tons of shops and there is a lot of cool places to eat as well. Its strange to think that even though I spent like 3 weeks living in London, I never once went there.

We hung out, and checked out some shops. I didn't realise that Zara men's fashion seems to perfectly tap into the wannabe Chinese Gangster look. Only then when it was pointed out to me, when I looked around there was a "gaggle" of Chinese men scouting the racks, truly considering the studded sparkly jeans or bright red boots with a zipper, with a matching red suit to go!

Do I look Chinese gangster enough?

I'm really looking forward to meeting up again, but this time in Seoul. Its all been arranged that I will be going there for a week in November. This will be fourth time I will be going, which is getting kinda close to the amount of times I've actually been to Hong Kong itself.

I do feel bad about leaving for November as the course has instructed that we carry our momentum of finishing to finding a job. Unfortunately this has already been planned a long time ago so I cant change it. The bad thing is that I heard that December is not a good hiring month, so it might be more realistic to find something in January.

Anyways, all this is still a while to go before it happens, hope you're all well and happy coding, talk to u guys next week!

Monday, 28 August 2017

Makers Week Four: We Are Mids!

Last Friday was the graduation of the June cohort which means we move from being the junior cohort to the middle ones. Their group was unusually small in comparison to all the other groups with 10 students. The cohort average tends to range around 20.

This was an extra sweet graduation as I had gotten to know some of them, especially my super awesomely supportive mentor. Each group chooses to become mentors of the lower cohort if they want.

These final projects were given 2 weeks to complete,  sometimes with languages and testing frameworks that they might have to learn from scratch.


Zombie Paint is a homage to the classic Microsoft Paint of which was announced that they would be ending this year.

The group attempted to make everything from scratch, whilst fully implementing industry standard testing.

Check it out! - https://zombie-paint-902ce.firebaseapp.com/
Githubz - https://github.com/mihobo/zombie-paint


The perception is a headline quality checker. With this day and age of "15 ways Buzzfeed makes pointless headlines" and straight up fake news prevalent, this app checks the quality of a headline and approves or disapproves it.

They collected data from thousands of headlines to find similar patterns from API's of  various news organisations.

Have a play! - https://the-percepticon.firebaseapp.com/
Githubz - https://github.com/tbscanlon/percepticon-frontend

Both projects were really inspiring and it will be hard to believe that my cohort will have to do something like this in 2 months time. They both had tons of problems and struggles but managed to complete the task in the end!

Graduation projects will be uploaded to the Makers youtube channel, and you can check out some of the older ones...


My three weeks living as a Londoner has come to an end and to be honest it has everything I expected. I did live in London for a few years after graduation so this wasn't any culture shock.

At times its lonely, other times its great going to events, but all in all its an expensive affair! It is pretty awesome being able to catch a bus straight there, getting there early hasn't been a problem.

Next week, which is this week because its Monday the blog day, we're moving on to do some stuff in Javascript. In learning coding by myself I focused on JS so I should be ok, but its funny how much I've forgotten already. Ruby is so tidy and minimal, and javascript has brackets all over the place!

One of the cooler things I learned last week was how everything in Ruby seems to be an object, within an object... within another, until your reach the Basic Object Class. Then above that? Well that's like asking who made God? (Don't ask that its confusing)

Pretty interesting to see where everything comes from. I probably haven't even explained it properly/correctly, check out this post for more details...

Talk to you guys next week dudes, happy coding.... peace out London, twas a blast!

Liverpool Street Stationz and dat!

Add this