Go Cloud Go

Eleven Fifty Academy

2015-11-16T14:14:00.000-05:00

Last week I was fortunate enough to join with the two Daves from getfretless and help them to teach a group of developers the core concepts of angular.js and node.js.

This was a full five-day course where most students stayed and learned for more than 8 hours per day at the campus of the Eleven Fifty Academy.

I had a wonderful time helping students create a real application with a Node.js REST API, and well constructed angular front-end. I will be continuing to teach courses like this in the future at Eleven Fifty and hope to have many more classes that were as receptive and eager to learn JavaScript as this one. Thanks to the class for a great week.

Introduction To React - Officially Published!

2015-09-16T09:02:00.002-04:00

It has been a while since I posted that I was writing a second book, Introduction to React. Today it is officially available in both ebook and paperback formats. I hope you enjoy reading the book and the introduction to React as much as I enjoyed writing it.

Introduction to React teaches you React, the JavaScript framework created by developers at Facebook, to solve the problem of building complex user interfaces in a consistent and maintainable way. React.js shrugs away common front-end conventions in an effort to make things more efficient – use Introduction to React to learn about this framework and more today.

You will learn what React is, and why it was created to solve the problems it does. You will get to know the React API, and be introduced to React’s specific JavaScript extension, JSX, which makes authoring React components easier and maintainable. You will also learn how you can test your React applications and the tools you can use while building. Once you understand these core concepts, you can build applications with React. This will help you cement the ideas and fundamentals of React and prepare you to utilize React in your own use case.

What you’ll learn

How to use React to maintain complex user interfaces in an efficient way
How to integrate existing user interfaces and move forward with React
How to manage application architecture using Flux
How to easily utilize JSX, React’s JavaScript extension

Who this book is for

Introduction to React is for a web developer who is comfortable writing JavaScript and CSS. You will apply JavaScript to build web pages that utilize the paradigm shifting React framework. Introduction to React will provide you with the tools to create maintainable complex user interfaces.

Trying to Run React Native Android on Windows

2015-09-15T14:20:00.000-04:00

React Native for Android was released yesterday. As soon as I spotted the release I wanted to give it a whirl on my work PC. I did the npm install and got started right away, only to find that the init command was failing. I expected this because officially React Native isn't supported on windows but there is this master tracking issue for this in Github => https://github.com/facebook/react-native/issues/2693 ... anyway.. so I got an error:

events.js:141
      throw er; // Unhandled 'error' event
      ^

Error: spawn npm ENOENT
    at exports._errnoException (util.js:837:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:178:32)
    at onErrorNT (internal/child_process.js:344:16)
    at doNTCallback2 (node.js:429:9)
    at process._tickCallback (node.js:343:17)
    at Function.Module.runMain (module.js:477:11)
    at startup (node.js:117:18)
    at node.js:951:3

Not being one to give up right away I wanted to fix it. I noticed from the error message that the spawn of npm using ('child_process').spawn was causing the error. Luckily, npm contains several modules that can be a drop-in replacement for this and I just grabbed the module cross-spawn. I needed to fix this inside the react-native-cli/index.js file.

This fixed this first error. Next, I encountered an error where the script could not find my Android SDK. This is pretty much expected because on my machine I'm running Android Studio so it is the only place that knows about the SDK. The quick fix here is to find the path to the Android SDK and add that to a new environment variable ANDROID_HOME. I also needed to make sure that my JAVA_HOME environment variable was correct so that the build process would be able to find it.

Awesome, now I'm nearly there. I started my JS Server to watch for changes, I'm using Console 2 and Git Bash here

$ react-native start

Then in another console tab I run:

$ react-native run-android

Result:
It works, but not really.

First it seems to think that I'm not running my JS server, but then it kicks in to fetch the file changes.

This gets my hopes up. but then goes back to the red screen of fail. Why did it do this?!!? Well it seems that there may be an underlying issue with the way that the packager works on Windows based on the error that the packager spits out. I'm guessing that there is a simple thing to get this to work, but for now I'm moving back to OSX to do React Native.

        React packager ready.

[1:39:35 PM] <START> Building Dependency Graph
[1:39:35 PM] <START> Crawling File System
[1:39:52 PM] <END>   Crawling File System (17082ms)
[1:39:52 PM] <START> Building in-memory fs for JavaScript
[1:39:54 PM] <END>   Building in-memory fs for JavaScript (1498ms)
[1:39:54 PM] <START> Building in-memory fs for Assets
[1:39:55 PM] <END>   Building in-memory fs for Assets (1421ms)
[1:39:55 PM] <START> Building Haste Map
[1:39:56 PM] <START> Building (deprecated) Asset Map
[1:39:56 PM] <END>   Building (deprecated) Asset Map (326ms)
[1:39:56 PM] <END>   Building Haste Map (905ms)
[1:39:56 PM] <END>   Building Dependency Graph (20907ms)

