I was talking to a C-level executive the other day and he asked me to explain how does MuleSoft’s capacity/sizing across various deployment models work. Given I always wear my technical hat I jumped right into the concept of cores and virtual cores and containers (and Kubernetes!) and did a pretty bad job. Fortunately, that executive was very accomodating and somewhat understood what I was talking about. Nevertheless, I should’ve done better.
I was thinking about this conversation over the next couple of days and decided to explain it to my wife - who is very non-technical.
Think of MuleSoft as a specialty cookie store. Or even better, think of Salesforce as a big giant grocery store, with a bakery section called ‘MuleSoft’.
MuleSoft specializes in cookies. They offer 3 types of options to buy their fantastic product.
Cloudhub: Pre-baked cookies, these come in boxes. Very light and crispy. Rightfully branded as ‘Cloudhub’. You can buy as many boxes as you want. Each box contains 10 cookies. This means with one box you can feed 10 guests. If you have more guests coming over, or some guests are unusually hungry you can buy more boxes.
There is also an allergen/gluten free version of pre-baked cookies for government guests.
Hybrid: A cookie dough to bake your cookies in your oven. The cookie dough is branded as ‘On-premise / Hybrid’. You can decide how big (or small) each cookie can be. You can make as many cookies as you want with the dough. (No more 10 cookies per box restriction!). Of course, some guests will find your ridiculously small sized cookies unappetizing (or funny).
Runtime Fabric: After some guests complained that pre-baked cookies were too big, and ‘make your own cookies’ unappetizing. MuleSoft started offering ‘Runtime Fabric’ branded cookie dough. You still have to bake your cookies, but the sizes of cookies are standardized. They won’t look funny.
I was looking for a simple way to calculate performance of my investments over time. Popular portfolio trackers like Moneycontrol and Value Research did not meet my needs. So I decided to try out Google Spreadsheets.
Nice thing with Google Spreadsheets is its support for import and queries.
e.g. AMFI India publishes daily NAV’s on their website http://portal.amfiindia.com/spages/NAV1.txt
You can import the data programmatically and run a query on it to find desired NAV.
I can use following simple query to check the latest NAV of Birla Sunlife Frontline Equity fund, whose symbol is INF209K01YY7
"SELECT * Where Col1 like '%INF209K01YY7%'"),";"), "Select Col5")
Google Spreadsheets obviously supports data from Google Finance with its built in function GOOGLEFINANCE
This will return latest price for State Bank of India.
You can also use Stock Exchange assigned ID’s to query the data from Google Finance
This will return latest price for Larsen and Tubro.
However the most killer feature of Google Spreadsheets is its support for ArrayFormula in conjunction with XIRR.
Let me explain.
Consider following cash flow.
We have to update the XIRR formula to include the new transaction we just added in our cash flow
This is very cumbersome to update XIRR formula, if you have a diversified portfolio with 10+ symbols and investing on a regular basis.
You can see for two symbols we have to keep close track of cell numbers etc to accurately calculate XIRR.
ArrayFormula provides nice workaround to simplify and automate this process of using XIRR formulas for a growing number of transactions
As you can see that except the symbol name both the formulas are identical. We can remove the hard coded symbol name and refer to the cell which has symbol name.
Using ArrayFormula in the portfolio tracker has simplified maintenance of the spreadsheet and saved quite a few hours for me.
While testing REST APIs for one of my projects, I found REST Assured. It was perfect, as it took care of low level HTTP calls under the hood, and provided a high-level, easy to use framework to write tests. Not only REST Assured works really well to test webMethods flow services, you can also run these tests as part of Continuous Integration process through Gradle.
You will need following things on your machine. Make sure these are working without any issues.
Java JDK 1.8 (link). Set JAVA_HOME. And add JAVA_HOME to your PATH
Here we are just taking advantage of Integration Server’s built in content handler for Content Type - ‘application/json’. For the flow service available on Integration Server, we can simply pass JSON request using REST Assured framework. Integration Server will take care of converting this to IDoc and subsequently process it to return a JSON response back to your test case.
Run the tests using Gradle wrapper
Gradle wrapper provides a convenient and easy to use CLI to run your tests. Using Gradle wrapper you can quickly associate your REST Assured tests with your Continuous Integration process.
Good thing about using REST Assured and Hamcrest to test your webMethods flow services is, it is completely FREE. You don’t need to buy an expensive automated testing solution to test your flow services.
Further resources to read
REST Assured has comprehensive documentation available to get you started.