Google Now, the new NSA

I’m going to make a bold claim here, but I don’t care. Google Now is essentially a mechanism to spy on people and I think everyone should disable the feature immediately.

I’ve had a lot of respect for Google over the years since I started using Google Search back in 1998. I really appreciated the “do no evil” mantra, as well as the focus on open source technology and giving back to the community.

Then something happened and a lot of free services started getting cancelled. Next there seemed to be a huge push toward paid goods and services (Play Store, Play Music, Fiber, Fi, and now YouTub Red). Meanwhile many of the open source technologies seem to be self-serving– sure I like AngularJS and am intrigued by Go, but I have no reason to believe Google won’t drop these like hot potatoes.

Despite the progression of the company, back in 2012 I decided to try my hand at interviewing with Google. It literally started as the rudest interview I’ve had to date. At the time, I had only had .NET programming experience in my professional career. The interviewer obviously hadn’t researched me as a candidate to understand that my passion lies in Unix-based operating systems and open source technologies*. The interviewer’s introduction went like this:

So… you’re a .NET Developer? *3s long sigh* Uh.. yeah.. I guess let’s get started.

* After an 18 month hiatus, I returned to a .NET position solely because Microsoft announced plans to open source .NET. That’s how serious I am about it.

I’m sure there’s a bad egg or two at Google, but my experiences haven’t left a positive impression on me. Then, this happened…

I’m a software architect, working on a new web module for club management software. On October 6, I entered some tasks into our project management system by listing out a rough model of some things to code. A few of these tasks included variations on the word “slots”, since this is a module for scheduling players to tees at a golf course.

On October 22, I got around to the task related to implementing slots. I looked over my initial model and felt like there was something missing, so I discussed it verbally with a veteran programmer at the company. This was a 15 minute, in person conversation in which the word “slot” probably came up 50 or 60 times. Later that night, while browsing Google’s Play Store on my phone:

Google is always listening.
Google is always listening.

What. The. Hell.

I immediately texted that screenshot to the guy I talked with that day. We both thought it was weird and a little creepy.

I had previously noticed ads targeted based on things I knew I had conversations about, but thought little of it. “I’m sure I googled it if I was talking about it,” I’d tell myself. This time, I’m 100% positive I hadn’t googled anything about a ‘slot’. The concept of a ‘slot’ in the system I’m working with is an abstract way to relate a time (07:15am) to a tee (Tee 1) on an certain day (10/22/2015). I would have had about as much reason to search for ‘slot’ as I would have to search for ‘turkey sandwich’. Just to be sure, I reviewed my search history at as well as locally in my browser. As I thought, there was no recent activity for the word ‘slot’ aside from 10-15 entries on 10/16 about an Amazon deal of the day.


Being a technologist has its perks. I had recently installed CyanogenMod on my phone and it exposes functionality to individually manage permissions for an app. I went to Settings -> Apps -> Google App and clicked the ‘Modify’ button. I then disabled permissions for the microphone (which at the time had been allowed thousands of times). I started watching TV to let my phone sit with the screen off. After 19 minutes, I checked back and the Google App microphone permission had been denied 43 times. In 19 minutes.

I left the ‘OK Google’ detection enabled on my phone for the next day to see how much Google was actually listening to me. This turned out to be 1185 times.

2015-10-24 15.20.01

But, this whole “Google is a bad guy” thing is just conspiracy theory, right?

Consider the fact that within the past year, Google introduced “Google Now” into their Chrome browser. Earlier this year, users became outraged to find out a secret component in the browser allowed Google to listen to everything going on in your home or office. Google’s response was that they don’t care about your conversations and that the recording is only available on or on the new tab page of the browser. Basically, “Don’t worry about it.”

But then, why do they hold a patent for delivering ads based on environmental conditions and background noise? The first image of the patent clearly displays a “client terminal” as a browser or mobile device.

There are a few issues with the Google Now service and the patent that Google holds for targeting ads based on my ‘environmental conditions’. First of all, I opted into letting Google listen to my microphone at regular intervals for “OK Google”. I don’t deny that. I did not opt into Google using my conversations while my phone is off to deliver personalized ads. Maybe I’m wrong and these targeted ads weren’t based on audio recorded while my phone was laying, turned off, on my desk at work while I was having a conversation? If Google Chrome is the culprit, the same issue exists. I’ve opted into Google targeting ads based on my search history. I did not opt into Google intercepting every keystroke in my browser (especially not for private intranet sites) to target me with ads.