<--- Last few GCs --->

  157866 ms: Scavenge 1402.8 (1455.6) -> 1402.8 (1455.6) MB, 12.3 / 0 ms (+ 3.0
ms in 1 steps since last GC) [allocation failure] [incremental marking delaying
mark-sweep].
  159306 ms: Mark-sweep 1402.8 (1455.6) -> 1402.7 (1454.6) MB, 1440.1 / 0 ms (+
4.0 ms in 2 steps since start of marking, biggest step 3.0 ms) [last resort gc].
  160988 ms: Mark-sweep 1402.7 (1454.6) -> 1402.7 (1455.6) MB, 1681.5 / 0 ms [last resort gc].


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0000034B02A37349 <JS Object>
    1: join [path.js:~217] [pc=000002DAEE697E24] (this=0000026D39474171 <an Object with map 0000031DF7E23E19>)
    2: arguments adaptor frame: 3->0
    3: /* anonymous */(aka /* anonymous */) [c:\GitHub\AwesomeProject\node_modules\react-native\packager\react-packager\src\DependencyResolver\DependencyGraph\ResolutionRequest.js:~226] [pc=000002DAEEEC76DA] (this=0000034B02A04131 <undefined>,real...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory

I'm going to be tracking this all down and hopefully then pushing this work back to the react-native repo as a pull request.

Introduction to React

2015-07-09T14:48:00.000-04:00

A few months ago I was approached by my editor from Node.js Recipes to discuss the possiblity of writing another book. This coincided with a time where I had been spending time working with React for side projects, and it just so happened that the title which I would be writing is Introduction To React.

So I decided to write the book and spent the next 11 weeks writing it. I am currently finishing up the edits and the book is due to be published in September. I'll be sure to update as the publication date approaches.

dev.Objective()

2015-02-25T10:42:00.003-05:00

Every time I attend a conference or get bogged down following all the new tools and frameworks that are coming out in the front-end development world (which seems to happen daily) - I decide that I want to write a talk about how we as developers can optimize our front-ends without rewriting everything from scratch. I finally was able to get an abstract for a talk that will address such things written a month or so ago. I then decided to submit this talk to DevObjective, a conference happening in Minnesota in May. I feel that this talk might hit well with the audience as one of the things that stood out for me from the conference site was the following sentence:

Cutting edge stuff is awesome, but most people are more concerned about getting their jobs done now

I feel that this hits home with me, as I love to just be able to get my job done now. I'm not saying that we can't enjoy the advances made by new and modern frameworks, even if we are working on a years/or decades old project, but we can make smart choices to modernize our applications. Luckily my talk was accepted and I'll be speaking about "Front-end Modernization for Mortals" in May at Dev Objective.

I'm excited to be joining a group of speakers who will be discussing a wide variety of topics from which any developer should be able to gain some valuable knowledge for their daily jobs. If these sound like something you would be interested in, you should join me at the conference in May!

At the time of this writing, there is still time for the early bird pricing if you click the banner below:

Firefox Developer Edition

2014-11-04T16:24:00.003-05:00

In my most recent talk at jQuery Chicago, I spoke about the promising future of debugging that involved the Firefox Tools Adapter which is a brilliant step forward in the world of remote debugging.

This was under the radar until the day before my talk when it was announced on the Mozilla Hacks blog. So it suddenly became a bit more mainstream.

Yesterday Mozilla has teased a developer focused version of Firefox they have codenamed #fx10 in a theatrical-like trailer. I for one am excited to see what sort of product arrives with this new browser.

So it turns out that this Firefox Developer Edition will be a replacement for the current Aurora Channel. What it will bring is a separate profile so it can run alongside the stable version of Firefox without having to mess with custom profiles. It will have easy access to developer tools, and looks as though the Firefox Tools Adapter will be built in to the product directly. This is a great advancement for those looking to use the cutting edge developer tools from Firefox on the web

jQuery Mobile

2014-10-07T15:42:00.000-04:00

I have been fortunate enough to have the opportunity to speak at several jQuery Conferences in the past two years. The focus of most of my talks, and most of my day-to-day work actually, is based around building mobile web applications with jQuery Mobile and Cordova, two wonderful open source projects. During these conferences I was able to meet and get to know many new friends and fellow developers, including many of the folks on the jQuery team. Eventually, while in Vienna at jQuery Europe I was talking with Alex, the lead of jQuery Mobile and he suggested that I start contributing to the project.

I have been fortunate enough to have an employer who is generous enough to allow my some time to donate to the project and I have been contributing through bug-triage, pull requests, and generally just trying not to get in the way since March of this year. I have already learned a ton and am always encouraged by the support of the jQuery team and the advice they give.

Yesterday - 6 October 2014 - I was officially made a member of the jQuery Team. I am honored to have this opportunityand am excited to join the team of people whom I have come to know over the past two years. I am also pretty excited about the opportunity to continue to do what I have been doing all this year, just now I have access to the GitHub repositories.

Node.js Recipes Screencast Edition

2014-07-09T15:37:00.000-04:00

Last year, I wrote Node.js Recipes in a relatively short time span. It was accomplished in something like 120 days, or about 10 days per chapter. This was exhausting and I vowed to my wife that I would not write another book at that pace again.

Then I was tempted. My publisher asked me if I had interest in several titles, and man did I, but after a couple days of deliberating over each one - I could not commit to the time frame.

Then came an introduction from someone within the publisher’s organization that proposed I create a screencast series based upon the book which I had already written. This was something I could get on board with because the material was already written (right?).

So I created a sample video for evaluation and we decided to move forward with another aggressive schedule to record ~6 hours of screencast based upon material in my book.

It turns out this was a pretty agressive and time consuming undertaking as well. Sure the material was already written, but it needed to be reworked into a standard Powerpoint format and of course I would need to be coding most of the stuff I’d already written again. All of this (with the exception of creating some of the powerpoints) was a great time and I enjoyed being able to revisit my book from an angle of a user or reader, rather than an author.

In the end I recorded nearly 12 hours of raw footage for the video which is being post-processed currently and should see release in the near future (no official date that I know of yet - stay tuned for that). The team at Apress has done a fantastic job with the final editing and composition, from what I have seen and I look forward to everyone getting the opportunity to check out the finished product when it is available.

The Winter of jQuery

2014-04-08T11:37:00.001-04:00

This winter I was fortunate enough to be able to speak at two jQuery events - First in jQuery Conference in San Diego, then in Vienna for jQuery Europe. The traveling is always great, and these events were top notch as far as organization, content, and attendees.

While I always enjoy attending conferences, these two seemed to be extra engaging in that the attendees I talked with all brought a great deal of encouragement and excitement to continue to share what they know and learn.

I was also able to spend more time with a few of the folks I have met from the jQuery team and really see the vision of where some of the projects are headed. From this, I have even started to spend some time trying to triage and/or fix issues on the jQuery Mobile project.

In any case, here are the slides and video for my presentations about building $.Widgets for both UI and Mobile.

View this presentation on Blazon

Book Review: Principles of Object-Oriented JavaScript

2014-02-24T18:09:00.000-05:00

I just finished reading another fantastic resource for JavaScript developers "Principles of Object-Oriented JavaScript" written by Nicholas C. Zakas.

Nicholas C. Zakas is an excellent Front-End developer, and what I have always enjoyed about his work, is his ability to clearly articulate his knowledge to developers of all skill levels. Because of this I had high expectations for reading this book. I'm happy to say that this book did not disappoint.

The book, to me, is an reference I will keep with me throughout my JavaScript career, and I'll recommend it to any developer interested in JavaScript. Targeted toward JavaScript beginners, this book highlights areas that many who are new to JavaScript will likely have to learn the hard way, or discover after they have reached a level of frustration that makes them decide to hate JavaScript forever.

Now, this does not mean that this book contains some secret recipe to JavaScript Zen, but it does provide all the necessary tools for the reader (Seasoned JavaScripter or one who is new JS) to understand how to build great applications with JavaScript. The topics - functions, objects, prototypes, inheritance - are all covered thoroughly through well though out examples which are not too complex for even a new developer to follow. These examples and explanations are accompanied with wonderful notes and snippets that signal the voice of the seasoned JavaScript professional that Nicholas C. Zakas is. As I wrote above, I definitely recommend this book.

Node.js Recipes

2013-10-24T18:08:00.000-04:00

It started when I favorited a tweet in February in which a request was being made for some help updating a JavaScript book. I had recently spent some time contributing to a jQuery Mobile book and wanted to continue writing. Shortly after I contacted Louise (my editor) and it turns out that they had already found someone to update the book.....

It turns out that Louise had some plans for a Node.js Recipes book, which I thought would be spectacular so I set to work writing an outline and proposal for the book.

After a few weeks I had the proposal in hand, sent it to the publisher and it was approved. This is where things get crazy, because I now had to write the twelve chapters I'd outlined and I had less than two weeks to write each one if I was to make my deadline.

This crazy schedule, while good at keeping me on task, was not great at keeping me rested and stress free. There were many late nights and long weekends where I was not able to spend quality time with my family or friends. I am grateful that they allowed me time to research and write, because I was able to create a book which I feel will be a useful tool for any developer who wants to learn more about Node.js. It will give readers a glimpse of what goes on in Node.js not only in the Core, but also in the third-party modules that have helped to create the robust Node.js ecosystem.

If you are interested in getting to know Node.js better, or if you would just like to buy an amazing book for your coffee table or library, please buy the book.
http://www.amazon.com/Node-js-Recipes-A-Problem-Solution-Approach/dp/1430260580/
http://www.apress.com/9781430260585

FirefoxOS Apps

2013-09-23T18:05:00.000-04:00

A few weeks ago Mozilla announced another initiative to get some more applications into the FirefoxOS Marketplace.
I had submitted a simple compass application early on in the Marketplace's life, but thought that this opportunity would be perfect to get an PhoneGap wrapped HTML application that I created for Android onto the marketplace, so I applied for a phone for app port deal. Within a couple days I recieved confirmation that I would be getting a developer preview phone from Mozilla, in exchange for my app port.
Now, I could have waited around until I received the phone to get started working, but with the FirefoxOS simulator available as a Firefox Add-On I set to work right away. I had previously submitted an application so I knew the general Firefox manifest format which is probably helpful. Once I had a Firefox app manifest being served (with the proper MIME type) from AppEngine I was ready to submit. I did however wait until I had a physical device to test and ensure it appeared and functioned as I expected.

Busyness

2013-09-01T21:10:00.001-04:00

I have had a busy time over that last few months. Firstly, I have been engaged in a very ambitious and exciting project for my day job. Aside from this keeping me busy, I also had a talk accepted for the jQuery Conference in Portland in June. Conferences like the jQuery Conference are always welcoming to new speakers and the community as a whole is open to everyone's input. Experiencing a conference such as this is always a thrill. This was my first talk at a big conference but I think it went well and I hope to do it again.

If you listened to at least the beginning of that talk, you may have heard me mention that I’ve been writing a book. This book has been a great deal of fun, but has also been challenging. Between research, writing code, writing text, editing, and following up with the technical reviewer it has kept me busy. It should be published this fall so stay tuned…

Remote Debugging Revisited

2013-03-16T21:04:00.000-04:00

A little less than a year ago, I wrote a post about remote debugging tools. Since that time the landscape has changed, so this post will try update where we are in the world of remote debugging. (Note: by ‘we’, I mean me, and by ‘world’ I really mean, what I’ve used since last year) First, lets review where we were a year ago. Chrome for Android was brand new, and had remote debugging support baked in. Opera Dragonfly had great remote debugging support. Adobe Shadow (now Edge Inspect) was new, and WEINRE was still a .jar. Fast forward to now. Chrome for Android still has great remote debugging support, when connected you can see all your inspectable tabs from your remote device, and debug away. In Opera land, things have shifted a bit. Since they have started their switch to Webkit, who knows where their remote debugger will be in another year. Adobe Edge Inspect is a very popular debugging toolset for iOS and Android. Weinre is now (debatably) more accessible as a Node.js server, making it super easy to install and run a local/or remote hosted server. Weinre powers the phonegap debug service . It is also the service behind the experimental mobile debugging option at jsfiddle.net.
The newest version of jsbin.com has a pretty incredible remote rendering capability, but you can see for yourself on youtube:
Over the course of the last year, Firefox has built a homegrown set of Developer tools, so developers need not rely soley on Firebug on Firefox. These tools have been built with remote debugging as a high priority - with the proliferation of Firefox on Android, and the fancy new Firefox OS - remote debugging is important. Remote debugging for Firefox has been around for a few versions, but I really like to live on the nightly branch (currently 22.0a1), so thats what you’ll see here. Its quite simple to enable on your computer: just swing over to ‘about:config’ and toggle ‘devtools.debugger.remote-enabled’ to ‘true’ restart, and you are set. \

Next (assuming you’ve got your android platform-tools installed) you simply connect your device to your computer and

adb forward tcp:6000 tcp:6000

Then, assuming you have enabled remote debugging on your Android device, you again go to ‘about:config’ and toggle the ‘devtools.debugger.force-local’ to ‘false’ and ‘devtools.debugger.remote-enabled’ to ‘true’.

Restart. Debug. To Debug you open the remote console by selecting ‘Connect…’ from the Tools > Web Developer menu. Thats it. Remote debugging is important. And as the web development industry moves more toward mobile, these tools need to and will get better and more accessible for everyone. I expect I’ll be revisiting this topic again soon as tools improve or emerge.

Whitelisting URLs in PhoneGap

2013-01-14T10:00:00.001-05:00

I've built a couple of HTML5 (jQuery Mobile) applications that have also targeted native app stores using PhoneGap. When building these applications, it becomes clear that to get desired navigation in iOS, one must carefully consider the PhoneGap settings for url handling "OpenAllWhitelistURLsInWebView" and "ExternalHosts". In many configurations this results in setting the "OpenAllWhitelistURLsInWebView" to "YES" and Subsequently setting a single "ExternalHost" as "*" in order to keep your application functioning within the WebView exclusively. This is great for everything except where you wish to open an external link that would break your HTML5 applications navigation (due to a lack of back button). What follows are a few tricks I have picked up to help with whitelisting. In many cases you know when you're building your application where you'd like to have the external links open, in which case you can set these external links within your Objective-C source code letting the applicaiton know which links to open. This would look something like the following Gist (which looks to the prefix of the URL in order to open a link outside of the WebView): In other cases, your application may allow for some dynamic client created content to come from the server. This can mean either a maintenance nightmare for setting up this prefixed whitelist, where you get to update the whitelist and resubmit the app to Apple everytime the list changes (icky).... Or we can come up with a solution that works better. One way in which this can be accomplished is by looking to the suffix of the URL to find a querystring parameter that would indicate that we need to open external. A perhaps more robust solution, allow for the conversion of any link with target="_blank" to open in Safari. This solution is inspired by this where you tell your iOS app to find a specified document fragment, and also tell your web application to ensure that target="_blank" links always have such a fragment. The Obj-C code looks like this: and telling the webapp to set this fragment (using jQuery) looks as follows:

I read a book: JavaScript Enlightenment

2012-12-28T09:11:00.001-05:00

I dunno if this is a full fledged review or not, but I recently picked up and read the new book JavaScript Enlightenment by Cody Lindley, and I found it ranks in my list of JavaScript books I would direct others to read in their quest to JavaScript wizardry. Lindley states he writes his book first and foremost for himself, as a personal reference, which I find handy because that is exactly how I like to read JavaScript books. His approach to teaching the language might strike some as contrary to what is found in the wild - he spends plenty of time not using object literals when creating objects in order to hammer home the underlying principles of JavaScript objects - but he does also hammer home that using literal notation is preferred for its terseness and readability.

What else did I like about this book? Well I enjoyed the use of code examples, as its always good to see JavaScript in action. He also makes many great succinct notes that help make good distinctions such as "Remember: object instances created from constructor functions are just plain old objects". Another concept that those in search of JavaScript enlightenment should find well laid out in "JavaScript Enlightenment" is how the prototype chain is traversed whilst accessing a property on an object. Along with traversing the chain, Lindley describes through an example of what not to do, how prototypes can be altered even on the Object.prototype, promptly reminding the reader that this is a "forbidden" example. Since the prototype is key in JS, the book dedicates a considerable portion to describing and outlining how it all works.

The book describes in great detail and examples many concepts that any front-end engineer should be familiar with. Things such as the Function objects instance properties and methods - you know: arguments, constructor, length, apply(), call(), toString() - including going into specific examples on how to use arguments.callee when calling a function recursively. The discussion of JavaScript scope and closures is straightforward and to the point without over complicating concepts that are sometimes hard for some developers to grasp.

Other parts of this book I would describe as desk reference material. These are items that are common and I think are generally understood by many, but in the case someone runs into a gotcha during development, they may find it useful to hit the chapters on the various objects: Array(), String(), Number(), Boolean(), as well as then utilizing String, Number, and Boolean primitives. Other desk references: Math(), null, and undefined.

I'd totally recommend this book on the same JavaScript binge handed to new developers when the get underway (things like The Good Parts, Eloquent JavaScript, JavaScript Web Applications, or any of the many many useful links to the plethora of great resources available to the modern developer). I guess this did turn into a full fledged review.

Openness

2012-11-19T15:04:00.002-05:00

On 11 November 2012, my first patch to jQuery-UI landed in the project. It was not the world's greatest pull request, nor was it the best code ever written (by a long shot). But it was important. Not because I get my name on a change log somewhere, or that I will now conquer to world with my open source prowess. Its important because it is another tiny step in the massive open source snowball that wins. It wins big. The open web as we know it has spiraled out of openness and open source projects. The documentation that I turn to regularly and have contributed to is open and invites new contributors each day. There are countless open initiatives in the world these days - and by no means are these all software related - these encourage the scientist in us all to submit pull requests, change direction and assert for the greater good. If you have a passion, pursue it. That is all.

Homework

2012-11-07T14:05:00.000-05:00

Recently I was tasked by my son's pre-k teacher to present a paragraph that describes my occupation... in a way that 4 year olds will understand. This really put things into perspective for me, more than I thought it would. At first I think of what I might describe to my parents: "Software Engineer: I write code for web applications and databases"... No. So what is it that I do?

I was then reminded of an interview question I once had where I was asked: "How would you describe a database to your grandmother?" These sorts of questions may seem silly to some developers, but I find them to be a great exercise. These questions help us to target and focus on what it is we really do, and how our end users or clients might perceive what someone in the software profession might be thinking. So I thought of the answer provided in that interview where I made the analogy of a jewelry box that helps to organize and sort jewelry for efficient placement and retrieval.

How does a jewelry box translate to pre kindergarten children? Well I tried to avoid an abstract analogy and simplified it by stating that I teach computers to do neat things and give us information when we ask them for it by typing or clicking the mouse.... Our children don't care about CSS, HTML5, JavaScript, objective-C, C++, Java, Ruby, Python, C#, or if we built our app for Android, iOS, Windows Phone 8 or whatever,
they care if they can learn from and enjoy whatever it is we built.

So a fresh perspective of "how can this actually benefit someone" has been bouncing in my head lately. I'm not saying one shouldn't try new cool tech... Still create experiments and things that push development forward, but perhaps a deeper look at what is truly needed should be a priority.

TypeScript

2012-10-03T16:15:00.001-04:00

This week Microsoft released its shiny new JavaScript pre-processor - TypeScript. It represents a superset of JavaScript that is designed for large-scale application development. It utilizes concepts that most developers are comfortable with in their non JavaScript languages. Things like Classes, Modules, and Type checking.

These are all things that many people complain that JavaScript does not have built in. With TypeScript, JavaScript does not magically gain these things. TypeScript makes these things accessible to a developer through its pre processing. Developers and JavaScript do not need TypeScript, and it is not a requirement to build large scale applications. It won't magically make crappy programming better, but it may help catch a gotcha for someone every now and again, just as JSHint would. I for one think that it will take off rather well, especially in the ASP.Net community. I also will probably try it out in a project or two or three. I like that it looks and feels like JavaScript, which is a syntax that I am comfortable with. That is one reason why I have not adopted CoffeeScript, it just looks so foreign to me. I suppose if I were a full time Ruby on Rails developer, CoffeeScript would feel right, but I'm not, so it doesn't.

I'm going to end this by just showing the difference between TypeScript and JavaScript. It is subtle and that is appealing to me. See the comparisons below:
typescript javascript

Liberated Pixel Cup

2012-08-01T12:02:00.000-04:00

July marked the beginning of the coding portion of the Liberated Pixel Cup which is an amazing two-part competition that involves amazing artists creating open game assets during part one (June) which developers then take to create a game based on those assets (July). I first heard about the Liberated Pixel Cup a few weeks into the second part of the competition. After a day or two of contemplating if I could get a game off the ground in time, decided to make an HTML5 game. Other than my orientation demo Catch and the node.js interpretation of the card game Wizard, I had not made (or at least published) what I would consider a graphics based, animated, HTML5 game. I decided to take this opportunity to dive in head first.
Over the last few years, I have seen quite a few HTML5 game engines come around and have taken note of many, experimented with some. The big name in the HTML5 engine space right now seems to be ImpactJS which I have yet to use, but of the ones with which I have experimented,cocos2dx-html and melonJS, I chose melonJS. I decided that to get an RPG style game with the assests provided in the competition playable in the limited development time that I had, melonJS fit that need perfectly. So now I can kill two birds with one stone, get an HTML5 game built and get more familiar with one of the HTML5 engines I have been eyeing for some time.
So I spent my evenings and weekends for the last couple weeks doing quite a bit of hacking. First I had to familiarize myself with making some tilemaps for the different world areas within the game that I wanted to create, figure out how that tied in with the melonJS framework that I was trying to learn, and create a simple story in the game which could be completed before interest is lost. Creating the tilemaps was easy, and the way in which melonJS incorporates them into the game is slick and effective. A couple things which weren’t clear from the melonJS documentation were 1) dynamically adding projectiles or arbitrary objects (such as the magic in my game) to the screen, and 2) how to get the level transitions to behave how I wanted. The first was pretty simple in the end, all I needed to do was check if my player had the magic, check direction, create & align, add it and make sure it displays on the scene:

