Fork me on GitHub
#off-topic
<
2018-08-09
>
Josephine16:08:22

Literally off topic, but did anyone else try this indorse web-platform?

Josephine16:08:02

To be a little more specific, http://www.indorse.io

soulflyer03:08:41

looks like an interesting idea but so far it only seems to recognise skills in python or javascript. I'd rather keep quiet about my javascript skills 🙂

soulflyer03:08:39

my bad, they appear to have added java, c#, and solidity (whatever that is) now.

Josephine10:08:03

Thx @U0E3H1J5Q 😊 Did you try it out? I've never used this kind of programming skills validation before. Just got curious.

Josephine10:08:30

Btw, solidity, I think it's used for smart contracts and blockchain infrastructure coding.

👍 4
soulflyer11:08:47

I got as far as the drop down list of skills I don't have or don't want to brag about and gave up. It looks pretty new so it will probably be worth taking a look again in the future.

Josephine13:08:29

Hmmm.. I'll try it out this week end & give you some feedback if it's worth anything. Bye bye @U0E3H1J5Q 🙂

👍 4
jjttjj18:08:52

I have a vague idea around how to implement a data model for something and am wondering if this is some sort of pattern that someone’s encountered before (particularly in an open source project), or if there’s some reasons I’m missing that this might be a bad idea. Basically my app is built around a particular REST api. I want to be able to think of that data conceptually like a nested datastructure (ie nested maps). I’m thinking I can create a type that implements ILookup. When a key is looked up a cache is checked for the data and if nothing’s there the REST call is made and the cache is populated. Cache rules would vary by endpoint.

lilactown18:08:28

this is essentially an idea that we’ve implemented at work. we’ve defined a IDataSource protocol which is a combination of an IDataRemote and IDataStore.

john18:08:30

@jjttjj in CLJ, not CLJS?

lilactown18:08:13

an IDataRemote implements the specifics of how to get the data you want. an IDataStore implements the cache. we didn’t use ILookUp because 1. we’re using this on the front-end (CLJS) so we can’t have blocking lookups 2. principle-of-least-surprise

jjttjj18:08:51

@john pretty flexible. I'm prototyping in CLJS but have eventually plans to move a lot of this to CLJ

jjttjj18:08:04

@lilactown cool thanks for the input

john18:08:30

wouldn't ILookup imply a synchronous result?

jjttjj18:08:43

oh yeah, good point

john18:08:53

doable in a worker

jjttjj18:08:48

hmmm yeah probably leaning towards not using ILookup now

john18:08:57

sync-xhrs are still available in workers

lilactown18:08:31

this is very specific to our use-case, but we decided to settle on the reagent ratom interface being the interface we used to get the actual value

lilactown18:08:38

so you’d basically do (data/pull! :source-name [:some :query :here]), which would return a ratom that represented the status of the particular query of the data.

lilactown18:08:00

if it was already loaded it would immediately be {:loaded true :data { ... }}

lilactown18:08:26

we basically made apollo for arbitrary REST APIs 😛 (poorly)

soulflyer03:08:41

looks like an interesting idea but so far it only seems to recognise skills in python or javascript. I'd rather keep quiet about my javascript skills 🙂