melezhik @ melezhik @programming.dev

Posts

2

Comments

10

Joined

2 yr. ago

You may try out https://github.com/melezhik/sparky which is a local / remote task runner with nice front end and scripts could be written on many languages

Yep. Fancy devs watching me coding some Rakulang in nano 😂

Ok. "I am a good FOSS developer"

Thanks, will take a look

nano is the best (imho) for up to medium size files. It’s preinstalled in most Linux boxes , it’s simple and flexible enough, takes a minimal amount of time to learn basic for keys and then use them all the time

Yep. Like said - "We talk about use of Bash for simple enough tasks ... where every primitive language or DSL is ok", so Bash does not suck in general and I myself use it a lot in proper domains, but I just do not use it for tasks / domains with complexity ( in all senses, including, but not limited to team work ) growing over time ...

We are not taking about use of Bash in dev vs use Bash in production. This is imho incorrect question that skirts around the real problem in software development. We talk about use of Bash for simple enough tasks where code is rarely changed ( if not written once and thrown away ) and where every primitive language or DSL is ok, where when it comes to building of medium or complex size software systems where decomposition, complex data structures support, unit tests, error handling, concurrency, etc is a big of a deal - Bash really sucks because it does not allow one to deal with scaling challenges, by scaling I mean where you need rapidly change huge code base according changes of requirements and still maintain good quality of entire code. Bash is just not designed for that.

Let me generalize that - yaml pipelines are terrible 😀

Ok. Huge part of building microservices framework is infrastructure automation - like setup nginx load balancing in runtime, build and deploy apps from source code, configuring services, tcp ports, health checks, horizontal scaling (adding new worker nodes), setup logging and monitoring, etc, also this needs to be propagated to all cluster nodes, I am not going to do this from the scratch - Sparky is alike (rough comparison though) ansible but with UI and programmable on Raku, so as Sparky has already addressed the mentioned tasks, it's logical for me to carry on with it. If we take Sparky out of equation, Raku by itself is reach and super flexible language to automate infrastructure, I don't see why can't I use it for that ...

The plan is to build the entire system on top of Sparky which is written on Raku and extended by Raku