Naughty Dog overcoming limitation’s through lateral solutions.

Considering It has been some weeks since my last post, I was itching to post something onto my blog but I had no developer related ideas to contribute. Until that is I came across this 👇.


Here you have the co founder of Naughty Dog, LLC talking about game development process and challenges in era of pre PS1.

How is any of this relevant to present day web developer life and challenges you ask. Well, it is not that different the use of SPAs, Node.Js, Agile development and use of frameworks & libraries in our time. The challenges Andy Gavin had to overcome in the 90’s are somewhat perennial.

As you may know part my developer journey involved creating a game project (🏆 Colour master 3000) and game development is no stranger to web development with most being on-line nowadays.

If you pay close attention to the narrative especially here (at 21:21) where Andy is discussing multiple memory packets with the user only rendered what is visible and creating levels with such a layout that it is never in position to need more than sixty packets of memory. It is very much like coding for web users with low bandwidth.

The solutions used in Crash Bandicoot were pretty ahead of their time. We are talking about ten years before Node.js was released (In which JavaScript would pass on time consuming requests on to the host environment and the host environment passing it back to JavaScript when complete to deal with the result) or twenty years before Google released it’s cloud gaming service Google Stadia was launched in which Google relies on it’s own servers to process the game frames requiring the device to have an Internet connection.

Beside from tech related solutions he delves closely into details around start-up process, the wins, brand development and being bought out by Sony 💰 (kerching!). All which are connected to present day web development but which I will not be going into in this post.

Mo Out!

Learning TypeScript

My blog has been a bit quiet recently, precisely for this reason. I decided to add TypeScript to my skillset. Which to my surprise “was not just a JavaScript written for Windows” as I a previously believed.

So here is what I’ve learnt thus far.

In the world of programming languages there are “Statically typed languages” such as Java and C#, TypeScript is an optionally statically typed language (e.g. don’t have to use declarations). TypeScript is superset of JavaScript, it is ECMAScript6 with optional typing.

Unlike JavaScript you do have to use a compiler with TypeScript. The compiler’s job is to output a JavaScript. A key benefit of this compiler is that it compile ES6 supported features into usable code for older browsers and older versions of JavaScript (e.g. you can write code with a fat arrow function => () and still compile to a older ECMAScript).

Data Types

TypeScript  is the typed version of JavaScript. This means we can specify types to different variables at the time of declaration. They will always hold the same type of data in that scope.

Typing is a very useful feature to ensure reliability and scalability. Type checking helps to ensure our code works as expected. Also, it helps in hunting down bugs and errors and properly documenting our code.

The syntax to assign a type to any variable is to write the name of the variable followed by a : sign, and then the name of the type followed by a = sign and the value of the variable.

There are three different types in TypeScript: the any type, the Built-in types, and the User-defined types. Let’s have a look at each of them.

Built-in types

These are the types which are built in TypeScript. They include numberstringbooleanvoidnull and undefined.

let num: number = 5;  
let name: string = 'Alex';  
let isPresent: boolean = true;


In JavaScript you don’t know it is an object unless you read the code. So TypeScript helps to take the weight off. not using brain resources ourselves, don’t need to compile the code in our minds. pre optimise your code.

What is more is that in you don’t need to actually type num: number anymore because you can just declare let name = 'Alex'; and the linter will show you an error if you did let name = 1; (the error in linter will state that it can’t be assigned anything other than a string), unless initially you declare a:

any type

The any data type is the superset of all the data types in TypeScript. Giving any variable the type of any is equivalent to opting out of type checking for a variable.

let myVariable: any = 'Alex'


Another interesting feature of TypeScript I found was interface

To create an interface, we use the keyword interface.

