Morning

Morning 🙂

https://github.com/aws-samples/aws-codedeploy-samples/tree/master/load-balancing/elb#important-notice-about-handling-autoscaling-processes > Disclaimer: There's a small chance that an event is triggered while the deployment is progressing from one instance to another. The only way to avoid that completely whould be to monitor the deployment externally to CodeDeploy/AutoScaling and act accordingly. The effort on doing that compared to this depends on the each use case. > WARNING: If you are using this functionality you should only use CodeDepoyDefault.OneAtATime deployment configuration to ensure a serial execution of the scripts. Concurrent runs are not supported. So much caveats.

I suspect that Datomic is working around this somehow by using AWS Step Functions, but I'm not certain.

@mccraigmccraig thanks for the links! Having a read now.

also

morning!

morning

måååning

@alex.lynham happy to chat further - i'm a fan of doing all i/o async, and it's been working out well on yapster

Morning.

morning

Until this morning, I had been unaware that Gerald J. Sussman had co-written texts on Classical Mechanics and Functional Differential Geometry (with Scheme code). When my OH asks what I want for my birthday, I now have an answer!

ooo that looks pretty cool @rhinocratic, although my calculus skills are sadly atrophied compared to those of my 22yr old self

If the truth be told, mine are a bit rusty - probably 25 years since I used them for anything significant!

@mccraigmccraig indeed. Will probably take that up with you once I’ve digested. Most of the JS SDK for AWS is async for i/o as well so it does come up a lot

Morning

Bore da Clojurians

Bore da @agile_geek , a yw'n heulog lle rydych chi?

I tried to do some trigonometry the other day @rhinocratic @mccraigmccraig and it was a complete disaster.

I think my calculus would be even worse

@danieleneal My problem with trig was the number of identities one ends up having to memorise. I was never good at memorising rules and axioms - always seemed much easier to learn methods.

yeah all the sin(a+b)=sin a cos b + cos b sin a

in vast swathes

the thing I found was that in maths class the equations were carefully chosen to be solvable

but when you have an actual problem there's no guarantee that you'll end up with something that can be solved analytically

I ended up going round in circles trying out different identities but not making my equations any simpler

then I tried it in mathematica and it crashed

you need the intuition about which identities can be applied when, which seems to disappear without continued practice

yeah @mccraigmccraig that's exactly it - the intuition about where something can go

Morning!

I missed the morning coffee/breakfast run today 😞

but its almost saturday so i’m in a good mood 😄

I always liked maths precisely because I didn’t have to remember anything. I only had to understand it.

:thinking_face:

I have this problem where I find it hard to remember things that I don’t understand. History for example was a nightmare, because all of the dates seemed so arbitrary. (Though it was the only time in school I recall being taught to evaluate sources critically.)

@peterwestmacott 100%

history isn't really about dates (though it does help hinting at causality)

history is about reading and understanding bias

in primary documents

@peterwestmacott I identify with that - hopeless at history for that reason. My least favourite maths exam questions were always the ones along the lines of "State the axioms for ...".

(tho most history before university in the UK seems to be pretty poor)

I can remember things that i found exciting at the time. So I can still remember how to beat the boss inside of jabu jabu’s belly (zelda ocarina of time). But i constantly forget where ive put my keys or the like.

@otfrom I think history as a subject is both fascinating and important. But when exam questions say “On what date did x happen?” I say “I don’t care”.

@guy you should hide your keys inside jabu jabu’s belly

indeed 😞

@guy remove the retrospective recall and replace it with habit and forward-thinking - always but always put your keys in the same place, and in the cases where you can't do that put them somewhere where you can't possibly forget them - in the pocket of the trousers you will put on in the morning, or the bag you will take with you

I was thinking about just getting a keys hook, at a high enough level that only I can reach it :thinking_face:

But i like the idea with habit and foward thinking so thanks 😄

My youngest had put spoons in my trainers this morning

Which was cute and annoying all at the same time

a key-hook fulfils the habit approach!

a keys hook just inside the door works for me

She’s got a fun game where she gets a ladle and bangs a pan 😄 😅

i am always disturbed by the lack of spoons in my footwear, so i applaud your child's actions

Alright i’ll get to DIY tonight 😄

I use these: https://www.amazon.co.uk/Command-Small-Strips-17082-white/dp/B000VWHSSO/ref=lp_2540276031_1_24?s=diy&ie=UTF8&qid=1533202803&sr=1-24

or something like them

just stick em on the wall, they come off without damaging the wallpaper

awesome ill get them 😄

you can usually find them at whsmith too

well here's a nail for clojure.spec's coffin (10x-100x performance degradation): https://github.com/jafingerhut/funjible#wait-isnt-this-what-clojurespec-is-for

