At the time of the project inception I hadn’t had the mobile training that I received up to this point. So, being a good web developer and JavaScript aficionado I chose a JS/HTML approach.

The Framework

Rather than re-invent the wheel I choose to go with a nice little app called Kiosk Pro (http://www.kioskproapp.com/). This app handles all the heavy lifting as far as locking users into the application and is able to run a nice little local  web server (no WiFi needed). We went ahead and spent the $5 and went with Pro (as we didn’t need all the remote updating capability with Plus). An additional feature is you can drop the files right into the app with the free version of DiskAid (Mac).

The JavaScript Libraries

I used the following libraries to give it some zing:

jQuery – used this for fast development, but if performance becomes an issue I can probably switch this out for Vanilla JS

HammerJS – (don’t hurt ‘em) this library is a nice library for multi-touch and gestures (think swiping and tapping) http://eightmedia.github.io/hammer.js/

iOS Overlay – neat little library to display iOS style alerts. http://taitems.github.io/iOS-Overlay/

Move.js – for CSS3 animations. This works well to animate the HammerJS gestures. Swipe left and make the screen move left. If done right it can emulate native iPad transitions. http://visionmedia.github.io/move.js/

AudioFX – JS library for sound. https://github.com/jakesgordon/javascript-audio-fx/

Final Result

The final result is a simple kids game running totally on JavaScript and HTML without having to learn Objective-C. Admittedly, probably not as performant(sp) as native, but the user experience is perfectly fine.

I look forward to seeing how the kids interact with the game.

JS iPad Game

It can be a frustrating, time-consuming, seemingly non-productive experience which can be compounded even more the bigger the knowledge gap (or “management gap” as I am calling it).

In the web world (and even the I.T. world) we casually throw out tech terms. REST, Ajax, MVC, etc. And that makes sense to each other, but how do you even approach this with management or peers who have no concept of the fundamentals, but who are the decision makers?

I know of many people in the field that suggest just forgetting it and look for another job. And, I get that. Maybe you don’t have the desire to address the problem and it definitely is the easier way through.

But, what can you do if you DO want to attempt to make it better?

Here are some strategies I’ve found. If you have some to add please share in the comments as well.

Patience
In I.T. we deal with this one all the time. On twitter recently someone tweeted about developers: “You might know a lot, but you don’t know everything”. My addition to this is if  our minds are so great why can’t we keep our own emotions in check enough to just have some patience? If we can’t do that then maybe we aren’t as great as we think we are.

Admittedly I have been guilty of this many times. I have lost my cool and felt that superiority before, but I’m aware and trying to work on it. It takes time.

Don’t Talk Down
This is a hard one too. Talk to them with compassion and give them some dignity. It will go a long way in fostering your working relationship.

Guide Them
It might be all you can do not to pull your hair out and want to run to your office and tune everyone out. Problem is you are still all in it together and the problem will just get worse rather than better.

Instead offer to have them sit down with you for a step-by-step. Offer some training. Point is if you not at least attempting to inform then you’re really not doing anything to help the problem either.

Share Their Frustration
Technology can be difficult and it’s changing constantly. Relate your experiences. Remember what it was like when somebody helped you when you were new. It might give you a little more compassion and will definitely make dealing with them better.

There is no silver bullet and I do believe there are some gaps that are too great, especially if they are unwilling or there are roadblocks such as time or just plain ability.

All I can say is give it a shot and maybe things will get better.

Sorry for the tardiness of this but here is a copy of the slide deck as well as the links to the source code on Github.

Slides: Object Relational Mapping from A to Z

NHibernate Demo Source

Entity Framework Demo Source

Massive Micro-ORM Demo Source

One big reason I love this tool is no Java is required. This is already a huge plus for me since I don’t like to run Java on my actual development machine for various reasons I won’t get into (maybe another post).

In any case the only dependency you have is that you have to have NodeJS installed. Not a huge deal since you already have it installed right? If you don’t no worries, just head over to nodejs.org and download the latest release.

If you’re on a Windows machine I also recommend that you install the latest version of Git for Windows. Not only do you “get Git” (get it?) which is pure awesome, but you get some of the more useful Linux commands (VIM, grep, etc). The Windows command console will probably work as well, but I have not tested it for this example. The Node installer will also install a NodeJS shortcut that also offers a Node command-line console, this will work as well.

Once you have Node and your command line console you should be able to open up “git bash” (if you’re using git) and then type “node”. If you see the > prompt node is ready to rock (see below)

NPM and Express

Not going into too much detail here as NPM and in particular Express are larger topics that I encourage you to investigate if you’re interested in developing with Node.

The short of it is NodeJS has this thing called NPM (the Node Package Manager) baked into it. If you’re familiar with Nuget on .NET it’s very similar. What NPM does is allow you to install additional packages to Node that other developers have made. For the sake of getting this going I am going to install a default Express project via NPM to work with for this example. (I’m really just scaffolding something for us to look at).

To do this I will first Ctrl+C twice to get back to the $ prompt (or you can close the Git bash window and re-open). Then I’ll install Express globally by typing npm install express -g. Don’t worry, it won’t dump files everywhere. On my machine it created a folder called node_modules in the c:\users\kelly\appdata\Roaming\npm directory.

Now, in your console navigate where you want this project to reside on your file system. Then you’ll type “express test“, with “test” being the directory it will house all your project files in (see below). You’ll also want to follow the on-screen instructions and “cd” into that directory and type npm install which will install all your dependencies for express and node into a folder called node_modules.

Installing Grunt

Installing Grunt is pretty much the same as express. Just type “npm install grunt” and hit enter. I am also going to go ahead and use the –g flag so I can run the grunt keyword via the command line anywhere as well, so type: npm install grunt –g as well.
The final step is to create your gruntfile. I just put mine in the root directory of the project (with package.json and app.js, etc). This gruntfile needs to be named “grunt.js”. So go ahead and create that file (empty for now).

Configuring Grunt

Now the first thing we want to figure out is what we want to build. I’m going to go ahead and create a source directory (test/public/javascripts/src) and then download and dump jQuery, and Underscore javascript files in there. I am also going to go ahead and add a build directory under the javascripts folder as well. This is where my production build output for javascript is going to go. You should now have something like this

So my plan with this structure is to perform some sort of optimization to the jquery.js and underscore.js files and move them into the build directory for the application to reference. The purpose is to reduce the amount of files the browser has to transfer from the server as well as perform any other optimizations like minification (which we will do after this).

The first optimization I’m going to try is to concatenate them together.

Concatenating with Grunt

So in your grunt.js file you’ll need the following:

module.exports = function(grunt) {

    // Project configuration.

    grunt.initConfig({

        concat:{
            dist: {
                src: [' public/javascripts/src/jquery.js', 'public/src/underscore.js'],
                dest: ' public/javascripts/build/mybuild.js'
            }
        } 
    });
// Default task.
grunt.registerTask('default', 'concat');
};

Starting from the top I have a standard NodeJS “module.exports” and function wrapping the configuration. The important bits are inside the initConfig. My first task is “concat”. This keyword is known to Grunt. There are also lint, min, watch, etc to name a few others that are built in (check the grunt site for more details). — UPDATE– Grunt 0.4.0 no longer ships with built-in tasks. Plugins now exists in under the relevant grunt-contrib name. For more detail go here: http://gruntjs.com/plugins

The concat task first expects a name for your task. I called my dist. Then it takes src and dest arguments. The source in this case being an array of files I want to combine. Note that I don’t have to explicitly define the file names. I could’ve just said: ‘public/javascripts/src/*.js’ and Grunt would pick up all the js files in that directory. There are other regexp matches I could do as well if I were inclined. But I will keep this simple.

The next item I have is the destination or dest. This is the path and the file this job will create.

The final thing I need to do is register the task. registerTask takes two arguments. The first is the name of the task (in this case I’m calling it default) and the second is a space delimited list of tasks for that default task (it’s a lot of “tasks” I know).
For this example we’re just using the baked in concat task and I already added that above.

Now all that’s left to do is run the build. Type “grunt” in the command window. You should get something like this (if you don’t check the error and retry):

Magic! It created a new file in the build directory called mybuild.js with underscore and jquery mushed together.

Minifying with Grunt

The last thing I will show you is how to minify. Doing this is as simple as adding the built-in “min” task to the grunt.js file like this:

module.exports = function(grunt) {

    // Project configuration.
    grunt.initConfig({

        concat: {
            dist: {
                src: ['public/javascripts/src/jquery.js', 'public/src/underscore.js'],
                dest: 'public/javascripts/build/mybuild.js'
            }
        },

        min: {
            dist: {
                src: 'public/javascripts/build/mybuild.js',
                dest: 'public/javascripts/build/mybuild.min.js'
            }
        }
    });

// Default task.
grunt.registerTask('default', 'concat min');

};

Pretty much the exact same configuration as concat. Notice I also added the “min” task to my registerTasks (tasks are run in order of appearance).

Now run this again with “grunt”, it will take a bit longer this time as it’s using the Uglify minifier to minify your concatenated file. You should now have these files with mybuild.min.js being the concatenated and minified version.

Final Thoughts

There is much more you can do with Grunt not only with tasks out of the box, but with packages people have added via NPM. This is a very cool tool that takes the hassle out of having hand craft high performance javascript.
Just grunt!

However, I felt like another article needed to be written to offset the negativity. So here it is….

First. Let’s get a couple things straight here. I’m not a fanboy. I do drink the Microsoft Kool-Aid© now and then, but I also have partaken in the Linux “tea” and even the Unix…umm…let’s call it an “aged vinegary wine” (kidding). My interests are varied but I always try and get to the meat of where my software requirements, budget, and future maintenance aspects converge. This, in my view, is what any I.T. person worth his/her salt does.

Personally I don’t see a problem being a “fan” of SQL Server/Oracle in the same breath as MongoDB/Cassandra.

So what is the fuss? Why does this have to be a religious debate? There are certain facts in play. Yes, a NoSQL database in all likelihood is going to outperform a RDBMS database, probably by a factor of something. But can you do OLAP cubes with NoSQL? Does it safeguard its transactions as well? Probably not without hampering the performance (which is the whole point right?)

Here are some back-of-napkin reasons I love/hate both:

Why I love RDBMS:

• Rock solid (it’s ACID man)
• Proven and established
• Incredible toolsets (reporting, analysis, BI, etc etc)
• Ability to pull bits of data together to make something meaningful (JOINS, OLAP)
• Data types (protecting users and programmers from themselves)
• Set based which can make working with large datasets easier.

This I Don’t Like About RDBMS:

• Expensive (if you have to scale at all)
• Overkill for small databases
• Bulky
• User manual can be prohibitive (mountains of information to learn).
• Fear of not having a firewall in front of it (exploits)

Why I love NoSQL:

• JSON (simple, easy, and JavaScript/web ready)
• Cheap (a couple Linux servers and you’re good to go)
• Fast (really fast)
• Super scale-able
• Don’t have to sully my big RDBMS with stupid tiny databases (think online form capture)
• Not easily hacked (it can be done though).

Things I Don’t Like About NoSQL:

• You typically have to implement everything yourself (toolsets are limited, so far)
• Can dig yourself in a hole really quick if you architect your database incorrectly (sharding)
• Have to cobble the data to get meaningful results (reporting)
• Can be hard to pick which flavor to use for newbies.
• Syntax can be hard to visualize

So after all that can you start to see your requirements fitting somewhere?

I encourage you to investigate the pros/cons and make a smart choice, not hop on a technology because its popular or “we’ve always done it that way”.

Leave a comment if you totally disagree (or agree), I’d love to hear it.