Quite often I find myself in a situation when I need to rebase my local feature branch containing the latest code against the master, but running git rebase master generates a bunch of conflicts that I am expected to fix manually, though I know that my local feature branch has the latest and greatest and I simply want the changes in my feature branch overwrite the corresponding files in master each time such conflict arises. This usually happens when I am the only committer on the project.

With Gulp 4 approaching its release date many would like to install it now and take advantage of the cool goodies the new v4 comes with. Can’t blame them—we’ve switched to Gulp 4 a few weeks ago and couldn’t be happier.

Level 3 organization

Now we are ready to review the organization structure at the third level. If you’ve missed my previous posts, recommend reading them first before continuing further:

• AngularAtom Component-based organization - Introduction (Part 1)
• AngularAtom Component-based organization - Level 1 Organization (Part 2)
• AngularAtom Component-based organization - Level 2 Organization (Part 3)

app/components/ folder

This folder contains all application components. A component is perceived as a single isolated feature or a single piece of application functionality. They are the building blocks of an app. Each application contains one or more components. Components are stateless and can be reused by other components. This is somewhat similar to the concept of features in Agile/XP methodology.

Examples of such components are:

• auth—enables application to authenticate users (authn) and control their access (authz)
• profile—enables profile management in an application
• site-search—enables search within an application
• dashboard—gives ability to users to manage application dashboard(s)
• …

Level 2 organization

Now we are ready to start reviewing organization structure at the second level. If you’ve missed my previous posts, recommend reading them first before continuing further:

• AngularAtom Component-based organization - Introduction (Part 1)
• AngularAtom Component-based organization - Level 1 Organization (Part 2)

app/ folder

In this post we’ll examine organization of the app/ folder. Since the app/ folder contains user generated application code, we divide it like this:

Global file conventions

• an individual file should be created per each Angular resource (e.g. controller, directive, animation, service etc.) and the file name should incorporate the name of that particular resource, ex. login-directive.js, facebook-service.js, phone-animation.js. Do not combine multiple resources in one file.
• the file name should be suffixed with the type of resource it contains, e.g. ...-model.js, ...-controller.js, ...-service.js and so on
• unit tests should append _spec to the file name and be placed alongside each file the logic of which they are testing. There is no dedicated folder for the unit tests. This is done intentionally, so it is easier to locate the existing and the missing unit tests.

Level 1 organization

Now we are ready to start reviewing organization structure at level one. If you’ve missed my introduction post into component-based organization called AngularAtom, recommend reading it first before continuing further:

Application root

At first level, also known as application root, we break down our application into two main chunks:

1. User generated application code
2. Plus, everything else required for this application code to run.

Introduction

Many of us started the Angular journey by reading the official docs at www.angularjs.org and following their online PhoneCat app tutorial. I personally think this is a very good tutorial giving an immediate exposure to the various important concepts of Angular 1. The code is organized by type where all controllers are placed into one controllers.js file, all directives are placed in directives.js, services in services.js and so forth.

As we all know, the DDO (Directive Definition Object) returned by the Angular 1.x directive callback function has a require property, that sort of establishes dependency of one directive on others. This is a convenient way of building components that contain multiple directives where one directive may depend on the functionality of others. In practice, the require property simply tells Angular compiler where a particular directive controller should be search for.

As of git 1.9.4, it appears that there is no easy way to remove local tags that don’t exist on remote (a.k.a “stale tags”). According to --prune option in git fetch documentaiton :

In AngularJS we can have one or more directives communicate with each other. This gives us an ability to create web components (hello AngularJS 2.0) that are built from multiple directives. In order to for a directive A to access the API methods defined in a controller of a directive B, the latter needs to define the require: property with a value set to the name of directive A and specify how the search should be performed (in my example, I prefix directive name with ^^, so the search for controlelr is done on the parent DOM elements only). The compilation of directive B will fail if directive A controller cannot be found in the “search path”.

A few months ago, I finally had a chance to get my hands on the so-much-talked-about AngularJS framework and I really digged it. In fact, I like it so much that I am 100% sure this framework will stay ahead of others for a long time. Well, in our world this means for at least another year or two.

RailsAdmin is a very nice simple gem that allows you to manage data in models via a simple to use GUI. By default, it comes without any authentication enabled, so anyone can access the /admin URL. It does allow you to integrate with popular authentication frameworks, though, like devise and CanCan, however, I find it to be an overkill in small simple projects. In case of the latter, I simply opt in for basic authentication over HTTPS.

Over time, your rails models go from being a super model to being fat and eventually end up obese waiting any time for a heart attack to choke your app. When refactoring such models, I really like and follow the approach described by Code Climate in [7 Patterns to Refactor Fat ActiveRecord Models] (http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/).

When we generate a new Rails project, it spits out at us a nice well thought-out folder structure with a particular place for each code component should go to. App code goes into /app folder, configurations into /config, log files int /log and so forth. We love it and it works great until you come across a situation when you’ve got other files that you also need to associate with the project, but your generated rails app doesn’t seem to have a folder for.

You’ve finally realized the value of SOA (Service Oriented Architecturee) and decided to move all of your dynamic functionality into an independent service layer. Smart!

In my ongoing quest of porting apps from Windows to Mac OS X environment, I had to install Tomcat’s mod_jk connector to proxy requests from Apache to JBoss application server. This is not my favorite setup, of course, but rather a legacy environment for one of the clients. Everything was going smoothly until mod_jk compilation part. After doing some research and reading some blogs, here is these are the steps that finally worked for me:

Just moved from MySQL to PostgreSQL for the new rails apps. I think it is time I try something new after being so faithful to MySQL DB for the past X years. My first PostgreSQL install didn’t go as smooth as I expected, but wasn’t too bad. Here is a summary of the installation steps that worked for me (assuming you are using the awesome Homebrew package manager).

You’ve just upgraded to Ruby 2.1 and Ruby is hitting you back with this error?

Failure/Error: Unable to find matching line from backtrace
ArgumentError:
comparison of NilClass with 0 failed

So, you’ve finally found some free time to replace your default Rails console with Pry and now you want to see nice Hirb formatted output instead of the default IRB one? I hear you. To achieve that just add the following lines to your local ~/.pryrc file (e.g. /home/dmoore/.pryrc)

My livereload was working fine until I’ve added the better_errors gem. Then, each time when an error page was shown by better_errors, I had to manually hit Command+R to reload that page in order to see the changes I’ve made. Needless to say, this was quite inconvenient in the development.