Omar Gonzalez

I do Flex and Flash on everything. I like it.

• About

• RT @pixels4nickels: t.co/NGPcw5E7 #cleancode #SOLID #TDD about 1 hour ago from Tweetbot for iOS ReplyRetweetFavorite

How I Learned To Enjoy JavaScript

Eleven months ago I would have cringed at the thought of having to build large web applications, like the ones I'd usually built in Flex, using JavaScript. Over the years my JS usage became less and less; embed a SWF, fix an IE bug. At the same time the opportunity to work on a big web app that would need to be written in JavaScript was becoming a real possibility. I began to research what the latest JavaScript techniques, tools and best practices were being used by the JavaScript community. What I've learned over the last eleven months is that I am also capable of enjoying big development in JavaScript, even after being mainly an ActionScript developer for close to 10 years. And even after being so adamantly opposed to dynamic loosely typed languages like JavaScript after having grown so accustomed to a strict-type language like ActionScript. With time and some good tool choices I've now gotten to the point where I can enjoy a JavaScript project just as much as any Flash, Flex or any other language I've coded throughout the years. Below I'll talk about some of the tool choices I've made to help make my life in the JavaScript world more enjoyable.

The first thing that I noticed in the modern JavaScript world was that there are about as many frameworks as there are JavaScript developers. Its like there is a new framework named after some fruit or celebrity about every day. Going through so many frameworks and libraries is a daunting task. I spent a lot of hours reading and watching video tutorials about as many frameworks as I could possibly find. Below I will go into my toolset of choice. I am not saying this combination will solve everyone's problems, or that this is the best combination for you. I will instead present the toolset that has made me a happy JS dev, why I chose them, and I will list some alternatives where I can. So here goes!

Script Loaders

One of the first things I knew could be a mess with JavaScript development is script management. The old days of having over 20 script tags in an HTML file and having to manage those was not something I was looking forward to trying to deal with. Scripts arranged this way can be fragile. Are they in the right order? Will scripts break if I have to add more code? Script loaders help you so you can keep your JS code organized into "class" modules. My other goal with finding a script loader was being able to use a single script tag.

require.js

I've been using require.js to do all my script loading. Aside from giving me a more maintainable set of <script/> tags in my HTML pages it also provides a great file concatenator and optimizer that will package all of your JavaScript files into a single file and then minify it with Uglify.js or the Google Closure Compiler. Require.js is an AMD module loader, which is a JavaScript module pattern to help you keep your code out of the JavaScript global scope to help prevent function name collisions. There are other module patterns like the CommonJS module approach, which is the pattern used in node.js scripts. The require.js approach can also be used in a node.js context.

Alternatives: Shepherd.js, Browserify.js, Common.js

Automated Testing

Running automated tests is important for any software development. When you're coding in a language like JavaScript I would say it is even more so. This is a space where JavaScript has very many options to choose from. In my experience looking through all of the options this really becomes a matter of syntactical personal preference.

Jasmine

For unit testing my JavaScript code I use the Jasmine BDD style framework. I really like its readability, the api it provides creates what I think is a very readable set of tests. It comes with its own mocking/spy framework, or you can use something like Sinon.js to create your mocks and spies. There are also different ways to write Jasmine tests and execute them. You can set up your Jasmine test runner in an HTML file and just navigate to the page. I prefer to use jasmine-node, a node.js based Jasmine spec runner. I prefer this approach because I don't have to manually add to a test suite. I can simply set a spec path and jasmine-node will run all the spec files it finds.

Alternatives: QUnit, Mocha, YUI Test, Buster.js

jasmine-node

The jasmine-node npm package lets you run Jasmine specs in a node environment. More importantly, if you're writing require.js modules then you need AMD modules to run in node, node's require expects CommonJS modules (module.exports = {}). Using the jasmine-node options you can configure it to use require.js. You can then write your browser JS modules as usual in closures with define() calls. Then in your Jasmine specs, simply wrap them in a require() call and run jasmine-node, like this:

