Last week I wrote a brief introduction to Kristof Degrave's ongoing, multi-stage IndexedDB tutorial. Judging by the number of reads, it looks like quite a few of you are interested in learning more about HTML5's IndexedDB. I'm following Kristof's tutorial anyway, so I might as well keep posting about it here. Today Kristof has posted his next IndexedDB tutorial -- Transactions -- and here's where IndexedDB begins to get exciting, where the work of creation and definition begins to pay off. We're preparing for actual data retrieval and manipulation, so we'll be creating a READ_WRITE transaction. At this point, if you're trying to understand IndexedDB formally as well as use it pragmatically, you might want to get more comfortable with W3C's conceptual treatment of transactions along with the formal object description, and maybe the IDBTransaction interface too. (For me, it especially helps to understand emerging tech like HTML5 a little more abstractly, just in case the standard takes a different turn than previously expected.) If you prefer learning by doing, here's how Kristof explains transactions: Today, I’ll handle the transaction subject. As said in previous posts, every request made to the database needs to be done in a transaction. So for every read or write request we need to create a new transaction. There for we need a database connection and 2 argument that we will pass to the transaction method. The post is, like his previous tutorials, quite straightforward -- painlessly showing you how to use what is potentially one of the most powerful features of HTML5. Take a look, create an IndexedDB transaction, and get ready to retrieve and manipulate data.

