http://adambrault.com/post/52004360603/just-a-person

I’m so glad that’s out of the way because I really didn’t want to do it. It’s not that JSConf wasn’t crazy good (it was), and it wasn’t that Chris and Laura didn’t go completely over the top in a good way for everyone involved (they did), it’s just that I don’t want to be the guy writing those posts because there’s so much more good to talk about – especially when I’m pretty certain if you asked ANYONE at JSConf if they’d recommend going next time you’d get a yes. Seriously, anyone…I really can’t think of a thing wrong with the conference aside from the horrible cellular coverage in Northern Florida on T-Mobile while I’m selling a house and looking for a job.

So with that out of the way, dripping love for JSConf aside…

There was an undertone to this conference and the community there. Maybe I’m reading into it because I want it to exist – but I don’t think that’s it. I think it was really there: in the sessions, in the people, all around.

Javascript has a community both young and old because of the nature of the newfound revival of a language that’s been used for 18 years. Javascript is also a language that nobody can tell you the “right” way to do things. There is no “one” MVC framework  - in fact, there are oodles.

Given how often we adopt, drop, and rework our flow in Javascript, when large groups of us meet to talk about Javascript it’s chaos. And I love the chaos – it’s like a mix of hardcore language basics and boundless creativity and rocketscience from all walks of life.

Let me explain with the rise and peak of Adobe/Macromedia Flex that I lived through:

I used to use Flash quite a bit – it was my favorite platform several years back (though I didn’t have that much experience in others at the time). I was drawn into it by the creativity being sparked in the community. It was THE creative tool to use, hands down. Something happened, though – we adopted a framework. Flex is/was pretty damn good actually. It shares a lot with other similar things like Silverlight/XAML and Android/XML. Nothing wrong with Flex.

Here’s the problem, though – I remember being at a 360Flex (great conference BTW) several years ago and EVERYONE was doing business applications and throwing Flex at it. There really wasn’t much talk about other tools/technology/creativity – just how to do stuff in Flex. I know, I know – Flex conference…but it really highlighted the shift in my favorite creative platform to the business side of things. Everyone was talking about Flex, not so much about Flash – just Flex. Adobe pushed that stuff hard to Java devs, and with the huge marketing focus on “Flex: The One Framework to Rule Them All (better than crappy Java) ™”, Flash was sort of forgotten about by lots of money seeking entrepreneurs and also folks who just didn’t want to get left out of the new technology standards.

At the time, I thought that the entire community settling on a single framework was a good thing – but for me, it really sucked the creative juices and talent from an awesome animation/interactive platform.

Compare this to what I’m witnessing in the Javascript community. “OMG I love Dojo…wait no! Backbone is for me! But look over there, it’s Google Clo….oh wait its Angular now!” We’re talking about MVC frameworks, and we’re talking about boring old business applications – but things are moving too swiftly to settle in. As a result, we can have rigorous and intelligent conversations about Require.js, but we’re not going to get it crammed down our throats at JSConf.

The lack of a solid direction here is a huge opportunity that I’m seeing folks at JSConf take in spades. Instead of obsessing over one thing -we’re obsessing over a huge number of things in completely separate directions. This is what makes a community absolutely fun and thriving.

We had Janessa Det obsess over beat detection and sound. We had Steven Wittens obsess over WebGL, we obsessed over Nodebots, Nodecopters, and 3D printing. Would we have seen this if 2 years ago someone had declared Backbone.js “The One Framework to Rule Them All (ps: Flash sux)™”? I’m obviously not a JSConf organizer, and having met Chris Williams once for 4 seconds, I certainly can’t speak for him. However, perhaps I’d think as an organizer, I should load my conference up with Backbone tracks and Backbone training.

As a result of all of this, I’m seeing loads of creativity and creative uses of Javascript – much of this knowledge coming from communities and research that has nothing to do with Javascript or the web. This makes me very happy.

Perfectly capping it all off, we were treated to Seb Lee-Delisle. I truly hate being a fan of anyone, but its really hard not to be a fan of Seb’s. In addition to showcasing some jaw-dropping interactive installations, he treated us to a short Creative.js training session with generative art in the HTML canvas. His session was the perfect mix of humor, self-deprecation, humbleness, and inspiration. He had one piece of great advice that I’ve only been smart enough to adopt recently – “Think small and FINISH YOUR PROJECT – Nobody will see it or know about it if it’s 90% done”.

Seb’s was the perfect end session to spark a thought in my head. The thought is that this community has some very creative and curious folks. And for me, knowing that there are lots of other creative and curious folks creates quite the inspiration to continue what I’m doing….and of course finish more of what I start!

For me, a UI developer, the North Carolina Triangle Area, while a hotbed of awesome tech and startups, is still too data-centric. I don’t mind data — data is good, but I want great interaction and visualization to back it up. To be fair, I did tell someone my line of reasoning and they offered to hook me up with several places that offered that if I’d stay in town.

But our minds (my wife’s and mine) are made up! I think I’m making the right decision. Looking on Meetup.com, I see 20 times the interesting meetups in the Bay Area than in the Triangle. Browsing Craigslist, I see 2 RTP area jobs per day in the internet engineering section, whereas in the Bay, I see 20 per day.

These are the things I justify the decision with, as right or as wrong as they may be.

So as a result, we are selling our house, moving (probably) to the Bay Area, and I’m finding a new job. As anyone in this nerve-racking situation would do, I jumped in immediately to search for jobs from afar — and that’s how I’ve come to learn the ways of Silicon Valley style job hunting. I think I finally have a decent feel for it, though I’ve done a lot of stumbling.

