Raymond Camden's Blog - JavaScript

More on my JavaScriptCookbook Node project

Fri, 14 Jun 2013 11:27:00 -0400

Over the past couple of days I've made more progress on the Node project I started. If you haven't read the first article, click that previous link for the background. Here's what I've been able to do since my first post.

GitHub

I mentioned this in the comments, but if you want to look at, and criticize, my Node code, you can do so at GitHub: https://github.com/cfjedimaster/javascriptcookbook. Everything is in there except for the JSON file that I used to store authentication information for the admin panel and my Gmail integration (more on that in a minute). As I think I say every time, I'm still a Node/Express noob, so I wouldn't consider this to be good code, but the site is complete for now.

Email

I used the excellent Nodemailer module to set up email support for my application. All I needed was the ability to send an email to myself and this worked fine. Here's a code snippet from my app.js showing this in action. The only oddity I ran into was that even though I set the From to be your name and email address, when it shows up in Gmail it is always my email address. I'm assuming that is a Gmail security thing. If anyone knows better, let me know. Since I include the sender's email address anyway this isn't a deal breaker for me.

MongoDB

I tell ya what. I never want to write SQL again. This isn't the first time I used Mongo but my god - what a pleasure. Here are a few examples. I think that $or search is the one I like the most.

Templating

I hate the Jade templating system and EJS is ok, but my favorite templating system is Handlebars. The HBS module gives me access to that inside my views. I can even extend it with my own utility functions. Here is one sample view:

Commenting

Yeah, Disqus. Done.

Hosting

I love AppFog. How much do I love AppFog? AppFog is this: Let me describe what their process was like for me.

I signed up.
I made a new app.
I clicked about 2 buttons to add Mongo support.
I installed the command line tool via npm.
I typed "af update javascriptcookbook"

