Fork me on GitHub
#clojure-uk
<
2018-09-07
>
agile_geek06:09:52

Bore da pawb welsh_flag

agile_geek06:09:21

That article on rebasing is one of the reasons I don't use it for feature branches->master. I've definitely had the broken commit somewhere in a chain of many and also broken commits in messing up resolving conflicts. Arguably most of this could have been avoided if the org I was working for had either not used long living feature branches, committed to by many dev's, but in that particular culture it was the only sensible option.

💯 2
thomas07:09:02

mogge 😼

thomas07:09:27

my fix yesterday didn't fix the problem... so back to the drawing table.

otfrom07:09:48

thoughts and prayers @thomas

alexlynham08:09:42

morning morning

yogidevbear08:09:17

The comments in that article were interesting too.

yogidevbear08:09:49

Always mixed opinions based on coloured lenses

alexlynham08:09:29

idk I feel like rebase is something I reach for when I've messed up, but for day-to-day it's making a simple tool (git) unnecessarily complicated

alexlynham08:09:03

same reason why I don't like using protocols in clj unless there's some serious interop going on

alexlynham08:09:35

I guess my background is languages/humanities so I privilege being fluent/thinking in my lang and tools and if the vocab (feature set) expands beyond a point it's like one of those foreign languages with loads of tenses we don't have in english 😂

Conor08:09:46

Leigh anois go curamach na treoracha agus na ceisteanna a ghabhann le Cuid A. Minigh an tuiseal ginideach...

Conor08:09:59

Thanks for giving me a cold sweat flashback to my Irish exams dude

mccraigmccraig08:09:10

is irish a case-based language then @conor.p.farrell ?

alexlynham08:09:34

in the aliens' language from arrival you can rewrite your branch history

Conor08:09:18

Yes, you need to understand the genitive case, etc. etc. which is a right pain

Conor08:09:43

I wish I could speak it better, but it's not taught very well in school

mccraigmccraig08:09:23

i did russian for a while, which is also case-based... i don't think cases were very well taught there either - i certainly only have a vague understanding of how to apply them now

rickmoynihan09:09:28

The rebase article above is a bit of a strawman in my opinion — though I think unintentionally. Firstly there are many ways to do git… there are pros and cons to the different approaches… etc. Ultimately consider the options for your team, and do whatever works best for your team. Now the caveat is out of the way I agree with the wider point of the article. That is most teams with the rebase workflow have a silly desire to create an artificially linear history. This is IMHO completely misguided, mainly for the reasons the article states. However I think a better workflow is that feature branches should be rebased and tidied into a logical sequence, rebased ontop of upstream, and finally merged with --no-ff, i.e. I want linear sensible commits, but I want to see the boundaries of each feature, without “sync merges” blurring things. The problem with this approach is that most people do rebase wrong. So that dependencies on future commits are accidentally introduced & bisect etc becomes useless. The solution is simple which is that you need a rule for every commit to compile and pass the test suite (also every commit should be a single logical change). This is what you need to enforce for bisect to be truly useful, anyway… rebase is not to blame for not enforcing this. Essentially developers before pushing should run rebase -i and exec all the tests on each commit. The problem with the rule is that it requires a team with a lot of discipline; but it pays dividends when resolving conflicts, as you know all sides of the conflict work. If you don’t know this things become very difficult. The reason the article is a bit of a strawman is because they attack rebasing for breaking bisect; but bisect will be broken anyway without the discipline of enforcing (e.g. with ci) a rule that each commit works.

rickmoynihan09:09:28

Also they accuse rebase of making merges more confusing — but rebases often (though not always) make merges easier; as you get to resolve the conflicts piecemeal rather than all at once.

rickmoynihan09:09:51

I think ideally what you want to avoid is having visible “sync merges” in your history. You can do that two ways with the rebase strategy, or with git merge together with git rerere.

rickmoynihan09:09:52

At the end of the day it’s a trade off between quality and unnecessary process/waste. If your team are struggling a lot with conflicts, then adopting the above strategy spreads the work across the team; rather than forcing it all into a stressful merge process. It does require a lot of discipline and git fu though, so it’s certainly not suitable for all teams.

👍 1
thomas09:09:40

does anyone here have any experience with react? (just plain JS, no cljs what so ever, unfortunately)

thomas09:09:01

I am rather stuck on a problem at the moment

peterwestmacott10:09:02

not with plain JS, but you could try me

peterwestmacott10:09:43

or try #reagent / #react-native / #re-frame ?

peterwestmacott10:09:13

I expect someone in one of those would have some JS experience of React

thomas10:09:03

good idea... thank you @peterwestmacott

mccraigmccraig11:09:44

what's your problem @thomas?

mccraigmccraig11:09:49

(i've mostly used react via reagent, but i have been using it for a good while and have occasionally had to descend down to the js levels)

alexlynham13:09:05

has anybody here used apache flink?

thomas13:09:21

@mccraigmccraig something seems to update my state... but I don't know what/where/when

jasonbell13:09:19

@alex.lynham not properly, just kicked the tyres

alexlynham13:09:27

@jasonbell that's more than me! what were you using it for?

jasonbell13:09:08

Mainly to see if there was any features that would replace what I was doing in Kafka.

alexlynham13:09:22

it's come across my desk in a 'shopping basket' list of tech and I'm trying to work out if that's because the person who put it there 100% knows something I don't, or if they were just writing down a bunch of things they saw on thoughtworks tech radar or whatever

jasonbell13:09:25

Like I say, literally kicked the tyres. Some good stuff on Safari

alexlynham13:09:30

(and I don't mean that in a mean way)

jasonbell13:09:04

@alex.lynham yes the O'Reilly learning/book/vid platform

jasonbell13:09:32

I think MapR were giving out some Flink things for free, Ellen Friedman had written them

alexlynham13:09:54

I'm with you now

alexlynham13:09:14

some impressive performance stats I've seen, but performance isn't an issue we have

alexlynham14:09:35

thanks for the link 🙂

mccraigmccraig14:09:16

@thomas ah, i've never used component-state - it's not really necessary with reagent

thomas14:09:03

I know... this just confirms why cljs and reagent/re-frame are so much better IMHO than react and JS.

mccraigmccraig14:09:33

redux does a similar thing to re-frame doesn't it ?

mccraigmccraig14:09:59

single-source-of-truth, reduce events onto that state with handler fns

thomas14:09:21

I think it does... but not sure

alexlynham15:09:51

re-frame is just an even more opinionated version

otfrom15:09:25

hee hee. thx the @keithmantell for making a #brompton channel

👍 2
mccraigmccraig15:09:46

i'm not sure about cycling on roads @otfrom... it seems a bit unnatural

😂 2
otfrom15:09:15

@mccraigmccraig I mix it up by riding through the park and on the cycle superhighway too

otfrom15:09:41

it is all deeply, deeply unnatural, but that is just the mechanically enhanced world we live in

keithmantell15:09:44

brompton photo won't be there for long