Fork me on GitHub

Does anyone know good resources and/or open source projects that are implementing payment workflows (e.g dealing with retries, cancelations, etc..)?


@wcalderipe Do you have some specific use-case in mind? ‘Payment workflows’ is quite wide topic, but I guess you’re talking about integrating customer payments into some kind of web-site/service? Or are you building a payment service yourself?


Technical details vary quite a lot depending on what payment method is used (credit card, invoice, PayPal etc…). However usually you use a payment service provider (PSP) who provides a higher-level API to smooth out the differences to some extent.


Stripe has really nice and developer centric docs that describe different workflows and scenarios. You can probably find inspiration there.


Has anyone tried as their job keyboard? What has been your experience with it? I am looking for new keyboard and focusing on ergonomic one do you have any recommendations ?


Can really say anything about the products, but looks very similar.


I have an ergodox first generation. I have short fingers, and thus for me it was even worse than a normal keyboard as I couldn't properly easily reach the farthest keys of the thumb cluster. But it might have been fixed in ergodox-ez, which IIRC is an updated version.


Ergodox ez here. Had to swap a key last week after 3 years of use, but that's about it. (Newer models come with a swapping mechanism, so you wouldn't even need to solder things) Can confirm that some keys, specially on the thumb cluster, are definitely a bit too far (and my hands aren't particularly small) Regardless, there's no going back. No more pain + programmable. The sole contender would be keyboardio, but it has a larger footprint.

Mario C.18:01:39

Co-worker has one and he seems to enjoy it. I thought it was a little awkward when I tried it but I am guessing you get used to it


i have small hands and i am afraid it might be too big for me now


I saw that there are a lot of keycap types to choose from. Are any of them 'small' or intended for us with smaller hands


Can anyone suggest a simple syntax/language I can embed in strings for doing simple if/switch statements?


I guess I want some kind of string templating


Think I want something simpler, the filters might play havoc.


Actually, should be fine as long as I HTML escape it afterwards.


Possibly overkill, but do look at MessageFormat


That looks quite nice actually, TIL


Thanks, that is the closest thing I've seen that accomplishes what I need and no more, TIL too.


btw format can also do positional params:

user=> (format "%2$s %1$s" 1 2)
"2 1"


It’s actually an ICU format


It should come to browsers at some point — there’s a few JS libraries that try to support it, but since it’s so huge you might not get all features.


Of course Google Closure also has a limited version.


Also very helpful, since I need to parse this out of strings in cljs


not sure if there's a #bikeshed channel or not... but through the years, i've never found a consistent naming style for namespaced keywords. so, like all good clojurians i like namespaced keywords. however, how do you organize them? when do you use namespaced keywords, and when not ? take this hypothetical map, identified by the spec acme/user:

{:acme.user/id #uuid "...."
 :acme.user/role :default}
here, :default is non-namespaced. however, i've also used this:
{:acme.user/id #uuid "...."
 :acme.user/role :acme.user.role/default}
both have their advantages and disadvantages. at this point, i'm mostly concerned with consistency in code i work with, so im looking for some kind of rule of thumb that dictates whether or not to put something in its own namespace... when to use which?


> both have their advantages and disadvantages You're definitely right here. At some point, I was fed up with dealing with namespaced keywords. So now I just work with the plain ones, unless there's a really good reason to use the namespaced ones.

👍 8

Honestly, I kind of hate namespaced keywords :p


A love/hate relationship I'd say


My rule is generally that I only use them for keys


And only when they are for shared concepts


So normally in combination with spec


So in your example, when using keyword as values I wouldn't namespace them, so it would be :default


I also don't generally include the app name


Unless the data was to be shared with other apps, but even then, most often you wouldn't comingle it without some other partitioning.


So I'd just do: #:user{:id #uuid ... :role :default}


I even dropped the #:user bit from most of the places. Suppose you have #:cat {:children [...]} and #:dog {:children [...]}. Well, now you cannot have code that operates on :children because there are no :children, there are only :cat/children and :dog/children. And passing the ns or the particular kw get ugly real fast.


And I stopped using :: and all that, as it just creates monster namespaces on the keys which I don't find particularly useful. Also, you cant refactor as easily since it complects the key and the namespace it is in


Ya that's true. That's what I meant by shared concept though


If children is shared, I'll spec it and give it a namespace like: :acme/children


Or :animal/children


Eh... maybe I should just drop them all together as well 😆


:: is nice with spec and re-frame, especially given that you can use namespace aliases with it. And for keywords that server as an implementation detail, like ::not-found or something like that.


Now that I think of it, I'd actually do {:type :dog :children []} for your example, and create a multi-spec over type

👍 4

Whats the point? That you can tell the namespace in case of an error?


You mean with ::?


Like you said its nice with spec and reframe


Why is it nice?


With spec I stopped using it, because it coupled my spec with its location in code. Like you can't just move the spec to a different namespace later


Or rename the namespace


atm I'm using a namespaced keyword as a tombstone value in an immutable db to signal a deletion. It means you can't store the value ::tombstone in the database, though :rolling_on_the_floor_laughing:


With spec - because you no longer need to think of some particular ns that somehow corresponds to the current ns, you just use the current ns. Since you can avoid using ns here altogether for a good reason, :: makes sense here. With re-frame - because it makes it much more obvious what ns you need to require to dispatch a particular event or subscribe to a particular subscription. :common-ev/get-updates can be easily dispatched without requiring the file where the corresponding reg-event-fx is called. But something like will make you think and provably do a (require '[ :as ad]) and dispatch ::ad/get-updates instead.


Moving a spec or renaming its namespaces doesn't differ from any other refactoring. It's just a bit more places where you have to make the change. NS aliases with :: make it a bit easier as well.


Ive just been burned by them. As long as they are only local and in memory it works great, but persist any data with them and you're stuck


The biggest issue is, you can't alias if there is no corresponding namespace


Its rare I'll rename or move a namespace. But its common I'll move fns out of it into another one


Yeah, but not having a corresponding ns is an issue separate from :: though. Also, I think there's a ticket to support such aliasing.


And so I find it weird, the namespace doesn't own the data, it all feels so OOP to me


@U064X3EF3 mentioned something in relation to human editing vs computer at some point as rationale for deps.edn


Right, I like the idea of ::, but tying to code modules I think was a mistake


@U09LZR36F I'm struggling to tie something as a rationale for deps.edn to the talk about namespaces, to be honest. :)


Sorry, I meant the rationale for deps.edn not using namespaced keywords. Brain is done for today I think :)


Although deps.edn still uses namespaced keywords... So I guess there were other reasons at play, so to speak.


Someone had asked something I thought was possibly the missing piece, chaining namespaces


Cause one annoyance now is: ":user.profile/id"


{:user/profile {:user.profile/id 123}}

🤢 4

This gets cumbersome real fast as you have more and more nested maps


Worse if you used ::


Family trees would be fun: {:mother {:mother/mother {:mother.mother/mother ...}.


If you have ::, you have


But you can't do: ::cool-app.user.profile/id


And have cool-app expand


So now all nesting you need to type the full alias ugh


Anyways, I'm starting to think like you, do we need all these namespaces? What for? I can just start using :req-un and :opt-un everywhere. Then I'd only use ::for spec names.


Which by the way, I find strange as well. Why not use symbols for referencing specs? The only reason I can think is because of how the keys are meant to map to their spec

Alex Miller (Clojure team)18:01:38

symbols are used for referencing function specs

Alex Miller (Clojure team)18:01:21

symbols are annoying to use unresolved because quoting


True, but I've seen many people add back resolution to keywords just to make sure they don't have typos or forgot some spec, etc.


In general, I havn't found myself needing to spec things that depends on spec to be defined later


So I'd actually enjoy symbols throwing error if I do


Unless I'm missing something


And I feel in the case you do need too, declare could have been used similarly, like an s/declare



user=> (def Int int?)
user=> (def Foo (s/or :int User :string string?))
user=> (s/conform Foo 12)
[:int 12]


Okay, maybe I get it. If specs had used the same registry as var, it would be fine, but given it has its own registry, then all symbols must be quoted


Or they'll be looked up in the namespace symbol->var registry, and you won't find it there


But for FN specs, since there is a symbol of same name in the ns already for the actual function, this problem doesn't exist

Eric Ihli18:01:29

Given a domain and range, how would one go about creating a continuous function?

<=5  -> ~3
6    -> ~3
7    -> ~2
8    -> ~1
9    -> ~1
>=10 -> ~0


(assuming a linear mapping)

dvingo18:01:09 these are useful for such problems

Eric Ihli05:01:23

This is dope. Thanks.

Alex Miller (Clojure team)19:01:29

And Datomic.. :)

😄 4
datomic 4