Omar Gonzalez

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

• About

• LOL “@_struct: This is why you should always pay your web developer. t.co/LsPiCWlK” about 4 hours ago from Tweetbot for Mac 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

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!

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).

Getting faster, and faster…

Getting faster is something that almost every developer wants to do. At the least, every developer _should_ be striving to do things faster and faster. I'm not going to get into approaches such as Test Driven Development versus UML-ing first, etc. Instead I am going to talk about things that every developer of every level can do to improve the speed at which they do things.

So why should all developers strive to be faster? Beside being more profitable as a developer, independent or not, it allows you to move on to your next development thought. When developers are coding everything is our enemy. Anything that is outside of the thinking process is an obstacle to overcome to get your thoughts in code and working in an application. The dog barking outside, your hands, the keyboard, the font size, noisy office, finding parts of already written code… all these things are trying to distract you from your main goal. Some of these are out of your control, others are not. Below are some of the ones that you can practice and help you get your thoughts into code faster so you don't lose your train of thought… again.

Learn to type

Ok, this sounds kind of funny… but seriously, learn to type. If you're trying to code and you are typing with two fingers, or wresting with the keyboard and looking down instead of looking at your screen as you type, then you need to learn to type correctly. The keyboard and your hands are two of the biggest obstacles to getting your ideas down into a document, whether its documentation for an application, a tutorial, this rant on coding faster, or the code you write to make your applications. The less that you have to think about typing the faster you will put your ideas into your code. You should be able to put your hands down on the keyboard and start typing without looking at the keyboard before, during, or after typing. Essentially, it should become second nature.

There are several ways that you can improve your time other than just practicing the proper techniques. There are free typing games and lessons that you can find online. There's typing software too such as Mavis Beacon Teaches Typing. You can also start by memorizing the keyboard and practicing the motions in your head or on a keyboard printed on paper. Both of these techniques work very well. Think of words in your head and mentally find the keys and think of which finger should be touching each letter. This type of brain exercise helps you to build the kind of coordination that you need to identify where a key is quickly and have your finger react, which is what is happening when doing things such as typing on keyboards or fretting guitar chords on a fretboard.

Learn your IDE

Something else you can do to increase your speed is to really learn everything that you can about working with your IDE of choice. Here I am also not going to go into detail about which IDE is better or which one will make you faster. All developers have chosen their IDE for one reason or another and I'm not going to get into that. Instead, I want to emphasize that which ever one it is that you do choose, take the time to learn it completely. I use both Flash Builder and FDT and I still learn new things about both IDEs. You won't be able to learn your entire IDE in a day or a week, but take time out at least once a week to spend some time exploring some buttons or options you might not have looked at. Sometimes I just press keyboard combinations to see if they do anything (be careful with this do it in a test project) or I look into the key mapping options to get a listing. The listing isn't always very clear based on the command names but it will give you a good idea of some things you might want to try out. Flash Builder and FDT share many hidden little gems because they are both built on Eclipse. IntelliJ and others will have their own wealth of features that will help you to get code written faster, and ultimately, your thoughts in code with more efficiency.

Exotic Flash Builder 4 Tips and Tricks: blog.guya.net/2010/10/03/exotic-flash-builder-4-tips-and-tricks/
We <3 FDT: welovefdt.com/
IntelliJ Tips and Tricks: www.jetbrains.com/idea/documentation/tips/index.html

Organize better

I am always looking at the package structures and class structures I make to see if there is a better way to refactor my code and make things easier to find and read. Don't be afraid of refactoring, in fact, do it often. Not only will it make your code easier to read, it'll make your code easier to find, which can get confusing and time consuming in poorly organized classes and packages. It is said that we spend the vast majority of our time actually reading code instead of actually writing it. This time can be reduced if you stick to both well established standards and standards that you have built on your own or with your team. Having these in place and strictly following those conventions will always make your code organization better, and will help you to reduce the time it takes to find and read your code. This is a good thing so that you can have more time to actually write code and concentrate on making progress. This will make you faster.

These are just some things that will help you to get your thoughts in code faster and hopefully make you a more productive developer. Each of these can have their own post or tutorial, I am just touching on some very simple things that you can do to improve your productivity. If there are other awesome productivity tips and tricks that you have I'd love to hear them, please do post them in the comments and share with everyone! I'll update the post as great new tips come in from anyone else that wants to share.

OSMFSparkComponents Flex 4 Library

Example: basic player
Example Source: example source code
GitHub: OSMFSparkComponents

Last week I posted on my GitHub account a new library I'm calling OSMFSparkComponents. The library is a small collection of classes that support what are right now two main components, the OSMFSparkPlayer component and the OSMFPlaylist component. Both of these components are Flex 4 Spark based components. Here is a working example of a very basic implementation: basic player. You can right click on the SWF to view the example source code.

The goal of these components is ease of use for most of the basic OSMF needs while providing a foundation to expand on the components and build a more robust player that meets the needs of complex projects.  The components both come with default skins that are designed to have a unified look, but because the components are built on the Spark architecture skinning the components works the same as you would expect from any Flex 4 Spark component.

The OSMFSparkPlayer component is pretty simple, its only requirement is setting the screenWidth and screenHeight properties.  It has properties for toggling things like autoPlay and methods to do things with media, such as pause the media or play the media.

The OSMFPlaylist component allows you to easily create a playlist component that will display a list of media items and control an OSMFSparkPlayer instance to playback video.  The playlist component also has properties to toggle different functionality, which include autoPlay, looping the playlist, automatically playing the next item, and toggling the ability for users to actually be able to click on a playlist item to make the media play.  Getting data in the playlist is easy as well.  The playlist component expects an array of objects to be set to the components data property.  The component uses the array to build the list of items, and the component has field definition properties, such as labelField on a DataGridColumn, to define where to get the information that it requires to correctly render the item renderer for a particular item.  The default four field definition properties are titleField, descriptionField, thumbnailField and urlField.  The playlist will use these field definition properties to look up the relevant information on each object in the data array.  The urlField expects the object to return a URL string that the playlist component will run through a MediaFactor to create the appropriate OSMF MediaElement type.  This means that the playlist component will support all of the media playback capabilities that the OSMF framework supports out of the box, while providing access to the MediaFactory instance to enhance the capabilities of OSMF with custom elements.

Which leads me to the YouTubeElement.  In the basic example link above the first two lines in the script of the MXML file are how to add custom elements to the playlist component.  The OSMFSparkComponents library includes a custom MediaElement built for YouTube, which will play any YouTube video links to public YouTube videos.  Simply adding those two lines activates the YouTubeElement for the playlist to be able to play YouTube videos such as the Seether video it plays in the example.

These components are currently in a very early stage as I begin to develop more features and I start to identify and squash bugs in the components, which is why they're at version 0.1 with this first release, but I'm trying to go by the release quick and release often, so this first version has hit the day light.  You can get the SWC or source code from GitHub here: OSMFSparkComponents. If you do end up checking these components out and find any issues I would appreciate any reports that you can drop off on the issues section in GitHub, and I will try to squash them asap, or feel free to fork away and submit patches!

Facebook Flash Web App Debugging Locally (sorta)