Share the Love! Free Programming eBooks

Leave a comment Standard is giving away these free programming books and I thought I would share the love for anyone who hasn’t seen them yet. There are more available from their website but these are the ones I was most interested in. Enjoy!

Screen Shot 2018-01-31 at 4.26.46 PM

Screen Shot 2018-01-31 at 4.26.54 PM

Screen Shot 2018-01-31 at 4.27.01 PM

Screen Shot 2018-01-31 at 4.27.11 PM

Screen Shot 2018-01-31 at 4.27.18 PM

Screen Shot 2018-01-31 at 4.27.24 PM

Screen Shot 2018-01-31 at 4.27.37 PM

Screen Shot 2018-01-31 at 4.27.44 PM


GIT Tutorial: Fetching and Testing Pull Request Branches Locally

Leave a comment Standard

There are a lot of times when you’re using Git and BitBucket in a work environment and you want to be able to test someone’s PR branch without having to download a patch or clone it. Here’s a nifty trick that will allow you to fetch and checkout PR branches on your master repo without having to clone or patch from BitBucket.

1. Add your remote master as an upstream

git remote add upstream ssh://user@myrepo.git

2. Change your new remote to fetch from your pull requests instead of regular branches

git config --add remote.upstream.fetch '+refs/pull-requests/*/from:refs/remotes/upstream/pr/*'

3. Now fetch the PR branches that are currently available in your repo

git fetch upstream

4. Finally, you can use the ID of the PR you want (the ID will be available in the URL of the link to the PR) and simply checkout the PR with that ID number by replacing ID with the number of the PR in the code snippet below.

git checkout upstream/pr/ID

5. Voila! You’ve now downloaded a PR branch to your local git instance and can run it like you would for any other branch.

Tutorial: Flexbox dividers with positioned labels over top

Leave a comment Standard

It’s so frustrating to make a horizontal ruler with label text positioned on top of it. There are many different ways to do it but they require a lot of custom CSS that makes it hard for you to easily move the label around to a new position if you need to. I’ve come up with a way to fix that problem using FlexBox and I wanted to share. This JsFiddle will let you select from a few different styles of horizontal rulers, whether it is a full span of fixed width and where the label should be positioned in just a few lines of code. Enjoy!

Highcharts Tutorial: Set Custom Tooltip Date Format

Leave a comment Standard
high charts custom date format in tooltip

I spent a good 4 hours trying to figure out how to get HighCharts to use a custom date in the tooltip without using the custom tooltip formatter. Geesh! Why is it so painful?? Anyways, here is a JSFiddle showing how you can add your own custom formats to HighCharts and then use them in the date formats on the tooltip. In this example I’ve added a %c and then I can use that anywhere in HighCharts that I want to use my custom date formatting.

Jasmine Tutorial: Unit Testing Promises In Angular Services

Leave a comment Standard

So recently I’ve been doing a lot of Angular unit tests with Jasmine and Grunt. I have to say, testing promises is extremely frustrating and most of the examples I found out there either 1) didn’t work or 2) wouldn’t allow you to test content in a then block if you had multiple chained promises, or if you had a promise being called from and returned from another service. After many hours of frustrating trial and errors I found a solution I’m happy with so I want to share.

Let’s assume this is your controller:

'use strict';

