Mewlo Web Framework Blog Entry #3 - October 2, 2013 - Where to Start?I've been writing code for the Mewlo framework off and on for a couple of months now, but I think we still need one more preliminary blog post before I start getting into the details of the code.
What I want to talk about in this blog entry is establishing a solid foundation for a collaborative (open source) project.
Now I have to say off the bat that I don't have much experience with heading up active collaborative open-source projects. I have written some open source projects in the past, but these projects were never popular enough to get much collaboration, and not much thought went into creating an environment that fostered collaboration.
But for this project, it's very important to have an environment that both encourages collaboration and ensures that the the ecosystem around Mewlo does not become chaotic.
In the past I have been highly critical of some large open source projects, primarily those that support 3rd-party community addons or extensions. I find that such projects often become dumping grounds for large numbers of half-finished, abandoned, unsupported, conflicting addons, making it near impossible for anyone to find what they need and maintain a system built from these addons.
I am much more amenable to the idea of an actively "curated" ecosystem. That is, I am in favor of having some centralized organization and supervision of addons, and a fairly strict set of guidelines, policies, and standards.
An Open Source RepositoryFirst, we choose an open source repository system. There are many to choose from -- I'm not sure that it matters terribly which one we go with, but for Mewlo I chose
github. You can browse the Mewlo project on github
here. Github has a number of attractive features, including a systematic way for people to propose code patches, and have them reviewed and then merged.
While we don't have need of it yet, we will eventually be making use of the issue tracker and wiki services provided by github.
Coding Style DocumentThe next thing we need to do is establish a coding style guide and set of standards for the code. The specific decisions about coding style are not critical -- but what is important is that all code conform to a single consistent style guide. Furthermore, we need to outline the philosophical approach to the way code is modularized and structured. A key aim of this project is to create a consistent, clean, unified framework that does not feel like it's the result of jamming together a bunch of separate pieces written by different people.
So it's important to have an easy-to-read document describing these guidelines. You can read the early draft of this document for Mewlo
here. It still needs a lot of work and it's going to change over time, but I think the important thing is to have a place where we can refine these guidelines, and have an official document that people can refer to.
The website (
http://www.mewlo.com) where that document, and all other Mewlo documentation, lives, is generated dynamically from documentation files and source code files. These files are part of the open source repository, and because of that they are always up to date with the actual source code. There is no such thing as the documentation reference manual falling out of sync with the source code.
Code the Infrastructure to Modularize the ProjectEverything I've said in this post up till now is sort of textbook open source project management. But now I'm going to talk a little about something that doesn't come up all that often, about the idea of where to start coding.
Mewlo is a huge project, with many components. Where to start?
I've approached this question by asking myself what core infrastructure of code is needed for other coders to be able to jump in and write (and maintain) semi-independent modules?
In answering that question, I have focused on the following:
- 1. Organize the entire codebase around the system for supporting addons/extensions/plugins. In many projects, the plugin-system is the last thing to be designed -- something glued on top that would let plugins add features. I take the opposite approach here, and put the extension system at the foundation. Whether one is talking about the core code modules, or 3rd party plugins, everything is managed by a central system that manages packages of code, their dependencies, version and author information, etc.
- 2. Related to the idea of starting with an extension/addon system -- we have support structures to facilitate communication between components. This includes a signal broadcasting/receiving system, a component registry, a settings registry, etc.
- 3. Another foundational component that is important in facilitating the ability of other coders to create semi-independent modules is a substantial logging/debugging/error-handling system. There are two things we aim for here. First, and less importantly, we want to make it easy for coders to log and display information to help them track down issues. Second, and more importantly, we want to establish a standard for handling errors and logging information. We want a rich set of support functions and a coding standard for exactly how different kinds of errors should be handled, how they should be returned, when we should throw exceptions, etc.
- 4. Support for Unit Testing. Unit testing is a fancy (silly) term for the sensible idea of building automated tests that can test all aspects of the software and ensure that all code is working as expected. It's particularly useful in finding when changes to one piece of code cause unexpected failures in other pieces of code.
The common theme here is that in this first stage of coding, we are trying to establish the ground rules, the style of the code, the conceptual approach to the division of labor, the error-handling policies, etc., so that the code that gets built on top of all this will be consistent with the overall vision of the project.
Recent Posts
