Guiding The Geek In You
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.
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.
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:
Some file stubs (files that exist without any content) I like keeping handy to handle RWD needs, or to load AMD formatted scripts, respectively:
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
Asynchronous Resource Loaders
JS MVC Frameworks
JS Libraries
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 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.
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!
Special Note: Congratulations to the AngularJS team on their 1.2.0 release! New features, better security, more stability. Read more about it on the AngularJS blog.
Before we continue I would like to quickly mention how important a good sandbox is for the rapid building and breaking of educational code. In an upcoming post I plan to cover how I configure my sandbox. For now I recommend attaching the excellent CSS framework Bootstrap to your project index.html files to take advantage of pre-constructed classes that will make your rendered markup – tables in particular – easier to read.
Note these are View snippets – in order for these Bootstrap classes to work you must initialize the parent containers with their own Bootstrap classes. Again, more on this in a future post.
<div ng-app="myApp">
<div ng-controller="AvengersCtrl">
<table class="table table-striped table-bordered">
<tr ng-repeat="actor in avengers.cast">
<td>{{actor.name}}</td>
<td>{{actor.character}}</td>
</tr>
</table>
</div>
</div>
Did you notice?
ng-repeat="actor in avengers.cast"
The ng-repeat directive is an example of angular magic; a small directive that drives iterations through data sets without needing extensive pre-configuration. Sweet!
// Initialize App
var myApp = angular.module('myApp', []);
// Create the Service
myApp.factory('Avengers', function() {
var Avengers = {};
Avengers.cast = [
{
name: "Robert Downey Jr.",
character: "Tony Stark / Iron Man"
}
// rest of the cast added here, more entries = bigger table
];
return Avengers;
});
// Define the Controller
function AvengersCtrl($scope, Avengers) {
$scope.avengers = Avengers;
}
Adding a Search filter, for the entire table or for a single column, only requires a small change to the View.
<input type="text" class="form-control" ng-model="search.$">
Using the dollar sign “$” refers to all available fields and is perfect for a table-wide search:
ng-model="search.$"
Replace the dollar sign “$” with “name” to limit searching to the name field:
ng-model="search.name"
Finally, enable search by adding the following:
<tr ng-repeat="actor in avengers.cast | filter:search">
In addition to outputting markup, each ng-repeat loop iteration can also be piped through a filter, as I’ve done in this example. Pattern matching is just one example; many other filters are available for even more advanced output manipulation. Refer to the AngularJS docs for more information on this awesome feature!
Huge credit for my continuing AngularJS education goes directly to egghead.io. Their awesome video library and associated sample code, most of which is FREE, is an incredible addition to the community. Thanks in particular to John Lindquist for explaining these concepts so clearly.
Thanks for reading.