This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (1)
- # beginners (172)
- # boot (47)
- # cider (7)
- # cljs-dev (30)
- # cljsrn (43)
- # clojure (180)
- # clojure-dusseldorf (1)
- # clojure-greece (1)
- # clojure-italy (3)
- # clojure-russia (41)
- # clojure-spec (67)
- # clojure-uk (101)
- # clojurescript (128)
- # core-async (4)
- # cursive (13)
- # datomic (29)
- # devcards (5)
- # emacs (19)
- # events (1)
- # hoplon (38)
- # lein-figwheel (1)
- # luminus (8)
- # midje (1)
- # off-topic (47)
- # om (10)
- # onyx (23)
- # protorepl (1)
- # re-frame (11)
- # reagent (7)
- # ring (3)
- # ring-swagger (9)
- # rum (6)
- # sql (5)
- # untangled (4)
I think @agile_geek is the most ancient, if we get back to oldness wars, I'm not far behind him...
@agile_geek: unless you were unusually late going to uni I think I have three or four years on you...
@seancorfield I love the fact that in 'real' life I try to fit in with the 'kids' in work (I'm old enough to be the father of the Head of Software Engineering at my current client!) but in this channel we have a p*ssing contest to see who is oldest!
Holy cr*p Batman! I'm a state of mind! Presumably a deranged state of mind 😉 My wife and children do wonder if I'm a figment of their fevered imagination sometimes!
You should be able to guess my age from this : in 4 days time I will be almost exactly 1300 times as old as my baby.
13 thousand times? Really? Not sure the math on that works out? even if your baby was only 4 days old that would be 52,000 days - approx 142 years old!
well, it's older than 4 days, since the earliest message in this channel from you which is still visible is on 18 dec, which means your age is >= 14 years @korny !
oh, i see - you are treating age as discrete @korny - that helps some. the least common multiple of 365 and 1300 is 94900, which means in 4 days you will be 260 years old 😬 although taking account of leap years looked like effort so i know i'm probably a bit wrong
not all of us are Norse death gods that have been around for hundreds of years like you @mccraigmccraig
Try using weeks as a unit. And now I'm embarrassed by my crude approximations of date calculations
ah, in which case you are most likely 25, 50, 75 or 100 years old. given that people always use flattering bio pics i would guess you are 75 👴
When I was "Senior Software Architect" at Macromedia I was one of the oldest people in the company. Then Adobe bought us and suddenly I was one of the youngest people in the company. Perhaps not surprisingly I didn't stay long at Adobe.
I don’t think frameworks create demand, at least not initially. They cater to a segment who wants a framework
And almost every discussions of such topics I see omits whether the target is a long-lived in-house application, or an agency-style “one-and-done” type of project
which is probably a spectrum, but will have very different needs in the framework stakes
@glenjamin Interesting distinction. At work our original legacy codebase was built without a framework (in CFML), then in 2009 a rewrite started (again in CFML) but using frameworks (MVC, IoC, ORM — argh!), and then as we rewrote some of that in Clojure we gravitated toward a framework more out of comfort than anything else, and now we are framework-free! Hooray!
I think if we wanted to stand up something quickly and didn’t plan to do a lot of long-term maintenance on it, we might consider a framework to “jump start” that but otherwise I think we’re done with frameworks.
and would possibly leave them in the hands of clients who might hire someone else to pick up where they left off later
Yeah, and I think consultancies that build a lot of apps would either develop their own “framework” or use an off-the-shelf one?
@glenjamin I agree they don't create demand. I think their strength is getting to market quickly and consitency, weakness is you have to carry the framework forward and you can get painted into a corner. However, I can see strong evidence in my current client that not having a framework has led to a patchwork of different approaches all cludged together.
Even if the framework is not great they tend to add constraints around the design and sometimes that's a good thing.
We build a collection of clojure apps. Rather than a framework to help though it helps to standardise on a 'stack'
@agile_geek your issue sounds more like the Lisp curse of devs overcooking and doing their thing, rather than having the guardrails of a framework to restrict/guide them
for example there are multiple ways of routing on the client side. Started with one way, then a different set of developers came in and took different approach but old way is still there in places, then they found issues and changed to new approach (but legacy approaches still there). I see this as language independent but a lack of maturity in idiomatic approaches to these issues in the CLojure community at large.
I don't care what the approach is as long as it works and you stay consistent. If you need to refactor to fix an issue, fine. Try out the approach, develop a way to incrementally move to the new way, bake the approach into every change in the backlog and ensure everyone understands the plan, execute.
Agreed. I see it with our code base in a lot of areas, as we gain more experience with Clojure. For example, with
clojure.spec, we have about three different approaches in the code base so far, as we’ve experimented with what works best. I think we’ve reached a good place now and over time we’ll bring the two earlier approaches in line with the latest “best practice” thinking. It can be really hard when there’s so little established best practices out there, and very little in the way of guidelines for idiomatic Clojure.
(it also doesn’t help that our code base initially started life as a set of libraries embedded in our legacy application and has evolved into standalone apps now — so our use of Component is a patchwork and our early use of mutable state still shows through in places)
I'm fine with this as an evolution. The bit teams need to get right is communicating what the current best practice is and how to migrate towards it. That's what I mean by discipline and comms
Yes agree. Not sure a framework would help in these cases (choosing a client side routing lib or clojure spec strategy), when the lang and ecosystem is still evolving at such a pace. Interesting thoughts though, in that large teams may suffer using such an evolving tech, especially with growth of team members + deadlines etc. I suppose the advantage of a framework is to have a known approach and to be firm and stick with what it offers, but in a large team the urge may always be there to splinter off, and the result could be better or worse (worse because at least with a pluggable stack some tempered evolutionary moves may be better than big bang bet-your-house moves). So it comes back to your discipline and comms, managing the people problem. TL;DR; with bigger teams a framework wont save you.
@jonpither very true. I think I'm drawn to frameworks as they tend to come with idiomatic approaches that most developers follow (you can still get rogue groups!) and they give you some sane defaults. The bit I dislike about all frameworks I've used is that once past the simple stuff you get painted into corners or you have to know the frameworks specifics very well. Also they bloat your app with things you may not want. I was hoping arachne might be different.
Arachne will certainly help us to frame the debate. It will be great to see it in action.
Interesting the pain I'm seeing currently is not changing the routing library (same one is in use as at start) it's because it's a library and can be used in multiple ways so it's strength is also a weakness
I'd love to see an informative guide on here's how to run large teams with a lang like Clojure (fast evolving, quite new)
I come back to a maxim I've chanted for 20 years "IT projects never fail due to technical concerns, they always fail because people failed to communicate properly"
I think the answer is 'make someone responsible for each component/service/app in your architecture' and it needs to be the right person. Not necessarily the best architect/developer but someone competent who has the respect of the teams and who can listen and facilitate discussions. But ultimately it's their call. Not quite 'benevolent dictator' but certainly not 'design by committee'
if you can isolate portions so people don’t often / don’t need to work on lots of different bits
Constantly applying single responsibility principle (in the large as well as the small) and thinking 'is this easy to change when I find out I got it wrong or the world has moved on?'
I've never been all that good at design decisions but I've always favoured easy of change over almost anything else and that way I've dug myself out of many holes in the past
And you need commitment from somewhere up the management chain that if (when?) you find you’ve made a wrong choice, you can actually spend the time/money to go back and correct it consistently across the whole code base.
@seancorfield agreed. Although, I have managed this kind of change incrementally alongside every other change by 'adjusting management expectations' (and pointing out the cost of not making the change)
I think framework’s could help with consistency. Don’t get me wrong I definitely like the building up from simple pieces approach - but it’s not without its drawbacks. For example we have maybe half a dozen web apps written in clojure. The lack of a good templating approach really hurts, because each project is different; and they all do things differently… Many were luminus projects to begin with, but then as luminus itself changed the template every month or so, have all drifted substantially from each other… some apps use mount others component, others neither for example. I personally don’t find it a huge problem as I know what to expect and how to deal with it… but I was asked to onboard a developer recently who needed to start a new project and I basically had to spend a day templating the start of the app of for him — e.g. putting in component/logging/liberator/aero etc etc I totally agree with the whole communication point; but often one of the best ways to communicate is through code, by establishing good patterns that work, and pointing people at them to copy/reapply. Unfortunately not having a framework means every project is unique, so if a developer googles stuff they won’t necessarily find an answer… Then they need to speak to me or one of the more experienced clojure developers on the team, which is great - but it’s also a distraction.
Anyway, I hope Arachne will do something useful here… but I worry it might be too heavy.
That makes me wonder how far a “corporate standard lein/boot template” would go? It would help in terms of starting a brand new web app… maybe even offer a guide for how existing apps work?
seancorfield: that definitely helps - but you learn more as you go on… so the template gets updated, but the older projects don’t get rewritten (at least not fast enough) so though the onramp is quicker the problem remains
Right, and that goes back to the comments about how should a company / client manage the process of continually updating “legacy” apps to current best practices… which is a hard sell, a lot of the time...
We only added Component into the mix toward the end of 2015 (I think) and it’s been a continual process ever since, converting more and more old code to follow that blueprint.
yeah - we’re actually probably quite good at that - but it takes time - and you have to choose your battles
Regarding frameworks though, I do sometimes wonder whether frameworks are fundamentally at odds with the clojure philosophy, which is why they’ll struggle to be adopted.
Basically I think a frameworks primarily become frameworks rather than just libraries when they start supplying and managing state…
And in the clojure philosophy, saying things about state is basically an application concern not a library concern… i.e. it’s usually better to have an application supply an
atom of state - rather than have a library def it.
Corralling all that random data and getting it organized for useful publications and analysis.