This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-04
Channels
- # architecture (27)
- # bangalore-clj (4)
- # beginners (22)
- # boot (35)
- # cider (26)
- # cljs-dev (2)
- # cljsrn (3)
- # clojure (156)
- # clojure-austria (3)
- # clojure-dev (9)
- # clojure-italy (25)
- # clojure-nl (10)
- # clojure-poland (5)
- # clojure-sanfrancisco (1)
- # clojure-spec (6)
- # clojure-uk (64)
- # clojurescript (169)
- # core-async (13)
- # cursive (13)
- # datomic (63)
- # dirac (50)
- # duct (21)
- # editors (1)
- # emacs (6)
- # events (1)
- # fulcro (1)
- # java (22)
- # keechma (14)
- # leiningen (2)
- # luminus (4)
- # off-topic (23)
- # onyx (4)
- # parinfer (5)
- # pedestal (4)
- # re-frame (6)
- # reagent (4)
- # ring-swagger (7)
- # rum (4)
- # shadow-cljs (84)
- # specter (5)
- # sql (36)
- # tools-deps (76)
- # uncomplicate (3)
- # yada (4)
Morning
@lady3janepl did you make it in the end? I couldn't go and had to change my RSVP on meetup
Hello friend π
@yogidevbear yes I did! Loved the talk about Clara rules engine and the one about AWS got me thinking >.>
Morning. π΄
Having a bit of trouble with Mach (though I think it's more lack of experience with js in general). I'm trying to get it to fill in a mustache template with data provided in an edn file.
Figured I could use the npm mustache library to do this but I can't figure out how to require
it correctly. Tried following a few of the examples but none of them worked. Going by the usage example, on npm, mustache seems to export a global object called Mustache but if I try to reference js/Mustache
I get "Mustache is not defined".
Here's my Machfile
{
mach/dependencies [[aero "1.1.0"]]
mach/npm [[mustache "2.3.0"]]
mach/init (do
(def stache js/Mustache))
;;;
}
Did anyone else listen to : https://www.reddit.com/r/Clojure/comments/8gp62v/problem_solving_and_clojure_19_with_rich_hickey/ Seems to be really cool!
Yes - I listened to it on my journey home yesterday. Quite a bit of interesting stuff in there.
It sounds like work on further host platforms beyond JVM, JavaScript and the CLR isn't a priority for Rich at present.
what's the most clojuriey way to a database library to handle integrity errors on inserts?
return null
? raise an exception?
@xlevus we go for ex-info
exceptions with a [:cause-key {:detail :info}]
variant encoded into the ex-data
map... if the op failed you want some way of handling that and since you will always have to deal with exceptions on the jvm you might as well use them as your failure info transport
cool. jdbc throws errors. Was wondering if it's clojurey to handle them sooner or later.
i think it depends on context. our web api code often lets them bubble through to http errors, while our streaming code tends to handle and log. the job of whatever is throwing is to provide enough info for sensible handling/logging/investigation later
What a beautiful day outside today βοΈ π
I'm guessing that you're not in Manchester. π
Kind of overcast here, but looks to be improving.
@rhinocratic Have I seen you at Lambda Lounge? You look familiar, and I am also in Mancs
@U6SUWNB9N Hello Dan - sorry, I missed your message earlier. I was at Lambda Lounge last month - and some time ago I used to work at ISS. There was an overlap (fairly brief, I think!) when we were both there.
Ahha! π:skin-tone-2: That photo was in ISS wasnβt it? I recognise the ceilings ;) I was there β04. (Old building) to β14. Were you down in CIS?
I was - on Floor B, from April 2014 to December 2017. I was in the Web Services Team, (David Harrison's team). Doing Student Portal / Staff Intranet stuff. And yes, the photo is in ISS. I probably ought to update it now that I've gone all beardy.
Is it that bad in Manchester? My brother recently moved to Aberdeen of all places and he messaged me asking if it sounds sensible to be wearing shorts in 16 degree weather π
I'd hate to think what it could mean to snap a body part called the rear axle
still grey as hellll in mcr rn
who'da thunk it, manchester: hotbed of clojure
@guy yes - and I thought codeq sounded intriguing.
I remember discussing a vaguely similar idea with someone at EuroClojure a few years ago - depending on individual functions, maybe in a βgistβ or something. Iβd be super interested to see where Rich is going with that.
I don't think tools.deps.alpha supports that kind of granularity, so I'm wondering how it ties back in.
but it has custom dependency resolution doesnβt it - or at least it is supposedly extensible in that regard?
I wasted quite a few hours this week because somehow the docker container wasn't running the latest version of the code... and I rebuild everything several time... deleting all the containers/images in the end seem to do the trick.
I could imagine splitting a lib into a bunch of single-function nano-libs deployed as gists, and then depending on only the ones needed.
It would negate the need for any kind of dead code elimination, if you only depended on the individual functions that were called.
I have done little experiments like that using datascript and a graph like schema. dependency resolution is just a [?e :fn/name ?code]
away.
I find the codeq bits very exciting, referring to fn
s like that could be amazing for things like reagent
components that can evolve very quicly for example.
I briefly talked to rich about it at the conj, they were experimenting with it