#javascript

Here at Setfive, when not helping our clients with their technology woes, we love experimenting with fun new technology and continuously growing our professional tool kit. As of late we have been throwing around some potential ideas for a Setfive iPhone app (get Chicken Pad Thai delivered no matter where you are in the world) and have been looking at a couple of tools to turn this lofty dream into a reality.

Since no one in the office has any significant experience with Objective C or Swift we decided that, rather than bang our heads against the wall trying to learn the nuances of yet another programming language, we would look to one that we already know, and decided to dip our toes into the JavaScript driven React Native ecosystem.

In the past we have taken our chances with other cross-platform native apps (PhoneGap in particular) that allow you to wrap a web app into a web view however, these methods fall short; if the looks of your app don’t bother you then the serious performance hit that comes from interfacing directly with native objects will.

If you are unfamiliar with React Native, it’s an open source JavaScript framework, built by Facebook, that allows the production of iOS and Android applications using a syntax familiar to HTML. What separates React from other frameworks is that it runs a separate JavaScript thread to control the UI of your application so it can utilize native mobile components. The idea is that this should lead to a seamless user experience that feels both polished and native. After some hands on experience we can say that React did not disappoint.

What we built

In order to test React a little bit farther than the simple hello world example we decided to build a simple application on top of our preexisting Rotorobot API. This app allows users to see the available players for a daily fantasy sports contest on that night.

To get started, we needed an index page that would show up when the app was loaded. Just to keep things simple we incorporated a minimalist layout with a UIButton that responds when pressed.

Upon pressing the button a new scene is added to the storyboard of our application. This scene is a ListView Component that has a row for every available slate of games that will be played that night. In addition, each one of these rows is also wrapped in a TouchableHighlight Component, which allows them to respond to touches.

Any row that you touch results in an AJAX request being made to the Rotorobot API and the available players in that slate are displayed, sorted in descending order based on salary.

Our Experience

Getting something up and running with React Native was definitely a lot easier than expected. It was honestly as simple as using npm to install react-native-cli and then creating a new react native project using react-native init. The init function provides everything that you need to run a React Native application.

After your project has been setup it’s time for all of you Xcode naysayers to either bite the bullet and download Xcode or look for guidance in the form of another SaaS solution.

In order to help you out we’ve provided links to a couple:

If you’re old fashioned like us, and opted for the traditional route then you installed X-Code. The react-native init function creates an Xcode project file inside the ios folder in your new project’s directory. Simply open this up using Xcode and you are off to the races and ready to build/run your project at will.

There was only one minor gotcha that reared it ugly head while trying to get our application up and running. The React Native Packager runs underneath node and requires a port for its functionality. The default port that it runs on is 8081, and there is a chance that you could have a process already running on that port so your application will not be able to run. So before you try and run your Xcode project for the first time it is worth doing a quick check to make sure that port 8081 is free using:

sudo lsof -i :8081

Other than this minor inconvenience you should be all set for development!

After an hour or two of playing with React Native and building a pretty simple app, the power and simplicity of this framework became clear to us. First and foremost it was very refreshing to only have to run one or two npm commands and then be writing code in minutes afterwards. Setup was quick and painless which is always appreciated. During development we immediately noticed that developing our app felt just like developing for the web. Laying out the application was done using the CSS flex box, and was both quick and intuitive. Additionally, and probably more importantly, the framework just works. The UI components are native UIViews so naturally they look, feel, and behave the same as normal native components. We would definitely consider using React in the future and look forward to seeing how it improves and progresses from here.

Posted In: Javascript

Tags: , ,

Enter the dragon

Interning with Setfive for the last couple of months has given me the opportunity to both work with numerous, modern-day technologies and transition into being a more confident, organized developer. One technology in particular that I’ve had the chance to learn about and use extensively during my internship here is the JavaScript programming language. Programming with an MVC framework like AngularJs has shown me the many facets of the JavaScript language and given me an interesting foray into learning JavaScript from the top down.

