tess0r

you can not only map prime numbers in a circle/spiral, but also in a triangle and get some nice knitting patterns :)

https://tessi.github.io/walking-the-ulam-spiral/

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.

q

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.

[1] https://github.com/tessi/wasmex/ [2] https://github.com/wasmerio/wasmer [3] https://rubygems.org/gems/wasmer [4] https://github.com/Shopify/liquid

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 :)

I agree. I've written an interpreter in rust [1] and input handling, esp for numbers, was really annoying.

I guess the best reference for implementing new interpreters is npiet and testing all example images.

[1] https://github.com/tessi/rpiet

good point. will make it a gif! :D

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 :)

https://tessi.github.io/walking-the-ulam-spiral/

I stole my wifes sewing machine foot-pedal for a similar project recently https://github.com/tessi/programming_paddle (code there is hacky, don't jude ;))

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).

edit: typo

* the green lines are somehow weirdly blurred (for god know what reason)

* it's hard to notice that the current timestamp is the most right (white or green) bar. Would be nice to have the current time in the center.

* It's hard to get the concept without explanation (at first glance people just see weird green bars moving).

But then, I never meant to make a perfectly polished clock. It's good for a quick experiment.

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.

Also, sometimes, you can find "twin primes". https://tessi.github.io/primetime/?t=1500000000 has such a twin-pair in the center of the screen (the twins are 1499999927 and 1499999929).

This remembers me of "primetime" a "clock" which draws a green bar every time the timestamp is a prime.

https://tessi.github.io/primetime

Did it in my student years, looks awful today, but I was proud back then ;)

edit:

I just remembered that you can give it a timestamp to display (instead of just displaying the current time). Unix Time 1,500M would be

https://tessi.github.io/primetime/?t=1500000000

and is (obviously) not a prime number.

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.

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).

[1] https://www.indiegogo.com/projects/feelspace-follow-your-gut...

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.