I actually really like the prototype system, it makes introspection (also know as reflection) really easy. Surely class based has its advantages and I actually believe that could exist in a single system and be used where it is more appropriate. In my opinion once you start getting too big class hierarchies you should start using mixins and prototype based OO.
The only part of introspection that's easy is to figure out if a function is defined immediately on a class instance via `hasOwnProperty.` Everything else is very difficult.
For example, to build their dependency injection system AngularJS actually converts functions to source via `toString` then runs a regex on that to parse the count and names of function parameters so they can figure out what params to pass. This works (mostly, there are problems with minified code) but is a hack that pushes what should be compiler activity to runtime and slows startup.
That said - I agree with the rest of your comment. Towering class hierarchies are no ones friend and mixins allow for the quick creation of instances that would otherwise require one-off classes.
The dictionary used to be a very different book, meant for much more than listing definitions.
From the blog post linked below:
"The first thing you’ll notice is that the example sentences don’t sound like they came out of a DMV training manual (“the lights started flashing”) — they come from Milton and Shakespeare and Tennyson (“A thought flashed through me, which I clothed in act”)."
http://jsomers.net/blog/dictio...
After reading James Somers' post about adding the 1913 Webster's dictionary to his system I gave it a try. The old dictionary sometimes has archaic definitions but is generally much more useful and even entertaining to use.
If you've got lots of plugins for Chrome, try disabling most or all of them and see if that makes a difference. Plugins run in the same process as the browser and can add JS code to 'background' pages that are present in memory even when you're not interacting with the plugin.
Google published a remote desktop plugin for the Chrome browser. It's not Open Source, but it is free (as in beer), and professionally written installation / setup instructions are available in multiple languages.
Actual remote access for you will be controlled by the user, they create a one-time passkey in Chrome and share that with you to connect to their system.
Here's the plugin page: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fchrome.google.com%2Fwebstore%2Fdetail%2Fchrome-remote-desktop%2Fgbchcmhmhahfdphkhkmpfmihenigjmpp
Here's the support page: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fsupport.google.com%2Fchrome%2Fanswer%2F1649523%3Fhl%3Den
For non-technical users adding a browser plugin is going to be much easier to understand than messing around with port forwarding and system permissions.
"The National Rifle Association has launched a website defending the use of lead ammunition against scientists and environmental organizations..."
Okay then, at least they didn't defend the use of water boarding on scientists. Oh wait, I totally parsed that wrong due to my inherent bias against anything coming from the NRA. So, I checked the link and saw that it goes to a site "huntfortruth.org" (so you can kill it). Dang! There goes that inbuilt sarcasm again.
Here's a report, republished from Association of Firearm and Tool Mark Examiners Journal, Volume 31 Number 4, Fall 1999 written with assistance from a researcher a the Oak Ridge National Laboratory that details what a "green" bullet is: http://www.firearmsid.com/Feature%20Articles/GreenBullets/GreenBullets.htm
So the guy figured out that browsers render all links on a page and then reflow any that should by styled to indicate they have already been visited. Apparently you can figure out which links have been reflowed by checking the number of frames that have to be rendered to display a link. Not a big deal, and if your site uses the same style for links that are already visited, not an actual attack vector.
The second attack, using SVG (or, I assume) canvas to create a screenshot of what's visible to the end user could be leveraged for an actual attack, you know, if everyone didn't put iframe busting code on their pages served over SSL. Vendors can update the SVG rendering system to adhere to the same cross domain restrictions as other components and not include pixels from iframes in the buffer that is available to inspect via JS and this hole will be closed.
Not too much to worry about here, but I'm surprised that SVG doesn't already do this (canvas won't allow JS to work with cross-domain images unless they have been served with a header that marks them as "safe" according to their originating service).
Node.js supports the use of addons written in C/C++.
Use JS for libraries that are shared between client & server (e.g. HTML templating) and for logic that changes frequently or needs to be accessible to dedicated front-end devs (e.g. request routing). Use compiled C for code that needs to be extremely fast &/or robust (e.g authentication & creation of dynamic resources).
Here's a handy example addon from the node.js docs:
http://nodejs.org/api/addons.html
Resource Description Format? Oh no, it's a Framework.
No scope to speak of
well, it's not true really. In the following example x will have global scope and y will be local to its function:
x=2;
function test() {
y = x + 3;
}
--
The declaration of the variable 'y' in the example is missing its keyword 'var' and will unintentionally create a globally scoped variable.
Should be:
var x = 2;
function test(){
var y;
y = x + 3;
}
console.log(x);
console.log(typeof y);
- well, there is the keyword "inherits" and it does allow an object to be extended and you can use the 'prototype' to have multiple inheritance.
The prototype inheritance pattern doesn't allow for true multiple inheritance (like what C++ has). However, you can fake it by munging functions from multiple classes into your class' prototype effectively providing the functionality of multiple inheritance in simple cases.
meaning that third parties can implement their own interface to Yahoo! mail.
http://developer.yahoo.com/mail/
This may be what Fairpoint is doing to give users access through their branded portal. These same APIs mean that any user can implement their own non-Fairpoint approved access mechanism for their webmail.
It may not be a solution for all users, but at least yahoo's opened up enough that there are options available in the case of abusive network access providers.
Beware of all enterprises that require new clothes, and not rather a new wearer of clothes. -- Henry David Thoreau