require("path/to/ClassUnderTest", function (ClassUnderTest) {
  describe("ClassUnderTest()", function () {
    it("does stuff", function () {
      // test something
    });
  });
});

This lets you run your AMD modules through Jasmine on node with jasmine-node and then you don't have to manually create suites or test runner HTML pages. I find it more productive. Check out the article "Testing with Node, Jasmine and Require.js" below for info on resolving global objects some of your scripts may depend on, like window, document, etc. Angular.js also solves some of these issues with the abstracted services it provides like $window, $document and its dependency injection system, more on that below.

Cucumber.js

Unit tests are cool, but they're not going to ensure your JS modules are all tied in together and all working as expected once you've integrated all your units together and you run them in the browser. Cucumber.js is a JavaScript port of the popular Ruby BDD testing framework Cucumber. It lets you write Gherkin based application specifications that you can then link with the Cucumber.js in what is referred to as step definitions to actually test your application specification. Ive used Cucumber.js for web apps doing headless browser testing with Zombie.js, running on Node.js. I've also used it to spec, build, and test CLI apps built on node.js. In fact, Cucumber.js can even test itself!

Alternatives: None that I know of.

CSS Preprocessors

With all of the experimentation going on at the different browser vendors it is increasingly more difficult to keep track of things like browser specific prefixes and which platforms they actually work on and don't. CSS preprocessor help to keep your CSS maintainable not only by helping to normalize browser specific prefixes but also by introducing language features not currently present in CSS, such as easy to use variables and better CSS specificity in your style definitions.

LESS

My preprocessor of choice is the LESS preprocessor. I haven't found much difference in the usage itself between LESS and other alternatives like SASS. LESS chooses a syntax that allows all CSS syntax to be valid, and then adds to it with variables, mixins, and nested rules. LESS has functions, SASS has inheritance and brace-less syntax option (a la CoffeeScript, Haml, etc). The main two reasons I chose LESS was a build tool called LESSLESS which lets me easily compile LESS code into CSS at build time, and less-elements, which solved my prefixes concerns by providing a set of mixins ready for use, nice.

Alternatives: SASS, Stylus, Compass

Application Frameworks

This decision took the longest for me, as I suspect it will take anyone that is currently looking to switch from another language or framework to something different or new. For me the decision ended up coming down to three choices, Ext.js, Ember.js and Angular.js.

Angular.js

For me ultimately I chose Angular.js for a few of reasons. The first one doesn't appear to be as big an issue as it was about 10 months ago, but at that time the documentation on Ember.js was not nearly as thorough as it was for Angular.js. Angular.js has a great tutorial, dev guide and api reference which were mostly there when I was evaluating these frameworks.

Testability was also a determining factor for me. Even in its earliest days Angular.js has always had a lot of examples on unit testing its parts, and all of the patterns in the framework are written in very testable forms. From the dependency injection it provides, to built in framework mocks and Jasmine test runners and test samples it really proved to me that the Angular.js team held testability as a first-class citizen in the framework, and not just an after-thought. As their tutorial teaches you how to use Angular.js, it also teaches you how to test your code along with it.

In evaluating Ext.js there is no doubt that it provides a great component set. I did not like what I saw from the MVC it comes with, which is optional. That said, Angular.js is extremely flexible, and so Ext.js components can be easily used in Angular.js directives, giving you a truly declarative and decoupled interface layer. Ext.js says its declarative, but writing markup in a JavaScript string doesn't make it declarative. At least not in my opinion. But because I could still use Ext.js components, or Twitter Bootstrap, or jQuery UI, at my discretion in Angular.js, I ultimately chose Angular.js.

Alternatives: Ember.js, Ext.js, Backbone.js, Meteor.js, Knockout.js, Sammy.js

Linting

