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

Surprisingly easy! I was scared of building TUI like this because it seemed so complex, but it's actually not that hard. Or at least, with tui-rs[1], which is surprisingly easy to pick up. Once you read two or three examples, you'll gain pretty good overview of how to build applications with it. I can definitely recommend it, it does all the heavy lifting and leaves surprisingly little for you to care about. Just don't forget to unset terminal raw mode before your application exits, or else you'll start breaking people's terminals :-)

[1]: https://github.com/fdehau/tui-rs

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'll add technical section to readme, but for short. I've used tui-rs[1] with crossterm[2] backend (which handles the actual terminal interaction). The docs may seem intimidating, but it's surprisingly easy to use.

I've considered using curses, but tui-rs seemed that it will be easier to handle. I can certainly recommend it for making tui applications.

I didn't actually use any documentation at all, it wasn't in the man page and I didn't feel like hunting for it, as it was pretty easy to understand just by looking at the output.

Sed debug works by running the code specified just as normal, but it annotates what it does to stdout. So it might look like this: https://gist.github.com/SoptikHa2/a50e90bd1b34c7238944c20d1a...

Sed actually has pretty well-designed interface IMO, it's pretty minimal and has no nasty surprises.

Edit: Here[3] is something I've written about it.

[1]: https://github.com/fdehau/tui-rs [2]: https://github.com/crossterm-rs/crossterm [3]: https://soptik.tech/articles/building-desed-the-sed-debugger...

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.