This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-02
Channels
- # beginners (26)
- # bitcoin (1)
- # boot (9)
- # boot-dev (5)
- # cider (26)
- # cljs-dev (1)
- # clojure (190)
- # clojure-finland (1)
- # clojure-italy (42)
- # clojure-nl (20)
- # clojure-russia (3)
- # clojure-sanfrancisco (1)
- # clojure-serbia (1)
- # clojure-spec (50)
- # clojure-uk (16)
- # clojurescript (62)
- # core-async (4)
- # cryogen (1)
- # cursive (6)
- # datascript (1)
- # datomic (36)
- # duct (6)
- # editors (6)
- # emacs (14)
- # graphql (3)
- # leiningen (30)
- # off-topic (21)
- # om (7)
- # parinfer (13)
- # portkey (56)
- # re-frame (2)
- # reagent (2)
- # shadow-cljs (58)
- # vim (1)
- # yada (3)
It should be added as a class to Baldur's Gate / Icewind dale, where instead of casting spells you just type exprs in the repl that modifies nearby objects.
It's a game by a scandinavian team IIRC, where everything in the game is defined through a scripting language which you get a tool to access and modify. So the whole point is 'hacking' things like your bed to increase your rested to 100% in a minute instead of 8 hours, hacking doors so when you go through them you end up where you want to be on the other side of the map etc etc
Has anyone played around with ferret, a clojure-inspired project for the C++ embedded/ area? Very impressive to see one person make such independent progress.
I read a bunch of the source to get the gist of how it works, pretty cool for what it does.
Has anyone done cloud formation in continuous deployment before? How do rollbacks go in practice?
We haven't used it in CD but we used terraform for initial server setup. We tried a remote store like S3 to store the state and then tried rolling back. I am not involved in the project so can't go on about how it worked. This link might help if you are using terraform : https://blog.gruntwork.io/how-to-manage-terraform-state-28f5697e68fa
We use terraform now. The lack of rollback during failure seems like it would be problematic for CD
We have two types of stacks we deploy:
1. short-lived
This is the stateless app stack. There's only an ASG and LC in here, we actually don't do stack updates here currently, we deploy a new short-lived stack and update the ELB to point at the ASG. You could do a stack update though!
2. long-lived
The long-lived ones are applied via changesets through peer review to get the approval. These happen less frequently but it'd be possible to have CD create a changeset and await review. Databases, Queues, Topics, ELBs live here.
---
We've found the tool iidy
to be helpful it's a bit more user & scripting friendly out of the box (in terms of UI and also waiting for things to happen).
https://github.com/unbounce/iidy
I'm going to look closely at this, this is really useful @U09U89Y6Q, thank you
@U09U89Y6Q when the changeset is deployed, is it deployed via automation?
prefer vec
for this as it conveys intent better (and is probably faster for common cases)
thanks @alexmiller!
vec runs a path that can be very fast for small collections (by building an array and actually making that array the root node of the vector tree)