HN user
Diversity makes teams stronger but makes clear communication harder. 20% of the population aren't neurotypical... they're simply not wired the same way. Throw in cultural differences.
I was so excited when I found The Judge: Am I misreading the tone of this?
What a wonderful tool to have at hand when things go awry in email threads, chat rooms etc.
Interesting bit to me is the communication problems, not so much the technical ones, we live with tradeoffs.
The thing is communicating takes time and busy people are entitled to prioritise "doing" over "talking".
As a community, Clojure is defined by the promises made and the processes established. I think "Brand Clojure" is defined by some truly wonderful attributes but it could be improved.
Perhaps this could this be fixed with process? For example
* Document architectural decisions [1] [2]
* Close tickets WONTFIX with a link to the relevant architectural decisions
Make that a process/promise so that it becomes a consistently applied approach and it would give the community confidence they are being treated well, heard and respected. "Brand Clojure" becomes more lovable.
But these processes also take time and we don't want to burden Clojure core devs. (More realistically, I doubt they'd allow us to impose on their precious time.)
So, can this happen without adding overhead for the core developers? I don't know. It's an interesting question though. Can we learn from others online communities on this topic? Are those who do this well based on dev leads who are naturally inclined to communicate? Are any using community funded positions to deliver on communication" outcomes?
Sounds like a community advocate/support role:
* Triaging tickets ensures inbound communication is effective and helpful. That helps by saving core dev effort. That helps avoid confusion on both sides.
* Generate architectural decision docs which can be linked from tickets
* Ensure WONTFIX doesn't feel like a dead end. Link to ADs, blog topical workarounds.
* Keep architectural decision docs fresh as consequences become more apparent over time.
Few ideas in there. Just a thought exercise.
--
[1] See Documenting Architecture Decisions http://thinkrelevance.com/blog/2011/11/15/documenting-archit...
[2] Is the 'garbage in/garbage out' architectural decision documented?
Seems like they've been so busy making us things to talk about them. I'm okay with that! I do look forward to seeing the survey.
Love that workflow demo!
Perhaps note that scripts should be loaded after form elements. You get an odd error if (init) runs before the form elements exist.
This might only be vaguely related. It's an example of managing bank account balances using datomic taking advantage of transaction functions.
Thanks Rich. Updated.
Just thought I'd risk proposing some possible architectures to confirm I see how the licenses (and datomic) applies.
Standard web application using free edition. Three servers. Architecture is DB storing data locally, a web server and another server (say for slow report queries, an API or web worker). Could use beefy servers to scale up.
Business application using pro license allows better redundancy and scalability. Can use different data storage options. Can break beyond limits of 2 servers for processing and request handling.
The pro's peer license cost per process (which I think means cost per grunty server cost) is at worst $800 up front plus $400 per year.
Note: This is unlikely to be quite right.
Updated: thanks to RichHickey.
I've really enjoyed using light table.
I spent a few solid days using it while implementing a spreadsheet into a webapp (I wrote the algorithm in clojure and then migrated to clojurescript).
Immediate feedback and live tests felt natural.
Given my clojure is rusty it was helpful to be able to see how functions work with little test cases.
The lein plugin is a nice addition. I'm looking forward to seeing it trigger a refresh when project source files change.
Some kind of compare-and-set! operator which occurs at the transactor perhaps.
Update:
1. you can do synchronous transactions.
http://datomic.com/docs/javadoc/datomic/Connection.html#tran...
2. transactions can include data functions.
"The database can be extended with data functions that expand into other data functions, or eventually bottom out as assertions and retractions. A set of assertions/ retractions/functions, represented as data structures, is sent to the transactor as a transaction, and either succeeds or fails all together, as one would expect."