mcgwiz

Hmm, aside from the distaste of a "guilty until proven innocent" formula being injected, this suffers from a critical flaw. The word "endorse" symbolizes something different than "substantial and not nasty". It symbolizes subjective support, agreement. Because of this association, the use of this system will tend to signal that groupthink is valued, and a cycle of groupthink will become entrenched.

The fix is simple: use a different symbol. Something that more precisely, objectively signifies "not simple and not nasty". This will create a more permissive gate that allows opinions of moderate substance and moderate tone through (an "err on the side of allow" policy). Inevitably the symbol must also consider the tendency of moderators, being active participants in a discussion themselves, to favor their own views.

Taken all into account, I suggest the "endorse" link be renamed "tolerable". (Rather than an action, it becomes a kind of flag.) This has the explicit connotation of erring toward permissiveness of differing views, and contrasts the two fears expressed in the post: comments that are boring or unprofessional/spiteful/mean.

(And as it stands, upvoting already signifies "endorsement".)

Seems a bit extreme. Two of the stories currently on that list made it to the front page.

As with all programming practices, theory and application do not always align, especially when the application achieves cargo cult status.

The details of how MyClass calculates due dates should be irrelevant. The test in your example violates this. It makes privileged assumptions to assert implementation details.

This is why it's better to code and test against interfaces. This makes it harder to make any assumptions about the implementation because it puts the abstraction front and center. A test suite written against an interface can be applied to multiple implementations. This of course requires some dependency orchestration to load different implementations into the suite, as well as to create/avail any needed mocks for that implementation (which ideally are also declared as interfaces). But this limits ripples from implementation changes to the dependency orchestration code.

With that in mind, if an implementation's internals need testing, then tests can be written against the class itself (rather than any interface). If the class has dependencies, then it should be obvious (or documented) how/when those dependencies will be accessed. When necessitated by the class's outward responsibilities, this makes it possible to ensure that a dependency is correctly accessed in certain conditions. E.g. Perhaps it must be ensured that an order processor always asks for validation from a credit card gateway. Your example does not meet this standard.

Basic theory aside, I personally agree that high coverage is not worthwhile. I prefer tests that ensure bug fixes don't regress, or that are high-level and mimic end-consumer behavior.

Agree that structure-specific CSS is unwieldy. However, it's robustness is still a worthy benefit. If you use a white-space sensitive CSS preprocessor, it is not unwieldy, and actually quite maintainable and elegant, since it's structure reflects nicely-formatted HTML. E.g.

  main
    > section
      > main
        text-decoration blink

Thus, things that are easy to change in HTML structure (cutting, pasting, and changing indentation) are similarly easy to change in CSS.

Totally agreed. And more generally, specificity is by far the most difficult challenge in large-scale CSS. Without discipline and some well-defined conventions for selector construction, you will end up with the equivalent of spaghetti code and late-nights deciphering unexpected cascading from other people's styles.

Since large projects will inevitably have to rely on non-semantic HTML and class names anyway (e.g. to differentiate between sibling <p> tags), a simple rule of thumb would be to only use class names in selector construction. HTML elements can still be semantic for other purposes, but the CSS should not care about it.

The other half of the specificity problem is nesting. I advocate strongly against the descendant combinator ` ` in favor of the child combinator `>`. E.g. `.body > .content` is much more robust than `.body .content`. However, an alternate approach would be:

    <section class="body">
        <main class="body-content"></main>
        <aside class="body-sidebar"></aside>
    </section>

Either way, don't leave it up to individual developers. This has to be adopted by the team.

Fair point. "Abstract" might be better. It embodies the information-/implementation-hiding goal of this technique.

Abstractions still require names, and the names should be meaningful (not easy: "naming things is one of the hardest things to do in software development"), at least to the development team (hate to keep rattling off platitudes, but "you should write code for humans first, computers second"). Rather than "semantic", "descriptive" seems to fit the bill.

"Abstract and descriptive". Doesn't quite roll off the tongue, but I tried :)

So? Asking earnestly, what exactly is your point? That the title offends you because it uses the phrase "work around"?

Adding a relative path to a *PATH variable is clever, elegant, useful, and uncommon. It resolves a problem not directly (by changing how 'require' works internally), but indirectly, aka "working around" it.

This is perplexing to me.

> 1. Bad search ranking and Twitter/Facebook previews

This problem is patently obvious to the most cursory examination of single-page applications. If SEO is important, and you want to do an SPA, then you must be willing to bear the cost of addressing HTML requests. For my startup, I wanted to keep things DRY, which lead me early on to the Nustache engine for ASP.NET, allowing me to use the same Mustache templates on server and client. This doesn't have anything like the complexity described in the article.

