JS for beginners, the TLDR version – Part 1

Java Script is not different then other languages ! It’s unique and special in its own way.

JavaScript has everything you would expect to find all computer programming languages:

  • For loops
  • While loops
  • Do – Then loops
  • If – Else Statements
  • Switch Statements
  • Classes and Objects
  • Functions
  • Dynamically Typed (most languages have this)

However it has some very weird and interesting differences:

  • It has no truth, it is a truthy language
  • You can stuff a function into a variable
  • There are more ways then one to do the same thing

WTF is a Protocol ?

This part of the Swift language is pretty simple to explain. A “Protocol” is what is called a “Interface” in most of the other languages out there. It is basically a set of rules that your struct, class, or enum has to conform to.

You maybe asking your self “why would I ever need this weird construct ? I know whats what. I don’t need these things if I am doing it all myself. ” Well thing is that it keeps you honest, and it keeps you on track.

More importantly it opens the door to things like delegates. More on this in my next blog post.

WTF is an Optional ?

Long story short, it helps you with the turning nothingness into somethingness, or at least simulates a sort of nothingness.

In most languages out there like C#, if a variable does not get initialized with a value or is not set to any value, it’s value is “null”. Knowing this, you can go about your life as programmer knowing that you just have to check if that variable is null before using it, and your good 😎

However with Swift that is simply not the case.  That is due to the fact that the Swift language does not allow variables to be “null” (In Swift its “nil”) at runtime. It believes that every variable has to have some sort of value. To combat this Optionals came into existence. What Optionals do when Swift asks them if a variable is “nil’, is reply with a “maybe, who knows” and Swift moves on.

Literally speaking here Optionals are just a offshoot of your standard variable that may or may not contain a value. This way your never left wonder why something didn’t have a value, when you thought it would.

Heres a coding example shown below:


How to go from view to view in iOS

This might seem like a very simple and easy thing to some of you out there. However I have failed to see any clear and concise explanation of how to do it. So here it goes:

  1. Create a segue from from the blue controller to the red controller. You do this by hovering over the icon pictured below, and then clicking and dragging while holding the ctrl button, until your over the view controller you want to navigate to.
  2. You will be presented with the option below, and for this blog post just pick “show”. Then the following arrow below will be created, this is called a segue. Set the name of the segue to something descriptive, in this case I am going to be naming it “ToRed”.
  3. Create a button on the blue view controller, and create a IB action for that button. Then inside the method call the “performSegue(withIdentifier: “ToRed”, sender: nil)” method where the “withIdentifier” is the name of the segue you want to use to do the navigation.
  4. Now create a button on the red view controller and create an IB action for that button. However this time inside the method call the “dismiss(animated: true, completion: nil)”. This method allows you to go back to your previous view.

And thats all there is to it. Next time I think I am going to be getting into the topic of passing data back and forth from views, which requires an understanding of protocols and delegates.

You can find the link to the final product here.

Understanding Unity – Part 2

The primary language of Unity is C#, but you can also use JS and Boo (python). Most of the tutorials and assets out there use C#. In my opinion C# is just like JAVA so if you know that you should be just fine. When you create a script in Unity it automatically inherits from the class MonoBehaviour. If you do not inherit from MonoBehaviour your class becomes a regular old C# class.

MonoBehaviours have a number of methods that you can implement, that are called over the life time of the object. All the way from when the object first gets created to when it is destroyed.

These different methods are executed in a different stages and these stages happen in a certain order. Going from “Initialization” -> “Game Logic” -> “Decommissioning”. I am not including a few of the stages here because they are not fundamental for getting started with unity.

Then the break down of the most important methods in each stage would be as follows:

  • Initialization:
    • Awake()
      • This function is called the second that an object is created. “Created” in these sense just means the second that game engine acknowledges its existence.
    • Start()
      • Similar to Awake() this function is called right before the first frame that is being rendered. You can think of it like just before it appears on screen.
  • GameLogic:
    • Update()
      • The Update function holds all your game logic, and gets executed every frame
  • Decommissioning:
    • OnDestroy()
      • The OnDestory function gets called just before a object is destroyed. This can come in handy, when you want to say update the score after killing an enemy.

