nackjicholson

[Bower][1] is a package manager for front end web development. It stores all sorts of CSS and Javascript libraries.

Why do you need to use it? You don't. But as I see it, this is the scenario it addresses, and you should decide for yourself if you're fed up with that scenario or not.

How we manage awesome libraries now

You find a new library for javascript that you want to use in your project, maybe you're on the official site for the library, maybe you're on it's github, maybe those are the same thing. You download or clone the project to your computer. You then copy and paste the files into your project. That's pretty easy. Well a few months go by, and you realize the awesome guys that build your new library are really fast at releasing new versions, and you're a few behind. You make your way back to awesomelibjs.com, download the new version, copy it, paste it into your project, and delete the old version. Months go by, you've found 27 other awesomelib.com's, they all update all the time, you have e

nackjicholson

In my last blog on this topic, I claimed that the choice to use RequireJS handcuffed you to the less than awesome experience of using a browser based test runner. I was wrong! Surprised? Yeah, me neither.

I describe my ideal testing experience to be this: Anytime something changes, my personal robot army runs unit tests and tells me what I broke without me having to lift a god damned finger. I'm a programmer, I'm lazy, that's why I do this; so I can automate my life, my code, my income, and just retire to an island while my robots run shit. I'm not quite there yet, but this is here to share with you, how I finally figured out step 1337 of this plan - Automated Javascript Unit Testing.

Get Some Background

In this post, I'm not planning to go deep into how to write unit tests, mock, spy, or any of that. This is going to be about where and how the tests are run, not how to write them. If you're just getting started with testing your RequireJS modules, check out [amd-testing][1] and [RequireJS + Chai + Moc

nackjicholson

I have been wanting to learn how to write a mobile app with Phonegap for, well...since I first heard there was such an incredible thing as Phonegap. The very idea that it could make a Objective-C ignorant (but js ambitious) developer like myself, able to take his satisfactory JS/HTML/CSS code and transform it into a satisfactory mobile experience. Yay, Phonegap. But, you probably aren't here because you don't know what Phonegap is, you're probably here because you want to put the oh-so-interesting angularjs framework onto a phone and do incredible things. Well, so did I. I found great tutorials, the best of which is definitely this 4-part delight by [@markcoleman][1].

[Phonegap and Angularjs the Start][2]

I would've been lost without it. However, after I completed it I wanted to build my own app, and I was looking for a place to start. In my exploratory phase with angular, I had discovered the [angular-seed][3] project and [angular-phonecat][4] tutorial. I knew angular-seed would start me out with runnable

nackjicholson

If you've done much reading about angularjs you've no doubt come across mention of karma, a test runner recommended especially for use with angularjs applications. The [angular-seed][1] project is a great way to get started with the basics of angular testing using karma, but for projects of any significant size you will soon hit the cieling in terms of organizational complexity. What I want to share in this article is the approach I have taken using [Grunt][2] and the [grunt-karma][3] plugin to sustainably manage my projects' client side unit tests and run them via [TravisCI][4]. I plan to write another entry about how to approach the actual minutia of unit testing angular code in the near future.

Karma, configuration for tests

Karma is really nothing more than a set of centralized configuration that builds a test runner for you. The advantage being that it allows you to easily execute tests in a headless browser, and output to the command line. As someone who has actually set all of that up from scratc

nackjicholson

Test setup is hard, it's tricky, and it feels like a hack. That's how you know you're doing it right. (maybe?)

This Post Aims to Cover

• Why you aid testability by wrapping $resource in an api service.
• Test setup and mocking in jasmine to handle api services.
• How to test and resolve promises in your controller specs.

All of the code is available on [plunkr][1]

nackjicholson

Prior to my last attempt to use Yeoman, I had tried on three separate occasions to start a project with it. All three times ended in overwhelming confusion, and a feeling that I was so far behind on the state of web development that maybe I should just quit and start making and selling my own bumper stickers at the Saturday market. I'm really glad I was born with the gift of stubborn perseverance, and a sharp sense of revenge. I became determined to make Yeoman my bitch, and as it turns out, it wasn't that hard...it wanted to be my bitch all along.

All of the Things!!!

I think as a web developer I have a propensity to try to take on too many "best practices" all at once. This is because I spend a lot of time with my head down on a project, and when I get the chance to look up, everyone is gone. On to the next one. When I start something new therefore, I spend time catching up on the state of the world. I found [Grunt][1], [Bower][2], and [Yeoman][3]. They got me with the sales pitch, generating template

nackjicholson

Test Driven Development is a practiced skill. I'll be the first to tell you, I don't have it. I am working on it though. What I want to share in this blog is the process I go through to flip my brain from thinking about how to write code, to thinking about how to write tests I can code against.

I'm going to assume if you've found this blog you already know what TDD is, why you should be doing it, the basics of [PHPUnit][1], and you don't need a lengthy description of what we're talking about here. The gist is this:

1. Write unit tests
2. Write code that passes those tests.
3. Refactor without failing the tests.

nackjicholson

If you've ever had any problem with a program in your career (hardly ever happens), you've checked a log file to help discern "What the !@#$ is happening?". As PHP professionals we know we should be logging to make systems easier to monitor and debug both for ourselves and anyone else who may inherit them. However, the difficulty of creating poignant, searchable, interpretable logs is often overlooked when accomplishing a new task. So being the professionals we are, we set up a log file, have our application spew to it in a few choice locations, pat ourselves on the back for a job well done, and never look at the log file again.

6 months later something breaks, and we're no closer to answering the question -- "What the !@#$ is happening?"

[Monolog][1] is a [composer][2] installable package which provides an extensible framework for delivering logs to wherever you would like them, as well as increasing their utility. While it is possible to make that unorganized log file you're about to make using monolog, i

nackjicholson

A stylistic dispute about indentation and line breaking of large function calls which take a callback as well.

This? All parentheses and brackets on separate lines, arguments indented and given their own line breaks to start on.

async.waterfall(
  [
    func1,
 func2,

nackjicholson

// What do you guys think about this as a way to possibly pass streams
// around from one module to another? I don't think it comes up in simple
// examples but I can see in complex cases where if you wanted a separation of
// concerns for a stream, that you might want them to be passed around. It
// kind of opens up a protocol for communication between modules.
//
// Essentially this is a widgetMaker module which is responsible for making
// widgets. And the widgetKing module wants to be notified every time a widget
// comes off the factory floor.