This week has been one of prose and design. Of laying the foundation for the future of how this project is perceived by potential users and contributors. The more of those we have, the greater our work will become.
Because writing is what I’ve done all week, I’ll keep this short.
Table of contents
Now that we’re not alone in our quest for the perfect pipeline, we’ve given the pipeline project a common name.
This means (1) future users won’t confuse our work with one that is limited to Mindbender, but can be used by any organisation within a similar industry and goals which widens the amount of help we can get and (2) the help we do get are given a sense of ownership and purpose, one that extends beyond Mindbender and it’s property.
Design & Prose
The updated documentation now features a few things that (1) enable others to understand and contribute to the project, (2) avoid bugs by actually running the code found anywhere mentioned throughout the text, and insert the results into the website itself, (3)
When code within your documentation is part of your software life cycle, checked in and tested like code, it’s called “living documentation”. This kind of documentation means that whenever our code changes in such a way that it breaks the written documentation for it, or when documentation is written in such a way that it doesn’t actually run with the current version of the code, a loud error is made and whomever is responsible for the damage is given a chance to rectify it without anyone ever noticing it happened.
To the author, code looks like this.
Yadda yadda yadda, here's some code import sys print(sys.executable) print("Hello!")
Once rendered, it’ll take the written code and (1) format it nicely with colors, (2) run it and (3) insert whatever was outputted.
The best part is that, it doesn’t matter who writes it or what the environment and software is on the local machine; it’ll get run “in the cloud” on an anonymous machine with an identical set-up to what I use myself. Which means others can make changes too, and changes could be made from your phone, or directly from the GitHub interface.
The end result is example code that (1) informs the author of error and (2) assures the reader of correctness.
You are welcome to read it, but keep in mind it’s not yet ready for an external audience; it is and is expected to reach that state by end of next week. At that point, you should be able to read it from top-to-bottom and understand precisely where we are, how we got here and why.
The merge of the two pipelines this week has been very successful. Roy has transitioned into our database-driven asset management, and we’ve transitioned into their much more refined graphical user interfaces.
As importantly, it proves that the separation of concerns presented by the division of Core and Config works. A studio can benefit from a shared codebase whilst at the same time fulfill their unique requirements.
_____________ ______________ | | | | | mindbender | | colorbleed | |_____________| |______________| ______________________________ | | | core | |______________________________| _____________ ______________ | | | | | file-system | | database | |_____________| |______________|
This is very encouraging and means we can continue to expand onto more users and collaborators. Next up, I’ll be looking at getting MetaPipe up to speed with where we are at and investigate whether another join of forces is possible - a doubling in size of the team, from 3 to 6.
I’ll be deploying the past two weeks of work for you on Monday morning, as
mb-gui-mottosso.bat until we’ve given it a proper go. There are some fundamental changes to the underlying pipeline, none of which should be noticeable by you (but might take the form of bugs), apart of course from the new and updated Loader and almost ready and vastly improved Manager.