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.

Sometimes, Android development is terrible. This recent blog post by Tony Cosentini discusses some of the more common and recognizable pain points in Android development, and how to get around them. Consentini concedes that Android development has been improving lately, pointing to developments like Android Studio and its Gradle build system, but there are still problems. In particular, he focuses on the following: Activities that are treated like view controllers The fragility of intents Problematic unit testing And for each, he provides a solution. For example, he points to Square as a useful source for a number of Android-simplifying solutions. Take a look at the full post for more ideas on how to solve some of the basic frustrations in Android development.

At a fundamental level it's important to understand how JavaScript timers work. Oftentimes they behave unintuitively because of the single thread which they are in. Let's start by examining the three functions that we have access to with which to construct and manipulate timers. var id = setTimeout(fn, delay); - Initiates a single timer which will call the specified function after the delay. The function returns a unique ID with which the timer can be canceled at a later time. var id = setInterval(fn, delay); - Similar to setTimeout but continually calls the function (with a delay every time) until it is canceled. clearInterval(id); - Accepts a timer ID (returned by either of the aforementioned functions) and stops the timer callback from occurring. In order to understand how the timers work internally there's one important concept that needs to be explored: timer delay is not guaranteed. Since all JavaScript in a browser executes on a single thread, asynchronous events (such as mouse clicks and timers) are only run when there's been an opening in the execution. This is best demonstrated with a diagram, like in the following: There are Plenty of Reasons Why JavaScript Timers Matter You may become frustrated if you just look at JavaScript timers as something that doesn’t serve any real purpose for you. It is easy to get yourself into that mentality, but it is also not entirely productive or accurate to think of them in this way. The truth is that JavaScript timers are extremely effective, and they help control various processes that need to be controlled. You may want to set up timers to go off when someone clicks their mouse or when a certain amount of time has passed. Whatever the case may be, you need those timers to help you take care of what is happening. JavaScript timers have already proven themselves to be incredibly useful for many people, and they can be for you as well. Since JavaScript can only ever execute one piece of code at a time (due to its single-threaded nature) each of these blocks of code is "blocking" the progress of other asynchronous events. This means that when an asynchronous event occurs (like a mouse click, a timer firing, or an XMLHttpRequest completing) it gets queued up to be executed later (how this queueing actually occurs surely varies from browser to browser, so consider this to be a simplification). To start with, within the first block of JavaScript, two timers are initiated: a 10ms setTimeout and a 10ms setInterval. Due to where and when the timer was started it actually fires before we actually complete the first block of code. Note, however, that it does not execute immediately (it is incapable of doing that, because of the threading). Instead, that delayed function is queued in order to be executed at the next available moment. Additionally, within this first JavaScript block, we see a mouse click occur. The JavaScript callbacks associated with this asynchronous event (we never know when a user may perform an action, thus it's considered to be asynchronous) are unable to be executed immediately thus, like the initial timer, it is queued to be executed later. After the initial block of JavaScript finishes executing the browser immediately asks the question: What is waiting to be executed? In this case, both a mouse click handler and a timer callback are waiting. The browser then picks one (the mouse click callback) and executes it immediately. The timer will wait until the next possible time, in order to execute. Note that while the mouse click handler is executing the first interval callback executes. As with the timer, its handler is queued for later execution. However, note that when the interval is fired again (when the timer handler is executing) this time that handler execution is dropped. If you were to queue up all interval callbacks when a large block of code is executing the result would be a bunch of intervals executing with no delay between them, upon completion. Instead, browsers tend to simply wait until no more interval handlers are queued (for the interval in question) before queuing more. We can, in fact, see that this is the case when a third interval callback fires while the interval, itself, is executing. This shows us an important fact: Intervals don't care about what is currently executing, they will queue indiscriminately, even if it means that the time between callbacks will be sacrificed. Finally, after the second interval callback is finished executing, we can see that there's nothing left for the JavaScript engine to execute. This means that the browser now waits for a new asynchronous event to occur. We get this at the 50ms mark when the interval fires again. This time, however, there is nothing blocking its execution, so it fires immediately. Let's take a look at an example to better illustrate the differences between setTimeout and setInterval. setTimeout(function(){ /* Some long block of code... */ setTimeout(arguments.callee, 10); }, 10); setInterval(function(){ /* Some long block of code... */ }, 10); These two pieces of code may appear to be functionally equivalent, at first glance, but they are not. Notably, the setTimeout code will always have at least a 10ms delay after the previous callback execution (it may end up being more, but never less) whereas the setInterval will attempt to execute a callback every 10ms regardless of when the last callback was executed. There's a lot that we've learned here, let's recap: JavaScript engines only have a single thread, forcing asynchronous events to queue waiting for execution. setTimeout and setInterval are fundamentally different in how they execute asynchronous code. If a timer is blocked from immediately executing it will be delayed until the next possible point of execution (which will be longer than the desired delay). Intervals may execute back-to-back with no delay if they take long enough to execute (longer than the specified delay). All of this is incredibly important knowledge to build off of. Knowing how a JavaScript engine works, especially with the large number of asynchronous events that typically occur, makes for a great foundation when building an advanced piece of application code. This is an excerpt from my work-in-progress book: Secrets of the JavaScript Ninja. To be released Fall 2008. Previous excerpt: Partial Function Application in JavaScript

So, Android Studio exists. While there are a number of fixes for the less-than-graceful aspects of Android development in Eclipse - Genymotion, right? - some are moving to Android Studio for a more stream-lined approach. This recent post from MeetMe's engineering blog details Bill Donahue's switch from Eclipse to Android Studio, and he has some pretty strong feelings about it. He says - and this is his own emphasis - the following: I will never go back to Eclipse Donahue then explains the key differences as he sees them. First he makes a list of complaints about Eclipse - constant refreshing, awkward UI building, hogging RAM, and so on - followed by a list of the improvements found in Android Studio, such as full-program themes, new UI tools, better stability and performance, and more. He does point to a couple of hiccups, such as the switch to a Gradle build, but it's more of a thing you're going to have to learn than an issue with Android Studio. Check out Donahue's full post for more details on the switch and the little things Android Studio does to make it more comfortable.

According to Philip Rathle on The New Stack, graph databases can be used for more than just finding football stadiums. In fact, they can help with some pretty interesting problems: breaking up organized crime, for example. The example Rathle relies on for this article isn't the Sopranos-style organized crime you might be picturing, but rings of bank and credit card fraudsters. These are perpetrators of "first-party fraud," defined by Rathle as people who "...apply for credit cards, loans, overdrafts, and unsecured banking credit lines with no intention of paying any of them back." This type of fraud is a major problem for financial institutions, largely because of the way fraud rings mirror the strengths of graph databases: a small number of real addresses and fake phone numbers can be tied together in different combinations to create a vast web of dummy accounts attached to fake identities. This structure of fraud is hard to detect, Rathle says: ...traditional methods of fraud detection are either not geared to look for the right thing: in this case, the rings created by shared identifiers. Standard instruments—such as a deviation from normal purchasing patterns—use discrete data and not connections. Discrete methods are useful for catching fraudsters acting alone, but they fall short in their ability to detect rings. And particularly using relational databases: Uncovering rings with traditional relational database technologies requires . . . a set of tables and columns and then carrying out a series of complex joins and self-joins. Such queries are incredibly complex to build and expensive to run. Scaling them in a way that supports real-time access poses significant technical challenges, with performance becoming exponentially worse not only as the size of the ring increases but also as the total data set grows. This is where graph databases come in uniquely handy. Rathle points to languages such as Cypher as providing a semantic that lends itself to navigating these types of relationships, and it is fairly clear, as Rathle demonstrates with a visual, how graph relationships can pinpoint rings. Take a look at Rathle's full article for more details on how graph databases can be used to traverse complex relationships and detect fraud rings.

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.

(This article is the second in a two-part series leading up to the AMD Fusion Developer Summit, the only developer conference dedicated specifically to heterogeneous computing. Check out the first article for a conceptual overview, with extensive resource links.) Recently Anand Lai Shimpi hosted a community Q&A with Manju Hegde, Corporate VP of Heterogeneous Applications and Developer Solutions at AMD. The topic: Heterogeneous Systems Architecture, the standards-based, AMD-led effort to ease development of heterogeneous systems, especially CPU+GPU systems. Normally I'd just send you over to that most excellent Q&A -- but in this case the questions are so good, and Manju's answers so thorough, that you might not have a chance to read everything. So here's a detailed summary, with links to more in-depth resources: Differences between Fusion and HSA: Goals: Fusion: let developers use GPU along with CPU HSA: make the GPU a first-class programmable processor Specific HSA improvements: C++ support for GPU computing All system memory accessible by both CPU and GPU Unified address space (hence no separate CPU/GPU memory pointers) GPU uses pageable system memory (hence accesses data directly in CPU domain) GPU and CPU can reference caches of both GPU tasks are context-switchable (esp. important to avoid touch interface lag -- contexts switch rapidly in heterogeneous environments) (GP)GPU versatility: Non-UI use of the GPU is currently active at a basic level in security, voice recognition, face detection, biometrics, gesture recognition, authentication, and database functionality. But each task is currently GPU-routed. HSA will make GPU use in all these non-UI domains much easier in the next few years. C++ AMP and HSA: C++ Accelerated Massive Parallelism (AMP) is the Microsoft alternative to OpenCL. Both are excellent, and will fill similar roles within the larger HSA. Because C++ AMP does not represent a huge departure from C++, the AMP development learning curve will be relatively shallow. Gaming vs. compute performance: GPU architecture and production costs mean that there is usually an inverse performance relationship between gaming and pure compute performance. This means, in turn, that desktop (i.e., non-specialized) GPU design involves a careful balancing-act between gaming and compute performance (see for a technical overview of some reasons why -- it's more than just GPUs' excellent floating-point performance). AMD and developers: In the past, AMD tended to engineer products, and stop there. Now, because HSA involves a much more serious attempt to encourage heterogeneous systems development, AMD will be working more closely with developers to help them take advantage of (especially GPU) powers they might not have been able to use in the past. The advance of the APU: AMD has no grand strategy to promote APUs, even though they already make numerous different kinds of APUs. Every APU is designed as a response to a specific use-case. The advance of OpenCL:AMD is deeply interested in strengthening OpenCL itself, and to that end has recently driven these OpenCL initiatives: improved debugger and profiler: Visual Studio blogun, standalone Eclipse, Linux static C++ interface extended tools by close collaboration with MulticoreWare (PPA, GMAC, TM) OpenCL book and programming guide university course kit (for use with aforementioned book and programming guide) webinars self-training material online hands-on tutorials at the Developer Summit (select 'Hands On Lab' under 'Session Type') moderated OpenCL forum OpenCL training and service partners OpenCL acceleration of major open-source codebases Aparapi to make Java coders use OpenCL more easily The continuing (but receding) importance of device-specific GPU optimization: Roughly speaking, as GPUs become more General Purpose (GPGPU), the need to optimize for specific GPUs will approach the (real but relatively low) need to optimize for specific CPUs. The CPU-GPU bottleneck (or, whether to use PCIe 3.0 or on-die CPU/GPU integration): The impact of the bottleneck depends hugely on the algorithm. The problem of GPU physics: Simple techniques (resolution, antialiasing, texture resolution) scale graphics easily across many levels of hardware capability -- and this is how game developers have used GPUs in the past. Physics does not scale across hardware nearly as easily, so most developers handle GPU physics at the lowest (console) level. But HSA will make cross-hardware physics scaling much easier. HSA's benefits to small but parallel workloads (versus earlier GPGPU acceleration, which had disproportionately large effect on workloads with lots of data): HSA does not require cache flushing and copying between CPU and GPU, so the quantity of data shared matters much less than previous GPGPU acceleration attempts. HSA availability and AMD's long-term commitment to developers taking advantage of heterogeneous computing: AMD will continue to hold Fusion Developer Summits annually; is already partnering with Adobe, Cloudera, Penguin Computing, Gaikai, and SRS, and working closely with Sony, Adobe, Arcsoft, Winzip, Cyberlink, Corel, Roxio, and many more; and will continute to help make OpenCL development much easier. But the open-standard HSA is where AMD's major, highly ambitious effort in heterogeneous computing will lie, beginning in 2013-2014. HSA and HPC (high-performance computing): AMD is designing HSA-based APUs for both consumer and HPC markets. Penguin Computing will explain some of their HPC applications in detail during the upcoming Fusion Developer Summit (June 11-14). How software stacks will catch up with heterogeneous hardware: The HSA Intermediate Layer (HSAIL) will help facilitate this by insulating software stacks from individual ISAs. Why use graphics shading languages (OpenCL, DirectX) at all: Radical change must be evolutionary, not revolutionary (e.g., assembly -> C -> C++ -> Java). Existing codebases must be used effectively, not abandoned for code written in a theoretically perfect language (the 'software side' of heterogeneous computing). HSA is designed to help developers take advantage of their own skills and existing codebases at the same time. As several of these questions noted, the annual AMD Fusion Developer Summit is an essential component in the eventual rollout of the open-standard Heterogeneous Systems Architecture. No other conference covers heterogeneous computing specifically. The track list is amazingly broad, and the schedule incredibly ambitious. To GPGPU-wrestlers and non-wrestlers alike, heterogeneous computing is a thrilling, emerging technology. Learn more and consider attending the conference on June 11-14.

Learn about overfitting and generalization, and how they relate to the bias-variance tradeoff in machine learning. We’ll also cover techniques for finding the optimal balance between bias and variance in deep learning models.

A guide to developing a text-to-speech converter.

One crucial aspect of ensuring a secure Kubernetes infrastructure is the effective management of secrets, such as API keys, passwords, and tokens.

Explore how flexibility in ACE allows the progression of independent unit testing, without needing to wait for a larger organization to move to containers.

In this interview, learn more about what kind of data Foursquare deals with, what it does with that data, and how using a knowledge graph is going to help.

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.

Learn how cloud-native JuiceFS empowers quantitative hedge funds to enhance AI training and achieve elastic throughput in the cloud.

This article explores NestJS, Mongo, and Typegoose and provides an example of how you can use MongoDB in your NestJS application in a headache-free way.

Inverted indexing in Apache Doris 2.0.0 realizes two times faster log query performance than Elasticsearch with 1/5 of the storage space it uses.