Fork me on GitHub

Good (well) morning. Getting reminded the hard way why I don't fancy traveling by train. I'm not coping well with how the train moves... :face_vomiting:

😟 2

Like getting carsick?


Exactly like that. In the car I can counter by watching the road. Anyway, feeling a lot better now. And we should soon be at our destination.


Funny. Yesterday I was suggesting to my family that we should be taking the new train option for a trip to Hamburg. Just as a fun and exciting thing to do. Not so keen right now. And my kids have an even worse time with car sickness than I do.


I 😍 the train and 😡 the plane.


Different strokes. Actually that's a canoe but you get the point.


That sucks. I believe trains are the future of intra-continental travel. Maybe you would feel differently in a high speed train though? It's a much smoother experience than a regular one. I've tried a bunch of them in China.


In Sweden the high speed trains are the worst in this respect. It was one of those I traveled with this morning. (Though Swedish ”high speed” trains would not be called that elsewhere. They are pretty slow. 😄)


man, that really sucks then.


But maybe the trains to Hamburg are not using these trains. I'll check. I really like the idea of a train adventure with the family.


Yeah, me too. It's really the only mode of transport, aside from boats, where you're not confined to a seat the whole time. I especially like sleeper trains.


And obviously the most efficient fuel-wise too.

🌍 1

I was traveling by plane yesterday. Perfect isolation, nothing to do but work. Got a weeks worth of work done in a couple of hours 🙂

😁 1
metal 1

Funny how that works. We have normalised living with so many distractions.

😢 1

I find the space in a plane too narrow compared to a train. I could barely open my macbook air 13" last time I was on a plane

💯 1

taking hammock-time to new heights

😄 3
Jakub Holý (HolyJak)09:09:32

At previous work we practiced no-meetings day (or at least 1/2). An official endorsement of plugging out and diving into work really helps to say no to all distractions. Nobody can complain about your slack and email being off during that period... (And they still have you ☎️ if a real crisis happens.)


Having said that, one could argue that with my role, it’s more important to unblock my colleagues than churning out new code. One might even say that I’ve failed if the situation is that I’m the only one available/capable of churning out said code.

💯 1

... he said, writing messages on Slack.

😹 2
Rachel Westmacott08:09:53

morny-mcmornface everyone!

👋 3
Rachel Westmacott09:09:01

Does anyone have any experience sticking core-async channels into stuartsierra.component system maps?

Ben Sless10:09:04

Can you elaborate?

Rachel Westmacott10:09:31

Well I want to use channels to communicate

Rachel Westmacott10:09:54

but then if I stick them in a system-map then I want them to be re-usable

Rachel Westmacott10:09:05

there's a question about lifecycle and idempotency

Rachel Westmacott10:09:27

eg. a channel can be closed, so arguably it has lifecycle

Rachel Westmacott10:09:36

but then how would you restart it?

Rachel Westmacott10:09:57

I feel like I end up needing to wrap my channels in an object, a bit like a decorator pattern

Ben Sless10:09:12

You can't restart it, you need to make a new one

Ben Sless10:09:19

Do channels take metadata?

Rachel Westmacott10:09:30

if they did that would be the solution

Rachel Westmacott10:09:41

I could add all sorts of stuff round the sides

Rachel Westmacott10:09:06

and easily provide instance-specific protocol implementations

Ben Sless10:09:13

Another trouble for me regarding channel life cycles is they are implicit sometimes

Rachel Westmacott10:09:19

I think I need to wrap them in a defrecord

Ben Sless10:09:25

If you autoclose them or something

Ben Sless10:09:53

Aaaand you can extend Lifecycle to channels

Rachel Westmacott10:09:00

yes, they can get closed not as part of a system shutdown

Rachel Westmacott10:09:09

I could do that, but I don't like it

Ben Sless10:09:12

So they don't really need a stop

Rachel Westmacott10:09:22

makes sense for stop, ensure the channel is closed

