Fork me on GitHub


  If x is reduced?, returns (deref x), else returns x


@dominicm I would go further and say having two boards is a very bad idea. The whole reason for having some visualisation mechanism, such as a story board, is to allow visibility on priorities and progress. All stakeholders need the same view because if one party has a different perspective they will push their own priorities over the other parties. I also strongly believe in treating 'bugs' exactly like any feature request, for the same reasons. If you keep a bug tracker separate from the 'stories' then users can't see why their wish list seems to be being delivered slower and they also get no insight into the impact of 'bugs' (reputation damage, user retention, conversion rates, etc.) I also think having visualisation of the 'funnel of work' for the team helps biz users realise they need to prioritise and prune the list. See two of my many rants on Agile below:


Morning All 🙂


Anyone on here got any experience with clojure.instant?


I am storing some dates in Datomic with "#inst" datatype, but I've realised that this might not be very flexible in terms of writing queries that, for example, would be about finding entities that have a date that falls in a particular month in a particular year... Unless of course there is some flexibility / utility in clojure.instant that I am missing...


@maleghast the inst in datomic is a java.util.Date 🙂.


You can use interop on it


Ok, so if I am Java 8 / Clojure 1.8 I can use clojure.Java-Time to interact with it..?


Datomic stores them as the older type, java.util.Date, operates on the newer java.time.* constructs. So no.


@dominicm - Ah, good to know; thanks 🙂


Quick follow-up, can I get away with using JodaTime / clj-time to avoid doing Java Interop


@maleghast clj-time has the coercion fns to convert from j.u.Date to joda & back


also, the Java 8 core time library has conversion functions (via toInstant methods iirc) and is functionally similar to Joda time (but without an additional dependency)


Depending on your data size & kinds of calculations, coercion may be undesirable or desirable.


I wish datomic just used java.time.*


@mccraigmccraig @peterwestmacott - Thanks, I will investigate further... I might split my dates up into year, month and day attributes so that I can do maths against them instead.


if you’re doing date maths yourself, just be sure to consider leap years / timezones etc.


Yeah, I will... Thanks 🙂


clj-time has add/subtract of different time units - doing it yourself correctly for all TZ / leap considerations is going to be hard!


@dominicm - I agree with you that it would be FANTASTIC if Datomic was using the up to date implementation...


Obviously, Cognitect don't want to exclude all those hundreds of thousands of enterprise customers who are still on Java 6 or 7.


@agile_geek - Yeah, I realise that is the case, and I am not "demanding" my feature here, just wishing it was so...


I really__ want to use Datomic, but I am starting to come to the conclusion that it might not be "best fit" for the things that I want to achieve at the moment. Perhaps in the future, or for better-fit use-cases as they come up...


what’s the closest open sauce alternative?


@maleghast Not sure if you've seen the day of datomic videos, but they talk about the bad/good places for datomic's use.


@dominicm - I will go looking, thanks 🙂


For me, Datomic is valuable simply because of it's query api, it's amazing.


@maleghast this is where they discuss, when to use datomic, and also capacity planning too. Interesting overall.


I'm working with it every day. I like it and there's been one requirement recently that would have been almost impossible without it's ability to 'time travel' but TBH I really suspect that we could have moved faster with a simple relational database


*nods* I am already impressed by that aspect of it, and I perceive real value in the immutable, passage-of-time paradigm that it offers, but I am not sure it's "right" for what I am doing / trying to do right now__


@agile_geek I love the safety that the immutability gives me. Nothing worse than having a db change values underneath you.


@dominicm - I am very interested in leveraging that aspect of what Datomic can do.


As a way of guaranteeing data integrity and auditability as well


(I am not sure that auditability is a word)


Absolutely, as I say I like it but the effort of moving a bunch of Ruby/Java/JS dev's to clj/cljs is enough without yet another new paradigm with it's own subtleties, Maybe it's just my 'conservative' CTO tendencies showing thru?


@agile_geek - I think that there is a pragmatism there that I can absolutely relate to 🙂


To wit, anyone prepared to stick their neck out and come down hard on either HugSQL or YeSQL?


I've used YeSQL in the past and liked it, but it occurred to me at the time that it might become unwieldy for a large project...


Am I being overly cautious and / or falling into the "premature optimisation is the root of all evil" trap, or am I right to be wary - discuss... 😉


HugSQL does appear to be quite similar actually...


It probably would become unwieldy. However, shared knowledge and experience of how to approach a problem is extremely valuable in avoiding unintended consequences and I too worry that 'we', as an industry, move too fast and throw away more than we should. No project I've ever worked on has failed due to technical reasons....always due to communication and shared vision between people so we should never take on additional cognitive load lightly, even if it is inherently better/simpler!


