Quino 2020 Roadmap
Now that Quino 8.x is out the door, we can look forward to Quino 9.
Quino 8 is a very solid and stable release that has already been test-integrated into many of our current products running on Quino. We don’t anticipate any more low-level API changes, though there will be follow-up bug-fix releases.
There are a few larger-scale changes improvements and enhancement, outlined below (and noted in the roadmap).
Ready for Change
With this release, we’ve got more coverage than ever. Excluding only generated code (e.g.
*.Class.css in the model assemblies), we ended up with a respectable 81% test coverage. Quino has almost 10,000 tests comprising about 51k LOC and covering 82k LOC, Many, many of these are integration and scenario tests. With this level of test coverage, we feel comfortable with refactoring to improve usability and performance.
One of the primary near-term goals is to improve Quino’s documentation story. The aim is to take a new developer through the common tasks of working with a solution based on Quino.
- Setting up a solution: getting packages and creating standard projects for testing, web, and so on
- Creating a model
- Using expressions
- Using quino’s command-line tools
- Generating ORM and metadata code
- Working with business logic
- Integrating the web
- Improving the debugging experience
- Writing tests efficiently, quickly and easily using powerful base classes and tools for snapshot-based tests
Some of this documentation is currently still out-of-date or will change as we improve the corresponding components. For example:
- Anything that refers to
Nantis no longer relevant
- Some of the
quinotool documentation will no longer be relevant after 8.1 (see tools-related issue in the issue tracker)
- The data documentation is still very much a work-in-progress
Search and Index
The latest table of contents is much more comprehensive than before and we’re still improving it.
We don’t have an integrated search for the conceptual documentation yet, but you can use Google’s site-specific search. For example, search for configuration with the following search text “configuration site:docs.encodo.ch”. The top results are:
Which is pretty decent, overall.
Several of our upcoming products using Quino (two are so new that they’re not yet listed) are replacing legacy products that are highly dependent on a central database that defines the application domain. That is, the model is in the database or in a model description that is not initiallly a Quino model.
Instead of defining the model in C# code manually and then building the database from that (the standard approach with Quino), these products define the model with varying levels of automation and import and then use the existing database.
The following list shows the various ways that we’re building Quino models, in addition to the standard approach of defining them in C#:
- Import a model from Microsoft Dynamics CRM
- Import a model from a legacy DSL like the Atlas modeling language
- Import a model from the database schema itself, using Quino’s schema-import/migration support
- Map a model in C# to an existing database schema, using Quino’s new support for mapping schemas
This allows customers with existing databases to relatively quickly and easily produce a Quino model that gets them access to the plethora of features available to Quino applications (e.g. ORM, schema-check and -migration, generated GUI for desktop or web, and so on).
The LOC analyzer included in Visual Studio had slightly different numbers:
- 297k LOC (source)
- 198k LOC (docs)
- 202k LOC (source/libs)
- 99k LOC (executable)
- 56k LOC (executable/libs)
- 43k LOC (executable/tests)
Quino has almost one line of testing code per line of library code (43k/56k ~ 77%). Quino has almost 4 lines of non-executable code per line of executable library code (202k/56k ~ 360%).
The disparity between the two results (JetBrains DotCover and Microsoft Visual Studio) just goes to show what a fraught metric LOC really is. According to these two measurements, Quino has between 56k and 83k LOC of executable library code.↩