Getting started with makefiles

The make command allows for quick building of your C++ (and other language) projects. For large projects, this becomes very helpful to update portions of the project rather than recompiling everything. In this tutorial, I’ll give you a intro to using make.


We will start with 3 files that make up our program. Make a new directory and add these three files.

mkdir make-tutorial
cd make-tutorial
touch myclass.h myclass.cpp main.cpp
// myclass.h
class MyClass {
    void foo();
    int bar;
// myclass.cpp
#include "myclass.h"
#include <iostream>

using namespace std;

void MyClass::foo() {
  cout << "From Foo" << endl;
// main.cpp
#include "myclass.h"

int main()
  MyClass myClass;;
  return 0;

Automating the Basics

Let’s start by simplifying our compile flow of these three files. To compile them normally, we would do the following:

  g++ main.cpp myclass.cpp -o hellomake

Then we can run the program.


This is pretty simple, but we can make that a little easier with a make file. By default, when running the make command, the program will look for a file called makefile. Let’s start with that.

//  makefile
    g++ main.cpp myclass.cpp -o hellomake

The syntax starts with the target. Here we have the target all which will be the default command for make to execute. We can then run the program likes so:


That make things a little easier 😀

Multiple Build Points

When projects get bigger, you will want multiple targets so that you can build portions of it rather than the whole project or the all target. Let’s use the current projects to show this with make. It will seem overly complex for this project, but hopefully you can see the potential.

Let’s create a new file called makefile-targets. Then add these two lines

all: hellomake

hellomake: main.o myclass.o
    g++ main.o myclass.o -o hellomake

This creates an all target that links to the hellomake target. This target will take two object files and build our whole project.

Next we will need to create targets to build those object files. Do that in this way:

myclass.o: myclass.cpp
    g++ -c myclass.cpp

main.o: main.cpp
    g++ -c main.cpp

The above will create our object files for our all target to use. Finally, it is good practice to create a clean target to remove object files:

    rm *o hellomake

The final file looks like this:

// makefile-target
all: hellomake

hellomake: main.o myclass.o
    g++ main.o myclass.o -o hellomake

myclass.o: myclass.cpp
    g++ -c myclass.cpp

main.o: main.cpp
    g++ -c main.cpp

    rm *o hellomake

We can then build our project likes so:

make -f makefile-target

Notice how we use the -f flag to specify our new file.

You can then rebuild a specific target like by adding an extra parameter to the make command:

rm myclass.o
make -f makefile-targets myclass.o hellomake

This allows us to rebuild only the myclass rather than the whole project.


There is much more to make than what I have shown you. Hopefully, this gives you a glimpse into the powerful tool of make.

If you really want to dig in, check out the docs:


Interfaces and Abstract Classes in Javascript with ES6

Interfaces and Abstract Classes in Javascript with ES6

Recently while working on a refactor, I wanted to use ES6 classes
combined with polymorphism. For this, I needed an Abstract Class.
However, in Javascript ES6, Abstract Classes are not a standard. However,
there is a work around using the method below.

The Abstract Class

This class is the base Chat Reporter. The details aren’t super important,
but as you will notice, I create separate reporters that need to implement
the Flag method for flagging a chat.

class ChatReporter {
  constructor (message) {
     this.message = message;

  flag () {
    throw new Error('You must implement this method');

The Subclass

Now with the flag method throwing an error, this will force our subclasses
to implement, otherwise the compiler will throw an error.

class GroupChatReporter extends ChatReporter {
  constructor (message) {
     this.message = message;

  flag () {

And that is it! This is a simplified version of what I actually implemented. If you want to see the real life example, checkout it out on Github:

iOS Dev => Full Stack Dev with freeCodeCamp: Week 1

If you don’t know what this post is about, check out my first blog post. Or you should know that I am using freeCodeCamp to turn my knowledge of iOS to the broader understanding of Full Stack development.

Week 1 Update

So of course how we start off week 1 is by being too busy to actually work on my freeCodeCamp project.

Here are my excuses:

  • My day job has been consuming my work hours.
  • My fiancé takes up my free time because I love her.
  • I’ve been working on the Software Engineering Daily podcast app
  • For some reason, I’ve also been watching a lot of Kitchen Nightmares.

Excuses aside, I did finish the jQuery section of freeCodeCamp and started Basic Front End Development Projects. So I have finished the first three sections or thirteen hours of tutorials so far (Even if I did finish two sections before starting to write this blog). That’s not a terrible place to be and now I’ll be able to start building some real projects with everything I’ve learned.

What I learned

This week I only went through the jQuery section of freeCodeCamp, but I also have never used jQuery so it was a very refreshing experience. I love learning new stuff. Coming from Swift I have few dislikes of HTML, CSS, and jQuery right now, and I believe most of these have some libraries that fix my issues. That being said, the main thing I don’t like about these languages is that everything is a string! I mean, purists will probably say I’m crazy but I come from Swift being my first language and seeing a "background-color" class is a bit crazy to me. I’m used to view.backgroundColor and if I misspell backgroundColor or the class doesn’t allow me to override this variable Xcode tells me everything.

It’s a strange place to be, but I also don’t need my hand held at this point in my development journey. It’s not that bad but I am glad I started learning Swift instead of starting in web development. Swift gave me a good foundation to learn the basic programming skills without getting caught up in little errors here and there.


To conclude, this week was alright. Going forward I’m going to spend more time focused on completing the next section, Basic Front End Development Projects. This should also be a more exciting than what I’ve been doing so far since I’ll be creating actual apps. Now, this is where the real fun begins!

Follow my journey & tell me yours!

If you’d like to see where my journey takes me, follow this blog and follow me on Twitter!

Please consider 👏👏 this post if you’re on Medium and post a comment giving me some feedback!

iOS Developer to Full-Stack Developer With freeCodeCamp

or Why I Am So limited As An iOS Developer: freeCodeCamp To The Rescue!

or I Want To Be a Full-Stack Developer and freeCodeCamp Will Get Me There

I couldn’t decide on a good title so I put a bunch of the bad titles up instead. I’m an iOS Developer, I have been for almost 2 years. But in the next few months, I’m going to start and document my journey to become a full-stack developer. Also the only resource I’ll be using is freeCodeCamp.

Why am I doing this? How will I make the jump to full-stack developer only using freeCodeCamp? What’s my game plan? Well, read the rest of the article. You’re supposed to skip over this blurb to the headed sections.

Why I am making the move to become a full-stack developer

I am an iOS Developer. I’ve been working as an iOS Developer for 1 year and 9 months. After the first year, I started feeling comfortable programming. For the past few months, I’ve felt very confident in my abilities as an iOS Developer. I’m now confident enough to start working with design patterns that scared/stumped me when I first started programming.

This is great! Exactly where I wanted to be in a little over a year and a half. My only issue is when I think about my next project it has to be an iOS app. Not only that but the app has to be server-less because I don’t have a good grasp on how to spin up a server. Right now I’m stuck in a box. While I think a lot can be accomplished with the right boundaries, I’m not feeling that. I’m feeling that when I have an idea I can only do 1/3rd of the idea.

So I’m done! I’m blowing the top off this box!

How I will make the jump to full-stack development only using freeCodeCamp (“Blow the top off this box”)

With a lot of hard work and determination! …and a huge catalog of challenges that cover every part of full-stack development.

While I will have to work hard and spend a lot of time learning, today it is easier than ever to make the jump into programming or general tech. It’s also even easier for someone who knows how to program to become a better programmer! There are plenty of resources out on the web today. These resources can teach you everything from the soft skills you need to manage projects, to the hard skills like advanced programming patterns. Though I am going to focus on seeing how far the resource freeCodeCamp can get me.

I’m going to talk about how great freeCodeCamp courses are in the next section. Though if you haven’t checked out freeCodeCamp yet, do yourself a favor and check out this amazing resource! freeCode Camp has hundreds of hours of challenges that will take you from beginner programmer to full-stack developer. This is exactly why I chose freeCodeCamp. These courses have more than enough information for me to start my full-stack development journey.

The Game Plan

Now let’s talk about freeCodeCamp

I’m choosing freeCodeCamp because it is the most extensive resource for front and backend development on the internet today. I’ve already blown through the HTML & CSS, Responsive Design with Bootstrap, and jQuery sections. Though there are hundreds (YES HUNDREDS!) of hours of tutorials that you can complete on their website without leaving your browser. These tutorials cover frontend and backend so freeCodeCamp should be the only learning resource I need. I have also been told there is a beta website where they have EVEN MORE challenges that expand upon the core concepts covered on the website right now.

I’ll be going through the entire frontend and backend courses on the freeCodeCamp site. This article talks about the length of time it takes to complete the frontend development part of the freeCodeCamp site. It took the author of this article 185 hours over the course of 45 days to complete the frontend development course. This seems about right considering the 100’s of hours of content that freeCodeCamp has. The courses might not take that long for me to complete but we’ll see as I go along.

Oh, also Quincy Larsen is one of the big inspirations for starting this blog. So double win!

Follow my journey & tell me yours!

This has been a high-level overview of the learning path I’ll be going down. My path may change a bit as I go down it, but we will have to see.

If you’d like to see where my journey takes me, follow this blog and follow me on Twitter!

Please consider clapping this post if you’re on Medium and post a comment giving me some feedback.

Also let me know what you think about this idea:

Starting a podcast chronicling my journey and highlighting YOUR stories if you’d like to share your stories with me.

Tell me what you think so I can continue to push myself in the blogosphere as well as my programming skills!

Responsive iOS UI without AutoLayout

Note: All of the concepts in this post are about creating views programmatically. I do not use Storyboards at all in my projects and therefore do not create views or layout constraints from the interface builder.


Hello, dear reader!

The other day as I was perusing reddit, I came across a post that was something along the lines of “The case against AutoLayout”. The post linked to an issue on the IGList Github repo, where Ryan Nystrom, a developer for Instagram, said “Instagram doesn’t use self-sizing-cells or auto layout at all”. This had me thinking. I don’t love or hate AutoLayout but I’ve also never considered there was a different way to create views, and I certainly didn’t think that a company as big as Instagram would shy away from the industry standard of AutoLayout.

After researching and testing a few ways to create UI without AutoLayout, I believe I have found a solid starting point. Today we’ll go over the basics and I’ll show you how I got from a design in Sketch straight to Xcode using math and not a single AutoLayout constraint.

We’ll go over some of my issues with AutoLayout, explain some of the math and custom view classes we’ll be using, cover our Sketch design, and finally start writing the code in our project. If you’d like to skip to a specific section, please see the table of contents above. You can also just go straight to the Github repo for the full project.

Issues with AutoLayout

I only have 2 real issues with AutoLayout; syntax and scalability. But I understand there are workarounds and/or better ways to use AutoLayout to fix them. We’ll cover my go-to’s to get around these.

1). The original AutoLayout API syntax isn’t as clear as I’d like and takes too long to write.

When you have quite a few views, this syntax just becomes unreadable.

I use Snapkit in most of my projects, which fixes a lot of my frustration with this issue.

But the code isn’t perfect and it leads me to my second issue:

2). Insets/Constants are not scaled for each screen size. So, going from a design on an iPhone to an iPad can be a mess.

All of my apps are for iPhone and iPad because why not? My apps are not made for just one screen size and they don’t use anything specific to a particular device. So, the only barrier is my UI. AutoLayout is supposed to bridge this gap, but there are a few problems. For example, when setting up my layout I set an inset of 10 points for the left side of my view:

Then, when I launch my app on the iPad simulator, the inset will still be 10 points but the iPad has a much larger screen size. This leads to odd looking views that have been stretched instead of scaled proportionally.

These issues seem small but they start to snowball when you’re working on a lengthy project, working on multiple projects, or trying to get a UI design from Sketch just right, to balance your designer’s temperament. [make designer happy?]

If you have no issue with AutoLayout, feel free to read this simply as an alternative way to create UI. This isn’t a statement about the right or wrong way to create UI, because there is none.

The make up of a view frame

Let’s quickly talk about view frames. We create views like this:

The way I think about views in iOS development is as if we are placing the views on grids. The points on a grid are represented by a point on the x axis and a point on the y axis or (x, y). With an iPhone 7 screen as an example the grid starts at the top left of our screen at (0, 0) and goes all the way to the bottom right which is (375, 667). This is because an iPhone 7 screen has a width of 375 points and a height of 667 points. Of course the points scale out the bigger our screen is.


Frames also have a min, mid, and max property for the x and y values.


We can use these properties to get the top left point, top middle point, and top right point of any view. The same goes for the y axis. If we use these properties conjointly, we can easily snap views to each other.

Extensions, Math


Before we start creating views, we need two functions in an extension to help calculate the height, width, and position for our views when they are being scaled for different devices. These two functions:

These functions follow a simple formula:

CurrentScreenHeight / (iPhone7ScreenHeight / NumberToCalculate) = CalculatedHeight

So, for a view with a height of 50 on an iPhone 7 the calculations would be:

iPhone 7: 50
iPhone 7+: 55.1724137931035
iPad Pro(9.7 Inch): 76.7616191904048
iPad Pro(12.9 Inch): 102.3988005997

Now, our view height stays proportional to the screen height with a two simple functions.

In the functions I calculate the return value in relation to an iPhone 7 screen because that’s where the majority of my designs start. But feel free to tweak this and start from whatever screen size fits your needs.

More UIView Extensions

I also made up some UIView extensions that allow you to quickly get the points for the frame of a specific view. This will clean up and shorten a lot of our code. Think of this as “”.

Here’s the full extensions file:

Custom UIView Initialization

Alright, so while writing this article, I’ve gone back and forth on creating custom classes, inheriting a protocol, and copy pasting the same init method with a few tweaks. But honestly, my code just looked ugly. Like really ugly. That’s where you need to start, though. Looking over my code, I figured out a way to build a protocol, extend that protocol, and then extend the UIView to conform to my protocol. In doing that, I rendered all my custom classes obsolete and I turned 227 lines of code to 55 lines of code.

So, to show you a bit of my process, here is some of the code before:

Oh man, that looks good.

So, let’s break down what we’re doing here. First, we create a protocol with an init function and a function called “performLayout”. This makes sure that we implement both in our extension. We’ll be using the init method to initialize our view and calculate a new frame for it. Extending UIView means that any class that inherits from UIView will also use this custom init method.

After that, we call “performLayout” in the init method so we can use that method in the UIView extension and our custom classes. The “performLayout” method is where we’ll do anything specific to whichever view you’re using. This will always be called during initialization, so we don’t have to override our init method. You’ll see how we use this in a class later.

Note: We had to add “@objc” to our performLayout function in the UIView extension because in Swift 4 there is either a bug or a new syntax for the Swift 3 inference for @objc and I kept getting warnings about it.

I put in this bit with my old code to highlight that everyone writes ugly code and that you are supposed to write ugly code. My ugly code worked and then when I started writing this article it was confusing to ME. So I rewrote everything, even most of the article. I’ve done this about 4 times just so far. Just an interesting tidbit. Never be ashamed of your code. Please resume.

Sketch design

For the actual view we will recreate in Xcode, I have chosen the Post view from Instagram. This is a post I made of my puppy, Bandit, growing up way too fast. The design is simple and with this, we can see how Instagram would avoid using AutoLayout in their app.

I won’t go too in-depth into Sketch or our design. You can examine the image below and see that I have used a plugin called SketchMeasure to measure the height, width, and distance between views for every part of our design. You will be able to see pretty clearly how knowing all these measurements will help us in coding the views.

Full Design

Coding the views

Finally! Let’s stop talking about concepts and get down to the code.

Coding the Top Bar

Top Bar View

Create a new Swift file or create a UIView and call it “TopBarView”. Make sure this view inherits from UIView. Then, let’s create variables for all of our views.

And instead of overriding the UIView’s init methods, we will override the “performLayout” method.

The “performLayout” method works like an init method because we call “performLayout” during the UIView’s init method. So, inside the performLayout method we’ll start with the userImageView. This contains our user’s image (go figure). We will go ahead and initialize a new UIImageView, using our custom init method. We’ll also make the view circular and add an image.

First of the userImageView will be a subview of TopBarView so they begin with the same origin point. Right now without setting the origin point of TopBarView the origin is (0, 0). LeftInset represents the x value of userImageView’s origin in relation to it’s immediate superview which is TopBarView. TopInset is the same but for the y axis. So if we set leftInset to 10 and topInset to 10 then userImageView’s origin point will be (10, 10) because TopBarView’s origin is (0, 0). If TopBarView’s origin was (20, 20) then userImageView’s origin would be (30, 30).

Next we set just the height in our init method to 32 and set “keepEqual” to true so the width will equal the height at all times (If you set just the width and “keepEqual” to true, the height will always equal the width).

We use the “keepEqual” parameter here because the height and width for every other view is scaled by different formulas. If we didn’t set “keepEqual” to true, the circular view will become more of an oval when we scale it.

It’s important to note here that the values in our init method are optional and have default values so you can leave out parts like height and width and the view will still initialize. Though if we don’t set “keepEqual” then our height or width will default to 0 and our view will not be seen.

Then we set our corner radius to be the height of the userImageView divided by 2. That will round the view.

We have to set .clipsToBounds to true so that when we add an image it will be masked out and not extend beyond our circular view.

Then we add our image. I’m using an “Image Literal” because I have the asset inside of my project and you can just call the asset by name inside your project.

Finally we have to add our completed view as a subview to our TopBarView class.

Moving on to the userLabel which will contain the username of our user. Here’s the code:

We create a new UILabel with the same topInset as our userImageView and with a leftInset of 52 so our userLabel origin point will be (10, 52) in relation to the superview, TopBarView.

We also would like to scale our font in relation to screen size as well, so we’ll use the same getValueScaledByScreenWidthFor function we use for our views. The function will work the same way with any value you put in but I’ll create an extension for fonts some other time.

Then of course we add the userLabel as a subview to TopBarView.

Side note: We could easily calculate the inset from the right side of the userImageView like so:

The inset is 10 from the right side of the userImageView which we can find using userImageView.topRightPoint().

Last we have the ellipsesImageView. The code for this imageView is almost exactly the same as the userImageView.

And we’re finished with the TopBarView.

Coding the Button View

Button View

For the Button View we don’t do anything too crazy, so I’m just going to throw the code for the class up here.

Coding the Comments View

Comments View

The comments view isn’t super complicated but we do a few new concepts that I’ll cover. But of course every view starts the same.

We use the performLayout method again

In our performLayout method we will start with our first label:

We create a variable called “labelsWidth” because all our labels will have the same width. If you look at the Sketch design you can see that there is a 16 point inset on both sides of each label so we just multiply 16 with a calculated width by 2 and subtract the total frame width by the outcome. We’re using 375 because that is the width of an iPhone 7 screen.

Next we create our description label:

We snap the description labels origin point to the bottom left of the likeLabel by using “likeLabel.bottomLeftPoint()”, use the same width, and a height of 42. We also want the username to be bold for this label so we do a bit of fiddling around with attributed strings. There are much better ways to work with attributed strings here but I just threw this together and it works for our use.

Our second to last label is the viewAllCommentsLabel. In the actual Instagram app, you can see the last comment that was made on that specific post but we’re going to avoid that for now since we’d need to use a stackView and hide/show labels when there are a certain number of comments. That’s a bit much for this tutorial but i’ll fit that into it’s own smaller tutorial.

Here is the viewAllCommentsLabel code:

Our last label is the timeLabel. Nothing complicated here:

Lastly for this view, I’m going to show you a way for a view like this to calculate it’s own height depending on the sum of it’s subviews. We can quickly accomplish this like so:

I’m adding this because not only will we want to add another label or two but labels can have multiple lines and descriptions can get very long in Instagram. There are a few tricks we’ll need to use to correctly calculate the height for each label and at the end this snippet will calculate the sum of every subviews height.

And that is it for the comments view.

Putting it all together

Now that we have all of our individual views, let’s put all of them together in another view that would be our view to use in a collectionViewCell with some setup functions, but we created some default data for every view so we won’t do any of that today. We’re just going to call this new view in a view controller.

Start out like we do with our other views:

You see that we skipped over the postImageView and that’s only because it is simply an image and doesn’t need to be a separate view.

Let’s initialize all our views in the performLayout method:

Hopefully by now you can tell what we’re doing here by snapping every view to the bottom of the view above it.

And if we’d like to use this PostView in a view controller all we have to do is use it like this:

Also I hope you caught that I am not adding the subviews height’s together and setting the PostView’s height based on that. That is something that I’ll leave for another post to cover all together or for you to figure out on the side.

After we create the PostView and initialize it in a view controller, we’ll see that our UI scales for every screen:

All Screens

And we’re done! Let’s talk about drawbacks.


The biggest drawback for this workflow is that when in Xcode you won’t be able to see the changes you make to your views until you run your app. Fixing that issue specifically is a whole other can of worms. Though the future of this project isn’t to work with UI inside of Xcode. The future of this project is to export your designs directly from Sketch, or a similar design program. That way we keep our design and our code separate. This of course has it’s own positives and negatives but for my projects, that is the workflow I am working towards.

Another drawback you may be thinking about is rotating an iPhone screen. Though for this project, a lot of the apps I have created, and even most the apps I use on a daily basis don’t rotate at all. This is an issue I’m experimenting with but it’s not a huge deal for me at the moment.

The third biggest drawback would be animation. I’ve been experimenting with this more recently and I can see it not being to hard to implement a quality animation library. We’ll save that for another post though.

Despite these drawbacks, I believe there are ways to get around them and I believe they aren’t a critical issue at this time.


To conclude, this is a new way of creating UI that I have been experimenting with. The next steps are refining the classes and giving a bit more flexibility with what you can do with them. I’m very happy with where things are now though and these concepts are at a base state where I can use them sparingly in my projects where performance is key.

Speaking of performance, I never spoke about performance. Mainly because I don’t have a good way to test the speed of UI but there are obvious performance benefits to not using AutoLayout. If you have a way, please let me know!

If you would like to see this workflow in an actual app check out my apps Kibbl and the Software Engineering Daily Podcast App.

That’s about it though! Thank you so much for reading. Please let me know what you think by commenting on this post or sending me a message through social media(see below). If you have something to contribute to this project, please visit the Github repo.

Also since writing this post, I’ve made this entire responsive UI concept into a CocoaPod library you can use in your projects. Here is the KTResponsiveUI Github repo. Go ahead and star and follow the repo because I will be updating this library more and more as I find out new and better ways to implement this type of UI.

The KoalaTea Github:

My Twitter:

My Reddit:

If you liked this post, sign up for the KoalaTea Newsletter. You’ll get notifications when we have new blog posts and we’ll be working on even more content soon!