Linting is the process of going through your code and identifying potential dangerous or buggy code usually based on static analysis. It helps to identify some of the really common pitfalls in JavaScript and in coding in general. Things like accidentally using "=" in an if comparison, or using "==" instead of "===".

JSHint

The two popular choices are JSLint and JSHint. I chose JSHint because it provides more options so you can configure it to your liking. You can get as strict as you want or relax some of the rules that it imposes.

Alternatives: JSLint, Google Closure Linter

That's a lot of stuff to run

Each one of these tools provides valuable benefits. However, running all of these tools manually to reap those benefits is not productive. The idea is to make the development process more enjoyable, and not more burdensome. Automation does not stop at the testing layer. All of these steps, from compiling less, switching .less file links to .css links, concatenating JavaScript, running unit tests, running Cucumber suites, minifying CSS and JS files, linting code, all of these things can be easily automated with the use of one of many build tools.

grunt.js and node.js

The big part of why node.js became so popular was its use as a quick web server and the many possibilities it opened to JavaScript developers on the server side. But a side to node.js not often talked about is its role as a great build environment. I run unit tests with Jasmine using the jasmine-node module for node.js. I run Cucumber.js tests using its command line interface which runs on node.js. I use a node based web server to serve my static HTML files to Zombie.js, which is a node based headless web browser you can script in JavaScript from within Cucumber.js step definitions. And finally, I use grunt.js to write my build scripts in JavaScript, also running on node.js.

Not only are my builds extremely fast on node, but they're easy to maintain. The grunt.js framework has over 100 plugins already. I wrote the grunt-jasmine-node plugin, and also the grunt-cucumber plugin. Its fast and easy to set up a grunt file, in JavaScript, and automate your builds. I like being able to have one language for the entire toolchain that I use, even though I know other languages and don't have an issue switching. Especially in big projects, it reduces the amount of requirements needed for a developer to be effective with your entire project.

Alternatives: ANT, make, rake, jake

WAT?

That is a lot of frameworks and libraries to learn, but I've found them to be very complimentary, and so far have been effective for my needs. It can't hurt to have a great IDE to enjoy coding in JavaScript either. My choice is IntelliJ IDEA, or WebStorm (can be loaded as a plugin to IDEA). Another thing to keep in mind is you won't enjoy JavaScript if you're trying to force patterns and practices you're used to in other languages like ActionScript 3 or Java. Within all of JavaScript's ugliness it is entirely possibly to write clean, trust-worthy, maintainable and elegant JavaScript code. You just have to find the patterns and designs that make you the most productive. Learning the language design and its capabilities will allow you to create new workflows and patterns that you might end up liking! So far I am very happy with the toolset that I've chosen, but I'd love to hear about your choices as well! There's always something to learn somewhere…

Suggested Reading

• Test Driven JavaScript Development
• 20 JavaScript Frameworks Worth Checking Out
• Ten Reasons You Should Be Using a CSS Preprocessor
• Cucumer and JS: Getting Started with Cucumber.js
• JavaScript The Right Way
• AngularJS Tutorial
• Meet Grunt: The Build Tool for JavaScript
• Testing Your JavaScript with Jasmine
• Testing with Node, Jasmine and Require.js
• Specification by Example

Deleting Tweetbot Public Beta Columns

So I just got the new Tweetbot public beta, released for those that got a Twitter token for Tweetbot Alpha for Mac. The new beta has a column option that pretty much adds the only missing feature to completely get rid of TweetDeck once and for all (I already had).

But once I added some columns I couldn’t find a way to close the columns. I did find a way but you have to edit the app’s plist file.

Go into your user folder. In your user folder navigate to

~/Library/Containers/com.tapbots.TweetbotMacAdHoc/Data/Library/Preferences

If you don’t see the Library folder turn on your hidden folders. Or you can try typing this into Terminal:

open ~/Library/Containers/com.tapbots.TweetbotMacAdHoc/Data/Library/Preferences