Coming from a mainly C++ background the first thing I noticed about JavaScript was its flexibility. The mixture of the dynamic typing, along with the support of multiple programing paradigms (Functional programming and Imperative programming) gave me a freedom to program any way that I saw fit and do things that I never even thought were possible in a language with a stricter typing system. However this freedom definitely comes with a price, sometimes making even moderately complex programs both hard to navigate, and even harder to debug.

This lack of an inherent language structure, though initially causing a few headaches and even more than a few fist shaking bugs has, over time, helped ingrain both strong development skills as well an inherent need to intuitively structure code. Both of these skills are at the forefront of programming with AngualrJs.

Leveling up

My experience with Angularjs has definitely been an incredibly positive one, although the beginning was quite rough. Actually, the beginning was fairly easy however, the step after the “hello (insert name bound from text box)” step was actually the rough one. With Angular, easy things are very easy but can become difficult very quickly as soon as you are trying to develop something that is not so rudimentary.

My first experience with Angular came in the form of writing unit tests for a project that was under development here during the Summer. I spent a couple of weeks delving through a large Angular application written by one of our head engineers. After my introduction to the framework I was given the chance to use it for some development while working on some frontend modules for the Rotorobot site. These are the main challenges that I ran into while trying to learn Angular Js.

The Tough Stuff

The first challenge that I had to overcome was understanding the structure of the Angular framework. Being very inexperienced with the design pattern of Model View Controller (MVC) made this aspect the hardest part of learning Angular. Angular implements MVC by having the developer split their application into MVC components and then acts as a pipeline connecting them together. It is a robust MVC framework that promotes complicated integration of different components into whole applications. If you don’t have a sense of how the pieces fit together then the “Set it and forget it” or 2-way data-binding nature of the framework can easily turn into one of your biggest headaches.

The second challenge with learning Angular was understanding the way that scoping works within the context of the framework. What possibly could have possessed the developers of Angular to name one of the most confusing parts of their framework the same name as one of JavaScript’s most confusing aspects –who knows. In order to use some of the most powerful features of Angular such as, custom directives, it was really important to understand how scoping works or else it’s virtually impossible to link programs together. Developers would be left with a pile of stateless, independent components responsible for various tasks of the application rather than a connected working whole.

The last major challenge with learning Angular was thinking in terms of modularity. With things like custom directives, and the various service providers being at its core, the Angular framework really helps to promote code modularity. And breaking your application into small, reusable, testable components. This concept is huge in Angular, and I felt like seeing it work within the context of the framework has made me a better JavaScript programmer overall.

Overall I thoroughly enjoyed my time with Angularjs and felt like I learned a significant amount about structuring web-based applications. I am glad to have been given some experience with a modern JavaScript MVC framework and I wouldn’t hesitate to use Angular again in the future.

Posted In: AngularJS

Tags: ,

One of the more opaque concepts about AngularJS is the process that converts a chunk of HTML from a template into “Angularized” HTML which is then inserted into the DOM. During this conversions, custom directives are replaced with their corresponding HTML content, Angular directives like ng-repeat are processed, and any event handlers of interest are wired up. As it turns out, Angular’s $compile service is what’s responsible for making the magic happen. OK great, but why is this interesting or important? Because leveraging the $compile service directly lets you take dynamic content and process it to enable Angular directives and behaviors.

Since examples are always helpful, here’s an admittedly contrived one that we’ll walkthrough. Imagine that we’re building a WordPress slideshow plugin and we want to support custom themes for individual slides. So in our plugin, a user would be able to modify the HTML that displays a slide, we’d save it to the database, and then retrieve that template when we render the slides. For arguments sake, let’s assume the “default” template for the slideshow looks something like this:

As you can see, we’ve got a few directives and by default we’re displaying some description. Generally, we could set this up by creating a “slide” directive that looks something like:

Great, nothing to crazy but with this setup there’s no way to supply dynamic HTML from our database to use in the template. In order to allow a custom template you’d just need to modify the directive to look something like:

And then you’d be able to use it with:

The key difference is that in the modified directive the template is inserted into the directive’s element using “angular.element(el).html(scope[“slide”].template);” and then finally the $compile service is invoked to process the regular HTML to get Angular magic.

Anyway, as always questions or comments welcome!

Posted In: Javascript

Tags: ,

A couple of days ago in my journey down the AngularJS rabbit hole I ran into an interesting issue. If you have a directive that’s dynamically adding an iframe tag how can you set an onLoad handler on the iframe with access to the directive’s $scope?

Interestingly, the top StackOverflow answer on Google recommends adding a function to the window object and then setting the onLoad attribute to that function. Although it works, this approach is decidedly not “the Angular way” and would definitely become unwieldy with more than one iframe on the page. I poked around a bit and turns out there’s a better way to do this. The “trick” is that it’s possible to access a directive’s $scope from inside its link function so you can set onLoad on the iframe element from there. This post provides an overview but it’s a bit light on details so here’s a concrete example.

Posted In: Javascript

Tags: ,

There’s plenty of opinions about the efficacy of technical interviews and an equally large amount written on the topic. Personally, I don’t think there’s much value in putting someone in front of a whiteboard and seeing if they can regurgitate how merge sort works (I couldn’t) and there’s plenty of blog posts arguing that point. Something that I do think is valuable is trying to gauge how well someone really knows a language that they’ve listed on their resume or used in a project. And recently, with the surging popularity of Node.js and “coding boot camps” it seems like every resume we’ve seen mentions a proficiency in Javascript.

So how could you suss out someone’s knowledge of Javascript? I poked around on Quora a bit and ran across few top voted related questions: What are some good JavaScript interview questions? and What are the most important JavaScript concepts to know for a job interview?. Skimming through them know, the questions are mostly focussed on “tricks” which isn’t very useful and the list of skill is a bit underwhelming as well. Ok, so what questions can we ask?

Prototypical Inheritance

Prototype based inheritance is woven into the fabric of Javascript so I think chatting about it will reveal a lot about a candidate. You’ll get a sense if they generally “get” how object oriented programming works and then more specifically how Prototype inheritance in Javascript works.

Looking at code, a good starting point would be talking through the difference between “Duck” in the following sample:

From there, there’s the natural philosophical discussion about how Javascript doesn’t have classes but instead objects are copied from existing ones down the prototype chain. That seems to naturally lead to a discussion of how you’d accomplish something like (don’t in production):

First Class Functions and this/bind

First class functions are heavily used Javascript in idiomatic Javascript so they certainly deserve some discussion. At a high level, describing first class functions is fairly simple. Functions are treated like any other object so that they can be passed as arguments, inserted into arrays, and all the other things you’d normally be able to do with objects.

Jumping back into code. An interesting first discussion would be “How could you implement a switch statement without using ‘if’ statements or a ‘switch’ block?”

Getting a bit fancier, another task would be to implement a “filter” method similar to the one found in lodash/underscore. “filter” accepts an array of elements and a callback and returns the elements which return “true” when passed to the callback. So as an example:

The big change is in our “filter” we’re changing the semantics so that “this” is the value from the list being filtered. Watching how someone approaches and implements this will reveal how deeply they understand Javascript’s function semantics.

Async and Promises

Last up would be touching on Javascript’s model of asynchronous programming followed by a Promise implementation (q, jQuery, etc.). The difference between asynchronous code and synchronous code is large enough that it probably could fuel an interesting discussion. A couple of interesting points to touch on:

  • At a high level, what is the difference between asynchronous and synchronous code?
  • In a single threaded environment like a Javascript engine, why would an asynchronous model be beneficial?
  • Typically, why would an implementation using Promises be more flexible than just a callback?

Jumping back into some code. A good first task would be to execute a set of asynchronous operations in series – Another interesting task would be to implement a tiny API using regular callbacks and then using a Promises library.

Anyway, just a couple of quick ideas. I’m still new to the recruiting and interviewing game so I’d love any feedback or comments!

Posted In: Javascript

Tags: ,