I was using an Apple store employee's term. He claimed the "standard" configurations listed on the website are what we should typically expect in the store initially. Later, they'll stock popular customizations. FWIW, I've been unable to find a single "non-standard" machine in stock at a store in my cursory checks.
You're right. You wouldn't care about everything in npm. The point is this: When using Gulp/Grunt, we have to search for a plugin. This greatly limits our selection.
I see your point, it makes sense. But I have to note that in gulp (at least) you aren't restricted to plug-ins. You can use "generic" npm packages, as long as they output a stream (e.g. browserify).
My Angular 2 vs React post from Medium is currently on the front page of Hacker News and Reddit/r/javascript. I give Medium's platform some credit for that. Their tagging system helps get the ball rolling. It seems to provide enough eyes that someone is likely to submit it to the big aggregators. For many smaller bloggers, it's hard to get over that hump. I hit the front page a couple times on my personal blog, but most the time my posts just didn't get enough initial attention to create any buzz. I've been very impressed with my reach on Medium compared to my ~3 year old, post once/month .NET/JavaScript blog. In just one day today, my post got as many views as my biggest post of all time on my blog.
That said, there are cracks showing. Medium has begun removing features many loved. They pulled the full-bleed images that elegantly faded away as your scrolled down. They removed public inline annotations by the author. And any comments people make inline now cannot be made public anymore (very frustrating). All were unique features that drew me there. They're trying to simplify, but I feel they went too far.
That said, the writing experience is seriously luxurious compared to Wordpress. So that combined with the increased reach has me hooked...for now.
Great point. I didn't mention findability but that's a struggle in dynamic languages since you must resort to searching for strings. Thus in dynamic languages similar/duplicate function names hinder refactoring and navigation.
Point taken, I can understand the confusion based on the title. I'm referring to risk of boundaries between technologies causing people to choose the wrong tool for the job. In each example there are two ways to solve the problem. I'm simply arguing to stay native.
Logging has its place, but I'd argue it's far more important that great programmers write code that fails fast. In his example, he didn't have instrumentation in production to determine why a module was returning null. If null isn't an expected return value, then an exception should be thrown to avoid the system moving forward in a crippled and unpredictable state. A well tested system that stops processing and fails fast with a descriptive exception greatly reduces the need for time-consuming and resource depleting logging systems.
Thanks for a good comment. Failing fast is great. In this case, since null was returned, the whole call failed gracefully (returning an error code to the calling party instead of simply throwing an exception).
The key point though: however the problem is detected, you need to have enough information to help you answer the question "Why did it fail?". You can add information in an exception, or in traces/logs, as long as you can tell why it happened, not just that it happened.
Yes but no, in many cases you do not want to fail fast and loudly. If a corner case in a minor module crashes all the pages of your app, you better fail silently, and log.