In the preferences folder find and open: com.tapbots.TweetbotMacAdHoc.plist

You’ll need XCode to open it, I’m not sure if there are any other apps you can use to edit a plist file. Not my realm of expertise.

Once you open the plist file, scroll down to the entry ‘MainWindowColumnInfo’ and open the tree,  you should see an entry for each column you have open. Press the little minus sign to remove them and restart Tweetbot. Voila!

Android Development: First Impressions

Over the last few weeks I’ve spent time diving more into native Android development, and I thought it might be useful to share some of my impressions and thoughts on ways in which to approach learning this type of engineering. Read the rest of this entry »

Intro to MongoDB and MongoAS3 Slides and links

I gave a presentation to the AZFPUG (Arizona Flash Platform User Group) on MongoDB and MongoAS3. Below are links to the presentation slides and the GitHub repository to download the example code. The examples code repository is just a start and will continue to get new code additions as new features and new code example requests are received. If you find any errors in the code or have any comments or suggestions on the code examples please post them in the issues section in GitHub as opposed to the comments in this blog post.

Meeting Recording: t.co/WJ6yPIR6
Slides: dl.dropbox.com/u/1414382/slideDecks/IntroToMongoDBAndMongoAS3.pdf
Code Examples on GitHub: https://github.com/s9tpepper/MongoAS3-CodeExamples

Robotlegs Support for Starling Framework

Today I finished creating a set of classes for the Robotlegs framework that allow you to use the Starling Framework with Robotlegs.

Robotlegs is a great lightweight application development framework that works great with traditional Flash and Flex based projects. With the release of the Starling Framework we can now leverage the new Stage3D APIs in Flash to create 2D experiences that are GPU accelerated. This means we can now build even richer user experiences in Flash than we ever have before! Because Starling is based on Stage3D the Context class that comes with Robotlegs does not work out of the box with the Starling framework. Using the robotlegs-starling-plugin that I have uploaded on GitHub you can now bring these two great frameworks together and start building great Stage3D experiences with Starling!

MobileHackDays Hackathon LA – Building WarShips

A couple of weeks ago members of our team at almer/blank participated at the hackathon in Los Angeles representing Adobe as Team Adobe. You can read and see some video of the game we built, WarShips. I thought I would write a little bit about how we accomplished building a P2P multiplayer multiplatform working game foundation with a single code base deployed to every major device operating system in the market (iOS, Android and BlackBerry QNX as well as web browsers, OS X and Windows) in under 18 hours of development.

The team consisted of four developers and a designer. In terms of pre-written code, we used PureMVC with SignalsCircuit and as3Signals. Everything else was written from scratch at the event. We thought we had an idea of how to break up the work, but once we started writing code we quickly realized we'd have to just coordinate as we went along.

To start off we had one person set up the P2P framework for establishing a connection with peers and building a mechanism for sending notifications to other connected peers. Second person started with building the game "login" screen to connect to the game. Third person started by building out the domain objects and proxies. The fourth dev started on the main view code which drove most of what you actually saw visually, the quadrants and zooming into them, cursor for aiming and editing of the ship placement.

As we each started to finish the parts we were working on we would usually end up in a sort of pair-programming-ish kind of mini-session to either help someone else out with what they were doing or coordinate where we could help with keeping progress being made. The code was all being managed using GitHub, pulling/pushing worked pretty flawlessly for us in this rapid development pace. Working with a framework like PureMVC or Robotlegs is really vital to the success of this kind of development. Being able to easily communicate with your team members how we want to build something and then execute pretty much on 'theory' and then having it all work was a real testament to the value of micro-architectures. I'm not turning this into a PMVC vs RL vs Swiz debate, what I am saying is that it is vital that your team all speaks the same language, and that you all speak it fluently. That's really where the value is in these frameworks, of course aside from all of the technical code reasons, it enables teams to speak the same language.