That's it. I was done. Period. And it worked! Now it turns out I was supposed to modify one line: app.listen(3000) needed to change to app.listen(process.env.VCAP_APP_PORT || 3000). But even before I did that it worked. Heck, I didn't even have to tweak Mongo. So now my process is - I make some changes - I commit to GitHub - I push up to AppFog. The update process for AppFog takes about 20 seconds. I'm so happy with them that I'm going to go ahead and take the plunge and spend the 20 bucks a month. (Although I'll probably end up putting an AdSense ad on the site to help pay for it.) Want to give it a whirl? Check it out here: http://javascriptcookbook.aws.af.cm. I am definitely looking for some submissions now and would love someone to make a favicon if they feel so inclined. ;)

IndexedDB and Date Example

Thu, 06 Jun 2013 09:33:00 -0400

About an hour ago I gave a presentation on IndexedDB. One of the attendees asked about dates and being able to filter based on a date range. I told him that my assumption was that you would need to convert the dates into numbers and use a number-based range. Turns out I was wrong. Here is an example.I began by creating an objectstore that used an index on the created field. Since our intent is to search via a date field, I decided "created" would be a good name. I also named my objectstore as "data". Boring, but it works. Next - I built a simple way to seed data. I based on a button click event to add 10 objects. Each object will have one property, created, and the date object will be based on a random date from now till 7 days in the future. Note that since IndexedDB calls are asynchronous, my code should handle updating the user to let them know when the operation is done. Since this is just a quick demo though, and since that add operation will complete incredibly fast, I decided to not worry about it. So at this point we'd have an application that lets us add data containing a created property with a valid JavaScript date. Note I didn't change it to milliseconds. I just passed it in as is. For the final portion I added two date fields on my page. In Chrome this is rendered nicely: Based on these, I can then create an IndexedDB range of either bounds, lowerBounds, or upperBounds. I.e., give me crap either after a date, before a date, or inside a date range. The only conversion required here was to take the user input and turn it into "real" date objects. Once done, everything works great: You can run the full demo below.

Two more MAX Videos: Cutting-Edge HTML and Debugging Your Web Apps

Fri, 31 May 2013 08:12:00 -0400

The Adobe TV folks got my last two MAX sessions online. As always, any feedback, suggestions, or questions are welcome. Enjoy the silky smooth sound of my voice...

Using the Page Visibility API with Edge Animate

Wed, 29 May 2013 08:38:00 -0400

Yesterday I blogged about the Page Visibility API. In that entry I talked about how the API works and how it can be used. Today I thought I'd demonstrate another example of this API. Imagine you have an Edge Animate animation that runs in a loop. It would be cool if you could use the Page Visibility API to pause the animation when the browser tab isn't being displayed. Here is how I solved this.First off, I have to admit that I did not know how to create a looping EA animation. This blog entry explained it well: How to Create a Loop in Adobe Edge Animate. Essentially you create a trigger at the end of your animation that causes the whole thing to start over. Simple and effective. I then put all of my design skills to use to create the following: Epic, right? The next part was rather simple. (Again, the assumption here is that you read the last post.) In Edge Animate I created a creationComplete event and then used the following code. This is basically the same code as shown in the previous entry, but now it makes use of the EA APIs to stop and play the animation.

Using the Page Visibility API

Tue, 28 May 2013 08:41:00 -0400

A few weeks ago at MAX I had the pleasure of giving half a presentation with Greg Wilson on "Cutting Edge HTML". One of the APIs I demonstrated to the audience was the Page Visibility API. As you can probably guess, this is a basic API to let you know if your page is visible to the end user. It doesn't have complete support yet, but it is (yet again) another great example of something you can add to your code with relative ease to enhance the experience for your end users.So how well is it supported? The embed below comes from the excellent CanIUse and will be up to date no matter when you are reading this blog entry: I think you could summarize this as "good desktop support, poor mobile". That being said, the API is simple to use and doesn't cause any harm to your code if the end user's browser doesn't support it. Let's consider a simple example. In the script below, I've got an AJAX call being run every (approximately) 2 seconds to fetch a news feed from the server. I assume the code above is trivial enough to not really need any explanation, but if I'm wrong, just let me know in the comments. Now let's look at an updated version making use of the API. Let's tackle this bit by bit. First, note the use of the event handler in the document.ready block. The Page Visibility events are still prefixed so I built in support for the unprefixed, Chrome, and Mozilla versions. (Remember that IE supports this so in theory, I could add in the IE prefix too if necessary. I'd love it if someone could check to see if IE has this prefixed or not.) Speaking of prefixes, I built a function, isVisible, that wraps the checks to the document.hidden property. This is the main way we can tell if our document is visible. What about the active variable? Since we're dealing with AJAX calls and asynchronous crap, we've got a delicate situation. We may, or may not, have an ongoing AJAX call being fired when visibility changes. If we've gone from hidden to visible, but we had an existing AJAX call already, we don't want to fire one now. If we do have one active, the callback handler will handle scheduling the next call. In this way we ensure that we don't double up our AJAX calls or forget to start the process again. Be sure to check the specification I linked to above. They have an interesting demo as well. Instead of stopping their AJAX calls they simply slow them down. I can see both ways of handling this being effective. You can demo this here: http://raymondcamden.com/demos/2013/may/28/crap.html. If you want, you can also demo the pre-Page Visibility version here: http://raymondcamden.com/demos/2013/may/28/pre_crap.html Pardon the file names. I'm not sure what I was thinking there. There is only one real drawback to this API that I can think of. According to the specification, the browser should report as hidden when minimized. In my testing, this was not true. In fact, it doesn't report as hidden if you put another application in front. It only reported hidden when I switched to another tab. Again though, I figure this is better than nothing and the additional code (10 lines?) is trivial enough to make it worth your time. EDIT: FYI, Firefox does notice it when you minimize the application. Way to go, Firefox. Later today (most likely tonight, I've got a big presentation this afternoon), I'm going to show another example of this using Edge Animate.

Review: Instant Wijmo Widgets How-To

Mon, 27 May 2013 05:41:00 -0400

