Fork me on GitHub
#clojure-uk
<
2017-10-04
>
otfrom07:10:25

I learned emacs, java, linux and LaTeX at the same time and only b/c clicking on a text file in redhat 5.2 opened up emacs by default.

cddr07:10:46

What do vim users (or really users of any non Emacs editors) do to configure indentation of macros usage?

dominicm07:10:08

@cddr vim-clojure-static (bundled with vim) has options like g:clojure_fuzzy_indent_patterns = ['^with', '^def', '^let'] and g:clojure_special_indent_words

dominicm07:10:12

If you want to not fight with emacs users, you should also set let g:clojure_align_subforms = 1 I haven't done this yet, becuase I will eventually conquer the emacs foes. I also think it's far more sane of a default.

dominicm08:10:06

> The later one in particular now means that ClojureScript has a dependency on JDK 8. 🙂 time to update

glenjamin08:10:05

i only learnt to use vim because i kept pairing with people who used it

reborg08:10:27

nice @dominicm I was thinking how to use 1 to align subforms yesterday 🙂

dominicm08:10:03

https://github.com/bbatsov/clojure-style-guide/issues/126 this is an interesting read regarding the two modes

dominicm08:10:55

> Simpler rules, no need for have special cases for macros with body forms which are indented with 2 spaces (so it's complex to set up this rule when editor doesn't have built-in support) This is my favourite reason to not do it

reborg08:10:19

OMG waay too long discussion 🙂

reborg08:10:11

I'm okay with 1 or 2 with very mild preference for 1. You guys decide I'll stick with it

dominicm09:10:06

I think it was nailed in the first post.

guy09:10:44

Morning all

guy09:10:56

I've been trying graphql these past few days and its been quite fun and interesting experience

guy09:10:24

would recommend a peruse of their main docs and a look at lacinia clojures lib for it

mccraigmccraig09:10:56

can you summarise your impressions @guy?

guy09:10:33

I can try haha !

guy09:10:19

ok so my gut feelings about it. First impressions of graphql, they are quite desperate to show how they are better than rest. A lot of the tutorials repeat that they are better over and over, which can be a little off putting at first. Then it takes a little while to understand the different way it works. Things i found nice about it, I can see clear benefits to speed of coding and maintenance of a project. Having a clear contract between front end and back end with an edn schema in the middle is quite nice. The front end can start building things with a spec/schema backed contract, being able to see the shape of the data almost right away. It feels like its easy to extend and update to add new or update objects and mutations/queries. Things i found hard. There is a lot of support for other languages our there, with some really nice js clients (which makes sense as it was facebook project iirc). So when googling you have to work a bit harder. I found the #graphql and the graphql slack to be helpful and people to be friendly. You have to read and reread the main docs to understand the whole concepts when working with lacina. I found the lacina docs to be pretty bare bones so i had to look at ruby/js/etc examples to get a feel for it. Overall i'm enjoying it and its been quite a fun journey so far. It gives me a chance to use clojure spec as well in the resolver-functions which is something i've not used before too. Apologies for the wall of opinons/text

guy09:10:15

@mccraigmccraig i hope that helps

maleghast10:10:12

Morning All…

guy10:10:46

morning!

reborg10:10:15

something I'm trying to get with graphql lacinia is, if I already have core.spec definitions of most of the objects that end up in a query, is there a way I don't need to repeat myself with a new edn dialect? Maybe it's a solved problem already

dominicm10:10:10

I think trying to use spec for everything will result in inflexible specs.

yogidevbear10:10:51

Morning all 🙂

reborg10:10:26

well, @dominicm then I'd love a generator spec->graphql 🙂

dominicm10:10:46

@reborg not sure I follow

guy10:10:08

I think its slightly different @reborg

guy10:10:55

In the edn schema you have to specifify if things need to be non nullable in different thigns

guy10:10:02

like in mutations vs objects

guy10:10:51

well thinking about it

guy10:10:56

im not so sure anymore

guy10:10:06

because you can still make things optional in spec too :thinking_face:

guy10:10:11

I wonder if the core.spec definitions will fulfill the graphql specification though

reborg10:10:12

For example, a game query is described with something like https://github.com/hlship/boardgamegeek-graphql-proxy/blob/master/resources/bgg-schema.edn#L19 That is not necessarily a full spec for a board game, but it overlaps with one if you happen to already have a board-game as core.spec somewhere. I was just wondering if I could just generate/derive the query from the specs.

dominicm10:10:48

I think about it this way: there's an impedence mismatch in the contracts that are provided by spec & graphql. In order to align them you have to: 1) constrain your specs throughout the application to use the subset which graphql can understand: I think this is very restricting, and is not an obvious design choice when adding a spec that it's going to screw up everything else. 2) write a very powerful clojure parser that can infer (valid-age?) means that this needs to be a number in graphql. Essentially, conversion requires alignment of contracts. Spec's contract is extremely open, meaning that it's a lot of work to align it with other contracts. This is the power of spec.

