HN user
We’re concerned about this as well at GitHub. We don’t link directly to the Google Analytics script, which could be updated at anytime. Instead we host our own script version that’s locked down with CSP and SRI. We still allow XHRs to the Google Analytics origin to report the data but the script code itself can’t be changed without an internal security review.
Hey, I'm one of the devs for this new PR stuff. This flow is something we're hoping to improve as well. Force push support is pretty second class right now, any previous commits and discussion basically gets lost. It sucks.
So we already use a internal refspec for tracking the latest PR HEAD. You can actually manually fetch this under `refs/pull/123/head`. However, this is only the latest HEAD, not any previous histories.
My idea was to expand this to include tracking all historical HEAD refs. We came up with a clever/hacky idea to string together a chain of dummy commits pointing at all the historical HEADs. This fake commit chain would only be used internally, but it would ensure git's gc reachability checks don't sweep up any old PR HEADs. Its an alternative to creating a new ref for each previous HEAD or maintaining text reflogs for an entire repo network. Both have some performance issues for larger repos.
Its something we're still working on, but it still helps to vocalize your support for wanting improved force push support. :D
Ha, I guess someone started this awhile ago.
https://github.com/judofyr/duktape.rb
I opened a PR update it to 1.0.
If someone publishes a ruby-duktap c extension, I'll definitely get that supported in ExecJS.
It seems like Langley and Gibson both agree that OCSP Must-Staple would resolve all this.
"If we want a scalable solution to the revocation problem then it's probably going to come in the form of short-lived certificates or something like OCSP Must Staple." - https://www.imperialviolet.org/2014/04/19/revchecking.html
"The case for “OCSP Must-Staple" - https://www.grc.com/revocation/commentary.htm
This looks so great. I just looked at the current print.css styles today on a README and they look really awful comparatively.
There might be some JS hacks that could be done on github.com itself to render a more stylized view when ⌘+P is pressed. Avoiding the need for a special "print this page" button.
Private markdown files should be accessible from a tokenized raw.github.com link. So it'd be neat if https://gitprint.com/josh/secret/master/REAMDE.md?token=123 worked.
"both" referring to selector-set and jquery patch. Its wishful thinking that browsers could expose a similar api as selector set that they already use for matching css rules.
You can still export the data from GitHub Analytics into Google Analytics. That'd give you more info then what you get from a bad image hack.
Most the issues under "bower is a mess" are being discussed in the https://github.com/bower/bower.json-spec repo. I have a number of proposals to improve the "main" directive and other require paths.
There is a strong dissenting opinion in bower community that it should basically be just like "npm" and none of these structured require build tool hints should be encouraged. It'd be great if others in support of the current Sprockets bower integration or this Rails Asset tool to voice their opinion and real world use asset for improving the state of the bower.json manifest.
Thanks, Josh, author of Sprockets.
This doesn't replace Sprockets at all, but integrates with it. It replaces bower "installer" with a pure ruby dependency. Sprocket still handles the runtime operation.
It should require "sudo" privileges now.
If your site is a simple static blog or whatever, there probably is no XSS vector. So you probably don't need CSP.
> my hope for Rails 5 is it's the one that embraces fat-client JS apps
Pretty sure DHH would say not a chance.
The quickest way to drop it in vendor/assets. Anything there will override any gems. so `//= require jquery` will just find your local copy instead. Shouldn't have to change any requires.
curl http://code.jquery.com/jquery-1.7.js > vendor/assets/javascripts/jquery.js
Had this exact same issue. xpdf isn't on the new cedar stack.
Not ideal, but you can package up a rubygem that can compile itself. https://github.com/josh/ruby-xpdf
pow isn't written in ruby, but javascript. So it might be installable from npm soon.
If you `git clone git://github.com/37signals/pow.git`, you can install it from source with `npm install -g` (requires npm 1.0)
Hack: Change CFBundleVersion to 2.0 in /Applications/Dropbox.app/Contents/Info.plist
I've done this w/ my mustache implementation. Its compiled on the server side and sent down as a pure JS function.
Theres some duplication between the server side (Ruby) and client side (JS) models.
CoffeeScript has been a joy.
Because most of the code runs in the browser, we were able to use the WebKit debugger. I never had any trouble matching up the compiled JS with the original CS source.
All the eco templates are compiled and shipped along with the JS files. The server backend only sends JSON to the app. Its much smaller and faster to render, plus its cacheable on the client side. Its a huge win over RJS templates.