Well, after hubbub, including some here at DZone, the HTML5 element has returned. Paul Cotton, on behalf of the chairs of the working group, issued a revert request -- and his explanation is interesting: The Chairs have received multiple requests to revert change r6783. This change is related to bug 13240 [1] which was never sent to the HTML WG since it used a possibly incorrect Bugzilla component. Since WG members were NOT notified of the creation of this bug the Chairs have decided that this change should be subject to the Enhanced Change Control rules in the WG Decision Policy [2]: "Therefore during a pre-LC review, or during a Last Call, feature additions or removals should only be done with sufficient prior notice to the group, in the form of a bug, a WG decision, or an on-list discussion. This applies only to LC-track drafts and does not apply to drafts that may include material for future versions of HTML." We therefore ask for a revert of this change to be completed no later than the end of day on Tuesday 8th of November. If this revert is not complete by that time, we will instruct W3C staff to make this change. In other words: people don't like it, and we never really meant to approve, and we're not really sure how it got through in the first place. Now, the decision policy quoted sounds as though it would not invalidate the change, since the 'bug' was listed (and discussed) since July. I don't know what 'possibly incorrect Bugzilla component' means -- did they actually find something misconfigured in Bugzilla? -- but the vague hedging on 'possibly incorrect' raises my suspicions a bit. The meeting minutes don't help much (though it's neat to glimpse at how these conversations go). After the decision, a proposal to modify the reverted element was posted on the W3C wiki. This might map the near future of , so it's worth checking out for that reason alone -- though also, again, to help understand how HTML5-spec decisions are made. But however it happened, is back. So: did the W3C WG actually bow to popular outcry? or was there really just a bug in their bug-review system? I don't know, but I'm curious. What do you think? Update: Discussion has re-opened in the original bugpost since the revert command came through -- some deductive, some inductive. Results from the blekko web grep mentioned in the last comment might be very interesting...

So affirms Sencha, in the latest installment of their HTML5 developer scorecards series. Four-sentence version: After putting the Galaxy Nexus through our test wringer, we can say that Ice Cream Sandwich is a major step for the Android browser. However, it still falls short of iOS 5. It’s a solid browser for normal page browsing and it adds major new features that support most of the HTML5 spec. It also has taken a big step forward in correctness of rendering, which is a welcome change for people who want to push their mobile browsers to the limit. The most exciting new feature support, in Sencha's opinion: tons of CSS3, including the more nativey-slick, like animations, refletions, transformations, and transitions. Some specific missing features: Web Workers Web Sockets WebGL datetime and range input types overflow-scrolling Shared Workers The device Sencha used was a Samsung Galaxy Nexus, which meant that some performance and zoom issues might tell you as much about the hardware as about the OS. But the biggest rendering improvement: rendering was simply correct. One way Ice Cream Sandwich beat iOS 5? Embedded inline HTML5 video. They actually played inline on the Galaxy Nexus, in Sencha's tests; they didn't on the iPad and iPhone running iOS 5. Here's Sencha's rather glowing closing summary: In summary, the Galaxy Nexus and Ice Cream Sandwich are a major step forward for the Android platform. Feature by feature, HTML5 support has gotten much better, rendering has become more accurate, and performance has gotten much faster. Although still behind the current HTML5 gold standard of iOS5, Android 4.0 is night and day compared to previous versions. That 'night and day' is pretty strong, and definitely great news for HTML5 developers. If you're developing HTML5 apps for mobile, you should probably read the full report, which includes JavaScript performance numbers via SunSpider, Acid3 scores, and detailed results of Sencha's own touch-specific test suite.

Serious local database support is probably one of the coolest new features of Windows Phone 7.1(5). For the Windows Phone developer, it's not hard to create a local database, or add some columns, indexes or tables. But if you're using a SQL CE database then you are, after all, developing for a phone. And one of phones' most exciting powers isn't their hard drives -- it's their cameras. And it turns out that Mango makes storing camera photos -- or any image data for that matter -- pretty easy. To see how easy, look at this HowTo from Anton Swanevelder, posted a few days ago on his blog. Anton breaks SQL CE image-storage into three steps (the CRU in CRUD), and every step takes less than 20 lines. For example, you can create a column to store image data like this: [Column] public byte[] ItemImage { get { return _ItemImage; } set { if (_ItemImage != value) { _ItemImage = value; NotifyPropertyChanging("ItemImage"); NotifyPropertyChanged("ItemImage"); } } } The other two steps are more interesting (converting a camera stream to a storable byte array, then converting the byte array to a bitmap markup-able in XAML), but no more difficult. Read the full post for the full implementation.

Suffering a little whiplash after the rapid-fire removal and return of HTML5's element, I became curious about how the working groups at W3C actually, well, work. In particular, I noticed something about the wording of Steve Faulkner's original revert request: the editor of the HTML5 specification has made a change to the specification that is not supported for good reasons (see below, source: http://willyou.typewith.me/p/9Zl7I2dOKs) I therefore request a revert of this change http://html5.org/r/6783, so that it can be further discussed and decided within the consensus based HTML WG process. Emphasis (er, offset) added. The editor-vs.consensus theme chimed with an early, rather severe response to the original decision, calling Hickson's move 'self-contained'. Okay, everybody likes consensus, especially about standards. But the once-upon-a-time student of decision theory and commitment devices in me perks up skeptically at (even implicit) accusations of unilateralism. Lucky for me, an Invited Expert from the CSS Working Group at W3C has already posted a thorough treatment of how the CSS group works. The inside-view really gives a better feel for how people really act in the CSS group -- more than, for example, the official charter and process document of the HTML Working Group (which are very top-down, as presumably documents of this sort must be). CSS isn't HTML, of course. But CSS is now being developed in modules, rather than tangled, monolithic versions; and one of the differences between W3C and WHATWG (the 'other' HTML5 standards group) is that W3C is maintaining the kinda-versioned 'HTML5' designation, while WHATWG now treats HTML as a 'living standard' (complete with an exacting list of differences between the W3C and WHATWG specs). So versioning is a bit of a thorny point in both HTML(5) and CSS, and the issue of versioning must deeply affect any standards-regarding decision-making process. Indeed, the 'Inside View' grants modularization a whole page to itself. The full site goes into a lot of gritty details -- interesting for anyone interested in decision-making at this level, but especially for anyone involved in defining new web standards. But most of us aren't defining new web standards. So, for the rest of us, here's an outline of how the CSS Working Group does its thing, in tl;dr form: People and Roles: module editors (in charge of each module) CSS WG members (inner group of discussants) www-style contributors (all other discussants) Communication: mailing lists (technical discussions; high volume; members follow closely) telecons (1hr, once/wk; chair presides, scribe takes minutes) face-to-face meetings (3 full workdays, 3-4 times a year; half in USA, half split between Europe and Asia; one meeting takes place along with other W3C groups; addresses deepest/hardest/complexest issues) IRC (side-discussions during official telecons; unofficial chats) internal mailing list (mostly just planning meetings and other administrative tasks; any technical discussion is immediately moved to the public www-style list) www.w3.org (homepage with specs and blog) dev.w3.org (editor's draft specs, with revision history) wiki.csswg.org (lots of stuff, technical and administrative; general-purpose, like any good wiki) test.csswg.org (subdomain=giveaway) Making Decisions (usually somewhat informal; for this one read the full treatment) Modularization (first formulated during 2007 CSS-WG meeting in Beijing; page includes history and rationale) Spec Process: working draft (with numbered iterations, until Last Call Working Draft) candidate recommendation (calls for implementations; this usually means lots of implementations already exist) recommendation (=finished; arrived at only after two correct independent implementations exist) Sources of Innovation (full post discusses three different sources for CSS3 Backgrounds and Borders) Makes sense to me. The site is much more discursive than this outline summary -- and the discursiveness gives a better feel for what it's like to participate in the WG, so the read is pretty fascinating.

This recent article from Alyssa Frazee's blog provides a tutorial on how to help non-programmers get started with R. Given that R is a programming language popular outside of the development world - its focus on statistics and data visualization makes it popular among data scientists and sociologists, for example - the tutorial is a useful starting point and provides an outline of the need-to-know aspects of R. A lot of ground is covered in a series of quick and concise steps. For instance: How to download R and RStudio Working with graphics Data types Exploratory data analysis And more. An important detail here, though, is the intended audience of the tutorial: It is not for non-programmers attempting to learn R, but really for programmers attempting to teach R to non-programmers, especially in a concise, crash-course fashion. I think there would definitely be some value here for non-programmers or even programmers who are new to R (though experienced programmers interested in R might be better served elsewhere), because it provides an outline of things you need to research and learn, but I believe the intention is to be more of an informal teaching aid. Check out the full tutorial for some insight on how to help a non-programmer get started with R.

Explore this fun experiment using DuckDB to parse CockroachDB Change Data Capture output and query CockroachDB with DuckDB.

Learn how to build a chat server using gRPC, a modern remote procedure call framework, and its support for streaming data.

Several of us might be familiar with the clear () API in the Java collections framework. In this post, let’s discuss what is the purpose of this clear() API?

This PostgreSQL JSONB Cheatsheet presents a complete guide to PostgreSQL JSONB functions with examples and some demo code.

Looking for a more streamlined and intuitive way of querying databases, similar to the elegant LINQ constructs in C#? Check out the open-source library JPAStreamer.

The combination of Playwright and JavaScript allows you to create automated tests that can be run repeatedly and consistently, saving you time and effort.

In this article, the reader will learn how to perform a failover with a headless Aurora Global Database and its outcomes.

We’ll take a look at the imports field in package.json and how it can be used to configure path aliases for various use cases.

Learn out about how to query and write Apache Parquet files in the first post of our series on the popular data exchange format.

Using a common GitHub issue, the author will take the reader through the process of working through an issue on an unfamiliar codebase.

Thinking of learning Go in 2023? This book could be a good choice! The focus for Learning Go isn't just how to write programs in Go; it's how to write Go idiomatically.

In this blog, the author will take the reader through the step-by-step process of how to backup and restore a PostgreSQL database.

This blog discusses the importance of commonly used design patterns and how they provide reliable solutions to common software development problems.

In this blog post, I will demonstrate how to use OceanBase in a Python project. We will create a REST API that serves as the backend of a headless e-commerce app.