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.

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

taking hammock-time to new heights

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.

Can you elaborate?

Well I want to use channels to communicate

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

there's a question about lifecycle and idempotency

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

but then how would you restart it?

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

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

exactly!

Do channels take metadata?

no

if they did that would be the solution

Yeah

I could add all sorts of stuff round the sides

and easily provide instance-specific protocol implementations

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

I think I need to wrap them in a defrecord

implicit how?

If you autoclose them or something

oic

Aaaand you can extend Lifecycle to channels

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

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

So they don't really need a stop

makes sense for stop, ensure the channel is closed

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

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

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

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

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

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

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

Sure does, although start just returns a new record anyway

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

Asking too much?

maybe

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

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

"all things must pass"

And on start will create a new one?

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

You could

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

Principle of conservation of meh

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

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

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

Here https://github.com/bsless/companion/blob/master/src/bsless/companion.clj

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

You can deref it to get the state

interesting, thanks!

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

Life is good!

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