We did this throughout the first day, and we got the majority of what is working in the video by midnight on the first day. On the second day only one of the team members started the day, so it was on that one developer to figure out how to get the last bit tied together. Still missing was actually setting off the Fire button, hitting/missing the airplane and enabling the next person to take their shot. Basically, we didn't have a game without this piece, but all the pieces were in place to tie it all together.

The first dev on day 2 started with a few instant messages to the other two devs to find their way around starting to bring the final loose ends together. Eventually we had three team members together  again to finish out the last couple of hours before presentations started. In those last couple of hours we were able to work through the last few issues that finally got the firing turns working. I was able to chill out and watch the other presentations while deploying to AIR desktop, and the web browser. We weren't going to do those since it was a mobile event but I had time and it was easy.

This was definitely an interesting experience. I had never done anything of the sort so I wasn't really sure what to expect us to actually finish. Going in I thought we might be a little overambitious with the p2p stuff as well as deploying to all the devices that AIR lets us except TV (and thats just cuz I didn't bring a TV and my hardware dev kit). We managed to pull off a working game and we deployed to all the devices we wanted to and it wouldn't be possible without Flash Builder, AIR and some good team coordination. I was pretty proud of what our team accomplished in such a short time and I think it speaks volumes about the capabilities of Flash, AIR, Flash Builder and the future of where we're headed. Flash is dead. Long live Flash!

A Glimpse into Adobe MAX 2011

I just finished setting up my schedule for Adobe MAX 2011 and I have to say I am even more excited after finishing my schedule. There’s a lot to choose from all the sessions being offered this year but after finishing going through and selecting what I’ll be going to it turned out that I am heavily favoring the gaming sessions. There’s a lot of cool stuff so I thought I’d list the sessions that I’ve signed up to in case you’re wondering what kind of sessions are being offered but haven’t taken the time to look through the MAX schedule. I can’t wait! Read the rest of this entry »

Book Review: ActionScript Developer’s Guide to Robotlegs, from a PureMVC Dev’s Perspective

Recently I decided to use Robotlegs as the application framework for a small personal project I was working on to test the usability and needs of MongoAS3. Stray was awesome enough to provide me with a prerelease copy of the book to help me along with my introduction to Robotlegs. In this post I’ll go into what I thought about the book and my experience with the Robotlegs framework.

Read the rest of this entry »

Using ViewNavigator in Flex 4.5 Web Projects

I was going to write a long drawn out post, something like this one: omar.likesflex.com/?p=32 But, I had a different idea this time. Below is a video that shows the process of getting the ViewNavigator starting with an empty project. I left the sound recording on so you can listen to some awesome music while you watch me code, haha. I’ve also attached an FXP file with the project created in the video if you want to get right at the code. Read the rest of this entry »

Introducing MongoAS3

I've recently finished some work on a project I've been doing on my downtime at nights called MongoAS3, an ActionScript 3 driver for MongoDB. The driver is now at version 0.1 and I've written a getting started blog post on my personal blog here: omar.likesflex.com/?p=37.

MongoAS3 lets you establish a connection directly with a MongoDB server  and lets you use it directly from AS3! Check out the code on GitHub (https://github.com/s9tpepper/MongoAS3) and fork it, pull requests are encouraged!

If you have questions please post them on my blog or in the issues section of GitHub (https://github.com/s9tpepper/MongoAS3/issues).

Recent Posts

• How I Learned To Enjoy JavaScript
• Deleting Tweetbot Public Beta Columns
• Android Development: First Impressions
• Intro to MongoDB and MongoAS3 Slides and links
• Robotlegs Support for Starling Framework

Archives

• September 2012
• January 2012
• October 2011
• September 2011
• August 2011
• July 2011
• April 2011
• January 2011
• December 2010
• November 2010
• September 2010
• July 2010
• June 2010
• May 2010
• April 2010
• February 2010
• November 2009

Categories

• Actionscript
• actionscript 3
• Actionscript 3.0
• AIR
• Announcements