I've not looked at Wijmo in some time, so when offered the chance to review a book on it, I thought it would be a great chance to reacquaint myself. Wijmo is a UI library of 40+ controls that are extended from the core functionality provided by jQuery UI. Wijmo is not free, but seems fairly priced for its size. I've not honestly used Wijmo in a production environment yet, but it looks great, and it was my hope that the book would give me a feel for whether or not I'd actually use it. "Instant Wijmo Widgets How-To" was written by Tochi Eke-Okoro. It clocks in at only 82 pages, which is slim, but I have no problem with that. I would imagine that a UI library probably doesn't need a huge book. I kind of like the idea of shorter, more focused e-books when it comes to technology. You should know, however, that with the front-matter being near 20 pages, you are looking at an approximately 60 page-length book. Given that size, and given that Wijmo has 40+ controls, I'd expect the book to cover the basics of how Wijmo controls work in general followed by a deeper dive into maybe 5-10 controls. I'd also expect some good real world scenarios. (If you read some of my earlier reviews you know that's kind of an important thing to me.) However, this book does not do that at all. You are dropped immediately into discussion of one of the controls (the bar chart) with no real context of how Wijmo works. That may not be entirely fair. The book does list the dependancies, but for example, it lists a Wijmo Complete CDN and a Wijmo Open CDN. I can guess as to what the "Complete" file is. But the "Open" file? No idea. Nor does the book ever make an attempt to explain it. I suppose I could get that from the main Wijmo site, but I'd expect the book to tell me that. The meat of the book is a look at various controls (7 of them) and a bit of how Wijmo handles data sources. For each control listed, you have a huge block of code followed by a screen shot and a very short description of what the code does. That's it. Honestly it feels like what I'd expect from the Wijmo docs and no more. There's never a discussion of how to use the controls in a real app (for example, combining them with a real form). The datasource portion was the only interesting aspect to me, but unfortunately, it was not fleshed out enough to make sense to me. I'll put some of that blame on me though and am planning on rereading that section to see if it makes more sense on a second reading. I did appreciate the fact that the author describes how to use Wijmo with Knockout. Knockout is a JavaScript MVVM framework that I think is pretty cool. If I hadn't recently gotten over my Backbone issues it would be my framework of choice. Seeing Wijmo in use with one framework though gives me an idea of how I'd apply it elsewhere. Overall, I can't recommend this book. I can say it did convince me that Wijmo is a good UI framework and definitely worth my consideration in the future, but I'd rely on their own docs instead of this book.

Infinite Scroll Example with ColdFusion

Tue, 21 May 2013 14:34:00 -0400

A few weeks ago a reader asked if I had an example of infinite scroll with a ColdFusion back end. I replied that I did not, and that infinite scroll was the worst thing to happen to the Internet since the rainbow horizontal rule. I'm possibly being a bit overly dramatic, but I'm really not a fan of it. Maybe it's the OCD in me, but the fact that I can never get to the end of an infinite scroll UI just bugs the hell out of me. That being said - I figured - why not make a quick example. It can't hurt, right?I did some Googling on the topic. Initially the results I found were not very helpful. Many required a bit of configuration and I was really looking for something quick and simple. Finally I came across this great answer on Stack Overflow: 4 simple lines. Nice! So I took this and ran with it. I first created a fake service in a ColdFusion component that would return an infinite amount of data. Not exactly real world, but it worked. Note that I added a bit of a delay to the code so that my local testing would feel a bit more realistic. The code here is pretty arbitrary. I return an array of structures containing a title and a body. I accept a start parameter, but I don't really even use it. Again, the entire purpose for this was to just send me a lot of data. Now let's look at the front-end code. A bit more than 4 lines, but hopefully you will see that I've simply taken the logic from the Stack Overflow answer and wrapped it around a call to a function called loadContent. loadContent handles several things.

First, it is intelligent enough to recognize when it is fetching data and prevent you from making multiple XHR requests at once.
Secondly, it handles updating the DOM with a loading message so you know important crap is on the way.
It does the XHR call and handles rendering it out. (Insert reminder about using JavaScript templates here.)
Finally it removes the loading message.

Overall, pretty simple. You can demo this here: http://www.raymondcamden.com/demos/2013/may/21/test.html. If it seems slow, remember that I kept in that sleep() command there. I built a second demo that makes use of my actual blog database. For the most part it is the same, but note the use of a Query and limit operations to page the data. You can demo this version here: http://www.raymondcamden.com/demos/2013/may/21/test2.html In my testing this downloaded pretty quick (and I'm on VPN now downloading 2 gigs of VMs). There are two things missing from this version. One - I need to enable my front-end service to recognize when it is no longer getting rows of data from the back end. I could handle that with a flag in the result object or some other way. Second - If I were to add links to the actual blog entries, I'd need to support some way of remembering where you were when you hit the back button. If folks care, I'll do some updates to add that.

Capturing camera/picture data without PhoneGap

Mon, 20 May 2013 10:31:00 -0400

As people know, I'm a huge fan of PhoneGap and what it allows me to do with JavaScript, HTML, and CSS. But I think it is crucial to remember that you don't always need PhoneGap. A great example of that is camera access. Did you know that recent mobile browsers support accessing the camera directly from HTML and JavaScript? Let's look at an example.Over a year ago I wrote a blog post in which I created an application called "Color Thief." This application made use of PhoneGap's Camera API and a third party JavaScript library called Color Thief. I loved this example because it demonstrated how you could combine the extra power that PhoneGap provides along with existing JavaScript libraries. This morning I watched an excellent Google IO presentation (https://www.youtube.com/watch?v=EPYnGFEcis4&feature=youtube_gdata_player) on Mobile HTML. It was an overview of some of the exciting stuff you can now do with mobile HTML and JavaScript. To be clear, this was all without using wrappers like PhoneGap. In one of the examples the presenters discussed the new "capture" support for the input/file field type. This is rather simple to implement: <input type="file" capture="camera" accept="image/*" id="takePictureField"> If supported (recent Android and latest iOS), the user can then use their camera to select a picture. I decided to rebuild my old demo to skip PhoneGap completely and just make use of this feature. Here's the code: For the most part, this is pretty similar to the last version. I no longer wait for the deviceready event, but instead just listen for the document itself to load. Instead of listening for a button click, I've switched to an input field using type=file. I now listen for the change event, and on that, I see if I have access to a file. If I do, I can then use the URL object to create a pointer to the source and then simply add it to my DOM. After that, Color Thief takes over. The only tricky part I ran into was that in iOS the URL object is still prefixed. You can see how I get around that in the startup code. To be fair, this isn't 100% backwards compatible, I could add a few checks in here to ensure that things will work and gracefully let people on older phones know they can't use this feature. But the end result is nearly the exact same functionality in a web page - no PhoneGap, no native code.

Converting a list of dates into a shorter, combined list

Sun, 19 May 2013 09:03:00 -0400

Forgive the title, I'm not sure it best describes the task. I was asked by a reader to consider a simple problem. Given a list of dates, how would you rewrite them so that two (or more) consecutive dates are displayed together? For example, imagine this input.dates = [(May 1, 2013), (May 4, 2013), (May 5, 2013), (May 7, 2013)] I want to take this list and join the values that are one day apart. I should end up with: dates = [(May 1, 2013), (May 4, 2013 - May 5, 2013), (May 7, 2013)] I wrote two solutions for this - one in ColdFusion and one in JavaScript. Let's start with ColdFusion. First I create my sample data and a new array that will store my results. Now for the real "meat" of the logic. My idea here was to store objects in the new date array. The object contains a first and last property referring to the first and last date. What this allows for is a quick date comparison. If the next item in my source data is one day after the last value in the previous range, than we 'extend' the range by resetting the last property. Otherwise we need to add a new item in the result array. Finally, let's make this easier to use by doing some formatting on the array elements. We will loop through each item and add a 'formatted' key. And the result is this: Woot. Ok, now let's look at the JavaScript version. I'll just share the complete template first and talk about the differences. Ignore our two helper functions on top for now. Our initial seed data is very similar to the ColdFusion one. Instead of using dateNew we use the Date constructor. The first loop is also pretty similar. Do remember that JavaScript arrays begin with 0. The main issue we have is doing the date comparison. There is no dateDiff in JavaScript. You can find great Date libraries out there, but as I had a very simple need here, I just wrote a quick function that compares the millisecond values of two dates and sees if the difference is less than one day. (By the way, the best JavaScript date library out there - imo - is Moment.js.) Finally, I did my formatting. Again, I could have grabbed a library for this, but instead I simply ran toDateString. My dtFormat function is a bit simple. Almost too simple to even be its own function. But I was imagining that I'd probably want to make formatting a bit more complex in the future. This lets me handle that later. The result: Note - I switched to Firefox for the screenshot as I think it prints objects nicer in the console. I've included a zip with the complete code for both examples. Note the CFM has a tag-version as well for older CF engines.

JavaScript Design Patterns - The Revealing Module Pattern

Mon, 13 May 2013 06:53:00 -0400

It has been a few weeks (ok, a few months) since my last blog post on JavaScript design patterns. I'd apologize, but frankly, it will probably be a few more weeks until I blog on this subject again, so hopefully people aren't expecting a fast series here (grin). As a reminder, the idea behind this series is to create real, practical examples of various JavaScript design patterns based on the book, "Learning JavaScript Design Patterns" by Addy Osmani. (See my review here.) In this blog entry I'll be discussing the Revealing Module pattern.Addy Osmani describes the Revealing Module pattern as:

The Revealing Module pattern came about as [Christian] Heilmann was frustrated with the fact that he had to repeat the name of the main object when he wanted to call one public method from another or access public variables. He also disliked the Module pattern's requirement of having to switch to object literal notation for the things he wished to make public.

There's two main issues here. First, the concept of "repeat the name of the main object when he wanted to call one public method from another..." If your only experience with the Module pattern is based on my previous blog post, then this may not make sense. Let's consider a simple example. I've got a simple module here called revealModuleTest. (And yes, this isn't a "real world example", but I wanted to demonstrate the issue with a simple block first.) My module has one private method, and three public methods. The first one, doPriv, simply wraps a call to the private method. The second public method, pub1, just returns the number 2. Finally, testpub, just makes use of pub1 and multiplies it by two. Note the three tests at the bottom. As the comments suggest, the final method will fail: Uncaught ReferenceError: pub1 is not defined Why? When the result of the module (everything in that return) is returned back to the caller the scope has changed such that pub1, by itself, is no longer addressable from testpub. You won't have this issue if a private method calls another one, but you will definitely run into this with the public methods returned by your module. (I don't think I did a great job explaining this - I may come back and flesh this out.) The fix is rather trivial - simply use the same API you would in your own code calling the module: The second thing Heilmann talks about is the switch to using object notation for defining methods. Everything in the return block is using object notation. Personally, this doesn't seem like a big deal, but all things being considered, I would prefer to write more code in function x() syntax versus x:function(). If it sounds like the Revealing Module is just a cosmetic change, that would be fair I think. But don't simply dismiss it. Anything that makes you quicker, more efficient, etc in your development is probably a good thing. I'd also argue that the issue with "public calling public" is something you could easily accidentally trip into. If the Revealing Module pattern makes that easier to avoid, then it is yet another reason to consider it. Let's look at an example of this - again - using my kinda stupid example. As you can see, this isn't a radically changed version. It has the same smell, but is just structured a bit differently. Note that all of the real logic is in private functions. The return block is now far simpler - it just provides the public API. Ok, so how about a real example? In my previous blog post I created a diary application that allowed you to create and read diary entries stored in WebSQL. I defined my Diary as a module. You can view that source here. To modify this to match the Revealing Module pattern, I moved everything into private methods and created a much simpler return block. So what do you think? I have to be honest. When I first read about this pattern, I really didn't think much about it. As I said, it seemed just cosmetic. But after seeing the change to my Diary module, it just... feels better. I didn't put this up as a 'live' demo since the functionality is the exact same as before. (And as a reminder, it only works in WebKit browsers, which is bad, and will be addressed later.) If you really want to try this, you can download the code from the last entry and drop in the new diary. Since it is has the exact same API, everything will just plain work!

