Category: Tech Ramblings

9

Logging. An old friend. So critical for a production deployment and so hidden away. Much has been said and done in this area, and we’ve seen both success and total domination by log4j, as well as an abysmal failure of java.util.logging (still hearing the chorus of WTFs and raised eye brows).

With the introduction of the playing field has changed dramatically, but something was still missing. Multiple applications in runtime were still writing to the same single log file. And while it was easy to split out log entries for your custom classes and packages,  in practice it had little value without the larger context of Mule and 3rd-party library log entries. Besides, re-configuring logging at runtime wasn’t quite possible. And with multiple applications running in a single Mule instance, one-config-fits-all was no longer an ideal choice.

So, without further ado, welcome the new Logging in Mule 3.1.2.

With the explosion of APIs (funny that we have started using the term APIs instead of web services) what have created a monster integration challenge that I talked about in a previous post about cloud silos. However, to get an idea of how this challenge will manifest itself I thought it would be interesting to take a look at some statistics.

API Growth

Programmable web is a great resource for tracking and mashups and has become the defacto registry for web . The site provides a wealth of statistics tracking back to 2005 when the site was started by John Musser.

API Timeline

com.thoughtworks..: ERROR: Element bla bla bla not found

Ok. Face the music. Let’s debug.

Check list:

  • Is locator well defined? Yes. 
  • The element is rendered? Yes.
  • Do I have any error when I execute code step by step? No.χ
  • Am I crazy? Perhaps. But the problem continues to be there and I have no clue why!!!

What is happening here?

When MuleSoft opened the office in Buenos Aires, everybody from San Francisco was asking about the here. We researched and found that there were a couple of initiatives to start it but died long time ago. We thought it would be great not only to sponsor one, but to create it and help to have it’s own .

How many web sites/web services have you wished you could just interact with over the command line? Sometimes, you just want to type commands in your shell. I can name at least 3 of our products which I’ve wished I could do that with: iON, MMC, and Tcat.

There are some challenges though. Bash/BAT file scripts don’t provide facilities to interact with web services. Then, if you go with a cross platform language, you have to write cross platform scripts and provide a way to distribute it.

We thought we’d make this easier, so we wrote Mule Jockey, a tool to turn annotated scripts into a cross platform distribution of shell scripts.

It’s really easy. First, write your command. For example:

This isn’t an industry that needs more acronyms but there is no stopping the *aaS rocket ship so its better to clearly define new categories that get created as we fly towards the clouds. Integration Platform as a Service (iPaaS) is a new type of service tailored specifically for integration applications. The term ‘PaaS’ is a layer of cloud software that deals with the platform for building applications (if you are not familiar with PaaS take a look at my previous post). This layer is analogous with ‘middleware’ and in the same way middleware was broken into categories such as App Server, ESB and messaging, PaaS will also get broken down.

Gartner released a report earlier this year that broke PaaS down into application Platform as a Service (aPaaS) and integration Platform as a Service (iPaaS). The aPaaS category is the one that most folks are familiar with numerous services including Heroku, Elastic BeanStalk, CloudBees, Azure with some platforms being more aligned with PaaS concepts than others. The category is very new with Mule iON announcing earlier this year and others such as WorkDay have started to emerge.

Ramiro Rinaudo on Wednesday, April 6, 2011

The Developer Testing Paradox

0

Over the years, I’ve seen many different styles while doing software development. Each one has unique characteristics, and some developers can identify themselves with more than one probably. I would like to go over all the different styles and point the effect it has over the project.

How much time do you invest in estimating your backlog? Do you really get any value from it? When was the last time you thought about the value it provides you? I can see as a source of problems in many ways.

Ross Mason on Thursday, February 10, 2011

Groundhog Day: Cloud Silos

6

There is no denying it, the is having a massive impact on all our lives. In the enterprise many of the applications that we to host in our own data centers now live in the .  We are a fairly typical company in terms of our IT, we don’t host any business software in house. We use Google Apps, Salesforce, Intaact, Marketo, and more. We do it because it is convenient, quickly and usually painless.  This instant app-gratification that SaaS and cloud provides is inviting us to make the same mistakes again; we’re putting our data in silos.

On my previous post about Kanban, I presented the challenges we had in our Engineering team. They were:
1. Uncontrolled growth of Work In Progress.
2. Not Enough visibility.
3. Reduced quality.
4. Inability to properly estimate all tasks upfront.
5. Planned features and improvements are hard to manage and implement.

During the implementation of we focused on solving those problems.