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).
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.
Google recently was asked about something we have suspected: Android and Chrome OS may converge. From our perspective, Android and Chrome OS both offer compelling opportunities for building great web apps, but having two distinct operating systems from Google, each with different approaches to development, just adds complexity and confusion to the overall development landscape. Of course, it still bothers us that iPhone apps and Dashboard widgets aren’t interoperable.
Android has the first mover advantage of being deployed today to many devices, but to really get the most out of it, you really should develop using Java, or employ a toolkit like PhoneGap. Chrome OS offers the promise of using web technologies that are popular today, but is not yet production-ready, or optimized for mobile devices like Palm’s webOS.
While there is a lot of short term interest in apps, you can still get significant results from mobile web apps, and the gap between a native app and a web-based app will quickly shrink, as evidenced by apps like Pie Guy. After all, web apps don’t require app store approval!
In the continuing blurring of the lines between web and desktop, Apple has moved the iTunes Store in iTunes 9 to use WebKit as its rendering engine. I was actually surprised to learn this was not always the case, especially with Apple adding Safari for Windows a while back.
The rest of iTunes remains a custom desktop user interface, but it would not surprise me to see iTunes 10 be completely rendered using open web techniques. We already see competing products like Songbird using open web technologies for rendering media players, and it could eventually lead to a version of iTunes that lives inside Mobile Me, with songs stored in the Apple cloud.
Given Apple’s recent push on efforts like Time Machine and Mobile Me, it seems like Apple is working hard towards the important goal of making it very easy for users to not lose their data and work, and moving the iTunes franchise to the web would seem to be the next logical step!
(or “Why JSON Hyper Schema means JSON doesn’t need XML’s namespacing colon cancer”)
I recently posted a proposal for an addition to JSON Schema, called JSON Hyper Schema, for defining the properties of a JSON structure that represent links or references within data structures. This is intended to provide the same linking capabilities of JSON Referencing, but in a much more flexible manner such that schemas can be used to describe link information in existing data structures without requiring a fixed convention. I wanted to exposit one of the further benefits of using this type of schema: satisfying the goals of namespacing in JSON.
Recently, there’s been an increasing emphasis and enterprise-organized uprising focused on eliminating IE6 from the world as quickly as possible. For the unaware, supporting this outdated browser is expensive and limits our creative abilities when it comes to web development.
Mashable has summarized Microsoft’s position that IE6 cannot die until Windows XP dies, even though Microsoft strongly encourages users to upgrade.
We recognize that IE6 was the best browser on the market when released — in 2001. We, also understand that many organizations have invested significantly, buying and building apps on proprietary, non-forward compatible technology such as ActiveX or extensions to IE6. While extensions are not inherently evil, they have a tendency to lock you into a single-vendor solution, which may not be supported in future versions of their product, in this case IE7 and later.
This is one of the reasons that we’re proponents of open source software. We build web applications using free and open source works such as Dojo, which we help adapt and update for new browsers as they are released, to prevent getting stuck with untenable solutions. If you’re looking to unshackle yourself from the confines of an IE6-strapped web application and empower your users to participate in the joys of modern-day web browsing, contact SitePen for a free 30-minute consultation today.
I recently attended a lecture by Matt Jones on the topic of Playful Design. Matt was talking primarily about engaging users and customers through a process of playful discovery, in which fun and quirky features are designed into products, allowing users to engage in entertaining passive exploration of the product. Playful features could have a purpose or simply be there as a wink to the user. The main idea is to create an atmosphere of play that enhances the intrinsic value of the software or product. This playful attitude can be added as part of error messages, quirky functions, or in-product mini-games.
Although the lecture didn’t really focus in any specific product categories, the overall concept seemed to be aimed at electronic consumer devices, social networks, and the kind of fast & fun web 2.0 applications that are popping up like mushrooms. It got me thinking: If playfulness has value, it stands to reason that play could be incorporated into more serious contexts as well. What about products that are notoriously unplayful?