I’ve had a long-standing interest in taking client-side programming beyond display logic and input validation. The new HTML 5 technologies are making full-scale application development in the browser increasingly practical. Unfortunately, the needs of Carbon Five’s clients generally exceed the capabilities of purely client-side solutions, so I don’t get to spend as much time developing JavaScript as I’d like. Consequently, I challenged myself to solve as many of my day-to-day issues as possible by writing applications that require only a single HTML page and a modern browser to run. So far, this has resulted in five applications; they’re available — with some additional thoughts on this style of development — below the fold.
Continue reading ‘A few experiments with HTML 5 applications’
Javascript library publishers often go out of their way to prevent other sites from linking to their libraries directly, preferring anyone who wants to use their library to download and host the file(s) themselves. The most common way to do this is to check the referrer of any requests for javascript files and reject any requests which come from other domains. However, this requires the (minor) extra complexity of requiring server side support.
I just discovered a neat hack in Douglas Crockford‘s popular json2 parser/serializer which obviates the need for any server side support. So simple, yet so effective. Check out the first line of http://www.json.org/json2.js:
alert('IMPORTANT: Remove this line from json2.js before deployment.');
Neat, eh?
We are embedding video from Vimeo on a site we are working on and wanted to change the behavior of playing a video so that it would go back to the first frame after the video was done playing, rather than staying on the last frame. Since it ended up being harder than expected and finding good documentation online was difficult, I thought I’d share my solution here. Continue reading ‘Controlling embedded Vimeo video using javascript’
Alex sent me an email Saturday morning with this really cute Canvas game he wrote with his daughter Ada. His timing was really great since I am on a panel at SXSW Tuesday called Is Canvas the End of Flash? He explains it all below…
I was telling Ada how video games are made one night, and she ask me if I could make a game. I said yes, we could make one together, and she bugged me all night to get started. I told her to start by designing a game on paper. She drew something that looks surprisingly like pacman (given that she’s never played the game), but she told me the dots were snowballs and that you could throw them at the monsters and use them to build walls. I started programming it as an SPA using canvas. She came up with all the rules, with some suggestions from me.
It may be that I’ve just been doing a lot of JS lately, but building a game like this in JavaScript felt really comfortable and extremely rapid. I had a basic version working with about 200 lines of code, but the details have tripled that. I went through a couple of major refactors, neither of which were troublesome in textmate.
The game is completely un-optimized, but it runs fast enough on my macbook. I know lots of ways to speed it up if I had to. It’s a little rough in a lot of areas, but it’s getting close enough to present.
Play Snowballs
Instructions
Load in Firefox or Safari. The arrow keys move your character, the spacebar launches snowballs (which you have to collect). Hit a monster 5 times to freeze it, then touch it to collect it.
Next week at EBig Jonah and I are wrapping up our world tour of talking about Javascript testing. March 17th in Oakland: ”Recent evolutions in Javascript testing frameworks now allow creating test suites, test-driving development, and running tests on a continuous integration server. This allows us to support more complex Javascript, have confidence in the implementation, and push more of the logic from the server into the browser, reducing the load on the server.” The focus of the talk is walking through a suite of tests we build for a real-world example.
For those of you who caught it last week at the SDForum, here are the links people requested:
To sign up for next Wednesday, go to the EBig site.
Jonah and I are taking our presentation about Javascript Testing on the road next Tuesday at 6:30 in Palo Alto, at the SDForum
The teaser for it… Recent evolutions in JavaScript testing frameworks now allow creating test suites, test-driving development, and running tests on a continuous integration server. This allows us to support more complex JavaScript, have confidence in the implementation, and push more of the logic from the server into the browser, reducing the load on the server…
Hope to see you there.
I’ve written a maven plugin to integrate Screw.Unit javascript tests into a maven build. The project is inspired by the Blue Ridge testing framework for Rails, but it’s a bit more light-weight by design.
Continue reading ‘Screw.Unit JS Testing in Maven: javascript-test-maven-plugin’
My current rails project is using Blue Ridge and the tool set it bundles together (Rhino, env.js, Screw.Unit, and Smoke) to write test driven JavaScript. The ability to write tests of my JavaScript, in JavaScript, as efficiently as I can test other languages has forced me to rethink how I structure my work and I’m writing better code because of it.
There are a couple of different options for JS testing available at this point but Blue Ridge’s plugin is the first I have seen which made writing test driven code as easy as I have come to expect while still providing all the functionality I need. In particular;
- Running my tests in a browser is fast. Refreshing fixture pages to rerun tests is dramatically more efficient than waiting for selenium tests to cycle.
- I can debug my tests as they run against their fixtures pages and inspect or manipulate the DOM at any point.
- I have mock and fake objects available to test behavior and stub out dependencies.
- My JS tests run in continuous integration, just like all the other tests.
By writing fixtures pages and tests first I am immediately using all of my code in two locations and running it against slightly different DOMs. That has pushed me to encapsulate most of my code as jQuery plugins and think carefully about how much I depend on the page’s structure. I end up with terse selectors instead of using whatever attributes are readily available and a clear configuration point for my page’s behavior as I chain together plugin calls in $(document).ready().
We’d like to see what other developers have done and share what we have learned so far so Carbon Five is hosting an open discussion of JavaScript testing in our office this week.
Topic: Javascript Testing
When: Tuesday Nov 17
6pm: arrive/network
6:30 – 8 presentation and discussion
Where: Carbon Five office: 171 2nd Street, 4th Floor
Please RSVP if you would like to attend.
Only pure agile devotees will find it interesting… Revisiting agile methodologies, I wanted to solidify my understanding of the differences between agile, scrum, XP, etc. I went through a mini-research project of reviewing the “canonical” sources of these practices, and then built a quick visualization to clarify my understanding:
http://ndpsoftware.com/agile_methods/agile_methods.html
Hint: Try dragging around the boxes to see how practices are related to each other.
Warning: If it doesn’t draw anything interesting for you, refresh your browser… there’s a large component of “randomness” to the algorithm and it can get stuck easily.
Warning II: Don’t leave it running in your browser, as it’s somewhat sluggish Javascript… this was a demo thrown together in a couple hours.