angular.module('myModule').controller('myCtrl', ['$scope', 'api',
function ($scope, $api) {

  $ = null;
  $scope.message = null;

  * Load some data from the API service
  * @return boolean
  $scope.loadData = function () {

    var config = {
      method: 'GET',
      url: '',
      headers: {'Content-Type': 'application/json'},
      data: null

    return $api.load(config).then(function (request) {
      if (request) {
        $scope.message = 'Your data was successfully loaded';
        $ = request.response;
        return true;
      } else {
        $scope.message = 'The API service failed';
      return false;

And here is the service making your API calls:

'use strict';

angular.module('myModule').service('api', ['$rootScope', '$http',
  function ($rootScope, $http) {

    * Makes the $http request given the proper configuration options
    * @param Object configruation for the $http request
    * @return Object $http promise that resolves to request payload or error
    this.load = function (options) {
      return $http({
        method: options.method || 'GET',
        url: options.url || '',
        headers: options.headers || null,
        data: || null
        function (request) {
          //we got a response back, return just the API payload data
          if (request.status === 200 && {
          } else {
            return {
              results: false,
              message: 'API request error',
              response: request

Finally, this is your working unit tests:

'use strict';

describe('testing myModule', function () {


  var $controller, $rootScope, $scope, $api, $httpBackend, $q;

    inject(function (_$controller_, _$rootScope_, api, _$httpBackend_, _$q_) {
      $controller = _$controller_;
      $rootScope = _$rootScope_;
      $httpBackend = _$httpBackend_;
      $q = _$q_;
      $api = api;
      $scope = $rootScope.$new();

      $httpBackend.when('GET').respond('test http GET call');
      $httpBackend.when('POST').respond('test http POST call');

      $controller('myCtrl', {
        $scope: $scope,
        $api: $api

  it('has a $scope.loadData() function', function() {

    var testConfig = {
      method: 'POST',
      url: '',
      data: { some: 'data'}

    var fakeData = { data: 'is fake' };

    //we spy on the API service and also return a fake promise call
    spyOn($api, 'load').and.callFake(
      function() {
        var deferred = $q.defer();
        deferred.resolve({result: true, response: fakeData});
        return deferred.promise;

    $scope.loadData(testConfig); //call the function we're testing in the controller
    $scope.$apply(); //we have to call this so Angular will try and resolve the promise
    expect($api.load.calls.count()).toEqual(1); //make sure it's called the api service
    expect($scope.message).toEqual('Your data was successfully loaded');

  it('returns an error if the API fails', function() {

    var testConfig = {
      method: 'POST',
      url: '',
      data: { some: 'data'}

    spyOn($api, 'load').and.callFake(
      function() {
        var deferred = $q.defer();
        result: false,
        message: 'api error'
      return deferred.promise;

    expect($scope.message).toEqual('api error');

Continue reading

Sample Angular Website

Leave a comment Standard

So I’ve seen a lot of people using AngularJS but I see very few examples of a website made using it. That’s why I decided to post an example website to give you an idea of what a full website looks like using AngularJS. It has samples of some of the things you’ll commonly find in a website made entirely with Angular:

  •  Navigation & Routing
  • Providers & Directives
  • Controllers & Config Blocks
  • Data Calculations
  • Filtering

Sorry if you’re looking for Angular 2.0, this was made with Angular 1.5.8. View, fork and/or edit the files on Plunker!

The Game Plan: Getting Started

Leave a comment Standard

Your game design can run fairly smoothly or it can be a continuous cesspool of hardships and setbacks and pain points. In the next few series of posts I’m going to try and help walk you through the process of getting your game up and off the ground, from what you’re envisioning in your head to an actual working version. So, let’s get started.

1. Get It Out Of Your Head

It’s time you pull out a pencil, pen, or open your laptop to a writing program. First thing’s first, you have to get your game out of your head. Write it down and put it somewhere you can reference it later.

2. Writer’s Block

So if you’ve opened a text editor or you have a pen in your hand you’ve successfully completed step one. Now, what do you write? I like to start with the five W’s:


  • Does your game appeal to a specific age range or interest group or gender or even ethnic background?
  • Will you have a large audience your game will appeal to or a small audience?
  • What are the benefits and downsides of the audience you’ve identified?


  • What kind of game are you trying to make?
  • What programming language best suits this kind of game?
  • Does it fit into a specific genre of game or does it span multiple genres?
  • Does it embody a completely new genre?
  • Can you find other games that are similar to the game you are trying to make? If so, what do these games do well and where do fall short?
  • Are there lots of other games on the market similar to the type of game you’re trying to make?
  • What will your charge for your game?
  • What do other, similar games of this type charge?
  • What are the benefits and downsides of the type of game you’re trying to make?


  • Where does your game take place?
  • What kind of maps or features or environment are unique to your game?
  • What are the benefits and downsides of where your game takes place?


  • When will you have time to work on this game?
  • When can you start this game?
  • When can you fund the development of this game?
  • What are the benefits and downsides of developing this game?


  • Why are you making this game?
  • Why is your game unique?
  • Why will your game stand out from the crowd?
  • Why will people choose to play your game over other similar games?
  • Why will people pay for your game?
  • What are the benefits and downsides of making this game?

3. Make A Design Document

Your design document is a refined version of everything you’ve written down in step 2. Go back and really analyze what your goals for the game are and if what you’ve written down makes sense in the larger picture. Sometimes a good idea you have for one area of the game will conflict or make another part of the game tedious, uninspired or downright frustrating. For a game design document I like to use the following format:

  1. Intro
    • What is the vision for your game and a short description of how the game is played
  2. Audience, Platform & Marketing Strategies
    • Who the game is for, what platforms you’re making it for and what sets your game apart that will make it marketable and different from others
  3. Core Gameplay & Mechanics
    • How the game is played including physics, rules and limitations
  4. Characters
    • What characters are in your game including what they look like, their names and backgrounds and personalities
  5. Story, Themes & Twists
    • If your game has an overarching story then you’ll outline your plot and how the game progresses with the story line
  6. World
    • Describe the world your game is set in, including maps and locations and their purpose or importance
  7. Assets
    • All the different images, music, animations, etc that you will need to have a fully functional game
  8. Technical Specs
    • What language you’re using, how games are loaded/saved, where games are stored, the number of servers you’ll need and anything else relating to the technical setup of your game
  9. Interface
    • What the game interface looks like and how the player will interact with it
  10. Outside References
    • Articles, links, design inspriations, or anything else that you’re using as a reference for the game you’re making
  11. Appendix
    • Code style guidelines, dictionary of terms, and anything else that is important for understanding your design document that may not necessarily relate to your game directly

Once you’ve fully fleshed out your game design by going into depth about the features, physics, economy, weapons, characters and how the game works it’s time to break it down. Start by creating lots of of small, easy tasks you can accomplish in order to see your core game mechanics to completion enough that you could play a simple version of your game without any extra bells and whistles. Set yourself up to do as little as you have to but as much as you need to in order to get a really simplified, yet completed, version of your game.