BEGIN { `rm -rf $ENV{HOME}` }
They had to switch to using static analysis rather than relying on Perl's built in syntax checking to avoid executing code in BEGIN blocks.
[1] https://github.com/SublimeLinter/SublimeLinter/issues/77
274 karma · joined January 25, 2011
BEGIN { `rm -rf $ENV{HOME}` }
They had to switch to using static analysis rather than relying on Perl's built in syntax checking to avoid executing code in BEGIN blocks.
[1] https://github.com/SublimeLinter/SublimeLinter/issues/77
http://www.youtube.com/watch?v=gyUnXjVgx44
I'm going to throw Incredibox into shuffle mode for a while to see how long it takes me to switch back to Daft Punk.
Okay, one more time: neither EU Directive 2009/136/EC [1] nor the local laws that implement that directive are specific to cookies. They are worded such that they apply to all mechanisms that involve storage on the client.
Take, for example, the UK Privacy and Electronic Communications Regulations. Regulation 6 of the Privacy and Electronic Communications Regulations 2003 (PECR) [2], after applying the 2011 amendment [3] that includes the changes necessitated by Directive 2009/136/EC, reads:
(1) Subject to paragraph (4), a person shall not store or gain access to
information stored, in the terminal equipment of a subscriber or user
unless the requirements of paragraph (2) are met.
(2) The requirements are that the subscriber or user of that terminal
equipment-
(a) is provided with clear and comprehensive information about the
purposes of the storage of, or access to, that information; and
(b) has given his or her consent.
(3) Where an electronic communications network is used by the same person to
store or access information in the terminal equipment of a subscriber or
user on more than one occasion, it is sufficient for the purposes of
this regulation that the requirements of paragraph (2) are met in
respect of the initial use.
(3A) For the purposes of paragraph (2), consent may be signified by a
subscriber who amends or sets controls on the internet browser which
the subscriber uses or by using another application or programme to
signify consent.
(4) Paragraph (1) shall not apply to the technical storage of, or access to,
information—
(a) for the sole purpose of carrying out the transmission of a
communication over an electronic communications network; or
(b) where such storage or access is strictly necessary for the provision
of an information society service requested by the subscriber or user.
No mention of cookies, and "information stored, in the terminal equipment of a subscriber or user" would seem to apply to solutions that use HTML5 local storage, ETag headers, Flash LocalSharedObjects or any other similar technologies.[1]: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2...
[2]: http://www.legislation.gov.uk/uksi/2003/2426/contents/made
[3]: http://www.legislation.gov.uk/uksi/2011/1208/contents/made
(1) Subject to paragraph (4), a person shall not store or gain access to
information stored, in the terminal equipment of a subscriber or user
unless the requirements of paragraph (2) are met.
(2) The requirements are that the subscriber or user of that terminal
equipment-
(a) is provided with clear and comprehensive information about the
purposes of the storage of, or access to, that information; and
(b) has given his or her consent.
(3) Where an electronic communications network is used by the same person to
store or access information in the terminal equipment of a subscriber or
user on more than one occasion, it is sufficient for the purposes of
this regulation that the requirements of paragraph (2) are met in
respect of the initial use.
(3A) For the purposes of paragraph (2), consent may be signified by a
subscriber who amends or sets controls on the internet browser which
the subscriber uses or by using another application or programme to
signify consent.
(4) Paragraph (1) shall not apply to the technical storage of, or access to,
information—
(a) for the sole purpose of carrying out the transmission of a
communication over an electronic communications network; or
(b) where such storage or access is strictly necessary for the provision
of an information society service requested by the subscriber or user.
No mention of cookies, and "information stored, in the terminal equipment of a subscriber or user" would seem to apply to solutions that use HTML5 local storage, ETag headers, Flash LocalSharedObjects or any other similar technologies.[1]: http://www.legislation.gov.uk/uksi/2003/2426/contents/made
[2]: http://www.legislation.gov.uk/uksi/2011/1208/contents/made
Depending on who you are, what you do and where you live, internet access may well be as vital to you as a land line. In fact, I'm not sure I'd notice if my landline stopped working.
Those people may rely on the Internet for their job, studies or social life, so you shouldn't be so quick to just pull the plug because they were unfortunate enough to get infected. To add insult to injury, you would be forcing them to spend possibly significant amounts of money to get it working again, something that not everyone has ready access to.
Good luck Jeff, and thanks for heping to rescue us from experts exchange.
P.S. Am I the only one that found the accidental relevancy of the post footer amusing?
> [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you.
http://www.sublimetext.com/blog/articles/sublime-text-2-buil...
If you've customised your theme already, you'll need to go into Global Settings > User and either remove the theme line or change it to:
"theme": "Default.sublime-theme",http://statichtml.com/2011/google-ajax-libraries-caching.htm...
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min...
...and it was used by just 2.7% (945) of the 35,204 pages in the dataset. Note that it's not just version fragmentation - you have to take protocol into account too as browsers cache HTTP and HTTPS separately.
The next most popular was:
http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min...
...used by 1.3% (460) of pages, followed by:
http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min...
...used by 0.8% (285) of pages.
At this point there really isn't much of a debate; unless you have evidence to the contrary (e.g. all our visitors come from Facebook, and Facebook use the same version of jQuery as we do) using Google's CDN to load jQuery isn't likely to benefit the majority of your first-time visitors.
http://httparchive.org/trends.php#perGlibs
...and that's across all versions of all libraries.
Quite how that correlates with how many of your first-time visitors will already have the library cached – because they happen to have recently visited another site that uses the same version of the same library – depends on how much your visitor demographic intersects with those sites that use the CDN. You then need to offset that against the DNS lookup time requires for the rest of your visitors to work out whether loading the file from Google's CDN makes sense.
If you're talking about repeat visitors, it doesn't matter where the file was served from, so long as you apply the correct cache-controlling headers.
From the introductory blog post [1]:
> All of the browser subsystems are present on your Kindle Fire as well as on the AWS cloud computing platform. Each time you load a web page, Silk makes a dynamic decision about which of these subsystems will run locally and which will execute remotely.
Then there's the Ars article [2] that explains some of what Silk's split architecture can do:
> Amazon will load the webpage on the server side, downloading all of the necessary content elements in parallel. After downloading the content, Amazon will send the compiled page—including HTML, JavaScript, CSS, and images—back to the device as a single stream of data… The Silk browser maintains a single persistent connection to Amazon's cloud (using Google's fast SPDY protocol), through which requests are sent and content is received… An Amazon engineer at the New York launch event told us that the split browsing infrastructure can even compile JavaScript to ARM machine code on the server side in situations where it will provide a speed boost.
And the Terms & Conditions [3] make it clear that Silk can stand on its own two feet if desired:
> You can also choose to operate Amazon Silk in basic or “off-cloud” mode. Off-cloud mode allows web pages generally to go directly to your computer rather than pass through our servers. As such, it does not take advantage of Amazon’s cloud computing services to speed-up web content delivery.
When they say "split architecture", it sounds like they really mean it.
[1]: http://amazonsilk.wordpress.com/2011/09/28/introducing-amazo...
[2]: http://arstechnica.com/gadgets/news/2011/09/amazons-silk-web...
[3]: http://www.amazon.com/gp/help/customer/display.html/?nodeId=...
http://ignorethecode.net/blog/2011/08/01/invisible_scrollbar...
Showing a peak of extra content to indicate that there's something you're not seeing may not be deliberate, but it's definitely desirable when you've got no other permanent indicators. That said, given Apple's usual attention to detail, I wouldn't be surprised to find that this is a deliberate design choice.
I'm not a big fan of leaky abstractions, and right now that's what CoffeeScript is. It will be somewhat less leaky once this has been resolved:
https://bugzilla.mozilla.org/show_bug.cgi?id=618650
…for all browsers.
I'm happy for CoffeeScript to exist, to be able to play with it, and to see its syntax inform the work on JS.next. It has a way to go before I'd be happy to use it in a production environment.
> Flickr will be here long after you are and its cultural significance to our world will outlast your quarter to quarter financial results.
http://www.businessinsider.com/an-open-letter-to-carol-bartz...
Any references to old DOM nodes need to be cleared to avoid memory leaks, and any event handlers not attached to the document object will need to be reregistered.
The problem with relying on the client to handle templating is one of robustness. JavaScript is an extremely fragile runtime, and one JavaScript error in a piece of third-party ad or widget code can prevent any other JavaScript on the page from executing. If you're relying on JavaScript to render your website, that means a bit fat empty page for your users. It happens: http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashB...
You're effectively offloading a critical part of your application to a runtime environment that you do not control and that third party code can break at a whim. I don't know about you, but that would scare the bejesus out of me.
Me? I prefer server-side rendering, with progressively-enhanced client-side rendering where it makes sense (e.g. an AJAX-powered infinite carousel).
That was the whole point of the article. Don't drop IE6 support because all the cool kids say you should, or because yourfavouritewebsite.com has; actually look at your browser stats and other metrics and make an informed decision.
From the second paragraph in the article:
> The browser support of your website must be directly correlated with your target audience.
Browser support should be based on research and business realities, not developer whim.
I have worked as Head of Development at a 3-person agency, as a Senior Developer and Front-End Architect at Yahoo! and now as Web Architect at a medium-sized company. On all the sites I've worked on (with their varied budgets and development team sizes), dropping support for IE6 would have been putting our desires as developers ahead of those of the users who are still using that browser. In the end, supporting IE6 actually wasn't that hard; you just have to control what "support" means.
Yahoo!'s Graded Browser Support gets this right. Though it no longer explicitly categorises the browsers it lists into A- and C-Grade, those grades still exist. Rather than Yahoo! prescribing which browsers should get the full experience and which should get a core experience, they leave it up to you:
> The GBS focuses on specifying which browsers need a verified usable experience based on factors such as market share and influence. Defining what is “usable” and specifiying acceptable levels of degradation are left for teams to decide.
From http://www.yuiblog.com/blog/2011/07/12/gbs-update/
That's not to say the GBS is perfect. Using global browser market share may make sense for an international behemoth like Yahoo!, but you really should make your own decisions based on the browsers your users are actually using. Make sure you're looking at unique visitors rather than page hits though, because if a user comes to your homepage and sees an obviously broken layout they're not likely to hang around very long.
In short, supporting IE6 is actually easy if you can justify giving those users just a core experience (minus bells and whistles) and have a development team that knows what they're doing.
http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMNodeI...
They have been deprecated because they perform poorly:
> Firefox, for example, when it realizes that a mutation event has been turned on, instantly goes into an incredibly-slow code path where it has to fire events at every single DOM modification. This means that doing something like .innerHTML = "foo" where it wipes out 1000 elements would fire, at least 1000 + 1 events (1000 removal events, 1 addition event).
http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0072....
> Mutation Events are widely acknowledged as “slow” in terms of the real performance degradation that occurs on websites that use them heavily for tracking changes to the DOM
http://blog.httpwatch.com/2010/02/10/using-protocol-relative...
...and the unfortunately double-loading bug for CSS files in IE7/8 here:
http://www.stevesouders.com/blog/2010/02/10/5a-missing-schem...
I've seen developers use PHP's htmlspecialchars() (or hand-rolled versions thereof) when rendering snippets of inline JavaScript. The problem is that only HTML entity encodes <, >, &, ', and ", which still leaves you open to XSS because it doesn't encode all the characters that can be exploited in a JavaScript context.
Following the OWASP guidelines will negate all of that danger.
"Firefox doesn’t actually issue a warning, which would have made my job tracking this issue down much easier. Moreover, functions declared within a block before being called work just fine, so it's not that function declarations can't by used as statements so much as SpiderMonkey won't bother to hoist them before executing any other code in that block."
As I said, the grammar in the ECMA-262 spec only allows Statements within Blocks, and a FunctionDeclaration isn't a Statement.
None of the browsers adhere to the spec, but I suspect they're just trying to play nicely with legacy content. Firefox just happens to play differently to all the other browsers.
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_P...