Front-end of Web Development up to week 6 of 12

Enough of my wax poetic. Here’s a brief overview of what I’ve learned in the last 6 weeks (half of my journey through the 12-week program at MakerSquare) from the front-end side of web development while at MakerSquare. I will next focus on back-end side and then a comparison between the two.

Front-end web development typically considers the visual, design, and interactive portions of a website or application, with a wink to to the hidden background running of database and server management. While at MakerSquare, I’ve learned how HTML, CSS (SASS and SCSS), and Javascript all work together to create a website, and how one can use nearly all these languages to itself to create a website. This was an incredible concept to me since I believed that a website must consist of both types of front-end and back-end software compromises. For example, Flip Stewart (one of our instructors at MakerSquare) taught us how AngularJS javascript framework and Firebase (online app and API for storing & syncing data) unites to provide a three-way data binding of HTML, Javascript, and Firebase backend. That’s the only pieces of software you need (pretty much).

This is the progression of knowledge I’ve learned:frontend

Obviously, one could argue the order but this how I saw my knowledge mountain progress. Without the prior component, I don’t think I would have understood as clearly. I know I’m just a newbie at this, but the vast amount of open source software and how it has allowed me to expand my knowledge of data abstraction is astounding.

As pa`rt of my culmination of knowledge, I built a simple language translator with a chatroom to speak in this alien, constructed language called Elian, which I plan to explain more in-depth at another point in time.

To explain the figure above more clearly, HTML was the skeleton, CSS was the skin (with SASS/SCSS being specialized tools that helped apply the skin), and Foundation/Bootstrap were the robots applying more beauty and curvaceous features. Javascript and jQuery worked jointly to apply life and movement to my special humanoid. Jasmine was my diagnostic tool to test the features of my creation. AJAX and Node.js were specialized auxiliary features integrated also. All this aggregates into the union of YGAF and eventually fleshing the humanoid as a fully-fledged and working application!

AngularJS is a MVC framework using HTML, CSS, and Javascript. The Model, View, and Controller are an all-in-one package with HTML templates presenting the View while the Model and Controller application logic are combined with Javascript language.



Profuse, overflowing, abundant, bountiful, ample… all the same words to me, all describing the incredible (truly unbelievable) the amount of information I’ve learned in the last few weeks.

Unfortunately, I have not done my best to explain how much I’ve learned. It’s hard to present what you learned, apply it, retain it, and ensure that each morsel and each tidbit of tips, hacks, and tutorials made it across the the marathon of a mountain climb in one piece… and know that I’m only at the beginning.

I feel this necessity to hypnotize and force my eyes to vibrate into a state of trance and slowly fall into the arms of a flow state, without waking in a cold sweat and realize that all this is real! I’m staring at ~50 Chrome browser tabs, each linked to one another in a haphazard trail up a mountain to become the best I can be as a web developer and hopefully a true software engineer. It’s insane how much information there is and how difficult I’ve climbed this mountain but the beautiful feeling of climbing and turning a glance over the shoulder for a brief moment is indescribable. Only those that have climbed before me and left a scent for me to follow can even begin to comprehend the beauty of the climb. It is this that I seek: a state of exhaustion with no physical ability to move but only the mental power to imagine the next frame of my future.

Hah, stack overflow?

Part 2: Git or How I learned to stop worrying and love the troubleshooting

More on some of the troubleshooting I’ve had to handle:

4. Adding a ‘.gitignore’ file after the ignored files are already in the repo (aka adding ‘.gitignore’ file to remove files to be ignored in the repo)

Several times I’ve uploaded ‘.bundle’ and ‘vendor’ folders after running bundler and subsequently pushing that into the repo. Oops. It’s stupid because you are adding files that can be installed from the user, so why make your repo bloated?

After pushing your ‘.gitignore’ file to the repo containing line-by-line the files and folders you want to ignore, run the complicated looking command below…

git rm --cached `git ls-files -i --exclude-from=.gitignore`

… then ‘git add .’ those changes, ‘git commit -m ‘removing .gitignore files/folders”, then ‘git push’ the new changes.

5. Use Seth Robertson’s website for more Git troubleshooting

Seth has made a pretty thorough, no-frills choose-your-own-adventure styled troubleshooting guide. I want to make an even simpler one eventually but his is great. Use it if Git help is just too complicated:

Part 1: Git or How I learned to stop worrying and love the troubleshooting

Git is a version control system (VCS) used to maintain almost every version of your document/source code without worry of losing it locally or remotely on the Series of Tubes, while allowing collaboration and merging of other people’s work on your same project. I say ‘almost’ since it’s dependent on you committing each change.

Git is quite popular because of the advantages of a Distributed VCS such as Mercurial or Bazaar, as opposed to the older Subversion or Perforce as Centralized VCS. Git was created by Linus Torvalds of Linux kernel fame and started up in 2005. It is the primary method, at least amongst all my independent and novice web developer friends and programmers, for version control of source code. If you want more information about its features, go search “wiki git” or the main hub, which will have a ton more information. I wanted to make this blog post to myself and future other novice Git users as a troubleshooting guide.

Makersquare pushed Git since it was the primary means of connecting to their Learn App and to begin the prework I started months ago. Reading over Git’s advantages and usage, I began to realize how naive I used to save my work. I would create “My Book Report-v1.doc” or “Don’t delete this file-My Antonia_My Book-Report—v2-JT-edit.docx” files just to keep track of my files while maintaining versions of it. Then the dreaded “oops I deleted everything single thing and now i must start over” accidents *shudder*. Horrible times.

Git is both relief, harmony, and fragile, all in one. I’ve already saved my ass several times with Git’s system of commits and pushes, but I’ve also screwed up and accidentally removed everything. It’s a thing to wonder and carefully use at the same time.

In summary, here’s the natural, unperturbed flow path for no issues:

(Assuming you have a ‘git init’ on your directory of choice)

1. Modify/change files as necessary.
2. Add/stage the file for tracking
3. Commit the files to the repository
4. Push the data to the remote repository to share with others.


In the times that I’ve screwed up, here are the various troubleshooting tips I’ve kept whenever I got into trouble and couldn’t undo my changes easily or navigate to safe grounds. Hopefully these help others. I will add to the list as my life cycle of a web dev engineer ages:


1. Error with creating a non-existent repository

I fell onto this error whenever I attempted to push to an incorrectly named remote repo, with the ‘.git’ being the only difference between the two repositories:

✘ ~/code/mks/backend/pizza   master  git remote -v
origin (fetch)
origin (push)
~/code/mks/backend/pizza   master  git push origin master
Username for '': lolptdr
Password for '':
remote: Repository not found.
fatal: repository '' not found
✘ ~/code/mks/backend/pizza   master  git remote remove origin
~/code/mks/backend/pizza   master  git remote add origin
~/code/mks/backend/pizza   master  git remote -v
origin (fetch)
origin (push)
~/code/mks/backend/pizza   master  git push origin master

You can see that the two origins are different enough that my ‘push’ wouldn’t work. Check your repository names or copy+paste correctly!

2. Error when pushing, requiring a pulling

Whenever changes are pushed onto your repo from a location that is not your own, such as adding a ‘’ file to your repo online, you need to do a ‘git pull’ before you do a ‘git push’. Take the following error messages and hints with care. They are very helpful!

✘  ~/code/mks/backend/pizza   master  git push -u origin master
Username for '': lolptdr
Password for '':
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to ''
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

~/code/mks/backend/pizza   master  git pull origin master
* branch master -> FETCH_HEAD
Merge made by the 'recursive' strategy. | 3 +++
1 file changed, 3 insertions(+)
create mode 100644
~/code/mks/backend/pizza   master  git push origin master
Username for '': lolptdr
Password for '':
Counting objects: 12, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (7/7), 1.53 KiB | 0 bytes/s, done.
Total 7 (delta 3), reused 0 (delta 0)
53f35a9..d1b427d master -> master

3. Error with pushing to the wrong branch

When you decide to work off a forked repo or if you want to split your work up from the master branch, you must ensure you are working on the correct branch, otherwise Git won’t allow you to push your updates. Makes sense, no? Why would you push work to the wrong part of the repo?

In this instance, I was pushing to the wrong branch (master) and received a notice to pull after pushing to the wrong repo, thus receiving another wrong message to pull again. I realized that after I was on the right branch (library) that I need to push to that branch specifically.

~/code/mks/backend/library   library  git remote add origin
✘  ~/code/mks/backend/library   library  git pull origin master
warning: no common commits
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
* branch master -> FETCH_HEAD
* [new branch] master -> origin/master
Merge made by the 'recursive' strategy. | 2 ++
1 file changed, 2 insertions(+)
create mode 100644
~/code/mks/backend/library   library  git push origin master (wrong branch to merge with!!)
Username for '': lolptdr
Password for '':
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to ''
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and integrate the remote changes
hint: (e.g. 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
~/code/mks/backend/library   library  git push origin library

To be continued…

MakerSquare Summary : Weeks 1 and 2

On July 14th, 2014, as part of cohort 8 of MakerSquare Austin, I started a new epoch in my life. As a previous equipment/process engineer at Samsung Austin Semiconductor and (now defunct) HelioVolt, this life conversion towards software engineering is a major step forward for something that has interested me for so long. I only sampled some basic VBA, MATLAB numerical methods, and some C++ in bioengineering when I was at Berkeley (Hi, Dr. Head-Gordon!). Heh, and I used to think programming was doing bits of modification around recorded macros in Excel.

Anyways, after working in manufacturing companies for so many years, I’ve decided it’s time to change it up. Evolve or be evolved as they say, and Austin is evolving so fast that I don’t want to stay behind. I’ve dabbled in programming only every few years but I’ve always been fascinated by automation (duh, I worked in manufacturing) and the excuse of programmers being “lazy” when really they meant they wanted convenience. Thanks to Amanda @AmandaContrer18 for helping get my questions answered during the application process!

So what have we done in the last two weeks?

Week 1:

  • Philosophy and Expectations of MakerSquare
  • Optimism and Pessimism
  • Setting up the development environment
  • Data structures and modeling
  • Algorithms (in Ruby, Array#pop, Array#insert, Array#include?) optimization and Big O notation
  • Ruby projects and Rspec testing
  • HTML/CSS Design review

Week 2:

  • More CSS Design rules: browser defaults, normalization, clearfix
  • CSS layouts: SASS/SCSS, Foundation
  • Puppy Breeder (Ruby project for a task manager)
  • Javascript diagram notation (JSDN)
  • Javascript and jQuery review and projects
  • Integrated modularity and testing of HTML/CSS/Javascript/JQuery using Jasmine

In Week 1, Way (, a MakerSquare senior instructor, prepped all our laptops (everyone had Mac or Linux OS) with the dev environment we needed. We installed Google Chrome and Mozilla Firefox browsers, Sublime Text 3, various terminal configurations (iTerm2, Meslo Powerline Font, Homebrew (git, zsh, imagemagick, the_silver_searcher), Heroku Toolbelt, VirtualBox, Vagrant, and an Makersquare-customized box for Vagrant. He then spoke about how our optimism and pessimism follow the expectations graph. I couldn’t find the exact graph he showed, but it’s still the same shape and concept. We are embarking on a microscopic random walk of optimistic and pessimistic peaks and troughs. We will be excited but then realize how little we really know, dropping our optimism to a trough of disillusionment, but will then improve as we become stronger and smarter and eventually plateauing in optimism, which asymptotes into a hopeful level of happiness over time!

expectationsPatrick @brennanp, our MKS algorithms instructor, began with concept memory saving and arrays. We then worked on creating Ruby methods for max (without using .max) value of an array, middle_element of arrays, and summing arrays. Optimizing algorithms means time and money. We also spoke about how Big O notation can be used to quickly determine and classify the order and prioritization of algorithms.

Nick @nickmcdonnough, our MKS Ruby instructor, then dived right into Ruby projects and Rspec testing. We learned the basics of TDD and BDD: test-driven development and behavior-driven development. The gist is that BDD is a feature-focused version of TDD. So we should focus on why and how our program works, not just to confirm values and what we expect.

Clay @Clay_Stewart, our MKS Front-end instructor, reviewed our basic HTML/CSS skills we prepared in our prework. My taste for graphic design has definitely improved haha. Geocities? Angelfire? Xoom? R.I.P.

On the administrative side, Chelsea@cheldeli is our community manager and took our pictures for our business cards, Savrut @BubzNRoses and Jessica @jasideshow gave a good presentation about career services including “Makertunities”, which are MakerSquare-alum directed jobs.

In Week 2, Clay pushed the envelope of our design skills and we proceeded into more wireframes. Definitely creating wireframes makes design much easier. Websites and life itself are just sets of squares framed within each other! Just like how all our lives are programmatic, almost robot-life, in most ways. Learning SASS stylesheets makes design even easier, but after learning Foundation templates, I am happy for the glut of web designers who can build nothing to prototype with only a few hours of freetime! That can be me!

Nick then focused on our Puppy Breeder aka Task Manager Ruby application. The basic objective was to satisfy User Stories and requirements to fulfill the completion of purchase requests for breeding puppies. Puppy mill, puppy garden, puppy cage, etc. euphemisms made this project more fun. This encompassed 2 days of Rspec testing and application building.

For the rest of week 2, Gilbert @mindeavor and Clay went over Javascript diagram notation, which I found a bit strange, but now I see. Javascript is a strange language to me since Javascript has specially designated first-class objects, although Ruby seems similar to me. I’ll have to keep studying to see more differences, aside from syntax and boolean conditionals. We made several JS applications that could be further customized with CSS and jQuery.


Whew, it’s been fast and furious and I haven’t finished all the work. Better get to it!




Addendum: Writing is something we don’t do enough of and my high school English teachers taught me the concept of reflection, seeking the metadata to organize the chaotic mind of ourselves. I hope that my reflections become an inspiration to myself and others, in anyway.


What kind of job am I hoping for? Data Science (ok fine Big Data). But let’s not forget Little Data too.

Python: List Comprehensions

Nature and life are one and the same. Programmatic nature is innate. Example, mathematical concepts translated into coded constructs such as list comprehensions in Python: My favorite example from list comprehension is the usage of creating a primes list: >>> noprimes = [j for i in range(2, 8) for j in range(i*2, 50, i)] >>> primes = [x for x in range(2, 50) if x not in noprimes] >>> print primes

[2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47]



I’ve started so many different blogs (xanga, blog, livejournal, another wordpress blog, etc.), but the intention of this blog is to focus on my journey to software engineer aka full stack developer, both through my own volition and through MakerSquare.

Here I will post interesting anecdotes, stories, ideas, tips, inventions, trials, and tribulations. My hope is to provide a record and an inspirational dipping pool for my weary eyes and mind and those of others.