This page shows the source for this entry, with WebCore formatting language tags and attributes highlighted.


Quino 2020 Roadmap


Now that <a href="">Quino 8.x is out the door</a>, 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 <a href="">products running on Quino</a>. 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 <a href="">roadmap</a>). <h>Ready for Change</h> With this release, we've got more coverage than ever. Excluding only generated code (e.g. <c>*Metadata.cs</c> and <c>*.Class.css</c> 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<fn>, 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. <img src="{att_link}quino_8_81_percent_coverage.png" align="none" caption="81% Coverage for Quino 8"> <h>Documentation</h> 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. <ul> <a href="">Setting up a solution</a>: getting packages and creating standard projects for testing, web, and so on <a href="">Creating a model</a> <a href="">Using expressions</a> <a href="">Using quino's command-line tools</a> Generating <a href="">ORM</a> and <a href="">metadata</a> code Working with <a href="">business logic</a> Integrating the <a href="">web</a> Improving the <a href="">debugging experience</a> <a href="">Writing tests</a> efficiently, quickly and easily using powerful base classes and tools for snapshot-based tests </ul> Some of this documentation is currently still out-of-date or will change as we improve the corresponding components. For example: <ul> Anything that refers to <c>Nant</c> is no longer relevant Some of the <c>quino</c> tool documentation will no longer be relevant after 8.1 (see tools-related issue in the <a href="">issue tracker</a>) The <a href="">data documentation</a> is still very much a work-in-progress </ul> <h level="3">Search and Index</h> The latest <a href="">table of contents</a> 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 <i>configuration</i> with the following search text "configuration". The top results are: <ul> <a href="">Configuration</a> <a href="">Configuration System</a> <a href="">Quino Application Configuration</a> </ul> Which is pretty decent, overall. <h>Database-first</h> Several of our upcoming products using Quino (two are so new that they're <a href="">not yet listed</a>) 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 <i>initiallly</i> 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 <a href="">defining them in C#</a>: <ul> <i>Import</i> a model from Microsoft Dynamics CRM <i>Import</i> a model from a legacy DSL like the <i>Atlas</i> modeling language <i>Import</i> a model from the database schema itself, using Quino's <a href="">schema-import/migration support</a> <i>Map</i> a model in C# to an existing database schema, using Quino's new <a href="">support for mapping schemas</a> </ul> This allows customers with existing databases to relatively quickly and easily produce a Quino model that gets them access to <a href="">the plethora of features available to Quino applications</a> (e.g. ORM, schema-check and -migration, generated GUI for desktop or web, and so on). <hr> <ft>The LOC analyzer included in Visual Studio had slightly different numbers: <ul> 297k LOC (source) 198k LOC (docs) 202k LOC (source/libs) 99k LOC (executable) 56k LOC (executable/libs) 43k LOC (executable/tests) </ul> 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.</ft>