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 Exercism.io 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!