I've been working for a software development agency in the past and one of my clients back then was (a different) mid-sized logistics company :)
For us (including the client) the following approach worked great and I'd recommend to give it a try
* hire an agency (or freelancers) to work on (requirements, architecture, design, implementation) your special software - make sure the code is yours legally and you can bring it to another software shop or internal whenever you want
* you get bootstrapping important decisions done by someone with experience. because hiring the first employee for that task is hard and risky
* you can transition to in house from there, if you're happy with the solution or decide to stay at that agency longer - you're very flexible
* Having good and maintained software as a base, start hiring. Build your team and gradually take over development. You don't have to go in-house fully, just so much that it makes sense.
Back then we bootstrapped custom software for that logistics company and gradually migrated it over to their team - even helped them hiring a team in the first place. Over time we lost them as a client (because they happily worked on their software now) but got many more clients since they recommended us highly. So it's a win-win situation.
Author of wasmex[1] here (an elixir package which allows runnung WASM).
Next to the mentioned wasmtime, wasm3, and wamr, there is also wasmer[2] I would add to the list of capable WASM runtimes.
The great things these runtimes offer are how easy they are to integrate into other programming languages environments. E.g. with wasmex you could easily run WASM from your elixir application (or with wasmer from ruby[3] or many other languages if you want).
Imagine building shopify, but without needing to invent your own template language for customers to extend their shop-template[4]. They could provide a WASM extension API where shop-owners could let sandboxed WASM files render their shop. This would let allow shop-owners to write templates in their favorite language instead of e.g. liquid and still be secure.
Cool, I haven't seen your interpreter! I'll have to give it a read through.
npiet is good, and I use its examples for testing, but FYI it diverges from the spec in how it handles whitespace. According to DMM, if the cursor enters a loop entirely within whitespace, the program should terminate. Currently, npiet doesn't have a cycle-detection algorithm so it hangs.
One of these days I'll get around to making my test infrastructure and polishing up my tests... but I've recently had some weird thoughts about a place&route algorithm to replace my existing Piet backend and that's more interesting. First step, design a router that creates right-hand-rule paths through whitespace? What am I even doing with my life...
I implemented my interpreter with the goal to learn some rust. So please let me know should you find things to improve :)
I remember a point in development when I implemented whitespace handling and cycles therein. I thought I had implemented the spec but some example programs did not run properly. Maybe that was because of the divergence in the spec vs. npiet you mentioned. Since my main goal was to learn rust I just made the example programs work and did not double check the spec again. Will look into it again when I find some time :)
Ulam sprials are super interesting. I developed a visualization (and some explanation) once just to understand the problem a little better. Maybe this sparks some interest in someone :)
It's an interesting and easy project to start soldering/arduino-fiddling. Parts can be purchased with approx. $25.
In comparison to the pedal used in the vim clutch, the sewing machine pedal has the advantage of not only having an on/off state, but returning the pedal-pressure (so half-ressed and all sorts of combos are possible).
Currently, I use it for sublime-text shortcuts (cmp+p on half-press and cmd+shift+p on deep-press) or for debugging (ctrl+d to continue code execution).
You can fiddle with the displayed time (by editing the url) -- it's fun to see that (very) early timestamps have much greater chance to be a prime number.
one of those projects is feelSpace[1] which is a belt with vibrators giving you either a new compass sense, or tells you where to go (as a navigation system).
In 1996 I was prototyping a belt with piezo transducers spaced around it with each doubling as emitters and receivers for a crude ultrasonic distance, and then each would vibrate at a higher frequency the closer the object came.
Nicknamed 'batbelt' in-house.
I dropped it after looking into insurance requirements and ADA compliance.
Yes, and I used a Basic Stamp, and replaced it with a PIC chip later on. I had several normal issues: ignoring very close objects like your arms swinging when you walk; short postives; timing issues with getting the whole array working, since I was trying to triple use piezo transducers as emitter/receiver/vibrator. Other than those issues, it was not too refined due to the limitations of the transducers, speed of the 8-bit chips I was using, and you had to wear it within proximity of your body, but then not cover it up.
Before I ditched the idea, I was going to put the vibrator belt as a second belt worn under the clothing, but there was no Bluetooth or WiFi or easily accessible way of going wireless between the belts in a practical fashion.
I had my neighbor, blind man who had a guide dog, trial it. He was a great guy, and helped me quite a bit to 'see' past my vision biases. Unfortunately, he passed away. He used to work for the IRS, and we would joke about me getting my deductions past him! He did like what I had accomplished, but many blind people do not have the money for something that is not subsidized, and then you get caught up in the compliance insurance issues. Not sure if that has changed much nowadays.
It was a great maker project before the 'maker' movement. Too bad there was no startup, or crowd-funding web sites back then!
Whilst a commercial offering is probably quite expensive, it strikes me as the sort of thing you could do quite cheaply and easily with an arduino.
I've actually been collecting the vibration motors from disposable electric toothbrushes to build my own belt; as they were designed to run form a single AA battery powering them should be easy.
I find it quite expensive too. I guess the price is fair if you include the research they did, plus the prototyping, manufacturing and company overhead.
I've tried a prototype version of this belt once (for a couple of hours), it worked surprisingly well. But integrating the vibrations as a "new sense" into your brain (so that your subconscious can use it) takes at least some days.
I am one of the devs in the pictures. We often have measurable improvements -- the shark hat (meant for performance improvements) is obvious. Results are shown in our performance monitoring tools.
The impact of our rainbow-hat (meant to enhance the codebase, contribute to some open-source projects we use, do what you think makes the world a better place) is harder to put on a graph. But we could count code metrics, documentation, merged features in OOS projects etc. We don't do that , though.
What we do is talking about what we did with our hat time after each sprint when choosing the new hat-wearers.
For us (including the client) the following approach worked great and I'd recommend to give it a try
* hire an agency (or freelancers) to work on (requirements, architecture, design, implementation) your special software - make sure the code is yours legally and you can bring it to another software shop or internal whenever you want * you get bootstrapping important decisions done by someone with experience. because hiring the first employee for that task is hard and risky * you can transition to in house from there, if you're happy with the solution or decide to stay at that agency longer - you're very flexible * Having good and maintained software as a base, start hiring. Build your team and gradually take over development. You don't have to go in-house fully, just so much that it makes sense.
Back then we bootstrapped custom software for that logistics company and gradually migrated it over to their team - even helped them hiring a team in the first place. Over time we lost them as a client (because they happily worked on their software now) but got many more clients since they recommended us highly. So it's a win-win situation.