> 2. Flaky stats and monitoring

Simply not true. Using Google Analytics and Backbone, you simply listen to the Backbone.history:route event and fire off a pageview using the Google Analytics API.

> 3. Slow, complex build tools

Complex, yes. Slow? Using r.js, no slower than a typical static language build.

> 4. Slow, flaky tests

Slow, yes, but no more so than desktop app test automation. I've found PhantomJS with QUnit (unit-testing), and CasperJS for integration testing to be quite reliable. It took a few days to get everything connected (scripting IIS Express to start and end in the background being the trickiest bit), but that was it.

> 5. Slowness is swept under the rug, not addressed

This is a UX challenge that is known and obvious up-front. Failing to address it is a design problem, not a technological one.

Overall, this seems the result of the ineptitude prevalent in inexperienced, "move fast, break things" teams. Rather than owning up to moving too fast and foregoing due analysis/research, they blame technology. Or, the article is a marketing ploy.

I had an incensed reaction to their email, which had only stated that the passwords were "encrypted". Not until I searched these comments here for the text "encrypt" did I learn that they actually hashed with bcrypt.

I humbly suggest all security notices like this that are sent in the future, if written with the word "encryption" rather than "hashing" for the layperson's sake, have an asterisk next to the word "encryption". At the bottom of the email, the explanation "hashing with {{algo}}" where "hashing" links to [1] would be included. Laypeople get their simple explanation, technical people don't get too angry. And some laypeople may click through the link and learn something.

[1] http://en.wikipedia.org/wiki/Cryptographic_hash_function#Pas...

Along these lines, John Resig recently created http://nodestreams.com/ as a way of composing and conceptualizing stream processing. Pretty nifty.

Let's be fair about this. You have a right to mouth off to a police officer as much as the police officer (in this case) had a right to arrest the offender. Neither are necessarily constructive, but simply allow stubborn people to prove some point. Practically speaking, one has to ask if proving that point (whether it's a point about morality or about power) is worth the risk of negative consequences.

Yes yes, done is better than perfect.

However, it helps tremendously for imperfect code to exist in a disciplined higher-level organization. In particular for OOP, this means interface and package/assembly responsibilities should be clearly-defined and leak-free. To me, this is the minimum ideal--it may never be definitively achieved, but one should aim for no less. Then, all manner of code abominations can be hidden and compartmentalized. Various components can be improved and cleaned at will, without rippling out destructively throughout the codebase.

This means some shortcuts are not allowed, and time to delivery will increase slightly. But those are the shortcuts that create spaghetti-code and tend by far to incur the greatest debt. So I see this simple minimum bound as a good 80/20 tradeoff for maintainability.

True, but I think he meant give them a chance. His point is that people seem to be criticizing it without direct experience, especially in a case that seems clearly fair on Azure's part to people who have experience with both Azure and AWS. Generally speaking, how can something earn credit when people are prejudiced against it and won't give it a chance?

"Bait"? Oh geez. First, they have Linux images all available under BizSpark.

Second, you act as if entrepreneurs are idiots who don't read terms/considerations of agreements and aren't capable of evaluating costs/benefits.

Everything about the BizSpark program is transparent. If you fail to understand the terms and to consider the ramifications (and if necessary hedge against risks by making your technology portable to other clouds), that is your fault. No one is forced into the program.

For partial argument binding, I find myself using an implementation that doesn't close 'this' much more often. E.g.

  Function.prototype.partial = function () {
    var 
      fn = this,
      args = Array.prototype.slice.call(arguments)
    ;
    return function() { 
      var newArgs = Array.prototype.slice.call(arguments);
      return fn.apply(this,args.concat(newArgs));
    }
  }

I would love for there to be some regular program of independent security auditing of major web companies focusing on social engineering attacks. It can be government-funded or privately-funded (companies would pay to be audited in order to be included in a certified registry). I'm not 100% sure how the details would work (they'd have to maintain a huge number of dummy accounts all over the place), but the value of such an effort would be tremendous.

The idea that these companies would rather cater to individuals who are careless with their accounts than uphold the sanctity of the majority of their users' identities is deeply troubling. The thought of a dispensable, minimum wage worker being all that stands between me and total calamity is terrifying.

To get into the linguistic nitty-gritty, perhaps he could have said "elitist strategy". But the point was that Dustin's execution, and the decisions behind it, were based on the marketability of exclusion. The point wasn't that Dustin thinks he is better than others and therefore should be judged negatively.

