This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-02
Channels
- # aws-lambda (1)
- # beginners (28)
- # boot (54)
- # cider (11)
- # clara (28)
- # cljs-dev (74)
- # cljsrn (13)
- # clojure (342)
- # clojure-austin (3)
- # clojure-dusseldorf (4)
- # clojure-france (2)
- # clojure-greece (11)
- # clojure-italy (42)
- # clojure-poland (7)
- # clojure-russia (11)
- # clojure-spec (44)
- # clojure-uk (156)
- # clojure-ukraine (4)
- # clojurescript (102)
- # cursive (17)
- # datascript (19)
- # datomic (17)
- # dirac (39)
- # emacs (22)
- # funcool (56)
- # hoplon (25)
- # jobs (3)
- # jobs-discuss (31)
- # leiningen (2)
- # luminus (4)
- # lumo (3)
- # off-topic (47)
- # om (51)
- # onyx (57)
- # re-frame (13)
- # reagent (57)
- # remote-jobs (15)
- # ring (9)
- # ring-swagger (7)
- # robots (2)
- # rum (6)
- # specter (16)
- # sql (7)
- # test-check (37)
- # untangled (7)
- # yada (5)
@yogidevbear ClojureX bytes events are talk nights just like the monthly ones, but with a speaker associated with ClojureX (e.g have spoken at the conference previously)
Morning Cool, thanks John
Jade! Wazzuuuuup
Just joking, I'll stop doing that Jase
It’s okay, I use it as leverage to give @agile_geek a really hard time 🙂
Haha, and to convince him to do talks at events, yes?
Proposals from agile_geek?
A different style of volunteering
Good Morning! (And death to history!)
Morn'
@jasonbell you insulting yourself doesn't give me a hard time.. you're just perpetuating the meme I started...this makes me smile
Not sure you understand how schoolyard humour works?
If you're trying to deflect by joining in the joke, that's cool but wouldn't cause me a hard time.
Re: talk proposals from me...up until now I haven't had anything worth saying that's Clojure specific. I can talk about development processes/culture and architecture (generically) till the cows come home but none of it is anything to do with Clojure.
@agile_geek the Clojure community is one things that makes Clojure such a joy to use...
when I get stuck (which is quite often) I can come here (or other places) and ask my silly questions and you wonderful people help me (for which I am very thankful)
so maybe a talk about how the the Clj community can even become better at this would be something you could talk about.
I'm pretty sure agile_geek should propose his architecture experience report for this year
It's a pretty incoherent story atm but I may submit if I can edit it into something useful
It's nothing revolutionary BTW just personal realisations and quite satisfying resolutions to a number of problems I've wrestled with for years.
@agile_geek, you've got 9 months to put something together for ClojureX 😉 Plenty of time to make it more coherent. And any "battle tested in the wild" tales would be helpful to devs of all ages and experience levels
Less time than that for me to determine if it's worth submitting tho.
and as this has so far been 8 months in the making and I've barely managed to write any of it down that doesn't bode well!
my talks are usually months of thinking followed by a day or two of writing it down
I'm thinking about submitting a basic talk on Clojure to a ColdFusion conference in late October as there is some interest in Clojure within the cfml community thanks to Sean Corfield. Not sure if the talk would be any good though with me being a CLJ novice, but would give me something to work towards which would help me learn faster. Does that sound like a very silly idea?
@yogidevbear not a silly idea at all... how about making it a very introductory talk.. this is how you get started... and then give a few examples of what the advantages are over cfml.
@agile_geek - Last time I stood on a playground was in 1988, I assume you're still there 😉
@jasonbell absolutely...although I'm frozen in the playground of a few years earlier
@thomas, yeah, I was thinking along the lines of a talk called "Clojure, a whirlwind tour" and going over things like the resources/tooling (http://Clojars.org, Leiningen, Boot, etc.), language basics, code/file structure, ns, and maybe do a basic demo of a web app using ring, compojure, etc.
@yogidevbear try and keep it simple.... I don't think there is a need to mention both lein and boot (just one would be fine) and I probably wouldn't mention clojars (unless someone asks).
Yeah maybe you're right. I thought discussing the tooling / resources might be useful to some though. Maybe it's more of a two talks type offering. One to go over the tooling/ecosystem and one to actually demo the language itself. That said, this will be the first time putting myself into a public speak situation so best not to bite off more than I can chew 🙂
I know there is definite interest within that community so anything presented well would be welcome I think
@yogidevbear You need to pick out 1-3 things you want to focus on for a 25 min talk or 1 thing for a 10 min lightning talk. Anymore than that and your message gets lost and you won't have time. These talks work best when given from a 'What worked for me" or "What I learned" perspective. Your suggested topics target beginners so I would focus on what you think you wissh you'd known when you started.
It sounds more and more like I'm actually going to put a proposal together for that conference 😱
What format do you guys normally use when submitting a talk proposal doc?
yogidevbear usually there is an online form to fill in. Short but punchy descriptions help
@yogidevbear don't think we've formally opened CfP's yet
Oh, wasn't meaning ClojureX specifically
Almost all conferences have some online submission form
@yogidevbear please add to your presentation a picture where there are all languages as an bicycles with square wheels and Clojure one with circle wheels 😄
TBH, some languages are probably worst than bicycles with square wheels
I would try and demonstrate how clojure is different and why that (most of the time, but not always) has advantages.
Well for one, it's FP vs OOP / procedural
But I take you're point
what I have done in the past is show the various data structures (list, vectors, maps and maybe sets) and then map, filter and reduce.
I was thinking about demoing basic types and then lists, vectors, maps and sets and paralleling those to the data structures termed in cfml (structs, arrays, etc.)
@dominicm: not followed all of your conversation about j.n.URI
but be very wary of that class (and also j.n.URL
which is a travesty). j.n.URI
can’t encode/decode URI’s properly… especially in double encoding scenarios,in particular where a query param key/value is an encoded URI itself… e.g. if you URLEncode a uri that has a +
in it in a qparam it will fail.
j.n.URL
should be avoided like the plague too - because its .equals
method actually tries to resolve the URL!!! So never ever put that in a HashMap!
otfrom: good question. I have a side project where I’m writing a parser from the BNF spec (using instaparse & validating the model it with clojure.spec generators etc..) though that’s quite a way off being finished. there are URI classes in RDF4j that we use; but they do very little validation; so we use them when we don’t care about validation… when we do, well we use java.net.URI with some horrible workarounds via grafter.url — which provides a protocol abstraction over j.n.URI/L, it’s own record based one and the RFF4j implementations.
grafter-url currently acts as our interface to stuff
though there are some bugs in it too — which is one reason why I want to fix it with a proper parser etc
basically it turns out nobody parses URI’s properly (anywhere)
(here’s the horrendous bodge around double encoding with j.n.URI: https://github.com/Swirrl/grafter-url/blob/master/src/grafter/url.clj#L123 )
but it works properly
basically you have to use reflection to forcibly set a private field
so you can fix the behaviour of the constructor
and handle encoding/decoding yourself
even more 😱 is that no web browser parses URL’s properly either: https://webkit.org/blog/7086/url-parsing-in-webkit/
in practice it’s not a huge problem for our RDF work… usually you can just treat URI’s as opaque identifiers, and normally we want them to be pretty clean for readability purposes… the bodge was necessary because a +
was used in a URI which a webservice then encoded on a qparam, and it caused j.n.URI to freak out.
@rickmoynihan I'd be very interested to know if the library I linked could handle it at all
@dominicm: if they do that’d be great - it’d save me some work 🙂
I’m discouraged by the use of pretty crazy regexes though
@dominicm: and also their rationale is mistaken
equality check on URI is fine… equality check on URL does the DNS lookup
@rickmoynihan Me too, which prompted a discussion on parsing. I get the impression that the regexes are born out of knowledge of RFC
If I’m nitpicking I also disagree a little with their model… I think the model should ideally represent paths and query fragments as vectors of strings not strings themselves
@rickmoynihan paths should be strings, not vectors of strings, no?
well a common operation is to modify path segments etc… to .e.g. canonicalise etc
I’d probably represent a path of ///
as something like [”” “” “”]
but maybe strings are better
@rickmoynihan I agree it's common to treat it as segments, but I'd rather leave that task up to bidi 😉
dominicm: the thing is query fragments aren’t always a map. In grafter-url we provide two ways to view them, as ordered pairs or as a map.
@rickmoynihan in that case the value becomes a vector doesn't it. Hadn't considered that ordering of all params might be useful
Technically no, because the ordering of qparams in a URI can be meaningful. Sure, it seldom is meaningful, because the hash-like semantics are so common place; but the RFC considers the whole of a URI to be an identifier so preserving order is important.
Interesting, didn't know that property of URIs, I'll have to bare that further in mind in the future. I was aware of the repeated presence of a qparam having meaning, but not the ordering.
@rickmoynihan https://github.com/weavejester/integrant/issues/12 I went to open this exact issue last night 😆
dominicm: lol I’ve been meaning to open that issue for a while - only got round to it yesterday though.
On one of our client projects we're basically doing "component on top of aero" so it might make sense for us to swtich to integrant
Coincidentally, Component on top of Aero was one of the things I tried in Duct before moving to Integrant.
@weavejester Interesting, any strong reason you'd encourage a switch?
@dominicm I can only speak about my own reasons, but one of the problems I had with a Aero/config to Component approach is that anything I wanted to configure and happened to be tied into the dependency graph, I needed to wrap in a component.
@weavejester I don't understand that, can you rephrase please?
Sure. So for instance, say I had some Ring middleware that needed to access the database.
I can’t include that into a component dependency graph without writing a function that converts a component into a Ring middleware function.
I had the same problem with handlers, but eventually I just found that I was writing components for too much. They were too heavy to support the granular configuration I wanted.
Integrant can effectively extend further, because it’s not as heavy. It doesn’t need to wrap everything in components, because the dependency graph is declared in the configuration.
Ah, I understand. Yes, sorry, I see what you mean now. That's a general issue with Component as opposed to an aero/component combination problem though, yes?
Yeah, but if you don’t want to connect Component to a configuration then you can just do things with functions.
Like you can just hard code stuff and have a minimal top-level config
But if you want to configure everything, if you want your application structured around data
Then Component gets a bit heavy.
In regards to RDF @rickmoynihan @otfrom is there anything worth interoping from the old Jena Java API for RDF? It's years old but it was the best thing at the time for parsing RDF for the JVM.
jasonbell: suggest we take this to #rdf — I’m more of a fan of RDF4j (formerly sesame) than Jena - as the API’s are much much cleaner and nicer. Grafter wraps it in a clojure layer: https://github.com/Swirrl/grafter I have a plan to eventually port grafter to a core.rdf project and interop with either sesame/jena backends too.
We use both JENA and sesame/RDF4j — as JENA is better for some things and RD4j for others. Code quality / readability / usability in RDF4j is much higher IMHO though. (disclaimer I’m technically an RDF4j committer - but more in name not in practice, and my opinions were formed before I was invited to be one)
For reading/writing RDF RDF4j/sesame has a pretty nice/clean API and supports basically every RDF serialisation reliably & grafter exposes that capability as pretty idiomatic clojure lazy sequences. The usage of this bit is largely undocumented but straightforward, stable and widely used at swirrl.
@weavejester we use #ref
to bring in configuration like that, or am I misunderstanding? (I'm running a bit slow tonight)
@dominicm #ref as in Aero’s #ref, rather than Integrant’s #ref?
@weavejester yes, aero's, my apologies.
So if you think of it as being divided into “configuration” and “implementation”. So a configuration might be a database URI, and an implementation might be a database connection.
Some implementations depend on other implementations.
Aero allows you to #ref other parts of the configuration
But not the implementation.
For instance, a middleware function might need a datomic database connection. So the middleware configuration depends on the database implementation.
Does that make sense at all, @dominicm? 🙂
@weavejester ah, so #ig/ref is superior to #aero/ref because it can auto-"componentize" anything that it needs to, to a degree.
Not sure I’d say it’s superior 🙂
But it does do more. It brings in the “implementation” rather than the “configuration”.
Just thinking about a feature for aero where a "ref" could be resolved in different ways. Unsure about quite how it would work though. Probably don't want to restart your system each time you re-read the config
I think you do want to restart your system each time you change the configuration. But you can scavenge connections etc. from the old system.
@weavejester I mean more that. Reading the config shouldn't cause the system to be read.
Right. But you’d ideally have something like: (run-system (read-config “foo.edn”)) => system
You produce a system from a configuration. When you’re done with the system, you discard it.
@weavejester approximately how does #ig/ref work? Does it attach metadata / replace with a particular container that integrant knows?
@dominicm No, it doesn’t use any containers. When you init
an integrant configuration map, the keys are walked in dependency order, producing an implementation map. Refs are replaced with the corresponding implementation.
Because the dependency tree is static, and can be worked out from the configuration, we can build it up without using any sort of container or metadata system.
That said, in order to halt
the tree, the original config map is attached as metadata to the implementation.
@weavejester I wonder if that would have worked for aero actually 😊
@weavejester do you handle dependency cyles?
I’m using Stuart’s dependency library, the same one that’s used for Component. Any dependency cycles cause an error.
@weavejester okay, same as aero then. Okay, I thought you were doing a (start)
over the args, not building a dep graph
Yeah, it builds up a dependency graph to figure out which keys to init
first.
I think I need to play with it a bit. I've got a little toy project currently on mount, so a switch would probably be a good experiment.
@weavejester oh, this is the container I was asking about: https://github.com/weavejester/integrant/blob/64dc418f2628adc1a1eba5939e1b985a56493e0d/src/integrant/core.cljc#L9-L15
@dominicm Oh, you meant the container of the ref itself. Yeah, it’s just a record with a single key.
@dominicm @weavejester: I’m very curious to try integrant (which I think looks like a nice improvement on component — and seems significantly better than mount)
in particular I’d also like to hear about how well it works with aero
@rickmoynihan You should just be able to use it straight with Aero, once you add a data reader for integrant.core/ref
.