This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # ai (1)
- # beginners (84)
- # boot (111)
- # cider (2)
- # cljsrn (9)
- # clojure (245)
- # clojure-italy (2)
- # clojure-mke (1)
- # clojure-russia (6)
- # clojure-spec (92)
- # clojure-uk (32)
- # clojurescript (55)
- # core-async (1)
- # cursive (8)
- # datomic (19)
- # events (1)
- # hoplon (379)
- # lambdaisland (4)
- # lein-figwheel (8)
- # off-topic (115)
- # om (18)
- # om-next (5)
- # onyx (25)
- # re-frame (8)
- # reagent (5)
- # ring-swagger (1)
- # rum (19)
- # schema (3)
- # untangled (24)
Back in 2008 I was lucky to be working at a (now defunkt) startup that let me use Clojure - original use was a system for clinical trials recruitment… Basically it was a clojure DSL for expressing consort diagrams as s-expressions - we installed the software on GP machines and it would query the current patient for trial suitability… the consort s-expression basically had several interpretations… one was as an executable query; the second was diagramatically as a funnel to visualise drop out rates… The DSL itself was pretty minimal maybe just two macros… an outermost one and an internal
branch one which was like
if but would capture extra data. Most of the code was in composable functions that you’d mount at the branch points… We had plans to write a GUI that would basically build the clojure sexpression as data for you… but sadly we never got that far in the end.
then I worked at a few other startups where I did a few bits and pieces in clojure — most notable was probably a pubsub message bus… then some time at an agency - where I only really used clojure on the side for prototyping & some one off ETL type jobs etc… - then swirrl
2 cents: we went the lein template route right at the start of our adoption at MixRadio, and although it did evolve, without it we wouldn't have been anywhere near as successful. It choose a selection of libraries for people, and most importantly, ensured that new projects worked with our deployment tooling, and metrics, logging in prod. Gave all the projects a similar layout to, which is really helpful. The template did get changed, especially towards the beginning, but after it settled there wasn't much to it. People still innovated on top of it, lots of unique flowers, but people only tend to experiment with one or two bits at a time, so in actually helped a lot there to.
Nice to see the framework discussion deepend after I left it last night. PS @rickmoynihan I completely agree about communication via code. In Architecture roles over the last 10 years I've often supplied reference implementations as well as the usual whiteboarding and docs. I find different ppl take to different forms of comms but code is Lingua Franca to Devs.
i'm increasingly coming to the conclusion that you need something higher than the code though, something that shows how the pieces vaguely work together. Across a group of micro-services the code can get you there, but with out a map it'll take you a long long time to grasp the over all flow of information that is at work.
yeah, I think the communication via code thing is a good reason to invest in refactoring and cleaning up legacy… to ensure that the right idioms become meme’s rather than the bad ones
tcoupland: yes - there’s always a role for something more… I think my point is that if you’re talking about code, often the best way to do it is with concrete code examples… it all depends on context of course, for example many algorithms you can’t simply understand by looking at the code… you need to read a paper or see a diagram or something too… But for idioms and ways of doing things etc, I think developers will often not ask, and just reach for code that’s infront of them anyway… I think improving code quality, helps decreases the proliferation of bad code meme’s
@tcoupland @rickmoynihan it's not even that you need different comms for different levels of abstraction (which you do) but you also need different forms of comms for ppl who learn differently. Some are visual and diagrams work, some need examples they can work through, some need a presentation and/or a workshop as they learn through interaction. I used to do all these when I ran teams. If I ever get back to running a number of development teams I think I might record presentation/workshop sessions as a resource to on board new dev's.
Mince pies consumed, play The Last of Us all morning. Half a blog post in the making. I’m bored now, just don’t tell the boss. 🙂
Told we’re going out to get some turkey, there’s something happening on Sunday I’ve been told.
you'll need the turkey to carry you through the days of darkness when no shops will be open. Cook it early before the lights go out
agile_geek: we’ve definitely had that same observation too… communication, information-flow and understanding is asymmetrical - all individuals (and therefore teams) are different, so you need to change how you work/communicate to accommodate who you’re working with
@agile_geek Totally agree with all of that, something I strive to have time for. It seems like your supposed to do all of those things, write more than half code, review in depth the over half, design all the database schemas, get everything setup in multiple environments, manage said environments and respond to any live issues at the drop of a hat! While mentoring people through all of those things too of course.