I’m of the opinion that my resume is fairly strong, so getting callbacks hasn’t been a huge issue — but they do take a while. Most have taken around 2 weeks for a response from the time of submitting online. Submitting online is a huge hassle but one you just put up with. You’re subscribing to any number of recruitment sites to submit your resume and cover letter. Brassring.com comes to mind. Or if the company is big enough, they have their own internal submission tools. Either way you’re entering in your information over and over and over again. Even when linking your profile with LinkedIn, you generally have to enter it somewhere else for each job.

Annoying, yes. End of the world, no.

The Recruiter

Next you talk with a recruiter. I’ve actually enjoyed talking with the recruiters — you get to brag a little, and it’s their job to stroke your ego and reel you in. The bigger companies have whole recruiting departments. In one case, I was passed through 4 different people before I landed on the one that could help me out.

I think the only way you’ll screw things up at this stage of the game is to start swearing profusely or making death threats. Of course, I’ve passed with flying colors — making 0 death threats. I haven’t even WANTED to drop the f-bomb; they have simply been pleasant people to talk with. When you pass this phase, it becomes their job to schedule a tech interview.

Prior to my first ever failed Silicon Valley style tech interview, which was with Google, I didn’t know what I was getting into. The recruiter basically said, “You know the drill.” I thought to myself, “Sure, I know the drill. We’ll get technical and maybe throw in some questions to prove my domain knowledge.” Nope, I was unprepared for this next world of hurt.

The Initial Tech Screen

So, I had an appointment at a specific time. I was also passed a Google Doc link so the interviewer and I could share a screen and collaborate via code. That was new to me, but I rolled with it, unsure of what would happen.

Since I WAS unsure, I reached out to one of my wife’s friends who worked at Google to learn what to expect. He told me to read the book Programming Interviews Exposed.

I picked it up on my Kindle — but I was already at t-minus 2 days until my tech screen, so I skimmed. While I skimmed, I recognized that it was a pretty decent book, but I didn’t think it was AT ALL applicable to my situation. After all, I was a UI programmer going for a Javascript role for god’s sake. I thought that as long as I could express some domain knowledge and maybe explain what my jQuery was doing under the hood, I’d be set.

The book covered sorting, trees, binary trees, graphs, implementing linked lists, Big-O analysis, and more. I must say that I brushed it all off before my first interview. Those are concepts I really haven’t discussed or seen since my college courses (13 years ago), and especially given the discussion on pointers in the linked lists and graphs, I really thought I’d be more preparing for a C++ interview with this book….not a Javascript/HTML one!

I was wrong, so wrong. Try giving a friend or loved one a call RIGHT NOW and explain how to do a breadth-first search on the phone without first refreshing your memory. It didn’t work for me. BIG FAIL for me in fact. In fact, the breadth-first search problem is a great example of what to expect on a couple different levels.

For me, being asked that proved that not all code you’ll be writing in the interview has a sexy, elegant solution when you’re on the phone with your interviewer. For those that don’t know breadth-first search, you’re basically taking a tree like an XML file or any other nested structure. Instead of searching the root, then the child, then the child of the child, you’re searching the root, then all the 2nd level, then all the 3rd level. The solution here is to push all the child nodes into a stack and shift off the first one with the important thing being that you need a list/array to store things in memory.

I didn’t even want to go there for that question and other questions in the interview. I thought there had to be some easy, recursive solution that spanned like 3 lines of code. Why would they ask something overly complicated and unelegant over the phone?

Well, they do. They want to see error checking. They want to see the solution as messy as it may be.

In the end, that book proved to be the perfect preparation guide, which I was able to absorb for my subsequent interviews.

One other thing this book teaches is that it’s OK to stumble if you don’t know the solution to a problem that the interviewer asks. It’s necessary to just keep talking to them. Don’t choke, just keep talking. Tell them why you are going down a path to solve the problem and what you are thinking on the fly. If you don’t solve it, they may give you some hints. Even if you think you fail at solving the problems, they may be impressed with your problem-solving process and still continue on to the next round of interviews.

My first interview with Google? I did NONE of that. And you know what else? I never got called back. After that bomb of an interview, I was able to have some really good ones based on what I learned.

The Domain Knowledge Interview

After all that, I’ve had some good interviews — but my best ones have been when the interviewer asked for domain knowledge. You know, that interview where it’s not like an interview, but you just nerd out and talk about what you do at your job and what you like or dislike. Those are the ones that have made me feel like a real person, not a piece of meat, and it’s shown.

Even my Google interview might not have been my worst. That was probably the one when the interviewer was a guy less than 1 year out of college. I don’t say his age to be dismissive. I have no doubt he is very smart, but he didn’t have much experience giving a tech interview — which meant he picked random problems out of a data structures and algorithms book. But I kept talking and giving him my thought process, despite getting every question potentially wrong. To my surprise, I got a callback for a second interview after that debacle, which was more of a tech conversation that went quite well.

Next Up: The On-Site Interview

Right now, I have a few on-site interviews lined up. The kind where you get flown out like royalty and put up in a hotel room. My initial reaction to getting asked out for them was that they must really be formalities, and if a company drops that kind of money on me, it’s mostly a sure bet I’ll need to screw up pretty bad to get rejected. But given how wrong I was before, I’m not taking any chances! Prepare for the worst is what I’ll do!

HTML/Javascript is Weird to Interview for

As a final thought, I want to talk about how weird it is going for a front-end job these days that focuses on HTML/CSS/Javascript. Even the domain knowledge interview is a disaster.  There is little chance you’ll talk about the same frameworks in most of the interviews given there are so many popular ones (especially MVC style). To top that off, you really do feel like an idiot if they ask native Javascript questions. No, I am not a jQuery scripter that copies and pastes. However, because I use jQuery a lot, I sometimes forget the exact native Javascript syntax . See the problem? To prove you’re a bad-ass Javascripter, you must recite things you never use in your day-to-day life.