There are also event triggered functions, such as OnCollisionEnter2D that get executed under specific situations. In the next post I will go over these functions, and the 2D physics system in Unity.


Understanding Unity – Part 1


Unity is one of the most popular and easily accessible game engines to date. Which has lead it to become of the best documented and beginner friendly games engines. It can be used to create both 2D and 3D games, and uses C# as it’s main scripting language. And the best part is that every part of it is completely free. Combined with its robust asset store and plethora of free online tutorials it is the game engine to learn these days.

How Unity Works:

To understand Unity, you need to first understand the differences between a library and a engine. A library is something to that you use to build your application, whereas a engine is something that only calls your code.

Unity is an engine, it is something that you have to understand and use in your pursuit to make a game. You do not get to decide on how the physics engine works or how the lighting effects work. You are just given a number of ways to use the sub systems that were created for you.

When you create anything in unity your making a object. Every object in unity has certain properties attached to it, like its position and scale. You can add other components to it like a particle emitter or sprite render. The way you start coding your game is by way of using scripts that you attach to the object like any other component. Once the script is attached you can then start manipulating the different attributes your game object has.

In the second part of this series I am going to talk about the life cycle of a unity object.

Django – Part 2


Django’s slogan is “The web framework for perfectionists with deadlines.” It accomplishes this in a few different ways, forced compartmentalization, built in development tools, and every feature you could ask for. Below we will discuss how to get started, and how see how Django handles MVC.

Getting started:

You first want to setup a virtual env. I am using Anaconda, so I would type in:

  1. conda create –name <your env name> django
  2. source activate <your env name>

Then you would use Django’s great command line tools to create your first project:

  • django-admin startproject <your app name>

Once you the command above you will have your very first Django app. However it won’t do very much. You can execute the following command to run the application:

  • python manage.py runserver

As you can see its pretty boring and does not due much. Django is built around the idea of applications, being different modules in your over all application. These modules are separate from the main project and encapsulate the different features of your application. You create a Django app by then running:

  • python manage.py startapp <app name>

By running the command you get a new directory generated in your folder structure.

Getting started with MVC (MTV):

Dajango does not use the MVC design pattern per say, rather it uses the MTV design pattern. MTV stands for:

M – model : This is a simple python classes.

As you can see it is very easy to start building the inter model relationships. All models need to inherit from the Model class. This is all possible due to Djangos built in ORM. The ORM abstracts away the whole concept of having to work with a SQL DB, since it also provides a easy method revise your tables to reflect changes to your python models. This is simply done by using the:

  • python manage.py migrate
  • python manage.py make migrations < Dajango app name>

T – template : This is your html that displays model data through server side rendering.

Note that to serve these files, they need to be outside your main Django app, and they need to be reregistered in the Django settings file.

V – view : This is interestingly your controller.

As you can see above, you tie the data from your controller to your view by way of dictionaries. And tie your templates to your controllers to your views by specifying the url path name, and the file name.

A point of interest here, is that unlike some other frameworks your mapping a url to a method, rather then a whole class that contains different methods. This method mapping to is done using url.py files that exist both in the directory of the main project and the django app.

The main project directory:

The Django app:

As you can see your using regex, to find a specific url, then mapping it to a method. The main urls.py file contains the main urls for the whole project and imports the urls specifically for the Django app. Whereas the Django app just contains the sub urls for that particular app.

The “; would hit the “first_app” app, then it would then hit any of the sub urls stored in the Django app urls file.

As you can see Django is not that hard use at all, and in most ways is significantly easier then other frameworks, that don’t have all these built in features. In the next blog post I will be discussing Models, the Django admin console, and how the ORM handles model changes.

You can find part one here.