Blog

Apr 3

Queued: Theming

By on April 3, 2009 12:01 am

As part of our series on how we built Queued, today we’re going to talk about theming the Queued application, and touch on a few examples of what made putting the skin on Queued so much fun.

The foundation for the beautiful theme for Queued was laid down by colleagues Damon Dimmick and Torrey Rice, and their amazing wireframe and mockup work (respectively) provided the building blocks for laying down Queued’s skin.

Apr 1

Stocker: Advanced Dojo Made Easy

By on April 1, 2009 4:41 pm

SitePen is excited to announce Stocker, which demonstrates some of the more advanced capabilities of Dojo, including the newly released DataChart, the DataGrid, Data Store, Comet, Persevere, and BorderContainer. SitePen is also offering a one-day workshop where you will learn how to create Stocker yourself, but I’m here to give you a sneak peak of what Stocker is and how it works.

Stocker uses these technologies to emulate a stock monitoring application. We’re using made up data, but that’s actually more interesting. The Persevere server generates new stock items at certain intervals, and then pushes them to the browser with Comet. Then the Data Store updates its items and triggers an onSet notification. The DataGrid and DataChart are both connected to the same store, and are listening to that event. They then update their displays and show the stock items and their latest data.

Stocker

Mar 31

Queued: Demystifying Deferreds

By on March 31, 2009 12:16 am

At SitePen, we work very hard to to provide our customers and fellow developers with useful web app development services. We’re currently deconstructing the development of Queued, our Netflix Queue management application built with Dojo and Adobe AIR. Having presented on dojo.deferred and related topics at the Ajax Experience, and having heard that the Queued team ran into a few problems with them, I thought it would be interesting to review problems that are sometimes encountered when using Deferreds. What is the source of these problems, are these problems related to bugs or because there are misunderstandings, and how should we address this going forward?

Mar 30

Queued: Architectural Decisions

By on March 30, 2009 12:07 am

Dojo is a very flexible toolkit; it doesn’t dictate how you organize your code or create your widgets. It simply provides tools, and it’s up to you to decide how you want to fit them together. Developing with AIR puts you squarely in the browser-based application model, but aside from that it mostly stays out of your way as well. As part of our series on the Queued development process, I’m going to take a look at the decisions we made and the philosophies we adopted for the project. It should provide some insight into our process.

Introducing DojoX DataChart

By on March 30, 2009 12:00 am

The latest addition in the Dojo 1.3 release is the new dojox.charting class, DataChart. Its primary purpose is to make connecting a chart to a Data Store a simple process. There are also other benefits with DataChart: less parameters are needed to create a basic chart, and more defaults and convenience methods get you up and running quickly with Dojox Charting.

Mar 26

Queued: API Challenges

By on March 26, 2009 12:06 am

SitePen’s new Queued application works very well with the Netflix API, but the smoothness of this functionality was the result of a lot of research, and trial and error. In fact, this experience led me to propose that future project timelines should budget extra time when working with an unfamiliar API—and even more time when that API is brand new and untested. Netflix released one of the more exciting APIs in recent months and SitePen began to work with it right away. The Netflix team did great work on their API and they were also very helpful with us when we had questions or there was a bug on their end. I can imagine the challenges of setting up a (Netflix) REST API with an existing system and a large and complex library of items was not simple. Integration with the Netflix API presented its own set of challenges to us.

Mar 24

Queued Overviewed

By on March 24, 2009 4:35 pm

Last month, we announced Queued, an open-source application for managing your Netflix Queue. Queued is a desktop application created with web technologies and techniques including the Dojo Toolkit, and it is distributed as an Adobe AIR application to provide several performance boosting benefits from living on the desktop.

At SitePen, we help our clients build great web applications. Most are not available for public consumption as they live behind company firewalls and/or require licensing. On the other hand, Queued is free and open-source software, BSD-licensed, and hosted on Google Code.

Mar 2

Storing Binary Data in Persevere

By on March 2, 2009 5:46 pm

Persevere stores structured data in the same way data is represented in JavaScript and JSON. Various different data types can be persisted including numbers, strings, booleans, objects, arrays, dates, functions, and even binary data. Most of these data types are familiar to JavaScript developers; however, binary data is usually not seen in JavaScript. Support for binary data opens up a powerful realm of application capabilities by allowing data such as images, audio, and video to be stored directly in the Persevere database and referenced by JavaScript/JSON style data structures.

Feb 27

Deterministic Client/Server Interaction

By on February 27, 2009 1:04 am

The module dojox.rpc.Client was introduced in Dojo Toolkit version 1.2, providing extra request headers on XMLHttpRequests to facilitate implementing deterministic request handling on servers. Browsers typically use two or more TCP connections to send HTTP requests to a server, while subsequent requests are often routed on separate TCP connections. This means there is no guarantee that the request that is sent first will arrive at the server first. With sophisticated web applications, non-determinism can lead to bugs that are very difficult to track down.

If a web application sends multiple requests to a server and assumes that the server will handle them in the order they were sent, this non-determinism can be problematic. Furthermore, messages that arrive out of order can be rare, and therefore problems can be hard to reproduce. On old modem connections, packets were sequenced over a slow PPP connection that made out of order messages almost non-existent. With modern broadband connections, the race becomes more interesting. HTTP pipelining adds another mechanism that can lead to messages arriving out of order and with browsers beginning to support and use pipelining, messages arriving out of order will become even more likely in the future.