I believe the practice starts with resistors, and because of differences in use of . and , and the fact they are hard to tell apart, the units are placed in stead of the .
ie 1,500 ohm -> 1k5 ohm
"Domains provide a way to handle multiple different IO operations as a single group. If any of the event emitters or callbacks registered to a domain emit an error event, or throw an error, then the domain object will be notified, rather than losing the context of the error in the process.on('uncaughtException') handler, or causing the program to exit with an error code."
This will be great for things like request handlers, initialization code and other "loose" blocks of code where you don't really care about success but you do care about errors not propogating.
I've been reading back and forth between this post and the docs and I'm still not really getting it.
Is this just a way of registering a single callback to respond to error events that could be emitted by different operations? What are some examples when this would be better than handling error events individually?
> Is it sort of like a try/catch for error events?
Yes, but it's also sort of like a try/catch for thrown errors.
d = domain.create()
d.on('error', function(e) {
console.error('an error: ', e)
});
d.run(function() {
throw new Error("whoops")
})
would console.log, rather than crashing the program.
When an EventEmitter is bound to a domain, their error events and any errors thrown while emitting an event on them will be handled by the domain object that they're bound to.
Thanks! It is marked experimental, and we really do mean that. The API won't change in 0.8, but it probably will change somewhat in the next stable release. Please try it out and let us know what you think, especially in what ways it is lacking, how it actually helps or hurts in real apps, etc.
That description at the start of the docs is unhelpful.
After scanning the rest of the docs I get the impression that domains are weak containers for resource cleanup (not just IO), paired with an error handling context.
Not a fan of this. Especially when you are just starting out with an idea that changes rapidly. A Google Doc with a few bullet points for key goals and big deadlines is more useful.
From their job application forms, it seems like they use a lot of Autodesk 3D modeling tools along with Adobe creative processing/finishing software too. I'd also really like to know what software packages were used exactly.
Agreed. They are unbearable. But name a better alternative!
Anything that I can think of like adding to the CAPTCHA such as a half-line of letter above and below or adding noise would probably make cracking them programmatically even easier.
Surely they're not actually maintaining those hosts themselves (imagine the embarassment of doing a RDNS lookup and getting "flame-cc1.nsa.gov"). They are almost certainly compromised machines owned by someone else, which makes "securing" them in the classic sense pretty much impossible.
I know it was a joke comment, but names like "Flame", "Duqu" or "Stuxnet" are not names in which those viruses were developed, but those were attributed to them later through security community
I'd imagine the folks doing this have a windowless van parked outside a Starbucks. I'm fairly certain you'd never be able to trace it back to a .gov computer without physically finding the computers themselves.
What's impressive is that at no other company you could wake up one morning and say, "HTTP is slow, so let's change that." Google, amazingly, can do stuff like that, and I'd rather them ship early than not ship at all.
(Well I guess Microsoft could have done it but they would have screwed it up like every other net technology they introduce and then we'd have two internets or something worse.)
I'm not sure it's fair to say that Microsoft has "screwed up" every technology they've had a hand in. Ajax, notably, is a Microsoft invention. What I do think is a fair statement is that Microsoft has historically been slavishly backwards-compatible even with obvious design mistakes and implementation artifacts, whereas the other two 800-pound gorillas (Google and Apple) have a mantra of never keeping legacy tech around when it can safely be replaced. The latter results in cleaner technologies; the former results in longer-living technologies. As a programmer, I prefer the Google/Apple take, but it's worth noting that Microsoft's variant has a clear advantage for the user in at least the short-to-medium term.
>Microsoft's variant has a clear advantage for the user in at least the short-to-medium term.
The approach also often comes out on top when the client is a business and accounting considerations take the lead, as opposed to B2C situations.
When you divide the cost of a Microsoft license by 7 (number of years a business will be running XP on a workstation) it turns into a really great price.
The reverse compatibility mentality is universal in the enterprise.
To put that into proper context, XmlHttpRequest was a hack by a single person at Microsoft -- with zero input or coordination or working groups or long term planning -- on the MSXML team to do a favour to the Outlook team. Further it could only happen because of ActiveX, and paralleled various other light request tools that existed at the time.
XmlHttpRequest is a great demonstration of a hacker getting a solution out there.
EDIT: Downvotes? I am intimately aware of how XmlHttpRequest came into existence, having been closely involved with its birth, so if someone has some correction to add, please add it. But in no universe does XmlHttpRequest vindicate Microsoft on moving web standards along. Their contribution was unintentional and largely accidental.
During my interview with that team, one of the kids proudly took credit for the span tag. A weekend hack. Committed the code and shipped it. No review. SOP.
Being more standards-minded at the time, I wanted to throttle the kid.
With the benefit of hindsight, I see that all the jitter and experimentation was pretty much ideal. If a feature proves useful, other browsers may adopt it, and it may become a de facto standard.
Two internets looks like the direction Google are taking us, not Microsoft. No other company is so willing to bypass the standardization process so willingly, and force other browser vendors to use their technology or face compatibility issues.
SPDY, NaCl, Dart are among some of the examples. Developed behind closed doors where nobody else can have a say, then released as an "open standard", but at the same time slipped into the browser and promoted for use - thereby eliminating the option for others to propose an alternative, or any major (breaking) change.
I'm all for pushing forward with tehcnology, but google should open their doors earlier, or we'll end up in a situation where they're effectively dictating the direction of the web and other browser vendors are busy playing catch-up.
It'll only be impressive if Google actually take the advice from Opera et al, and adjust their SPDY protocol to suit everyone - not just Chrome users. (And the same for NaCl, Dart, and the next "new standard" Google push for).
… which has a clunky interface, annoying limitations and since release has been pushed forward by others (i.e. Mozilla).
Microsoft has had a few first-to-market ideas but they're horrible at continuous improvement because their core business is freezing an API and supporting it for a decade so enterprises feel comfortable using it.
HTTP wasn't, and isn't, broken. Google alone had the combination of a financial incentive to improve, engineers capable of improving, and few application-level opportunities to exploit instead. This is literally the last thing you should worry about optimizing. Very few of us are privileged enough to work at a place that is so short on real problems we can worry about one like this.
In this industry we have a 15-25 year rewrite cycle. The cycle always begins with something deceptively simple that wins wide support through being easy, and ends with multilayered nonsense of dizzying complexity. Efficiency was not a design goal of HTTP. "Changing" that isn't just insulting to the spirit of HTTP, it expresses a complete lack of regard for history.
I don't know how we're going to break the rewrite cycle, but I can tell you heaping complexity atop complexity appears to be exactly the engine driving it, and just when things reach the pinnacle of the absurd, someone comes along with a disruptive, simple alternative and takes over the world with it. SPDY is late-game technology. The end of this loop is near, and we'd be better served keeping an eye open for the start of the next one than trying to master the intricacies of one more difficult and unnecessary improvement.
This is only true if you narrowly define the scope to be what HTTP started as: synchronous, unidirectional, and only concerned with single files[1]. When you consider the problems many, many people - not just Google - are dealing with break at least one of those assumptions it's clear that HTTP is incomplete.
1. SPDY will be nice for anyone using much JS/CSS on their site
I don't think I could disagree with you more thoroughly than I do. Your argument amounts to saying the postal service is incomplete because mail trucks don't have jet engines on top.
First, HTTP pipelining exists.
Second, HTTP's inefficiencies establish a bounds on your performance. HTTP itself does not define your application's performance, unless you've already mined every optimization opportunity at the levels above. Do you ensure all your CSS and JavaScript assets are bundled into single files and minified? If the answer is "no," you have no business complaining about HTTP's performance—managing your assets better will improve performance far more than using SPDY alone will. What about your caching story? What about your database, is it indexed properly? These are tangible improvements that you can make in your application today that can and will improve performance for the end user.
At my work, there is a CGI app written in C that does some atmospheric calculations against a database. The old database was Oracle, the new one is PostgreSQL. The CGI now takes twice as long to run as it did before, which is noticeable because it used to take about 5 seconds, so now it's taking 10, for one day of calculations. Looking into the problem, we found a place where an index would be a good thing to add. So we added it, and the performance didn't change at all.
It turns out, the app is sending a separate SQL query for individual data points. The app needs hundreds of thousands of data points to do its work, so it's sending many thousands of queries on each request. One query can fetch all of the data this program needs in about 0.3 seconds. So this app is, in effect, not measuring the performance of the database itself at all; instead it's measuring the overhead of running an instantaneous query on Oracle and Postgres, multiplied by several thousand. It turns out that the overhead of setting up and performing a query is about twice as high with Postgres. This fact never matters in practice though, because when you notice it you're doing something stupid. Nobody ever says "you should switch to Oracle, because that Postgres's queries take 4 milliseconds to setup instead of 2." (The fact that this app is written in C and could easily be outperformed by a shell script is also telling.)
This is exactly why HTTP is in no sense incomplete or narrowly defined. Google is the one with the narrowing requirements: they know exactly how much money HTTP's inefficiencies are costing them and are in a position to throw engineering time and energy at that number to decrease it. They are also in a position to optimize every other corner of their stack, and presumably they have. This is not true anywhere else.
SPDY is somewhat beneficial for consumers. But it undermines the simplicity and clarity of HTTP. That's what makes this late-game technology. SPDY is SOAP and CORBA to HTTP's RPC. Is it a better definition? Probably. But it's also harder and the benefits are insignificant except at scale.
… and is not currently usable, nor as full-featured as SPDY even if correctly implemented by all vendors
> If the answer is "no," you have no business complaining about HTTP's performance—managing your assets better will improve performance far more than using SPDY alone will
Flat-out wrong: there are many use cases which require multiple requests (you only mentioned CSS/JS but images are significant, too) and this would be exhibit A for an HTTP deficiency: you've internalized the idea that a visitor to the site must download and process EVERYTHING you could ever use to avoid making multiple requests, wasting bandwidth and device CPU/memory because you're trying to use asset packaging as an end-run around protocol shortcomings.
As for databases, this was a fascinating and completely irrelevant digression.
