how should I get the whole path that I should follow to go from source to destination (in latitude and longitude). Any API which would let me do so?

@tasdikrahman Dijkstra, A* and Contraction Hierarchies. See GraphHopper: https://github.com/graphhopper/graphhopper

at which point, should I switch from "develop directly against production db" to "have a production db and a dev db" ?

before starting your project

are you serious?

it's not a good idea to just develop until it's basically working, then worry about prod vs test db ?

some would argue this is premature optimization // not necessairly me, I don't know yet

develop directly against dev db, and eventually make a prod db

but never develop directly against prod

alright, so prodjuction is beanstalk + aws + rds

what if, during dev, I want a way to interact with the production rds

if you need to be sure that works early on, put dev there too

mimicking all of aws seems way too much work

don't, just make a dev environment on aws

what you shouldn't ever be doing is having a "prod db" that you apply untested code to

okay, so there's dev-rds and prod-rds // even when developing locallhy, I'm ioperating with dev-rds

then, right before I deploy to beanstalk, I switch to prod-rds

right - and I like a "staging" for verification too

can you explain what you mean by staging? I'm literarlly going from "building hobby projects" to "oh shit, I'jm taking credit card payments now, so I need to be serious"

you must have a qa env that faithfully mimics prod, but never uses prod data. never go directly from dev to prod; stage to qa first, then promote to prod. so you need at least 3 environments.

why not just qa and prod ?

why have a dev at all?

treat qa the same way you treat prod. dev is for farting around, trying crazy ideas.

or: treat your environments the same way you treat your code.

a good qa env will tell you if you've added something in dev that won't fly in prod. you don't want to discover that after you've pushed to prod.

or rather, you don't want your users to discover that for you.

in theory, I agree with you

in practice, I'm probably goign to dev on prod, do something stupid, get hit with chargebacks, then decide, okay, time to invest in fixing this

qqq: one vital reason to have a qa staging environment is to test the very process of a "release"

in dev you fart around, do things to the db you might have forgotten etc.

but if you push up to the qa environment and forget the migration, things will fail

that's your reminder to write a proper migration and run it when deploying to prod

how do you populate qa / dev databases ?

do you snapshot the prod?

qqq: it's not just chargebacks, your reputation is not immutable, and it's finite. People leave services and don't come back if they think the devs are just fucking around

yeah, but it appears SV has bought into the whole "move fast and break things" movement

@qqq yeah, a snapshot is a good place to start with staging (but without sensitive customer details if such things exist)

does AWS make this easy?

if I launch an RDS with Aurora, MySQL, or Postgres, is there an easy way to "copy this prod over to dev" ?

with postgres I honestly usually use pg_dump directly, because I've always used it

I don't have experience with the others

alright, I'm convinced this is not too hard to do, and may be even scriped, i.e. dump prod, restore to dev

is there any step by step guide you can recommend?

I just learned this stuff at work where we had a wiki...

would you do business with a bank that used snapshots of prod data for qa?

eh, probably better than mt goz

Scylla / Charybdis = lose important data vs leak important data ?

it's all schemas. your prod dbs have schemas. use the schemas for qa. esp. now that we have spec generators.

leaking = lawsuits.

btw, you'd be amazed at what a sophisticated attacker can do with seemingly innocuous data. where i work we have PhDs whose job is to do "disclojure analysis".

maybe

though I'm already suspecting, that if you're willing to pay, there are places where you can type in someone's name and it'll dig through gov records to find brand of first car, elementary/middle/highschool attended, list of previous addresses, parent's name, etc ...

you don't have to pay. it's called "google".

@mobileink I've been thinking about this lately (re the spec thing). The problem is that spec doesn't necessarily hold the right proportions that the real data does, or the relationships that is really there.

@stathissideris is working on https://github.com/stathissideris/spec-provider which does statistical analysis to infer the spec. But I'm not sure it could do occurrence count into the resulting generators.

"disclojure analysis" - somebody's been programming clojure too long 😉

haha. disclosure, not disclojure.

until a website hits 1M dailya ctive users, does the choice of mysql vs postgresql matter ?

http://www.tylerlhobbs.com/

this person makes art with clj

p cool

Is it more likely, in a clojure shop, for things to be done "right" the first time, or is it just a given in our industry that things are rushed out the door?

I've definitely seen things rushed - but we can get closer to right when rushing than some competitors for sure

I feel maybe I've been doing startups too long. We're re-doing something because it was rushed out the door the first time, and now it seems we're cutting corners and rushing this one also.

as it turns out there is no "right" ;O

if u rush in a future-compat way with being more "right" tho that's nice

@nikki What's that from?

nvm https://leanpub.com/codeshifter