Encapsulation patterns in AngularJS

Providing public and private design patterns in Angular.js

The concept of Encapsulation is an important design pattern in most object-oriented programming designs. Determining which properties and methods should be accessible is a nice forcing function because it forces the programmer to think about how his or her could will be consumed.

If you’ve spent any time in the world of Javascript, you probably know that Javascript does not provide native support for defining public or private interfaces.

If you haven’t explored Javascript encapsulation in the past, encapsulation is most often used in Javascript Constructor functions which operate a bit like class definitions in Classical inheritance using the new Object() constructor pattern.

Encapsulation is typically achieved by defining local variables within the function object. These locals can only be referenced by other functions defined on the function object.

You can find a more detailed exposé of encapsulation in javascript here.

What about AngularJS?

Angular provides a number of ways to create javascript singleton objects that are available via dependency injection. Depending on who you talk to, it’s a bit of a mess. At the end of the day though, AngularJS is just javascript and we can build encapsulation into our Angular factories and services using the same types of patterns.




I find myself thinking a lot about what should be exposed publicly in my view controllers. As a beginner, it’s easy to just attach your functions and variables to $scope (or this if using `controller as` syntax) and call it a day. But do you really need your view to have access to all of those functions? In most cases you don’t. Instead, assign these private functions or values to a local variable within your controller function.

I often define a function that initializes the default values within the controller.

Making peace between server and client: Camelizing and de_camelizing Restangular data

Sometimes you find that the API that you’re interacting with via Angular $http requests uses the underscore convention rather than Javascript’s camelCase convention. In this case, our Ruby on Rails app spits out blobs like the second example and we ultimately want it re-serialized like the first example. It’s easy to create a confusing quagmire of under_score and camelCase functions and keys all over your project if you don’t implement a way to translate object keys.

We need some way to re-serialize this object’s keys to camelCase after a response is received. Similarly, requests made to the server should be translated to under_score like the server is expecting. Fortunately the Restangular library makes this quite easy to accomplish.

Restangular allows you to add response and/or request interceptors which allow you to modify your data before and after a $http request. Using the Humps library to camelize and deCamelize, it was simple to modify the requests and responses handled by Restangular. Simply add a config block and use the provided RestangularProvider to add a responseInterceptor and a requestInterceptor:

How to specify a custom model class for your ActiveModel::Serializer 0.8 Serializer

ActiveModel::Serializers gives you a lot of flexibility and modularity when it come to generating JSON for your Rails api. Serializer just work when the serializer is named after the model it references ( MyModelNameSerializer). You also knew you could easily extend a base ActiveModelSerializer using class inheritance MyExtendedSerializer < MyModelSerializer. Recently, however, I found myself building a serializer that couldn't be named by ActiveModel::Serializer convention and couldn't inherit from the base serializer for that class. So where does this gem find it's dependent class? It turns out that the method Serializer#model_class, defined on Serializer defines this behavior.

It was relatively simple to override this behavior: Just override this method in your serializer so that the class method model_class refers to the parent class.

ENV vars: A better way to pass arguments to rake tasks in Rails

Today, I happened upon a situation where I needed to pass an argument into my rake task. In the past I’ve passed an argument using an array-like syntax like like this post describes. While this works, I didn’t really like the syntax and it didn’t seem very natural in the command-line.

Calling a task like rake seeder:seed[100,someString] didn’t seem as readable as it could be.

I’ve found a solution that I like better that utilizes a method from Thoughtbot in their Paperclip gem.

Set an environment variable as part of your rake task command, then look for that ENV var during the task.

Then look for the env var in the task itself.

It’s simple and a lot more readable than passing in an array of arguments.

Building your Tolerance for Risk

In the past year, I’ve quit my comfortable job, started my own consulting business, moved to another country (한국!), learned ruby on rails and started working on product at a startup. It’s been a whirlwind of a year and I’ve learned a ton about taking chances.. and reaping the rewards.

Dealing with risk and risk tolerance over the past year has reminded me a lot of the training that I doing in the pool in my teens. In fact, the past year has demonstrated to me that becoming a risk-taker is less about a specific attitude and more of a learned skill that must be exercised. I’m convinced that we can acclimate our own tolerance for risk, if we so desire.

