Nirodha – Simple JS and CSS management for websites

Nirodha (in the context of the four truths in Buddhism) is the absence of suffering. I’ve created a project by the same name which aims to reduce the suffering that is arranging javascript libraries and CSS files for developing websites. I’m tired of maintaining source maps and keeping track of whether I’ve deployed this minified file or that uncompressed js files. I wanted a system in which I could dynamically insert libraries and style sheets, debug them easily, and then deploy minified versions of the final product. This is what Nirodha does.
Nirodha is a command line utility with 3 main switches for creating and managing projects (a project is typically one website and views inside of the project are the html pages). Nirodha can create projects and views, serve up the assets for those views, and deploy those views into compiled sites with minified css and js. The project is written in node.js and hosted on Github at https://github.com/JamesonNetworks/Nirodha.

Using Nirodha
To use nirodha, check out the repository, run npm update to get the required libraries, and then add that directory to your path environment variable. Then, copy the settings_template.json file into settings.json and set the ‘path_to_nirodha’ variable to the nirodha path. Nirodha requires that node and npm be installed order to work. Now, let’s take a look at the structure of a project!

Structure
A nirodha project contains two directories, ‘custom’ and ‘deploy’. The Custom directory is where you can drop all of your custom libraries for a particular project. CSS and js files in this directory will be compiled and minified when referenced in the project. The ‘static’ folder will be served as if all its files were in the root of the webserver directory. The templates file is for offloading your html templates which you reference in the main html view (I typically use Mustache templates). In the root of the project are the view html files, describing json files which contain all of the library references for a project, and the info.json file which is for Nirodha’s internal use. When you are developing a web page and want to add a new js library to the page, simply open the $view.json file and add the reference to the appropriate place. The references are arranged in an array form and have a ‘title’ and ‘libs’ property. The title property is used as a place holder to inject the references in the web site (so you can have multiple library sets in given page which allows you to load the js/css either before the page loads completely or after it loads). For instance, if your title was {pre-load}, in your html page you can put the {pre-load} token in the head section of the site and this token will be replaced with the appropriate library references on serving and deploying the page. Take a look at the example project to get a feel for how this works.
Creating a project with nirodha is as simple as running

'nirodha -c $projectname'

The created project will have the default index.html view and associated files. In addition to custom js and css for individual projects, there is also a libs folder in the nirodha root. This folder can hold all of your shared libraries between different sites and references can then be made to the files here as well. So for standard libraries that you will want to use in just about every site, just drop them into the libs folder and then create a reference in your project, nirodha will do the rest.

Serving your site
After you have your references for a project set, you can serve the page using the

'nirodha -s'

command. This will require sudo unless you set the port higher, but as a default it is set at 80. This runs a webserver that will serve all of the assets as listed in the project. On each page load, the libraries are read and served up. This allows you to develop using the uncompressed js files.

Deploying your site
Once you are done developing the site, you can run

'nirodha -d $view'

This deploys the view for your application, reading in all of the referenced js and css, putting them into new files, and compiling and minifying them. The references will be added to the site in the form of ‘$view-$token.js’ or ‘$view-$token.css’. As a final product you will have a website with the smallest number of outside references possible.

I’m using this project to build and manage http://www.semipho.com. If you view the source on semipho, you will see I have two sections of libraries referenced, the {pre-load} and {post-load} sections which generate 5 files overall, a js and css for before loading, an html file with all of the templates injected, and a js and css after loading in init anything that needs to be setup after the DOM has loaded. This allows me the convenience of developing using all uncompressed libraries and deploying a project which only has 5 required connections to the server to get the smallest possible CSS and JS files!

I’ve released this project under the MIT license and hope that you find it useful to use in your projects!

A New Frontend Paradigm

Every now and then you have epiphany moments during software development. My epiphany moment has come while working with javascript and attempting to write a frontend for a pet project of mine, http://www.semipho.com.

I want to create a website which allows users to share their galleries with specific people that they choose to. Plenty of these sites exist already, but I have some unique idea that I think will set my site apart. In creating the ui for Semipho, I was able to quickly get a front end up in going in about 6 hours. I was happy with my work, and went about implementing new backend features. I was able to get gallery sharing working on the backend and set about creating the appropriate ui hooks. This is where I ran into a problem.

After several hours of battling through my terribly muddled ui code, I decided to scrap the whole thing and start rewriting it. Development on Semipho stalled during this time while I worked to come up with an appropriate design pattern to handle my front end. The pattern I’ve decided on is a UI-Bilayer.

The UI-Bilayer describes a way of interacting with a RESTful back end in order to promote code sharing between UI ‘views’. I’m creating a view as a way of looking at an aspect of an application. For Semipho, the index view serves as a way for viewing photos in a person’s gallery of images. All of the html content is segregated into two files, an index.html file and an index_templates.html file. Then, two javascript files control the interaction with the front end. The ‘view’ javascript file manipulates all of the markup and the DOM and the ‘core’ javascript file handles interacting with the service. Multiple view files can call into the core file in order to interact with the service, and the core module triggers events on a defined element in the view. Using this design, a single core file can be responsible for all interactions with a service, and the view file can respond accordingly. Decoupling all markup and building an event driven user interface allows the developer to build a UI which is easily extensible by adding new view functions and new events to interact.

I’m using Bootstrap, jQuery, jQuery-ui, and Mustache to quickly build robust front ends.

I’m going to work on a proof of concept and create a demo on github which will demonstrate the design pattern.

Introducing Incrudible

Incrudible is a Node.JS library I’ve worked on to handle some boilerplate database functions. I’ve been busy at work at a new job and gearing back up for school. I’m looking forward to the Sparc Hackathon this year and wanted to get some code to be consumed out there. I hope incrudible can help someone else in their experiments with Node.JS

https://github.com/JamesonNetworks/incrudible

Install it with:

Mac OSX, Rails Difficulties, and Homebrew

Alright. I’m done with MacPorts. It isn’t that I didn’t like it or it didn’t work. It did a great job. The problem I have with it is the difficulty of getting ImageMagick to work with a project I’ve started to play with in ruby on rails. HomeBrew, while not making ImageMagick any easier to deal with, does have some very nice features. The best I’ve found so far is the version control system built in Git (Ports may very well have had this, and I never stumbled across it). With Mac HomeBrew, you can look at all the versions stored in a Git repository using the command “brew versions “. Using this command, I was able to check out the version of ImageMagick I was hoping to try with the following commands:

…and bam! The version of ImageMagick which I wanted is now installed. Now the next trick is getting the gem for Ruby on Rails to compile. I’m using the rmagick gem in order to manipulate some uploaded images via CarrierWave. This has worked fine after following a video from Ryan Bates on RailsCasts.com, however the latest version of rmagick is having a tremendous amount of difficulty compiling now. After just about beating my head against the wall, I finally found this gem of a command that got it to install:

Why it needed this command, I’m not sure. But it’s working and I can go back to my other problem that isn’t working now.