Mark Stephen Sobkow's Projects at github.com   

Welcome to my project history page; there really has been only one project I've worked on since the late 90's other than projects for employers. I recently decided to eliminate my initials from the name, and clarify that it is a code fractal rather than a "factory." It doesn't "manufacture" anything but source code that is ready for integration, given a valid model and rule base defining how to map the model to code.

Mark's Code Fractal is a tool used to accelerate the production of the repetitive code that comprises 75-85% of the typical enterprise business application - the "glue" between the business logic programmer and the backing data servers and databases. It does so by applying a knowledge base of General Expansion Rule (GEL) files following specific XML document schemas and semantic constraints to a Business Application Model (BAM), which is at it's heart an enhanced ERD defined as an XML document following yet another schema specification.

The BAM defines the tables, indexes, and relationships of an ERD, including Superclass, Container/Component, Parent/Child, and Lookup relationships. It also provides the means of encapsulating customizations of the output source code, though the approach for that will change radically for Mark's Code Fractal 3.1 as opposed to MSS Code Factory 2.13, allowing for much more flexibility than the current hard-coded approach to such customizations.

I invite you to read through the prototype architecture and philosophies, and through the 2.11 documentation. Although seriously stale about the details, most of the key concepts and descriptions about how the CFCore engine works as described in the 2.11 documentation are still valid to this day.

I'm currently refreshing and refactoring my code base to support generic Java clients, take advantage of the latest Java features, provide back-end Spring web services initially using JSON to replace the old XML message protocol, and later replacing JSON with a byte-stream client if at all feasible. Along the way, the databases have been split up into isolated instances with the Obj layer providing a unified view of the component database hierarchy. That way each data silo can retain control over its own security concerns, subject to unified identification and authorization of users through the CFSec packages and services at the bottom of the stack.

CFSec itself may well become an OAuth2 service provider by the time I'm done, too, which I don't expect to be for quite some time, possibly not before 2027. As such, this code is very much in a state of flux.