This article briefs about the impact of spam and how it can be addressed with emerging machine-learning technology based on our journey in this domain.

We know traditional security practices can’t support this scale, so how do modern practices allow us to scale security with these architectures?

Learn how to combine two or more streams of data together in real-time with a streaming database, run SQL queries and create a materialized view.

This article will give you a better understanding of data quality testing, monitoring, and observability. So let's explore these concepts together.

A comprehensive Test Pyramid tutorial that covers what Test Pyramid is, its importance, benefits, best practices, and more.

Learn how to avoid traps with Java Optional and how to use it efficiently by taking the best of this API to make a readable code.

DevOps pipelines automate software development workflow for continuous integration, delivery, and deployment.

Natural Language Processing (NLP) and Machine Translation have emerged as indispensable tools in our increasingly interconnected world.

This article delves into different system components, from the client and DNS, to the load balancer server, firewall, service instances, and other core elements.

Kubernetes security is more important than ever and should be top-of-mind for most teams. Walk through the latest in k8s security solutions from KubeCon 2023.

This presentation from Hilary Mason at devs love bacon in April, titled "Everything You Need to know about Machine Learning in 30 Minutes or Less," is an introduction to machine learning for those who have no prior experience with it. Take a look if you're interested in a quick, fun overview to help you get started: Hilary Mason - Machine Learning for Hackers from BACON: things developers love on Vimeo. Then, if you want to get a bit deeper, check out this intro to machine learning in R, or to get a lot deeper, our Machine Learning Refcard.

So, you heard about IoT. You got your Apple Watch and your Intel Edison and you're putting Doom on everything and your refrigerator is sending all kinds of emails. All you have left to do is check all the entries on your IoT shopping list and get your home fully automated, bring your life into the future. Before you worry about the technological singularity, though, you may want to consider something more immediately threatening: your rapidly emptying bank account. According to Terence Eden's recent look at the price of Things, a truly automated home is a bigger economic undertaking than it might seem to be at first glance. First, he points to sensors for his windows: After a traipse through my family home, I discover that I have 20 separate external doors and windows. I don't live in a mansion - but all my windows are split into two different sections. So, if I want my windows to become part of "The Internet of Things" I'm going to be shelling out £600. That's quite a lot of money. And that's only for a passive system. And, as Eden points out, that's just to let you know whether the window is open or not. It doesn't lock or unlock your window. It doesn't close or open your window. That's £600 - $980.30 USD according to my extensive research - just to keep you from worrying about your carpet when it starts raining. But it gets worse from there. Eden also looks at more branded scenarios, such as decking out your IoT house with some better lighting: Suppose I want some smart lightbulbs? The highly desirable Philips Hue Personal Wireless Light Bulbs are FIFTY QUID EACH . . . If I were to deck my place out completely in Philips Hue bulbs, I wouldn't have much change left from £1,250. And those are just a few of the items that the home of the future would likely include. Eden briefly looks at iBeacons and NFC tags, for example, and his conclusion is the same: IoT is expensive. Certainly these prices will drop over time, and it's definitely not an all-or-nothing game when it comes to these devices, but either way, Eden presents an interesting look at a less-often-explored aspect of the Internet of Things. There are a lot of exciting things happening right now, but to what degree will we actually have access to them?

If you're interested in getting involved with IoT - maybe you're one of those Java developers who just got a fun set of tools - it looks like the next few years are going to be a good time to do it, because according to Business Insider's BI Intelligence report, the Internet of Things is growing. A lot. Specifically, the report is measuring the growth of internet-connected "everyday" and "enterprise" devices, which I assume refers to any internet-connected device that one would not traditionally expect to have an internet connection. In other words, your refrigerator, or your toaster, or your dog. According to Business Insider, there are approximately 1.9 billion of these devices today, and by 2018, there will be about 9 billion. Again, that's not including smartphones, wearables, traditional computers, and other things you expect to be internet connected - in fact, that 9 billion figure is greater than the predicted numbers of all those other devices put together. That's a lot of things, and it makes sense, given what we've already heard about all the IoT money and IoT jobs. Business Insider also points to a few potential sources of this influx of IoT devices: connected billboards, for example, and flexible electricity grids that compensate and adjust for various energy usage scenarios. In short, IoT is already here, and it's going to get a lot bigger. Soon, this will be your life: pic.twitter.com/0fmnhs7BvG — Omer Shapira (@omershapira) September 26, 2014 Or, you know, something along those lines. Check out Business Insider's full article - a preview for their BI Intelligence report, which requires a sign-up - for all the details.

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...