New Brackets extension - JSDownloader

Wed, 24 Apr 2013 11:14:00 -0400

Over the weekend I was working on a small project and needed a copy of jQuery. I try to avoid the CDN as I find myself at airports without wifi access sometimes so I did what I normally do:

Go to jQuery.com
Click the download link
Click for the latest minified version
Right click, save as

That's what I always do - but it kinda bugs me. I had heard of a tool called Bower that I thought might help. It's a package manager for the web. In theory, it would do what I wanted. I went to the command line, installed it via npm (have I said before how much npm rocks?), and then fetched a copy of jQuery like so: bower install jquery. This worked - and it was epic cool - until I realized how much it grabbed... Ugh. Don't get me wrong - this was still quicker then my old process. And I "get" the idea behind the metadata involved here and why it would be useful in the future. Bower is pretty damn powerful and I definitely recommend folks take a look at it. But what if you just want a copy of the library, one time, and that's it? I decided to whip up a quick Brackets extension as a proof of concept. Clicking the "Run JSDownloader" menu option opens up a dialog of options: Clicking the library fires off a process to download it: And yeah... that's it. Simple, direct, exactly what I need. There's a few caveats though. Right now it only supports "single file" downloads. I've got basic architecture in there to support a list of files, but it isn't complete. The idea is that if you provide a list of files, it will create a subdirectory based on the name of the library (as in: currentdir/jqueryui/) and then copy the resources there. But this isn't complete yet because... The second issue is that Brackets still doesn't support binary file writes in extensions. In theory I could do so if I hook up a Node module to my extension, but... honestly it feels like a bit much. I'd rather just wait a bit and hope for support in a future sprint. Finally, there is no support in Brackets yet for refreshing the project view. So while the extension certainly works, you need to do a reload to see the files show up. So - where did that last of four projects come from? This is kinda cool I think. In order to "drive" the data list, my extension reads from a simple JSON packet. Here's how it looks now: While this file is in the extension itself, my code reads the GitHub version of it instead: This means folks could add a new library by just committing to my GitHub repo. I don't have a nice UI to refresh the cache, but if folks end up using and contributing to this extension, I'll add it. Download/Fork the code here: https://github.com/cfjedimaster/brackets-jsdownloader

