Happy New Year! It has been a few weeks since my last post. My sabbatical was refreshing and productive. I finished my first major AngularJS project, which I am excited to start writing about, and of course took some much-needed down time. I hope your end of year festivities were equally pleasant.

This year I have a diverse topic list in store for CompassInHand that I hope will be as interesting to you as it is educational to me. Technology is amazing. There is no end to what can be learned. My hope is that I can give back some of what others are teaching me.

AngularJS Project One, Released

As mentioned, I released my first application written purely in the “Angular way”: Our XBOX 360 Library (OX360L)! If you are interested in checking out the code, please visit the project git repo.

Plans for CompassInHand

Loyal readers will note: prior to my holiday sabbatical my posting interval was about once per week. Unfortunately I rarely had enough time to do the research, understand the technology, and write a quality post about it within the single week. Therefore my new posting interval will be about twice per month. The additional week will be a tremendous help and should make for tighter posts with more code examples.

While no release date exists yet, this year you can expect CompassInHand to undergo a big face lift. With the help of my good friend (and new father!) Trian Koutoufaris a new WordPress theme is slowly taking shape – including an actual site logo! Stay tuned.

Finally, I plan to begin supporting RSS feeds. This is not a big technical challenge, just an administrative oversight I never considered before. Whether this feature is useful will be up to you guys – please, comment and let me know!

What Is On The Agenda?

Lots of things!

Over the next several posts I will be discussing some of the many (many, many) lessons I learned while building OX360L. Some of these lesson topics may include:

• The Magic of Promises
• Implementation of JSONP based Promises
• JSONP vs CORS, a technical compare / contrast
• Using Directives for DOM manipulation
• Best practices regarding $scope
• When to use $apply / $watch / $broadcast
• Integrating jQuery plugins into an Angular application
• Populating the select element (ng-option v ng-repeat)
• What is ng-cloak?

Looking past Angular / OXB360L, other post topics coming in the next several months will include:

• Grunt “The JavaScript Task Runner” – sweet sweet process automation
• Bower – Dependency / package installer, like npm for those of you who use node.js
• Yeoman – Yo + Bower + Grunt equals this interesting workflow process
• RequireJS – Great for dynamic JS library loading
• Node.js – You can expect several posts on this topic, starting with building RESTful Web APIs
• Bootstrap – Once a bloated CSS “framework”, now practically indispensable (for me anyway!)
• GitHub – I use git nearly every day, but I admit I understand it poorly – let’s change that

Finally, I have another project getting ready to spin up. Look for hints and mentions as meaningful progress is made. Hopefully it can be useful for all of you who go to lunch with coworkers.

Thanks for reading!

Sometimes the hardest part about a project is sitting down to organize your environment before you begin. Sure, you probably have several, maybe hundreds, of pieces of functional code stashed in your git repo or squirreled away in different folders on your hard drive, but starting a brand new project? Ugh! Enter the project sandbox.

Why a Project Sandbox?

Project sandboxes are templates designed for easy duplication that allow you to quickly create an ideal project environment. Pre-configured folder structures and file names optimized to your liking make launching a new project as easy as duplicating a template and making a tweak to the new project’s server config file.

Similar to regular sandboxes – also known as development servers – project sandboxes isolate projects to a well-defined structure, preventing code pollution. The key difference is Sandboxes are usually designed for developing within an existing code base protected by a code repository. Project sandboxes, however, exist only to help start new and potentially disposable development in a reliable way.

Naming schemes

Regarding naming schemes: the word of the day is CONSISTENCY. Name your project sandbox files anything you like and commit to your scheme. When you find a better naming method (and you will), retrofit your project sandbox right away – don’t put it off! Using consistent file names will build strong mental associations that help you decide where to put certain code.

My project sandbox files:

• main.js
• main.css
• index.html

Some file stubs (files that exist without any content) I like keeping handy to handle RWD needs, or to load AMD formatted scripts, respectively:

• responsive.css
• requireLoader.js

Being Flexible

Flexibility in terms of a project sandbox means keeping a variety of battle tested and carefully vetted resources at your finger tips, not all of which you may need for every project. Some resources should be configured to load by default, while others (like frameworks) are kept out of the loading stack.

Some of my core resources:

General Tools

• Modernizr (good for detecting CSS3 / HTML5 compatibility in older browsers, affords better Progressive Enhancement – load by default)
• HTML5 Boilerplate: Homepage (designed for easy tweaking – load by default)
• HTML5 Boilerplate: github
• Bootstrap (load by default)

Asynchronous Resource Loaders

• RequireJS
• yepnopejs (bundled with Modernizr)

JS MVC Frameworks

• AngularJS
• Backbone
• Ember.js

JS Libraries

• Underscore.js
• jQuery (keep a couple of versions handy – load one by default)
• Zepto.js (lighter weight than jQuery, better for mobile devices)
• [Your Favorite jQuery Plug-ins Here]

CDN vs Locally Stored Resources

Should you use a CDN or keep your toolkit stored locally? I prefer using local files. Staying local removes a layer of potential complexity (not relying on a file that probably stays the same), improves performance, and keeps resource files readily available for dissection. That said, CDNs are extremely valuable in many other situations.

However, using local resources means you must manually keep your project sandbox current. Get into the habit of watching for updates, reading release notes, and making informed decisions about updating your resources. Broken and dull tools are even worse than no tool at all!

Folder Organization

Folder organization depends largely on your web server and middle tier language of choice. Discussing the best ways to organize folders for different servers and languages could be a cool topic for another day.

Since I use Node.js my project sandbox folder structure is pretty simple, as demonstrated below.

• WEBROOT
  • TEMPLATE (this is your Project Sandbox – copy and paste at will!)
    • startServer.js (the Project Sandbox config file)
    • PUBLIC
      • index.html
      • JS
        • main.js
        • requireLoader.js
      • CSS
        • main.css
        • responsive.css
      • FONTS
      • IMG
  • RESOURCES (libraries, frameworks, often used assets – only one copy necessary)
    • JS
      • LIBRARIES
        • jQuery (development and minified versions)
        • JQUERY PLUG-INS
          • [your favorite plug-ins here]
        • Zepto.js
        • Underscore.js
      • LOADERS
        • RequireJS
        • Modernizr (includes yepnope.js)
      • FRAMEWORKS
        • AngularJS
        • Backbone
        • Ember.js
    • CSS
      • FRAMEWORKS
        • Bootstrap
    • FONTS
      • [non-web fonts used often go here]
    • IMG
      • [logos, backgrounds, etc – include only if used frequently]

Of course, this is only a start! Your project sandbox can be tailored in any way you see fit and will change over time. The important lessons are: make one, keep it consistent, keep it current.

Good luck, and please comment with any suggestions. And as always, thank you for reading!