Fork me on GitHub
#clojure-europe
<
2020-10-12
>
javahippie07:10:21

:spock-hand:

plexus07:10:46

good monday! (if there is such a thing)

plexus07:10:01

going to need a lot more tea for this one

otfrom07:10:06

Pretty sure today is a post lunch coffee day

otfrom07:10:21

@javahippie peace and long life

dharrigan08:10:18

Good Morning!

dominicm08:10:41

Morning. I meant to say it already, but I was busy dropping a table.

otfrom09:10:09

@dominicm always difficult to remember pleasantries when flushed with so much adrenaline

otfrom09:10:26

but at least you know you are alive (until the client finds out anyway)

otfrom09:10:37

can you drop tables in crux?

dominicm09:10:36

I'm not using crux, I don't work for JUXT anymore @otfrom

otfrom09:10:34

ah, my bad

otfrom09:10:51

so just good old fashioned RDBMS table dropping this morning?

borkdude09:10:46

drop table datomic_kvs

javahippie09:10:20

You could also drop furniture

๐Ÿ˜‚ 3
genRaiy10:10:05

@dominicm people outside of JUXT are also allowed to use Crux IIRC

dominicm11:10:37

Only if there wasn't already a database in use ๐Ÿ˜ข I do hate having a schema for the work I do. Makes everything harder.

๐Ÿค“ 3
genRaiy10:10:09

@otfrom tables don't exist in CRUX, only as a fiction when using SQL for querying data

otfrom13:10:10

that sound DaaF(t)

genRaiy10:10:00

cloud servicing the sky today

slipset10:10:11

I seem to remember a library used for testing web-apps built on compojure, but my google-fu is not strong enough today. I also seem to connect this library with someone working at JUXT, Anyone know what lib I'm looking for?

slipset10:10:50

I could of course just state my problem. I'd like to be able to pull all the routes out of a compojure route-definition, if that makes sense.

plexus10:10:20

not sure if that's possible @slipset, short of parsing the source yourself. AFAIK compojure works by composing closures, they're opaque functions

slipset10:10:28

Yes, there would be some trickery involved in doing so.

borkdude11:10:30

It would be nice if those closures carried some metadata about the routes maybe?

borkdude11:10:04

Other solution could be wrapping compojure macros and extracting the routes yourself before it goes into compojure

slipset11:10:14

In other news. Spent the weekend refactoring some rather opaque Clojure code. One could argue that that job would have been easier if I were working in a statically typed language. One could also question the ability to cleanly type this code and still end up in the same mess. I guess what I'm saying is that the types written for for the code as it were would have been as messy/opaque as the untyped code was.

slipset11:10:42

An argument that I could accept is that given a statically typed language you wouldn't write as messy code, as your types would indicate that your code is messy, but then again, you didn't need types to figure that out.

genRaiy11:10:20

@slipset not sure what point you're really circling here but it's true that you can write messy code in any language

genRaiy11:10:12

also messy might be OK in some situations, like a code spike but not for the long term

genRaiy11:10:01

when I write messy code it's a sign that I don't understand the problem or that I haven't yet found the correct abstraction

genRaiy11:10:01

which is to say that a lack of some knowledge contributes to the mess

genRaiy11:10:37

but it also feels to me that you can see it more clearly in Clojure than most languages

genRaiy11:10:06

mess is like art, you know it when you see it ๐Ÿ™‚

borkdude11:10:47

Clojure keeps you ignorant of the mess for longer as well and ignorance is bliss :)

slipset11:10:18

I guess what I'm circling around is that it would have been easier to do this refactoring if I understood the data being passed around. This understanding would have been easier to come by if the code had been typed.

slipset11:10:05

But then I would argue that the types that would have made this stuff even compile would probably have been so obscure that any insights would have been lost.

slipset11:10:09

So I'm basically arguing for and against static typing, and handwaving my way to figuring out that static typing wouldn't have helped even though it seems like it would have on the surface

borkdude11:10:58

thus creating peace of mind for current practices, which is an evolutionary mechanism to preserve energy troll

simple_smile 6
dominicm11:10:34

I think messy code that you actually have to maintain benefits from documentation of some kind. If you're just trying to incrementally modify that code, then types are extra due to the refactoring capabilities they provide. But if someone spent time writing types, why didn't they instead choose to simplify and/or document!

slipset11:10:14

I guess because typing (or spec'ing) it doesn't break the existing code. My refactoring will have bugs in it.

slipset11:10:36

But if you want an omelette...

borkdude11:10:52

I find tests the most helpful thing here

slipset11:10:01

If only...

borkdude11:10:50

never too late to write one ;)

slipset11:10:06

But then you have to understand the code ๐Ÿ™‚

borkdude11:10:31

No, you have to understand the requirements

slipset11:10:38

true. At this point in time I guess the only requirements are that it works as it always has, Including whatever Hyrum's been up to.

borkdude11:10:09

> Michael Feathers introduced a definition of legacy code as code without tests,

borkdude11:10:46

I have that book, but I never read it.

slipset11:10:07

Not sure if I still have it or if I gave it away. But I have read it.

dominicm13:10:27

I think I made a script to do that too, I probably should have shared it :p

otfrom16:10:17

๐Ÿฅ• ๐Ÿฅ•

otfrom16:10:24

(wot? no purple carrot?)

otfrom16:10:45

hmm... apache commons BZip2CompressorInputStream seems unusably slow for a file that inflates to 459MB

otfrom16:10:48

that is a pity

borkdude16:10:53

maybe shell out to bzip2?

borkdude16:10:56

I'm reading on wikipedia that bzip2 has better compression at the cost of speed and memory usage

otfrom18:10:33

I'm actually wondering about nippy as it will really only be consumed by clojure

otfrom18:10:47

But shelling out is a possibility too

borkdude19:10:44

it would be worthwhile to measure the shelled out time against the Java time. Chances are bzip2 is just slow in general?

otfrom20:10:57

Bzip2 command line is noticeably faster

borkdude20:10:14

@otfrom why not just use gzip though?

borkdude20:10:17

I have a function in my current buffer for un-gzipping natively in Java without deps:

(defn un-tgz [^java.io.File zip-file ^java.io.File destination-dir verbose?]
  (when verbose? (warn "Unzipping" (.getPath zip-file) "to" (.getPath destination-dir)))
  (let [tmp-file (java.io.File/createTempFile "glam" ".tar")
        output-path (.toPath tmp-file)]
    (with-open
      [fis (Files/newInputStream (.toPath zip-file) (into-array java.nio.file.OpenOption []))
       zis (java.util.zip.GZIPInputStream. fis)]
      (Files/copy ^java.io.InputStream zis
                  output-path
                  ^"[Ljava.nio.file.CopyOption;"
                  (into-array
                   [java.nio.file.StandardCopyOption/REPLACE_EXISTING])))
    (sh "tar" "xf" (.getPath tmp-file) "--directory" (.getPath destination-dir))
    (.delete tmp-file)))
(note: I untar at the end, for this I shell out, this is only necessary when dealing with multiple files)

otfrom21:10:05

That would work. I think when the bzip2 didn't work I wondered why I was round tripping to csv