@agile_geek - I must admit I am tending to agree with you on everything there. I do think that there is merit in adopting new-tech if__ it's better tech, but there should be a conversation about real pros and cons rather than mere "Oooh shiny!"


That having been said there are some great examples of Clojure AND Datomic empowering really top quality development, so I am not unconfident that Clojure in general and Datomic in particular can__ offer the problems I am currently working on a lot of positives, but I think that there is a likelihood that my immediate challenges don't need to be encumbered with my own Datomic learning curve...


We shall see... I have to dart out to a meeting in a few minutes, so I am not going to solve this in theory or practice today. Time to accept and move on 😉


Time to say "bye, bye U.K." -- at LHR after a whirlwind week!


Re: HugSQL/YeSQL -- do those both separate our SQL from code?


Happy trails!


@seancorfield - Yes they both separate SQL from Code


Not sure whether I like that model... I've generally found code is easier to read if you can see the SQL inline with your code, for simple queries. And then the power of composability that HoneySQL provides makes the more complex queries easy to deal with.


I know some people like to keep their SQL separate -- heck, some people even prefer stored procs for that reason! Boggles my mind.


Are there (m)any other databases that have Datomic's db snapshotting feature? Either for a single query or for multiple.


@dominicm I don't know of any.... however I also have only come across a few problems that need this facility extensively.


Surely there's a race condition lying in wait when you don't have it?


or maybe even any batch processed too? OFFSET/LIMIT fails when new records get added. You can mitigate through ordering. But all problems disappear with an immutable db.


I think that answer is out of date: all options should be passed through now, including fetch size etc. If not, it's a bug 🙂


Not sure whether it's worth specifying a small fetch size like that...?


Probably not. My use is "for every member ever, go do X to them"


Per note later on "There's an open issue for :fetch-size not being passed down to prepare-statement in – Michiel Borkent" -- fixed!


I'd use row-fn for the "do X" part. Not sure how best to structure the result-set-fn to avoid realizing the entire sequence in memory. The default is doall which is fine until your result set won't fit in memory.


Internally it performs a map. Guess it might be nice to have an option to do run! instead if you don't care about the result?


Of course having a reducer option might be even better there simple_smile


(There's already an open issue for that)


@mccraigmccraig - That sounds interesting... Is it something that you can share..?


a similar interface should be possible with something like though


but then you would be leaving the confines of jdbc


@mccraigmccraig does cassandra support something cursor-like then? For large queries?


Thanks @mccraigmccraig I will take a look...


@dominicm always one active list of “up next”, multiple backlogs before that can be useful sometimes IME


@glenjamin I usually have a backlog of loosely prioritised/not prioritised stuff with a high or no WIP limit (although not being 'worked on' I'm not sure WIP is the correct phrase?) then a TODO column of stuff up next (with a hard WIP limit) plus whatever columns you want to track after that. If I'm doing Kanban I quite like having intermediary columns if I have handovers/handoffs between specialists on team to make waste visible (again a hard and low WIP limit - usually 1 'card' per person on the 'pull' side). As with all things it depends on situation but in Scrum I usually only use one board and one backlog per team.


yeah, so I’d say there’s sometimes value in segmenting that backlog of not prioritised stuff


depends how big it is I guess but I've had issues with users only interested in stuff on one backlog not realising that the team had other priorities


Anyone interested in giving a talk on 2nd May for London Clojurians? Dominic @ juxt has suggested a talk on how REPL tooling works. Could do with another 30min talk or one or two shorter talks


Alternatively I could run a "New Speaker" workshop as the ClojureX call for papers is open (and we are short of willing speakers for the talk nights). Thanks


Anyone got any idea how to solve this: I need to thread a map through sequential assoc calls, in order to update the value already in the map, so :

(-> coll
     (assoc :key-i-want-to-update (Double/parseDouble (get coll :key-i-want-to-update)
 (assoc :another-key-i-want-to-update (Double/parseDouble (get coll :another-key-i-want-to-update))


but... the "coll" is implicit as I am doing this inside another threading macro and the value threaded in by "(->" is from the previous expression


so it's like above, but:

     (assoc :key-i-want-to-update (Double/parseDouble (get coll :key-i-want-to-update)
 (assoc :another-key-i-want-to-update (Double/parseDouble (get coll :another-key-i-want-to-update))


  (update :key-i-want-to-update #(Double/parseDouble %))


& repeat for the the other key


You are kidding... I've just spent an hour looking for a solution to this and... OK - thanks 🙂


Yep - perfect... 🙂


@seancorfield that thing is running an old linux & ssh.


If you could get on it's network, you could possibly shellshock it & run arbitrary code... youch.


There's definitely an exploit.