3,186 karma · joined July 11, 2008
Minneapolitan in exile. My blog is http://recursion.org.
I usually go by "look" online but that was taken at HN when I registered.
> What if every "API call" were hosted by a different server? Well, you'd have a lot of flexibility in fixing any given call without needing to impact clients that don't use it. And it'd be easier to distribute it over multiple machines — it seems like it'd be a better design than the BEA WebLogic design, which is to run a few copies of your MonolithService on each of a handful of machines. There would be new problems to solve, but who's to say it wouldn't be a better design overall? We won't know unless we ask the question.
Choose boring (to you) technology.
Still, she is one of my favorite writers so it's interesting to read what she likes reading.
The busy work and stress of dealing with digital photos has actually caused me to take fewer photos. I have a preservationist bent and I just don't want to deal with organizing them.
[1] This doesn't mean they're bad -- they could have trouble interviewing, or be subject to conscious or unconscious discrimination.
Direct link: http://www.cosmographica.com/spaceart/pluto-predicted.html
I love Maciej's sense of humor and honesty.
Now, to download my bookmarks...
Also ignores HOA dues (if the home is a condo).
One question I have which is not addressed by the article is how to deal with database changes. Every database has difficulty with schema migrations to one degree or another, but MySQL (which IIRC is what GitHub uses) is particularly bad. In my organization, we are VERY careful with any deploy that contains a migration.
(I suppose this is where GitHub's staging environments with real world datasets come in.)
One workaround I've considered is automatically deploying code that doesn't contain a migration (which is the vast majority) and forcing a more manual approach to database migrations, to make sure people are on hand to roll it back if necessary.