Why is SagaBase generic in Jonathan Oliver's CommonDomain library?
That has more to do with a poor design decision related to an assumed dependency on NServiceBus. CommonDomain was actually a bunch of spike code that worked so well, that I started using it in production. I was using NServiceBus which requires that all messages implement IMessage. As a result, SagaBase requires some kind of type, e.g. IMessage. In the coming weeks, I will be overhauling CommonDomain and perhaps inlining critical parts of it into the EventStore. For now, you can just use AggregateBase if you'd like.
Related
I found many options recently, and interesting in their comparisons primarely by maturity and stability.
Crunch - https://github.com/cloudera/crunch
Scrunch - https://github.com/cloudera/crunch/tree/master/scrunch
Cascading - http://www.cascading.org/
Scalding https://github.com/twitter/scalding
FlumeJava
Scoobi - https://github.com/NICTA/scoobi/
As I'm a developer of Scoobi, don't expect an unbiased answer.
First of all, FlumeJava is an internal google project that provides a (awesomely productive) abstraction ontop of MapReduce (not hadoop though). They released a paper about it, which is what projects like Scoobi and Crunch are based on.
If your only criteria is the maturity -- I guess Cascading is your best bet.
However, if you're looking for the (imho superior) FlumeJava style abstraction, you'll want to pick between (S)crunch and Scoobi.
The biggest difference, superficial as it may be is that crunch is written in Java, with Scala bindings (Scrunch). And Scoobi is written in Scala with Java bindings (scoobij). They're both really solid choices, and you won't go wrong which ever you choose. I'm sure there's quite a similar story with Crunch, but Scoobi is being used in real projects and is under continual development. We're pretty very active in fixing bugs and implementing features.
Anyway, they're both great projects with great people behind them and were both released within days of each other. They provide the same abstraction (with similiar api), so switching between the two won't be an issue in the slightest. My recommendation is to give them both a try, and see what works for you. There' no lock in in either project, so you don't need to commit :)
And if you have any feedback for either project, please be sure to provide it :)
I'm a big Scoobi fan myself and I've used it in production. I like the way it allows you to write type-safe Hadoop programs in a very idiomatic Scala way. If that is not necessarily your thing and you like the Cascading model but are scared off by the huge amount of boilerplate code you'd have to write, Twitter has recently open sourced its own Scala abstraction layer on top of Cascading called Scalding.
Announcement: https://dev.twitter.com/blog/scalding
GitHub: https://github.com/twitter/scalding
I guess it's all a matter of taste at this point since feature-wise most of the frameworks are very close to one another.
Scalding also has the advantage of significant open source projects built atop it, such as Matrix API and Algebird.
Here are some examples:
http://sujitpal.blogspot.com/2012/08/scalding-for-impatient.html
Cascalog was released almost two years before Scalding, and arguably has more advanced features for building robust workflows:
https://github.com/nathanmarz/cascalog/wiki
For a project I'm using both Scala and Riak (two things I have never worked with before ;) ).
Google searches seem to suggest using Riakki. However, it seems like that particular library hasn't been maintained since 2009 and doesn't even compile on my system. There is a more up-to-date fork on GitHub that does seem to work with more recent Scala versions. But Riakki seems to depend on Jiak, which has been deprecated since february of last year.
Seems like the only reasonable choice would be to use the official Riak Java-library from Scala. That's certainly possible, but I'd like to do things the Scala-way as I'm trying to learn the language. Having to interface with a Java-style API might ruin a bit of the fun. Writing my own wrapper sounds like it will be too much work.
tl;dr: I want to use Riak from Scala. What are other people using?
edit: just found Ryu (can't link to it - annoying limit on amount of hyperlinks per question for new users). Doesn't seem all that mature though.
Stackmob recently opensourced Scalariak.
Scaliak is a scala-ified version of the High-Level Riak Java Client w/
a Functional Twist. It is currently being used in production at
StackMob.
Scaliak is currently feature incomplete vs. the original High-Level
Riak Java Client. What is currently supported are mostly features
being used in production (there have been a few features implemented
and subsequently not used).
There is also Raiku which states that it is async.
I'm in the same bucket - excuse the bad pun - although I have some experience with Scala. I'm thinking of using the official Java client.
When you are toiling up a steep learning curve, you don't need to be dealing with incomplete and potentially wobbly API's. In my experience, using Java API's from Scala is minimally painful.
I think there'll be enough delight in playing with our new Raik toy that we'll forget about whatever un-Scala-ish foibles the Java API inflicts upon us. All the best.
I'm the author of yet another Scala Riak client, simply called riak-scala-client. It is based on Akka and Spray, it is not built on top of the existing Java client, and most importantly it is completely non-blocking.
Check it out at http://riak.scalapenos.com and let me know what you think.
This thread introduced two different approaches to a fundamental need of every web-app - email-based interactions with a site's users - the uses the term MailManager. I'm currently suffering the pain of a poorly designed, first gen attempt at generating (and sending, and logging, and searching) things like invoices, notifications, followups and tracking. Stuff that wasn't in the original spec. I understand the need to refine things to use a more generalized controller.
So i'd like to study how this functionality has been implemented in other projects. Is this role generic or well defined enough that perhaps one of the codeplex or git projects (or an MVC-based tutorials) has a fleshed out example?
I was trying to find an answer for my question today using google and StackOverflow search engines... but no luck :)
I was wondering what are the key features of every framework for end user, and how can you characterize every framework from the end-user point of view (I've looked into Framework Design Guidelines by K. Cwalina, but I've found only concepts and guidelines for framework architects), for me:
it should be extensible
should let build extensible and reusable components
and of course : Simple things should be simple, complex things should be possible. (http://en.wikiquote.org/wiki/Alan_Kay)
I think there is much more out there.
Please share your knowledge.
Here are two good quotes from Ralph Johnson and Brian Foote
A framework is a reusable, ``semi-complete'' application that can be specialized to produce custom applications
One important characteristic of a framework is that the methods defined by the user to tailor the framework will often be called from within the framework itself, rather than from the user's application code. The framework often plays the role of the main program in coordinating and sequencing application activity. This inversion of control gives frameworks the power to serve as extensible skeletons. The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application.
There was a special issue of CACM that you might want to take a look at too.
Here's one more link The Hollywood Principal. "Don't call us, we'll call you." About how the framework inverts the typical control so the framework calls your code instead of you calling some library code.
It sounds like you just want to know what is the defining characteristic of a framework...?
From FOLDOC:
In object-oriented systems, a set of classes that embodies an abstract design for solutions to a number of related problems.
So basically, a class library ("set of classes") that's extensible ("embodies an abstract design"),
I'll attempt a definition based on my own understanding: A framework is a body of code that abstracts a subset of tasks common to some classes of application programs. The intent is to provide, once, proven and tested code so that application programming doesn't have to keep re-inventing code for the common tasks handled by the framework.
In real life, frameworks often spring into being when a programmer or team get carried away with generalizing and future-proofing what started out as a single application. There's an honorable intent to start code re-use, but it often turns out that such frameworks aren't designed with intent from the beginning, don't have consistent design reflecting this intent, and are actually lousy code that ends up not being re-used at all. Most architects who feel qualified to create frameworks, aren't.
The difference between libraries and frameworks: You call libraries. Frameworks call you.
Answering your question covering the depth it deserves is beyond the scope of this forum. All you should do is read this book though its focused on .Net frmaework specifically and written by the designers of the .Net framework, I'm sure the wisdom and information that this book provides would be sufficient to answer your question and satisfy your curiosities on the subject.
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition)
alt text http://www.lybrary.com/images/0321605012.jpg
A Framework is for me a other name for a Library (like Boost and many others) that is not about only one Topic (there are Librarys about Math, Networking, whatever out there, but these are no Frameworks) and it is of course Extensible and you can combine the Features of it to do your Job.
I'm faced with writing a framework to simplify working with a large and complex object library (ArcObjects). What guidelines would you suggest for creating a framework of this kind? Are static methods preferred? How do you handle things like logging? How do you future proof your framework code from changes that a vendor might introduce?
I think of all of the various wrappers and helpers I've seen for NHibernate, log4net, and code I've read from projects like NLog and NetTopologySuite and I see so many good approaches, but honestly I'm at a loss where to start.
BTW - I'm working in C# 3.5 but it's more about recommended approach rather than language.
Brad Abrams' Framework Design Guidelines book is all about this. Might be worth a look.
Try to write code to be more flexible. For example, if you have a method that accepts an array as a parameter, would you be able to accept an IEnumerable or IList instead?
I think that you're consistent is more important than what conventions you go with. As far as future-proofing yourself, that's a matter of the code that you're making a framework for. It's a lot easier to build on a brick house than a sand one.
Writing code for framework is absolutely very different from writing application code.
I have always consulted (and have others consult) the Design Guidelines for Class Library Developers when writing framework level code.