Security in the Internet of Things is a fairly common concern these days - you know, Heartbleed, toasters, that kind of thing - but you may not even have considered the greatest threat to your connected devices: classic 1990s first person shooters. That's the scenario presented in this recent experiment from Context Information Security. By taking advantage of a web interface that require no user authentication, the Context team managed to get Doom up and running on a Canon Pixma printer. Obviously Doom is not the point in itself, so much as an illustration of the vulnerability, but it definitely gets the idea across. According to Michael Jordon at Context, the vulnerability was fairly serious: At first glance the functionality seems to be relatively benign, you could print out hundreds of test pages and use up all the ink and paper, so what? The issue is with the firmware update process. While you can trigger a firmware update you can also change the web proxy settings and the DNS server. If you can change these then you can redirect where the printer goes to check for a new firmware. So what protection does Canon use to prevent a malicious person from providing a malicious firmware? In a nutshell - nothing... Jordon's post goes into detail on how the encryption was broken. Canon was contacted and informed of the problem, and responded that it would be fixed, but Jordon warns that it's not a unique scenario. While this particular technique is not currently a common concern, it demonstrates the reality of security concerns when it comes to IoT devices. Once everything is connected, how many devices will be vulnerable? How confident can we be that the creators of these devices will be cognizant of these issues? As a potential catch-all solution, Context offers a strange bit of advice: Context recommends that you do not put your wireless printers on the Internet, or any other ‘Internet of Things’ device. So, there you go - one way to be sure. The Internet of Things can't help but be secure if you get rid of that whole "Internet" part.

After a brief test-drive, IntelliJ IDEA has migrated its bugs and feature requests from JIRA to YouTrack, the new bug and issue tracker from JetBrains announced a few weeks ago. As usual, you can report IntelliJ IDEA bugs or feature requests to IDEA: Feedback, with two more projects available to view and comment: IDEA: Backlog and IDEA: Development. YouTrack, currently in 1.0 Beta stage, provides the following advantages over competition: Keyboard-centric approach lets you use easy shortcuts for major operations, including creating, modifying, and searching for issues. (Read more.) Query-based search with intelligent query completion helps you find (and save) any set of issues in seconds, across projects. (Read more.) Powerful commands enable you to batch-modify multiple selected issues, including fixing, specifying priority, types, writing comments etc. (Read more.) The following resources should help you get used to YouTrack: YouTrack features. YouTrack demos and documentation. YouTrack blog. YouTrack is also used to track issues in other JetBrains products, including TeamCity, dotTrace, MPS, and Web IDE. You can download YouTrack beta as a JAR or WAR distribution, and try it out in your own environment. YouTrack 1.0 final release is scheduled for autumn. Watch YouTrack blog for latest news and tips.

if you've been looking forward to intel's edison development platform since it was announced, your time has come. at the idf 2014 keynote a few days ago, edison was released. intel has brought us iot. it's a slick little package. you can't read about it anywhere without hearing about how small it is - it's the size of a postage stamp, you see. it's small! (via anandtech ) if it's the specs you're looking for, intel can help . edison includes: ...a 22-nm intel® atom™ soc, formerly silvermont that includes a dual core, dual threaded cpu at 500 mhz and a 32-bit intel® quark™ processor mcu at 100 mhz... [and] 40 gpios and includes: 1 gb lpddr3, 4 gb emmc, and dual-band wifi and bluetooth® low energy... and it supports: ...development with arduino* and c/c++, followed by node.js, python, rtos, and visual programming support in the near future. it'll be retailing for $50. that's a pretty manageable hit to take in your iot budget - after all, it's just 1/7th the price of that shiny new apple watch .

