Well it worked for Motorcycle Maintenance and Archery…
After the deal had been signed, requirements were drawn up, everybody went through training, and all the software had been download, the developers and architects new to Mule ESB often puzzle themselves with this question, “Ok, what do I do now?” With all the tools and options provided by our products, taking that proverbial first step toward go-live Nirvana can indeed come across as a daunting task for Mule implementation virgins. As the pseudo-scholar of Eastern Religions, a doctor of philosophy, as well as the most monkish employee at MuleSoft, I hope to illustrate how meditating on Zen principles can help get implementations started and bring good karma to successful project completions.
This week we chatted with one of our Sr Javascipt UI Engineers, Emma Guo. Read on to learn more about her love for AngularJS, zombie makeup, and Ted. Yes, that angry teddy bear Ted.
First thought this morning?
- How can I get ready in 10 minutes? (Even though I know it’ll still take 30)
What exactly do you do?
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?
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.
Mule ESB is a big solution with tons of features. There is information about Mule ESB all around – we have info for our community users as well as our enterprise users – and this info is spread in multiple sources. We know that finding the right information on all of these sources might be a challenge, so we came up with a solution, our new knowledge search engine that we call “Knowledge Center”.
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.
This week we’re back with another exciting Meet a Muley post. We chatted with Marina Bottacchi, our Front End Web Developer in Buenos Aires about her geek merchandise days and her adorable pets. As a part of the web and marketing teams, Marina not only ensures our site is always looking good, she does a lot of project management for our more technical web projects.
Keep reading to learn about Marina!
The dreaded user table. Think about it: whenever you start working on a new end-user application, you’ll have to create a table to store emails, user information and passwords. And then you’ll need to add support for the password reset workflow. And so on and so forth. The wheel gets re-invented time and again. Of course, you may go sophisticated and decide to manage users in LDAP or even – gasp – ActiveDirectory. Now you would have a whole different range of problems to deal with, starting with interacting with this external directory in a graceful manner.
Enter Stormpath, the SaaS API whose sole mission is to make authentication and user management awesome and developer friendly! And thanks a new connector for Mule (available here), you can now benefit from Stormpath’s extensive features, which include all of the aforementioned ones, and many more.
In this post, we will look at a Mule application that integrates with the Stormpath API via this new connector. This application exposes a web user interface that uses AJAX to interact with the Mule application. This application allows a user to create an account, log-in and trigger the password forgotten procedure. Enough ado, let’s start digging!
Today I am going to introduce a recently created module: Mule Requester.
As its name may hint, its goal is to allow the request of a resource at any point in a flow. This resource can be a file, a message (from VM, JMS, AMQP, etc.), an e-mail, etc. It’s intended for resources that originally could only be requested by message sources.
Let’s try to explain it better with an example. Say we want to consume messages from a queue on demand, i.e. not consuming the message as soon as it’s put on the queue but at a later stage, when a user calls an HTTP inbound endpoint, for example. We cannot achieve this by using a JMS inbound endpoint, since it will consume the message as soon as it’s put on the queue. Thinking about a way of doing this, we could have a stopped flow and activate it on demand but this would cause the consumption of more than one message or a clumsy implementation that would pick a message and stop the flow again. Another option would be to use a component but this would have to deal with the specifics of the transport, leading to either one implementation per transport type or a big component handling all the transports.
The above mentioned case can be easily achieved using the Mule Requester module, simply by placing the starting point of the flow (the HTTP inbound endpoint in our example) followed by the requester:
Today I will introduce our performance test of the Batch Module introduced on the Mule’s December 2013 release. I will guide you through the test scenario and explain all the data collected.
But first, if you don’t know what batch is, please read the great Batch Blog from our star developer Mariano Gonzalez, and for any other concerns you also have the documentation.
Excited? Great! Now we can start with the details, this performance test was run on a CloudHub’s Double worker, using the default threading profile of 16 threads. We will compare the on-premise vs cloud performance. Henceforth we will talk about HD vs CQS performance. Why? On-Premise and CloudHub users will be using by default the HardDisk for temporal storage and resilience but, this is not very useful on CloudHub as if for any reason the the worker is restarted, the current job will loose all its messages, then if Persistent Queues are enabled the Batch module will automatically store all the data with CQS (Cloud Queue Storage) to achieve the expected resilience.