Ben Sless10:09:34

And the start could be with metadata on a vector of args, apply a/chan

Rachel Westmacott10:09:46

but start means you need to know the circumstances of the channels construction

Rachel Westmacott10:09:59

how does that survive a start -> stop -> start scenario?

Rachel Westmacott10:09:18

no metadata means it's just an opaque async channel in the middle

Rachel Westmacott10:09:31

you can't reclaim the constructor args for a new channel again

Ben Sless10:09:34

AFAIK you can't really restart a component system, can you? You need to make a new one anyway

Rachel Westmacott10:09:59

I like my components to be restartable - it can help at the repl

Ben Sless10:09:20

Sure does, although start just returns a new record anyway

Rachel Westmacott10:09:22

ideally a started and stopped system should be functionally identical to an unstarted one

Ben Sless10:09:11

Asking too much?

Ben Sless10:09:40

Part of life cycle is it ends. Let go of your dead channels 🙂

Rachel Westmacott10:09:41

I think it's simpler just to create a record that holds the core.async channel though

Rachel Westmacott10:09:49

"all things must pass"

👍 1
Ben Sless10:09:56

And on start will create a new one?

Rachel Westmacott10:09:24

yeah, a record with the constructor args (or fn), create a channel on start, close it on stop

Rachel Westmacott10:09:49

then I want an idiomatic way to expose the channel though, so when I'm using it it's not a pain

Ben Sless10:09:11

Principle of conservation of meh

Ben Sless10:09:39

You can only move the meh parts around, never get rid of them 🙃

💯 1
Rachel Westmacott10:09:34

IDeref is syntactically light (with @ to access the channel) but I'm not sure it conveys the right meaning (plus I have to faff around with prefer-method to stop it blowing up when trying to print a record that also implements IDeref at the repl

Ben Sless10:09:58

I actually have a gist for that which I want to make. a library out of, hang on I'll unprivate it

👍 1
Ben Sless10:09:54

The idea is a generic state component has • start: take the component as argument and create a state which you can access later • stop: if you want to • step: if you want to thread the state as a first argument to a function, that's the function

Ben Sless10:09:15

You can deref it to get the state

👍 1
Rachel Westmacott10:09:21

interesting, thanks!

Ben Sless11:09:39

Added a brief incomplete readme to explain why it's not a terrible idea 😄

Jakub Holý (HolyJak)09:09:53

Good morning, folks!


Maddain Mhath!


Good morning to branch out

😄 2

and try #scittle

sci 1

Good morning! Back from vacation, I woke up at 5am today to do a pre-sunrise scuba dive.

🤿 3

Life is good!


I'm oh so sleepy now, but it was worth it 🙂


So. I had this code:

(if whatever
   (then ...)
   (else ...))
Which I basically refactored into
(if whatever
   (else ...)
   (then ...))
The details of why are perhaps not so interesting, but what is interesting is that tests still passed. Looking into this, it was because the code in else function was very defensive and ended up doing what the then fn was doing. So I removed the defensive stuff in else, and as expected, the tests blew up, and I could fix the if test properly. But it begs the question. Which is better?


As a general rule, I think avoiding negation in the condition is best. Otherwise, I usually just put the more code-heavy/happy path part in the first branch and the less code-heavy (= less stuff to follow) part in the second branch, since it makes it easier to ignore.


At least that’s how my brain works


Yeah, I do that too @raymcdermott, but only in cases where either branch is of somewhat equal importance.


Oftentimes an if will be more like (if condition? do-happy—path-stuff else-do-nothing-of-importance)


and the best if is a when + functions that accept nil as input 😛


another pattern i quite like is (or (when () (when () (when () ...))) i-give-up-use-this) to avoid having to return 'i give up' in several if else positions


sometimes cond yes, unless you need to wrap some let stuff, if you don't want to use some cond-let , better-cond custom macros, or + when is really convenient in that situation

☝️ 1

yes, some of those when could be when-some