soptikha2

My experience is quite different in regard to working in Europe.

How exactly is hiring a very tedious process? Seemed quite fast and easy to me.

And btw, it's not that hard to fire a wrong hire. You have few months to do so basically for any reason at all, and afterwards, you can still do it, if you have a good reason to do so.

I made a tool and browser extensions that determines if people in video are currently talking or not, and speeds up the video accordingly. Great for long lecture videos for skipping time spent writing on a whiteboard.

My use case are corona-time lectures. I don't want to just watch the teacher write something while saying nothing, so I speed up the video 1.5x when teacher is talking, and 4x otherwise.

So this extension analyses sound in the video, and determines which parts are loud or silent. And depending on that, it changes playback rate of the video. Technically, this is javascript extension that downloads video information (when it's loud or silent) from server (which is btw written entirely in shell & gnu coreutils) and tells the videoplayer what to do. So only videos explicitely indexed by my server are managed by this extension. User has to click a button in the extension menu to index a video (as the data about videos are stored on my server and it has very small disk size, so I don't want to do this for every video).

Yes, my priority was making the UI done as fast as possible, as I wanted to focus on making the debugger and didn't want to think too much about UI. I looked at some examples of both of them and decided that tui-rs looks easier to use, it takes care of everything for me. Note that I might be wrong, I didn't spend even half an hour looking at the frameworks.

Another reason, albeit really small, was that tui-rs was written specifically for rust, and curses framework I looked into were essentially just C bindings, making it a bit weird to use. To be fair, this disadvantage is by far outweighed by the fact that curses is far more popular than tui-rs, and there is so much more tutorials and documentation to be found about it.

But I wanted to focus on writing the debugger, so I went with what seemed to be more convenient option and paid the price of lower control and performance - for example I have troubles implementing syntax highlighting because tui-rs tries to be clever with mine ansi escape codes.

---

Thanks for the links, especially the ble.sh looks amazing.

I certainly do. This is meant just as a toy, and way to learn Rust, which is what I've written this in. If I need to actually achieve something, I use python or haskell.

However sed is perfect if you have spare time and want to write basic programs in unnecessarily complex way for fun.

Hi, author here. I’ve written a debugger for sed in Rust. This was not only to learn rust, but to actually have a solid debugger for sed. I’ve started learning sed recently and decided to start writing various algorithms in it. And as sed doesn’t have numbers and can just filter/transform text, this is a challenge even for something like comparing two numbers. I’ve seen people do amazing things with it.

I’d be glad for any comments regarding code quality or the debugger itself.

I can confirm that I'm being redirected as well.