Fork me on GitHub
#clojure-uk
<
2016-12-22
>
korny02:12:20

I think @agile_geek is the most ancient, if we get back to oldness wars, I'm not far behind him...

korny02:12:16

Though at 2am with a baby on my lap I feel about 95 :-)

agile_geek07:12:19

@seancorfield yeah, I am the most decrepit and ancient programmer on the planet. I remember when John McCarthy was just a post grad! Thanks for reminding me @korny!

seancorfield07:12:46

@agile_geek: unless you were unusually late going to uni I think I have three or four years on you...

yogidevbear07:12:20

Morning šŸ˜„

agile_geek08:12:52

@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! toot

agile_geek08:12:03

@jr0cket did I do something to upset you....come back... šŸ‘‹

jasonbell08:12:30

I thought @agile_geek was a state of mind, not an age. šŸ™‚

agile_geek08:12:18

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!

agile_geek09:12:15

@jasonbell scary thought but you're safe.

korny10:12:16

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.

agile_geek10:12:41

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!

agile_geek10:12:58

You are looking good for your age then

agile_geek10:12:57

Feel free to correct my mathematics as it's always been rubbish šŸ˜‰

korny10:12:51

Hmm, sorry, 1300 times!

korny10:12:48

And through the power of slack I've fixed it, so your comment looks more confused

jasonbell10:12:08

you can tell itā€™s near Christmas canā€™t you....

agile_geek10:12:14

My comments always look confused....similar to their author

agile_geek10:12:54

makes me older than you BTW

mccraigmccraig10:12:34

but how old is your baby @korny ?

korny10:12:14

That would make it too easy! It's a very new baby.

mccraigmccraig10:12:50

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 !

korny10:12:48

Does it help to mention that in 4 days it's my birthday?

mccraigmccraig11:12:29

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

minimal11:12:12

not all of us are Norse death gods that have been around for hundreds of years like you @mccraigmccraig

korny11:12:11

Try using weeks as a unit. And now I'm embarrassed by my crude approximations of date calculations

mccraigmccraig11:12:50

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 šŸ‘“

mccraigmccraig11:12:52

i find that hard to believe @minimal

jonpither13:12:54

really want a TL;DR; of @korny's age now

agile_geek13:12:50

@jonpither my age minus just under 2 years

jonpither13:12:16

(assoc @agile_geek :age (- (:age @korny) 2)))

jonpither13:12:42

actually that's wrong. NM

agile_geek13:12:41

(assoc @korny :age (- (:age @agile_geek) 2))

seancorfield16:12:15

@agile_geek: my boss (VP Eng) is half my age so I feel your "pain" there šŸ™‚

seancorfield16:12:59

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.

glenjamin17:12:21

Late to the party, but RE: the framework discussion from yesterday

glenjamin17:12:44

I donā€™t think frameworks create demand, at least not initially. They cater to a segment who wants a framework

glenjamin17:12:00

That demand is probably increased these days after the popularity of rails et al

glenjamin17:12:43

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

glenjamin17:12:05

which is probably a spectrum, but will have very different needs in the framework stakes

seancorfield17:12:43

@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!

glenjamin17:12:24

Whereas some companies would have started 20 or 30 fresh projects since 2009

seancorfield17:12:33

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.

glenjamin17:12:50

and would possibly leave them in the hands of clients who might hire someone else to pick up where they left off later

seancorfield17:12:23

Yeah, and I think consultancies that build a lot of apps would either develop their own ā€œframeworkā€ or use an off-the-shelf one?

agile_geek17:12:33

@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.

agile_geek18:12:08

Even if the framework is not great they tend to add constraints around the design and sometimes that's a good thing.

jonpither18:12:42

We build a collection of clojure apps. Rather than a framework to help though it helps to standardise on a 'stack'

jonpither18:12:39

@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

jonpither18:12:31

Fair enough, Im not there!

agile_geek18:12:37

They aren't writing their own DSL or anything

agile_geek18:12:59

simply struggling to settle on one approach to each issue.

agile_geek18:12:22

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.

agile_geek18:12:54

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.

agile_geek18:12:21

I think that communication and discipline are the key issues.

seancorfield19:12:38

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.

seancorfield19:12:56

(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)

agile_geek19:12:15

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

jonpither19:12:28

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.

agile_geek19:12:03

@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.

jonpither19:12:38

Arachne will certainly help us to frame the debate. It will be great to see it in action.

agile_geek19:12:50

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

jonpither19:12:50

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)

agile_geek19:12:56

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"

agile_geek19:12:51

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'

agile_geek19:12:23

These are actually the skills required of an 'architect'

glenjamin19:12:34

if you can isolate portions so people donā€™t often / donā€™t need to work on lots of different bits

glenjamin19:12:41

then the cost of inconsistency is reduced

agile_geek19:12:09

absolutely, again the role of a good architect

agile_geek19:12:40

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?'

agile_geek19:12:44

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

jonpither19:12:46

The management of people - hiring (and sadly firing) - is just as critical

seancorfield19:12:44

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.

agile_geek19:12:26

@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)

rickmoynihan23:12:09

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.

rickmoynihan23:12:13

Anyway, I hope Arachne will do something useful hereā€¦ but I worry it might be too heavy.

seancorfield23:12:52

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?

rickmoynihan23:12:33

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

seancorfield23:12:29

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...

seancorfield23:12:05

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.

rickmoynihan23:12:43

yeah - weā€™re actually probably quite good at that - but it takes time - and you have to choose your battles

seancorfield23:12:07

Remind me: where do you work @rickmoynihan ?

rickmoynihan23:12:18

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.

seancorfield23:12:58

Herding cats, only with data. Sounds like fun šŸ™‚

seancorfield23:12:02

Corralling all that random data and getting it organized for useful publications and analysis.

rickmoynihan23:12:20

yeah you have a point šŸ™‚

rickmoynihan23:12:33

Itā€™s pretty good funā€¦ a nice mix of client work + platform

seancorfield23:12:27

Cool story of Clojure adoption. 2008, eh? Almost prehistory!

rickmoynihan23:12:50

yeah - Iā€™ve been using it for a fair few years now šŸ™‚