Back in August when Google acquired Instantiations, the speculation was that Google would possibly provide Instantiations GWT Designer as a free tool for all to use. Today, Google has made my day, because not only is GWT Designer relaunched as a free tool, but so are their three other core products. This is a huge day for Java developers, particularly those focussed on the desktop, as these tools are among the best of breed: as commercial tools they were worth the cost as they boosted productivity, but as free tools they are now an indispensible part of your software development workflow. The importance of this announcement can not be overstated. Firstly, Java developers now have a production quality UI builder for fast prototyping of their desktop application using either Swing, SWT or RCP, as well as GWT and XWT. I've used WindowBuilder in the past, and it's a great way to get started quickly. The code generated is very usable. There has been no convincing free solution available for this range of UI frameworks in the past: today that all changes. High quality static analysis of code is important for Java developers. Before you walk into a code review, it's always worth taking a scan over your code. Typically developers skip this, or else they use a free static analysis tool (e.g. FindBugs). Working CodePro AnalytiX into your development process, or just your nightly build, will help you identify bugs, and possible security issues, with your codebase earlier. Finally, automated UI testing is one of the most difficult areas to get right. While there are free solutions available, the commercial products have always seemed one step better. WindowTesterPro will allow you to automated tests for your Swing, SWT or RCP applications. It includes record and playback functionality to get you started with an automation test suite quickly. Here's a quick overview of the tools, now relaunched as Google products GWT Designer Powerful Eclipse-based development tools that enable Java developers to quickly create Ajax user interfaces using Google Web Toolkit (GWT) CodePro AnalytiX Comprehensive automated software code quality and security analysis tools to improve software quality, reliability, and maintainability WindowBuilder Pro Java graphical user interface designer for Swing, SWT, GWT, RCP, and XWT UI frameworks WindowTester Pro Test GUI interactions within Java client rich applications for the SWT and Swing UI frameworks Google plans to unify the products into the Google Plugin for Eclipse. You can download any of the tools from the GWT download page. Check out Google's announcement to find out more.

An application rarely depends on one single extension. If it does, then it has something wrong with its extension model and maybe it doesn’t need one after all. An extensible application allows the use of a multiple extensions that satisfy the standard exposed by the SDK: In my previous article I showed how to use MEF to import a single external assembly. However, MEF doesn’t impose a limit on the number of assemblies that can be imported, although some conventions should be followed. The extension standard is defined by a single class library with the following contents: namespace PluginDevKit { public interface IWriter { void DisplayMessage(string message); } } I will create two new class libraries that will represent two different extensions for the base application. For the first extension, the implementation will be: using PluginDevKit; using System.ComponentModel.Composition; using System.Diagnostics; namespace FirstPlugin { [Export(typeof(IWriter))] public class FirstPlugin : IWriter { public void DisplayMessage(string message) { Debug.Print("First Plugin: " + message); } } } Here, I am implementing the IWriter interface and exporting the main class that will later on be used by the main application. The second extension is implemented the same way, with minor naming changes and it displays a different message: using PluginDevKit; using System.ComponentModel.Composition; using System.Diagnostics; namespace SecondPlugin { [Export(typeof(IWriter))] public class SecondPlugin : IWriter { public void DisplayMessage(string message) { Debug.Print("Second Plugin: " + message); } } } Now let’s look at the application itself, that will consume the extensions above. It’s structure is a bit different compared to the one that imports only a single assembly. First of all, the property that is used to import is no longer a single instance: internal IEnumerable Writer { get; set; } There are multiple instances of IWriter to be loaded, therefore those are stored in an instance of IEnumerable, that will later on allow to go through each one of them to access their functionality. There is also an interesting aspect when it comes to setting the Import attribute. The standard Import attribute only allows one Export to be assigned to the property that satisfies the condition set by the contract. If there is more than one Export present that satisfies the same contract, a CompositionException will be thrown when the composition will be attempted. Prior to the current release, the Import attribute could’ve been used to set a collection that will contain multiple instances of satisfactory Exports. In the current release, this is not allowed. Instead, the ImportMany attribute should be used. [ImportMany(typeof(IWriter))] internal IEnumerable Writer { get; set; } This attribute automatically implies that there are multiple Exports that satisfy the defined Import. When loading a single assembly, or when all extensions are registered in the same assembly, an instance of AssemblyCatalog can be used to parse the assembly. When there are multiple assemblies, this approach can no longer be used and an instance of AggregateCatalog should be used instead. It represents a collection of AssemblyCatalog instances (via the Catalogs property) that can be used to parse and compose multiple assemblies at once. var catalog = new AggregateCatalog(); catalog.Catalogs.Add(new AssemblyCatalog(Assembly.LoadFrom(Application.StartupPath + @"\Plugin.dll"))); catalog.Catalogs.Add(new AssemblyCatalog(Assembly.LoadFrom(Application.StartupPath + @"\Plugin2.dll"))); I copied both extensions in the application folder, so I can easily access them. It is a good practice to keep all extension components in a single location that is relative to the application. The rest of the composition process is similar to the one when a single assembly is used: var container = new CompositionContainer(catalog); var batch = new CompositionBatch(); batch.AddPart(this); container.Compose(batch); foreach(IWriter w in Writer) w.DisplayMessage("DD"); Once compiled, in the Output window you can see that both extensions have been activated and the DisplayMessage method was successfully called.

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.

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.