Google’s service is apparently still a part of the Chrome browser (navigate to chrome://voicesearch and see for yourself). However, I don’t see a way to disable this. From what I can tell in searching it seems like Google has at least temporarily removed Google Now functionality from Chrome. I can’t tell whether or not the browser has access to randomly record audio while the browser is open.

I wouldn’t be so bothered by this, except that Google hasn’t been completely transparent about what’s being recorded from my phone or browser and transferred to their servers. What if I worked in the US Government? How could Google not be held accountable for their actions when the NSA’s actions have been deemed unconstitutional?

You can disable lots of Google’s search and ad targeting services in your Account Settings. I link to it directly because, as you probably guess, it’s not exactly easy to find.

Flattr this! Free Learning

Over at, they’re offering a free book every day as part of a free learning initiative.

They’ve had some good books in the past for free (R Starter, Node Web Development, Mastering NInject for Dependency Management). You’ve missed those (Sorry!), but there are plenty more coming out each day. They’re only available for 24 hours each.

Click the link below.


Flattr this!

[javascript] Be sure to read documentation carefully…

I have a love-hate relationship with JavaScript. I love the language, but I hate the idiosyncrasies. And like many others, I use MDN pretty regularly to verify function signatures, browser support, or to find example code or shims.

The recently posted article on MDN, “A re-introduction to JavaScript”, demonstrates something I wish JavaScript developers would stop demonstrating: cleverness. The article links to one of Crockford’s posts about JavaScript being the most misunderstood language. Sure, there are quirks, but they’re defined quirks in most cases.

I showed a coworker an example of an oddity in JavaScript the other day.

var x = "016";
var y = 0|x;
// 16

var x = "0o16";
var y = 0|x;
// 14

// 14

// 14

This example works differently in ECMAScript 3 and ECMAScript 5, as beautifully explained by CMS on StackOverflow.

Those are ‘gotchas’ of the language that you just have to know. Yes, it sucks. The big problem is when people share code that attempts to be ‘faster’ or ‘more efficient’. Not only do JavaScript developers have to weed out unexpected behavior from the language, but they also have to be diligent to not assume every other JavaScript developer is sharing bug-free code.

This is what you’d see if you were skimming through the recent re-introduction article:


If you’re in a hurry, you’ll probably not see the important bit of text immediately following the examples:

Here we are setting up two variables. The assignment in the middle part of the for loop is also tested for truthfulness — if it succeeds, the loop continues. Since i is incremented each time, items from the array will be assigned to item in sequential order. The loop stops when a “falsy” item is found (such as undefined).

Note that this trick should only be used for arrays which you know do not contain “falsy” values (arrays of objects or DOM nodes for example). If you are iterating over numeric data that might include a 0 or string data that might include the empty string you should use the i, len idiom instead.

If you’re like me and skimming the article for anything interesting, you’ll have probably also missed the text but immediately caught the possible bugginess of the “nicer idiom”. A less experienced skimmer will see the “nicer idiom”, think it’s clever, and use it somewhere it shouldn’t be used. That’s just how the JavaScript community works, even when code on a trusted website like MDN doesn’t work in a given situation.

For a clear example of the problem, consider this code that uses the “nicer idiom” in the wrong way:

// Correction on Mozilla's 're-introduction'
var arr = [],
    terminate = 20,
    i = 0;

while(i <= terminate){
    arr[i] = i++;

delete arr[5];

// NOTE: arr[0] is 0, which is falsey. This won't print!!!
// change idx=1 and this terminates at index 5.
for (var idx = 0, item; item = arr[idx++];) {

// proper iteration
for (var i = 0; i < arr.length; i++) {
    var item = arr[i];   

Play with this in jsfiddle

The issue here is that the array must not contain falsy values. This includes undefined values in sparse arrays, null, zero, "0", "0.0", "", NaN, document.all, or any other values that coerce to false. The proper way to iterate over an array is to explicitly visit every index unless you have a clearly defined and documented reason not to continue through the array.

The lesson to learn here is twofold: actually read documentation and articles, and don’t just assume JavaScript code is usable code.

Flattr this!

Review: Core Java for the Impatient

I’ve just finished reading Core Java for the Impatient by Cay S. Horstmann. I also own Scala for the Impatient by the same author, and I really loved that book. Having had previous experience with Scala, I was excited to read up on the newer features introduced in Java 8. Maybe it’s because I’m a C# developer professionally, but I’m really impressed with the new Java 8 features.

Horstmann’s books are excellently written for existing developers to quickly become familiar with newer languages and technologies. This book isn’t meant for a beginning programmer to dive right into software development using Java 8, but if you have C#, Java, Scala, or other C-style experience you’ll be set. The pace is excellent and the book flows really well.

While it’s expected that you’re already a proficient programmer, I didn’t get the feeling that it was expected for the reader to understand functional programming. Java 8 introduces a lot of functional style which I’ve seen existing Java developers complain about. I’ve also seen C# developers complain about Java verbosity. While I can’t help people who dislike functional programming, I can say as a C# developer that Java 8 really helps reduce the verbosity of the language.

Before Java 8 you’d have to construct a whole new class that implemented a single method if you wanted to create a Runnable (I have limited experience with pre-Java 8, so forgive me if that’s incorrect). In Java 8, you can assign a runnable to a lambda expression. The compiled code will still contain a one-off class but you as a developer don’t have to worry about those details. This kind of syntactic sugar really makes for more readable and more maintainable code. This is the first material I’ve read which covers Java 8, so I assume Horstmann has covered everything. I actually don’t think Java could have packed anything else into Java 8 that wasn’t covered in this book. It’s hard to believe so much great content was presented in less than 500 pages.

The book is written to appeal to the applications programmer, so Horstmann offers a lot of material such as functional concepts in the Collections and Streams chapters, annotations support, date/time improvements, and internationalization. He doesn’t walk you through creating a parser or an actor system like he does in Scala for the Impatient, but he does give you the necessary information to create a maintainable application in Java. The fact that you’ll learn how to create and process annotations as well as to perform runtime compilation of classes opens a world of possibilities (these sections obviously only touch the surface).

The book also covers Nashorn, a JavaScript REPL that provides access to Java types. I have node.js experience, so this really interests me. I’ll need to investigate the performance implications of running Java code from within this JavaScript environment, but this also opens a lot to an applications developer. For example, if you want to play around with a type in Java’s core library, you can fire up a REPL and instantiate the type rather than going through the rigamarole of creating a throw away project. As a C# developer, I use LinqPad regularly on Windows and Mono’s `csharp` interactive shell on OSX.

Again, I love how concisely the content is delivered. The code that accompanies the book is well structured, allowing the reader to quickly jump between text and the full implementations of the code in the book.

Another thing I enjoyed about this book is how information with short examples are presented in the chapter’s text and exercises are presented at chapter end to give a more hands-on experience. If you skip over the exercises, you’ll still get all of the important material of the chapter.

I would recommend this book to any non-beginner who wants to learn about Java 8.

Rating: ★★★★★ (5 stars)

Review “Learning 2D Game Development with Unity: A Hands-On Guide to Game Creation”

I’ve just finished reading Learning 2D Game Development with Unity: A Hands-On Guide to Game Creation, and I really enjoyed it despite many issues with the actual text (I’ll try to cover everything here). I’m just starting to learn Unity3D for 2D game development, so I’ve only watched a few of the official videos and followed a few tutorials online (the best so far being from After reading this book, I felt way more competent at creating my own game than with tutorials I’ve done elsewhere.

That’s not to say there aren’t some problems with the actual book contents. Quite a few people also have had problems with the book based on the Amazon reviews. I think the greatest comment, and a sentiment I share, is that the book could benefit from a technical edit. I’m a professional software developer, and I struggled to follow what was going on at one point.

This leads me to a major issue I had with the book, dropping a star from my review: Chapter 7 (Setting up Player Physics and Colliders) belongs before Chapter 5 (The Basics of Movement and Player Control). I don’t know how something like this could have been missed, but there’s no excuse for a ‘follow along’ book to be anything but sequential in its content. I’ve self-published a programming book, so I know getting things in the correct order while writing and editing is difficult. I also know that it’s unlikely for an editor or even a technical reviewer to catch this (you literally have to be ‘following along’ to encounter this problem). I toyed with giving the book 4 stars because I loved the content so much, then I thought about how well presented other books I’ve given 4 star reviews are and this book isn’t presented at the same level. If you take my advice and read Chapter 7 before Chapter 5, you’ll have almost no problem with this book. I went through the entire book in about two weeks using Unity 5.

This leads me to another problem which reduced my review by a ½ star: Chapter 14 is incomplete. Chapter 14 covers a then-beta feature of UGUI control layout and interaction. Unfortunately, there is only a single page between adding your first element (a Mask) to the canvas and the end of the book. Had the book just ended there, I would have thought, “OK, that was very high level,” and probably shrugged off the last chapter. The summary of Chapter 14 says “We gave a brief overview of building a simple Options menu with some text elements, buttons, and graphics” and almost none of this was even covered in the chapter (possibly because I’m reading the ebook?). Again, this seems like it would have been caught with a good technical or even a copy edit.

Another 1½ stars get deducted for what others have emphasized as a general feeling of being ‘all over the place’ with the instructions. There are a few times where numbered lists go from selecting a GameObject and doing nothing to modifying some other GameObject and selecting the first GameObject, which then gets modified. I actually found some humor in this, because it reminds me of peer programming with an extremely caffeinated coworker. I couldn’t ignore this in the review, though, because it happened more than once. For another example, the ‘Creating Components’ section of Chapter 2 explains the steps for creating components in what read like commands (but are statements) and the following section defines the actual steps. If someone was to follow the command-like steps (not in list form) of the one section, then the actual command steps (in list form) of the following section, this would become very confusing.

I experienced a general feeling of the book being ‘all over the place’ through Chapter 4. This was where I realized that the end-of-chapter ‘Exercises’ were actually continuations of the chapter content. I’ve literally never read a book where an ‘Exercises’ section wasn’t supplemental content to further your understanding of the material within the chapter. Rather than an ‘Exercises’ section, this book really should have just labeled the section appropriately. DON’T SKIP EXERCISES or you’ll be skipping part of the content.

I will say that other reviewers on Amazon have had unnecessary problems with downloading companion code. The code is very clearly linked on the book’s preface and from the InformIT product page. Even if you were to purchase the book from Amazon or somewhere else, I don’t know where else you’d look for companion content than in the preface.

Please don’t read my review as negative, I’m only trying to point out the issues I’ve found with the book. If you follow all of the exercises, read Chapter 7 before Chapter 5, and pay attention to what you’re reading (some of the examples in the book have incorrect code which have been fixed in the companion content’s project files for the chapter), you’ll really enjoy this book. I enjoyed making the example 2D platformer throughout the book. I didn’t hate or dislike the book, but I also don’t think beginners should have to piece together the contents of a book just to ‘follow along’. All of this stuff could easily be resolved with an updated (and well edited) copy of the book.

One of the things I really enjoyed about this book is how options are explained concisely in a single place. This made me feel way more familiar with the Unity editor and the options for game components. While watching some of the official videos on Unity’s site, I felt like the speaker was moving way too quickly for most people to follow along in the editor while explaining very little about what every option meant. Many tutorials I’ve seen online explain the steps to make a simple game (often lacking sound effects, particle effects, or even most of Physics2D). This book does an excellent job of explaining the basics of everything used to make a 2D platformer game. In fact, if it wasn’t for the editing issues I mentioned earlier, I would have given this book 4.5 or 5 stars. It’s meant for beginners, and I feel like non-programmers and programmers can all easily digest the material.

I made a list of many mistakes I found while reading this book. I’ll be emailing the authors the list, so hopefully the addenda will be updated. I’d love to see the book updated for Unity 5.

Ratings Summary

Overall: ★★★☆☆ (3 stars)

Editing: ★★★☆☆ (3 stars)
Not ‘poorly’ edited, but very close. A lot of the mistakes could have easily been caught by having any non-technical reader proofread the contents.
Presentation: ★★★☆☆ (3 stars)
I gave three stars for presentation because there are some code snippets in the book that just won’t work. I’m not talking about issues like Unity 5 doesn’t have this.rigidbody2D anymore, so you need to create a private variable and gain a reference in the Start or Awake function. I’m talking about things like the EnemyController’s Flip method flipping the instance and invoking flip on a colliding enemy instance, causing the two operations to cancel out. Then, there’s the issue of at least one image, Physics2D configuration, not matching the text in which the text says Player-Player is unchecked while the image shows Player-Enemy unchecked (using image settings makes your player invincible).
Material: ★★★★☆ (4 stars)
I enjoyed the material. Best of many tutorials I’ve followed. I give 4 stars because the book is very basic (it’s for beginners), yet doesn’t exactly introduce best practices. For example, the basic platformer developed in this game creates a single level in which 1×1 components are used for the scene’s map. There’s no mention of performant alternatives like using Tiled and Tiled2Unity to create a single mesh map. This *could* be because Tiled2Unity wasn’t out at the time of the writing, but I’d expect at least the acknowledgement of the performance limitations.
Enjoyment: ★★★★☆ (4 stars)
I thoroughly enjoyed the book. With my notes about following exercises and reading Chapter 7 before Chapter 5, I would recommend for beginners to read this book. One last caveat: if code in the book doesn’t seem to ‘work right’, try the code on the author’s companion site.


Flattr this!

iTerm2 Toolbelt

I’ve been using iTerm2 for 2 or 3 years now, and I’ve only just now noticed the ‘toolbelt’ option in the window menu. You can also hit ⌘⇧B to bring up the toolbelt.

The toolbelt expands to the left of the terminal window and allows you to quickly and easily show all running jobs and send standard signals to the process. You can also switch between profiles (something I rarely ever do), access clipboard history and save textual notes.

Here’s a short video demonstrating the feature:

Flattr this!

Review: Swift for the Really Impatient

I’ve recently finished reading Swift for the Really Impatient. It was a really good book; I’d give it 4 out of 5 stars.

I had previously read Scala for the Impatient by Cay S. Horstmann. I’d like to note that, despite the similarity in title, Swift for the Really Impatient is not written by Cay S. Horstmann. I found the writing style to be noticeably different, but in neither a good nor a bad way. I just wanted to mention that Swift for the Really Impatient is written by Matt Henderson and Dave Wood, in case you’re a Horstmann devotee.

I’d like to make one thing clear for future readers. This book will not teach you to write your first functional OS X or iOS application; it assumes you’re an experienced Objective-C developer wanting to learn Swift’s syntax quickly. It differs in this way from Horstmann’s books, the style of which the authors have attempted to mimic. For example, after reading Scala for the Impatient the reader will be be able to write parsers, perform file and network functionality, as well as design and implement a minimal (yet powerful) distributed event bus using actors. Swift for the Really Impatient won’t teach you any of these types of things. Again, it’s related to Horstmann’s books only by similarity in title.

The book flows very well and very quickly. I read the entire book in my spare time, spanning only a few days. At only about 140 pages, compared to The Swift Programming Language book written by Apple (~600 pages), Swift for the Really Impatient is by far the easiest and quickest book to digest if you want to gain an understanding of Swift. If you’re familiar with Scala, you’ll breeze through this book.

One thing that kept throwing me off in the book was how it really feels targeted toward developers who were previously familiar with Objective-C. This isn’t a bad thing, considering you’ll need to at least understand Objective-C to really dig into OS X and iOS development using Swift. It’s also not a prerequisite for reading and understanding this book. The reason it threw me off is because the book doesn’t really ever explicitly define the target audience as having prior Objective-C knowledge, so sections explaining that “…the syntax of Swift should look familiar to Objective-C developers…” offer very little to developers without Objective-C backgrounds. It is fair to mention that the description on the Amazon product page for the book does clearly define the target audience as experienced Objective-C developers. If you pick this book up having had no prior experience on Apple’s platform, you’ll probably see some of the Objective-C code and think “what the…?!” Good news, though! You should be able to easily glance over the Objective-C parts and still fully understand the syntax of Swift.

I would actually take the authors’ references to Objective-C and expand them a little. Much of the Swift syntax would be familiar to someone with Java, C#, Groovy, or even JavaScript experience. The only places I think some developers may have a hard time are with the sections on Optionals and pattern matching. I felt like the authors excellently explained these concepts, but I’ve experienced first-hand in Scala how Java developers have struggled with these concepts. If you find yourself struggling one these sections, take your time and maybe reread the section (be less ‘Really Impatient’).

I loved how well the authors explained closures. If you have a JavaScript background, the section on closures will make a lot of sense. A book I previously read on Swift application development using Cocoa did a comparatively terrible job explaining closures, so it was refreshing to see the subject clearly and concisely presented in Swift for the Really Impatient.

The book definitely delivers the material you need to quickly understand the capabilities and syntax of Swift. The reason I’ve given it 4 stars instead of 5 is because it doesn’t explain how to execute Swift code. There’s no mention that XCode 6 is required to build and compile Swift. XCode is mentioned only on one page, less than 20 pages from the end of the book. The section mentioned XCode explains how to bridge Swift and Objective-C code which took me a couple of tries to figure out when I attempted this while following Apple’s official documentation. I’d imagine that a truly ‘Really Impatient’ developer would get frustrated with the short explanation of the process.

Swift for the Really Impatient should absolutely be the starting point for any developer hoping to code for Apple products. It is quick, concise, and (most importantly) accurate. I may even go so far as to suggest the book to any engineers who are interested in learning the syntax of different languages.

Flattr this!

Create configurable Angular services using providers

With Angular 2 on its way, it seems like a lot of developers are now afraid of Angular 1.x. I have nothing bad to say about Angular. Sure, some things could be made easier but that’s why Angular 2 is on its way. I’ve played with Angular 2 a bit, and it only works in Chrome. I’m fairly confident Angular 1.x will be around for quite a while.

In that light, let’s talk about creating configurable services. One reason why AngularJS is so popular is because you can easily create modular, reusable code. This code can encapsulate logic, directives, extensible services and factories (via decorators), as well as configurability. I’ll talk about creating directives and decorators in future articles.

This example will be a simple URL constructor for Any AngularJS service can be written to be configurable (if there’s reason to configure the service, of course).

First of all, let’s see how this service will be used.

.controller('View1Ctrl', ['$scope', 'kittyService', function ($scope, kittyService) {
    $scope.kittycat = kittyService.getUrl();
  <p>How about a kitty cat?</p>
  <p><img ng-src="{{kittycat}}"/></p>

Pretty simple. We’ll call kittyService.getUrl() and use the string returned from the service as the src for an image.

To create a configurable service, we’ll use an angular provider instead of a service or factory. The structure I use for a provider is this:

(function () {
    'use strict';
    var module = angular.module('', []);

    module.provider('serviceName', function ServiceName() {
        // use `this` for configurable properties or functions

        this.$get = [function () {
            var service = {};
            // This can be any valid return that you'd normally use
            // with module.service or module.factory
            return service;

This structure is only a little different from a service or factory. Rather than return an object or constructor function, you use this.$get to create your reusable code. What you assign to this property is the array injector for your service definition. You’ll feel comfortable with this syntax if you define your services using the array-based dependency injection:

.service('serviceName', [function (){
            var service = {};
            // This can be any valid return that you'd normally use
            // with module.service or module.factory
            return service;

You can use instance properties and methods on the provider definition to configure your service, then use the private context of your provider to share the configuration with the service. Here’s the full code for the kittyService:

(function () {
    'use strict';
    var module = angular.module('', []);

    module.provider('kittyService', function KittyServiceProvider() {
        var height = 100,
            width = 100;

        this.setHeight = function (h) {
            height = h;
        this.setWidth = function (w) {
            width = w;

        this.$get = [function () {
            var service = {};

            service.getUrl = function () {
                return '' + width + '/' + height;

            // This can be any valid return that you'd normally use
            // with module.service or module.factory
            return service;

The provider has two private variables: height and width. The two methods on the provider object allow you to update these values, but only during the config phase. After your application’s config function has completed, your provider’s functions are no longer accessible.

One problem with this service is that shows the same image for a given combination of height and width. In the config phase of our application, the service’s height and width can be configured randomly:

.config(['kittyServiceProvider', function (kittyServiceProvider) {
    var widths = [200,300,400,500,600];
    var heights = [300,400,500,600,700];

The name injected into the config phase is kittyServiceProvider and not kittyService. This is important. AngularJS knows that when you request kittyServiceProvider in the config phase, you want the object containing your service definition (the KittyServiceProvider function in the example above). Once the config phase completes, the $injector service will prepare your service from the this.$get definition of your service.

If you load the example code, refresh the page a few times and you’ll receive a new kitty image.

NOTE: The heights and widths may not always combine in a way that retrieves an image. Just refresh for another example.

Why not do this in a service?

True, you could do this directly in the service if this was just your code. The benefit here is when you want to share a service with other developers, perhaps on a different project within your company or publicly on GitHub. What if your team wants a 200×300 kitty and HR wants a 500×500 kitty? In these situations you can’t just modify the code with your hard-coded values. True, in this example you could use constants or values instead but then your service would have a dependency on the consumer (this is bad).

A service that dumps a string for displaying a cat image is probably not that useful in the real world. Consider other possibilities. I’ve used providers for creating a reusable notification display which allows you to define whether a notification will automatically close and how long notifications will be displayed if they auto-close. Suppose your application often receives 40x errors when users leave their browsers unattended long enough for an authenticated session to time out; you could create a provider which caches failed requests and retries up to X (configurable) times before giving up. Or, you could create a configurable service which caches those failed requests, displays a login dialog, then automatically retries the failed requests X (configurable) milliseconds after logging in successfully. Those examples would require the use of an http interceptor, and would have been quite a bit more complex than a kitty image linker.


Sample code for this blog post is available on github at jimschubert/blogs.

Further Reading

If you really want to dig into the guts of Providers (versus services, factories, constants, or values), check out Adrian Castillo’s blog post, AngularJS Providers under the hood.

For reference to each recipe, check out AngularJS Provider Recipes on the official docs.

Flattr this!

Review: Microsoft .NET – Architecting Applications for the Enterprise, 2nd Edition

I’ve recently finished reading Microsoft .NET – Architecting Applications for the Enterprise, 2nd Edition by Dino Esposito and Andrea Saltarello. This book caught my attention for two reasons. First, I really enjoy software architecture. Second, I’ve read lots of work by Dino and always found them enjoyable.

The book gives examples of a few architectural patterns like Domain Driven Design (DDD), Command Query Responsibility Segregation (CQRS), and Event Sourcing. It starts with a pretty heavy focus on DDD and seems to assume that you’ve read *The* Domain Driven Design book by Eric Evans. I’ve only skimmed through that book, but it was enough to get many of the references. This book does cover the high level definitions of DDD in a way that the reader can jump right in. The accompanying source code even provides the same example in DDD and CQRS (the two main architectures being discussed).

There were two major things I liked about this book. I really enjoyed how the book isn’t presented as ‘this is the best software architecture, so you should use it.’ Things are presented in a way that clearly states the authors’ position on each architecture. For example, DDD is discussed as a the typical go-to architecture for enterprise systems. It’s a proven pattern that ‘just works’ in many cases. The discussion of CQRS clearly identifies some weaknesses in DDD and supplies an alternative with the explicit caveat that a CQRS-based architecture will change how you think about data.

The other main point I liked about the book is how real-world the discussions are. I usually get that feeling from Microsoft Press books. Early on the authors say, “To design a system that solves a problem, you must fully understand the problem and its domain.” In one of my previous positions, one of the first things I asked when joining the team was, “How have you documented what we’re trying to build?” I received a weird non-answer from the team’s senior developer. I went to the team’s manager and asked the same thing so I could understand the requirements gathering and technical design analysis that went into the product. He said, “We don’t have any of that — we’re Agile.” I thought he was joking, but he wasn’t. Obviously it would strike a chord with me when the authors said, “Agile architecture is sometimes presented as an oxymoron, like saying that if you’re agile you don’t do any architecture analysis, you just start coding…” Elsewhere they described the businessman-developer disconnect that occurs when requirements are incomplete, which is exactly what happened on the previous team I mentioned. It’s like I always say, “If you don’t know where you’re going, how will you get there?”

Another aspect of the book that I think can get buried in reading is the point about developing for a task-based user experience. Too often do developers start coding at the database and work their ways up to the user interface. Without a clean architecture, this can lead to situations where a column in your relational database has to change all the way to the UI. That’s silly. With a good architecture that clearly identifies boundaries in code, you inherently create more reusable and more maintainable code. I think this should be everyone’s main goal while writing code.

I also thought it was cool how the book and accompanying example code demonstrate using a NoSQL database (RavenDB) for an event sourcing application. While I don’t know where I’d ever use Event Sourcing over a more common architecture (mainly because I have to account for the expertise of other developers), I really like the Event Sourcing pattern. Now that Akka.NET is gaining traction, I wonder if Event Sourcing will become the way of the future.

One minor issue I had with the companion content was that it didn’t run as-is. There was a problem with the NuGet packages and MVC5 for which I found a solution at

I would definitely recommend this book for senior developers and engineers. It provides concrete examples and guidance from experienced architects toward more solid enterprise application design.

You can download the companion code for the book at

Flattr this!

Developer James Schubert shares his code and his thoughts.