Fork me on GitHub
#off-topic
<
2020-01-23
>
wcalderipe04:01:48

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

valtteri06:01:05

@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?

valtteri06:01:30

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.

valtteri06:01:34

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

lepistane09:01:29

Has anyone tried https://ergodox-ez.com/ 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 ?

p-himik09:01:20

Can really say anything about the products, but https://ultimatehackingkeyboard.com/ looks very similar.

solf09:01:18

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.

aisamu12:01:24

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

lepistane19:01:21

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

lepistane00:01:57

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

danielstockton09:01:56

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

danielstockton09:01:12

I guess I want some kind of string templating

danielstockton09:01:49

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

danielstockton09:01:36

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

orestis10:01:14

Possibly overkill, but do look at MessageFormat

borkdude10:01:20

That looks quite nice actually, TIL

danielstockton10:01:15

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

borkdude10:01:56

btw format can also do positional params:

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

orestis10:01:06

It’s actually an ICU format

orestis10:01:40

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.

orestis10:01:49

Of course Google Closure also has a limited version.

danielstockton11:01:18

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

lmergen17:01:43

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?

p-himik17:01:05

> 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
didibus17:01:34

Honestly, I kind of hate namespaced keywords :p

didibus17:01:51

A love/hate relationship I'd say

didibus17:01:37

My rule is generally that I only use them for keys

didibus17:01:08

And only when they are for shared concepts

didibus17:01:23

So normally in combination with spec

didibus17:01:22

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

didibus17:01:19

I also don't generally include the app name

didibus17:01:08

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

didibus17:01:14

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

p-himik17:01:04

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.

didibus17:01:46

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

didibus17:01:33

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

didibus17:01:20

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

didibus17:01:36

Or :animal/children

didibus17:01:21

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

p-himik17:01:03

:: 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.

didibus17:01:38

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

👍 4
didibus17:01:10

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

p-himik17:01:00

You mean with ::?

didibus17:01:37

Like you said its nice with spec and reframe

didibus17:01:52

Why is it nice?

didibus17:01:58

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

didibus17:01:10

Or rename the namespace

mloughlin17:01:39

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:

p-himik17:01:58

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 :acme.data/get-updates will make you think and provably do a (require '[acme.data :as ad]) and dispatch ::ad/get-updates instead.

p-himik17:01:12

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.

didibus17:01:37

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

didibus17:01:33

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

didibus17:01:00

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

p-himik17:01:50

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

didibus17:01:02

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

dominicm17:01:42

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

didibus17:01:44

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

p-himik17:01:06

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

dominicm17:01:57

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

p-himik17:01:53

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

didibus17:01:01

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

didibus18:01:16

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

didibus18:01:05

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

🤢 4
didibus18:01:46

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

didibus18:01:51

Worse if you used ::

p-himik18:01:51

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

didibus18:01:06

If you have ::, you have com.acme.cool-app/user

didibus18:01:31

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

didibus18:01:40

And have cool-app expand

didibus18:01:54

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

didibus18:01:29

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.

didibus18:01:28

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

didibus19:01:11

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.

didibus19:01:31

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

didibus19:01:46

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

didibus19:01:17

Unless I'm missing something

didibus20:01:06

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

didibus20:01:58

Hum...

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

didibus20:01:17

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

didibus20:01:45

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

didibus20:01:21

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

hiredman18:01:35

(assuming a linear mapping)

dvingo18:01:09

https://www.d3indepth.com/scales/ 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