spec is not fast.

has no intentions of being fast afaik.

Fast enough for repl use.

that is my understanding as well. Would be interesting to see how it compares against schema

There was this but it’s 16 months out of date now http://muhuk.github.io/validation-benchmark/

spec is faster than I expected

It was pretty slow the first time they did that benchmark but then Rich/Alex did some perf work to speed it up

ah, interesting

TIL: https://github.com/ptaoussanis/truss

lol @ "A lightweight alternative to static typing"

Anyone hacking on interesting stuph at present? I would be, but keep getting distracted by work. :thinking_face:

I’ve been trying to hack something together to build architecture diagrams that would also pull live metrics about things so you could use it as a dashboard. Half because I think it would be useful, half because I wanted to learn more cljs

Sounds cool - sort of a visual indication if processes are timing out or chewing up memory or something?

Yeah. It would be configurable, you’d have to configure what metrics are the most important to show for a particular component. Ideally with thresholds for what healthy and unhealthy values are to change colour

Most of my time has been spent mastering re-frame - https://github.com/firthh/living-architecture

Just looking at your code for the diagram elements - I like the use of inline SVG!

Yeah, I wanted to learn that a little better rather than just reusing stuff

Hi, I have a question regarding your git practices on branch syncing in your team: - What do you use and why? The reason I ask is that I have a new person in the team and they are trying to argue that they should be merging into their topic branch, from master, with visible merge commits. I’m arguing that this does not add any value, to show that you’ve synced against master with this merge commit and you might as well just be rebasing master onto your topic branch. I’ve worked with ‘rebase into my topic branch’ flow for years. They’ve worked with merge into their topic branch with merge commits for years. The merge commits don’t bother them. They see it as OK as it shows that they’ve synced their branch with master. I’d rather not be spending time on this at all. But it’s here and I figured and ask for some advice about what your thoughts/feelings are on this. Thanks

merge commits are scourge

here everyone commits to master - but we’re a small team

@dotemacs showing that a sync has happened to a topic branch doesn't add any value from my own measures of good git history. That feels like the turning point, what are they optimizing for, and what are you?

Amen. This is my argument too. But they are passionate about it (or just trying to nit pick and stick with the flow that is familiar to them). All I’d like is to have clean history. So that I can look back and see what was changed and why. I know that seeing merge commits won’t kill me, but if they are unnecessary why add them.

I develop in my own branch... and then do a PR to master and if there are any merge conflicts I fix them there and then...

that is how I first learned it, so I don't really know any other way 😉

we use medium-lived version branches, and quite often shared topic-branches off of these. rebasing is great until you have to share - i prefer a bunch of commits on a local-private topic branch to be rebased before merging to the version branch, but it doesn't come up that often for us, and given how much of a pain it is to have rebased when you should have merged i slightly prefer people to always merge so they don't have to think about it

Gawd, it's hot in here. We're forbidden to open windows, the air conditioning is broken and we now have noisy evaporative cooling fans in the room. Since it's a closed system, the temperature just gradually climbs with the heat from the motors. 🤒 Any hotter, and Dave's Syndrome will kick in.

Just start pouring water all over yourself

:thumbsup:

Why can’t you open your windows?

😞

To stop people from jumping out, I think. If I insist on working nude, they'll soon fix the air conditioning.

@dotemacs merge commits get in the way when trying to git blame, or they have done for me.

OK, that is a good reason

We are 10 devs and we tend to just work on master. Means everyone has to think about what they're committing and make sure it doesn't break live, you get much more feedback early on as to progress, and you don't have a horrible huge merge mess to sort out at the end of a long lived branch 😉

But working in microservices does really help with that, as we're not often trying to work on the same microservice as someone else

@dotemacs verify that first, but I'm pretty sure I had to multi-hop or something, and something wasn't very clear. All a bit confused.

we pretty much do that @carr0t , but instead of a single master have a current dev-version branch on to which all previous version-branches are generally expected to be merged (e.g. to pick up hotfixes from the prod-version branch)

I’d rebase for clarity, but I’m used to single-developer, short-lived branches

I don’t like the mess that merges with conflicts create - after you’ve fixed up the conflicts, you are no longer able to distinguish clearly what came from master and what was your own idea of retrofitting it to your branch.

and (this is my personal experience) conflicts are easier to resolve (as in: less accidental bugs, due to resolving in smaller, localised chunks) when rebasing than when merging

it's pretty rare for us to have conflicts @lady3janepl - it does happen, but only maybe monthly, or when we merge from one major-version branch to another

Small branches, small commits, easier to rollback if you need to. Also easier to PR as well.

but again, very dependent on personal workflow. I insist on small branches, small commits, and small features.

small branches, rebase when master changes

