326 karma · joined October 15, 2010
Pros: It's great for building your MVP. Super easy to get up and running, super easy to work with at a superficial level (I'm talking about storing data and querying here more than ops and administration), dataset can grow to a fairly large size without you having to think about your database at all, freeing you to think about your business. Mongo was my first brush with "schemaless" and that's a big advantage particularly for early-stage projects where things are in flux. I also enjoy using JS as the query language, because I like JS, but YMMV.
Also for certain use cases, particularly the single document case, it's probably one of the best solutions available. However, in my experience, this ends up being a limitation if your data doesn't fit nicely into a single document, and the types of data that do fit this use case are rare.
The cons you've probably heard before: no transactions, no joins, not ACID compliant, until very recently writes locked the entire database, scaling/sharding just works until it doesn't.
I tend to use a service object abstraction based around concerns, or "business stories". My service objects map to specific scenarios or pieces of business logic that often utilize multiple underlying Models and/or other entities (eg. third party interactions services).
It wasn't clear to me whether such a scenario is discouraged with Trailblazer, or maybe not even possible.
> Now, to be clear, I’m not saying you should immediately refactor all your Rails applications to use monads; I’m just using Ruby as a tool to explain an interesting idea about programming, not giving you a best practice for all your Ruby code. However, it’s good to know about techniques like this! And in some cases, by applying the power of monads wisely, we can untangle nested callbacks, make parts of our code more reusable, and generally make our programs better.
2. I rarely if ever plan ahead. Maybe if I have guests coming over for dinner I'll plan a day in advance. I typically have a rotation of staple dishes which I go through, but it's very flexible, and I come up with random new things when inspiration or boredom strikes.
3. All sorts of things, but typically Italian, French, Tex/Cal-Mex, some Thai/Chinese style and the odd curry.
4. Nothing strict, but I'm very low carb, low sugar, high protein and fat with tons of veggies.
5. I use cooking as an escape, and thus don't care too much about my productivity. That said, I can get stressed if things look like they aren't going to turn out well, or when I feel like I'm scrambling to maintain my timing. One tip: it typically pays off to do most or all of your prep work before you start cooking. A little prep+cook multitasking is manageable but I find cooking a lot more fun when I have everything prepped and ready and can focus all of my attention on the composition.
edit: I'll take it by the downvotes without responses that's a "no"?
The most relevant statistic in the link you reference is "Pct of population" with the US at 14.3% and Germany at 11.9%. Two and a half percentage points does not seem like such a big difference in scale.
My attitude isn't "why not me" but "why is this so absurd"? I got in to both countries, but one was a total clusterfuck and one wasn't. Obviously one of them is doing something better than the other. I'm positing that the ultimate solution to demand (if one exists), is more in the direction of the German system than the random lottery of the US.
Agreed that this is the case in a lot of industries, but the problem in Silicon Valley and the tech industry generally isn't the cost of workers, it's finding enough highly-skilled workers to allow companies to grow and achieve their visions.
Even if a new treatment for depression were developed due to this research (which it probably won't), and you were clinically depressed, would you want to receive it knowing it was came about after the torture and eventual deaths of 20 baby monkeys? I wouldn't feel comfortable with that.