Fork me on GitHub
#off-topic
<
2021-02-18
>
roninhacker01:02:48

Yeah, I had an extremely plebian meaning in mind ---transforming equations for math homework. LaTTe looks amazing though, thank you for linking me to it. The closest I found is a Little Java (I suspect actually clojure) App That Could on Sourceforge, the only review quite derisive. I think there's the core of something great though: https://sourceforge.net/projects/ket/

phronmophobic01:02:19

I used to use wolfram alpha (https://www.wolframalpha.com/) for math homework in college. you just type in the math and it usually brings up any relevant derivations on its own

πŸ‘ 9
phronmophobic01:02:16

your school may even have [free] logins/licenses

jjttjj15:02:00

In documentation for java libraries, frequently a classname is mentioned but without mentioning the package or path of that class and I end up having to just google the class name or look at source code until I find a better way to import. Is there a better way?

πŸ‘€ 3
❀️ 3
πŸ‘† 3
orestis18:02:33

I try to find the Java doc page and ctrl-f in there. It’s super annoying though.

kulminaator19:02:16

to any people here writing stuff on Rust ... how do you keep your projects maintained and alive over time ?

kulminaator19:02:53

i tried writing a small tool with rust for postgresql .... and the postgresql client lib pulled in 70 dependencies on it's own. bloody hell 😐

kulminaator19:02:03

looks like npm hell all over again

kulminaator19:02:25

sounds like i will write my tooling with clojure instead and opt for graalvm to get a binary should there be a need for one ...

borkdude19:02:32

Take a look at https://github.com/leafclick/pgmig for a Postgresql CLI (migrations) using GraalVM :)

borkdude19:02:34

Also you can do scripting with babashka and https://github.com/babashka/babashka-sql-pods/ should you need fast startup without compiling yourself

kulminaator19:02:00

startup time won't be an issue

kulminaator19:02:42

the target will be to port a few terabytes of data from a postgres cluster to a yugabyte cluster and keeping active replication going after the initial data has been copied

borkdude19:02:46

I think the thing in Rust is that they want to push as much of the language into libs so they can evolve outside of the core

borkdude19:02:21

so you will quickly need libs for basic stuff like async, a global mutable var, etc

kulminaator19:02:29

as for db migration tools .... amazing , yet another one that thinks that you want to manage individual migrations as changes from shape A to shape B

kulminaator19:02:06

if you think of your database structure as just ... well structure definition, it suddenly becomes code .... we don't manage our code like we do mange our db migrations do we ?

kulminaator19:02:07

i mean you don't change the code by creating migration_2342042042 add line (def x "fobar") into babashka.clj

kulminaator19:02:53

first off it's impossible to read the thing even after a few migrations and it's impossible to reason about it if you have 50 migrations

kulminaator19:02:31

i know there are a ton of tools out there that maintain db structures like that, but they are all flawed by the design, nobody wants to have 800 migrations for a 6 year old project

borkdude19:02:54

We have been using it on a 5 year old project, it works well for us. YMMV.

kulminaator19:02:20

well you probably run less db migrations πŸ™‚

borkdude19:02:29

I will count them

kulminaator19:02:40

because applying 800 migrations just to run your db tests .... πŸ˜•

kulminaator19:02:56

or making any sense from the last 40 ...

borkdude19:02:19

we don't do tests like that. we only test against real systems :P

kulminaator19:02:22

if you would want to compare the state from 5 months ago to current in your babashka code, you would open up git and diff

kulminaator19:02:41

maybe individual changes sometimes too, but mostly just the big diff from now to then

kulminaator19:02:08

but for some reason the quite fewliners db definitions are a holy grail and are treated totally differently

kulminaator19:02:49

i have seen db management tools that work differently and treat db structure as code. feels way more native once you have touched such

borkdude19:02:18

I guess you could write a more intelligent tool by comparing the columns etc that are already there and create those that aren't there yet, but for some reason I didn't come across that. Are you using one?

kulminaator19:02:50

was using one back at skype. not using at the current company, i haven't found a very good open source one.

☝️ 3
kulminaator19:02:21

some are based ontop of the complex systems like django or rails

kulminaator19:02:34

but if you dont use django or rails they become aliens in your world πŸ™‚

kulminaator19:02:44

i will work towards getting a tooling out of my boys to create a similar tool for rabbitmq though

kulminaator19:02:50

because i face the same problem there

kulminaator19:02:02

a lot of structure in the exchanges & queues & bindings

kulminaator19:02:25

and migrations from shape A to shape B are quite risky after a while

kulminaator19:02:39

and hard to reason about

borkdude19:02:47

we're using rabbitmq as well, but not a lot of churn there

kulminaator19:02:47

i mean civil people would like to test their stuff right πŸ™‚

kulminaator19:02:12

and compare different stages of their changes if needed

kulminaator19:02:31

and clean up stuff once they dont need it

borkdude19:02:52

Maybe one reason such an open source tool doesn't exist is that it would be very db specific, while migratus works pretty much with any type of persistence thing

kulminaator19:02:14

well both postgresql and mysql are big enough really to have their own tooling

kulminaator19:02:41

the "works across databases" often leads to a horribly inefficient design or just a bunch of lies πŸ™‚

kulminaator19:02:55

because a few steps onwards from the sql standard things start to differ a lot

kulminaator19:02:40

and is quite a big overhead for development too 😞

borkdude19:02:06

Btw, speaking of Rust and data replication, we are using ZomboDB, written in Rust, to sync data from our postgres to an ES cluster. Works well.

kulminaator19:02:43

i expect most stuff written in rust to work well, the design of the language itself is very neat.

kulminaator19:02:15

but on the perhaps unfair example from npm world, if your project starts to depend on ~100 packages then after 3-4 years a good dozen if not more of those will be unmaintained & rusting in the corner, no pun intended.

kulminaator19:02:00

if i grab clojure & jdbc driver & graal - i have a pretty small pack of things that are maintained and kept up to date

kulminaator19:02:53

have at least to be thankful for the tokio stack in rust, that seems to keep a big part of their world in a line

borkdude19:02:54

agreed. the approach that zomdodb takes is that it lives inside postgresql, as an extension

kulminaator19:02:25

regarding ES clusters .... it's interesting to see what eventually comes out from the elastic vs aws battle

kulminaator19:02:03

that turned into quite a sh*tshow πŸ˜•

orestis20:02:42

I have an always up to date ddl sql file that I run tests against, and the migrations are just some Clojure functions that I consider temporary. Not ideal and need a lot of preconditions and postconditions but I will add those when Postgres becomes a single source of truth (right now mongo is that, so Postgres is used for analytics and stuff)

dpsutton20:02:15

Austin and Texas people in general. Hope all is going ok for you. I'm in Louisiana just down i-10. please feel free to ping me if i can help with anything at all.

❀️ 7
πŸ‘ 4
slipset21:02:00

Hihi, mongo as the single source of truth.

πŸ’― 4
😏 4