This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-17
Channels
- # beginners (70)
- # boot (4)
- # cider (16)
- # clara (6)
- # cljdoc (21)
- # cljs-dev (2)
- # cljsrn (1)
- # clojure (73)
- # clojure-finland (2)
- # clojure-nl (6)
- # clojure-russia (35)
- # clojure-sg (1)
- # clojure-spec (14)
- # clojure-uk (146)
- # clojurebridge (2)
- # clojurescript (128)
- # cryogen (2)
- # cursive (20)
- # datomic (27)
- # emacs (6)
- # events (8)
- # figwheel-main (57)
- # fulcro (46)
- # hoplon (3)
- # hyperfiddle (2)
- # immutant (3)
- # jobs (6)
- # jobs-discuss (15)
- # juxt (2)
- # off-topic (33)
- # parinfer (2)
- # portkey (4)
- # protorepl (1)
- # re-frame (4)
- # reagent (78)
- # ring-swagger (45)
- # schema (6)
- # shadow-cljs (167)
- # spacemacs (2)
- # specter (13)
- # tools-deps (6)
Hey you guys how would you explain why Datomic is more powerful than SQL in one slide to a business person? Pictures or words. Basically you get about one sentence and one picture and they have to "ah ha" or we failed
1. More leverage 2. Less anticipation / more agility 3. Enforces / educates to IT best practices
And 4. Integration heaven
Not sure if they can «ah ha», I mean if they are not technical all dbs will look the same to them I think
I would do it in two pictures: first picture is a two timelines showing the steps and latencies of an cycle with datomic vs SQL (a cycle would be developing the schema, migrating, creating queries, optimizing, etc)
the second picture would be the number of times that you go through a cycle in a typical development project.
then, it’s just multiplication to show time saved
I would usually address risk before productivity though (they will usually trust you about productivity)
What's the business? It entirely depends on what their concerns are. If it is a business where audit and history matters, one slide mapping that feature to those specific concerns is enough
Not all businesses care about that, but the ones that do really do
In any event, the best case is where concerns/painpoints map directly to features
I am trying to explain to venture capitalists why http://www.hyperfiddle.net/ is dependent on Datomic and why that is our greatest strength, not a weakness
Ah. May be better as a DM conversation, but I wonder: is that a question about Datomic, or is that a question about the applicability/leverage of the hyperfiddle concept?
The rest of the deck is about Hyperfiddle, its the specific Datomic dependency which has been a hang up thus far
Hmm, yeah not sure how to articulate this positively, but I mean, I’ve messed around with hyperfiddle. I’m having difficulty even visualizing how one might do it with say MySql
Why is an implementation detail like the database a VC concern?
Well sometimes they've folks who will dig in on your tech stack. Been through that more than once
It’s really difficult to boil down to a pitch-deck slide, I think, because there’s like a 1.5-2 minute talk you can give that makes it abundantly clear how Datomic lets you differentiate yourself from the same team in an alternate universe stuck using SQL, but when you zoom out far enough to fit all those points into a single slide/~20 seconds talking over a slide, it tends to dither out to “we use it because it is awesome next question” (which I’m sure you’re familiar with)
Here is the text of the “useful properties of Datomic” slide from a meetup talk I gave about Datomic Cloud a few weeks ago:
- Data modeling is (almost all) deferred to query time
- Accumulate-only, immutable stream of facts means that you can create arbitrary "views" over your data just by writing (or refining) a query
- Reads can scale arbitrarily - peers read directly from storage and don't need to coordinate with anything to pull reads
- Writes create a consistent state that can be replayed, queried, etc. ("what was every value of the db at the time this bug occurred")
I’m sure you’re aware of it, but this blog post also gave me a lot of raw material for the ~20 seconds of talking about that slide: https://augustl.com/blog/2018/datomic_look_at_all_the_things_i_am_not_doing/
Hi, given that in cloud we’ve lost the bytes type and strings are now limited to 4K are there any recommended strategies for dealing with requirements for more ‘midsize’ strings, etc. Just say longer text vs something that should more appropriately be a ‘file’ in S3 or something
I'm planning on using a foreign KV store from a transaction function (the foreign write will be optimistic, not atomic – e.g. upload your image again if it failed without rolling back the rest)
Ok, yeah, I’d started thinking about stuff like that. We’re doing S3 for images, etc. Wanted something ‘easy’ lol, for this scenario. I’d really like bytes back 🙂
This is one possibility: https://vvvvalvalval.github.io/posts/2018-05-01-making-a-datomic-system-gdpr-compliant.html
(Not the GDPR stuff, but augmenting datomic with an external KV store for the actual data)