This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (33)
- # boot (38)
- # clara (21)
- # cljs-dev (1)
- # cljsjs (2)
- # cljsrn (12)
- # clojure (230)
- # clojure-argentina (1)
- # clojure-brasil (3)
- # clojure-dusseldorf (4)
- # clojure-france (9)
- # clojure-italy (1)
- # clojure-russia (123)
- # clojure-spec (46)
- # clojure-turkiye (1)
- # clojure-uk (60)
- # clojurescript (83)
- # core-async (6)
- # cursive (10)
- # datascript (19)
- # datomic (28)
- # defnpodcast (1)
- # emacs (7)
- # figwheel (7)
- # fulcro (29)
- # leiningen (29)
- # lumo (9)
- # off-topic (14)
- # om (1)
- # onyx (25)
- # pedestal (1)
- # protorepl (3)
- # re-frame (10)
- # reagent (41)
- # ring-swagger (11)
- # shadow-cljs (10)
- # testing (5)
- # unrepl (3)
- # vim (3)
@thomas I guess because it is a revolutionary idea in an environment that is trying (at least when I left) to install command and control after 3 productive dev anarchy years. There is a small number of good Clojure devs, so you really need to sponsor a great working env to attract them. Sometimes even good money is not able to buy that. With the abundance of JS or Node devs (for instance) you have much easier life.
I don't think it's a Clojure failure. DM fails to show how proud they are to use Clojure, making me think that they see it as a legacy of some revolution from the past.
No conference presence, sponsorship, development blog, Clojure related activity on github. If any DM people is at #clojurex please shout that you are alive 🙂
I’m pretty sure the community as a whole don’t want to be associated with DM. see https://stopfundinghate.org.uk/ There was even a bit of drama when functional works advertised roles for them. They ended up dropping them from their site.
Yep, that's the other problem. As a foreigner it took me some time to realise what I was contributing to. I was there when they were pushing for brexit, helping against my own interests! That was it (along with other things)
@jasonbell I am not jealous at all what so ever.... I just love the smell of
burning Hibernate in the morning.
I just wish Spring’s shameless Dropwizard clone wasn’t called “Boot” - it clashes with a certain other tool that I’m currently learning / googling for help on.
too many tools have the same/similar names. quite annoying when you try and search for something.
at big blue there seemed to be about 5 project names that got reused again and again... very confusing as well
perhaps all projects should be named by guids? (I’m assuming it’s obvious that I’m not serious.)
some products had good ways of naming projects. One I was working had stars, where we had names like Atlas and Betelgeuse
can't remember what C was...and D wasn't death star, too great disappointment of several people!
There was another site I used to use that used botanical names of flowers for their releases
I remember trying to find logs for a container system called ‘garden’. Surprisingly the search results for “garden logs” were not helpful.
coming up with machine names was also good fun... we had a massive list of dead rock stars at one stage 🎸
I used Discworld characters at home, but then got my domain as a Culture reference. So I now have confusing hostnames like http://downey.masaq.infinitefunspace.co.uk
Which other teams scoffed at, but now they end up asking each other "What does Gandalf do?" "I don't remember, is that the filter?" "I thought the filter was Sauron" etc
@mccraigmccraig why did you go for specific drives on machines for your services? Shouldn't they be able to fail over gracefully (say if you lose a c* or kakfa node)?
@otfrom i put c* , ES and kafka on MOUNT volumes for performance and operational simplicity - i can still add and replace nodes
and ELK's deployment story on dc/os was looking painful - whereas humio have a dc/os package which makes it trivial, so convenience won out
one of my goals was to have zero config of the dc/os cluster after the cloudformation setup - ELK would have required config on every node, so another config mgmt thingie
but i wanted to use a mesosphere supported dc/os deploy, and that meant cloudformation
this looks well considered https://github.com/bernadinm/terraform-dcos - if i wanted to start again and go terraform instead of cloudformation i'd probably try that
yes, although the "important" statement here https://dcos.io/docs/1.10/installing/cloud/aws/advanced/ might make me reconsider in the future
whereas bernadinm is clearly a devops beast https://github.com/bernadinm/terraform-dcos/tree/master/aws#upgrading-dcos
@mccraigmccraig based on my conversation with you, I think cloud formation might be better!
cloudformation has been rock solid, once i figure it out - and the dc/os templates are the mesosphere supported way of deploying on AWS, so it's a good solution
ha, maybe, i had a look inside the mesosphere CF json... the thought of having to do anything with it other than run it unchanged made me sad