In this post, I am going to demonstrate a two-step Scala implementation of Radial Basis Function Neural Network (RBFNetwork): (unsupervised) k-means clustering first, and (supervised) gradient descent second. This two-step implementation is fast and efficient compared to Multilayer Perceptron while providing good predictive performance. This is because unsupervised learning at the first step provides information about data distribution so that the second step can have an intuition about the data and fine-tune the model.
For us, most of the Machine Learning models that we use today are just black box approaches that we take from some library. It is good to have this ability for faster development; however, it would be nicer to know internal dynamics of their implementations. Therefore, I am hoping that this post will be simple enough to provide you that information.
Tired of having your changing dependencies slow you down? Gradle 3.1’s composite builds provide you with a process of changing and refreshing your dependencies.
Our journey with Gradle started one and half years ago with this presentation. Everybody in the company just loved its expressive and easy-to-understand structure and realized that a plugin model was the wrong level of abstraction. Instead, language-based approaches were the right one in terms of their flexibility for the long term.
So it didn’t take long for almost 50 members of the development team to change the whole build infrastructure with Gradle. Gradle doesn’t just throw away the foundation that other build tools brought. Instead, it builds up easily and more powerfully on top of others while remaining 100% compatible with them. Therefore, this made Gradle not an alternative but an upgrade for us.
While we were migrating projects, simple pom.xml projects required only a few steps, such as; “gradle init,” but others needed more effort. Everything was good with Gradle except for one thing — “composite builds.”
And finally, our most-requested feature came out with Gradle 3.1, and now we love Gradle more than ever.
After trying several different approaches, we came up with what we think is the most elegant way of integrating Docker into our build tool Gradle.
Docker and Gradle have been around for a while, and there are many tutorials, blog posts, etc. related to best practices. After trying several different approaches, we came up with what we think is an elegant way of integrating Docker with our build tool Gradle. What follows is a simple and elegant integration of the two technologies.
First, let’s simply start with why we chose and how we can use Gradle’s Application plugin without getting into Docker yet. The Application plugin works hand in hand with Groovy, Scala, and Java plugins to create an executable JVM application. Using the Application plugin itself also implies application of the Distribution plugin. So, when it comes to deciding what plugin to use for making executables, the Application plugin is the most official way of doing things.
AI and deep learning are transforming the way we understand software, making computers more intelligent than we could even imagine just a decade ago. It is the technology behind self-driven cars, intelligent personal assistant computers, and decision support systems. Deep learning algorithms are being used across a broad range of industries. As the fundamental driver of AI, being able to tackle deep learning with Java is going to be a vital and valuable skill, not only within the tech world, but also for the wider global economy that depends upon knowledge and insight for growth and success.
Type-interference is a great programming feature that helps coders write clean, readable code in a reasonable amount of time. Learn more here.
Writing type-safe language while maintaining less boilerplate code is an important aspect of programming languages in terms of developer’s productivity. Because type-safe code is less error-prone and less boilerplate code leads to more readable code, both together means reduced development time. Type-inference is a great programming language feature that maintains this balance.
Developers usually read more often than write. Thus, even if the source code will end up being processed by the computer, most of the time our focus is putting it into more human-readable form. At some point, we pay attention to the UX principles, like:
Humans have a limited attention span, so source code should help to spend this attention wisely. Information comes at a cost, so the longer the code is, the more overwhelming it is to read.
Sometimes, less means more. Short code may look brilliant, but it amplifies the time that others must spend on it. We should provide just enough information. Implicit values, if we do not abuse them, are the fix for this.
Vert.x can lend a hand with helping your microservices find each other. See how to get it set up and what it can do for your software.
Remember the Unix philosophy “Do one thing and do it well?” That is the philosophy of microservices. In software development, it is a common practice that when the same functionality is seen in the different parts of the application, it is abstracted away as another component.
This article shows you how to launch Vert.x, the toolkit for creating reactive apps on the JVM, in a dynamic way.
Vert.x started back in 2011 and it was one of the first projects to push the reactive microsystem model of the modern applications that need to handle a lot of concurrency. Since back then, people have developed best practices from writing good quality code using Rxfied Vert.x, RxJava’s Observable, and JoinObservable to its deployment using Docker, Kubernetes, or Swarm. Vert.x does not restrict developers to obey certain rules and standards, therefore, it is a better fit for our current Agile environments and Lean Entreprises. Thus, Developers like us, who are keen on freedom, can try new ways of doing things. With that in mind, we did not want to launch our microservices in statically defined ways. So in this article, I want to introduce how we launch the Vert.x in a dynamic way and in the coming days we want to publish series of articles about how we use brand new methods related to things like service discovery and deployment.
See how Vert.X, its Service Directory component and its eventbus work to get services talking to one another on both single or multiple JVMs.
In my previous article, I explained the Service Discovery in Vert.x and introduced an example of transparent remoting using Service Discovery. Transparent Remoting is a remote method invocation that looks like a local method invocation. In the other words, we have a plain Java interface and its proxy implementation at the client side. In the meantime, we have stub at the server side, where the actual implementation runs. With Service Discovery in Vert.x, we can obtain service references using its service name so that we no longer need to care whether a service runs locally or remotely. However, Location Transparency in Vert.x is a very important topic, and I am going to explain it in detail in this article.