Presenting on PhoneGap Next Week

Tue, 23 Apr 2013 10:15:00 -0400

On Tuesday, April 30th, I'll be giving a free, online presentation about PhoneGap as a preview of my Fluent 2013 presentation in San Francisco next month. This presentation will be your basic "What the frak is PhoneGap"-type presentation, but if you are looking for a chance to get introduced to the product, please join me. Developing Mobile Applications with PhoneGap (Wow - I need to update my bio there. Apparently I'm still an independent contractor focused on ColdFusion.)

Article Posted (Again) : Building a Google Maps Application with Updating Markers

Mon, 22 Apr 2013 08:53:00 -0400

Just as an FYI, today my first article on flippin' awesome! was published this morning: Building a Google Maps Application with Updating Markers In the article I discuss how to create a Google Map that automatically refreshes marker data every few seconds. The idea being that you may have data for moving items (trucks, dragons, users with jetpacks) and your map can automatically update the display in near real time.The article focuses on the client-side aspect of the application with a little bit of time spent on the server-side. I wanted to share one little tip that I didn't think was relevant to the article but that my readers may find interesting. I had originally planned on sharing a live demo of the map with the article. While it is trivial to fire up a Node app, I was curious if I could a) use a subdomain off my main server and b) use port 80 even though Apache was using it for my virtual servers. Turns out this is rather easy. I'll be honest and say I do not grok this code 100% (hell, not even 1%), but it worked perfectly fine both on my local OS X Apache as well as my live Windows server. My read of this is - listen for the domain nodetest.dev and proxy all requests, back and forth, to the server at 127.0.0.0 on port 3000. As I said, I was able to hit my subdomain just fine and Apache handled the proxy perfectly. I ended up not sharing this because my server-side logic didn't constrain truck movement, so after running for a long time, the data points wandered off the main view port.

