Category: Tech Ramblings

Shohil Kothari on Thursday, January 16, 2014

Top Posts from 2013

0

2013 brought massive shifts in integration tech, from APIs to SaaS and everything in between. Check out our most popular blog posts of 2013 to get a sense of the landscape and what 2014 might bring.

The Hunt for the Perfect API

Your API can be a key to your company’s success. Get it wrong and you lose out on a big opportunity. So how do you design a great API? Is there such a thing? What does it look like?

dillon.compton on Wednesday, January 15, 2014

Minding the API Hierarchy of Needs

0

The rising popularity of APIs as an architectural and development pattern has driven a massive shift in how we think about application and systems design; but how are we thinking about APIs themselves? As API adoption increases, we need to learn how to mitigate risk, maximize utility, and ensure we are building the right APIs for the right people.

Reza Shafii, Director of Product Management, introduces the API Hierarchy of Needs in his InfoQ article, “Minding the API Hierarchy of Needs with RAML and APIkit“, and discusses the advantage of a holistic, broadly inclusive approach to API initiatives.

You may have already heard that on December 31st, 2013, Snapchat was hacked and  4.6MM records were subsequently compromised. According to the official blog, “an attacker released a database of partially redacted phone numbers and usernames.” It turns out the hacker(s) had exploited the “Find Friends” API to try to return the username of automatically generated phone number combinations.

In this case, only phone numbers and usernames were released. Pretty harmless, right? Not quite. The most substantial loss that Snapchat faces in this situation is the loss of trust. Snapchat, along with other organizations that have faced similar challenges, will ultimately recover and fix flaws to become stronger than ever before.

Skip the hampers and gift cards and give the developers on your team something useful this holiday season to transform their hard-earned skills into something creative.


Raspberry Pi

Way better than Fruitcake, Raspberry Pi is a credit-card-sized single-board computer running Linux that can be used for all kinds of great ideas from running a web server in your pocket to building home automation systems. We used one to fly helicopters using a fitness wristband device at our last MuleSoft hackathon. You can get one here for less than $50.

Picture cool kids in startups, cranking code as if their lives depend on it, focusing on the proverbial MVP above all else. At this stage, who cares if technical debt accumulates as fast as code gets written? It would be a waste of time and focus to try to keep the field as green as it was initially. Then the worst happens: the cool kids have it right, people love their new app and traffic starts to surge. Though strong, the duct tape that olds the application together starts to show signs of fatigue. Maintenance becomes painful, adding new features is excruciating. The blood of the architecture that has been sacrificed on the altar of time-to-market is calling for revenge.

One of the most typical architectural mishap that comes back to haunt startups is tight coupling: the whole system is a monolith where coupling manifests itself both from a temporal manner (everything is synchronous) and a lack of abstraction in the interactions between the subsystems (everything knows the intimate details of everything else).

The good news is that there is hope: the giants of past time, upon whose shoulders everything is built, have fought these problems and won. Take Hohpe/Woolf’s Enterprise Integration Patterns (EIP) for example. They discuss how messaging can be used to alleviate coupling issues. Sure enough, the “enterprise” term in the name is dubbed “run away!” by our startups’ cool kids. So in this post we’ll look at a few of these patterns and how they could be used beneficially in modern applications. And hopefully these patterns will feel more lovely than enterprisey!

TL;DR? Don’t worry, (: You can see the code running here.
Destructuring CoffeeScript

Introduction

Destructuring in Coffeescript is an elegant feature that makes the language feel closer to pure functional languages such as Haskell. Let’s see an example of that.

Show me the code

We will start by creating two types of tree objects:

Leaf, as the name suggest, will be the tree nodes that contain values. On the other hand, Nodes will be the objects that will glue together the tree.

james.donelan on Sunday, November 10, 2013

Can Programmers program?

10

199 out of 200 applicants for every programming job can’t write code.

“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.

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!

This post is brought to you by… you! Yes, a couple of weeks back I was writing about how dealing with OAuth2 secured APIs got way easier since Mule’s August 2013 Release. We got such a great feedback that we decided to incorporate some of it in our latest October 2013 release.

 

 

Token Management vs. Token Nightmare

So let’s do a quick recap. In the last post we said that now Mule is way smarter at automatically handling your tokens. So, in a single tenant scenario you could just do this: