“A surprisingly large fraction of applicants, even those with masters’ degrees and PhDs in computer science, fail during interviews when asked to carry out basic programming tasks. “
When I first heard this years ago I initially thought it had to be inaccurate. I had seen a large number of developers flunk interview coding tests and write really bad code, including some of this. But how could that many career developers out there pass for great programmers, yet when it comes down to actually producing code couldn’t do it well.
In our upcoming MuleSoft webinar, “‘The Health Cloud’: Are we there yet?”, we’ll be talking all about healthcare and the cloud. There has been quite a bit of talk about a “Health Cloud” which promises to extend the point of care, improve patient outcomes, enable closer clinical collaboration and lower costs, but have healthcare organizations really embraced the cloud? Or is this another case of media hype? With such confidential information at risk, how are organizations dealing with data security and integration with third party applications and services?
Hot on the heels of the announcement of the RESTful API Modeling Language (RAML) by the RAML working group, I am very happy to announce the general availability of APIkit.
APIkit consists of a set of open source Maven and Mule Studio-based tools that enable developers to be massively productive in creating well-designed REST APIs. APIkit features include the ability to take a REST API designed in RAML, automatically generate backend implementation flows for it, and then run and test the API with a pre-packaged console.
Back in the old days when I used to write SaaS integration apps for living (long time ago, like 2 months back…) I always found it somehow difficult to reconcile large datasets with the Anypoint Cloud Connectors. Don’t get me wrong, I love those connectors! They solve a lot of issues for me, from actually dealing with the API to handle security and reconnection. However, there’re use cases in which you want to retrieve large amounts of data from a Cloud Connectors (let’s say retrieve my 600K Salesforce contacts and put them in a CSV file). You just can’t pass that amount of information in one single API call, not to even mention that you’ll most likely won’t even be able to hold all of those contacts in memory. All of these puts you in a situation in which you will need to get the information in pages.
Today I’m going to share some valuables lessons learned about developing highly concurrent software. These are real life lessons that come straight from the development of the Mule ESB. This is a story about deadlocks, context switches, CPU usage and profiling, focusing in how to diagnose this issues which is often the hardest part of the solution.
So the story begins a couple of weeks ago when I started working on a new feature for Mule 3.5.0. You’ll hear the details about it soon enough but basically it’s a new feature that aims to address integration use cases which requires processing huge amount of data. As you can imagine then, this feature has to deal with parallelization, process management, atomicity, consistency, distributed locks, etc…. All the fun stuff!
Mule Clustering is the easiest way to transparently synchronize state across Mule applications in a single data center. Mule Clustering, however, assumes that the Mule nodes are “close” to each other , typically on the same network, in terms of network topology. This allows Mule applications to be developed independently from the underlying cluster technology and not to explicitly account for scenarios like network latency or cluster partitioning.
These assumptions aren’t as sound when dealing with multi data center deployments. Unless you’re lucky enough to have fast and reliable interconnects between your DC’s you need to start accounting for latency between datacenters, the remote data center going offline, etc. In such situations the choice of a data synchronization mechanism becomes paramount.