This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # aws (2)
- # beginners (32)
- # boot (147)
- # capetown (1)
- # cider (11)
- # cljs-dev (45)
- # cljsrn (57)
- # clojure (187)
- # clojure-russia (5)
- # clojure-spec (97)
- # clojure-uk (33)
- # clojurescript (33)
- # cloverage (17)
- # clr (4)
- # conf-proposals (93)
- # core-async (6)
- # cursive (9)
- # data-science (1)
- # datomic (24)
- # defnpodcast (1)
- # devcards (3)
- # emacs (3)
- # hoplon (95)
- # jobs (1)
- # off-topic (7)
- # om (97)
- # onyx (32)
- # overtone (1)
- # parinfer (4)
- # pedestal (1)
- # proton (1)
- # protorepl (13)
- # re-frame (4)
- # reagent (10)
- # specter (14)
- # untangled (40)
while testing is the broad focus, the testing of the scheduler is what the talk'll be about, so the abstract deserves a rewrite to focus on that.
maybe something like "testing in clojure 334: mocking, dependency injection, and a deep dive on rigorous testing of a reentrant scheduler"
My theory is that any title with a : or a - in it should be cut in half :)
I have just submitted my proposal to the conj 🙂 I’m pretty excited; it’s a new venue for me
(My proposal is about calling C code, so I don’t know how many people care — but I think it’s an excellent example of how Clojure’s strengths are really quite general and it turns out to do well in corners where you might not expect it)
@alexmiller: alas I comically missed the SL CFP; my mom is visiting so I won't be able to make that :(
@bvulpes glad to hear; my main concern is audience; it doesn't seem very popular right now
Feedback on this: "Specifying the World (Singles) World Singles runs around 100 Internet dating sites, with over 40,000 lines of Clojure at the core. As part of a massive refactoring to support a new API-based version of our platform, we're focusing on our data model and the associated validation and data transformation rules. Find out how we're using clojure.spec across multiple application layers to engage our business team and clarify our rules, improve robustness and confidence, and simplify our code. I'll show how we use clojure.spec to support three different data models (input, domain, and persistence), to automate validation and testing, and to ease the transition between them."
@ericnormand: so far folks seem to mostly be treating it as a distinct test architecture, ie different lifecycle from
clojure.test testing, because it may take much longer if you're pushing lots of generated data through your code.
But I'd expect to have regular unit tests to catch common or critical failures, with the generated stuff primarily catching edge cases. You could also have separate configs such that some amount of generated data is pushed through your code pre-deployment, and then lots more on a less frequent basis to catch rare edge cases before users do.
I think you're right about pushing a small # of generated data through before is a good idea
And I'd trust Sean's opinion way more than my own here, since he's been using it in prod for an extended amount of time, whereas our usage is still pretty experimental.
@ericnormand: we already use test.check with Expectations for property-based testing so this isn’t terribly different for us: we
expect certain things of the summarized result of running
We’re currently rebuilding our CI environments and planning to have a suite of generative tests that run there and run longer (bigger test size) that either don’t run as part of the DEV tests or only use small test sizes.
@ericnormand: We use
more-of and run the output of
stest/abbrev-result — Expectations does a good job of pretty printing the
:failures key if there are any.
I may look at enhancing Expectations so that it can do it more clearly, but it’s pretty good already
So… not much feedback in terms of changes to my title / abstract? Doesn’t look like @alexmiller is around for feedback...
I think that loses some snappiness — and @alexmiller already hinted that titles with
- are often too long and should be split / shortened. I think that applies to
with a bit as well.
Your last title is ok although it seems like you have a more specific focus on your abstract re layered data models that maybe could be the focus of the title
so this is a good hook. the part people often don’t do as well is to tell the reviewers in the private comments what the “several patterns” are explicitly - that is, what are you actually going to talk about.
you don’t need to do so here, but that’s what I (as a reviewer) want/need to see - because that’s actually more useful to us in understanding the talk
(and believing you actually have specific things and didn’t just write the abstract :)
if a proposal comes in early enough that I can ask that question, I will often go back to the submitter and do so, but most proposals come in in the last few days and it’s not possible to read and respond to them. In that case, reviewers have to make their best guess. And I guess conservatively. :)
and is it still earlier enough in the cfp for the back and forth you just mentioned?
I think in the talk it depends what expectation you want to set for the attendees
the #1 cause of an attendee not liking a talk is because it was different than their expectation
if you don’t state some level of assumed knowledge in the abstract then it’s on you to explain it (or not meet some people’s expectations)
it’s totally fine though to say “assumes basic knowledge of generative testing or test.check” or something like that
assuming we are multi-track for the conj, which I think we are (don’t remember)
if it’s single track then I think a certain amount of explanation is required
would you recommend putting in a link to some place where they can get the basic knowledge?
oh, and now I'm filling out the form and it says maximum 5 sentences for the abstract
Once we’ve submitted a talk, do we get a chance to update it if we think of new stuff?
Like expanding on the main points or whatever (your response to Eric above made me wonder if I needed to be more expansive in that section).
@ericnormand: link/reference is fine. I’d treat what the form says as general guidance re length - yours looks fine.
@seancorfield: if you want to send me a replacement I can update your entry, or you can also just resubmit. I usually run a pass before we do anything and delete old revs of a talk