The technological landscape is an exciting one and programming obviously plays a crucial role in it. However, if our code doesn't function as intended, what's the point? That's where app performance comes in. Both are important, both should be prioritized but neither need to be difficult.
As a trend, cloud is now mainstream. And it’s not an exaggeration to say that every successful company has already adopted it or is in the process of adoption, with the goal of benefiting from the agility, flexibility, and speed made possible by the cloud.
While many organizations have fully embraced the cloud, not all of them have completely or accurately identified, evaluated, and addressed the critical security implications of scaling rapidly in the cloud.
To ensure success, organizations need to develop and implement a cloud security strategy that guides them before, during, and after cloud adoption.
This article continues a series that dove deeply into Dockerfiles to see how they are used to construct images. In this article we build two custom docker images: one image based on the “tomcat” base image that hosted a custom application and one image that installed a specific version of Tomcat to use as our own base image.
In this article we will explore the Java 8 default method’s feature in interfaces. The Java 8 says “Default methods enable new functionality to be added to the interfaces in libraries and ensure binary compatibility with code written for older versions of those interfaces”.
As we are extensively working on “OmniChannel” applications with REST APIs approach, mocking the REST services is essential in our day to day development. As part of our development first we are going to identify the REST APIs to expose and the request and response details. Once we finalize these details the backend development team use to create sample request/response (i.e XML/JSON response) for each API and the same can be consumed by the front end team and the native app development team. Till the backend development team provides the APIs the other teams use to hardcode the sample request and responses to complete the development. The “WireMock” provides an elegant way to mock the REST APIs.
For the last decade we tried to reach the magical 2 seconds response time goal but is this still valid? Aren't our users expectations different today? What is the impact of new Front End technologies like Angular.JS, React,...
I can’t even believe it’s May already! STOP THE WORLD I WANT OFF! Well, at least the times are exciting! There’s so much cool stuff to look at this week so let’s get to it!
New sessions are up on the shiny new SpringOne Platform website check it out! In addition to an Adrian Cockcroft keynote, we’re got speakers booked from Netflix, Google, Comcast, Express Scripts, Kroger, along with Spring leaders like Juergen Hoeller, Dr. Dave Syer, Rossen Stoyanchev, Oliver Gierke, and of course, yours truly!
In this post I will show the differences between chaining flows with a VM transport versus using a flow-ref. When I need to divide my Mule flows into re-usable units, I often break them into smaller flows and then chain them together in a main flow.
Flows can be chained together using flow-refs or using VM connectors; most recent examples use the flow-refs. However, flow-refs are a Mule 3 addition; in Mule 2, VM connectors were used to chain flows.
Today, modern enterprise is rushing head first into an always-on, digital-centric, mobile world. Organizations that fail to modify their approach to technology will be left by the wayside as others incorporate highly flexible and scalable architectures that adapt quickly and efficiently to the demands of the modern marketplace.
The rapid rise in popularity of microservices was driven by these market influences. In just a few short years, companies have implemented various configurations of technologies to offer the best user experience.