I've been working remotely for a few years now, for various companies and clients.
One itch I needed to sratch is timezone conversion. It's always a mental effort to figure out when someone in your team will be around, and to compute when you should schedule that meeting so that everyone invited gets a "respectable" time.
Here I present you whena.re, the most intuitive timezone viewer for your team ;)
It's been live for something like a year now, lots of people use it and feedback has been great so far,
I released a Slack integration so I'm hoping this will convince some of you to give it a shot if you've never tried it before!
Happy to discuss some more if you have questions or comments,
tl;dr:
governance is hard, there's no silver bullet, every system may be tricked.
"good blockchain governance" would rely on gathering the result of multiple "coordination flags" like a user vote, a coin vote, core dev decisions, etc.
Very complete "here are the limitation, in the end, just don't be dumb" article.
About the bribing part:
Could we get rid of it if voting is anonymous (I can't reward you with a bribe),
and we give right to coins that haven't moved for a certain amount of time (I can't ask for your money and your account has to be "old enough")
?
Since I couldn't find any explanation on the article:
> Snaps are containerised software packages that are simple to create and install. They auto-update and are safe to run. And because they bundle their dependencies, they work on all major Linux systems without modification.
Appears to be a packaging systems for (desktop) apps on linux with auto-updates and stuffs.
It's packaging and delivery for Linux desktop, server, and IoT apps. As elsen mentioned, updates happen automatically and roll back if unsuccessful. Automated review covers most cases and the format is simple yaml, so you can quickly push something up that you can install from anywhere.
Interesting "we must learn/accept/fight to cohabit" view,
It's super American - Westerners centric though, what happens if decentralised currencies take off in emerging countries?
I want a similar platform with reproducibility built in:
your paper gets in the blockchain, if and only if, its results can be reproduced by other members ("Proof Of Reproducibility").
I've been learning & trying to use clojure(script) for ~2 years now.
A few things I miss in every other languages:
- The REPL: I usually don't need a debugger,
- Figwheel: that makes frontend dev a pleasure,
- reagent/reframe: are incredibly straightforward, there's no special syntax, no special constructs, just a few functions, a few concepts (dispatch / subscribed) and you're done,
- core.async: based on a simple channels / pipeline paradigm
But then you get into the practicalities of testing & writing code. Shady special cases[1][2], annoying testing tools[3], useless stack traces. And other issues everybody knows. Simple things that become a 30 min discussion with 3 different libraries and 2 blog articles to go through[4].
To me, there's this hardcore group of clojur'ist that seems to be hyper productive and keep introducing new concepts. And the "rest" (me at least), that are floundering.
You fight with useless stacktraces? Boom, transducers. You deal with buggy test runners? Bam, a new specification library with test generations.
I've started moving my code to ES6 and Go. The community is filled with helpful people, but it seems to me that if you're not writing Clojure professionally already, the language is becoming less and less relevant.
The examples you raised are all - I believe not by coincidence - related to how Clojure interact with the host platform (both Java and Javascript). It simply doesn't shield you from it. As a consequence tracebacks bubble up, and you're expected to know how to debug it, and hopefully use the debugger of the host platform. This is aggravated on JS since JS exceptions mean nothing most of the time.
clojure.spec (launching on 1.9) will allow better error reporting on some cases, but the philosophy of the language has always being about giving you a lot of power vs. shielding you from complexity.
Also, a lot of people being introduced to Clojure from a Ruby background (and others, ofc) are having to learn simultaneously about: functional programming, Lisp, immutable data structures, the internals of JS/JVM, advanced concepts like STM, CSP, and a whole host of new libraries. That is a steep learning hill, specially if one bought the argument that programmers are snowflakes who can't take frustration. Once you're on the other side though, the complex, messy real-world projects become more amenable, because Clojure was created thinking about those. That's what Rich meant by "Simple ain't easy".
IMHO, working at a company w/ a codebase of ~150 projects written in Clojure, the productivity has paid off w/ interest though.
> specially if one bought the argument that programmers are snowflakes who can't take frustration.
I think that characterising a (clearly knowledgeable, well-referenced) account of frustrations - especially ones that do not occur in other languages - with the dismissive term "snowflake" is exactly where the stereotype of the "smug Lisp weenie" comes from.
I have used and loved Clojure for years now (I wrote the patch that made Clojure vectors implement java.util.List, back in the pre-1.0 days). The fact that these problems exist doesn't itself give me existential worries about the future of the language. The fact that almost every Twitter thread in the OP, and the parent comment, contained this sort of dismissive reaction makes me very worried indeed.
If we replicate the community of Common Lisp, we will end up replicating its level of industry adoption.
Peter Norvig, Paul Graham, Dan Weinreb, Edi Weitz, Jans Aasman, Patrick Winston, Kent Pitman, the people from Clozure/Franz/LispWorks/..., and many many others.
And yet, even these luminaries were insufficient to propel significant industrial adoption in the face of a famously hostile/arrogant/condescending community. The same fate befalling Clojure would be terrible.
Exactly my cliché of the Clojure community: a discussion about simple things like testing and tooling becomes a place to brag about some random features of Clojure. Insulting my patience (or the original author) on the way is a new one.
You're just confirming my last point, professional Clojurist? Enjoy it. Others, be warned.
The problems you listed are about ClojureScript. I agree the ergonomics are still behind JVM Clojure, but then again the competition is significantly worse too in the JS space.
And if you end up concluding some other front-end language is better, Clojure is still a really good choice for the back end.
You may not know: on Unity you can saturate / desaturate the windows. I set them almost black and white and increase the saturation when I need it (shift + brigthness up / down).
I have no idea if it provide health benefits similar to the "orangy filters" but it's pretty nice on the eyes and, personally, it makes me happy to see the outside world with brighter colors than my screen.
I've been working remotely for a few years now, for various companies and clients.
One itch I needed to sratch is timezone conversion. It's always a mental effort to figure out when someone in your team will be around, and to compute when you should schedule that meeting so that everyone invited gets a "respectable" time.
Here I present you whena.re, the most intuitive timezone viewer for your team ;)
It's been live for something like a year now, lots of people use it and feedback has been great so far,
I released a Slack integration so I'm hoping this will convince some of you to give it a shot if you've never tried it before!
Happy to discuss some more if you have questions or comments,