Loading ....

The other major hurdle I faced was the scenes when jumping from one map to another would sometimes immediately jump to a completely different map. This seemed like a bug and was so inconsistent I nearly scrapped the whole project, but as it turns out, a few of my enemies were walking their boundaries to the point where the level transitions began, triggering a random map change as if it were the main player. So that was a quick fix (once I figured it out). I do hope to add some more fun to it as time goes on, and welcome any contributors to expanding it to whatever it becomes. So go ahead and Fork it.
I cannot thank the other contributors to the competition enough, they are a cheery bunch on IRC who have donated time and talent to a really cool open game competition.
So now you know a bit of the backstory that led up to Pixel Quest, my HTML5 entry in the 2012 Liberated Pixel Cup.

Wizard

2012-07-11T19:47:00.000-04:00

Months ago I set out to create a nodejs based app for one of our office favorite games - Wizard (the ultimate game of trump). I started the project by myself, but after I got it to the point where I thought it could really become something I enlisted the help of a friend to help contribute to really speed up the development. Things went well and we reached the point somewhere around SXSW 2012 where it became playable and testable, though admittedly it is still in a fairly unstable state. We had privately hosted it on Bitbucket and collaborated through there, but I decided today that we are going to unleash it as a public repo on Github. So there it is. You can create your own instance of it and test and contribute (pull requests, issues, etc) as much as you like. If you just want to see it in action, you can view the latest stable build that I have hosted with nodejitsu currently at http://wiz.jit.su.

