This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (14)
- # beginners (133)
- # cider (27)
- # cljs-dev (7)
- # cljsjs (13)
- # clojure (105)
- # clojure-dev (58)
- # clojure-italy (1)
- # clojure-nl (17)
- # clojure-russia (33)
- # clojure-spec (5)
- # clojure-uk (154)
- # clojured (1)
- # clojurescript (35)
- # cloverage (4)
- # cursive (35)
- # datomic (58)
- # duct (8)
- # editors (9)
- # emacs (15)
- # events (1)
- # figwheel (47)
- # figwheel-main (132)
- # hyperfiddle (5)
- # immutant (29)
- # instaparse (21)
- # luminus (3)
- # off-topic (5)
- # onyx (5)
- # overtone (5)
- # pedestal (8)
- # re-frame (7)
- # reagent (6)
- # reitit (3)
- # schema (2)
- # shadow-cljs (178)
- # spacemacs (49)
- # specter (2)
- # sql (1)
- # tools-deps (110)
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.
@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
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
@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.
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
@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?
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 😄
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.
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
I always liked maths precisely because I didn’t have to remember anything. I only had to understand it.
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 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 ...".
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”.
(as in: I don’t care about absolute dates, but I agree that relative ones as you say “hint at causality”)
@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:
i am always disturbed by the lack of spoons in my footwear, so i applaud your child's actions
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
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/
It was pretty slow the first time they did that benchmark but then Rich/Alex did some perf work to speed it up
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!
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
@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...
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.
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.
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 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.
@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.
(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.
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
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
Yeah, as long as you can clearly tell that to remove the feature/story/requirement you need to revert them all
What's this all about then?
[email protected]:~$ 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! [email protected]:~$ 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 ?
you’ve got a side effect inside a lazy sequence generator (disclaimer, not a specialist, but mixing things like that looks fishy)
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
I just wanna say thanks to everybody who pitched in on my question about git team work.