Fork me on GitHub
#clojure-uk
<
2018-08-02
>
yogidevbear07:08:10

Morning šŸ™‚

dominicm07:08:23

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.

dominicm07:08:37

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

alexlynham07:08:05

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

mccraigmccraig07:08:13

mƄƄƄning

mccraigmccraig07:08:01

@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

rhinocratic07:08:44

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!

mccraigmccraig07:08:17

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

rhinocratic07:08:42

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

alexlynham07:08:14

@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

agile_geek08:08:39

Bore da Clojurians welsh_flag

thomas08:08:47

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

agile_geek10:08:17

Maeā€™n heulog

agile_geek10:08:43

and thatā€™s exhausted my welsh

danielneal08:08:03

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

danielneal08:08:14

I think my calculus would be even worse

rhinocratic08:08:43

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

danielneal08:08:15

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

danielneal08:08:22

in vast swathes

danielneal08:08:39

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

danielneal08:08:22

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

danielneal08:08:28

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

danielneal08:08:37

then I tried it in mathematica and it crashed

rhinocratic08:08:05

@danieleneal Ages since I used Mathematica (my first job was making Maths animations). It contained quite a nice functional language, as I recall - but it's probably changed a lot since then! Do you use it much?

danielneal08:08:57

Haha I only installed a trial version to see if it could solve this particular problem. I heard good things about the language and the clever symbolic stuff it could do but it couldn't solve my problem so I left disappointed šŸ˜„

rhinocratic09:08:31

I think I've still got a "student" licence for version 7, which wasn't as prohibitively expensive as the commercial offering. Rarely used, but occasionally invaluable.

mccraigmccraig08:08:45

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

šŸ’Æ 4
danielneal08:08:25

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

šŸ’Æ 4
guy08:08:16

Morning!

guy08:08:32

I missed the morning coffee/breakfast run today šŸ˜ž

guy08:08:44

but its almost saturday so iā€™m in a good mood šŸ˜„

Rachel Westmacott09:08:42

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

guy09:08:00

:thinking_face:

Rachel Westmacott09:08:43

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

āž• 8
otfrom09:08:23

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

otfrom09:08:40

history is about reading and understanding bias

otfrom09:08:53

in primary documents

rhinocratic09:08:00

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

otfrom09:08:24

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

guy09:08:21

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.

Rachel Westmacott09:08:24

@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ā€.

Rachel Westmacott09:08:27

(as in: I donā€™t care about absolute dates, but I agree that relative ones as you say ā€œhint at causalityā€)

otfrom09:08:18

I refer you to my earlier statement about history in the UK being taught poorly. šŸ˜‰

šŸ‘ 4
Rachel Westmacott09:08:19

NOT JUST HISTORY.

otfrom10:08:27

yeah, but I'm less well placed to comment on that.

Rachel Westmacott09:08:02

@guy you should hide your keys inside jabu jabuā€™s belly

guy09:08:13

indeed šŸ˜ž

mccraigmccraig09:08:00

@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

guy09:08:27

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

guy09:08:44

But i like the idea with habit and foward thinking so thanks šŸ˜„

guy09:08:37

My youngest had put spoons in my trainers this morning

guy09:08:45

Which was cute and annoying all at the same time

mccraigmccraig09:08:53

a key-hook fulfils the habit approach!

šŸ‘Œ 4
danielneal09:08:04

a keys hook just inside the door works for me

šŸ‘Œ 4
guy09:08:06

Sheā€™s got a fun game where she gets a ladle and bangs a pan šŸ˜„ šŸ˜…

mccraigmccraig09:08:21

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

guy09:08:23

Alright iā€™ll get to DIY tonight šŸ˜„

danielneal09:08:31

or something like them

danielneal09:08:46

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

guy09:08:18

awesome ill get them šŸ˜„

šŸ’„ 4
danielneal09:08:49

you can usually find them at whsmith too

mccraigmccraig09:08:03

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

dominicm09:08:46

spec is not fast.

dominicm09:08:55

has no intentions of being fast afaik.

dominicm09:08:59

Fast enough for repl use.

thomas09:08:45

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

minimal10:08:18

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

dominicm10:08:59

spec is faster than I expected

minimal10:08:35

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

dominicm10:08:35

ah, interesting

mccraigmccraig10:08:33

lol @ "A lightweight alternative to static typing"

rhinocratic11:08:17

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

firthh12:08:26

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

rhinocratic12:08:08

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

firthh12:08:35

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

firthh12:08:55

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

rhinocratic13:08:48

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

firthh13:08:48

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

dotemacs13:08:18

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

dominicm13:08:09

merge commits are scourge

Rachel Westmacott13:08:19

here everyone commits to master - but weā€™re a small team

dominicm13:08:47

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

dotemacs13:08:46

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.

thomas13:08:40

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

thomas13:08:00

that is how I first learned it, so I don't really know any other way šŸ˜‰

mccraigmccraig13:08:32

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

šŸ‘ 4
rhinocratic13:08:40

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.

guy13:08:19

Just start pouring water all over yourself

guy13:08:21

:thumbsup:

guy13:08:41

Why canā€™t you open your windows?

guy13:08:12

šŸ˜ž

rhinocratic13:08:32

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

šŸ˜‚ 16
dominicm13:08:34

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

dotemacs14:08:30

OK, that is a good reason

danm14:08:59

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 šŸ˜‰

danm14:08:46

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

dominicm14:08:14

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

mccraigmccraig14:08:58

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)

3Jane14:08:26

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

3Jane14:08:43

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.

3Jane14:08:38

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

mccraigmccraig14:08:25

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

jasonbell14:08:28

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

šŸ˜ 4
3Jane14:08:30

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

otfrom14:08:53

small branches, rebase when master changes

3Jane14:08:50

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

otfrom14:08:38

I think gelato just saved my life

šŸ‘ 8
šŸ¦ 12
3Jane14:08:41

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

dotemacs14:08:06

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.

danm14:08:37

How many of you are in the team?

guy14:08:43

šŸ˜

guy14:08:45

caps man

guy14:08:47

i like it

danm14:08:32

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

danm14:08:59

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

dotemacs14:08:34

You should have left the caps, it was hot šŸ™‚

danm14:08:44

Is this really the hill he wants to die on?

dotemacs14:08:23

Itā€™s nuts

dotemacs14:08:36

and there are 6 of us

danm14:08:49

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?

danm14:08:36

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?

dominicm14:08:39

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

12
agile_geek14:08:04

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

šŸ‘ 4
danm14:08:03

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

agile_geek14:08:37

Yeah, as long as you can clearly tell that to remove the feature/story/requirement you need to revert them all

mattford14:08:34

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

mccraigmccraig14:08:31

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

mattford14:08:08

clj doesn't work as I expect basically.

3Jane15:08:11

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

Rachel Westmacott15:08:24

I think thereā€™s a race condition in the printing isnā€™t there?

Rachel Westmacott15:08:30

is this reproducible?

Rachel Westmacott15:08:40

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

Rachel Westmacott15:08:17

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

mccraigmccraig15:08:34

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

3Jane15:08:56

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.

3Jane15:08:23

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

mattford16:08:47

Cheers, for the thoughts šŸ™‚

dotemacs16:08:08

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

otfrom17:08:11

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

jasonbell21:08:49

This is nice news.