4,307 karma · joined May 2, 2010
With running you need to play the long game and slowly build up your pace, total mileage, and number of weekly training days. It's hard to be patient, but it seems to be the secret to minimizing training injuries.
If anyone is interested Eddycrest [0] makes beautiful high quality boards also available with custom graphics. They are a very small family business producing great sewing furniture and game boards!
disclaimer: the business is near and dear to my heart as my brother is one of the carpenters/jack of all trades there.
I just finished The Grapes Of Wrath and this opening sentence feels like an odd futuristic parallel to that story.
Expensive, yes. My hearing aids cost ~$2500CAD each but "how shit hearing aids are" is not my experience at all. My hearing aids (Widex) are awesome! The quality of audio in normal situations is fantastic. My only real complaint is that they're not completely waterproof so I have to plan ahead a bit if I'm going to be outdoors in the rain.
Sounds promising, but by "a dedicated Postgres." do you mean a different server or just a different db on the same server? I'm trying to get at how the cost would change between the two solutions. Right now we can run N databases on the same Postgres server for roughly the same cost as running a single multitenant db. Switching to "server per customer" seems like it would be cost prohibitive.
This is the approach we took and I think it helps with IT review docs.
There's a few different approaches and deciding which to use can be tough. When I was adapting a formerly single tenant Django application to a multi-tenant solution, I went for a "db-per-customer" (with many databases on a single db server) for a few main reasons:
1) Allows you to backup and restore databases on a per customer basis.
2) Helps with IT reviews if you can say "your data exists in its own DB and is not co-mingled with other customers data"
3) Implementation seemed like it was going to be simpler, especially for adapting an existing single tenant application to a multi-tenant one.
4) Makes it easy to migrate existing single tenant-db's to the multi-tenant app.
The main drawback for us I would say is that it makes managing database migrations/schema changes a bit more challenging since you now need to update N db's every time there's a schema change. This was not super difficult though.
Overall I am very happy we decided to go with a multi-db multi-tenancy solution.