This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (153)
- # announcements (29)
- # architecture (6)
- # babashka (5)
- # beginners (197)
- # calva (71)
- # clj-kondo (27)
- # cljfx (4)
- # cljs-dev (33)
- # cljsrn (1)
- # clojure (52)
- # clojure-australia (5)
- # clojure-boston (1)
- # clojure-europe (38)
- # clojure-france (1)
- # clojure-hungary (5)
- # clojure-italy (1)
- # clojure-nl (19)
- # clojure-uk (5)
- # clojurescript (12)
- # conjure (4)
- # core-async (3)
- # cursive (22)
- # datalog (70)
- # datomic (32)
- # deps-new (8)
- # emacs (79)
- # events (2)
- # fulcro (15)
- # graalvm (15)
- # leiningen (2)
- # lsp (5)
- # minecraft (1)
- # nbb (1)
- # off-topic (37)
- # polylith (11)
- # re-frame (9)
- # reagent (1)
- # reitit (3)
- # releases (1)
- # reveal (2)
- # shadow-cljs (42)
- # spacemacs (1)
- # tools-build (4)
- # tools-deps (55)
- # vim (11)
- # xtdb (6)
I thought this was interesting and am very curious about what other Clojurians would think about it: http://pages.cs.wisc.edu/~anhai/courses/764-sp07-anhai/datamodel.pdf It is a survey of various types of databases that have come and gone from the 1970s to the early 2000s, and interpretations on why things developed the way they did. There is a short passage on the semantic web which I am especially curious about. I have been trying to find good documentation on RDF databases and have found relatively little so far. I keep coming across the semantic web and graph databases and I am thinking of reading some more on the latter. I would very much appreciate recommendations regarding RDF and graph databases. I am especially curious about something Rich mentioned, which is that RDF databases are often introduced when a company purchases another, to act as a “federation point”, my understanding being that a federation point is a database that somehow reconciliates disparate sources of data.
Triple stores have very little inherent structure, so they can be a way to expose different databases with different tables/documents/whatever in a single data model
if anything, it is an even simpler version of what they call the "simple" data model in that paper
I've worked on the architecture of two database federation products - one for federated SQL relational dbs (surviving today as JBoss Teiid), and one for federated SPARQL for semantic web dbs (written in Clojure), and indeed their major use case was combining things not originally intended to be used together, when the migration costs were too high for any one of them
the part of RDF / sem web that Rich most appreciates I think is the primacy of attributes over aggregates (entities / tables / etc)
graph databases are most useful when you are representing social graphs or other such data so you can graph-like questions about the data (what nth degree connections do two users share?) - those queries suck in relational as they require an arbitrary set of subqueries but are very natural in a graph db
Datomic is imo a magical sweet spot in between all of these. It's "simple" in just being EAV like a triple store (but avoids a lot of the most cumbersome parts of RDF like uuids), pretty easy to use for the common "table" like use case (but can be sparse or more flexible if needed), can do just enough of the graph-like stuff with recursive queries to cover many app needs. and of course, it's attribute-first (also seen in spec)
Tangentially related, have you seen someone migrate from a graph database to Datomic? Did it go well? Also wondering if from an architectural point of view it is possible and a good idea to make access to the database freely available to all teams and not lock it behind one team's management? Or is it a moot point given how multiple data sources could be queried
I didn't migrate, but after evaluating some options I chose to build my projects graph in datomic and it's going well so far
don't think I've seen that so don't know. can't say I've ever seen unfettered and ad hoc db access go well for anybody :)
I'm wondering if I could set up a system of layered or modular access to data without locking it behind APIs. Let's say, team A is in charge of the core data model, writes to db A, team B wants to add its own things in terms of the data model in A. Writes to DB B, reads from both. Is this even a good idea?
I'm trying to poke holes in my idea to make sure I don't fall in love with it only because it's my idea. How do I answer the refrain by team A of "we don't want you to have to deal with the internals of our data model, they shouldn't bother you"?
If you've got any stellar technical arguments on why they're wrong I'd be happy to borrow them
Anyone has experience with arm-like keyboard trays? Like the ones 3M makes, I've never owned one. I'd want it for either my keyboard or maybe the whole MBP (which I use w/ a monitor). Typing above the lap but below the desk would seem the sweet spot for me (traditionally either I've placed the keyboard on my lap, or on top of a desk adjusted at low height + monitor at high height) I guess I'm seeking for two things at the same time: 1) has to be adjustable in all sorts of angles e.g. positive/negative tilt + height + depth and 2) has to be super sturdy/stable, for keeping said adjustments in place.
My wife has one and I hate working on her side of the desk so it's definitely very subjective. When we set up the office at home, we both got articulated keyboard trays but I hated the setup so I've never used mine since that first setup twenty years ago. I prefer to just adjust my chair's height to get a comfortable position for my arms on the keyboard (on my desk) so I think it's really going to depend on your height, your desk's height, the length of your legs, and several other things. I don't know if that's helpful @vemv?
Sort of, I can definitely see my experiment failing. As you hint it's subjective, often I use stuff in odd ways :) One piece of info I'm seeking specifically is a model that won't be an outright piece of junk, bad material -> experiment doomed from the beginning
Ours was all Ikea. We love the huge, curved desk and side tables. Rock solid. My wife loves her articulated tray. I hated it. So we maybe wasted $100-150 on mine.
A height adjustable desk plus monitor on an arm was perfect for me. You can bring keyboard/mouse at a comfortable height and then adjust the monitor too.
I went back and forth on chairs, adjustable desks, keyboard trays, and foot rests over the years. These days I just put my keyboard on my lap and it’s always the perfect height 😆
I really like having a keyboard in my lap, but I'm always keenly aware of how awful my posture is when I have to look down at the screen
Do you mean you have your keyboard on your lap or your laptop on your lap? I use an external keyboard and monitor so those things are decoupled
I mean that I like to have a keyboard in my lap, and that for this reason I appreciate having a laptop in my lap (since it is its own keyboard)
I haven't gotten around to getting myself a nice set of peripherals yet, still clearing out space for a proper workstation.
Holy cow! Thanks @robert-stuttaford or whoever convinced the Slack CEO!
As noted in the announcement thread, it's for one year. We have to reapply each year.