Very interesting and inspiring post. On Fri, Jul 29, 2011 at 12:36 PM, Rickard Öberg <[email protected]> wrote:
> When me and Niclas started this project a long time ago, And many things changed and was added along the way... ;-) > So that's pretty much it. Good stuff. There's only one problem. It takes > quite some developer to understand one of these things, and a very decent > developer to understand all of it, and then a really good developer to > actually be able to implement it without making a mess. There is probably only one developer who is capable of thinking in pure roles, and I wonder if that is even possible when you are not an expert in the domain itself. Most domain experts thinks in terms of "things" and then a divergence of one of data manipulation, math/algorithms, actions. The CQRS mantra of "Commands" and "Events" seems to be easy-enough concepts to introduce to domain experts, but modeling in "roles" is really really tough. > A bigger issue is that the level of developer it takes, at any point in > time, to architect a good Qi4j app is just too high. And then you need to > teach the developers on the team how to do it. I've done it now with my > devs, and I know Niclas has had great success on his side (in spite of > initial ruffling and sneering), so it is possible. I chose to NOT introduce the developers around me to anything beyond "things" with Property, Value, Service, Entity, and only Mixins. Then allowed them to "discover" advanced features by "accident" looking at code that I wrote. For instance, I created a metrics subsystem, that measures the execution time of methods, and which mixins to measure are added at assembly. When one guy saw that, he went "Wow!!!"... > Then there's the competition. What is the competition? The way I see it you > have JavaEE and Spring on the one end, and then new-kids-on-the-block like > Rails on the other. JavaEE is "standard", and Spring is becoming a de-facto > standard. Everybody "knows it", and it shows up in job CVs and descriptions. It is an amazing marketing stunt that Spring has managed. Not only do they claim that your code doesn't depend on Spring itself, but they also claim that everyone understands it automatically. We have heaps of libraries that uses all the Spring magic in the book, and without it nothing can be made to work. And with all components being XyzAware something, means that even a small utility library brings in the entire Spring stack (bad packaging on our part though). > The Rails guys seems to be banking a lot on the "get up and running quickly" > train. It is very very impressive. Even to a hard core "no other language" old fart like me. Java EE tooling is also trying to get to that. And sometimes I think "maybe they are right, maybe most apps are simple enough...", then I realize "but then the main time spent is not on coding, but other things like deployment". > What separates Qi4j from these frameworks is that, IF we have app > templates, not only would you be able to get up and running fast, but AFTER > the first version you would actually be able to grow without too much pain. > Support for refactoring, JMX and admin, CircuitBreakers, and other > evolution/admin features, gives us an edge, along with the modeling > possibilities that just aren't there in other frameworks. Our "post get-go" case is really really strong, unlike Rails, which either can do it, or you are back to "on your own" and need to integrate into the Rails structures, which may or may not suit the (non-Rails suited) application. My worry is; IF we have a Rails like approach to the "get up and running quickly", would that mean that many developers will get "shocked out of their pants" when they leave the "protected environment" and venture into "native" Qi4j?? > So what gives? My thoughts, and here's where I need your feedback, is that > Qi4j 2.0 should focus on simplicity and productivity, as well as feature > completeness. Simply Productive! > * Templates for common app structures, where developers "fill in the > blanks", e.g. "domain goes here, app services here, REST goes here". Not sure what you mean by 'templates'. Before we start that, we would need to categorize N application types, since a consumer webapp would be radically different than a financial messaging system. > Convention over configuration, but architecturally as well as on the code. One thing that I would like to change is the @UseDefaults and @Optional. The person that writes the code, for instance an Configuration type, doesn't know whether the user wants to rely on defaults or not. I have not analyzed the exact need, but I think @UseDefaults should simply 'go away' and IF it is declared in bootstrap, then default value will be used if nothing is specified. > With the recent ClassScanner tool, this can even be "put these kinds of > classes in this package", and the ClassScanner can pick them up > automatically. I also think we should reconsider the "Layered Architecture". We know that the "Onion Architecture" is often a valid case, and I think we should support it much stronger. This would impact quite a bit and I wonder if the architecture can (I would like it to) be pluggable. Worthwhile serious investigation. > * IDE plugins. We have Envisage now, but it is getting outdated. I would > like to change it into something like a IDEA plugin where you can click > "Refresh" (like the Gradle plugin) Yes. Envisage also suffers from a deadlock bug in Prefuse. Need a large revamp of the whole approach. The IDEA plugin has also been bit-rotting for quite a while. There was some good features in there, such as inspecting if any missing mixin methods. And we had a huge list of good stuff one could add. Just that I am not good at plugin development. With IDEA gone open source licensing (Apache License some more!!) on the Community Edition, I think we have less incentive to support Eclipse as a "must have". > * Support for traditional technologies, specifically on the DB side. We need > to support storing data in SQL databases easily, for the simple reason that > admins know how to manage and backup these critters. As simple as that. They > can also provide scaling features, if necessary. I thought the SQL entity store is pretty straight forward. I have not used it, and perhaps we need to improve it. But perhaps you are talking about Mapping, which is a much more complex matter. > * More support for NOSQL. Adding e.g. CouchDB and MongoDB should be trivial. I think they are not trivial from testing point of view. ie. how hard is it to auto-download and start each of these to run the tests against them? Similar problem to the SQL entity store, which one would like to have tested against as many DBs as possible. > * Support for standard JSR's, such as 303 (Validation) and 330 (Injection), I have not looked much at either of these. On Validation; I would like add Post-Condition checks as well. > * Documentation. I've said this before, and I suck at doing it, but it's > still important. Documenting the basics, as well as common patterns. I still > feel like we need some kind of wiki-style website for this to be really easy > to do. YES! I am not convinced that Wiki-style website will be any more successful than SiteVision. It isn't the tool, but the editors. Sure, we say "If I had this tool instead, then I would...", but I think that is partly a matter of excusing oneself. Instead, I think versioned docs at source code level is better. Not when it comes to marketing and all of that, but to get all details of all features on digital paper. And as a measure of enforcement, prohibit check-ins to 'develop' on any code that doesn't have Javadoc on all public methods for instance. All packages must have at least N words in package-info.java, and so on... It is a difficult topic. No one likes to do it, I have been forcing myself many many times, but it is a chore I am not happy doing, especially since the need is massive and after spending one whole day writing docs, it isn't a noticeable difference. > * Getting a full stack. Again, that would depend on "application type". For instance, you use methods as "Commands" where as I use "Command Objects", which would require a different "stack". Since my project at work is now cancelled, I will try and re-implement some of the grid features that I put in place there; * Trails - Command/Event sequences which recorded method calls and log statements in a 'trail' so one could troubleshoot a single 'invocation' (for instance a timer tick). * Commands - Command Objects are dispatched to the node where the Aggregate Root resides and execute there to reduce network traffic. Full recoverability in case of JVM or hardware failures. * Events - Many grid nodes subscribe to the same event at the same location in the code. But most often one only wants one of the event handlers to receive it, typically resulting in further processing. * Limited Service - Often one need to run a reduced number of services, when all deployed uniformly on all machines. For instance, number of DB connections are limited. > So those are my thoughts on this. Is it doable? Or should I give up on this? Doable! We have overcome bigger hurdles than this before... Question is how much help we can get from the peripheral supporters of Qi4j and if we can entice some 'new blood'. > Is it possible to get any meaningful "marketshare" with Qi4j, if v2.0 has > all of the above? What is important? I think that 2.0 should be a Core Feature release, meaning the changes to the type system, all the incompatible changes we need to make, perhaps the support for "Onion Architecture" and similar. Once that is out, we focus 2.1/2.5 on the "Stack", "Fast Track", "Integration" and "Tools". And I think I need to get out of my current fulltime job. It really sucks my energy dry. Even weekends are ruined, and I just want to lay in sofa and do nothing. Perhaps it was a bad idea to give up CodeDragons. Anyone out there who wants to sponsor Qi4j development by hiring me full time? ;-) Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
