TxtyJukebox: Powering the soundtrack of your night

By Ashish Datta | 5 Comments on TxtyJukebox: Powering the soundtrack of your night

Picture the scene, it’s Friday night, you’ve got friends over and everyone wants to listen to some great music. The problem is everyone wants to jam to something different and you’re not thrilled to sit by your laptop all night. Enter, the TxtyJukebox.

TxtyJukebox lets you setup an event which creates you a unique number which users can text in song requests to. As TxtyJukebox receives song requests, it searches YouTube for music videos and then places the videos into your event’s queue. And then if you hook up TxtyJukebox to a TV you’ll be able to jam to videos on a big screen with big room sound. But wait, there’s more! If you have a Chromecast you can connect TxtyJukebox to your Chromecast via our app. The Chromecast app will launch from within http://jukebox.setfive.com/ so there’s nothing to download or setup.

So how does TxtyJukebox work under the hood? Well sit tight, technical details lay ahead. The webapp itself is a standard Symfony2 app along with the usual suspects – Bootstrap, Underscore, and a sprinkling of jQuery. Along with that, we’re using Twillio’s REST API to handle SMS along with a “webhook” from Twillio to the webapp to recieve messages. In addition, we’re leveraging the YouTube API to search and load videos which are then loaded into an iframe. Finally, the Chromecast app is HTML/CSS/JS powered by jQuery and underscore.

Building TxtyJukebox was a lot of fun and we’re thrilled that it’s been positively received. An awesome surprise was that Ryan over at Makeusof.com found it and incldued it in his post of How to Share Music from Multiple Devices to a Chromecast. As always, let us know if you have any questions or comments.

AngularJS: Automatically submitting HTML forms

By Phil Booth | Leave a Comment on AngularJS: Automatically submitting HTML forms

Our yearlong delve into the sea that is Angular Js has kept our engineering team busy for quite some time now. Throughout this fun time of exploration there have been ups and downs, muddled coding snares caused by niche problems that are almost impossible to conform to the constantly looming “Angular Way”, and complicated problems that could be solved so easily you wished you had a Staples button just so you could push it for the “That was easy”.

One invaluable resource that has continually helped guide us through our use of this robust MVC framework is the vast Angular Js community, that has helped answer most of our questions, from questions about basic tutorials, to more overarching questions about best practices when structuring applications.

On one of our more recent Angular projects, we ran into an issue implementing a fairly common need among web applications – generating an auto submit form. After poking around Google and StackOverflow for a bit, surprisingly, there was a lot less information on this subject than expected. So, we decided to write a blog post on the subject, giving back to the AngularJS community, which has given so much to us.

Interestingly, this problem can be solved quite easily once you have a more comprehensive understanding about the Angular directive’s Link function. Here’s a good StackOverflow answer if you’re interested in some light reading: AngularJS: What is the need of the directive’s link function when we already had directive’s controller with scope?. However, if you’re anything like us then you’re probably solely interested in learning just enough to solve the immediate problem at hand, so for you, the main “gotcha” that you need to know is that the template for any directive is wrapped as an angular element, and can be accessed inside of the Link function using the angular.element() function.

The basic idea is simple, create a custom directive for your auto submit form, make the template for this directive a form element with the information you want to send, and control its rendering using an ng-if directive. Using ng-if is important in this instance because this directive doesn’t just show/hide a portion of the DOM tree, but actually removes/recreates it, allowing you to take advantage of the directives Link function. Then, inside of the link function for the auto submit form directive, grab the form element using the angular.element() function and submit it using the javascript function submit().

If the above paragraph didn’t completely explain it to you, please don’t worry, here is a nice, concrete example to help you solve this problem quickly should you ever run into it again in the future.

Javascript, Angular, or how I learned to love the bomb

By Phil Booth | Leave a Comment on Javascript, Angular, or how I learned to love the bomb

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.

Spring Boot: Authentication with custom HTTP header

By Ashish Datta | 26 Comments on Spring Boot: Authentication with custom HTTP header

For the last few months we’ve been working on a Spring Boot project and one of the more challenging aspects has been wrangling Spring’s security component. For the project, we were looking to authenticate users using a custom HTTP header that contained a token generated from a third party service. There doesn’t seem to be a whole lot of concrete examples on how to set something like this up so here’s some notes from the trenches. Note: I’m still new to Spring so if any of this is inaccurate, let me know in the comments.

Concretely, what we’re looking to do is authenticate a user by passing a value in an X-Authorization HTTP header. So for example using cURL or jQuery:

In addition to insuring that the token is valid, we also want to setup Spring Security so that we can access the user’s details using “SecurityContextHolder.getContext().getAuthentication()”. So how do you do this? Turns out, you need a couple of classes to make this work:

  • An Authentication Token: You need a class that extends AbstractAuthenticationToken so that you can let Spring know about your authenticated user. The UsernamePasswordAuthenticationToken class is a pretty good starting point.
  • The Filter: You’ll need to create a filter to inspect requests that you want authenticated, grab the X-Authentication filter, confirm that it’s a valid token, and set the corresponding Authentication. Since we only want this to run once per request you can extend the OncePerRequestFilter class to set this up. You can see an example class below:
  • An Authentication Provider: The final piece is a class that extends AuthenticationProvider which handles retrieving a JPA entity from the database. By implementing an AuthenticationProvider instead of doing the database lookup in the filter, you can keep your filter framework agnostic by not having to autowire in a JPA repository. My implementation looks similar to:

And finally, the last step is to wire this all up. You’ll need a class that extends WebSecurityConfigurerAdapter with two ovveridden configure methods to configure the filter and the authentication provider. For example, the following works at a bare minimum:

And then finally to access the authenticated user from a controller you’d do:

Anyway, hope this helps and as mentioned above if there’s anything inaccurate feel free to post in the comments.

AngularJS: Using dynamic content with $compile

By Ashish Datta | Leave a Comment on AngularJS: Using dynamic content with $compile

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!