Arvel Gentry must be mentioned, he transferred much of the aerodynamics research to sailing with an amazing series of magazine articles. He debunked a lot of faulty theories, like how the slot works, in a meticulous but approachable style.
HN user
WALoeIII
https://www.andrewloe.com/
[ my public key: https://keybase.io/waloeiii; my proof: https://keybase.io/waloeiii/sigs/YA7PZUiF1uBYwXHp5NaXW6-noq_6l5IGSJxVxnCacqY ]
Don’t the terms of service for nearly all consumer ISPs explicitly prohibit sharing or reselling?
Completely unrealized gains or had you actually lost capital you converted to BTC?
Frequently at design time you don't know enough. This is exactly why SQL is great, it is incredibly flexible, it can also allow you to get in your own way, this is just a feature to help detect that.
This is very useful for batch or cleanup jobs.
For example, imagine a system where items are soft-deleted immediately upon user action, but not actually deleted for a few days to facilitate restoration (recycle bin).
There is going to be some nightly/hourly/scheduled job that actually really deletes these records. Initially it will have little work to do, but over time as the system grows it may become slow. Typically this would be hard to separate from other slow queries, you would have to catch it running while causing other queries to pile up. Query time isn't necessarily useful here as you may have enough I/O to cover the slow query replacing pages in the cache, but that I/O would be better serving user facing requests instead of this cleanup job.
This feature allows for the "work" it really takes to serve the query to cause it to error, instead of time which may grind down for other reasons. At this point you know its time to re-think the soft-deletion strategy, you disable the job. Maybe you sweep more frequently? Maybe you keep a look-aside of things to sweep to avoid scans? Maybe you sweep during a low-traffic time? Whatever. It buys you time to think.
I wish there were something comparable for MySQL.
This is excellent, especially the diagrams.
I'd love to see a explanation of the security implications of each flow. As I understand it the "most secure" flow is OAuth 1.0a (three-legged), but its a total pain so it is mostly avoided. OAuth 2.0 is dramatically simpler, but there are bespoke additions (Google and Facebook come to mind) that you have to handle, typically in the name of security. I am ignorant of all the implications and would like a guide.
You don't have to re-learn puppet/chef/cfengine/bash script every time. You learn it once. It requires much less effort to "maintain" than manually updating more than 1 box.
Can you please post a picture of the server so we can see all the sweet LEDs on network cards?
I want this to work, and be real, but I'm skeptical. I don't know how to change that.
For backend nginx instances (we use nginx to balance application servers, and nginx right in front of Unicorn on those application servers) use the Real IP module to have logs transparently show the original request IP not the load balancer's IP.
MySQL + Percona.
I have similar troubles with the mobile application when in "low signal" environments. It should decide to swap to local or do a better job buffering, but having 1 bar is not going to sustain a stream.
You are thinking too hard. Just pick one, you can always change later.
All of the options you have presented are "Very Good" - they do so many things right. To steal a pithy quote from my co-worker: "Its a balloon squeeze."
This decision will not determine the success or failure of your business, move along.
I pick Rails & Ruby.
There could be a revenue stream in here. They're limiting how many free users an application may have, but I would expect they could charge Tweetbot to have more users. Tweetbot could simply build this cost into the software.
Thats what this is.
Isn't this a "poor man's version" of what cloudflare offers?
They even have an optimized version called railgun (https://www.cloudflare.com/railgun) that only ships the diff across country.
Next time you are caching a bit list with memcached and running out of space, you may replace that big list with a bloom filter.
I'm a Ruby fan, but "pretty much first on the scene with their gem ecosystem" is patently false. CPAN is much bigger, and much older.
Site is having trouble.
CDN Link to the zip: http://c401222.r22.cf1.rackcdn.com/Tweetbot.zip
This is why nginx gzips the body before writing the headers out.
You can use 'chunked_transfer_encoding' to enable chunking, combined with 'proxy_buffering off', your backend can stream the body and nginx will gzip the chunks. Disabling buffering has other consequences, so be sure to read up and experiment before you go to production.
It says that the company is headquartered in Seattle, Washington which is on Pacific Daylight Time.
In my experience you get an IP returned as an A record for each AZ you have instances in. Inside each AZ traffic is balanced equally across all instances attached to the ELB. The ELB service itself is implemented as a Java server running on EC2 instances, and it is scaled both vertically and horizontally to maximize throughput.
I wish I could upvote this 50 times.
The diagrams show two separate masters in different regions with their own slaves, yet DNS is essentially randomly delivering users to each "half". There is no mention of how this is handled, or even that you would have to consider it.
You can't just put nodes in different regions, even with a database like MongoDB. It will work in theory, in practice you'll have all kinds of latency problems.
WAN replication is a hard problem and glossing over it by waving your hands is a disservice to readers.
"Real" solutions are to run a database that is tolerant of partitioning, and have application level code to resolve the inevitable conflicts. Riak, Cassandra and other Dynamo inspired projects offer this. On the other hand you can use a more consistent store and hide the latency with write-through caching (this is how Facebook does it with memcached + MySQL), but now you have application code that deals with managing this cache.
Either way you have to have very specific application code to handle these scenarios, and you may even run a combination of solutions for different types of data you need to store. There is no silver bullet, there is no framework or product that does it for you.
A "full-spec" machine, another X-Large with 4 EBS volumes that I can fail over to. Its in circular replication with the other "active" master (only one is receiving writes at a time). These instances are only snapshotted once a day to keep them as fast as possible.
I run a master with a "hot" master each in a different AZ and slaves of each in their respective AZs for days like today. Expensive, but makes it easy to sleep at night.
The slaves have their EBS disks snapshotted every 30 minutes, the master every 24 hours.
Agreed, start with a known entity. Take the one special table that is killing you and move it to a special database (Riak/Cassandra etc) suited for that task only once you understand exactly what you need.
Eventual Consistency is a feature, not a limitation of Riak (and friends).
It requires you to think about your application different, but it enables things that you could not do before.
For example, you can now handle databases in multiple datacenters, reducing latency to the client.
This cannot be reliably done with Windows XP in the wild.
http://en.wikipedia.org/wiki/Server_Name_Indication
Essentially, the cloudfront server doesn't know the certificate to present.
YAGNI - your first problem is getting customers.