n00b News- CSS Only Sticky Footer

By Jason Land



I’ve started adding a footer to my Origin Code Academy projects that links to my Github, LinkedIn, and webdev website. I’m used to having a sticky footer done for me with what I used to use at work, or having enough content that it doesn’t matter. Since our projects are often quite small, I discovered a troubling gap in my skills. So here is all you need to make a sticky footer using only CSS:

body {
    display: flex;
    min-height: 100vh;
    flex-direction: column;

  main {
    flex: 1 0 auto;

Make sure you have a <main></main> tag somewhere in your HTML. It can even be empty. I wrap my with the main tag when doing Angular UI-Router projects.

Proper hardware

By Jason Land

New monitor day!

There was a spare monitor up for grabs at class today so I grabbed it. We all come to class with just a laptop (though some more dedicated or experienced souls brought their own second monitor), so I felt like this was basically a necessity. I had forgotten how great it was to have extra space since quitting my last job.

I generally work with my text editor right in front of me and the browser window and its console to the left. I also leave my terminal just peeking out behind my text editor so I can see if new lines get logged while saving changes.

I’m used to a customized setup at my old work, and here it’s just a laptop and a desk. I figured I’d write a blog about how crucial it is to have an environment that’s frictionless and healthy for you to work in.


These days it doesn’t really matter what your OS of choice is, so pick whatever you like. Tools like Vagrant and Docker unify development environments for everyone on a team, so you can have a Linux production environment, Windows programmers and OSX designers (or vice-versa). If you’re sticking with a laptop, get one with a SSD for at least the operating system and your main programs, if not your data too. Make sure the keys are comfy and you don’t stumble on them while typing. If you have VMs, you’ll need a minimum of 16gb of RAM.


If you’re programming, that means your primary means of interaction with your work is probably a keyboard. An ergonomic keyboard is a must. I go for split keyboards, with the Kinesis Freestyle for mac at work and an Ergodox at home. Splitting a keyboard is great because it spreads my shoulders and allows my body to rest more naturally. Eventually I’ll convert to two Ergodox keyboards so my muscle memory just has to stick with one layout. Once that unification is complete I’ll start using a Dvorak key layout.


Two monitors is a must, three is a maybe. If the second monitor is big enough (24″ or more), turning it 90 degrees may work and you can have browser and console visible at the same time, though your width will have to be accounted for when doing responsive design testing. When you’re at a bootcamp, this is probably too much, so a 15 inch USB monitor is a good compromise here and can be had for less than $200.

Make sure they’re on risers as well. Place your monitors up so they match your field of view when you look straight ahead.


I find most senior programmers suggest just learning how to not use a mouse, but I find that it’s too intuive to use. However the standard mouse design causes a huge amount of pain in my elbow after extended use, so I go with an ergonomic mouse as well. My personal favorite is the Evoluent Mouse (they make left-handed mouses too).


It’s strange how many used Herman Miller Aeron chairs you can find on Craigslist these days. They’re pretty great though budget options exist. I don’t pay too much attention to how great a chair is because of the next section…


Ikea now makes a cheap sit/stand desk, for around $280. It’s not motorized, but that option will take you uip to $500 for a desk. However, I’ve found that switching every hour from sitting to standing really does help how I feel at the end of the day. Just make sure you have supportive shoes (keep those arches up) and a anti-fatigue pad to stand on.

Angular Anguish and n00b News (Sublime Text Plugins to help with Angular)

By Jason Land

Second week. AngularJS. I knew it was coming. I’m finally in virgin territory- no more know-it-all status with my classmates.

I’ve had a history with Angular- I heard about it as the new hotness, saw a two-way data-binding demo that wowed me:










tried to get it past that rudimentary task more than a few times and eventually gave up on it. I even had to occasionally work with a fairly standard dashboard app built with it at my previous work- nothing out of the ordinary on it, but also incomprehensible for those of us who didn’t write it. Hearing everyone go:

and then get confused, lost and gripe about it

was a familiar story to me. But companies love it and pretty much all coding bootcamps that teach JavaScript also teach Angular, so there’s no avoiding it.

But on the other hand, I found some Sublime Text plugins that will make Angular (and coding in general) much more frictionless.

The obvious one to start with is AngularJS. This has some Emmet-like functionality as it will autocomplete ng-* tags in an HTML document. Very handy if you haven’t memorized all 63 built-in directives.

The other two aren’t specifically for Angular, but they have distinct benefits. The first is All Autocomplete. This will scan open files for function and variable names and add them to the autocomplete list that Sublime Text offers when typing something outside of its normal lexicon.

The second is AutoFileName. This one isn’t perfect, as it activates whenever your cursor is between two quotes, as in both class="" and src=""but it’s easily ignored when unwanted. Since splitting functionality across different files is part of the Angular way, getting the path to those files can be a pain in the ass. This plugin helps autocomplete paths by showing all possible files and folders starting at the top level and narrowing as you type.

Tune in later this week when maybe I realize it’s not so bad or I think we should burn it all down and just use Lisp instead.

Trip to Wonderland: Falling down coding rabbit holes

By Mark Srethabahkti

For my final project, I am making a “Very Simple Sign-in Sheet Application” (or V triple-S A for short) for my dance coach’s studio. I’ve broken the project down into 3 week long sprints with the last week for any spillover user stories and debugging moving towards the final presentation date on August 31st so last Friday marked the end of my first sprint. Conclusion? Fairly successful so far. The goal for my first sprint was to create working API endpoints for authentication and sign-in sheet functionality as well as scaffolding  a MongoDB using Mongoose and all of these benchmarks were met with the commit last week. Through a process I like to call “consume and assimilate” I have managed to stitch together a fully functional API from three separate Treehouse tutorials, a Scotch.IO guide and several of my old projects. In the mean time, Sean also showed us a great program called Balsamiq for creating mock-ups for your front end user interfaces and I was able to show my coach, the “product owner,” some designs so that I knew what I should be building this week.

So what does that have to do with Alice in Wonderland?

My classmate Fabian “FABproject” Martinez coined the phrase in our cohort “falling down rabbit holes” to refer to focusing so hard on a highly specific problem that you get lost in the Stack Overflow, WC3Schools, Youtube tutorial Wonderland of mostly irrelevant information, and that’s pretty much what happened to me today. Also, my particular rabbit hole has to do with time so, I guess it’s fitting that I followed the white rabbit. You see, in order to create an instance of a sign-in or lesson object, I wanted to create a date object in the local time so that I could later filter the lessons returned using the local time, but no matter what I did MongoDB would save the date object as “Coordinated Universal Time” or UTC for short. I spent hours looking at time related stack overflow posts, documentations and plugins before Sean slapped some sense into me and told me that this “problem” that I had would not even impact my end user. It was only after I stopped focusing on the time problem that I realized that while MongoDB stores all incoming date objects in UTC format, it also automatically converts filter times passed into it from local time into UTC and returns results based on that filter. My end user literally would not be affected at all. *sad trumpet noise*  Anyways, I figured why let my research go to waste. The following is a list of some sites and plugins with useful date functions:

  • AngularJS Date FiltersI ended up using these to change the incoming UTC time from my database into the local time format for display for my view layer. Very easy to use, and very powerful as it will use the local time of whatever machine is calling the view.
  • Moment.jsAwesome plugin that extends the functionality of the traditional DateTime data type allowing users to not only format time in ways not possible with just Angular Date Filters, but also to perform basic arithmetic like adding or subtracting days and hours.
  • StackOverflow on ISOString DateTimeFabian linked me some code from this posting that helped him get his Javascript Datetime element to line up with SQL’s DateTime data type. The second highest posting  contains a helpful code snippet for creating a DateTime object in Javascript that is usable in SQL.
  • MongoDB Date() DocumentationIn case you were wondering about how MongoDB stores DateTimes, the documentation is chock full of exactly how much everything is displayed as UTC time all day every day. So there’s that.

It’s really easy to get caught up looking for answers for a problem that seems completely game-breaking at the time, but are actually relatively trivial. When you’ve spent a few hours on the same problem, it doesn’t matter how important you think it is to your overall project, it is time to step back, take stock of the whole situation, and maybe you’ll find that the solution is simpler than you thought. Sometimes those who wander really are lost, so thanks again Sean for pulling me out of the rabbit hole.

n00b News- Adding Texture to your Site

By Jason Land

The first week at Origin Code Academy is mostly focused on JavaScript basics. A lot of our first projects look very much the same, especially once our teacher introduces CSS frameworks to us (Bootstrap is popular, but I prefer Pure).

However, the blank backgrounds can be boring, despite Google’s full court press with Material Design.

A flat design, super boring.

Our solution was to add some code to the body tag in CSS like so:

    background-image: url('images/gplaypattern.png');
    background-color: #558ED3;

The first line in that CSS rule sets an image for the whole body of the HTML page. However, this has to be a transparent PNG file. The background-color rule tints it, and is changeable without re-rendering a new PNG file.

We used textures from  Transparent Textures and Subtle Patterns

Note: You’ll have to open the PNGs from Subtle Patterns in a photo editor that lets you change the transparency and bring it under 100%, as they only offer opaque images.

N00b News- A Git Cheatsheet for First-time Coders

By Jason Land


Make new repo on Github.com or Bitbucket.com, and a new project folder on your computer. Inside the folder type:

git init
git status
git add name_of_files_to_commit
git commit -m "description of this commit"

git remote add origin git_repo_url
git push -u origin master

There was much wailing and gnashing of teeth over some of the command line concepts yesterday,

…so I thought I’d post a blog about the basics just to cement them in my head, and provide a link to pass around to my classmates. This will work for both OSX, Mac, Linux and the sites Github.com or Bitbucket.com.

The first thing to do is to navigate to the folder you want to build your project in on the command line. If you’re in the main user folder on OSX, you’d see something like this (it looks slightly different on Windows, but the commands I’ll be using are the same:


I’m going to put my new project in my Sites folders, and that command looks like this (press enter after you type it):

cd Sites

Once you’re where you want to create a new project, make a new directory, and navigate into it.

mkdir my_new_project
cd my_new_project

Even though you haven’t written any code, at this point you should initialize the folder as a git tracked project.

git init

We’re going to leave the command line briefly and open your browser to Github.com. Login to your account (or register one if you’re really starting from scratch), and create a new repo. Give it any name you like (it doesn’t have to match your folder name) and click “Create repository”


Make some empty files in your folder in your text editor (like index.html, style.css, app.js) and save them. On the command we’ll check out which files are new by typing in:

git status

It’s a good idea to track from the very beginning, so we’ll add these to our staging area (files being readied for a commit):

git add index.html style.css app.js

If you type in git status again, you’ll see the added files have changed to green.


Time to commit! One simple command for this:

git commit -m "description of the commit you're making"

The -m is necessary after git commit so Git knows to add your message in quotes to your repo. Now we need to get our Repo location from your Github/Bitbucket account. Both of those websites show this to you when you create a new repo, it looks like this:


Copy both of those lines and paste them into your command line. Once you do that, refresh the page on Github, and you should see it now shows you’ve uploaded the files:


Broken Code

By Fabian Martinez

Get comfortable with having your code broken…that is one thing that I am coming good with coping with…a lot of people say failure but I don’t think of it that way (“being a developer you have to get good with dealing with failure every day…”)…the reason is because failure only happens when you stop…developers we don’t stop we keep going till it works…so again we have to get comfortable with breaks because it is only temporary…one of my class mates said that he felt like the scene of hamburger hill when they were climbing the muddy mountain and I think that is an awesome saying because when you do reach the top it is going to be a fantastic feeling …so let’s climb that mountain and make some great code!

Writing Good Angular Code

By Cameron Wilby

We’re big fans of John Papa at Origin Code Academy. The work that he and the Angular community have put into writing style guides not only for Angular 1.X, but also for the upcoming 2.X release is awesome.

Personally what I like about the guide is that lots of the style points come from real world experience, written from a point of view where readability and maintainability are king, because complex software is rarely written written in a vacuum. There are often many developers working on a single project, and with the rising salary of keeping good talent on your team – ensuring that they are able to be efficient and enjoy the work they do is paramount to providing value to a software solution.

I’ve included and paraphrased a few of my favorite style points below.

Write “Singularly Responsible” Angular components.

Follow the Rule of 1 principle, which states you should define 1 component per file, recommended to be less than 400 lines of code. One component per file makes your code far easier to read, maintain and avoid collisions with teams using a source control solution like Git or Mercurial. It also helps to avoid hidden bugs that often arise when combining components in a file where they may share variables, create unwanted closures, or unwanted coupling with dependencies.

/* avoid */
    .module('app', ['ngRoute'])
    .controller('SomeController', SomeController)
    .factory('someFactory', someFactory);

function SomeController() { }

function someFactory() { }
/* recommended */

// app.module.js
    .module('app', ['ngRoute']);

// some.controller.js
    .controller('SomeController', SomeController);

function SomeController() { }

// some.factory.js
    .factory('someFactory', someFactory);

function someFactory() { }

Use a consistent naming convention for your Angular components.
Use consistent names for all components following a pattern that describes the component’s feature then (optionally) its type. A recommended pattern for you to follow is feature.type.js. There are 2 names for most assets.

The file name (checkout.controller.js)
The registered component name with Angular (CheckoutController)

There’s a running joke in the industry that there are only 2 hard things in software development. Cache invalidation, and naming things. Naming conventions help provide a consistent way to find content at a glance. Consistency goes a long way to help your project, team, and company provide tremendous efficiency.

Wrap Angular components in an IIFE.
Now that we’ve talked about keeping Angular components in separate files, let’s talk a little bit about how those files should be laid out. Wrap the entire file in an IFFE (Immediately Invoked Function Expression). This ensures that variable and function declarations do not live longer than expected in the global scope, which helps to avoid naming collisions with other libraries. It also allows you to utilize the “use strict” declaration without affecting third-party components that may not utilize “use strict”.

(function() {
    'use strict';

        .controller('CustomerController', CustomerController);

    function CustomerController() {        

Keep data calls in a factory, not in the controller.
You should keep logic for making data operations and interacting with data in a data service, contained in an Angular factory rather than in an Angular controller. Make data services responsible for XHR calls, local storage, stashing in memory or any other data operation you can think of, and inject those into your Angular controller.

The controller’s responsibility is for the presentation and gathering of information to/from your HTML. It should not care how it gets the data, just that it knows who to ask for it. This will not only simplify the code in your controllers, but also make it easier to unit test your controllers by being able to pass in a mock data service, which is simpler than mocking the $http service.

/* recommended */

// dataservice factory
    .factory('dataservice', dataservice);

dataservice.$inject = ['$http', 'logger'];

function dataservice($http, logger) {
    return {
        getAvengers: getAvengers

    function getAvengers() {
        return $http.get('/api/maa')

        function getAvengersComplete(response) {
            return response.data.results;

        function getAvengersFailed(error) {
            logger.error('XHR Failed for getAvengers.' + error.data);

Write minification-safe Angular components.
Minification is the act of compressing client code delivered by a server so that the file size is lower. If you have a lot of user load on your web application, this will help your server handle more requests with fewer resources. For Angular code to be correctly minified, avoid using the shortcut syntax of declaring dependencies without using a minification-safe approach like this:

/* Original Code */
	.controller('DashboardController', DashboardController);

function DashboardController(common, dataservice) {

Instead, you should manually identify dependencies using $inject. This is the most readable way to manually declare dependencies for an Angular component.

/* Original Code */
	.controller('DashboardController', DashboardController);
DashboardController.$inject = ['$location', '$routeParams', 'common', 'dataservice'];
function DashboardController($location, $routeParams, common, dataservice) {

Don’t use $scope, use the Controller-as syntax.
Controllers are constructed or “instantiated” when they are needed, and destructed or “deinstantiated” when they are no longer needed. The Controller-As syntax is closer to that of a JavaScript constructor than the classic method of injecting a redundant $scope service into your controller. It also promotes the use of binding to a “dotted” object in the View, which brings a greater sense of context, is easier to read, and avoids any and all scope inheritance issues that you may run into in the future.

// dashboard.controller.js
(function() {
    'use strict';

        .controller('DashboardController', DashboardController);

    function DashboardController() {
        var vm = this;
        vm.title = 'DashboardController';

Installing Node, NPM and Express on OSX from Scratch

By: @jeffwardcoding


You need to have Git installed. By far, the easiest way to do this is with Homebrew. Follow these Homebrew Installation Instructions.

Now that you’ve got Homebrew installed, use it to install Git from within your Terminal:

$ brew install git

Installing Node

If you don’t have Git installed, use Homebrew to install that first.

Here’s a basic installation guide for Node.

Getting Node’s source code

If you don’t already have a place to store external source code, put it somewhere usefuls, like a “src” directory in your home folder:

$ mkdir ~/src

Now that we’ve got a place to put it, let’s download Node:

$ cd ~/src
$ git clone https://github.com/joyent/node.git
$ cd node

Building Node

You’ll want the latest stable version. Stable version are use even numbers, while unstable dev versions use odd. At the time of this writing, the latest stable release is 0.4.7, so let’s checkout that tag before building:

$ git checkout v0.4.7   # you'll get a note about a detached HEAD state.
$ export JOBS=2         # optional, sets number of parallel commands.
$ mkdir ~/local
$ ./configure --prefix=$HOME/local/node
$ make
$ make install

Telling your system where to find Node

We’ve got to add the node bin folder to your path so that you can easily use node from the command line. Open up your.bash_profile and add Node’s path to your PATH.

$ nano ~/.bash_profile

If you already have a line that starts with export PATH=, just add Node’s path to the beginning. For example this:

export PATH=/usr/local/bin:$PATH

would become:

export PATH=$HOME/local/node/bin:/usr/local/bin:$PATH

If you don’t already have a PATH export declared, just add this to the file and save:

export PATH=$HOME/local/node/bin:$PATH

Testing your Node installation

To make sure this all worked as expected, open up a new Terminal window and run:

$ node -v
> v0.4.7


Installing NPM

Now, I’m guessing you’d like to install some Node programs, like Express or something like that. EASY! NPM is incredibly easy to install:

$ curl http://npmjs.org/install.sh | sh

This should print out a bunch of stuff, ending in It worked. There may also be a single npm WARN Not installed in blah blah blah... line – don’t worry about it.

Testing your NPM installation

Again, just open a new Terminal window at run:

$ npm -v
> 1.0.1rc4

Another success!

Bash Completion

Once incredible helpful feature of NPM is that implements Bash completion, which makes using NPM quite a bit easier at times. To enable this you’ve got to source NPM’s completion file into your .bash_profile. Open .bash_profile up again, and add this to it:

source ~/local/node/lib/node_modules/npm/lib/utils/completion.sh

Installing Express

Now that we’ve got NPM installed, we can use that to install all the Node.js goodness we can get our grubby little hands on, including Express!

NPM 1.0 is more more opinionated than earlier releases – instead of installing modules globally by default, modules are installed at the project-level. Command-line tools, on the other hand, can be installed globally.

The express Command Line Tool

Express is both a project module, and a command line tool, so we’re going to install it in both places. Let’s start by installing it globally:

$ npm install -g express

Now that we’ve got our express command-line tool, let’s use that to create an Express application:

$ mkdir ~/Sites/bitchin-express-app
$ cd ~/Sites/bitchin-express-app
$ express -s -t jade


Dependency Management

Next we need to specify our application’s dependencies. NPM gives us a clean and maintainable way to do this with the “package.json” file. Create this by running npm init from with the root of your project, and just follow the prompts:

$ npm init

When you’re done with that, add your dependency declarations to the file. Express and Jade are both dependencies for me. This is what my final “package.json” looks like:

  "name": "bitchin-express-app",
  "description": "My Bitchin' Express App",
  "version": "0.0.0",
  "repository": {
    "url": ""
  "author": "Dan Dean <me@dandean.com> (http://dandean.com)",
  "directories": {
    "lib": "."
  "scripts": {
    "test": "expresso"
  "engines": {
    "node": ">= 0.4.7 < 0.5.0"
  "dependencies": {
    "express": ">= 2.0.0 < 3.0.0",
    "jade": "*"

Dependency management is one of NPM’s excellent features. We can automatically install all of our application dependencies by simply asking NPM to take care of it. From within your project folder run:

$ npm install

You should notice that your project now has a “node_modules” folder. Inside that you’ll see an “express” folder, which contains the Express framework module for use just with your new application.

Running Your Application

We’ve got to create a couple more little files before we’re ready to go: our “layout” and “index” files.

$ touch views/layout.jade views/index.jade

You’ll notice that back when we created our application we passed the -t jade argument to express. This configured our app to use the Jadetemplating engine.

Open up “views/layout.jade” and paste this into it:

    title Hell's Yeah.
    link(rel="stylesheet", href="/stylesheets/style.css")
  body!= body

And paste this into “views/index.jade”:

h1 This is a Bitchin' Web Applications!
p Am I right?    

Now all we have to do is start our fucking rad, Bitchin’ application! From the root of your project run this, the open thehttp://localhost:3000 in a browser:

$ node app.js
> Express server listening on port 3000

In Conclusion

Hopefully this introduction is enough to get you up and running. There’s a whole lot going on in the community. Keep up to date by following the Node blog. If you want to explore the many modules available for use in your applications, poke around the NPM Module Registry.


Source: http://dandean.com/nodejs-npm-express-osx/

The Revealing Module Pattern || JavaScript Design Patterns

By: @jeffwardcoding

The Revealing Module Pattern

Now that we’re a little more familiar with the module pattern, let’s take a look at a slightly improved version – Christian Heilmann’s Revealing Module pattern.

The Revealing Module pattern came about as Heilmann was frustrated with the fact that he had to repeat the name of the main object when we wanted to call one public method from another or access public variables.  He also disliked the Module pattern’s requirement for having to switch to object literal notation for the things he wished to make public.

The result of his efforts was an updated pattern where we would simply define all of our functions and variables in the private scope and return an anonymous object with pointers to the private functionality we wished to reveal as public.

An example of how to use the Revealing Module pattern can be found below:

var myRevealingModule = (function () {

        var privateVar = "Ben Cherry",
            publicVar = "Hey there!";

        function privateFunction() {
            console.log( "Name:" + privateVar );

        function publicSetName( strName ) {
            privateVar = strName;

        function publicGetName() {

        // Reveal public pointers to
        // private functions and properties

        return {
            setName: publicSetName,
            greeting: publicVar,
            getName: publicGetName


myRevealingModule.setName( "Paul Kinlan" );

The pattern can also be used to reveal private functions and properties with a more specific naming scheme if we would prefer:

var myRevealingModule = (function () {

        var privateCounter = 0;

        function privateFunction() {

        function publicFunction() {

        function publicIncrement() {

        function publicGetCount(){
          return privateCounter;

        // Reveal public pointers to
        // private functions and properties

       return {
            start: publicFunction,
            increment: publicIncrement,
            count: publicGetCount




This pattern allows the syntax of our scripts to be more consistent. It also makes it more clear at the end of the module which of our functions and variables may be accessed publicly which eases readability.


A disadvantage of this pattern is that if a private function refers to a public function, that public function can’t be overridden if a patch is necessary. This is because the private function will continue to refer to the private implementation and the pattern doesn’t apply to public members, only to functions.

Public object members which refer to private variables are also subject to the no-patch rule notes above.

As a result of this, modules created with the Revealing Module pattern may be more fragile than those created with the original Module pattern, so care should be taken during usage.