tag:blogger.com,1999:blog-132431932024-03-07T00:11:53.610-07:00 Just Do I.T. Software As If It MattersAnonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comBlogger319125tag:blogger.com,1999:blog-13243193.post-68613609511160420652015-02-09T15:54:00.002-08:002015-02-14T13:08:52.302-08:00Unveiling RxMuleI'm super excited to announce <b><a href="https://github.com/ddossot/RxMule" target="_blank">RxMule</a></b>, my latest open source project. <b>RxMule</b> provides <a href="http://reactivex.io/" target="_blank">reactive extensions</a> for <a href="http://www.mulesoft.com/platform/soa/mule-esb-open-source-esb" target="_blank">Mule ESB</a>, via a set of specific bindings for <a href="http://github.com/ReactiveX/RxJava" target="_blank">RxJava</a>.<br /><br/>
<center><a href="https://github.com/ddossot/RxMule"><img src="https://raw.githubusercontent.com/ddossot/RxMule/master/rx-mule.png" /></a></center>
<br />
For several years, I've been mulling over the idea of creating a DSL for configuring Mule. Indeed, there is a treasure trove of pre-existing <a href="http://www.mulesoft.org/documentation/display/current/Transports+Reference" target="_blank">transports</a> and <a href="http://www.mulesoft.com/platform/cloud-connectors" target="_blank">connectors</a> for Mule, which is very compelling for anyone building connected applications (which, nowadays, is probably everybody). Unfortunately developers can be put off by the XML-based DSL used to configure Mule, and thus may pass the opportunity to leverage all this available goodness.<br />
<br />
As Rx is gaining traction, more and more developers are getting accustomed to its concepts and primitives. With this mind, and knowing that Mule is at core an event processing platform, it dawned on me that instead of creating a DSL that would mimic the XML artifacts (which are Mule specific), I'd rather create bindings to allow using Mule's essential moving parts via Rx.<br />
<br />
In summary, <b>RxMule</b> adds a number of classes to RxJava that make it possible to observe:
<br />
<ul>
<li>Mule inbound endpoints from traditional <a href="http://www.mulesoft.org/documentation/display/current/Transports+Reference">transports</a>,
including global endpoints and endpoints defined by URIs,</li>
<li>raw message sources, like the new <a href="http://www.mulesoft.org/documentation/display/current/HTTP+Listener+Connector">HTTP Listener Connector</a>,</li>
<li>
<a href="http://www.mulesoft.com/platform/cloud-connectors">Anypoint Connectors</a> message sources.</li>
</ul>
In short, <b>RxMule</b> allows creating <code>Observable<MuleEvent></code> instances from different sources. A <a href="https://www.mulesoft.org/docs/site/current3/apidocs/index.html?org/mule/api/MuleEvent.html">MuleEvent</a> is what Mule creates and processes.
It wraps a <a href="https://www.mulesoft.org/docs/site/current3/apidocs/index.html?org/mule/api/MuleMessage.html">MuleMessage</a> which contains the actual
data and meta-data that's being processed.
<blockquote>You can read more about the structure of a <code>MuleMessage</code> <a href="http://www.mulesoft.org/documentation/display/current/Mule+Message+Structure">here</a>.</blockquote>
The following demonstrates an asynchronous HTTP-to-Redis bridge, that only accepts one request per remote IP:
<br />
<br />
<script src="https://gist.github.com/ddossot/af7bfb30341d19b321df.js"></script>
<br/>
So why don't you take <b>RxMule</b> for a spin and see if it helps you achieving your application and API integration needs: with Mule at its core, I bet it will! Bug reports and pull requests are welcome at <a href="https://github.com/ddossot/RxMule">GitHub</a>.Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-55611096026245124472014-11-15T12:36:00.001-08:002014-11-15T12:36:19.650-08:00Call me never (Ignite Talk)I've been super honoured to give an ignite talk during DevOps Days Vancouver 2014. Ignite talks are intense, as the slides mercilessly fly-by every 15 seconds, and this for 5 minutes sharp (yes, that's just 20 slides!).<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHdq_sD1ALfT_fNPAXTjIrE680vYp_8gBQ9gMvU23OZmjulkRol3ZBFPX_QZHK1yjtw_le-_vfbBMlY9x97WLrGIzqXFVRhaq3c8gQ5iz3uGPLh7D09O6S1U4NrEf2g-64x_8i/s1600/B2LrxeGCYAExnY2.png:large.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHdq_sD1ALfT_fNPAXTjIrE680vYp_8gBQ9gMvU23OZmjulkRol3ZBFPX_QZHK1yjtw_le-_vfbBMlY9x97WLrGIzqXFVRhaq3c8gQ5iz3uGPLh7D09O6S1U4NrEf2g-64x_8i/s1600/B2LrxeGCYAExnY2.png:large.png" height="211" width="320" /></a></div>
<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjL01dCniZHgiFpl_0jVgT180L_auphtGhl9DteXRdqX28cehnPrPJwmY2sYUFu8XGhfTjfya1OiH_4tCgHaZijY-mSkwpXX3FudB3BQpaMK-C4LWi0sA_X7y2veMe_59UDrVuK/s1600/dod2014_01.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjL01dCniZHgiFpl_0jVgT180L_auphtGhl9DteXRdqX28cehnPrPJwmY2sYUFu8XGhfTjfya1OiH_4tCgHaZijY-mSkwpXX3FudB3BQpaMK-C4LWi0sA_X7y2veMe_59UDrVuK/s1600/dod2014_01.jpg" height="240" width="320" /></a><br />
<br />
In this talk, I tried to present some of the lessons we've learned at <a href="http://unbounce.com/" target="_blank">Unbounce</a> while rebuilding our page serving infrastructure. Our availability target is five-nines (that's an allowance of 6 seconds of downtime per week) so we've put lots of effort into building a stable, self-healing, gracefully-degrading piece of software. We had a few close calls though, hence the lessons learned shared in this talk.<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBcqw3Fw5xmNqbAcgfYn7nwE1RHyiSBR53uTyCF_rt0unxcmmqjhu_rosIyX21SU0_LR9dUgEX2dbRnIfPZOUIBJuLhrjAP6j1XQtZcY6gIcs8oQPwp7PchJUqzIzzHKqh9oc0/s1600/dod2014_02.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBcqw3Fw5xmNqbAcgfYn7nwE1RHyiSBR53uTyCF_rt0unxcmmqjhu_rosIyX21SU0_LR9dUgEX2dbRnIfPZOUIBJuLhrjAP6j1XQtZcY6gIcs8oQPwp7PchJUqzIzzHKqh9oc0/s1600/dod2014_02.jpg" height="240" width="320" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIjZVu2t1d_pz1t-eoEIw_KZzeMP1KWYhPI6W5oZd4N4n4V-avqt0S27pt-StYjx7r3Sqp_YpYA6Zn3ECqGyRtc_qA73wspTAWlirYIPfVLO7jMxCTKkb4EOYNItS1EdSaG67G/s1600/dod2014_03.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIjZVu2t1d_pz1t-eoEIw_KZzeMP1KWYhPI6W5oZd4N4n4V-avqt0S27pt-StYjx7r3Sqp_YpYA6Zn3ECqGyRtc_qA73wspTAWlirYIPfVLO7jMxCTKkb4EOYNItS1EdSaG67G/s1600/dod2014_03.jpg" height="240" width="320" /></a></div>
<br />
<br />
<br />
<br />
I was initially planning to cover this subject in a 30 minutes talk and had gathered tons of material to go in-depth, so delivering this material in 5 minutes was an interesting challenge! It was good actually, as it forced me to be drastically concise, while trying to preserve interesting content.<br />
<br />
<br />
<br />
<br />
<br />
If you can put up with my French accent, you can watch the recorded presentation here:<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="360" src="//www.youtube.com/embed/QEfS0z_iPoo?start=10094" width="640"></iframe>
<br />
Otherwise, here are the slides:<br />
<br />
<iframe frameborder="0" height="400" marginheight="0" marginwidth="0" scrolling="no" src="//www.slideshare.net/slideshow/embed_code/41597274" width="476"></iframe>
Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-65378294736086040642014-11-05T10:09:00.000-08:002014-11-05T10:09:58.380-08:00yopa is (almost) Your Own Personal AWSIf you're using AWS <a href="https://aws.amazon.com/sqs/">SQS</a> and <a href="https://aws.amazon.com/sns/">SNS</a> for more than trivial things, you've probably wished that you could run your queues and topics locally, and be able to peek at the message flows happening in topics subscriptions.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYnvaURTQiR7lXcHqJvrkVmFkGK73DVtEAlATcLoTiG3CmqpigFIBlsZ6VaS6RKZCkfscTxbGVihmxXXQCdK2wExO9TeQkPT-Vt64AqrwFaX2qVda6SQLxkREzvJBSLgul5cG2/s1600/yopa.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYnvaURTQiR7lXcHqJvrkVmFkGK73DVtEAlATcLoTiG3CmqpigFIBlsZ6VaS6RKZCkfscTxbGVihmxXXQCdK2wExO9TeQkPT-Vt64AqrwFaX2qVda6SQLxkREzvJBSLgul5cG2/s1600/yopa.png" height="91" width="320" /></a></div>
<br />Enter <a href="https://github.com/unbounce/yopa"><b>yopa</b></a>, a local SQS and SNS simulator whose sole purpose in life is to make developers' lives easier! <a href="http://inside.unbounce.com/product-dev/yopa/">Open sourced by Unbounce</a> and coded in Clojure by yours truly, <b>yopa</b> builds on the solid foundation of <a href="https://github.com/adamw/elasticmq">ElasticMQ</a> and adds its own SNS implementation.<br />
<br />
Granted, <b>yopa</b> only supports SQS and SNS for now so it's light years away from truly being <i>Your Own Personal AWS</i> but, hey, let's start small and see where it goes. And actually, there are already discussions about adding support for some EC2 and S3 APIs features as well.<br />
<br />
So if you're using SQS and SNS, please <a href="https://github.com/unbounce/yopa#usage">give <b>yopa</b> a try</a>! Pull requests are more than welcome.<br />
<br />
PS. Oh, there's also a <a href="https://registry.hub.docker.com/u/unbounce/yopa/">Docker image</a> available...<br />
<br /><br />Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-21891996417131470592014-04-05T09:58:00.002-07:002014-04-05T09:58:36.000-07:00I write only about funny animalsThe rabbit is out of the hat: I'm indeed working on a new book. It's called "<a href="http://www.packtpub.com/rabbitmq-essentials/book" target="_blank"><b>RabbitMQ Essentials</b></a>" and is published by PackT Publishing. Yes, you're reading right, after Mule, it's now RabbitMQ's turn! Clearly, I'm specializing in writing about animal-named technologies.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSLiJuZFb-8qBf_gPMLq0m79FZ4JCAqgunntdp0r7kxJ1GaL0q3T_fWVPfGYgGF-oZvbZ_YPWIpiAWxol1Kydxs7B0V_PLh8F_CjmT80vQDwnsFEUWaJ2ADhjtzssDGA62dJxu/s1600/Rabbit_and_Donkey.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSLiJuZFb-8qBf_gPMLq0m79FZ4JCAqgunntdp0r7kxJ1GaL0q3T_fWVPfGYgGF-oZvbZ_YPWIpiAWxol1Kydxs7B0V_PLh8F_CjmT80vQDwnsFEUWaJ2ADhjtzssDGA62dJxu/s1600/Rabbit_and_Donkey.jpg" /></a></div>
<div style="text-align: center;">
<span style="color: #666666;"><span style="font-size: xx-small;">(C) <a href="http://www.flickr.com/photos/challengeandfun/2490216702/in/set-72157605041153663" target="_blank">Kallisto Stuffed Animals</a></span></span></div>
<br />
Why writing yet another book about RabbitMQ? After all, there are already <a href="http://www.amazon.com/s/ref=sr_nr_n_5?rh=n%3A5%2Ck%3Arabbitmq&keywords=rabbitmq&ie=UTF8&qid=1396717037&rnid=2941120011" target="_blank">several very excellent books</a> on the subject out there. I think Ross Mason gave the best answer to this question on Twitter:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigYkxCqpPe4j1XTF8NQDQqd63irfobNZLZLuaGc4mdXVsUeunTqML2X20LJg_2QquPByQK8JZp_asJM6f59KMnyEBl2TzgzolsDlblIjM2F02O1n9-U2Q5PdahdxSyw8v7x8uH/s1600/rm_oss_book.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigYkxCqpPe4j1XTF8NQDQqd63irfobNZLZLuaGc4mdXVsUeunTqML2X20LJg_2QquPByQK8JZp_asJM6f59KMnyEBl2TzgzolsDlblIjM2F02O1n9-U2Q5PdahdxSyw8v7x8uH/s1600/rm_oss_book.png" height="315" width="320" /></a></div>
<br />
<br />
Let me further articulate the reasons why I decided to embark on this new book project while the ink on <a href="http://manning.com/dossot2/" target="_blank">Mule in Action</a> is still wet:<br />
<br />
<ul>
<li><b>RabbitMQ is a great piece of open source technology</b> and I think it can use all the coverage it can get. From the get go, RabbitMQ has been built with the idea to make things right: it's a breeze to install and configure. Adding extra plug-ins is a no-brainer. It's enterprise-grade software without the enterprise kludge. Moreover, AMQP is one of the rare messaging protocol that is truly interoperable so it too deserves to be discussed again and again.</li>
<li>It's 2014 and surprisingly <b>many developers still don't have a good grasp of messaging concepts</b>. Beyond covering RabbitMQ, I'm covering more general principles around building distributed applications that leverage messaging as a decoupling agent. In the book, I'm sharing the love for everything asynchronous!</li>
<li><b>I love to write</b> not only code but about coding as well. I'm not an outdoor person by any stretch of imagination, so this new book is a perfect project for the gloomy and wet winter that we get in the Pacific North-West.</li>
</ul>
The book will be short and easy to read. Its style will be conversational, with lots of questions asked to the reader. It won't be an in-depth coverage of any particular feature of RabbitMQ but will instead give a broad coverage of the broker, the AMQP protocol and some of the custom extensions added to it. The book will contain lots of code (Java, Ruby, Python) and will be articulated about the coding journey of a fictitious company that starts using RabbitMQ and see it multiply... and multiply...<br />
<br />
Hopefully you'll enjoy this journey too and will learn a few things while reading <b>RabbitMQ Essentials</b>. You can pre-order your copy right from <a href="http://www.packtpub.com/rabbitmq-essentials/book" target="_blank">PackT's website</a>.<br />
<br />
<br />
<i>Now what could be the next animal I could write about?</i><br />
<br />Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-90569706930878896792014-03-01T17:33:00.001-08:002014-03-01T17:33:09.802-08:00Explicit content required<span style="font-size: x-small;"><i>I had this post in gestation for a while but the recent post on SmartBear's blog ("<a href="http://blog.smartbear.com/programming/please-stop-staying-java-sucks/" target="_blank">Please stop saying Java sucks</a>") decided it me to finalize and publish it.</i></span><br />
<br />
I believe that it's a complete fallacy to equate "less code" with "better", this whether one is considering a language or a framework. In that matter (like in many others), I think the <a href="http://legacy.python.org/dev/peps/pep-0020/" target="_blank"><i>Zen of Python</i></a> provides the correct viewpoint:<br />
<br />
<blockquote class="tr_bq">
Explicit is better than implicit</blockquote>
Why is this important? Here is a quote from Bob Martin's <a href="http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882" target="_blank">Clean Code</a>: <br />
<br />
<blockquote class="tr_bq">
The ratio of time spent reading (code) versus writing is well over 10
to 1 ... (therefore) making it easy to read makes it easier to write.</blockquote>
<br />I'm inclined to add that <b>not having any code to read at all hinders the capacity to reason about a piece of software</b>, hence reduces the ability to work with it.<br />
<br />
One could brush aside this argument and argue that if a programmer knew better language X or framework Y, he or she should now that this or that behaviour would implicitly apply in the considered context. I would then posit that <b>readability trumps knowledge</b>.<br />
<br />
Applications tend to last longer than fashionable tools, languages or frameworks. Long after the knowledge of the intimate details of whatever technology has been deemed useless and dumped into oblivion, someone will have to read the code and maintain it. This someone will appreciate to have the capacity to navigate all the aspects of the application by following explicit seams that bind them together.<br />
<br />
When everything is implicit, an application code ends up like a novel where important points are pushed to footnotes, but without any reference to these footnotes. In that respect, I find Scala's implicits to be emblematic of a good approach to make code disappear and this because these implicits need to be explicitly used.<br />
<br />
Coming back to SmartBear's post, old Java's code signal to noise ratio is the key problem. Things are getting better release after release: noise is decreasing and thus the ratio improves.<br />
<br />
And that's the whole point of this post: throwing away the signal with the noise is not the solution. Code needs to be explicit so we can reason about it and so we can evolve it with confidence.<br />
<br />Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-2769910336676078102013-11-23T09:23:00.003-08:002013-11-23T09:23:43.372-08:00More than a language<blockquote class="tr_bq">
Nearly 300 high-level programming languages have been developed during the last decade.</blockquote>
One can only nod when reading this quote: indeed there's hardly a month without a new language being announced. The fun part is that it's the opening sentence of "A Guide to PL/I", printed in 1969! Clearly the programming community has always been prolific when it comes to spawning languages.<br />
<br />
And this trend makes sense: the tension between the need for general programming languages, which can deal with any type of problems, and the desire for specific programming languages, which best accommodate particular issues, is prone to give birth to a wide range of diverse languages.<br />
<br />
As a programmer, you therefore have plenty of choice when it comes to picking up a language for your shiny new project. Beyond the intrinsic qualities of the language, I posit that there's more to consider when deciding. Here are a few points that come to mind:<br />
<br />
<ul>
<li><b>Platform</b> - What is the runtime environment that this languages runs on? Is it mature? Is it easy to install and upgrade? Can it be well monitored in production? Does it use system resources efficiently?</li>
<li><b>Ecosystem</b> - Is there a large body of libraries available? Are these libraries mature? Does the community have a tradition for rolling out breaking changes in libraries?</li>
<li><b>Tooling</b> - Are there any tools for crafting code with this language? Any auto-formatters so SCM conflicts are minimal? Any static analysis tools? Any dynamic analysis tools?</li>
</ul>
I haven't included the "availability of developers" criteria because I think it's a red herring. Indeed, I'm convinced any programmer worth hiring should be able to pick up a new language very quickly.<br />
<br />
So if your project can accommodate risk and potential yak shaving, you can disregard these points and select a language only for itself. But for those building systems that should last and evolve gracefully, these extra criteria should be considered as much as the qualities of the language itself.<br />
<br />
Are there any other aspects you typically consider when opting for a particular language that you'd like to share?Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-771080934325355412013-04-26T14:15:00.000-07:002013-04-26T14:41:37.206-07:00Meet jerg, a JSON Schema to Erlang Records Generator<div>
I'm happy to announce the very first release of my latest Erlang open source project, <b>jerg</b>, a JSON Schema to Erlang Records Generator.</div>
<div>
<br /></div>
<div>
The objective of this project is to be a build tool that parses a rich domain model defined in JSON Schema (as specified in the <a href="http://json-schema.org/latest/json-schema-core.html" target="_blank">IETF Internet Draft</a>) in order to generate record definitions that can be used to Erlang applications to both read and write JSON.</div>
<div>
<br /></div>
<div>
I believe that having a formally defined object
model for the data that's exchange over web resources is a major plus
for APIs. It doesn't necessary imply that consumers have to generate
static clients based on such a definition, but as far as the server is
concerned, it raises the bar in term of consistency and opens the door
for self-generated documentation.</div>
<div>
<br /></div>
<div>
<b>jerg</b> doesn't deal with the actual mapping between JSON and records: there is already a library named <a href="https://github.com/justinkirby/json_rec" target="_blank">json_rec</a> for that. It doesn't also deal with validation as, again, a library named <a href="https://github.com/klarna/jesse" target="_blank">jesse</a> can take care of it.</div>
<div>
<br /></div>
<div>
This first version of <b>jerg</b> generates records with the appropriate type specification to enable type checking with <b>dialyzer</b>. It supports:<br />
<ul>
<li>cross-references for properties and collection items (ie the $ref property),</li>
<li>default values,</li>
<li>integer enumerations (other types can not be enumerated per limitation of the Erlang type specification).</li>
</ul>
</div>
<div>
It also supports a few extensions to JSON schema:</div>
<div>
<ul>
<li>extends:
to allow a schema to extend another one in order to inherit all the
properties of its parent (and any ancestors above it),</li>
<li>abstract: to mark schemas that actually do not need to be output as
records because they are just used through references and extension,</li>
<li>recordName: to customize the name of the record generated from the concerned schema definition.</li>
</ul>
</div>
<div>
<b>jerg</b> has a few limitations, like its lack of support for embedded object schemas: pull-requests are more than welcome!</div>
<div>
<br />
Enough talking: time to get started! Your next stop is <a href="https://github.com/ddossot/jerg" target="_blank"><b>jerg</b>'s GitHub project</a>. Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-1778022405425497622013-02-16T14:42:00.003-08:002014-08-19T08:34:35.791-07:00CRaSH for Mule, an introduction<blockquote class="tr_bq">
<i>This blog is the formal introduction to the CRaSH console for Mule on which I've been working for the past month or so. I've decided to interview myself about it because, hey, if I don't do it, who will?</i></blockquote>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMbD9J9eHiZXB5QAYj_AZVK6G9Tb0eAQGpwQihFqqKFaj3SiTdmBVrHGrtZD-cdSFA53G2g4YCTvtveTgSvY14bIE-wLOuEhUNQMx-5pIeLLNkc6fo8lt7XPPFYVLxSuBkJmHr/s1600/crash-splash.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMbD9J9eHiZXB5QAYj_AZVK6G9Tb0eAQGpwQihFqqKFaj3SiTdmBVrHGrtZD-cdSFA53G2g4YCTvtveTgSvY14bIE-wLOuEhUNQMx-5pIeLLNkc6fo8lt7XPPFYVLxSuBkJmHr/s320/crash-splash.png" height="60" width="320" /></a></div>
<span id="goog_523755743"></span><span id="goog_523755744"></span><br />
<h3>
What is CRaSH for Mule?</h3>
It is a shell that is running embedded in Mule and that gives command-line access to a variety of Mule internal moving parts. It's built thanks to the excellent <a href="http://www.crashub.org/" target="_blank">CRaSH project</a>, a toolkit built by <a href="http://www.julienviet.com/" target="_blank">Julien Viet</a> and sponsored by <a href="http://www.exoplatform.com/" target="_blank">eXo Platform</a>, which allows the easy creation of embedded shells.<br />
<br />
<h3>
What can we do with it?</h3>
Well, it's easy to find it out. Let's connect to CRaSH for Mule and ask for help:<br />
<br />
<script src="http://pastebin.com/embed_js.php?i=WNG73z5q"></script><br />
<br />
As you can see the range of actions include gathering information, like statistics and names, but also performing actions, like restarting a connector or even stopping the broker.<br />
<h3>
Why is it better than JMX?</h3>
Behind the scene CRaSH for Mule relies on JMX so anything you can do with it could be done with direct JMX interactions (like with <a href="https://en.wikipedia.org/wiki/JConsole" target="_blank">JConsole</a> or <a href="http://wiki.cyclopsgroup.org/jmxterm" target="_blank">jmxterm</a>). This said CRaSH for Mule has many advantages over raw JMX, including:<br />
<br />
<ul>
<li>Adds Mule semantics to JMX. You do not need to fiddle with lengthy object names do achieve what you want: CRaSH for Mule builds the right object names based on your actions.</li>
<li>Provides auto-completion, this for application names and commands.</li>
<li>Supports connectivity over telnet and ssh. No need for baroque JMX RMI connection strings.</li>
<li>All the other CRaSH commands are available. The default set of commands is very rich: to name a few, it comes complete with commands for dealing with the system, the JVM, JDBC and JNDI.</li>
</ul>
<br />
<h3>
How does it compare to MMC?</h3>
Well, it doesn't! The <a href="http://www.mulesoft.org/documentation/display/current/Mule+Management+Console" target="_blank">Mule Management Console</a> is way more capable and feature-laden, and comes bundled with the Enterprise Edition of Mule.<br />
<br />
CRaSH for Mule focuses on admin-oriented command-line friendly interactions with Mule. And it is fully open sourced.<br />
<h3>
How do I install it?</h3>
Navigate to <a href="http://www.crashub.org/" target="_blank">CRaSH's homepage</a> and locate the Mule distribution download link. You'll get an archive that contains different files, including <i>crash-mule-app.zip</i> that you need to drop in your Mule broker <i>apps</i> directory. This application contains a readme file that explains how to configure it, should the default configuration not satisfy you. You can also <a href="https://github.com/crashub/crash/blob/master/packaging/src/main/mule/README.md" target="_blank">read it online</a>.<br />
<br />
CRaSH for Mule 1.2.0-cr6-SNAPSHOT has been tested on Mule CE 3.3.1 and EE 3.3.1.<br />
<h3>
Got into trouble?</h3>
Report issues or open feature requests directly to <a href="https://jira.exoplatform.org/browse/CRASH" target="_blank">CRaSH's JIRA</a>.<br />
<br />Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-14671772419280844392012-12-27T09:38:00.003-08:002012-12-27T09:41:24.661-08:00My Final Word (Almost)In "<a href="http://www.javaspecialists.eu/archive/Issue207.html" target="_blank">Final Parameters and Local Variables</a>", Dr. Heinz M. Kabutz rants against the generalized used of the <i>final</i> keyword in Java code. For him, this is a "trend' and an "idiotic coding standard".<br />
<br />
I'm a firm believer of the complete opposite.<br />
<br />
As a software developer, I spend most of my time <b>reasoning about code</b>. Anything that can make this reasoning easier is welcome. Good practices like short methods and descriptive names fall in this category. I believe immutable variables do too.<br />
<br />
<b>Immutable variables simplify reasoning because they ensure a stable state within a scope</b>, whether it's a whole class or a single method. Having established invariants is a tremendous help in understanding code.<br />
<br />
Whether it is with my own code or not, I've experienced time and again that my mental load was way lower with immutable variables than mutable ones. Maybe it's just a limitation of my own brain power, but, to me, <b>less mental load translates in deeper understanding</b>. And to the contrary, finding out amid-function that one of its argument has been reassigned creates an intense sense of confusion, prompting to re-read the method again. And again.<br />
<br />
Of course, this isn't 100% true in Java, mainly because its default data structures are unfortunately mutable. But still, the comfort gained by using the <i>final</i> keyword everywhere, and actually letting your favourite IDE do it for you, far outweighs the small visual clutter it creates.<br />
<blockquote class="tr_bq">
<i>Unsurprisingly, I'm of the same opinion about early returns and loop breaks, but this is for another debate...</i></blockquote>
<br />
Dr. Kabutz will certainly argue that this is a matter of personal discipline or talent to ensure that one doesn't mess with invariants, because he doesn't "need the compiler to
tell [him] this". Again I disagree. I don't trust myself to be on top of things at all time so I want the compiler to tell me everything... and more. I want Findbugs to scrutinize everything I write and break the build if I've been sloppy. I want Checkstyle to reject my code if it isn't compliant to whatever standard is enforced on the project I'm working on.<br />
<br />
I do agree on one thing that Dr. Kabutz said though, which is that using the <i>final</i> keyword everywhere in printed books' code snippets is an annoyance. Indeed, books formatting rules constraints on code samples are so stringent (think 71 columns) that the rules of readability are tipped towards "less code as possible".<br />
<br />
What is your experience with <i>final</i> variables everywhere? Love, hate or ... Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-27795760566366965402012-04-21T18:03:00.000-07:002012-04-21T18:03:02.759-07:00IDlight Launched!<i>I'm super excited to announce the launch of <a href="http://www.idlight.net/">IDlight</a>, my very first <a href="http://en.wikipedia.org/wiki/Software_as_a_service">SaaS</a>. I'll promote it further after the week-end, but I wanted my blog readers to be the first to know :)</i><br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.idlight.net/img/idlight-logo-51.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://www.idlight.net/img/idlight-logo-51.png" /></a></div>
<br />
<br />
IDlight is an API that allows applications to retrieve public profile information. Among other things, it uses established and emerging standards like <a href="http://hueniverse.com/webfinger/">Webfinger</a>, <a href="http://docs.oasis-open.org/ns/xri/xrd-1.0">XRD</a> and <a href="http://microformats.org/wiki/hcard">hCard</a> to retrieve and parse public profiles.<br />
<br />
It unifies all the retrieved data under a unique <a href="http://api.idlight.net/_dtos.xsd">schema</a>, which makes it easy for applications to consume in a consistent manner.<br /><br />Please give it a try and share your feedback directly on <a href="http://idlight.net/">idlight.net</a>.Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-62713738038113064772011-11-19T10:44:00.001-08:002011-11-19T10:47:30.436-08:00QCon San Francisco - Day 3<div class="separator" style="clear: both; text-align: left;">
<i>QCon San Francisco 2011 is a wrap. I have mixed feelings about the conference and I believe I'm not the only one. Feedback forms will speak... Here are the last <a href="http://twitter.com/ddossot/favorites">tweets that I favorited</a> and that represent the ideas I grabbed from the sessions I attended. Thank you to all the twitter users I've shamelessly re-used :)</i></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9V7y0XMg8HQ_9ZUZfU3SfpTWuqxBa4ZGxK3nslpOxc3HdG9eCYbw44PZ_uQTFCsNvOTEwjFW59JzytINIyl8bM81U4SPxxu6T4ima_mYmPkNh6T7pzJliqccOaiEfICwXoN1y/s1600/qconsf-day3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9V7y0XMg8HQ_9ZUZfU3SfpTWuqxBa4ZGxK3nslpOxc3HdG9eCYbw44PZ_uQTFCsNvOTEwjFW59JzytINIyl8bM81U4SPxxu6T4ima_mYmPkNh6T7pzJliqccOaiEfICwXoN1y/s1600/qconsf-day3.png" /></a></div>
<br />Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-37792049453444986182011-11-18T08:27:00.001-08:002011-11-18T08:28:23.490-08:00QCon San Francisco - Day 2<i>My <a href="https://twitter.com/#!/ddossot/favorites">second-hand conference tweeting</a> continues...</i><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhk0Ashe-siEGnOc4-3Eb6uIPwxJ44J9eikrmKW5rWiVcksa8gUPlAbww4lc3byicAsmAZK4MTeeMIfUeV4gu3PHuMrvb_e3dm0rbPQC7v1eiJBqvHb9tWy_Ja5tEb8WPEspWK8/s1600/qconsf-day2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhk0Ashe-siEGnOc4-3Eb6uIPwxJ44J9eikrmKW5rWiVcksa8gUPlAbww4lc3byicAsmAZK4MTeeMIfUeV4gu3PHuMrvb_e3dm0rbPQC7v1eiJBqvHb9tWy_Ja5tEb8WPEspWK8/s1600/qconsf-day2.png" /></a></div>
<br />Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-34319359233379246392011-11-16T18:19:00.001-08:002011-11-16T18:20:54.218-08:00QCon San Francisco - Day 1<i>As I'm getting old and lazy, I've decided to cover QCon by <a href="https://twitter.com/#!/ddossot/favorites">favoriting other people's tweets</a> on sessions I attended and post the result as a daily chunk...</i><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjio40UcByz6imdFmmsshWMCFbbnzRKjEIqt-oism9BAuxHvhQbfkP3rb3JCDsQUJOJeciI-CIGSxJN7oLlD12ReWxFPupUiEdKndQIHJ63XQvXEpx1XOzZ8qLqwkvcoMskNmU_/s1600/qcon_day1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjio40UcByz6imdFmmsshWMCFbbnzRKjEIqt-oism9BAuxHvhQbfkP3rb3JCDsQUJOJeciI-CIGSxJN7oLlD12ReWxFPupUiEdKndQIHJ63XQvXEpx1XOzZ8qLqwkvcoMskNmU_/s1600/qcon_day1.png" /></a></div>
<br />Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-71762644050156068902011-11-05T18:53:00.000-07:002011-11-07T14:03:12.227-08:00API-First Development<span class="Apple-style-span" style="font-family: inherit;">A while back, REST advocate <a href="http://brendel.com/">Juergen Brendel</a> twitted:</span><br />
<blockquote class="tr_bq">
<b><span class="Apple-style-span" style="font-family: inherit;">API-first development: Modern dev. must consider multiple clients. Think about your REST API first, then add front end.</span></b></blockquote>
<span class="Apple-style-span" style="font-family: inherit;">I <a href="http://twitter.com/#!/ddossot/statuses/11835286686277632">retwited him</a> because I can't agree more. In fact, even if there is a single client I'm convinced API-First development is a winning approach.</span><br />
<span class="Apple-style-span" style="font-family: inherit;"><br /></span><br />
<span class="Apple-style-span" style="font-family: inherit;">I've been involved in <strike>two</strike> three API-first projects, all very different in term of domain, size and technology. But in all cases, things turned out pretty well, and, in fact, way better than with traditional approaches to web development.</span><br />
<span class="Apple-style-span" style="font-family: inherit;"><br /></span><br />
<span class="Apple-style-span" style="font-family: inherit;"><b>Clear responsibility delineation</b> - When an API gets defined, client and server responsibilities become easier to define. The API becomes the guardian of this separation of concerns, as any temptation to make concerns of one side permeate to the other will either be impossible or at least extremely cumbersome. The API will resist almost naturally to desires to pervert it.</span><br />
<span class="Apple-style-span" style="font-family: inherit;"><br /></span><br />
<b><span class="Apple-style-span" style="font-family: inherit;">Better </span>maintainability</b><span class="Apple-style-span" style="font-family: inherit;"> - Server-side front-end generation usually ends up in a pretty ugly mess where </span>presentation concerns get mixed with service concerns. Even when following the MVC pattern, the sheer fact all artifacts are contained within the same project space opens the door to nasty transfers of responsibility between layers. An API is a contract around which clients and server can evolve harmoniously.<br />
<span class="Apple-style-span" style="font-family: inherit;"><br /></span><br />
<b>Client liberated</b> - Front-end developers can use rich internet application frameworks and work on a clear interface with the back-end instead of getting constrained by a particular technology and having to deal with data transfer objects they don't fully control and which may change unexpectedly.<br />
<span class="Apple-style-span" style="font-family: inherit;"><br /></span><br />
<span class="Apple-style-span" style="font-family: inherit;"><b>Test what matters most</b> - This revolves around my <a href="http://blog.dossot.net/search/label/Testing">previous rants about what's really important to test</a>. When you expose an API, you can fully test your system as it is experienced by its different clients. There is no need for in-browser testing gimmicks. A simple HTTP client allows you to guarantee that the back-end is performing its duty and offering the front-end the features it needs. And that's what matters most.</span><br />
<span class="Apple-style-span" style="font-family: inherit;"><br /></span><br />
<b>Ninjas only</b> - This point is a little harsh but here we go: API-first tolls the bell of <i>tag soup developers</i>. This category of developers, not skilled (or experienced) enough to be doing pure server-side development nor pure front-end one, is not needed anymore. Developers building clients for a server API are experts in their domain, be it HTML5, JavaScript, Flex, Android, iOS, Phonegap or whatnot. They can't rely on "the back-end guys" to pre-chew their job and are fully in charge of what they do.<br />
<span class="Apple-style-span" style="font-family: inherit;"><br /></span><br />
<span class="Apple-style-span" style="font-family: inherit;">In API-First development, the time you reach the point of trying a </span>first<span class="Apple-style-span" style="font-family: inherit;"> connection between an actual client and the server is an </span>exhilarating<span class="Apple-style-span" style="font-family: inherit;"> moment. Sure you've been testing the back-end for a while with a simulated front-end, but when they both connect for the first time, it's party time! And amazingly, things work very well right away, all thanks to a well defined API.</span><br />
<span class="Apple-style-span" style="font-family: inherit;"><br /></span><br />
Before closing I should mention a downside for which I haven't found a satisfactory answer yet: <i>against what back-end should client developers work</i>? It is sure easy enough to expose a development-grade server to use while developing the front-end. But it's not always practical. A local server is an option, a client-specific stub is another one. Or maybe a state machine simulating the server API and allowing the front-end developer to change its state at will to easily simulate test scenarios?<br />
<span class="Apple-style-span" style="font-family: inherit;"><br /></span><br />
<span class="Apple-style-span" style="font-family: inherit;">So, what's your experience with API-first development? Any blazing success or horror story to share?</span><br />
<br />Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-59255482097349039792011-10-29T16:55:00.002-07:002011-10-29T16:55:57.960-07:00Service Oriented OrganizationsEarlier this year, I twitted this:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://twitter.com/#!/ddossot/statuses/78597979384188928"><img border="0" height="130" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsLKpdNv3cVz1K0Cxw2RqFV24QwQFGlOJ6vlHcWztzvG1HMDtXpSK_mAzhuAra8WoFN-6kUn5Kkjz15DdCOA6HWtnUTcKQydm7De-OXhiCfH2aem34QoGzRUwxw-3uJrceGMKQ/s320/78597979384188928.png" width="320" /></a></div>
<br />
and that:<br />
<div class="separator" style="clear: both; text-align: center;">
<img border="0" height="115" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhuvTUdql9v0Qmy5b9wmmFmGR6WOGl9hpaweo05hs191NPQvz7wh8E_YwAh8BV375q3k6IWnZJBPVyTjEwnMB5-uPRZWWcQU9ViNnQfNuP0oJDscldix9z5baskYDq-vLwjDEDU/s320/78847402123075585.png" width="320" /></div>
<br />
Though seemingly disconnected these tweets are actually related. So here we are, in the blink of an eye, almost five months later and I can finally find some time to circle back to these ideas and expand them a little.<br />
<br />
Both these tweets are related to the problem of growth and the pains a software company goes through when it expands.<br />
<br />
At the beginning of a company, life is good, sharing code is easy. Whether everybody sits in the same room or not, the number of people involved in coding the product is so limited that synchronization is easy. Friction is limited, things go fast. Conflicts can be resolved with beer and pizza.<br />
<br />
If by accident (!) the company ends up being successful, things change, sometimes very quickly and most of the time not for the best. So the team grows, divides into groups, and once the 150 persons mark gets passed, people start losing track of who's who.<br />
<br />
The traditional path to a graceful handling of growth consists in adding layers of management. Whether the control this approach brings is actual or illusionary, the fact of the matter is that it increases the distance between teams. Here I'm not talking about physical distance, though it may be the case, but really about the <i>perceived</i> distance, the kind of distance from which the "us versus them" mindset stems.<br />
<br />
Independently of all that, code still gets written. As the business has grown, so did the code base. Teams are sharing code. But now any code change must go through several layers of management, both up and down for each team. Fluidity has been lost in favor of process, which protects the business stability by doing what process does best: slowing things down, if possible to the point nothing happens thus preventing anything bad to happen.<br />
<br />
At this point, the sheer fact of sharing code becomes a heavy burden. In software companies, shared code doesn't typically consist of pure libraries, like Apache Commons. Shared code more often than not involves shared dependencies on enterprise resources, like databases. High level of coupling, if not tangling, exists in the shared codebase. The mismatch between the boundaries that have been cut across teams and the actual software artifacts' delineation becomes an impediment to progress.<br />
<br />
This is where the idea for a Service Oriented Organization comes from (notice how I avoided <i>Service Oriented Business</i> for obvious "acronymistic" reasons). It is not about getting rid of management or meetings. It is about <b>organizing teams around tangible boundaries that fit the needs of sustainable software development</b>.<br />
<br />
<b>In a Service Oriented Organization teams interact around well defined contracts: APIs and SLAs are the promises teams make to each other. And they fully define the actual extent of their commitments to each other. Teams do not share code but services.</b><br />
<br />
Having clear objectives in order to achieve common goals without exposing any gory details is beneficial both for people management and software development. Whether APIs expose fine-grained technical methods or coarse-grained business ones, teams will have the rabid desire to provide the best service possible for what they're responsible of, and this for functional and non-functional qualities.<br />
<div>
<br /></div>
Of course, all this sounds nice and rosy and quite possibly the wishful thinking of an utopian. The quest that many people have embarked upon is to find ways for corporates not to succumb to the illusion of control and grow themselves into dumbness.<br />
<br />
Service Oriented Organizations have been <a href="http://www.duperrin.com/english/2008/06/20/what-if-the-future-of-organizations-was-soo-or-spo/">discussed</a> <a href="http://www.castlepointe.com/20110225432/IT-Strategy-and-Innovation/Innovation-and-the-Service-Oriented-Organization-SOO-Business-Value-Through-IT-Innovation-Is-it-right-under-your-nose.html">before</a>. This is just my two cents about the concept. Please share yours.<br />
<br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-83239659921628295932011-10-22T18:11:00.002-07:002011-10-22T18:16:39.043-07:00SNMP Monitoring for ScoutHalf a year ago, I created a JMX plug-in for the <a href="https://www.scoutapp.com/">Scout</a> monitoring platform in the cloud. This time, I've created a plug-in for reading values from SNMP-enabled applications or systems.<div><br /></div><div>The plug-in is <a href="https://github.com/ddossot/scout-snmp-plugin">available on GitHub</a>.</div><div><br /></div><div>It's capable of reading multiple values or walking the tree and gather all read values.</div><div><br /></div><div>Let me know what you think of it: post bugs or feature requests here or directly in GitHub.</div>Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-12245380967335645172011-09-15T20:01:00.001-07:002011-09-15T20:03:00.952-07:00RSB (R Service Bus) at the Vancouver R Users Group<div style="width:425px" id="__ss_9276574"> <strong style="display:block;margin:12px 0 4px"><a href="http://www.slideshare.net/ddossot/r-service-bus" title="R Service Bus" target="_blank">R Service Bus</a></strong> <iframe src="http://www.slideshare.net/slideshow/embed_code/9276574" width="425" height="355" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe> <div style="padding:5px 0 12px"> View more <a href="http://www.slideshare.net/" target="_blank">presentations</a> from <a href="http://www.slideshare.net/ddossot" target="_blank">David Dossot</a> </div> </div>Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-28584658995185900142011-09-03T12:58:00.005-07:002011-09-03T13:58:04.515-07:00The loggr Erlang Client is out!I've just released <a href="https://github.com/ddossot/loggErL/tree/v1.0.0">the very first version of <b>loggErL</b></a>, my Erlang client for <a href="http://loggr.net/"><b>loggr</b></a>. In case you do not know, <a href="http://loggr.net/"><b>loggr</b></a> is a sweet piece of SaaS that offers <a href="http://docs.loggr.net/overview">a great deal of compelling log-related features wrapped in beautiful UI</a>.<div><b>loggErL</b> offers direct API calls to the <b>loggr</b> API, including support for optional fields:</div><script src="https://gist.github.com/1191767.js"> </script><div><b>loggErL</b> comes complete with a <a href="https://github.com/ahmednawras/log4erl">Log4Erl</a> appender that allows sending log events to <b>loggr</b>, again optionally supporting extra fields:</div><script src="https://gist.github.com/1191772.js"> </script><div>Feel free to fork this project on GitHub: <a href="https://github.com/ddossot/loggErL">https://github.com/ddossot/loggErL</a>.</div>Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-91993809275762092992011-07-29T15:09:00.002-07:002011-07-29T15:15:28.552-07:00Mounting Resque Web Server in Ruby on Rails 3If you want to load Resque's web server on a URL path alongside your main Ruby on Rails 3 application, no need to mess with config.ru or Rack::URLMap, as shown in different places.<br /><br />The solution is way simpler and consists in using the RoR3's capacity to mount Rack applications directly in the routes table, as shown here:<br /><br /><script src="https://gist.github.com/1114855.js"> </script><br /><br />Yep, it's that simple. Enjoy!Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-37568970305054620822011-05-26T21:55:00.002-07:002011-05-26T22:19:05.478-07:00Erlang Monads FTW!<blockquote></blockquote>A few days ago, the big brains at RabbitMQ have released <a href="http://www.rabbitmq.com/blog/2011/05/17/can-you-hear-the-drums-erlando/">Erlando</a>, a nifty pair of parse transformers that add support for cuts and do-syntax monads in Erlang. Like many others I'm sure, I've quickly started to use these new language constructs.<div><br /></div><div><span><span>Here is a quick demonstration of how the Maybe monad and the do keyword can simplify the chaining of methods. The following shows a succession of condition evaluations which must all succeed for the final function (<span class="Apple-style-span" >process_json_entities</span>) to be called:</span></span><span class="Apple-style-span" style="font-family: 'Bitstream Vera Sans Mono', 'Courier New', monospace; font-size: 12px; line-height: 16px; white-space: pre; "></span><div><br /></div><div><script src="https://gist.github.com/994663.js"> </script></div><div><blockquote>For those of you who wonder, yes I know that <a href="http://webmachine.basho.com/">WebMachine</a> could do most of this stuff for me: using this awesome REST framework is not an option for my project.</blockquote></div><div>Without the help of the maybe monad, I would have add to either nest case clauses (yuck!) or chain methods, each of them calling the next one in case of success of its condition.</div><div><br /></div><div>There are two problems with the latter approach:</div><div><ul><li>the most obvious problem is that the overall sequence of calls would not be in one place but buried deeper and deeper in the succession of functions,</li><li>the least obvious problem pertains to the classic issue of naming things: finding good names for a chain of methods, each of them testing a condition and calling the next one is very hard.</li></ul></div><div>So what's inside each of these method? Let's look into the first, which is basically a blueprint for most of them:</div><div><br /></div><div><script src="https://gist.github.com/994665.js"> </script></div><div><br /></div><div>Notice on line 4 and 7 how the <span class="Apple-style-span" >return/1</span> and <span class="Apple-style-span" >fail/1</span> method of the Maybe monad are used to influence the flow of the sequence in the encapsulating do. The values I'm passing to these two functions are purely arbitrary but it is not always the case. In the first example above, on line 5 the value passed to <span class="Apple-style-span" >return/1</span> <span><span>in <span class="Apple-style-span" >extract_json_entities</span> is assigned to <span class="Apple-style-span" >JsonEntities</span>, eventually passed to the actual processing function.</span></span><span class="Apple-style-span" style="font-family: 'Bitstream Vera Sans Mono', 'Courier New', monospace; font-size: 12px; line-height: 16px; white-space: pre; "></span></div><div><br /></div><div>To make this work, besides a Rebar dependency, not much is needed besides the following directives:</div><div><br /></div><div><script src="https://gist.github.com/994661.js"> </script></div><div><br /></div></div><div>Hopefully, this will whet your appetite and decide you to <a href="https://github.com/rabbitmq/erlando">give Erlando a try</a>!</div><div><br /></div>Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-28523964322462346982011-04-20T08:05:00.002-07:002011-04-20T08:09:06.898-07:00JMX Monitoring for Scout<a href="https://www.scoutapp.com/">Scout</a> is a very convenient monitoring platform in the cloud that I have started to use recently. I needed to monitor JMX data point, something that Scout doesn't do by default.<div><br /></div><div>One of the many shiny things about Scout is its extensibility: it is super trivial to write a Ruby plug-in and have start use it to report custom data points.</div><div><br /></div><div>Therefore, I've created a JMX plug-in which, after some QA from the awesome team at Scout, just ended up in their repository of supported plug-ins.</div><div><br /></div><div>Read more about this <a href="http://blog.scoutapp.com/articles/2011/04/20/jmx-monitoring">here</a>.</div>Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-34558322072075256642011-02-28T22:16:00.003-08:002011-02-28T22:21:02.736-08:00Put a rabbit in your HTTPI'm pleased to announce the release of <span style="font-weight:bold;"><a href="https://github.com/ddossot/rabbitmq-http-safe">http-safe</a></span>, a store-and-forward HTTP gateway plugin for RabbitMQ.<div><br /></div><div>Its goal is to simplify the integration and communication of services over HTTP by relieving systems from the chore of resending requests when something went wrong with "the other side".<br /><br /><b>http-safe</b> goes beyond the fire and forget paradigm as it supports the notion of delivery callback in order to inform the originating system of the success or failure of its dispatch request.<br /></div><div><br /></div><div>Read more on GitHub: <a href="https://github.com/ddossot/rabbitmq-http-safe">https://github.com/ddossot/rabbitmq-http-safe</a></div><div><br /></div><div><br /></div>Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-33574623741148848862010-10-26T12:17:00.006-07:002010-10-26T15:05:34.105-07:00Listen to Your Applications<div><i>Applications have lots to say. Here's how I've learned to listen to them.</i></div><div><br /></div><div>I have recently been involved in the development of a highly distributed cloud application. We were a small team and wanted to remain agile all the way through. We had extensive testing and continuous integration in place from day one giving us plenty of feedback during development, a feedback that is essential for building the right thing and building it well.</div><div><br /></div><div>But what about production time?</div><div><br /></div><div>We wanted to get feedback from this part of the application life cycle too, therefore we've decided to build and configure many different feedback sources so our application could speak to us.</div><div><br /></div><div>And speaking it did. It actually provided us precious feedback on three very different aspects of itself: <b>user experience</b>, <b>design</b> and <b>implementation</b>.</div><div><br /></div><div>I have tried to represent the different feedback sources we've baked into our application and to what domain they belong to on this lovely triangular diagram:</div><div><br /></div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjH_A0nqj6yh4rsNStrVcFIyTDdH1lj6gw6vnN6nqAtmYfDHD201X39GGfHb0qt1qUCYJWJMoztLUFTL2P2XOmwFfD15xvkgO0ltZ0doWC6HOqnFZBZxBiAVEyG3QM6xe2Owuaz/s1600/ApplicationFeebackTriangle.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 239px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjH_A0nqj6yh4rsNStrVcFIyTDdH1lj6gw6vnN6nqAtmYfDHD201X39GGfHb0qt1qUCYJWJMoztLUFTL2P2XOmwFfD15xvkgO0ltZ0doWC6HOqnFZBZxBiAVEyG3QM6xe2Owuaz/s400/ApplicationFeebackTriangle.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5532437176374375170" /></a><br /><div>Let me detail each feedback source:<br /><div><ul><li><b>Activity Log</b> - This is a detailed audit trail of each and every user action you can capture. It provides detailed feedback on your features and how you've made them usable or not. Storing this data in a <a href="http://www.postgresql.org/docs/8.4/static/ddl-partitioning.html">PostgreSQL partitioned table</a> did well for us. With higher volumes, you may want to <a href="http://www.gonosql.com/">go NoSQL</a>.</li><li><b>Error Log</b> - An embarrassing stack festival that may or may not have direct impact on the end user. No need to mention that this log is best kept empty. A service like <a href="http://hoptoadapp.com/">Hoptoad</a> can help you with that by putting errors in your face until you resolve them.</li><li><b>Trace Log</b> - This is where you take the true measure of what your application is actually doing, which is less than obvious in highly distributed applications. Logging correlation IDs and aggregating logs in a central place via <i>syslog</i> or <a href="http://github.com/facebook/scribe">Scribe</a> is a good approach. You'll need searching capacities in these logs: think <a href="http://github.com/tobi/clarity">Clarity</a> or <a href="http://www.splunk.com/">Splunk</a>, depending on your constraints and budget.</li><li><b>Response Time</b> - This is an obvious metric that will shed some light on your design and implementation. Just be sure you're logging it and paying attention to it.</li><li><b>DB TPS</b> - Though outside of the pure realm of your application feedback loop, this metric gives you a good measure on how DB intensive is your application and if it needs some redesign, like for example some low hanging fruits where caching could help.</li><li><b>Cache Hit/Miss</b> - Caching brings as much problems as it solves: a cache-happy application doesn't come for free, especially if it is distributed. Measuring the hit/miss ratio on each cache can help validate their usefulness or lack thereof.</li><li><b>MQ Throughput</b> - Monitoring of queues for high watermark thresholds is commonly done outside of the application's realm. An interesting MQ-related data an application can log is the time a message has been in-flight, including, or not, the processing time of the message after it's been consumed.</li><li><b>Activity Intensity</b> - This last one is a fun one: by representing the number of active application sessions and the current database activity, you can get a great idea of how active (or bored) are your users.</li></ul></div><div>Let me mention a single benefit of this approach: thanks to the detailed activity log, we've been able to spot design issues that were preventing users to make full use of some features. And we've been able to fix these issues not based on assumptions or wild guesses but on measured data.</div><div><br /><div><div style="text-align: left;">Your applications want to talk to you: do you listen to them? How do you do it?</div></div></div></div><div style="text-align: left;"><br /></div>Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-30308439935507882332010-10-12T21:47:00.001-07:002010-10-12T21:50:13.373-07:00Shamelessly Plugged: cferl & Mule Erlang Transport<div style="width:425px" id="__ss_5429434"><strong style="display:block;margin:12px 0 4px"><a href="http://www.slideshare.net/ddossot/cferl-erlang-transportplugs" title="Vancouver Erlang Meetup cferl & Mule Transport Plug">Vancouver Erlang Meetup cferl & Mule Transport Plug</a></strong><object id="__sse5429434" width="425" height="355"><param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=cferlerlangtransportplugs-101012234419-phpapp01&stripped_title=cferl-erlang-transportplugs&userName=ddossot" /><param name="allowFullScreen" value="true"/><param name="allowScriptAccess" value="always"/><embed name="__sse5429434" src="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=cferlerlangtransportplugs-101012234419-phpapp01&stripped_title=cferl-erlang-transportplugs&userName=ddossot" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="355"></embed></object><div style="padding:5px 0 12px">View more <a href="http://www.slideshare.net/">presentations</a> from <a href="http://www.slideshare.net/ddossot">David Dossot</a>.</div></div>Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-46888404078259925512010-09-15T20:15:00.003-07:002010-09-15T20:19:17.442-07:00DevOps: Time for Agile Operations!I've made a little <span style="font-style: italic;">xtranormal</span> movie to introduce DevOps on the blog of AgilePartner.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://blog.agilepartner.net/devops-time-for-agile-operations/"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 241px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiT6IpsY7bLSW4MB5Ivecu_t8NgjbGEEw4EPGg_3s1UTfAeJ2dqIl7k0FMg6619CHE9pvb7_sJX7dssCp0K33tXAOQ39DfwGwhyUdYd6ovAln0KMLuqS1QGfE1Y8bidjTMyKP0A/s320/Picture+2.png" alt="" id="BLOGGER_PHOTO_ID_5517345410743572722" border="0" /></a><br /><a href="http://blog.agilepartner.net/devops-time-for-agile-operations/">Go check it out</a>!Anonymoushttp://www.blogger.com/profile/13987512594987806769noreply@blogger.com