I also got a rather nice interviewer once who unfortunately didn’t really know a thing about Javascript/UI. I ended up switching gears to talk about Java and back-end stuff. Front-enders are in demand, and as a result, you might be interviewed by someone sorely needing a front-ender…to the point where they have none to interview you properly!

You can grab my NuiMotion project version 0.1 on NPM and Github. You can read why I did it, and about how I’m on a crusade for letting your interfaces move your body on the project page.

That said, I learned a lot of stuff. I think the project serves as a shining example of how one guy accomplished some rather difficult and not so ordinary things you’d need to do with Node.js. I won’t claim it’s necessarily the right way – just one way. I was a little scared of C++ before all of this, but I jumped in because I had a need that I wanted to fill, and C++ was the only way to get it done.

The C++/Javascript bridge is pretty cool to see how it works. There are all sorts of problems you run into with type conversion – your C++ variables to those loose Javascript variables.

The hugest hurdle was breaking down the architecture to something that wouldn’t block the entire Node.js main process. In all of the OpenNI examples, they would run a big old while loop that will grab frames of video/depth and pull out the features we need like gestures and skeleton data.

This is SO not cool for Node.js, so I needed to delve into how to achieve threading in the V8 engine with “lib_uv”. I still don’t understand everything about the final lib_uv code I used (why some things are declared as they are), but I successfully broke it out into a new thread that runs as fast as your machine will let it. We reach in and grab our joints using a custom defined interval to poll at, and we event out when gestures and other events are encountered.

Of course, all of this NEEDS to be threadsafe. If you access the wrong thing inside a thread, you crash your entire process.

You can checkout the main logic of all of this, completely with C++/JS communication and threading here:

https://github.com/bengfarrell/nuimotion/blob/master/src/Main.cpp

I didn’t do this alone, either. I asked a couple questions to the extremely awesome Node.js Google Groups. One was around the threads question, and the other was around C++ compiling. To demonstrate how much of a noob I was, my compiling question was that I didn’t realize you had to include ALL your *.cpp files in your sources target. I thought since the main.cpp references other things, they would be automatically included. NOPE! Live and learn.

Anyway – I’m of the opinion that this project probably represents some of the most difficult things you could ever need to know how to do in a Node.js addon (without getting into domain specific C++ code which could be infinitely complex for sure). So feel free to have a gander and learn!

So, for those that know what the Rift is…awesome.  But those that don’t – it seems like it may be the first legit, consumer-grade (read: affordable) VR headset.

The Oculus Rift is the very first thing I’ve ever backed on Kickstarter (my wife has since backed the Veronica Mars movie).  But the experience was harrowing.  I mean – you’re waiting for this thing for almost a year after dropping $300.  At the time, I thought $300 was a pittance to pay for something so potentially cool.

Then the delays started happening.  Oculus was supposed to have this thing out in my hands for December.  I just got it now in April.  It was supposed have Doom 3 support when I got it – it doesn’t, ID Software backed out I guess.  Bad news?  No, actually….just no.  Oculus, the company behind this, with these setbacks COULD have been so shady about all of this, but instead they’ve been an extreme class act every step of the way.

Something this cool was bound to have setbacks, and yah…Kickstarter…I’m probably lucky I got anything for my $300.  Oculus has been very communicative every step of the way since August.  They’ve done interviews, showed their tech off at game conventions, everything.  They kept me drooling and happy to wait with them through the problems.

No Doom 3 support?  Man that sucks.  But, the second this was announced, Oculus stepped up and offered a complete refund, a Steam Store credit, or an Oculus store credit for $25.  Way to go, guys – even after Team Fortress 2 support was announced in lieu of Doom.  Yah, there were setbacks, but they handled it like champs.

Imagine my….OK…non-surprise (since I had the shipping notification this week) when I got home and my Oculus was there waiting for me.  Given the trivial amount (yes I think $300 is trivial for a VR headset) you’d expect them to do a shoddy job packaging it.  Nope. I have a hard case with foam cutout inside that molds itself to all my pieces.  What the hell guys….this is more pro than real store-bought finished products.  I was even more impressed that it came with DVI and HDMI cords to connect my machine to the breakout box.  They could have made me go to the store to buy these, but nope – comes with.

Whatever though….what’s the experience like?

It’s incredibly fascinating.  The best demo so far that I’ve seen after playing around for an hour, is the “Tuscany” demo. This seems to be their showcase piece for now.  Basically, they’ve created a Unity demo with a quiet little cottage in Tuscany. You start out in the cottage in front of a roaring fire.  Putting on your goggles for the first time is a very wowing experience.  It’s so unusual, but your brain adapts pretty quickly – so quickly in fact that when I looked down and put out my hands, it was very disorienting to not see my body when I KNEW it was there.

You look around and you feel like you’re there.  The roaring fire is a nice touch.  It was a little awkward fumbling around to feel where my laptop keyboard and trackpad were, but I eventually found the keyboard controls and walked outside (no bounce to my step….that woulda been way cool).

After wandering outside, I immediately stepped towards the ocean and had a sensation that I didn’t want to get too close or I’d fall down the cliff.  After getting over this, I looked around – dandelion particles were drifting through the air…a VERY nice touch.

The extreme novelty wore off after a bit of wandering around, which was then around the point where I started to scrutinize things.  Walking up to things and looking close of course revealed the flat/3D polygonal look of the trees and other objects that from far away look awesome.  You can’t NOT expect this really – I mean, realtime 3D environments are what they are, but it was interesting to experience this!