Training to become a risk-taker reminds me a lot of athletic training. Throughout my teens, much of my free time was spent preparing for national level swimming competitions. Many hours are spent training your body, conditioning it for the exact kind of pressures that it will experience in a racing environment. One of those physiological processes is the build up of lactic acid. As you push your body past its ability to produce energy with the aerobic cycle, your muscles produce lactic acid to provide alternative energy through the anaerobic process. Lactic acid buildup hurts. You feel like you have hit a brick wall, but with specific training, your body begins to adapt and recover from lactic acid. In short, your body develops a tolerance for lactic acid. It’s adapted with a little hard work and training.

forget business school

Rewind back a little over a year ago and you would find me working comfortably as a frontend developer at an awesome athletic company. I loved most of my job, but I was frustrated because I didn’t feel like I was moving towards my ultimate goal of building a startup from its very early stages. That dream felt distant and vague even after working for several years out of college. The clock in my mind was ticking. I felt weak and afraid at times because I saw little tangible progress towards my dreams.

Logic and advisors told me to go back to school and get an MBA at a top biz school. I had watched other entrepreneurs though, build their own companies from the ground up, leveraging their own technical skill. All of them told me, that they learned more on the job as an entrepreneur than they ever would in an MBA. So I put my GMAT score aside and decided to keep working on product. I resolved to look into going back to get a masters in CS.

leave your job, move to korea

Around the same time, my wife accepted a job working at an international school in South Korea. We had 24 hours to decide. It was one of the toughest decisions I’ve personally had to make. Leave everything familiar and try to make things work in a foreign country? The big question for me was “What will you do in Korea?”. I had a vague notion that I could do freelance development. In the end, we decided to take the leap.

learn a new skill

The next leap was a little easier. I sat down with my boss and our CEO over lunch and gave them the news. It was way easier that I ever expected it to be and they even wanted to use me remotely as a consultant at least for a couple of months! About the same time, I heard about Dev Bootcamp, a new hacker school in SF.

I was skeptical that they could deliver on their promises, but after meeting several of the students and talking with the founder, I decided to put $10k down and give it a shot. Even if others could learn in 10 weeks, could I develop enough knowledge to build my own apps in 10 weeks? Dev Bootcamp ran June 6 – August 18. I would leave August 19 for South Korea. The next few months are a blur. I packed boxes, learned ruby notation, solved sudoku puzzles, learned OO design, and built my first Rails apps. I lived out of a backpack on the weekdays and didn’t know what I should call “home”.

my first client

I finished Dev Bootcamp in August, brimming full of new knowledge. But doubts still lingered. Could I build a product that people would actually be willing to pay for? Could I actually make a living? I got my first full-time consulting gig in September and finished my first commercial app in December! I learned sorts of new things from Chef Recipes to Amazon S3 to ajax uploads along the way. My second project, built on an existing Rails project and was successfully re-launched this past month.
Consulting pushed my risk tolerance to an entire new level. Several times, I had no idea what I would be working on in the next week. Somehow, I would always end up with more than enough work in the end. Along the way I learned a lot from my clients about how to communicate with your customers.

join a startup

In February, a got an email from a friend from Dev Bootcamp. He was looking for an engineer to join him on his startup. He’d already sold me on his idea back in July. There were(are) still a lot of question marks, but after a year of uncertainty, the choice was not nearly as hard as I expected it to be.

So finally, I reached my “dream”. I was at the point where I could work on a startup in the early stages of formation, where my impact would be directly felt. I always thought there would be one big decision, to drop my current job and start working on something new. It didn’t happen that way for me. There were a bunch of other decisions over that past year that made the decision to work on a startup even possible. I’ve now been working on Workhands for a little over a month. I have no doubts at this point that taking the risk will further my own personal growth and development.

Looking back to just a year ago, each of the risks that I’ve taken seemed a little easier than the one before. I always thought that just one risk would be life changing and I’ve been surprised to find that it really wasn’t. In the end, each risk has lead me to a point where I’ve had new opportunities. I feel more empowered and in control of my life than I ever have before. So if you currently thinking about taking the leap, taking a risk or chance on yourself, please do, you owe it to yourself!

More >>