Remote Debugging Tools

2012-05-06T18:53:00.000-04:00

Recently I have been working on some mobile content for a couple of my personal projects. And since working on the front-end of these projects involves spending some quality time with developer tools, I have also been spending some quality time utilizing a few different remote debugging tools. In the last few years the remote debugging tool category of software has grown rapidly which makes deciding on the best tool, somewhat similar to finding your favorite dev tools setup in your browser of choice. Just as some folks prefer debugging their front-end with Firebug, Opera Dragonfly, or Chrome Developer Tools (WebKit Inspector), there is now a similarly robust selection for remote debugging for mobile devices.

Built by Remy Sharp, JsConsole.com is perhaps the simplest and most accessible tool for remote debugging. Simply include the remote.js file in your html,

<script src="http://jsconsole.com/remote.js?IDENTIFIER"></script>

navigate to jsconsole.com, “:listen”, and you now have access to your remote device. Works splendedly, but doesn’t have all the bells and wistles that come along with the advancing browser dev tools. I use this tool a ton for remote debugging work, especially since it works across browsers on my mobile device. Another tool that I have utilized and is quite popular due to its association with PhoneGap, is Weinre or WebKit Inspector Remote. With this you simply run a server locally that will allow you to debug remotely utilizing a set of the WebKit Inspector toolset (Google Chrome, Safari) - provided you supply a target.js script in your source. Again this is not a full set of the tools which are normally available to a Chrome Dev Tools, Firebug, Dragonfly user, but is quite adequate and useful on multiple target browsers. I rarely utilize Weinre, but many developers find it a critical part of their workflow.