@mccraigmccraig oh yeah, totally. Rather: in daily use situations, these methods are largely interchangeable. It’s when you encounter the edge cases that it starts to matter.

I think gelato just saved my life

(things like branches with a multitude of committers, long-lived integration branches, several people having their own experimental branches and working on the same feature and cherry-picking from one another, that sort of stuff. And yeah, conflicts.)

He pulled up these two articles https://dzone.com/articles/git-merge-vs-rebase https://www.atlassian.com/git/tutorials/merging-vs-rebasing and threw out these quotes from them: > rebasing loses the context provided by a merge commit—you can’t see > when upstream changes were incorporated into the feature. > Rebasing doesn’t work with pull requests, because you can’t see what > minor changes someone made. Rewriting of history is bad for > teamwork!” Regarding the first one, I can see that you can tell when with the merge commit when the change was added in relation to your work. But I still see your feature branch as something that should be applied on top of the existing master. So it’s really down to you to sort out that any issues/conflicts that you might have. Regarding the second one, I can see that you’re rewriting history in the context of “the master just keeps on changing, while you’re developing your branch, so with rebase all the changes in the master are seen as to have been written before any of your changes”. But otherwise I don’t see this as a loss.

How many of you are in the team?

😏

caps man

i like it

I mean, fundamentally, there are plenty of people who use both workflows. There are arguments both for and against both. But if he is 1 person and has just joined a team of 4-5 (say), then he can damn well do things the way the team already is

If it was a case of "Clearly your way is insane and mine is correct, everyone else does it my way", then fair enough. But it's not. Plenty of people work your way

You should have left the caps, it was hot 🙂

Is this really the hill he wants to die on?

It’s nuts

and there are 6 of us

Personally, I don't care how often you had to merge, or rebase, or whatever. I want the clearest set of either 1 commit (pull request?) or multiple sequential commits (rebase/push) on master so that I can clearly see the steps gone through. Re-merges of master just confuse that. How does that even appear when you merge it back in?

Does it appear as if you did a series of commits, then a merge back in, then a load of other peoples commits might appear, then you do another series of commits?

@dotemacs the first article is about the reverse, as you pointed out. That article doesn't support their view. > Rebasing doesn’t work with pull requests, because you can’t see what > minor changes someone made. Rewriting of history is bad for > teamwork!” I mean, this statement is not true. We rebase pull requests all the time, works fine. Rewriting history is not bad for teamwork at all. I don't want to see a play-by-play of every character you typed. I want to see large logical steps, like a cookbook, not a work log "Redirect water" "Fix leak" "Re-connect original pipe". If our review tools suck let's discuss that, and how often this is actually a problem. I'm pretty sure Github has actually solved the problem of pull requests being rebased now.

FWIW I would have one overriding requirement regardless of how you use Git. I want one commit I can revert to remove and entire feature if the customer/client/manager changes their mind. How you accomplish that doesn’t bother me

I don't actually mind if it's one commit or multiple, as long as they're all sequential

What's this all about then?

matt@The-Beast:~$ lein repl
user=> (for [x [0 1 2 3]] (do (println (str "x:" x)) (+ x 1)))
x:0
x:1
x:2
x:3
(1 2 3 4)
user=> exit
Bye for now!
matt@The-Beast:~$ clj
Clojure 1.9.0
user=> (for [x [0 1 2 3]] (do (println (str "x:" x)) (+ x 1)))
(x:0
x:1
x:2
x:3
1 2 3 4)
user=>  exit

@agile_geek how is that going to work with feature dependency graphs and bugfixes ?

clj doesn't work as I expect basically.

you’ve got a side effect inside a lazy sequence generator (disclaimer, not a specialist, but mixing things like that looks fishy)

I think there’s a race condition in the printing isn’t there?

is this reproducible?

yeah the side effect in the lazy sequence could interact badly with the REPL printing the result

https://stuartsierra.com/2015/08/25/clojure-donts-lazy-effects read this recently, may be a useful overview?

I’m surprised that you get different results, but not that surprised. The actual values returned from the expressions will be identical.

perhaps different repl impls printing the results and accessing the lazy-seq differently ?

Concurrency issues; it matters in what order characters are printed to stdout. I’ve had similar problems and used dorun as the external wrapper to the lazy-generator I think… but that was an attempt to force things to happen when I had no clue about what I should actually use.

I should have used doseq then, and the above printing code looks like it would benefit from dotimes https://clojuredocs.org/clojure.core/dotimes

Cheers, for the thoughts 🙂

I just wanna say thanks to everybody who pitched in on my question about git team work.

working on that with @mattford and the problem was indeed laziness

https://www.confluent.io/blog/welcoming-the-distributed-masonry-team-to-confluent/

This is nice news.