ben336

Which is exactly why they're willing to make an offer like this :)

Thats not really how enterprise computing policies work :) If its not centrally administrated, its probably not allowed. At least in the type of environment where people are still on IE7.

Sources? Examples? Where are you getting this from?

they're legally required to rename it: http://gizmodo.com/microsoft-has-to-change-skydrives-name-be... (Edit: technically it didn't get quite that far. They're preemptively renaming to settle a lawsuit that they would lose. Regardless it remains hilarious how much trouble Microsoft has naming things. Even when they have good names like Skydrive, they turn out to be bad ones).

This piece doesn't seem to make any distinction between jQuery core, and jQuery plugins. If the lesson is "don't just stick random 3rd party scripts onto your site" then thats obviously good advice. If it's "don't trust jQuery, it might be dangerous", then I think they're just scaremongering.

Am I the only one who is a bit skeptical of this? Seems incredibly hard to believe, with no hard sources. (Email from Friend of a Friend of a gadget blogger is not where I want to be getting my credible news of law enforcement overreaching)

As an original Pittsburgh native, I'm curious which attributes of Pittsburgh you're thinking of when you say "Canada's Pittburgh"?

Nope. He's written a lot within a clearly defined scope "the human side of software development", so his articles are often related. Beyond that, self-linking is a great form of self-promotion and getting readers engaged in a blog.

That was my mistake. I posted it after reading, and didn't notice I was on the home page.

No LESS is a stylesheet language that compiles down to CSS. Javascript isn't involved at all, unless you use their script tool to run uncompiled LESS in the browser. That is only meant for prototyping though, in production it will be compiled down to CSS.

that site isn't actually Medium. Just a look-alike

"if the student hasn't even started programming prior to college, s/he is likely not of a succeeding mindset"

Clearly it couldn't have anything to do with a lack of access to resources, or simply developing an interest in programming later in life than you.

Starting later may make them less likely to succeed, but saying that it is probably because they don't have a "succeeding mindset" is quite a privileged sounding generalization.

Node.js 0.11 supports generators, which appear to be very similar to what you're describing: http://blog.stevensanderson.com/2013/12/21/experiments-with-...

Since that XKCD was from today, pretty sure the question is from today too :)

Sublime has very solid support for VI keybindings using a plugin that ships with the editor but is disabled by default.

Fair enough. I think the "tightly coupled to ember" part is what left a bad taste with me. Obviously the ember community is free to use whatever they want. But if the build tool is only useful for ember (and the "ember" name in the example cli indicates that will be the case) it seems like it might struggle longterm to keep up with grunt or other more broadly applicable build system.

Inventing their own build tools instead of using a Grunt plugin seems like a severe case of NIH for ember. I'd be curious to hear their rationale beyond "the currently-available options all have fatal flaws that make them unpleasant to use as your app gets larger."

oh cool. In my head when I see that I just think spammy popup :) I can't recall seeing it used for a legitimate purpose. But yeah that would accomplish what you're describing.

If I understand what you're saying correctly, I don't believe you can invokee a constructor defined in one window within another window ever. Javascript code is sandboxed to its current window/session in all browsers. You can't have multiple windows interacting with each other without some form of server-side code being involved. For what you're talking about (a web framework that has real time communication capabilities and can manage updates across multiple instances of the application on the same machine in different windows), you'll need to involve more than client side javascript. Unless you're talking about using Node.js, which you don't mention here.

Still see that.

Yes. They're generally performance and reading nightmares. But this is a very clever usage.

"it overwrites how require is actually supposed to be used"

According to whom? RequireJS is an implementation of the AMD spec.

If you read the release info, they're rolling auto-updates out over a few weeks. You can go to the IE website and download now if you want though.

Overaggressive learning algorithms can in some cases be more annoying than well thought out defaults. Especially since they won't be consistent (at least at first). Its not an easy thing to do right. For things like spreadsheet formatting, you want to have consistent behavior that you can rely on.

Note that this was written in 2001 when the statement "every piece of software I use is downloaded from the internet" would have been ridiculous at the time. Not saying your point isn't valid, but just pointing out that its not something that should have been addressed by the article.

It was canceled out by Stack Overflow and Bitbucket also being down this morning.

They say that they don't support it. There's a difference between "doesn't work" and "isn't supported". Isn't supported implies that if you encounter a bug that is due to your choice of JDK, they will not feel obligated to fix it (though may still choose to do so if its practical for them to do so).

I think most of the advocates for OOCSS would agree with you that preprocessors make them better. But the principles they're proposing are made better by preprocessors, they're not invalidated by them. Preprocessors let you get the benefits of reusable components without polluting the DOM with classnames. Which is better than plain OOCSS in most cases. But OOCSS allows you to have those reusable component benefits without tying you into a specific preprocessor (or any at all), and that is a benefit as well, even if you personally don't think its worth the semantic tradeoff.

Basically

OOCSS with preprocessor => reusable components + minimum DOM impact

OOCSS without preprocessors => reusable component + potentially messy DOM

CSS without OOCSS => potentially clean DOM + potentially non-reusable CSS

Did you see the outrage when they suggested requiring an internet connection? With the PS4 as a viable competitor they don't have the leverage to pull stuff like that.