Opera Dragonfly has a great remote debugging experience baked into their tools. One simply tells Opera Desktop to initiate a remote listening session, then Opera Mobile “opera:debug”, and you can inspect your remote page in Dragonfly. Honestly, I have limited experience here, because I rarely utilize Dragonfly, even though the tools are quite robust.

So what is my go to remote debugging tool today? Chrome. I am most comfortable with the Chrome Dev Tools in all my other debugging for a number of reasons including the continuous insertion of handy new features. So once I upgraded my phone to Android 4 (Ice Cream Sandwich) - which is required to utilize Chrome For Android - I have been happily utilizing the full suite of Developer Tools in Chrome to inspect my mobile app on my Android device. Again, the best solution for me because I can utilize the same toolset for desktop or mobile debugging. Its pretty simple to setup, just get your Android device set up for usb debugging in both the Android settings and Chrome settings, then (via the Android SDK) setup a debug bridge that will forward your console to a port of your choosing allowing you to open localhost:9222 which shows all your tabs open on your phone, ready for inspection. Start listening on that port using a script like this in your terminal:

adb forward tcp:9222 localabstract:chrome_devtools_remote

Rather than go through my terminal command history to find the command and possibly change the port, I aliased the command in my .bashrc file so anytime I hook up my phone I can type cremote 9222 in the terminal and inspect away

