Hej, Rickard, I continue to lurk on this list, as I continue to be VERY interested in what is going on. I still think that Qi4j is a BRILLIANT idea, and the way you guys have been developing this (smart theoretically AND practically) is optimal.
Since what I said about Qi4j being 10 years ahead of its time was about 2 years ago (more??), now I can say that I think it's about 7-8 years ahead of its time. :-) If I remind you of the original idea (at least as I remember it), you guys were going to build this super duper productivity platform in order to base a company off of it. Niclas always said how he thinks that 1 smart programmer with smart tools (i.e. Qi4j) could be 10-50x more productive than an average programmer with average tools (sorry if I remember the numbers incorrectly, but you get the idea). So, instead of worrying too much about features and getting market share for Qi4j (which is very difficult, and requires different expertise), why not go back to the idea of building a super-productive software business based on Qi4j? People will see the results and say "wow, how do you guys DO all this AMAZING stuff?" Then they will want to copy, then you have a story to tell. IIUC, that's kinda how Rails got started. I know I want to do something based on Qi4j. I _almost_ have my shit together to be able to get started, but still need some more time. I still believe it's the right thing to do. Anyway, just my 2 Yen (seems to be worth more than cents these days). Cheers, =David On Jul 29, 2011, at 1:36 PM, Rickard Öberg wrote: > Hi, > > I'd like to ask the question of what is the point with Qi4j, with the > software framework landscape being as it is. I'd very much like your feedback > on the questions and assertions below, to see if it makes sense. > > When me and Niclas started this project a long time ago, there were a couple > of different things that I personally wanted to address. First of all it was > the composite notion, that a domain object should be able to use mixins, not > only for code but also state. Being able to use a roles-oriented approach > significantly helps when building real-world applications. I think the theory > behind e.g. DCI validates this quite a bit. Some of you know the backstory > that in 2002 I tried using JBoss/EJB to build my first enterprise app > (SiteVision), and gave up after two weeks. It just wasn't possible. And then > I *had* to create the forerunner to Qi4j, just to "get stuff done". I don't > know how other developers can take the pain involved with standard modeling > tools and ORM's and all that nonsense, but that was my experience anywa. > > Another goal was to try and make AOP simpler. The ideas behind AOP are good, > but AspectJ, as the main implementation, is just too complicated. The > approach we adopted in Qi4j, with concerns/sideeffects being registered on > the composites, made it much more explicit where these things go, and makes > it in the end easier to read the code. We now have the option of specifying > these in the assembly, as well as role types and mixins, so if you want you > can apply application-wide concerns quite easily. It all ends up in the model > anyway, which can be visualized. > > Then, I also wanted to support DDD better. DDD in itself is mainly a process, > which technically doesn't require a framework, but by adopting some of its > terminology, specifically Entity, Value, UnitOfWork, etc. we make it easier > for those who want to do that. > > And finally, I have always been frustrated with Worditectures, where > architectural layers and modules are only in a Word document, and not in > code. If these constraints are not enforced at runtime, it's too easy to > break these things, which is not so good. > > 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. David Leangen said to > me that "Qi4j is 10 years ahead of its time". In part that was true, as some > of the theoretical background, such as DCI, is only now being explored. 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. > > Qi4j is also like an empty Word document. You can do anything, but if you > don't know where to start, it's a bit daunting. Now that I've done Streamflow > I can see a general pattern for how to do it, and making another app like it > would be much easier. In other words, one of the things we're lacking is a > decent template, or "scaffolding", for apps, where you can more or less just > "fill in the blanks". Most frameworks these days do this, and it would make > sense for us to have this as well. > > 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. > The Rails guys seems to be banking a lot on the "get up and running quickly" > train. 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. > > 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. This means: > * Templates for common app structures, where developers "fill in the blanks", > e.g. "domain goes here, app services here, REST goes here". Convention over > configuration, but architecturally as well as on the code. 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. > * 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), and it would show you what your app looks like. Now > that assembly is getting to a point where you don't necessarily have to > instantiate the app that is created, this should be relatively easy > * 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. > * More support for NOSQL. Adding e.g. CouchDB and MongoDB should be trivial. > I don't know how much these are actually used, but adding them as > EntityStores should a simple exercise, so why not? > * Support for standard JSR's, such as 303 (Validation) and 330 (Injection), > should be reasonably easy to do, and lowers the learning curve on these > things. Validation and Injection is a big part of every day work, so this is > important. > * 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. > * Getting a full stack. The main missing point to get a "full stack", as it > is, is the REST part. I have this, and can port it to Qi4j, so that should be > doable. Once that is in place we have a good end-to-end stack for building > apps, I think. > > So those are my thoughts on this. Is it doable? Or should I give up on this? > Is it possible to get any meaningful "marketshare" with Qi4j, if v2.0 has all > of the above? What is important? What is not important? What do you guys > think? > > regards, Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
