Carlos Galdino carlosgaldino
| # Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems | |
| 1. **Chapter 1. Reliable, Scalable and Maintainable Applications** | |
| 1. R faults != failures, faults cause failures. Systems should be fault-tolerant, resistant to some types of faults | |
| 2. S Amazon cares about 99.9% percentile because people with higher latencies usually are people who have the most data and therefore, they’re most valuable customers | |
| 3. S tail latency amplification - multiple requests one critical path during one page served | |
| 2. **Chapter 2. Data Models and Query Languages** | |
| 1. Hierarchical model - imperative querying, no way to change schema, children are ordered, no many-to-many | |
| 2. CODASYL (network) vs SQL | |
| 3. NoSQL - often no schema (precisely - schema on read vs schema on write) |
| module IRV where | |
| import Data.List (nub, sortBy) | |
| import Data.Maybe (catMaybes, fromMaybe) | |
| import Data.Ord (Down(..), comparing) | |
| winner :: Eq a => [[a]] -> Maybe a | |
| winner votes = do | |
| let freqs = frequencies votes | |
| top <- topCandidate freqs |
These are the Kickstarter Engineering and Data role definitions for both teams.
Document moved to: https://github.com/servo/servo/blob/master/HACKING_QUICKSTART.md
Kris Nuttycombe asks:
I genuinely wish I understood the appeal of unityped languages better. Can someone who really knows both well-typed and unityped explain?
I think the terms well-typed and unityped are a bit of question-begging here (you might as well say good-typed versus bad-typed), so instead I will say statically-typed and dynamically-typed.
I'm going to approach this article using Scala to stand-in for static typing and Python for dynamic typing. I feel like I am credibly proficient both languages: I don't currently write a lot of Python, but I still have affection for the language, and have probably written hundreds of thousands of lines of Python code over the years.
In order to setup Rails applications locales on a per request basis, we ought to get such information in a Restful way. That means to always include the desired locale in the URL in order to correctly share context among users through simple links.
That said, Rails internationalization guideline already provides a complete list of options from which we have to choose one. In this document I aim to explain the rationale behind the decision.