Lesson learned: don't expect a business built on breach of standards of conduct to be sustainable.

Monitoring call records and targeting ads based on them sounds very close to what the NSA has been exploiting in mobile apps (c.f. revelations a couple days ago). Atrocious. I blame both Pingjam and the app developers for callously abusing end-user trust and integrating with such a shady third-party.

This also reminds me of top comment on the $50,000 Twitter name social engineering attack article[1]: setup a list of vendors that have pathetic security practices, but in this case the list would be of apps that integrate shady third-parties.

I'm not sure if these guys are super-slick sheisters or legitimately clueless. This 'woe-is-us' blog post, written in the style of the humble lean innocent entrepreneur, certainly strikes me as disingenuous.

[1] https://news.ycombinator.com/item?id=7142523

Not that I have the time to do this, but it would be ideal if something like this existed for multiple services and was run by a third-party. Kind of like http://speakeasy.net/speedtest that speaks the APIs of various streaming video publishers. If it's crowd-sourced and non-profit, then it could be more credible and less subject to allegations of impartiality by the ISPs themselves.

Given that the greatest challenge to JavaScript testing is the browser environment, it'd be worthwhile to mention Zombie.js (simulated DOM) and PhantomJS/CasperJS (V8). Code organization is also important for any large codebases, which is often addressed with browserify or RequireJS.

The addition you're recommending is somewhat orthogonal to the article. The update at the end of the article clarifies that all one must do, strictly speaking, to protect against the weakness they describe is to power the computer down. If an adversary is knocking down your door, it's seems more important to get the keys out of RAM than to first ensure filesystem and OS integrity by saving/dismounting and cleanly shutting down.

Down-voter, can you articulate your objection?

I disagree with this premise, that we necessarily need that "end" state in content consumption. As many things in the real world have an end state as (effectively) don't. I can finish a game of Risk, but I will never finish building relationships with my friends. I can finish a pile of tacos, but I will never finish seeking an understanding of my existence. I can finish re-watching all Star Trek series, but I cannot finish learning about the opinions and ideas of others.

Some activities just go on forever. We learn that certain activities have an end and others don't. The ones that don't we give attention to in a manner proportionate to their importance. In representing content streams as infinite, publishers are simply mimicking the interminable reality of that activity. Future generations will never have learned that there's a daily endpoint to what you can know about your friend's lives, current events, etc. What a silly proposition!

I (wildly) speculate the feeling that an end state is needed springs from weakness/inability in moderating one's impulses. The end state then is really just a crutch to force one to stop some obsessive activity.

[Edit: removed disparagement of Star Trek DS9.]

Whitespace insensitivity and inability to return void in generic contexts are "critical flaws"?

Anyway, no one's saying C# is flawless. Personally, I would love the ability to declare immutable graph references.

I don't completely agree but your point is well-argued.

I'm bootstrapping my startup in NYC. I've spent over a year focused on iterating from intimate feedback of a slowly growing test group. The core product feels ready for a larger public push, but since it's a social network of sorts, I'm planning to play the long game with it. I'll organically grow the userbase on nights and weekends while returning to a day job. This strategy won't work with all kinds of startups, and once I start this I may find that my assumptions are way off and it won't work for my startup either.

Then, I'll adapt (seek angel funding?).

Ironically, at the moment the link to their own Privacy Policy page is broken. (I notified them by email.)

https://thedaywefightback.org/privacy.html

I wasn't making any comparisons. But since you brought it up, I'd rather have a $50- open source router than a $300 one. Just me.

Ironically, Belkin has a decent line of routers that are already flashable. I bought a dual band one new through their eBay store a couple years ago for $35. Threw Tomato (firmware of choice since it was released) on it and have been happy ever since: very fast, never locks up and supports dnsmasq.

Belkin bought Linksys, so they're the ones to blame, not Cisco.

I'm wondering if there's still marketability in stackable form. Do they even have switches of compatible footprint? Although I always dreamed of the day I'd stack my router on a switch from the same line to create a beautiful networking statue on my desk, I always deferred to price and other features when making purchasing decisions.

> pass through a million requests...

How does that make sense? As if CloudFlare would honor status codes but not take advantage of cache headers (which in this case stipulated an absurd 10 year expiration).

Clearly that venue data is valuable to them. Guaranteeing 99% accuracy can be a crucial selling point for 3rd parties. With a subscription-based offering, that data can provide a significant revenue stream.