May 11th, 2010 – by Kris Zyp
The NoSQL movement continues to gain momentum as developers continue to grow weary of traditional SQL based database management and look for advancements in storage technology. A recent article provided a great roundup of some of the great new technologies in this area, particularly focusing on the different approaches to replication and partitioning. There are excellent new technologies available, but using a NoSQL database is not just a straight substitute for a SQL server. NoSQL changes the rules in many ways, and using a NoSQL database is best accompanied by a corresponding change in application architecture.
The NoSQL database approach is characterized by a move away from the complexity of SQL based servers. The logic of validation, access control, mapping querieable indexed data, correlating related data, conflict resolution, maintaining integrity constraints, and triggered procedures is moved out of the database layer. This enables NoSQL database engines to focus on exceptional performance and scalability. Of course, these fundamental data concerns of an application don’t go away, but rather must move to a programmatic layer. One of the key advantages of the NoSQL-driven architecture is that this logic can now be codified in our own familiar, powerful, flexible turing-complete programming languages, rather than relying on the vast assortment of complex APIs and languages in a SQL server (data column, definitions, queries, stored procedures, etc).
Continue reading
Tags: nosql, Persevere, pintura, rest, Server-Side JavaScript, Pintura, and Persevere 2.0
Posted in Persevere, thoughts | 7 Comments
May 9th, 2010 – by Kris Zyp
The REST architecture has become increasingly recognized for its value in creating scalable, loosely coupled systems. REST is presented as a network interaction architectural style, not a programming methodology. However, the principles of REST can actually be very meaningfully and beneficially applied in the programming realm. We will look at how the resource oriented approach of REST can be applied as principles for programming language usage and design. The motivation for looking at REST should be clear. Little in history has been as ridiculously successful and scalable as the web, and REST is a retrospective look at the principles that were employed in designing the core technologies of the web, particularly HTTP. Applying such proven principles to our application design will certainly be beneficial.
Roy Fielding‘s REST architecture is broken down into seven constraints (and the four sub-constraints of the uniform interface). The individual concepts here are certainly not new, but collectively looking at these concepts as resource oriented programming may provide an interesting new perspective. I will also look at how these principles are exemplified in Persevere 2.0 in its object store framework, Perstore, and its web stack Pintura.
Continue reading
Tags: and Persevere 2.0, Dojo, Persevere, pintura, rest, Server-Side JavaScript
Posted in Dojo, JavaScript, Persevere, thoughts | 1 Comment
May 4th, 2010 – by Kris Zyp
Dojo 1.5 introduces a new paradigm for consistent interaction with stateful objects like widgets. Stateful objects now follow a pattern of using get() and set() methods for accessing and setting named properties. Following this paradigm, to get a named property from a widget, we now use:
widget.get("checked");
And to set a named property we do:
widget.set("checked", true);
This essentially supersedes the widget system’s attr() method, providing more readable function names that don’t require branching on variable argument length, and are more easily overridden. The attr() will remain in Dojo 1.5, but now delegates to get() and set(). The use of get() and set() is recommended over attr() now.
Continue reading
Posted in Dojo | 6 Comments
May 3rd, 2010 – by Kris Zyp
The dojo.Deferred module has long been a central component of Dojo, providing a powerful interface for asynchronous operations like HTTP requests. Dojo’s Deferreds are a form of promises, providing a separation of concerns between the mechanics of calling a function and the interface for interacting with the eventual asynchronous future result. Passing callbacks directly to functions tightly couple the interface with asynchronous semantics, but using Dojo’s Deferreds (promises) keeps the concerns separate for robust asynchronous code. Furthermore promises can greatly simplify interaction, allowing one to easily get the eventual result of an operation whether it has already finished, or if it is yet to be finished. While the Deferred module has existed in Dojo for some time, version 1.5 introduces some valuable enhancements.
Continue reading
Tags: Deferred, dojo15, functional programming, promises
Posted in Dojo | 11 Comments