Then if you shift your focus, you can make out the individual pixels on the screen – as if you were inches away from a TV.  You can easily choose to forget this and enjoy the experience, but it detracts…just a little bit.  Now that I think of it, one of the little demos that I downloaded from their forums by a fellow developer was mostly over a black sky, and generally dark, which removed the razor thin black border that goes along with these pixels.

The biggest detractor was the head movement.  The best I can describe it when you move your head fast is choppy.  It felt a little like the headset was polling your head’s movement at a lesser interval than needed to stay smooth – and the view in front of you chopped along.  My wife actually made the stellar point that using the mouse to move didn’t produce this – so my theory of refresh rate was shot down.  Also if you take off the headset and move it with your hands while you watch your 2D computer display, it’s not noticeable on there.  There must be some weird headset/display refresh rate combo effect going on.  Also, slower head movements didn’t do this for me.  Another demo seemed worse and another better – so I think this, my biggest issue so far, may just be a software improvement – and this is A-OK with me!

Anyway – I dreamt that this thing would be perfect.  It’s not, but it’s more amazing than the cynic in me expected.  There will be improvements as we go along – Oculus NEVER said these dev kits would be consumer grade yet. I’m looking forward to playing more and definitely checking out Team Fortress 2 this weekend!

http://www.benfarrell.com/2013/01/31/i-wrote-my-dad-a-letter-with-the-webspeech-api/

But that’s all in the past – I’m blown away with how it works now.  True – if you have a good deal of ambient noise in your room, it looks like Chrome has a hard time differentiating between you and the background noise.  Given a relatively quiet environment, or if you’re up close to your microphone, it works magnificently.

I liked it so much, I created a little painting demo with it and a Kinect like depth camera.  You can still use your mouse to paint in my demo though – so even if you don’t have a Kinect working over websockets or the like, it’s still functional!

I set up several keywords that the WebSpeech API listens for: red, green, yellow, purple, blue, orange, and black.  These voice commands are to switch colors.  I also added a “start over” command to clear the canvas.  Lastly…invoke “Bob Ross” for a little surprise!

Chrome listens to your speech, chops it up, and sends requests over to its servers.  You’ll get back “interim” speech and “final speech”.  Interim speech doesn’t make too much sense as you see it.  It’s putting together it’s best guess at phrasing as you go along, picking out the words it can without paying much intention to intended meaning.  The “final” speech comes delayed by a second or two.  Chrome things you’re finished speaking, and it waits a tick to make sure.  Then it puts together it’s thoughts and gives you something final.  It’s probably going to be grammatically correct and nicely accurate.

Some of the shorter commands you’ll need to enunciate.  It has a big problem when I say “green” sometimes, but honestly, when I’m making voice commands, there’s really no context in my grammar to pick up on.

I went ahead and wrapped up the WebSpeech API for Chrome 25 in a little Javascript library.  I allow you to add commands to listen for along with callback methods to call when those commands are spoken.  I also allow it to “keepAlive”, which means if Chrome thinks you’ve stopped talking for good, I go ahead and start the speech API right back up.   I also event out the surrounding words with a command if you care to make something like “search” a command and want the words that we spoken after it.

You can checkout the library I made here (its in a repo I made for motion/gesture control as a demo to add speech to the mix):

https://github.com/bengfarrell/node-sweatintotheweb-examples/blob/master/activities/common/js/speechrecognition.js

One annoying, but understandable thing is that to allow the Web Speech API to work, the user has to click to allow the microphone.  This needs to occur every time you start the API.  There could have been an error, or it could simply think you’re done talking – then when you go to start it up again, the user needs to click to allow.  Bad for natural interaction if you’d like to keep it running and listening at all times on your page.  GOOD if you don’t want web pages spying on you!

You can work around this by serving your page over HTTPS.  If you’re secure, then Chrome allows you to always remember the option if the user so chooses.

It’s a very cool feature that I hope the rest of the browsers adopt soon!  I wouldn’t mind dropping the HTTPS requirement though in favor of something else!

For my horrible Bob Ross impression AND demo, check out the video I made here!

So….low risk, let’s dive right into Angular!  I also had the assumption that if Angular was all I thought it was cracked up to be, it would save me lots of time, and allow me and others very nice visibility to how my project worked so they could make updates very simply, right in the HTML.

Boy was I right.  I felt like Angular sped things up and gave me what I wanted, with a nice easy, predictable structure.

What I didn’t expect was that I’d be mixing jQuery UI in.  What I REALLY didn’t expect was how SLICK Angular makes it to mix things like jQuery UI in.

The Problem: I want to drag something to a drop zone

Pretty simple right?  Of course, of course I can write this from scratch in Javascript.  And if I wrote it from scratch, I’d probably cut corners and…..not necessarily make it all fancy with tags and attributes for my Angular setup.  No, I’d probably loop through all the elements in my list that I’d like to drag, attach onmouseout, onmouseover, and onmousemove listeners.  And then keep a separate list of all my drop zones and check positions of things while they are being dragged.

PAIN IN THE BUTT.  I don’t mind doing cool things by hand, but things that are readily available elsewhere? Boring. So I turn to Google and type in “AngularJS drag and drop”.  I came across this gist:

https://gist.github.com/codef0rmer/3975207

Given what AngularJS is supposed to do, I didn’t expect to find any functionality in Angular to support drag and drop.  Indeed I didn’t, but what this gist shows is the ability to declare your own attributes in HTML and have Angular process them, adding your own logic to what those things do.  THAT IS SLICK!

Angular Directives