Proof of Concept - Connecting a Node app with Brackets

Tue, 16 Apr 2013 14:28:00 -0400

In one of the more recent Brackets sprints, Node.js was added to the core of Brackets. If you read my blog you know I've been playing a bit with Node.js lately. I've yet to deploy any "real" web site/app using Node, but I've built a few applications and demos as a way to help learn the platform. In a recent Twitter conversation the idea of using Node.js within an extension came up and I had a good idea I thought I'd try out.A few months back I blogged about a Node.js project I created called MockData. The idea was to provide a fake datasource of JSON data for client-side testing. So if you needed to prototype an app that would generate a list of people, you would fire up the server and access the resource by passing in query parameters that 'shape' the result data. So for example: http://localhost:3000/?num=rnd:10&author=name&age=age&gender=oneof:male:female&salary=num:150000 This returns: I built the project, released it up on GitHub (https://github.com/cfjedimaster/mockdata) and didn't really think about it again until last week. The app I built is easy to use... if you know Node. But I bet that I could make it even easier by integrating it into Brackets itself. There are a couple of useful links for this. The first being on the Bracket's wiki: Brackets Node Process: Overview for Developers. The second is a sample GitHub project: https://github.com/joelrbrandt/brackets-simple-node I won't repeat the docs, but will encourage you to read them carefully. I'll be honest and say I don't think I grok them 100% quite yet, but I was able to get things working. The warning about abandoned Node processes is a serious one. In my testing I had to force quit Brackets a few times. That's probably something stupid I did. I'll also point out that you don't want to forget about restarting Node on every change to your Node.js code. As you go back and forth between extension code and pure Node.js code, you can forget this. Two things that hit me that are not in the guides were:

For some reason, if I forgot to var scope a variable, I'd get errors. Typically this isn't a critical error. But for my Node.js stuff under Brackets, it was. So I had one non-var-scoped variable in my original Node.js demo that ran just fine as is, but not in Node.js under Brackets.
If you console.dir from Node.js in Brackets, you just get an object Object string. Skip that and use console.log(JSON.stringify(foo)) instead.

So did it work? Heck yes! Here's the menu item I added... Which then fires off the request and presents a nice dialog to the user: At which point you can start playing with it in your JavaScript code. I'm considering adding a nice little icon so that you can click and copy the URL to your clipboard in case you forget. There's also the issue of documentation. I know how to massage the server to get what I want, but I should provide a quick reference guide. Anyway... what do you think? You can download the bits below. If one person says this is cool I'll add it to GitHub.

Review: Learning JavaScript Design Patterns

Sun, 14 Apr 2013 10:10:00 -0400

I've been thinking a lot lately about client-side development (as is hopefully evident by the type of posts I've been making). I feel like I've finally gotten comfortable with JavaScript, but am looking for ways to bring my skill set to the next level. In general, I'm looking for ways to better organize my code. I know that design patterns can help me with that goal. So I was pretty excited to get "Learning JavaScript Design Patterns" by Addy Osmani. My expectation was that this book would give me a good overview of the various types of patterns I could apply to my client-side work. Unfortunately, I don't know if the book reaches that goal. Let me explain why.The book does a good job of introducing the concept of patterns in general, as well as explaining why classical patterns that you may have applied from a traditional object-oriented environment may not apply as well to JavaScript. These are important concepts, but I feel like the book focuses a bit too much on them. There is an even an entire chapter dedicated to writing patterns before the reader is introduced to any actual patterns. It isn't a big chapter, but I felt like so much time was spent on theory in the beginning that people who are not traditional comp-sci folks (like many web developers) may be a bit put off. Right after the chapter on writing patterns is a discussion on anti-patterns. Again, I think this is an important concept, but it just continues to delay the introduction of proper JavaScript patterns. When the book finally does get down to business (chapter 9), the examples are both good and bad. They are good in that they demonstrate the concept at hand, but bad in that there are very few practical examples. For example, a basket module (somewhat related to a shopping cart) in the abstract isn't terribly helpful. I was really hoping to see a full, if short, web application that demonstrated the pattern in use. I know "real" applications can be difficult, but I feel like too few of the code samples actually bring the concept home for the reader. As another example, there is an entire section on jQuery Plugin design patterns. To me, that seems like such a limited audience it just adds to the 'noise' of the book. I think this is the biggest fault of the book. If you're experienced in traditional programming, you can take the book and use it well. If you're the traditional web developer (who typically learned in bits and spurts as they had to) then it will be very difficult to take practical benefit from this book. This is something I find in many cases throughout the web community. I feel like there's a great deal of intro material, a great deal of very high end abstract material, and very little in terms of intermediate-level discussion. It feels painful to go from Beginner to Intermediate versus Intermediate to Advanced. I'm not sure if others feel that way, but thats how it seems to me. I think I can recommend this book if you've got some experience with patterns already, but not if you're coming from a non-CompSci (or server-side) background. I've got a great deal of respect for Addy and would recommend his blog and any presentation he gives. For folks curious about what type of material I think does do a good job of having practical examples, I'd strongly recommend the new series by Elijah Manor: The Angry Birds of JavaScript This is exactly what I'd like to see more of!