ABOUT THE AUTHOR: F. Michael "z0rtalert" Winsby is a self-identified geek, skater, performance artist, Monty Python enthusiast and chief engineer at his startup xeNify. When not drinking away his woes of a youth wasted on MMORPGs or getting yelled at by his pug-faced mail-order wife, he is blogging his way toward becoming the top-rated Scrum Ninja in the Western Hemisphere!
In Part I, we bid goodbye to outdated things like Java, collections and threads, and rewrote a sample CRUD app using the flexible new Nodules stack, with a brief introduction to the Zephram IDE. In part II of this tutorial, we learned how combining Nodules with the bit.orgy toolkit can drastically change the way you think about CRUD and ETL. Since then, several readers have written in to mention that the stack becomes significantly more powerful if the Bizsynth smeat framework is used to handle all the i/o logic.
Programmers familiar with Bizsynth's latest offerings (http://twitter.com/bizsynth) like BeefSoda and pl@stic have already come to expect the great flexibility their tools offer to the coder who is unafraid of living on the bleeding edge. For those shying away from BeefSoda's intimidating templating engine, or wanting support beyond Jython, they have spun off the smeat framework. At xeNify, I am encouraging all of our senior staff to start using smeat inside their ETL applications, and in this tutorial, I am hoping to show you why making this move is such a no-brainer.
Let's dive right into the code by picking up where our ETL sample stopped in the last part. After mapping controller addresses into the ORM portfolio, we had to design the core structure of the layer that generates the actual session bean. In Java, it would've taken us at least 200 lines of code, but the power of Nodules allows us to get away with a much more elegant solution.
[I:v] private static pure vertical [int->int:z_int]mapAddress(String address, Axiom a, Axiom b)
{
... (your vanilla axiom splicing boilerplate code goes here) ...
HashMold hm = apply(new HashMold()-> ActionFuser.getPrefuseInstance().mold(address, DynamicHashes.hash(address)));
hm.prescale(new byte[](address.length());
ByteOrbit orbit = new ByteOrbit(hm);
return orbit.transmit(@on_revaluate(orbit, sync_strategy::null));
}That's way more elegant than Java can do for us, but we can always do better - so we do! As Guillaume Theroux pointed out during his talk at JavaOne, hash molding is a powerful approach... for up to 4 non-nested axioms. We could do the nesting ourselves using a simple collection, but that's so 2011. Fortunately, the smeat bootstrap container introduced a new decorator family, which is exactly what the doctor ordered.
So, how about we sprinkle some smeat on the CRUD loader? Suddenly, our address mapper looks like this:
@Idempotent{purge=2}
private static symplectic [z_int:bijection]mapAddress(String address, MultiAxiom m)
{
... no more splicing - a MultiAxiom already takes care of it for you! ...
return DynamicOrbit.patch(@a->(a.source.layers | Bijectors.newSelfModifyingBijector(address)), sync_strategy::null));
}There's a lot of heavy lifting going on behind the scenes - which we don't need to worry about, because annotating the method as idempotent will automatically inject the proper DOFJ fabrics into all of your CRUD aspects. What's really significant here is that the new symplectic keyword takes out all the guesswork out of the painful process of deciding whether or not to use all-vertical methods, mix vertical and elevated, or glob all the business logic into pure vertical methods and post-bind any resulting latent variables. We cheat a little by giving the compiler a hint that only 2-purge resolution is required, but it is expected that later versions of the framework will take care of this for you.
Also worth pointing out is dynamic orbit patching, which is currently available in the alpha 0.7 release of smeat - but why would you NOT use the latest and greatest! Right now, lead developer Kristofer Bjørnevik promises that support for doubles and floats as return values is forthcoming in alpha 0.8, but anyone who finds that a deterrent can just go right back to coding Java.
Until next time, keep on z0rting!
I hate to get pedantic here but the DOFJ paper by @zedshaw does clearly state that you can scale to any number of Axioms in a HashMoldReduce critical section without the need for decorators. I should note that we now use a commercial SQL product to produce our graphs instead of reinventing the wheel with the whole reporting thing.