interface ICar {  
  model: String,  
  make: String,  
  display(): void  
// using interface

const Car: ICar = {  
  model: 'Prius',  
  make: 'Toyota',  
  display() => { console.log('hi'); }  

we can use interface to lock in the object values required by the function/object. An interface is like a syntactical contract to which an object should conform.


I appreciate This blog post went from zero to hundred pretty quick, the reason was that I did not want to cover all the boilerplate exercises (like installing TypeScript) for their are plenty of variables involved and plenty of resources available for that.

This is not the end of my TypeScript Journey for I have a lot of Udemy content to complete like:

  • Advanced React and TypeScript techniques (e.g. higher order components, render props, etc.)
  • Basic and advanced features of TypeScript (from modules to declaration merging)
  • Building a Nextjs web application which uses the GraphQL API
  • Using types provided by third-party packages and creating custom type definitions
  • Using React with TypeScript in general

I will update this space as and when I feel I can explain further.

Mo Out!

ARIA Labels, SR tags and deep nested accessibility provisions

Earlier this week I attended a Meetup themed around Accessability, as expected there were talks and discussions around accessibility but a Dev was also at the scene. Delivering a talk titled KISS Coding : Discover the power of HTML structure and ARIA labels (see talk on YouTube). Incase you’ve forgotten KISS stands for Keep It Simple Stupid.

Of the many facts and stats I learned from the Meetup were:

  • The Purple Pound (i.e. spending power of disabled households) is now worth £274 billion (thats 15% of UK’s total discretionary spending 😯)
  • 98% of popular websites do not comply to even the minimum accessibility standards
  • The school’s web app Times table rockstars not useable by screen readers 😮
  • Having a site with Accessibility improves your SEO and UX
  • You will gain customer loyalty as result of a good accessibility site (and vice versa)
  • Disability can be temporary (such as holding a baby, losing your spectacles and being drunk)
  • With websites always begin with accessibility in mind rather than a ad-hoc process (in one case it cost a company twenty times the original project budget as a result of doing accessibility as a after thought)

I also learned about Project Impactive who have been or are working on cool gadgets for disable client. Like this one handed Xbox controller.


Back to the subject of web development, some common Inclusive Design Fixes for existing websites can include:

  • Text – clear language and font; colour contrasts
  • Navigation – tabbing, larger buttons; give alternative to drag and drop (as some assisted technologies may not be compatible)
  • Images – provide alternative text descriptions
  • Communication – use captions and provide user assistance options
  • Timeouts – remove them or allow for the user to extend them (as the process maybe slower when using assisted technologies

Migrating to HTML5’s semantical model is a very good starting point (I go into details in my LinkedIn Article on this) but a developer can also use ARIA labels attribute inside your html tags. These labels depending on which one you use serve specific purpose.

  • aria-label
  • aria-labelledby
  • aria-hidden
  • aria-describeby
  • aria-required

My key takeaway being use aria labels and test your code using the voiceover feature, to avoid broken user stories.

Different browsers interpret Aria differently (i.e. say the sentence in slightly different wording).

Another cool aria label is using aria-live, this allows for immediate real time interaction of the user,  the example used was a html form field in which their are limited characters and the user is informed at the end of each typing interaction how characters are remaining by the screen reader. I think it is particularly good for devs know about this as with many job application forms and other online forms, getting this right will be a good enabler (here is the dev explaining aria-live).

Throughout the whole event I found that TDD (Test Driven Development) is probably the best approach when it comes to Accessibility web development. Also you may need add invisible values that only assisted technologies will require (e.g. instead of it stating “1 item in basket” it can say “1 item total cost of $44499 in basket” on an e-commence site).

Sticking to KISS and modular code was also a common theme.

With the 23 September 2020 deadline fast approaching I feel a tsunami of demand for devs coding accessibility features may too be coming. All the better reason to learn.

Mo! Out!

Wireframes through balsamiq

Even though I am not a fully qualified UXD, I have always paid close attention to what they do (see my LinkedIn article on UXDs) as user interface is part of web development.

So Early this week a business approached me, stating if I could advise and put together wireframes for a website based on ‘problems’ and ‘user stories’ they provide.

I had put together wireframes in the past (using Prezzi and Hatchful for my projects at General Assembly) but never actually used a wire framing tool to do so. The difference being with a tool like Balsamic it allows you to design the user experience (e.g. you can add buttons and links to other pages). All this plus you can do a walkthrough using the presentation tool.

we sat down and started planning user stories on paper (apologies for messiness 😬).


We planned:

  • number of pages
  • how they will be connected
  • unnecessary form information that a user will not need to input due history tracking on site
  • problems that we were trying to resolve

Once the meeting ended I preceded to put together the design on Balsamiq.

It had all the tools I came to expect and I have to say being a developer made it so much easier to understand. I completed the full design and linked together in about 2 hours.

This was followed by me clicking the little ‘play’ button on top right in order to carry out a User Test (i.e. someone browsing the website from a browser).

To my surprise I found situations where the user would be stuck and unable to return to main page (except by pressing back in the browser). I had to escape the test add the broken link and start the test over.

Once I was happy with the wireframes, I recorded my screen and talked through the designs (Yes I did a voice over 🎬).

The main take aways from this whole experience were:

  • You are in better place to understand wireframe tools as developer
  • The TDD (Test Driven Development) can be applied to Wireframes development
  • Wire framing tools are not just useful for building UI but also for creating UX
  • As a dev do not be afraid to try something new and outside the scope of coding

Mo! Out!




Another new stack

Yes, Incase you didn’t know the above monograms React Typescript Redux.

Earlier this week I was once more forced to work outside of my familiar tech stack. Which meant new syntax, new bugs and even new database (mySQL).

A dev got in touch to see what I make of their company’s full stack code test.

To say it was challenging would be an understatement, It brought great learning as result.

The challenges:

  • Learning new Syntax
  • unable to connect app to mySQL database
  • finding similarities (like: high order function in JavaScript Vs Typescript)
  • understanding new folder structure especially with the use of Redux (it was not MVC and it was not MERN)
  • Understanding Redux


  • Many of my Devs @ GA Slack Channel assisted me to set up and fire up the local host. Which successfully ran.
  • pseudo coded many code tests for the backend to demonstrate my understanding of TDD


Given the opportunity to do the test again, I would:

  • have liked to be in a more informed place (i.e. practice Typescript over or Udemy) prior to applying for such a position.
  • Work on the actual code test to out put a React component.

So in conclusion, I gave it a decent go at learning and turning around a solution code but this time I did not succeed (unlike my .Net challenge), main reason being having never worked with connecting mySQL database with React component,  I just screen recorded me talking through various challenges of the code test and sent it to the Dev.

Mo Out!



Haven’t written a piece recently, thought I I’d reiterate over the wonderful world of projects as Dev.

My time in GA meant creating projects as a means to demonstrate what you were technically grounded in.

Here is what the process entailed in terms of planning, coding, styling and challenges.

  1. On the weekend take out some time to come up with various projects that you can create within a six day design sprint. Mine were; a coffee game, a typo in code game, a music game, a spiritual game (you progressed by doing more yoga, meditation, hikes and avoiding distractions 😁) and a HTML colour guessing game.
  2. We pitched all our ideas to our instructor (tech lead) on the Monday, he gave me the all clear for one idea based on my capabilities and the timeline.
  3. Pseudo code the game logic.
  4. plan game functions on piece of paper.
  5. Commence work on MVP (Minimum Viable Product). The instructor would keep up in check for this when we our daily 1-2-1s.
  6. Be present for daily stand-up – describing your win from the day before, describing your blockers and what you plan to work on today.
  7. Keep an eye on the sprint timeline and scrap any ideas that will not work out.
  8. Do not code in any features on the last day of the sprint.
  9. Deploy project on Heroku.
  10. Work on styling and animations at the end of the project.
  11. Deliver a presentation of 3-5 mins on your project on the last day (Doing a project demo, talking through your Wins, challenges and any future features).
  12. Write the Github Read me on the project.

That was the overall project time line and how it came about.

I found that code planning is gold, the more you plan without writing code, the clearer it is for you when you sit down to write it (that is not to say that you will not encounter problems, you will but you will avoid a lot of them). I found that the more you enjoy working on the project the better devotion you will give to the project. I found that being able to screenshot your code error to a slack channel of your cohorts was really great way to share your bug (it could be 2am and someone may answer it 😳). For my styling I had great fun using Bulma and sometime I’ll use cool features from other sources like tile shake.

I cannot stress enough the strength a dev has when he has abilities to search coding errors, rely on fellow novice Des and a senior Tech lead. I could not have puled it off without it. 🙏

Mo! Out!


Livestream and me!

I know! What a milestone. For those of you unaware I do use this blog at times to celebrate my #wins in and around web development world.

This week I decided to try my hand at Youtube Live stream service. The reason being I dreaded the time length it took to record a video (using only my on device camera) and uploading it Youtube (the processing time was about two hours for a 5-7 minute video). So I thought (which I was wrong about as you will see) in order to reduce a two step process to just one I’ll give Live streaming a go.

Needless to say, it wasn’t an impulse decision. The steps prior were:

  • Submitting for an approval on Youtube to allow my account to livestream (it takes 24 hours)
  •  setting up camera such that no mishaps
  • deciding on general ideas that I intended to cover talk.

and thus began at approximately quarter pass nine Greenwich Mean Time (GMT) 😁 my first ever live broadcast. No one from my seven Youtube subscribers tuned in.

I talked through the pre planned content, there was some nerves as I had to do it one cut (no room for editing out stuff or second takes 🎬) and thus it was over before I knew it. Lasting eight minutes and fifty eight seconds (much longer than what I usually upload or the average attention span).

Post broadcast I had the same options at my disposal as uploading a video on Youtube (i.e. disable comments, thumbnail, write in video description and so forth).

Here are some key lessons I found as a result of this experiment:

  • The video quality dipped significantly for the video content. I believe this may be due to the wifi network speed I was using at the time. So even though I had cut my upload time down by X 8, it was at the cost of low video quality. So If you are interested in livestream and have a brand reputation to uphold, be sure to be in a good wifi or use ethernet connection.
  • In terms of content production, livestream means fresh and genuine, so it may not be a good idea to do scripted stuff live on air.
  • There are lots of cool features on Youtube to get an audience to tune it (e.g. scheduled live stream).

I think I will revert back to the old way of producing video content simply because of the wifi network speed I am connect to and the ability to edit stuff out. All in all it was fun and a great learning curve.

Mo! Out!

p.s. I have written two other blog posts which are related to media content. Check them out 👉 Sound broadcasting and 👉 Youtube adventure.

A new Tab added

Great News!

I have finished work on my new tab for this blog titled Learning @ GA .

A creation I am very proud of. You see I am a real stickler for taking written notes, well I was anyway, and I decided to type up my notes on web development.

I wanted to write something for anyone who is not a developer and wants to know enough not to be confused when dealing with one. It was aimed mainly at audience that was 80’s and 90’s born (hence the pop culture references). Throughout I used visuals and gif humour, in order to explain the matter at hand.

According to speechinminutes. com it should only take 84 minutes to read. Enjoy!

Mo Out!

What an Awesome Week and a half

You may or may not have noticed the drop in my blogging and posts on LinkedIn. It’s because I’ve been busy getting assed for a tech start-up. Yes, You heard me, after a full year of sending out applications and being rejected at various stages of the process, someone thought I was ready for a probationary period.

I went through three phases mainly:

  1. First and most obvious one being familiarisation with the existing code base and to my surprise what immense learning curve that was. With all sorts of add-ons used.

    I had to also learn about running command prompt on Windows as the mac machine was not available.

  2. The second part of this whole assessment was working with “Reviews/feedback” third party tools to create a HTML email. I learned about the limitations of working within their site builder. I would generate emails to myself to see if the media queries worked. I was given quite a nice wire frame to work to and I could hear advise of my seniors in my ears “That get it to align 80% and deploy” and “Premature optimisation is the root of all evil”. And thats what I did, The match with wireframe wasn’t precise but it was to a standard that was acceptable.
  3. My last task over the course of this try before you buy week was that of an actual React component. The stuff that full stack developers were made for. I created a component, used placeholders (image URLs, Name, Description) to create the UI and finally worked on consuming a backend API . I refactored the code by removing all html tags from main component and putting them under each sub component.

I learned also about forgotten causes for why you code breaks. This was all due to the fact that I had content from real life to work with. Actual legacy application to work within and a senior on hand to resolve issues with.

I enjoyed the whole process and hope the tech start-up did so to.

Mo! Out!

Social problems faced by Devs

I mean it is really all there in this video but this video is not just for those professionally forced to work with Devs or dating devs, but it is as important for Devs to watch.

The gloves really do come off at one point in this video. I have met, spoken with and interviewed by Developer of all levels, and it is a real problem. The Devs including myself do end up having machine-response like expectations from others.

Another point raised in this is a coder does not need to have slick haircut or wear polished deck shoes to write or work on apps as great as Uber or Deliveroo. In fact if you showed up to a dev opportunity/interview in such an attire it may be taken the wrong way somewhat, because the app users do not have need for that.

So, it is all well to know how machines respond to loops and If..else statments but if it is causing breakdown of communication amidst your professional or personal life, than as a Dev watch this clip for (understand your own flaws === true).

The first step is to acknowledge the errors in your interactions and that can only happen if you understand you can see them first.

I may not agree with everything that is said or to the degree it is said in the original clip and even though it may be talking about seasoned developer problem. However, I do think It maybe worth for all walks of tech-world to get a grips with trappings of tech life.

Mo Out!