Have you ever found yourself scrutinizing old code you have written years before, realizing in hindsight how slow it actually was, how badly you have written it at the time and pondering how it managed to still work acceptably for such a long time? We did on more than one occasion… After a while, you can’t help but wonder what exactly saves you so often from your own stupidity. Could it be luck? Unlikely… And after many years we have finally figured it out. We know now what our guardian angel is. It’s the JVM, this smart, amazing machine, about which we Java programmers know so very little.

Indeed, this article should be about the WannaCry ransomware, but first let us do a small detour to an event that happened exactly ten days before the madness, and let’s talk about the GoogleDocs phishing wave. The scary thing is that, while in the case of WannaCry the “only” human factor was the lack of even basic actions to protect the systems, in the case of the phishing attack the user was actually required to click twice: once to open a link in a strange mail, and once to allow some suspicious website access to their Google account.

Custom software developers sometimes anxiously wait for the maintenance period to begin. During maintenance, the software is already locally installed on the customer’s equipment and infrastructure, and the detailed job of adapting the software to the customer’s processes and needs is in almost all respects finished. If the development and implementation phases were well managed and finalized, during the maintenance phase, the software developer’s effort should be significantly diminished and the profitability should increase. With a little luck (or maybe it’s more than luck at stake), during maintenance, the developer’s work and allotted resources will be minimum, while the maintenance cost (some quite generous) will compensate for the low profitability of the project in earlier phases.

In the software development industry, we need to solve problems we encounter every day. To define the solution for a given problem, we use some programming languages and usually the solution consists in a piece of software. Problems and solutions can vary, but very often we see that some of them are repetitive and this can create frustration for developers. For such cases, developers came up with some generic approaches in either *design patterns* or architectural solutions. However, even in this case, repeating the same architectural solution can be frustrating and time consuming. In this context, some of the developers come out with a new solution in the area of Domain-Specific Language - a way to create new languages which are focused to resolve small and well regulated problems from a given domain, making it easier for development work.

th new consumer electronics emerging on the market almost every minute and sometimes using the same technology, but packaged and marketed differently, it is an unfortunate by-product that millions of tons of electronic waste is produced worldwide, each year. Everybody enjoys new technology but how many of us act environmentally responsible when we buy our newest mobile or smart device? There are steps we can all take to be more responsible towards the environment when we design our IoT projects, such as using the Three R’s principle.

Using assisted learning within user-centered IoT devices represents a step into the future in terms of how communication is performed. The main benefit intelligent agents bring to the IoT table is the creation of a system based on users’ needs. As a result, the different gadgets can learn the user’s habits, leading to more efficient usage of that gadget. IoT devices have developed in an intensive rhythm, and interconnected devices have started to offer data about the things they work on. Nevertheless, data is not valuable unless it is transformed into information which can later be used. This refers back to the Big Data field where raw data is processed to obtain valuable information. Yet, it takes time and research to be able to obtain knowledge about what was done and what should be done.

 A walkthrough of the key aspects of MAF – internal mobile automation API over Appium providing access to multiple devices on iOS and Android at runtime is described. The article covers some generic information about the Appium automation service, a personal challenge in the production environment (alongside the adopted solution) and a step-by-step tutorial covering the API installation and configuration.  Appium is an open source test automation framework for mobile apps. Currently supported platforms are iOS, Android and Windows which make use of the WebDriver protocol. It is also cross-platform meaning that it allows you to write tests for the previously mentioned platforms based on the same API. It enables code reusability across platform test cases as long as the UI of the applications is similar. To this end, it leads to a well-structured architecture of your testing framework. Another advantage of Appium is the flexibility of choosing the programming language for developing test cases. The currently supported ones are Java, Ruby, Python, PHP, JavaScript, and C\#.

Today we will focus on the “difficult” subject of multi-threading in a big enterprise environment. Because my previous experience was anchored in the .Net Framework, we chose to provide the examples from the C\# language, but the very same concepts, classes and abstractions described below have an almost word-to-word equivalence in Java.

There is a common understanding that front-end programming is less prone to architecture and design patterns, and more prone to the pursuit of more stable add-ons. Well, since this is an obvious shallow approach, we are going to use this article to throw a ray of light on classical inheritance in JavaScript, its common patterns, features and the frequent mistakes of its application. We’ll consider examples of inheritance in Babel, Backbone JS and Ember JS, and we will try to derive the key principles of object-oriented inheritance for creating custom implementation with EcmaScript 5.

Published in Issue 59 Read more

A properly designed domain model has a lot of embedded information that is expressive and readable to the end users. For instance, the class Order has a Customer property, having a semantics like: “*An order is made by a customer*” and the Customer class has simple type properties like *Name*, *Age*, *Email*, etc. with easy to grasp semantics: *A customer is named “John”, has age 30 and with email “john\@doe.com*”. In this line of thought, we see that a well-designed domain model comes with a lot of free knowledge we can take advantage of when building our system’s UX.