Morning everyone

Hello

Hi @dominicm Do you have anything exciting planned for today?

I have a few interesting things pulling at me. I suspect my time is going to go to building a private static site using AWS things. But I feel like I should put some power into some of my other decaying projects.

How about you @yogidevbear

Nice. Sounds like fun. I'm doing a bit of Clojure when I have spare time. Also going to walk the dogs somewhere nice and try help my brother to open a bank account (less fun)

@yogidevbear our behaviourist recommended pain killers for Sven, and we've seen a massive improvement. He's much more like the dog we used to have, he's so much less reactive to everything. We've even had a couple walks where he doesn't dawdle, but runs!

That's awesome news :)

Not feeling blown away by this AWS Lambda@Edge stuff. The Lambda has to be in us-east-1, which is fine, except for that you can't mandate that a single Resource goes into a different region using CloudFormation. Nor can you do that with a nested stack. I'm in a position where I can tear everything down and move to us-east-1, but I can't imagine the pain if you weren't already there.

https://www.terraform.io/docs/configuration/providers.html#multiple-provider-instances Terraform could handle this though. So it seems that it would have been the better choice here.

I hear a lot of great things about Terraform

In theory it's slower than CloudFormation, because it has to poll. We've had a few experiences where Terraform is slow to catch up on newer AWS resources, we're expecting that CloudFormation will be better in this regards (citation needed).

Having said that, with CloudFormation I have run into a few weird things around Lambdas now. It doesn't handle API Gateways & lambdas changing very well, because it doesn't know that it needs to send an event to a particular resource after it's done the update. I wouldn't generally expect a tool to go ahead and make that particular override, but as CF is supposed to be super integrated into AWS, I do expect it. I have no idea if Terraform handles this particular case.

CloudFormation has a Java API, which has some very nice potential though. You have the potential to do some interesting things with regards to "oh, this is changing, I better go inform XYZ" (or, write a workaround for the above case)

https://stackoverflow.com/questions/46561222/aws-lambdaedge-debugging for anyone following along at home. This is a serious wtf moment for me

the other week, I got this ill-advised idea to just use postgres and json fields as a document store. Today, I got something semi-functional \ o /. https://github.com/xlevus/docufant-clj Performance? idk. Good idea? Maybe for prototyping. Well written? probably not, this is my first bit of functioning clojure.

@xlevus One piece of advice I'll offer: avoid using global dynamic variables and global state (atoms). It causes problems for multi-threaded code and it can cause problems even in single-threaded code if you library ends up being used by multiple other libraries that leverage that global state (since users will not be able to compose those libraries).

clojure.java.jdbc (which I maintain) used to have a global dynamic *db* variable when I first inherited it from Stephen back in the Clojure 1.3 days and one of the major cleanups in the API was to move away from that so a db-spec (or a connected spec) was always passed as an argument.

If you make the connection an argument to all functions, then users can choose whether to pass a simple map spec, wrap code in with-db-connection (or with-db-transaction -- transaction handling is all built-in to clojure.java.jdbc), or use a connection pool. It will simplify your library to take that approach too.

See the community-managed documentation http://clojure-doc.org/articles/ecosystem/java_jdbc/reusing_connections.html for examples of how connection reuse can be achieved.

(and I should have led with "Nice job on getting PostgreSQL JSON to behave like a document store!")