This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (24)
- # announcements (1)
- # beginners (122)
- # braveandtrue (9)
- # calva (45)
- # cider (24)
- # cljdoc (8)
- # cljs-dev (23)
- # clojure (112)
- # clojure-europe (2)
- # clojure-india (2)
- # clojure-italy (36)
- # clojure-nl (3)
- # clojure-spec (32)
- # clojure-uk (35)
- # clojurescript (52)
- # core-typed (12)
- # cursive (4)
- # datomic (61)
- # emacs (4)
- # figwheel-main (2)
- # fulcro (14)
- # hoplon (5)
- # hyperfiddle (1)
- # jobs-discuss (6)
- # kaocha (5)
- # leiningen (2)
- # nrepl (15)
- # off-topic (62)
- # re-frame (26)
- # reagent (39)
- # ring (3)
- # shadow-cljs (56)
- # spacemacs (8)
- # specter (5)
- # tools-deps (1)
- # yada (2)
Looking to level up my hammock driven development abilities. Any recommend reading for design? (Im familiar with Domain Driven Design already)
out of curiosity, what are your thoughts on DDD? dunno if I should bother learning it... normally the people into it are knee-deep into OOP
IMO DDD is a great resource to draw inspiration from, works equally well for functional programming
as with all methodologies the key is to use your brain while applying it and not taking everything literally/to the extreme 😛
the give an answer to robert’s question: if you have some programmer you look up to, I recommend reading their code and see how they do things, and make your own notes about their design choices
Not a programming book, but it can applied to programming (specially UI design) very easily: The Design of Everyday things
There's positive talk recently about "causal modeling" for use in the scientific method. Perhaps we'll have Causal Driven Design one day https://en.wikipedia.org/wiki/Causal_model
There are so many different kinds of design, and scales, and scopes. e.g. are you more interested in the design of a single codebase, or of multi-tier apps, or of entire distributed system landscapes?
@U45T93RA6 I’ve been enjoying this book https://pragprog.com/book/swdddf/domain-modeling-made-functional on the subject
@U69US348Z I suppose I meant: how do you turn requirements into a solution that doesn't explode? That's a really general question, but I kinda just wanted to get into someone else's head when they start problem solving. What things are they looking for? What questions are they asking themselves? etc.
how can one send requests to peer-to-peer system to handle its’ request when we don’t know the ip-addresses of any of the nodes. Do we need kinda router/server for that knows all IP addresses of all peers in the system. I would assume that we would like to communicate with the nearest peer first. How can one achieve that?
I’m reading about DHT right now, but how can I ask the peer if I don’t know where it is
I mean, assume I have cluster of nodes (peers) having finger-tables (if we talk about Chord), but I need to send the request to at least one node in order to trigger the search
For the initial entry to the network, "seed servers" usually push out a seed list of peers, to get you started on the network.
That's probably one of the more dangerous points in the untrusted p2p situation. Malicious seed servers could be very dangerous. Sorta of a centralized/achilles heel of distributed systems.
Another option is f2f, where your friends are your seed servers, and you enter the network locally via some friend.
thank you! much appreciated. Doing distributed systems course right now at the uni and was kinda confused on this topic
hmm... strange. Both gnutella and freenet use DHTs, iirc. I wouldn't be suprised if most of the others there did too.
what are your thoughts on DHTs with/without the router component? I was just thinking about the router component/server (with replicas, e.g. 3) having the whole routing table for all live nodes (update the table while sending heartbeats every x seconds). This way the search would be O(1) with the cost of only 3 (or more, depending on replica policy) nodes, instead of being O(logN)
Absolutely... If you're not building some global thing, but a distributed thing of a controlled size, of under, say, 10,000 nodes, why not just keep the whole netdb on every router? People way over-engineer "distributed systems" with ideas around global fault tolerance, when they're only dealing with a few dozen servers. Crazy.
No prob. Good luck! I hacked on some p2p stuff back in the day, so let me know if you have any questions and do tell if you make anything cool!
Want to build a DHT (described in Chord paper) for fun and practice in Clojure. For this I would assume I need a RPC lib. Any lib you know is good? Slacker?
For any bits that you'd expect to use RPC for, I'd recommend trying to replace those with a data-first approach.
Yeah, a lot of older write-ups on chord-like architectures might have RPC idioms going on. But if you think about it, all RPC is all data over the wire anyway, so whatever RPC is doing for you, you can do with just data. And in clojure, ideally, you're working with data anyway.
RPC is kinda fancy and trendy nowadays 🙂 one could do both and then compare performance/readability(maintainability)
So it's best to avoid RPC unless you have to work with some legacy idioms for whatever reason... Or if you explicitly want to provide the illusion of locality
definitely need to read more on RPC and check the pro/contra argument. Go with gRPC seem to be kinda trendy atm (doesn’t imply it’s good though)
Also bear in mind, if any of your RPC method calls are synchronous then you may have some difficulty porting to a JS based host, like cljs, since blocking in JS isn't quite a thing.
Might be a fair trade off. Depends on who your users are and the problem the system solves. No, I mean users of a clojure chord or dht lib
Yup, #code-reviews and #architecture but you should probably cross post here or another related, more popular channel, to get people's attention and come over and check it out. Otherwise folks might not see it.
BTW regarding the API, I guess one would like to have same API as a standard hash-map in clojure (with assoc, get) meaning it would be synchronous this way, dunno
Sure, for the high-level api, and yeah that'd imply synchronous. Certain clojure programmers will frown on that rpc-like/map-like thing you've created 😉 But I fancy familiar interfaces when their differences are made obvious. For a low-level API, you may want to stick to the asynchronous reality, and go as event driven / reactive as possible.