Song Exploder Functional Geekery Guitar Wank Greater Than Code Build Phase The Bike Shed Reply All All Songs Considered

@hmaurer Freakonomics is probably my favourite podcast: http://freakonomics.com/archive/ It's about "the hidden side of everything" and it's extremely interesting and well made. Software Engineering daily is a cool very broad podcast where the host interviews tech people: https://softwareengineeringdaily.com/

people who use json a lot, would you keyword your keys less if there was a similar syntax for string? I'm wondering if keywords are preferred for their terse reader support :keyword and changing json to use these is for this convenience. Would you be more likely to leave keys as strings if there was a reader macro (?) for simple strings, like #keyword => "keyword"?

although perhaps the octothorpe is a little overloaded

for me, probably not, as the important difference to me is that strings aren't functions, which isn't a syntax issue

also strings aren't interned, keywords are, which helps with comparison performance

i've seen some criticism of people who just reflexively tell cheshire to turn all keys into keywords. So I was wondering if there was a shorthand for strings this would largely go away

but both points here are very strong

It depends where the input comes from really

You can trust your db schema as source (ex col names etc), user input not so much

@dpsutton as one of those who dislikes auto-conversion, I see it as a tree walking problem. If I'm going to convert all the keys to keywords, only to walk the tree and transform it into some other format, why bother with the cost of keyword conversion?

But if the JSON is the final format I'm going to use, then I might convert them.

or just use Transit from the start

i haven't been in this sphere yet. but i'm starting a clojure job next week-ish. just wondering. not sure if they use transit there.

I've used Transit on a lot of projects, and it's super cross-platform these days. Even supporting Erlang and C#

We even used it to extend Riak's indexing engine at one point (written in Erlang)

And it's sometimes faster/smaller than json 😄

supports self-reference as well?

no, it's a tree format

but it does support arbitrary nesting of keys and values

so you can transmit something like {[1, #{:a}] 42} via . json

although Transit is extensible, so I guess you could write some sort of cashing self-referencing system out of it. I've never thought of that...

is aws / cloud services basically just giong up the chain and replacing humans with APIs ?

in the most recent project I'm working on, when I went from ec2 -> beanstalk, and beanstalk -> lambda, every time I felt like I only needed 50% the engineering power since aws provides so much

Sure, it's probably replacing grunt work @qqq. But someone still has to design and implement the logic those servers are running.

It's a bit like saying "the GC replaces humans". True, but we just found harder things we could tackle.

@tbaldridge : I'm bootstrapping a startup, and I have been measuring it in terms of "number of people I don't have to hire before I get 10M users"

ec2/benastalk/lambda --> not hiring any sys admins any time soon

@tbaldridge Thanks for recommending me cognicast; I’ve listened to a few episode and it has been great so far

aurora db --> not hiring any db admins any time soon

route53 / security groups --> not hiring any network admins any time soon

JVM, not hiring any memory management specialists any time soon

pre Java, did people hire 'memory management specialists' ? I feel your argumen tis "GC eliminates this human job that never existed in the first place", whereas AWS is replacing real human jobs

We've had low level specialists for years, ASM coders, C programmers etc. Most of that is now gone and replaced by higher end development.

Same with GPU programmers, OS programmers, etc.

Abstraction removes the need for the lower level jobs, yes.

But why I'm not worried about it is that the jobs simply adapt. We no longer have punch card programmers, or machine code translators, etc.

But also on the other hand, it still takes someone knowledgable in AWS to know how to configure these things without leaving massive security holes or performance problems.

@tbaldridge : I agree that you in particular need not ever worry about it, but I do think 1. alot of programming jobs will start getting replaced and 2. the levle of expertise required to be a programmer will be a rising and rising bar

maybe, but where were the PHP programmers 20 years ago?

@tbaldridge : I have no aws expertise. However, for $100/month, I get unlimited phone calls with AWS engineers who walk me step by step through how to set things up. I can't recall the last time I read any AWS docs.

There will always be entry level jobs in new areas as well. And in the case of PHP/CSS/JS/etc. the bar was actually lowered from where it was 20-30 years ago. PHP is way easier than C or asm.

Maybe for client side, as there isn't AWS-Designer yet. I would argue that if you want to be a sysadmin, the bar is much higher, because for simple problems, ec2/aurora suffices.

well, that's where the whole devops thing comes along right? We no longer have dedicated sysadmin teams, instead we have devops specialists working with the developers.

I don't understand devops -- so I'll concede here.

Having worked with many programmers who try and configure AWS stuff on their own it's not as easy as it seems. AWS has a ton of rough edges.

And even then, I have a relative that works for a major hotel conglomerate, and he has a full time job doing AWS network configurations. At the enterprise level, you still have plenty of need for sysadmins even on AWS.

Perhaps that was due to a legacy codebase. @tbaldridge , if you were designing a clojure app that did the hotel conglomerate work, -- would your app need sysadmins on AWS ?

Managing tens of thousands of servers is never easy and takes an entire team.

or would you design it using elastic beanstalk / lambda / datomic / aurora in such a way it just scaled on its own

But that's the problem, they don't.

Things don’t scale on their own

It will scale on its own to a point, but at some point you hit the limits of AWS, and then you have to rethink your problem, and reframe it with a better design.

Sure.

Just start thinking about multi-region systems and you got design problems to keep you busy for years.

quoting myself:

@tbaldridge : I'm bootstrapping a startup, and I have been measuring it in terms of "number of people I don't have to hire before I get 10M users"

even 10mil is high, and depends on a lot of stuff. I agree for a startup where you don't care about reliability or performance it works out fine.

But if you want those things you need multi-region support, CDNs, etc. And that gets really hard really fast.

So...have you tested this app with 10mil connections from disparate locations of the globe?

No. I don't have users yet.

1. Because of AWS, I can build this myself, whereas without AWS, I would not be able to build a prototype without VC blessings due to need of hiring all the extra -engineers / -admins. 2. AWS provides CDNs. I don't know if Aurora provides multi-region, but would not be surprised if it did.

If I were in the bootstrapping startup phase and didn’t already know AWS, I’d look hard at having an AWS consultancy build e.g. terraform configurations for me

i'd like to get 10 users. i'll worry about scaling when it is a problem i actually have. and if it is, then i have the money to deal with it.

new to clojure (and lisp, and fp, in general) - just finished brave clojure, which book(s) would you recommend i read next? joy of clojure? clojure programming? SICP? should i just go through this list https://clojure.org/community/books ?

@sundarj i'm liking Applied Clojure along with Joy of Clojure

i'm reading through @alexmiller 's Programming Clojure. Fantastic chapters, good code examples. I've bought it twice now, one for me, one for intern at our company

https://pragprog.com/book/shcloj3/programming-clojure-third-edition

sweet I'll check those out, thanks :)

Stepping one topic back in the conversation, I'm the CTO of a small startup and I have years of AWS experience and also all three of the "Associate" certifications, and while I try really hard to write code every day, sometimes I have to be content with that code being YAML. Keeping a n-thousand user platform afloat and running happily and resilient to a Cloverfield monster eating us-east-1 is a full-time job for at least one human.

AWS (or Azure or GCE, I'm sure) is an amazing enabler for proving a concept and demonstrating an idea, but to imagine that all the complexity of running something that can serve users at scale comes along with that first pair of access keys and super-reasonable bill is to do your future self a serious disservice.

"joy of clojure" is well-written. I ditched "for the brave" because of a chaotic explanation and stupid made-up examples.

“clojure for the brave and the true” was good imho