function cremote() {
    adb forward tcp:$@ localabstract:chrome_devtools_remote
}

From there its on to your browser to find and inspect away to your hearts content. This remote debugging space is growing quickly, the upcoming version of many toolset have this capability built in directly, things like jsBin (v3), jsfiddle, Firefox dev tools, Adobe Shadow, Trigger.io’s remote inspector, and many others I’m sure are all available, or will be available to utilize as a remote debugger. So the developer wins in the end with a host of choices to choose from so they can find that which fits their needs and workflow.

DeviceOrientation Events

2012-01-27T18:52:00.000-05:00

The Mozilla Dev Derby is a pretty cool thing. Developers from around the world can openly add any demo to the site, and if their demo lines up with the prescribed derby for the month, they are automatically entered to win a prize (t-shirt, cool bag, android device). I decided I would enter again for the January 2012 derby based on Orientation. I made two demos.

catch

The first one called “Catch” which you are attempting to catch a randomly generated ball in the shortest amount of time possible. I have personally found it incredibly addicting to get the perfect game, or at least my best attempt at it and I even wrote the source code. What I learned in developing this app was a couple of things. One, there isn’t a ton of documentation on the web about the DeviceOrientationEvent. Two, its pretty straightforward to detect the orientation and utilize it to move an object. Here is the basic of my app:

 /*orientation stuffs*/
var initOrientation = function() {
    var count = 0, gam = 0, bet = 0;
    if (window.DeviceOrientationEvent) {
        window.addEventListener("deviceorientation", function(e) {
            //gamma = left to right
            //beta = front back
            //alpha = compass dir
            count = count + 1;
            gam += e.gamma;
            bet += e.beta;

            if (count === 0 || count % 10 === 0) {
                orientationYo(gam, bet);
                gam = 0;
                bet = 0;
            }
        }, false);
    }
};

//handle orientation
var orientationYo = function(ltr, ftb) {
    coor.x = coor.x + ltr;
    coor.y = coor.y + ftb;
    if (!gameState.victory && gameState.playing) {
        tgt.move(coor);   
    }
};

so that handles the detection of the orientation event, next I simply added the move call to my target (tgt) which looks like this:

var tgt = {
    isDrawing: false,
    collided: false,
    start: function(coordinates) {
        this.drawIt(coordinates);
        this.isDrawing = true;
    },
    drawIt: function (coordinates) {
        ctx.clearRect(0, 0, canvasWidth, canvasHeight);
        ctx.fillStyle = b2_color;
        ctx.beginPath();
        ctx.arc(coordinates.x, coordinates.y, 25, 0, Math.PI * 2, true);
        ctx.fill();
    },
    move: function(coordinates) {
        if (this.isDrawing) {
          this.checkBounds(coordinates);
          this.drawIt(coordinates);
        }
    },
    finish: function(coordinates) {
        this.isDrawing = false;
        ctx.lineTo(coordinates.x, coordinates.y);
        ctx.stroke();
        ctx.closePath();                
    },
    checkBounds: function(coordinates) {
         if (coordinates.y > bound.y2) {
            coordinates.y = bound.y2;
          } else if (coordinates.y < bound.y1) {
            coordinates.y = bound.y1;
          } else if (coordinates.x > bound.x2) {
            coordinates.x = bound.x2;
          } else if (coordinates.x < bound.x1) {
            coordinates.x = bound.x1;
          }
    }
};

collision detection is handled by my randomly placed bouncing ball, which detects when the target ball moves into its path:

checkObjectCollisions: function() {
    var imgData = ctx.getImageData(this.position.x + this.velocity.x1, this.position.y + this.velocity.x2, r, r),
        pix = imgData.data;
    for (i = 0, n = pix.length; i < n; i += 4) {
        if (pix[i] !== 0) {
            this.collided = true;
            if (Math.abs(this.velocity.x1) > Math.abs(this.velocity.x2)){
                this.velocity.x1 = -this.velocity.x1 * drag;
            } else {
                this.velocity.x2 = -this.velocity.x2 * drag;
            }
            break;
        } else {
            this.collided = false;
        }
    }
}

I am pretty happy with the game, its clean and works nicely. You can check it out here

compass

The other is a simple web compass where I utilize the DeviceOrientationEvent to get the cardinal direction your phone or device is facing. There are two cool (in my opinion) things that happened here. One is that to me it seems the device orientation event as defined states that the DeviceOrientationEvent.alpha ranges from 0 to 360 which to me is a 361 degree circle. The second is that I was able to utilize the offline caching capabilities of the modern web to make the compass available to a device event when not connected to the internet. This is done in minimal lines of code. The HTML and JavaScript are as follows:

<!-- This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this file,
You can obtain one at http://mozilla.org/MPL/2.0/.  -->

<!DOCTYPE html>
<html manifest="compass.appcache">
<head>
<meta charset=utf-8 />
<title>Cardinal Direction Compass</title>
<style>
  .pointer {
    height: 0;
    width: 0;
    border-left: 3em solid transparent;
    border-right: 3em solid transparent;
    border-bottom: 12em solid black;
    margin: -10px 0 0 -40px;
    top: 40%;
    left: 50%;
    position: absolute;
  }
  .n {
    top: 20%;
    left:50%;
    position:absolute;
    font:8em Helvetica;
    margin: 0 0 0 -40px;
  }
  </style>
  <script src="js/jquery.js"></script>
</head>
<body>
  <div class="n">N<br><br><br><br>S</div>
  <div class="pointer"></div>
<script>
        $(document).ready(function() {

          var rotate = function (deg) {  
              $(".n").css({ "-moz-transform": "rotate(0deg)"});
              $(".n").css({ "-moz-transform": "rotate(" + deg + "deg)"});

              $(".n").css({ "-o-transform": "rotate(0deg)"});
              $(".n").css({ "-o-transform": "rotate(" + deg + "deg)"});

              $(".n").css({ "-ms-transform": "rotate(0deg)"});
              $(".n").css({ "-ms-transform": "rotate(" + deg + "deg)"});

              $(".n").css({ "-webkit-transform": "rotate(0deg)"});
              $(".n").css({ "-webkit-transform": "rotate(" + deg + "deg)"});

              $(".n").css({ "transform": "rotate(0deg)"});
              $(".n").css({ "transform": "rotate(" + deg + "deg)"});
          };
          if (window.DeviceOrientationEvent) {
            window.addEventListener("deviceorientation", function (e) {
              rotate(360 - e.alpha);
            }, false);
          }

        });
        </script>
  </body>
</html>

The final point I’d like to make is that due to what I thought was minimal documentation, I participated in a Mozilla Doc Sprint last weekend to update the Documentation surrounding the DeviceOrientationEvent. Doing my part in the web development community was both rewarding and a learning experience. I encourage anyone to try it out as well.

$.widget

2012-01-07T18:50:00.000-05:00

I have lately been looking to become more involed with open source projects and for starters I have been looking at jQuery UI and jQuery Mobile. Both are amazing projects and share many of the same characteristics in their code. This is because in both cases, the majority of the functionality is inherited from the jQuery UI widget factory. If I’m going to become involved in this project I should understand how this works, so the following is my breakdown of the code as I understand it.

The widget factory looks like the following:

$.widget = function( name, base, prototype ) {
    var namespace = name.split( "." )[ 0 ],
        fullName;
    name = name.split( "." )[ 1 ];
    fullName = namespace + "-" + name;

    if ( !prototype ) {
        prototype = base;
        base = $.Widget;
    }

    // create selector for plugin
    $.expr[ ":" ][ fullName ] = function( elem ) {
        return !!$.data( elem, name );
    };

    /* OTHER STUFF */
}

I’ll get to the stuff in a second, but lets see what we’ve already learned here. First I see that widget can take up to three arguments (name, base, prototype), and example might be something like

