Overall, I've found a lot of the AWS documentation to be missing essential information or examples, or vital bits scattered across the AWS web properties. For example, setting up multi-instance Docker containers was not trivial; essential IAM policies needed to get AWS to work were scattered in marketing information. I think AWS has a great collection of products, but it is definitely not turnkey.
Exactly. The way I see it is these patent trolls are sandbox bullies.
Newegg's suing back is a genius move. It basically sends the message that if you're going to make a frivolous claim and decide to abandon it, we'll file suit and stop you from making further claims (hopefully setting a case law precedent), and we won't even ask for our time/money back.
batiste, I think what you are describing is that the culture around Ruby doesn't put a smile on your face, rather than just Rails.
Ruby's philosophy is quite a bit different from Python, Smalltalk, Perl, Java, and PHP. Ruby is roughly described as "batteries included." Some people don't prefer this, as it encourages meta-programming and introspection rather than explicit instructions.
A lot of libraries and tools around Ruby use meta-magic; some libraries have been attempting to strike a middle ground with meta magic, such as Datamapper (explicit) vs ActiveRecord (implicit). But the bias is definitely towards implicit; or as what DHH calls "omakase."
No warning, no error, mobile safari just kills the tab. It's not fun. Optimize images, optimize audio, stream audio, stream images, reduce text, pack text, pack everything. Repeat, repeat, repeat. Still crashes. How do people work with Apple stuff? I got a macbook and xcode, it lets me view logs/etc, but nothing helpful.
I think this quote summarizes hackers today: ``[T]ime spent sweating memory is time you're not writing your app. The hard part is developing the experience is that you need to know when you need to care."
Not having to worry about memory is now a luxury we can afford in the age of plenty. While writing an efficient spellchecker would have been a great feat in the 80s, there's no point of that when you can load the whole dictionary file in memory.
In other words, memory management is a #highclassproblem for many developers--you worry about efficiency once you have a lot of adoption. (Within reason; if your app is unbearably slow that isn't good.)
We also live in the age of plenty in regards to how many things we have running at the same time, or how many tabs there are open in a browser. Things can add up pretty quickly.
And why settle for "without optimizing it's slightly faster than things used to be when people had to optimize", when you can have "optimized, it's orders of magnitude faster than things used to be"?
> you worry about efficiency once you have a lot of adoption.
Sometimes things can be tricky to refactor if you didn't move carefully at every step. Initially not worrying about efficiency at all might mean having to rewrite from scratch once you do.
Of course, this can't be generalized. Sometimes it really, really doesn't matter, unless you care about craftsmanship as a value in and of itself -- taking 10-20% more time to write code that makes you happy and proud might very well make you more effective in the long run.
If you can sell it as faster than the alternatives, it makes sense to optimize.
But in the web-focused marketplace, adding 6 months to your launch calendar to get something fast to market may mean someone else's good-enough solution becomes the entrenched, de-facto standard that you are now fighting to prove you're superior enough to that it justifies people's time cost to move their data to your solution.
It's easy to point out the places where you could've done a bit more optimization after the fact. And, yes, sometimes those optimizations don't cost an arm and a leg, but it's very easy to fall into the premature optimization mode that kills the product and the company. Not everybody has tons of funding in the bank. For some startups shipping a day later can put you in the death spiral trajectory. Timing is a huge factor in a startup success.
It's easy to think why not just do it right in the first place. Aside from the timing you, as a startup, don't really know what "it" is or "it" is constantly moving. Committing to perfection at that stage can be a sure way to kill the company. Even if "it" is known and it's not changing you still need to keep in mind the Gall's Law.
That's the problem AirBnb has right now, according to a friend. Using Ruby has scaled AirBnb's business to great heights.
However, it has heaped to performance and code separation of concerns and structure debt. Of course, AirBnb can now afford to move things to Java/Scala and things that are better for multinational companies.
For AirBnb, it's really hard to fix a lot of these things since the product requires good uptime.
In the event of a destructive fire caused by a manufacturing defect, does Tesla replace the car or offer a full refund based on a replacement value of a Tesla without going through the owner's insurance even if it is outside the warranty period? Or must the owner file a claim with the insurance company?
I have pre check with the global entry program and was 'randomly selected' to go through a body scanner on a recent trip, so it can happen. Most of the time pre check just goes through a simple metal detector though.