This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-06
Channels
- # architecture (25)
- # bangalore-clj (1)
- # beginners (21)
- # boot (45)
- # cljs-dev (38)
- # clojure (272)
- # clojure-austin (7)
- # clojure-finland (7)
- # clojure-france (3)
- # clojure-italy (7)
- # clojure-japan (1)
- # clojure-russia (13)
- # clojure-spec (36)
- # clojure-uk (31)
- # clojurescript (96)
- # core-async (15)
- # cursive (16)
- # datascript (3)
- # datomic (97)
- # emacs (107)
- # hoplon (16)
- # jobs (9)
- # keechma (1)
- # luminus (1)
- # off-topic (19)
- # om (39)
- # onyx (15)
- # pedestal (3)
- # planck (22)
- # protorepl (4)
- # re-frame (20)
- # reagent (3)
- # ring-swagger (25)
- # specter (26)
- # test-check (19)
- # testing (1)
- # untangled (381)
@otfrom re: http://blog.jessitron.com/2017/02/reuse.html given our conversation on Tuesday reading this is quite frustrating as I'm half way thru writing something very similar myself but she's summed it up much more eloquently than I could! Oh well, I guess I'll have to find a different slant on premature abstraction to write about.
and instead we got recurring bugs in different products that had forked enough that you couldn’t copy-paste the fix
so while I agree with the problem statement, I don’t agree with the solution of giving up on reuse
@glenjamin I think it's a very hard problem to solve. I agree open sourcing it helps you get to the end point which IMHO is that the abstraction applied is a generic abstraction of the behaviour required rather than an abstraction that relies on the specifics of the biz domain and therefore the reuse is at library level. The reason I say this is that even if the developers have a shared understanding of the business domain and the architecture it's highly likely that this understanding will diverge in different areas/components of the business and system in the future. Although superficially the problem may appear the same, in many small but significant, ways the business requirements differ because if they didn't each team would actually be writing the same thing. Or if the reuse is in the macro and has domain specifics it may become a service but you need to examine whether the abstraction applied by that service is what you need before taking it on as component in your solution. One thing to guard for in open sourcing the reuse would be the differing demands from each contributor leading to the library growing out of control through accretion. This may suggest the abstraction is actually taking on two much and it's more than one high level abstraction with possibly one or more shared lower level abstractions?
IMHO almost all 'problems' in business related IT are problems of developer to developer/business owner communication! That's why I think that approaches that think only of technical solutions or process solutions in isolation are inherently flawed.
@thomas aye up! How's it going in the low lands today?
@agile_geek fine... went to see family yesterday.... as my daughter pointed out: it is very nice that we can visit family more often now... but it isn't as special as it was before.
morning!
"Does anybody else find themselves modifying the pages they're on when they find bugs?” I’ve been fixing the Concourse CI web view CSS while waiting for builds.
It would be super awesome to be able to push such fixes upstream
not just tech fixes - typos in content as well
(is there an app for that yet?)
@peterwestmacott there's a few services about.
Morning
I had a friend share this with me a moment ago so thought I'd repost here https://www.meetup.com/Londonjavacommunity/events/238211610/?rv=ea1&_af=event&_af_eid=238211610&https=on
Talk next week on Clojure and Kotlin