A Blog With Rails

Introduction:

Warning this only works on Mac OS.

Now before you start thinking your going to make the next WordPress, let me just say we are only going to be making the MVP of a blogging site, that’s right a MVP. What is a MVP you may ask ? It stands for Minimum Viable Product, this thing we are about to build is just a web app that has CRUD functionality. What is CRUD you ask ? CRUD is Create Read Update Destroy.

Don’t be afraid of the terminal, the terminal is your friend for life 🙂 you just got to treat it right.

Up and running:

  1. Install Home Brew, is manages the software you need to manage all the software, your going to use to make software. Just follow the instructions on here: https://brew.sh/
  2. Install Bundler, it manages the specific Ruby software libraries for your application. Type the following command “gem install bundler”.
  3. Install Nokogiri, it gives Ruby the ability to understand HTML and CSS among other things. Type the following command “gem install nokogiri”. This is going to take awhile, chill out and take a break you have been working too hard 🙂
  4. Install Rails, its the thing that you build on top of, to make your web application. Ruby the language has libraries for doing different things. Rails is just a really big library for making web based applications.  As you may have guess just type in “gem install rails”.

 

Making a Rails App:

  1. CD into a folder you would like to be in and run the following command “rails new <name of your app here> -T “
  2. Now if you look into the folder you just ran this command in, you will see a folder with the name of your app. Open this with your favorite text editor, VSCode is always a good choice.
  3. CD into the newly created folder, and make your database. You can do this by running “rails db:create” and then running “rails db:migrate”. What this is doing is creating a database, and then populating it with boiler plate info.
  4. Now run “rails s” and go to the URL is gives you. You should see your app, YAY you made your first rails app 🙂 If the URL isn’t working try using http:127.0.0.1/8080 or http:127.0.0.1/3000.

 

Actually making the Blog:

  1. Run “rails g scaffold Blog title:string body:text”. What this command will do is create a Blog object, that has a title and a body and can be stored in our database. Rails knows this since “g” is for generate, “scaffold” is for create everything for me, and the rest is specify what type of things you want there to be, in the object you are creating.
  2. Now you got to let the database know about this blog object you made. To do so simply run “rails db:migrate”
  3. Finally the moment you have been waiting for, run your app with “rails s” and ta-da you go your self a working rails app 🙂

“?” in Angular 5

As you an Angular component has a life cycle, much life us humans. In the beginning we are nothing, we do a bunch in the middle and then we die 🙂 However if you want to call a certain service in your “ngOnInit” to dump some values into a var that appears in your html, your going to have a bad time. Or at least angular is by throwing a lot of errors in your console, I mean it will still work.

To get rid of these errors all you have to do it the following add a “?” at the end of the end of the var that’s in the html, and ta-da errors gone. This works since the “?” tells Angular to chill out there will be a value you there “eventually”. Hmm… but why eventually you may ask ? Its because two functions before “ngOnInit” get called , the very first one being the constructor of the class and the second being the “ngOnChanges” method. So for the execution of the first two methods its asking “WTF where is this thing in the html in the .ts file ?”  which makes throw errors.

Unreal 4 VS Unity

Over the last decade Unity has become the game engine of choose for a good chuck of game developer out there. This is due to many factors, the main factor being that it was designed as a product first. Whereas a number of other engines where brought into existence to make a game. In my opinion this is the key difference between the two engines.

Unreal was originally developed to facilitate the creation of one the most beloved FPS of all time “Unreal Tournament”. Unreal Tournament was designed to be a fast paced shooter, with high graphical fidelity and high performance networking. These things are the key features of the Unreal engine, which is why the engine has the cons and pros that it does.

In Unity’s case it was designed to be nothing but a game engine that would not limit game developers in what they could do, and eliminate the many bottle necks in the game development life cycle. It is simply a product built to make any game, not a particular game.

The differences between the two are seen in the usability of either one the engines. This is most prevalent in the languages that they use. Unity uses C# (aka Microsoft’s Java) whereas Unreal uses C++. For beginners and even intermediate programmers writing effective C++ code it very difficult. Since there is no memory abstraction layer and the syntax is not as initiative to understand. Another point of difference can also be see in the minimum computer specifications needed to effectively use the engines. Unity for the most part does not require much, it could probably run on a potato. Whereas Unreal requires a quad core (i7 preferably), 8GB of Ram (preferably more), and good video card (preferably anything greater then a GTX1060) .

The differences highlighted above also explain where the two engines are usually used. After a while Epic Games started to licences out their engine. The licences were very expensive so naturally the only people that bought it were other game studios, who then made AAA games. Unity on the other hand had a free tier and inexpensive (comparatively speaking)  which lead a lot of indie developers to adopt Unity. Indie developers are usually tiny teams working on shoe string budgets. And they are usually content with their profits if it is just enough to make another game.

The biggest difference has to be the community of either game engine. Unity has one the largest and helpful communities out there. There are a ton of forums, blogs, books, and video tutorials out there on Unity. And then there is the asset store, a market place that allows developers to sell anything and everything one would need to make a game, wither it be art work, scripts, or even music the asset store has it all. The Unreal engine has something simpler however it is  not as robust as  the Unity asset store.

It is in my opinion that if you want to make video games you should use what make your feel comfortable. If your a experienced C++ developer looking to code games and have a few art friends to make high rez 3D models, and you want this to be a PC only game choose Unreal. If your a one man developer that has some coding experience choose Unity.

 

 

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:

 

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

Introduction:

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.