Fork me on GitHub

How's it going? I see you reppin' bidi in #clojure 😄


@seancorfield drops bidi into the Clojure In I'm busy working on 🙂


Well, @hiredman used it on one app he built at work and I kinda like the separation but it didn't fit as well into the "standard" way we'd been building web apps until that point... so I kinda need to try it out on a new web app and see how I feel about it and what I feel needs to change in our "standard" setup...


(he and I have very different views on how Component should be used which also played into that)


Makes sense, if you end up with any feedback it would be appreciated. We're itching a bit internally to do some non-breaking enhancements to bidi, so direction is welcome. Speed is something we're considering.


@seancorfield what are the two ways to use component?


main difficulty i've had with bidi @dominicm was syntax - now we have a sufficiently comprehensive set of routes that it's easy to copy, but in the beginning i found it rather hard to add new routes (and iirc i mistakenly used the map syntax rather than the vector syntax... switching to vector syntax made everything easier)


I view Component as coarse-grained, he views it as fine-grained. So I tend to have an Application Component that is passed into the Web App (and middleware passes it into each request) and subcomponents are passed into functions that the handlers call; he tends to have a lot of smaller Components (and a much larger map of dependencies) -- and defines his handlers as Components (essentially) so each handler can have explicit dependencies.


@mccraigmccraig most people report the map syntax as easier 😂 I think we want to deprecate it really though. Pairs4lyf.


kill the map syntax with 🔥


@seancorfield I understand both views. I have a preference for @hiredman's approach, having never actually had a chance to use it in practice. Now that I have integrant, I think I more want to use fine-grained, component makes the approach feel clunky. The reason is that I just end up with these massive hard-to-comprehend blobs of code, where I have to work harder to try and isolate the handler's dependencies and functions.


Well, our code base started off with globals and has only slowly adopted Component for legacy code (and globals still exist, mostly shadowing Component state now). If we were starting from scratch we'd do things differently 🙂


I've never seen a codebase like that, except that company who open sourced their code. I don't remember who now, but it felt very alien.


Like "that" -- which "that"?


(i don't use component for my context definitions, but) over time our app-context has become more and more fine-grained.. tending towards a hexagonal architecture... it's helped a lot with modularity and testing

Rachel Westmacott12:07:46

“hexagonal architecture”?


aka ports and adaptors - in our implementation we use protocols for ports and pass an app-context map around


fns get a very simple view of the world - an vanilla app-context map with dependency protocol impls - you want the db, lookup the db port from the app-context map etc


it’s a very simple idea, working very nicely for us


that, the globals


@dominicm That's how everything was done before Component, right? 🙂


Some of our production code dates back to 2011...


We set up JDBC connection pools as globals behind delay because we didn't want to pass a db-spec through everything (and we didn't want to use dynamic *db* vars).


By the time Component appeared, it seemed very hard to retrofit to our code. I asked Stuart about it and he didn't feel we'd be able to use Component. It was only later that I realized I could retain the globals for backward compatibility and have them set/unset in start/`stop` on the newly-introduced Components.


I came to clojure very late, component was well established by then.


Adopts Yorkshire accent "Luxury!" 🙂

😂 8

we actually did build our own dependency-management system with our own bare hands, while eating nowt but coal

🙂 4

(ok, the coal bit isn't true)


ah but did you have to get up 2 hours before you went to sleep and your father murdered you in your bed?


i love to get up 2 hours before i go to sleep, not so keen on the filicide though


Standing on the shoulders of giants 🙂


that's a nice pragmatic solution (setting globals in start/`stop`) to a gnarly problem @seancorfield


Adopts Yorkshire accent "Luxury!" 🙂

😂 8

Certainly if we were building this today, we'd never use globals. I happily tell everyone it was a terrible decision and we're still paying for it.


But we're also, slowly, digging ourselves out from under it. And all new code explicitly accepts one or more Components for any (stateful) dependencies it needs.


The joys of paying technical debt


No kidding. We have a tech-debt label in JIRA and regularly create Task tickets with that label to ensure we track any debt we know about (or discover).


We have a whole bunch of tickets around removing various globals -- but that means touching some fairly deep call chains to pass everything through instead, including some in our shudder legacy CFML code that calls into Clojure!


@seancorfield how do you allocate time to tech debt? Sometimes clients don't see the value, and it's start moving out of the bog of debt.


The Product Owner understands we need to address tech debt so it's just naturally part of our Kanban workflow.

💚 4

Sounds like you have a clued up PO? I wish I could get most of my clients for understand that tech debt interest is a real price you pay


In my current client they have a 3 year old system and the tech debt in just that is slowing development such that it’s taken almost 12 weeks to make a change to just the pricing algorithms to support new client sub systems for new markets.


Ah yes I’ve read that before. I’ve tweeted before about Tech Debt being a deliberate trade off design decision and lack of developer discipline is just not doing your job


Morning all!

👋 8


👋 8

Morning friends


Being a “T-shaped” person is really really hard. I can’t just concentrate on writing really clear code. Theres lots of layers to learn about these days! Do i just need to suck it up as reality or try something different? What are your experiences?


I keep a list of things I want to learn a little more about but that do not directly relate to my area of expertise. I try to tick off one or two every day. I do it because I find that the depth part of the T comes more naturally to me than the breadth part.


I populate that list mostly from reddit/blog posts, books or links I get passed.