Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Welcome to the world of machine learning, where computers learn from data and make predictions without explicit programming. At the heart of this technology lies the concept of a “model.”
In traditional programming, we create functions/methods that receive inputs/parameters and return a result based on a formula. For example, imagine a Java method that applies the formula y = 3x + 1.
If you are new to serverless, creating a simple application for a serverless infrastructure is a good place to start.
In this article, you will run through the steps to create your first serverless Java application that runs on any cloud.
Workflows are great for orchestrating services, functions, or events. They provide out-of-the-box features to make your applications resilient, reliable, and simple.
But currently, each cloud vendor has its workflow solution. AWS has Step Functions, Google has Google Workflows, Microsoft has Azure Durable functions, and so on. The lack of a common way to define workflows becomes an issue when you need to migrate or host your applications on more than one cloud vendor. It also limits the potential for creating tools and infrastructures that support several platforms. This is what the Serverless Workflow specification addresses.
The new LTS version (version 17) of Java was released in September. And since the previous LTS (version 11), many cool features were added. One of the coolest ones is “Pattern Matching for instanceof“.
Until Java 15, when we checked whether an object is an instance of a particular class, the compiler didn’t infer the variable’s type, even if the object passed the condition. Because of that, we always had to cast after the instanceof check.
When you need to test an application that consumes a web API, you basically have two options:
Many times, starting a container for that is not an option. For instance: you might not have a container environment available, or you just don’t have the artifacts to create that container (it might be a 3rd part API), or it is hard to emulate the needed behavior with containers.
A few days ago I did a post on LinkedIn talking about the Optional class. One comment was an excellent question:
Could the use of
Optionallead to performance degradation?
If you usually need to rewrite or copy similar code between different projects, it may be time to stop replicating it and create a library.
You can also share it as open-source, so other people can use it and help you improve it.
When you have more people using your Java APIs, your projects grow and naturally you become a better engineer. You become more likely to increase your incomes and join great new projects. It also enables people to get their jobs done faster. So it’s a win-win situation.
To keep those people who already use your API and attract more, you need to eliminate these 4 mistakes.
Java Engineers can adopt several strategies to stay up-to-date with technology. One of the most natural ones is by developing frameworks and libraries. By doing that, they often find themselves in one of these two situations:
If you find yourself in one of those situations, you need to know the 3 principles that sustain great frameworks and libraries. Applying these principles in your APIs will put you on the path to staying up-to-date.