cddr10:10:13

Very interesting. I've been thinking similar thoughts about spec in relation to avro.

dominicm12:10:01

I'm glad I've finally figured out how to word it such that someone else can understand my concerns. I think it's quite a subtle point.

mccraigmccraig14:10:03

presumably (i'm not a spec user yet, so have to presume) you could go the other way and generate a bunch of specs from your graphql. would that be useful ?

dominicm15:10:36

Yep. Going the other way is easier in some sense. Depending on what you're after, it might be useful.

dominicm15:10:11

If you want one true™ :user/name, then nope. If you're happy to have :user.graphql/name just for generation purposes, then go for it.

cddr17:10:10

I haven't used specs heavily on the project I'm on but my understanding is that they can be composed. Something like valid-age? would be like

(s/def ::valid-age (s/and integer? (greater-than 18))
When generating the graphql (or any "lossy" schema syntax), you can just look at the first predicate in the s/and and use that Not sure I have explained this very well but what I mean is implemented in this PR for spec-tools https://github.com/metosin/spec-tools/pull/69/files

dominicm18:10:06

They can. But I feel like you shouldn't replace clojure.core/and with clojure.spec/and.

dominicm18:10:51

That's just a weird gut instinct I have though. Like, why should I be changing the way I write my predicates for spec?

dominicm10:10:27

2 is a little facetitiously worded, but I think the point holds up. Every predicate you add for validation needs to also be added to the parser for spec->gql, just in case. And those found in libraries too.

glenjamin10:10:13

i’d probably go for something like “test that data generated from specs matches the graphql definition”

glenjamin10:10:23

then at least you get a decent automated check that they’re in sync

reborg10:10:12

not sure is doable, just noticing the repetition (between something like graphql edn, core.spec and sql create table if you have them). Wondering if one could add a graphql plugin to https://github.com/andrewmcveigh/speculate

otfrom13:10:13

org-mode can do all

conan14:10:51

@otfrom hey, i just noticed you guys are right round the corner in bermondsey, right? we're in the biscuit factory. i should buy you a beer

maleghast16:10:50

Anyone about got any experience with enlive and DOM selectors? I need to grab all the nodes that match the following selector:

body > table > tbody > tr:nth-child(2) > td > a

maleghast16:10:37

but I am not particularly clear on the enlive approach to the selector syntax… Any pointers / ideas..?

maleghast16:10:51

(selector captured using Chrome Dev Tools)

dominicm16:10:20

I'm verycertain this is possible

maleghast16:10:34

@dominicm - Yeah, I think it ought to be, but I am just not completely clear on how…

maleghast16:10:03

The documentation and the tutorials I have found do seem to be making the assumption that there will be CSS classes and / or ids…

maleghast16:10:14

The page I am attempting to scrape has NONE

dominicm16:10:15

There's an nth-child function

dominicm16:10:32

:body will match the body, no?

maleghast16:10:40

It’s nested vecs… Hold on I will show you in a sec…

maleghast16:10:11

I am up to here:

(html/select [:body [:table [:tbody]]])

maleghast16:10:17

and this works so far…

maleghast16:10:33

Actually that does not and it’s not as simple as all that, but I am getting there…

dominicm19:10:49

Interesting

dominicm19:10:37

We're using a script on top for passwords, which uses gpg

glenjamin19:10:41

I had a funny open-source interaction today

glenjamin19:10:09

got a PR which bumps dependencies on a module of mine, but also added a linter and changed a bunch of source code formatting

glenjamin19:10:33

this is a module which is a bit untidy, but basically stable and has barely been touched over the last few years

glenjamin19:10:48

so i said “why would we do this unless we were going to write a bunch more code?”

glenjamin19:10:07

and he said “I’m planning to go attack that TODO list you have in the README”

glenjamin19:10:44

so I said fine, and started merging linter stuff - but I wish he’d opened with that explanation 😄

seancorfield19:10:20

Software engineers are not always known for their communication skills! 🙂 I've been doing OSS work for over 20 years and it definitely has its highs and lows in terms of interactions with my peers...

yogidevbear21:10:03

Out of curiosity, what formatting is the norm when naming collections or functions where the name consists of multiple words? E.g: (def some-descriptive-name { :foo "bar" }) vs (def some_descriptive_name { :foo "bar" }) vs ???

mccraigmccraig22:10:35

kebab-case is the clojure norm @yogidevbear

mccraigmccraig22:10:44

though i often end up with a bit of snake_case around from using :keys destructuring on maps gotten from dbs where field names are usually in snake_case

yogidevbear22:10:45

Okay cool. That's what I figured