So let’s take “draggable” and “droppable” as our primary examples for an Angular directive.

In our HTML, create a div with your own custom attribute on it:

<html ng-app=”App”>

<div class=”something” draggable></div>

<div class=”somethingelse” droppable></div>

</html>

Obviously these two attributes mean nothing to HTML, so we want to process them with Angular.  Luckily we’ve declared our Angular App as “App”.  We can then process our directives:

var App = angular.module('App', []);
App.directive('draggable', function() {
    return {
        // A = attribute, E = Element, C = Class and M = HTML Comment
        restrict:'A',
        link: function(scope, element, attrs) {
        }
}

So, above, we’ve made a reference out of our “App” module (our HTML page/app).  Then we’ll add a directive – which is simply saying, anything labeled “draggable” – return an object that does something.

I haven’t tried anything except “restrict:’A'” yet, however this is pretty fancy.  We filter this behavior by attributes, elements, classes, or comments.  For our example, we’re restricting by our attribute.

Then the link process.  Here you define what you’d like to when Angular finds the attribute.  We’d like to hook up the jQuery UI drag behavior:

      element.draggable({
        revert:true
      });

Right! So all we do here, is take the element that the Angular directive gives us and call the jQuery UI method “draggable” on it.  I left the gist author’s revert:true in there, cause it’s pretty nice.  If the drag isn’t accepted, its animates back over to where it started.

Similar deal with droppable:

App.directive('droppable', function($compile) {
    return {
        restrict: 'A',
        link: function(scope,element,attrs){
            element.droppable({
                accept: ".itemHeader",
                hoverClass: "drop-hover",
                drop:function(event,ui) {}
    }
}

We process the directive, filter by attribute, and on link call the “droppable” jQuery UI method.

jQuery UI has some nice options here for droppable.  It can be set to only accept items of a certain class or ID (comma delimited lists inside the quotes are cool here).  You can specify a hoverClass as well.  In my case,  the “drop-hover” CSS adds a white border to the element.  When you drag your draggable over a dropzone, then the dropzone will light up with a white border.

And then the drop functionality.  What happens when you drop it?  I have my own logic, you’ll certainly have your own.  An important note is how to get the drag or drop elements using these parameters that you get:

dragged = angular.element(ui.draggable).parent();
dropped = angular.element(this);

This, of course is in the “droppable” method. If you were in the other “draggable” method, angular.element(this) would be the draggable.

Wait theres more! I had to do a little trickery in my application. See, it turned out that not everything could be dragged to everything else. If you picked up a draggable, you can only drop it’s related dropzones. Other draggables have other dropzones.

I needed a good way to NOT let the user drag something where they shouldn’t depending on what they picked up, but also make them SEE what they can or can’t drop on!

Start/Stop Drag Listeners

Luckily, JQuery UI gives us a few more draggable options:

App.directive('draggable', function() {
    return {
        // A = attribute, E = Element, C = Class and M = HTML Comment
        restrict:'A',
        link: function(scope, element, attrs) {
            element.draggable({
                revert:true,
                start: function(event, ui) {}
                stop: function(event, ui) {}

So, we can have something happen when the user starts to drag something AND when they stop.  So for me, when “start” is fired, I loop through my list of dropzones.  If it’s determined that the drag is not allowed on a given dropzone, I’ll add a “reject” class to the dropzone.  In my CSS, I fade the background and the text and everything so it looks dim.  And then in my element.droppable.drop function, I check to see if the “reject” class is present – and don’t do anything if so.

In my stop function here, I simple go through and remove all the reject classes from everything, since the user has stopped dragging.

Lots of options here for doing drag and drop!  And a pretty nice way of Angular opening the door to other tools as we add non-Angular functionality.

Last fall, I started playing around with the Kinect, and I was seriously in awe with how magic it seemed. I started reading up on NUI (natural user interaction) and went further down the rabbit hole.

Months later, I’m still deep in it.  I’m finishing up my Node.js natural motion add-on and demo content just in time for some upcoming speaking engagements.  I’m still not bored.  I’m still not bored, ready to move on – and my Leap Motion is shipping in May.  My Oculus VR headset is shipping in a matter of days.

Also after a few months, I’m still playing the augmented reality game “Ingress”.

These things all have something in common to me…and it’s pretty much the Natural User Interaction angle.  How do we interact with interactive experiences and apps in a natural way – whether with a GPS and physical location, or with your whole body as a controller.

Another important thread here…I’m out of shape.  I sit at the computer too much.  Rather than make the above endeavors work against me, I’m going to make them work for me and not do anything in my spare time that doesn’t encourage moving around a lot.

This means if I develop an interactive experience, it needs to involve moving around.  How much do you debug an app while creating it?  A LOT.  What if testing and debugging necessitated moving around wildly to do this?

So here I am wanting to learn about existing technology that gets you moving and creating my own experiments that get you moving. Not only for the fun of it, but to get myself in shape!  It is time for a non-technical hub for this, and I shall become a “Digital Fitness Trainer” in training.  That hub is Sweatin’ to the Web.  There I will do video reviews of apps, sites, and gadgets that get you moving around.  I’ll also be posting videos of my creative experiments there, like my work with Kinect-like devices.

It will be pretty non-technical there, but I’ll follow up on this blog with the actual technical side of things – how it works, maybe dig into the code if appropriate.

I’m excited!  I have a Fitbit review up now with a depth camera painting demo coming in the next week or so.  Hope you enjoy, but if not…I’ll keep blogging all the technical tidbits here as always

I got a reply right away.  Luckily @jwaltonmedia was just being friendly.  See, his flavor of the moment is BackboneJS.  We traded some kind words and left it at that – each sharing some awesomeness.

Got me thinking though, there’s too many articles out there about MY FRAMEWORK VS YOUR FRAMEWORK:  THE ULTIMATE THROWDOWN.  The winner rocks and we should push it on everyone whether they want it or not.  The loser suffers in shame for eternity.

Well, I was inspired to compare a few of these frameworks, but I don’t want to use negativity or competitive language.  Because, in all honestly we are in a moment where there are a metric crapton of Javascript frameworks that are ALL GOOD.

Thusly, I’ve named this article “fundown” instead of “throwdown”, because the only winner here is you when you try all this good software.  And instead of “versus”, we’re going to use “plus”, because while it’s not necessarily ideal to use 2 or more of these frameworks together, you should use all and more separately as you rock out your badass web app.

I’ve tried just around 3 frameworks/libraries heavily at one point or another – and I truly believe that each is the best tool for some job.  My learning process was pretty unscientific and involved me copying and pasting tutorials and code from the web – so my opinion here will be equally unscientific.

What’s good in all

It’s pretty easy to see that the 3 I’ve looked at are pretty mature at this point – Backbone.js JUST reached a 1.0 milestone and been around since October 2010.  Angular is ALSO at 1.0+ and dates back to January 2010.  Dojo is the grandaddy of them all, REACHING 1.0 in 2008.  So, I think it’s safe to say all mature, and all are well loved by their communities.

All 3 are geared towards helping you get going to mainly build web applications vs web pages.  Many times this will be single page apps, other times there will be lots of event driven data loading and interaction on the page….very AJAX-ey, or whatever it is the cool kids are calling it these days (especially since the cool kids are using JSON and not XML).

What’s bad in all

So, by virtue of just being Javascript, if you screw up something (and you will because you’re learning), it will silently fail on you.  All of these are relatively complex systems someone set up.  You have to initialize and use it.  Each come with their own dependencies, and somewhere along the line, you’ll want to use one of those dependencies, and it will fail on you.  It’s up to you to figure out how you screwed up the initialization of the framework/library.  More often than not, you’ll get something like “X doesn’t exist”, and you have to figure out what you did wrong in the setup such that X doesn’t exist.  Errors aren’t the most helpful here.

Dojo

Dojo was probably the worst of the pack in terms of unknown setups screwing you further down the line.  However, that’s a testament to how damn powerful this package is.  It probably packs the most power out of any JS toolkit I’ve used, and it comes at the price of complexity.

I would recommend not using Dojo for your one off web app.  Use it for your enterprise! Many libraries are moving towards modular loading, but I think it’s safe to say that Dojo had it first.  And as well it should, because it comes with a crazy amount of components and tools.  You definitely wouldn’t want to load them all up front.  I believe that most frameworks today will do modular loading, but they seem to make you realize that you are relying on Require.js as opposed to Dojo who advertises AMD, but doesn’t really tell you it’s Require.js – they seem to kind of brand it as a Dojo thing.

Anyway – Dojo….large amounts of skinnable modular components.  Back when I was trying it out, they were just getting around to a proper MVC implementation.

Backbone.js

Speaking of MVC…holy hell, MVC is like Backbone’s mantra.  You’re actually extending Backbone’s Model, View, and Collection base classes.  So everything, at least the beginner stuff, you see online is really going to push this way at you.  And that’s fine – but it’s also why I’ve found that it was hard to get past the concept of a todo app really.

I’m not going to be stupid here and tell you that a todo app is the only thing you can do in Backbone.  Backbone is plenty powerful and can do wonderful things – it’s just my opinion that the beginner’s material you see when researching seems to not really help you get beyond this simple “list my data” type of web app.

I didn’t really care for the lack of HTML or otherwise markup used in the framework.  It largely looks like you’re encouraged to work with code and append to the DOM that way.  Let’s be honest though, on a large app, after you’re settled in, doesn’t it end up that way anyway?  I mean, yah, it’s nice starting out in HTML – but it starts to get lengthy and messy, and you just wish you modularized your stuff and programmatically did it at the end.  One exception I’ve found here with Backbone is that people use a <script type=”text/template”> tag to contain an “item renderer” for their lists.  Basic idea is that, you load your data into Backbone, and you reference this tag, feeding it to Backbone to render each item in the list.

It’s a nice little hybrid of HTML and programmatically adding to your DOM.  Plus if you get bored with it, and want to go all JS, it’s easy to break it out.

Angular

Yet, as much as we say it’s all gonna be programmatic in the end – I just love markup.  HTML and CSS is the true visual layer in your web app, why pretend and muddy it with Javascript?  Yah….right…..any number of reasons, but none of those you really want to care about when you’re starting a project.

That’s why Angular rocks for me.  You put a magic ng-app attribute on your HTML or div tag, and you suddenly have an Angular application – one that you can attach a Javascript “controller” script to.   Your views are your HTML views with some extra Angular tags that are understood by the system.  I did forget to mention that this is one of the things I dig about Dojo as well!

So lets say that your ng-app=”MyApplication”.   Well, write up a “MyApplication” controller.  Other nested controllers and models that you define in HTML are class variables in your controller that you can access.  The scope is just magic here the way it intermixes your HTML and JS variables to one controller scope.  Using the double-curly braces will output a variable to be rendered on your HTML: {{myvar}}.

And yah, it does list rendering with a repeater.  An list item can be repeated over a Javascript array in your scope by saying:

<li ng-repeat=”item in mylist”>{{item.name}}</li>

So, doing the above will loop through your list and pump out the name property of each item in your list.  Pretty sweet!

And this strikes to the heart of why AngularJS is my flavor of the month.  I wasn’t told I needed MVC.  Angular tutorials just give me the tiny pieces I need, and it’s up to me to put them together.

Contrast that with Backbone – every tutorial I come across is how to hook up the Model, View,  and Collection to render your data.

Can you do other things?  Obviously, because Backbone rocks.  However, Angular presents “other things” so much better in the material I come across.  Plus, I’m just a sucker for doing my views with markup when I’m starting out a project.

Conclusion

In conclusion, all of this means nothing.  If I did anything for you, I gave you a sales pitch to try each of these things out.  You should try Ember too!  You should find frameworks I haven’t tried and try them as well.  Let’s just feel good about trying new things, and if you have a favorite, that’s cool – but don’t think of it is the knockout champion of everything.  Keep your noggin open to all things.

I’d still like to test a bunch before I call it a release, but I think I have something going here to work a Kinect or Kinect like device through Node with the help of an open source library called OpenNI and not-so-open-source middleware called NiTE.

Sending skeleton data, or joints, or body tracking points to Node was relatively straightfoward.  I just needed to take the data and push it through, making it available to Javascript.

Unfortunately, though, one of the main things we associate with the Kinect isn’t really included in the middleware I’m using, and you’re left to your own devices.  I’m talking about the gesture.  Whether you’re swiping your hand, waving, or any number of things we associate as “natural” interaction mechanisms to trigger something in our interactive experience to happen.

I actually didn’t know where to start with this.  Do people REALLY do brute force tracking of your appendage at every stage and consider every possible outcome of where your appendage could be at any given moment?  From what I’d seen, the answer is yes.  I posed my question to a private Kinect G+ Community I’m a part of.  My question was basically…”How do you even start going about programming a gesture?”.

Because this small knit group of people rock – I received C# source code almost immediately for a swipe gesture from a Turkish developer named Furkan Üzümcü (@furkanzmc).  I set out to convert it to C++ for my own purposes which I’ll share in a bit.  It really opened up my eyes to the attention to detail about what you are doing with your body to register a gesture.

Here’s the anatomy of a swipe right gesture (as performed with your left hand, swiping left to right):

• First, cancel any swipe right in progress if:
  • a) Left hand is above head – it doesn’t seem natural of a person to try to perform a swipe like this
  • b) Left hand is below left elbow – it seems more natural to perform a swipe when the upper arm is relaxed and the forearm is raised, with the hand in this position above the elbow
  • c) Left hand is above hip – this I think is more subjective, but ideally – you are purposely creating a gesture if you’ve raised your hand above your mid-section
• Next, if the left hand’s x position is to the left of the left shoulder, then we are on the left side of our body, and ready to start a swipe – so flag this, that we’ve started a gesture.  On the other hand – if the hand isn’t far enough to the left, measured by horizontal distance between the left hand and shoulder being less than the horizontal distance between the torso and the shoulder, then cancel the flag and indicate that we have NOT started the gesture.
• Next, if the gesture is started and the timestamp hasn’t been recorded then mark the start time of our gesture.
• Finally, if the horizontal position of the left hand is greater than the horizontal position of the torso AND the time it took is between the .1 seconds and 1 second, then we have a gesture!

So yeah, I’d call that brute force.  Not only are you defining an event flow based on MULTIPLE joints (your hand, elbow, shoulder, head, and torso), but you are approximating allowable “good distance” for things based on the distance between things like your shoulder and torso.

These are important things to realize.  This arm motion that sounds so easy, just became a whole body affair.  And global/world coordinates really aren’t that great to use here since people can be closer to or farther away from the camera and people also come in all shapes and sizes.  So, we think of all of our distances as relative to the distance from one body part to the other.

When I was programming this, I started sitting there, and really watching my body motion.  I’d take my arm and start swinging it around…just thinking about how it moved.  I felt like Otto the Bus driver from the Simpsons.

“they call them fingers but i never see them fing”…. “ohh there they go”

So, for a swipe left, you can imagine how that works.  Just reverse the motion of the left swipe.

Up and down was a little harder.  With the horizontal swipes, we can imagine a user as needing to vertically center the gesture just above their torso.  But what of vertical swipes?  I could easily swipe up at the left, right, or dead center of my body.  Any of these are valid in my opinion, and no starting horizontal position of the swipe invalidates the gesture.

So, I took a page out of the relative distance between joints game.  I said: “OK – the distance between your left and right hip is the maximum amount of horizontal variance you’re allowed to have in your vertical swipe”.  So if your hand starts below your hip, and your hand is below your elbow, and continues up to where your hand is above your elbow in the right amount of time and with less than the maximum horizontal variance, then you have a swipe up!

Same with swipe down, but reverse of course.

Interesting thing when you listen for both events, though – if you want to do either a swipe up or swipe down, you make a conscious effort to put your hand into position.  To get it into this position, it seems like a lot of the time, you are causing an accidental swipe up!  I haven’t resolved this issue yet, but it’s an interesting one.

Lots of things to consider here.  I also did one on my own –  a wave gesture.  As in a greeting – “hello”, “goodbye” – you know, a hand wave.  Here, I simply detected if the hand was above the hip, below the head, and above the elbow.  That’s my starting position.  Then if the hand’s horizontal position goes left then right in a cycle 6 times where each motion takes less than .2 seconds, we have a wave.

Overall, you’re considering a lot of different things when designing a gesture.  How “natural” it is for your users becomes how intuitive you make it.  Have you considered how different people might interpret a swipe?  If a user thinks perhaps a swipe takes place above their head, will they become frustrated if you don’t consider this fact?  If a user waves super slow, and each side to side motion takes .3 seconds instead of my .2 seconds as designed, is THAT OK?  Visual feedback can help greatly, but I think that considering all of the edge cases can greatly increase the natural feel and intuitiveness of any gestures you design even before thinking about visual feedback.

As I said, I’m funneling all this effort into my Node.js plugin.  It’s probably in the alpha stage right now, so I’ll just link you to my gesture scripts over on Github:

https://github.com/bengfarrell/nuimotion/blob/master/src/gestures/Swipe.cpp

https://github.com/bengfarrell/nuimotion/blob/master/src/gestures/Wave.cpp

I think as my add-on gets more solid, I’ll definitely be cleaning these up as well…organizing code better, removing redundancy, etc.  This should just give you a good idea of the logic behind the gesture.  Thanks again to Furkan Üzümcü for the C# Swipe code that my swipe is largely based on.

http://techcrunch.com/2013/03/15/the-future-of-javascript/

Basically, the article’s headline indicates a major throwdown is ahead of us.  People will reject Javascript outright… killing it, or we all open our hearts to JS making it the ultimate one for all language.  Thankfully, the content of the article is a little better, describing the growing pains as people have adopted the language more and more and speculating how it (and we) will adapt.

To me, though, this and other sensational headlines like it is the same old history repeating itself.  Did we really think that the big buzzword that is HTML5 would last forever?  Sorry to tell you guys this, but people are getting bored.  And when people get bored, the other camp that doesn’t like technology X comes out with pitchforks with the great big “I told you so’s”.

If the pitchfork dudes can sway opinion, then the snowball rolls and gets bigger….and bigger…and bigger.

But whatever shall replace this hole in our hearts, now that technology X has died?  There’s always something, and when technology Y is announced, it’s imagined as a heroic knight riding in on a white horse to save the day.  Once that happens, technology X has “died”.

Dig the grave, say your last piece and pull up the hearse.

It will happen to Javascript and HTML5, too.  Does it matter, though?  What happens to a technology when it “dies”?  Lets ask Adobe!

Flash is dead, right?  Nah – just fallen out of favor in the larger context.  Adobe still invests resources into making Flash better and better.  They’ve remarketed it towards games now, but it still does everything it did before.  Yah, so it doesn’t do mobile without the help of it’s little brother AIR.

Is it dead to you because it doesn’t do mobile?  Guess what genius, there are still plenty of laptops and desktops.  There are still people consuming videos and games and rich media.  Yes, some of this is being eaten by HTML5 adoption.  What are we seeing after Flash has died?  Well, it simply declined.  Some folks moved on.  Others didn’t.  I still hear of plenty of Flash and Flex projects going on, it’s just not a compelling story anymore because there’s been a decline and headline writers are bored with it.

OK….maybe it’s too soon.  Maybe death doesn’t happen that quickly and my example is bunk.  How about another Adobe product?  Way back in my career’s beginning, I was in love with a multimedia authoring tool called Director.  That was actually proclaimed dead when Flash started gaining traction.  So…..2002 or 2003, maybe?

Know what Adobe just released?  Yep, Director 12.  That’s like 20 years worth of Director by Macromedia then Adobe.  Do people still use it much?  Nope.  Is it still alive?  Yep.

There will always be old projects to update, workflows to continue, but if the new hotness comes along – yes, your favorite technology will decline in popular favor.

How bout another example?  There was a time when people said Java will take over the world.  I wasn’t a Java dev until recently, but if you got caught up in the moment, you might seriously believe it would.  I was kinda guilty of thinking the same thing of Flash back in it’s prime.  Tons of Java jobs sprung up, entire enterprises were taken over, it was injected into college curriculum as the real world thing you’ll need.

Anddddddddd….it declined.   But shit, Java in it’s decline was probably better than most techs at their peaks.  As a result, Java is still there.  We still need developers for it, and Google bumped it up a little with Android development.  Some people might say that Google brought it back from the dead.  It was never truly dead.  It just lost several percentage points in market favor.

See a pattern?  I do.  I’ve lived it.  And I’ve freaked out when my favorite technology was being threatened thinking I’d die in a gutter doing Flash and Director work for half eaten sandwiches out of a dumpster.

So, Javascript developers, HTML5 developers – listen up.  Your favorite things will all DIE!  But that doesn’t mean that they won’t lead perfectly normal lives after death.  Javascript might do as well as Java so long as browsers exist as they do today.  But just like Java, Javascript will die when marketing people get bored and try to sell you the new hotness.

Having said that, don’t use my advice for complacency.  Typically when things die, you’ll still find work, but you’ll get paid less and gigs might be a little harder to find.  So don’t get tied in to one tech.  Explore and branch out.  The biggest mistake I ever made, not ONCE, but TWICE was to think that my favorite tech was the bees knees and it would take over the world.  I’m seeing it happen with front-enders today.  In fact, I can recall one brain melting moment at a meeting when someone suggested that native mobile app development in Objective C and Android was the “Flash” of the mobile generation.  It’s a detriment, when soon folks will see the light and we’ll all be doing HTML5.

No.  Cross-platform never wins.  It always takes the dive.  Ride it high while it’s here but don’t expect it to last.  Just simply get curious about different tools and languages, try them out – and pay attention to the market.  Nothing you do will be a waste of time.  Anything that dies on you will still be useful, if not in it’s current incarnation, then through the concepts and ideas it carries over to all other things in our space.

Guess what’s living now?  All of it.  I can be a Flash developer, a Java developer, a COBOL developer, and a Javascript developer.  I can make awesome HTML5 experience and make some cool Hypercard experiences (I think).  The more technologies that “die” the more opportunities we have to do new and cool things, not the same amount of opportunities or less.