As I’ve gotten more involved with Moqui, I’ve realized that it is great for customization and building applications, but there are some parts of using Moqui that are a pain.
I’ve noticed some problems that I could fix, but I’d like to ask people on the forum about what they wish were better about Moqui. So, how could Moqui be improved?
Actual documentation. Not just in the code, but something to help developers to more quickly find answers to questions they have when it comes to chasing down problems in Moqui.
This is something I’m happy to work on, but I’m struggling to figure out where to start.
Given that there is already a significant amount of documentation, enough that only very few have read it all, and that current docs are far from comprehensive for everything that could be documented (which is infinite in theory, trying to anticipate every question that every person might ever have, not a practical goal), what is it in particular that more documentation would be helpful for?
One easier way of thinking about this: What are questions you’ve run into and have not been able to find documentation for?
Right now the biggest struggle I see is our ability to bring on new developers. Is there anything in place that we can use as a launch pad for teaching them what they need to know in order to get up to speed quickly and efficiently?
This topic can easily turn into an unproductive gripe fest, starting with thoughts that are not specific enough to be actionable. That is is a universal risk because it is easier to generalize than be specific, and easier to say “I can’t” or “I don’t know how to” than to break down a problem and identify what needs to be done and who can do it.
The only things that are impossible in software are requirements with internal inconsistencies. Everything else is just a question of effectiveness of design to meet requirements, and level of effort required to implement the design.
For pain points, the most useful part of that to discuss is the level of effort required to implement specific designs.
This might be better as a separate topic here on the forum, because training developers is a massive topic on its own and may not be the sort of pain point Michael had in mind for this topic. That said, whatever, this is all informal anyway.
From a manager’s perspective on training new developers, there is no way to get developers up to speed quickly and efficiently… or at least not that I’ve ever found.
You can do training classes, a week of dedicated drinking from a fire hose of information. That helps for sure, but the same people who have difficulty researching and discovering things on their own also seem to get significantly less out of this sort of training effort.
As a manger the main priority is making sure that the people you manage have the resources necessary to do their job. This starts with clear objectives and a definition of what their job is, which is the manager’s responsibility to define as part of the bigger picture that splits up roles and responsibilities across individuals or groups.
If you hire a developer that doesn’t know anything about Groovy, for example, plan for some time for them to learn Groovy and then support over time for Groovy related questions and issues. The same is true for Java, SQL, and of course Moqui Framework, Mantle UDM, Mantle USL, etc… each of these are large toolsets with considerable complexity and options.
If a developer isn’t doing research before starting to build something that is the first thing to ‘fix’ as a manager… the effective difference between a developer who doesn’t know a tool or business level artifact and one who does is in how much time it takes to do research before beginning development. I’ve been building this sort of software for 20 years, and personally dropped thousands of hours into building Moqui, but I still can’t do ANYTHING well without researching it first.
FWIW, there is nothing about this that is unique to Moqui. There are more and less effective ways to go about developing software, and managing software developers. There is nothing particularly complex or unique about Moqui compared to similar large scale transactional software. If a developer has never worked with large scale transactional software before it will be a challenge to get into and they will need a lot of training, time for research, and support.
If a developer has never built a web based UI in any tool, they will have a lot to learn about HTML, JS, and CSS before they can effectively work with any higher level tool. You can have a less experienced developer just learn the Moqui XML Screen elements, but do NOT expect them to be able to modify the framework or build framework extensions (like custom macros) to generate different output.
One management approach that helps developers learn a lot, and quickly, is reviews. If code/PR/etc reviews are just about formatting they are useless. The more helpful approach is to walk through the code line by line (or block by block) and what it does and why it was implemented that way, and alternative ways that it could be implemented. There is always the question of does the implementation match designs and/or meet requirements, but from a training and developer support perspective focusing on what is implemented and how it was implemented is more helpful.
If reviews are a standard part of your process, and reviews are collaborative (ie in a meeting versus async), they can be a very effective tool to not just improve code quality but also to support and train developers. Keep in mind that it takes years for a developer to become any sort of expert on complex software, there is simply too much information and too many variations depending on real world tasks to even anticipate everything a developer needs to know, let alone try to cram that into their head (using whatever means and with whatever capacity an individual has to absorb and organize information in their head).
In general software, or any tool, is only useful to the extent that the user understands it and understands the problems that it solves. For example, if a developer knows nothing about transaction management but they have a task that involves managing transactions, then the tools only matter so much because they have a knowledge gap on the general computing principles… not to mention the nature of the lower level tools in Java JTA, databases, etc.
New developers, and sometimes even experienced developers, often have trouble getting started… knowing what needs to be done technically. This is sort of the opposite of the review recommendation but looks similar, they need someone to review requirements and designs with them and chat about a general approach. Sometimes two peer developers can handle these discussions just fine, even if neither knows exactly how to go about it, and the results will at least be adequate. In that case there will often be far easier ways to go about it, and that are easier to maintain and support over time, but at least they can build something that works and can be improved over time.
Training is not something that can be done in a week or a month, maybe some initial training can be like that but for complex topics people need time and exposure to a wide variety of tasks over time. This means that the more important aspect of training doesn’t look like training at all, it is a management responsibility to setup processes and roles/responsibilities for continuous improvement, and ongoing research and knowledge sharing.
Right now the best way to find answers to questions about Moqui is this forum, and is one of the main purposes of it.
Hello, Thank you for starting this discussion and sorry for jumping in a bit late.
First of all I need to note that we are pretty much offering all solutions in moqui. This includes crazy things like video / chat real-time systems, mobile apps, and all kinds of stuff. Some of our solutions are booming in Kuwait and one of our clients is becoming a huge hit. So overall moqui is awesome and we’re happy adopting it.
Here are my main points of concern / pain
apps that supports all provided render modes (vapps, qapps, apps) for something that is dynamic and custom.<screen-extend.../> or something like that (which is awesome) but the roadmap is sort of unclear. We don’t know what to expect exactly and how to react to it.With that being said, thank you for all you’ve done. Moqui is great project.
Yes, many Pull Request are pending there and no any further comments from a moderator.
With UI customization, I find it incredibly easy to create common business screens like forms for this or that, but there are limitations of this. Trying to create something that has not been done in moqui before can get quite challenging for UI. Have you had a similar experience?
There’s a pretty easy fix for this one: Just have everyone use only one app type for custom applications (or force the usage of an app type for the custom application)
In my experience, there isn’t really a single direction that moqui is headed. I’d say that this is because it takes significant effort to produce new features and planning for what new features will come up is basically impossible. As of now, there is no cross developer system for submitting and planning for new features.
Is it a worry while using moqui that there isn’t a clear roadmap and changes / features happen seemingly out of the blue, or is it just a pain that there isn’t a clear roadmap?
I’d say that the biggest thing holding back framework, runtime, and base moqui components being contributed to is not just the quality of the code, but whether the code is compatible and useful for other people who use moqui. If it’s quality code that is beneficial for other people using moqui, then feel free to submit a PR and I’d love to go over it and submit my feedback about it.
@NickDragon When you say:
What kind of struggle are you talking about?
Do you mean something like:
I have the ability to hire new developers, and I’m able to find developers interested in working, but the developers are struggling to understand the concepts of Moqui?
Because that example is very different from something like:
I don’t have the ability to hire or find new developers.
The first example is a technical problem, while the second example is a business problem.
A technical problem is something that should and can be discussed here while probably not a business problem.
Do you have examples of the kinds of thing that should be documented? That’s really the first step.
Hello @michael
Thank you for taking the time to sift through all of this.
So to be brief:
With all of that being said, I will attempt to maybe create small PRs here and there and see if I can work my way up from there since you opened the door for us to try (thank you).
@michael I’m right there with you. Can’t figure out where to start to make the best impact. Maybe we just need to pick something and get going on it?
Do we know where developers are doing the most work right now? Maybe we can use the community to help us identify and prioritize a list.
-Nick
Those who wait for me, assuming I have agreed to something that I have not, will have a long wait.
- Yes I agree that it is incredibly easy to create common business screens. The problem is in the custom stuff. As you mentioned creating something that does not exist in moqui is where it becomes challenging and there are a quite a few things we need that fit that category.
It’s just Java and a bunch of common libraries underneath, are you saying it is MORE challenging than just using those tools for some reason?
- Sticking with only one render-mode means we lose on being output-agnostic. what if we want to switch in the future? or what if we deprecate one of the render modes or it receives much less attention? We prefer to write the code in an output agnostic way or at least be able to extend the render-specific modes and alter the structure of it. I’m not sure if this is moqui-specific or just the nature of things, but hey I’m just relaying my experience.
Why on earth would you build a highly dynamic or complex UI and target multiple render modes?
If you want to switch in the future, switch in the future… why worry about it now when it’s a great big unknown?
- So you hit the nail right on the head with regards to contributing. You said that the biggest thing holding back contributions is “whether the code is compatible and useful for other people who use moqui”. Knowing what that would be IS the challenge. How can I start contributing if I’m not sure of where we want to “push” so to speak. The only way to know is to try and be guided with feedback. Without guidance or feedback (especially in discussions in the forums / mailing list) I just do not have confidence to make PRs because I might start thinking maybe they don’t want this or don’t want that and I don’t want to just waste time so we keep developing locally.
With all of that being said, I will attempt to maybe create small PRs here and there and see if I can work my way up from there since you opened the door for us to try (thank you).
Contributing will always be a challenge, by design. Is that a bug, or maybe a feature? What is so critical that is missing that needs to be added for Moqui to be viable? What must be in the open source projects that you can’t do in any other way?
You can build anything you want and post it and share it on GitHub or many other places. The Moqui open source projects are intentionally strictly moderated. There are too many users of Moqui with too much on the line to be casual about that. FWIW, I don’t want Moqui to ever turn into OFBiz where contributions are moderated through all the time without sufficient discussion, review, and testing.
For the open pull requests and issues… I could go out there and be REALLY HARSH and just shut them all down. I prefer to leave them open with comments to see if they’ll go anywhere, and if anyone (other than me and the initial contributor!) wants to do something with it.
If that comes across as no moderation going on, look a little deeper… look at all the closed PRs, not just the open ones. Look at the long history.
As for scope and what makes sense to contribute… PLEASE don’t start with a big pull request! Ugghhh… I HATE those. Someone makes dozens of assumptions and decisions and implies that it’s the way to go without defining or describing anything, asking me to dig through and ferret out the garbage, and then complain when I don’t like it.
The place to start is… wait for it… COLLABORATION! Discuss publicly, and very specifically, what is it is you need or what it is you want to build. If there is not feedback, no replies and engagement, then no one cares. You may find it important and it’s worth building to you, but maybe not to anyone else who both sees your message and has a similar need at that particular time. I guess patience helps too…
The harsh truth of the world is most people don’t care about most things, and it is very difficult to rally volunteers around any particular things. It is not reasonable to expect people to care about everything all the time, I try that sometimes here and there… part of why I’m rather broken in the head. I don’t recommend it.
As for what to expect: EXPECT NOTHING! You’ll be a lot happier.
I’ve explained many times how things get into Moqui, based mostly on how I work in an open-source-first way. Others could do that too, but I warn you now: it is a a difficult thing that most could not do, and often a hell I would not wish on anyone.
Without operating open-source-first, does it even make sense to try to re-design and re-factor very custom solutions to make them open source? Usually not… but you can always release it in your own public repository on GitHub and find out!
Hi @jonesde
Thank you for spending time and energy on this discussion which I value and learn from. A quick feedback:
Again I thank you for all the feedback and pointers which are highly appreciated.
Hi @taher ,
I appreciate your sentiment, wanting to pay back. I don’t know that it’s possible to pay back because there is nothing to pay back, and sounds like you’re thinking along these lines anyway, that there are plenty of opportunities to pay forward.
What would be helpful to others to pay it forward? I suppose the very things discussed here provide some opportunities, ie: review and comment on issues and pull requests, contribute to documentation (more formal and structured on moqui.org or less formal and unstructured right here in the forum), contribute automated tests to help maintain quality over time, etc.
For new ‘feature’ or maintenance development there are some open PRs and branches in moqui-framework that represent in progress efforts. While I’d like to do more this way, for most of what I work on there simply isn’t time for me to let things sit hoping a volunteer will help… I’m on contracts and have to deliver, and then have to move on to the next thing and deliver, rinse repeat.
My clients are great to work with and also want to pay forward, so I have some influence on what is built and when, but ultimately my clients decide what to prioritize. That is how it has always been, and perhaps is how it always will be… and I don’t think it’s a problem, even if inconvenient for volunteer collaboration. There are some huge benefits to this, including keeping Moqui aligned with real-world needs of groups that themselves have to deliver real-world product.
I know this is getting off topic a bit from your comments, but realized that earlier I didn’t address the issue of a roadmap.
I suppose one way to thing of it is: roadmaps are for products. Moqui is NOT a product. Moqui is a project… a forever ongoing, forever evolving, and forever (hopefully!) improving project to facilitate collaboration and build a shared base that can, perhaps, even just a little, make our lives better and easier as people who deliver software solutions.