# 2021-05-19 thoughts [[Logs]] ## Epistemology Epistemology, the study of knowledge, is a topic I am very interested in. I was discussing with Karl yesterday and mentioned that most technical books could be boiled down to 10 pages of well written concepts, and the rest would just be reference material. I think I can rephrase that to: the essence of a book could be boiled down to 10 well written pages, and a series of examples and references. But how do I know that that is true, or that just reading these 10 pages actually creates the transfer of knowledge you would expect from reading a book. Maybe a reader needs to have some fluff, some time to digest, some ways of skipping some text, and hearing things multiple times in slightly different ways for it to actually carry over. The value of distilling things down to 10 pages, or in the case of work document, to a single page, is to create a nucleus of knowledge from which all the examples can be derived. How do I find a good introduction to this field of study? Because I am sure the field is full of nerds that are more interested in thinking about knowledge (like I am), than provide some tangible advice on what is best. I should maybe not worry about tangible goals and also just indulge in my nerdery. ## Back to office and brainstorming I went back to the office yesterday, and being able to brainstorm aloud in front of a whiteboard has been very fun. I didn’t get any programming done, but I could sit down with Justin and take a look at the system. Robert Gambee wrote a fantastic tool exposing printer metrics over websocket to a webUI displaying graphs. I am going to reuse that for FormCell (the new sketchy UI) for sure. I am quite confident now in my way of approaching problem solving and architecture. I spent a long time writing out thoughts and ideas to Dan’s project of creating a sample part request to printed part pipeline. In between writing, I’d go back to the whiteboard and bounce my ideas off of people in the vicinity. I have been doing similar things in slack, but in the physical space, you can tell if someone is busy or not, you get to move around, you get to draw. Finding a good solution for a physical whiteboard at home would be great. Drawing on the ipad is a good substitute, but the physical moving and erasing on a whiteboard is fun. Apparently, Seth starts to get the idea of workflows and their importance. Seeing that I still have problem communicating about them, I should maybe sit down with him to have a brainstorming session? Probably Jessie should be on it, because she will have many more insights into what these workflows could be and how to build them. I will schedule a meeting. Meetings to schedule: - [x] robert gambee and look at tirmo - [x] jessie and seth and brainstorm workflows ## Using bear and writing I have been getting the hang of bear, it really is a good tool. The zettelkasten system is lose and simple enough to really fit my needs too, and I understand how it is to be used (in the long term). I now need to refine the daily flow of writing notes, turning them into “idea cards”, creating documents for consumption, editing or rewriting drafts. The real work begins! [[Using Bear as a wiki]] I see the impact of my written documents in the FormCell product document, the DevOps lead planning document, and the sync document for Ed. I should expand on that, and keep what I have been working on as a blog in confluence for public consumption. That will force me to whittle down the longer streams of consciousness to short concise entries. I can then reuse that to show Ed and other people what I have been working on by just pointing at the blog, instead of having a myriad of little google documents. Well this is all very exciting, but I better get ready for walking the dogs and town hall. ## Turning writing into action Next topics: turning bear writings and other things into actionable tasks, and having a good TODO system. One thing I am struggling with is turning all these writings into actions that I can keep track of. For example, while taking notes during the devops discussion yesterday, I turned things into TODO notes. But I do need at the end of the day to transform these TODO items into something more tangible in a third party software, so that I can go over it in a more structured manner. Should it be omnifocus? Honestly, omnifocus just turns me off in its complexity. Could it be Todoist? I need to give it another try. Let’s do it! ## Pipeline thinking applied to embedded software Related to [[ZK - Queuing concepts also apply to embedded software]]: * How does this work exactly? How would this apply for to the print pipeline performance? Does this actually make sense? We can consider generative processes that can generate multiple units of work. For example, PreForm generates individual layer files, that then get uploaded. Similarly, the print.py processing done can also generate multiple layer files. There is a way to precompute work, so that the generation of the FLX doesn’t impact the flow. So not only do we need to keep track of accumulating inventory as a metric, but we need to track missing inputs as a metrics. This could be time waiting on incoming work, vs accumulating output. What if we want to instrument a metric that is not modelled as individual processes. If we look at I_Task, how can we model the fact that an I_Task is waiting on preceding tasks? - [x] How can we instrument I_Task performance and bottlenecks? [[2021-06-19 - Formlabs Log]] ## Neuron to visualize the Zettelkasten Neuron is a fantastic tool. I easily got it running on an export of my bear notes, and not only does it look good, but it really provides great functionality. It makes me appreciate how solid Haskell developers can be, and that haskell indeed is a great robust system to get things done and apparently not create bugs. How much of that is just that haskell developers are **good** developers focused on robust code, and how much is it indeed due to the leverage haskell provides. I can compare out PHP work which has many little subtle bugs. But if I had solid functional programmers on it, from the start, how much better would it be? That is I guess indeed a shortcoming of seb, building many things quickly but not spending time to consider the bigger architecture, and applying functional principles. ## Further thoughts about input stage of the Form Cell I was thinking that we’d provide the farm in ohio with: a) group arbitrary printers into a “formscale unit” b) a formlabs-internal form to submit sample requests into the system That way they have manual control over the whole system. While I don’t know exactly what their process does, I could see this being immediately useful. We should not spend time interfacing with anything other than our own stack. I can expand more on the technical details of the IMPORT step next week. It really is pretty simple, it consists on a simple HTTP API to create what I call “work units”. It’s basically a set of metadata with an ID, and that’s it. We should build it so that it might be possible for them to use a zapier integration or some other simple service to feed things from their system into FormScale, and similarly to provide a callback for when the part is printed.