I don’t like having to jump around too many different tools like your average startup. Which means we’ll keep issues and stories in the project on codeberg. The one issue with that is forgejo is missing a lot of common project management features. We can’t do milestones except on repo-specific projects. But I wanted just one big project for all of Tripoli since I prefer all tasks being seen in the same kanban board. Wikis are also only available per-repo. Also doesn’t seem to have complexity field or the ability to add fields.
So my solution is to fill in the shortfall with this forum, since we’ll need this forum anyway to support end-users and discuss development. We can make some pinned posts and use those as sort of wikis. As I type this, I’m the only person in this forum, but as devs join, I can point them to this post and I’ll also have CONTRIBUTING.md or something like that point here. I’ll make another post in Announcements giving a more general overview of what this thing even is because it’s not a product the general public uses like a browser or a game. There is the website but that’s written for people who are in the market for this.
Contributing Guidelines
On the issues, where appropriate, we’ll add these fields at the end the descriptions:
milestone: mugu
points: 5
Make it preformat like that to signify this is something we might want to have code read down the line. For now it’s just an informal thing. Only add fields as needed. Usually when you make an issue, you don’t add the milestone field unless it’s a dependency to another issue that’s already in a milestone. Points should probably be added during points estimation but someone very familiar with the code could add that when writing the story as well.
Components
Here’s a brief overview of the components of Tripoli. It’s named after the ancient city because it has three sub-components, just like the city traditionally has three parts. There are also three cities named Tripoli each outside of Greece patterned after the one in and similarly ancient. I named the components after parts of the Libyan Tripoli and for now use a mermaid as its symbol as one of its nicknames is “the mermaid of the Mediterranean.” These names are not going to be customer facing but the overall name of the project, Tripoli, is:
Oea
This is the GUI. We have a couple of different versions of it. There’s a haxe/coconut.ui version that is used for web, mobile (via react-native) interfaces and could also be used for desktop via electron. Then we have a gpui version that’s meant to be the high-performance desktop version. This communicates with the backend and web services via graphql and other protocols, does saving and generates reports. It will probably need to share code with the web component as both will have the reporting features.
Sabratha
This is the rust-based core that handles communicating with instruments or sensors, storing in time-series database and receiving requests from clients. It can be run standalone headless mode for remote control and is also meant to work in embedded contexts.
Leptis
This is the web app that handles basic LIMS functionality, storage of data and reports, customer management, etc. It will also ultimately host an extension store like Visual Studio Code. Extensions will usually be to add support for an instrument in Sabratha but could be other things like data analysis tools, report templates, etc.
Milestones
Here is an overview of the milestones we’re working on this year. Each are named after a place that has a Chumash-origin name:
Mugu
This is an MVP for something that can be dogfooded by Van der Stahl internally. This is not true dogfooding because I am not a calibration engineer at VDS (though I once was) but for the purposes of project management for software that’s made with them and their customers in mind, I’m counting their engineers as the in-group. They have my phone number if something goes wrong.
This will support the datalogging multimeter they use to calibrate packaging machines in Sabratha but use a Jupyter notebook to provide the UI, reporting and any data checking (checking peak values). In some ways this is going full circule back to the prehistory of Viu Calibrate (Tripoli’s predecessor) when it was just an Excel spreadsheet that communicated with WinWedge. As it puts Sabratha in the role of WinWedge and Jupyter in the role of Excel. I often use Jupyter instead of Excel so that makes sense. This is not simply a stopgap though. I foresee Jupyter and other means of using Sabratha directly as a powerful use of our tech. The main product will be Oea communicating with Sabratha but for many, including developers and scientists, there may be value in this approach as well.
Hueneme
This will have the first version of Oea so we can have a snazzy GUI of our own instead of having to use the Jupyter notebook.
Somis
This will be the first beta that will be made available to VDS’s customers. For this, there will be the first version of Oea and plugins for Sabratha for machines they use. The basic workflow of communicating with the machines, printing and saving must work flawlessly to the best of our knowledge from internal testing. We will dogfood Oea internally before releasing to customers. The deliverable will be Windows, Mac and Linux installers for the package, which will be autogenerated by Codeberg using github-compatible pipelines. Users will just be able to save and load data locally as the cloud infrastructure won’t be available yet.
Ojai
This is where we add cloud and user management features. This will be a launch of an MVP of Leptis for internal dogfooding and use by beta customers. Users will be able to schedule calibrations, mark things as requiring maintenance, etc. and note which user performed a calibration and issued a report. This will also come with additional plugins for machines used or marketed by VDS. Leptis is OSS like everything else but part of the business model outside VDS will be charging for use of our hosted version and providing managed hosting.
Anacapa
This will be where the phone app becomes available now that all the infrastructure needed for it has become available. Phones can’t directly connect to machines in most cases so this basically means a port of Oea itself to phones and tablets without Sabratha being involved, at least initially (it’s conceivable that we add support for logging things using built-in sensors or anything that can be connected via midi or something like that in the future, if this is useful). This will support using mobile version to add drawn signature to forms, enter using barcode/qr code scanner and look at past reports retrieved from Leptis.