$.widget("cg.awesomewidget, "ui.button", { /*...*/})

here name or “cg.awesomewidget” becomes the namespace and fullname so in my example I have namespaced it to “cg” with a fullname of “cg-awesomewidget”. I also see that we check if prototype is provided, if it is not we assume that we are not inheriting from a named widget, set the base parameter to prototype and set the base to the main $.Widget base object. Okay that sounds more messy than it is. Lets try to rephrase. The base is an optional parameter telling the widget factory we want to inherit from a known widget. In my example above its “ui.button”. If that parameter is not provided it simply pulls from the base $.Widget. So we know that any widget will carry the prototype base of $.Widget for starters. Now, what about this prototype? This is the base object literal that the widget makes its prototype. Sweet right? The next fun fact is that our widget gets its very own shiny new custom selector $(“:cg-awesomewidget”).

Next the object is constructed via the jQuery.extend() method as follows:

$[ namespace ] = $[ namespace ] || {};
// create the constructor using $.extend() so we can carry over any
// static properties stored on the existing constructor (if there is one)
$[ namespace ][ name ] = $.extend( function( options, element ) {
    // allow instantiation without "new" keyword
    if ( !this._createWidget ) {
        return new $[ namespace ][ name ]( options, element );
    }

    // allow instantiation without initializing for simple inheritance
    // must use "new" keyword (the code above always passes args)
    if ( arguments.length ) {
        this._createWidget( options, element );
    }
}, $[ namespace ][ name ], { version: prototype.version } );

here the $[ namespace ][ name ] object is merged together with the prototype.version into the existing constructor as described in the comments. Then the options are passed along to the base. Again this is done via jQuery extend.

var basePrototype = new base();
// we need to make the options hash a property directly on the new instance
// otherwise we'll modify the options hash on the prototype that we're
// inheriting from
basePrototype.options = $.widget.extend( {}, basePrototype.options );

This is followed up with a call to $.each() that checks all the functions of the base and applies those to our new widget.

$.each( prototype, function( prop, value ) {
    if ( $.isFunction( value ) ) {
        prototype[ prop ] = (function() {
            var _super = function() {
                return base.prototype[ prop ].apply( this, arguments );
            };
            var _superApply = function( args ) {
                return base.prototype[ prop ].apply( this, args );
            };
            return function() {
                var __super = this._super,
                    __superApply = this._superApply,
                    returnValue;

                this._super = _super;
                this._superApply = _superApply;

                returnValue = value.apply( this, arguments );

                this._super = __super;
                this._superApply = __superApply;

                return returnValue;
            };
        }());
    }
});

After all of this its time to put it all together. The widget prototype is now set via extend where we extend our basePrototype (widget) merging in the new widget and prototype. The last thing needed is a call to $.widget.bridge() which creates an instance of the object.

$[ namespace ][ name ].prototype = $.widget.extend( basePrototype, {
    namespace: namespace,
    widgetName: name,
    widgetEventPrefix: name,
    widgetBaseClass: fullName
}, prototype );

$.widget.bridge( name, $[ namespace ][ name ] );

That concludes our walkthrough of the jQuery UI widget factory. Fairly amazing when you look at how simple it is to create a widget based on this. A simple example is a look at jquery.ui.tooltip.js

Collision Detection on Canvas

2011-12-28T18:48:00.000-05:00

I was toying around with a bouncing ball on an HTML canvas the other day when I wanted to find an easy way to detect collisions. One thing that is easy is validating against the bounds of the canvas. This is done with a simple check on the bounds of the canvas as follows:

//this is a Ball object
if (this.position.y > bound.y2) {
    this.velocity.x2 = -this.velocity.x2 * drag;
    this.position.y = bound.y2;
} else if (this.position.y < bound.y1) {
    this.velocity.x2 = -this.velocity.x2 * drag;
    this.position.y = bound.y1;
}
if (this.position.x < bound.x1) {
    this.velocity.x1 = -this.velocity.x1 * drag;
    this.position.x = bound.x1;
} else {
    if (this.position.x > bound.x2) {
        this.velocity.x1 = -this.velocity.x1 * drag;
        this.position.x = bound.x2;
    }
}

You’ll see that if we get the Ball beyond the bounds of either axis we reverse the velocity vector (and for my example) I augment that vector with some drag. Then I start the Ball off (headed the other direction now) from the start of the boundary. This is straight forward and not too difficult to come up with. The same can be done for other shapes on the canvas which we do not wish for the ball to pass through. These again can be simple if we know the layout and the position of the target walls (think floating boxes). Where this gets to a point where the shapes are not at right angles or the boundaries have become more arbitrary, I no longer want to calculate each possible collision point. I also do not wish to wrap the object into a larger boundary box to utilize for detection. So a more elegant solution can be found. If we, just before moving the ball, simulate the move and have another means for detection we can then change the trajectory of the object and send it sailing away. Here’s what we need. we need a ball sized snapshot of the canvas where we plan to put the ball on the next move. We then iterate through those pixels on the image and find ones that arent the color of our background (in my case non-white). To do this without also seeing the ball as a collided upon object, I’ll clear the canvas of the ball first. Here is the code:

//clear canvas, add shape
context.clearRect(0, 0, canvasWidth, canvasHeight);

context.fillStyle = "rgb(150,150,150)"; //not white
context.beginPath();
context.moveTo(200, 100);
context.lineTo(300, 125);
context.lineTo(250, 175);
context.lineTo(200, 200);
context.lineTo(200, 100);
context.fill();
context.closePath();

//now we check our next move for collision
var imgData = context.getImageData(this.position.x + this.velocity.x1, this.position.y + this.velocity.x2, r, r);
var pix = imgData.data;
for (var i = 0; n = pix.length, i < n; i += 4) {
    //check if we're not on a white pixel
    if (pix[i] != 0) { 
        this.collided = true; 
        //bounce away
        if (Math.abs(this.velocity.x1) > Math.abs(this.velocity.x2)){
            this.velocity.x1 = -this.velocity.x1 * drag;
        } else {
            this.velocity.x2 = -this.velocity.x2 * drag;
        }
        break;
    } else {
        this.collided = false;
    }

}

Thats it! Now we can throw our ball at a target. The demo I have is located at this jsFiddle.