nfm

Only if it's not gzipped :P That would bulk it up to more like 25 bytes.

This sounds like a bit of an anti-feature to me. It might encourage a practice that makes it very difficult to tell what styles will be applied to an element without inspecting it in the DOM. I've been thinking about how to code for maximum grepability recently and this is at odds with that.

I believe the fix for this (checking if the request is xhr) hasn't been committed yet.

Wow, you weren't kidding - 10164ms for me. From what I can tell, there's not much dynamic content in the page. Static caching would go a long way there. I'm sure they'd appreciate a pull request from someone with some Django chops! https://github.com/mozilla/kuma

Please note these contain security fixes for XSS in `number_to_currency`, `simple_format`, and `i18n`, and a denial of service exploit in `ActionView`.

Agreed, the revert paints things in a whole new light: https://github.com/joyent/libuv/commit/804d40ee14dc0f82c482d...

Is that the typical case?

In Australia, although there's definitely a lot less VC money going around, I believe VC funded founders typically pay something closer to a stipend than an engineering salary. That seems pretty practical to me too - most founders don't need a 150k salary to get by, and you can make a million dollars go a lot further if you choose to pay yourself half that amount.

Why are people desperate to see Tesla fail? Is it a negative PR campaign from the auto or oil industry? This blog post shouldn't need to be written.

Why would anyone downvote this?

Looks cool. Here's what I'd love to see: built-in git deployment (ie. take a Dockerfile, build an image from it, and then after a push add the latest source code to /app and start new instances), and some kind of orchestration so you could run a number of app containers behind a load balancer container.

Can you do that with a server hook? I've looked into this before and thought it had to be a hook in the client repository, as it would modify the commit hash. This is problematic because it requires everyone to add it to all of their repositories themselves.

I'd love to be wrong on this!

I have mixed feelings about this, but that might just relate to a certain subset of SaaS products we've used - namely products that require heavy integration with your data.

I'd sooner spend engineering time writing our own report generators than writing code to push data to another service, in the format they expect, pre-empting which data we might want to have in that service down the track, understanding exactly how the different reports are calculated, and then inevitably having to write a few custom ones of our own as well.

Of course, the exception to this are services have a huge set of useful features and take basically no time to fully integrate with, like Google Analytics.

Official links:

http://googleblog.blogspot.com.au/2013/10/new-free-expressio...

http://uproxy.org/

This appears to be opt-in for Google Apps accounts.

An alternative would be to push to a private repo, rather than the shared, central repo. Of course, this has it's own pros and cons.

If you're interested in using presenters with Rails, the draper gem is worth a look: https://github.com/drapergem/draper

Does anyone know what's going on behind the scenes with `alias_method`? I'm curious to know how it's implemented such that it was actually faster!

We pay basically the same % fee for our merchant account (maybe 2.2%), plus per transaction fees for the merchant account, plus an annual fee and per transactions fees to the gateway, plus an annual fee and per transaction fees to our recurring billing provider.

2.4% + 20p sounds great to me!

Thanks to the dev tools team - these are some solid enhancements. Nice work!

I took it to mean that the 10 minute window was when the driver was driving past the LSE, where the detectors where.

I'm loving the focus that's been going into the FF dev tools over the last few releases, they are improving rapidly and dramatically!

One thing that irks me is inspecting returned JS values - I almost never want to see [object Array]. I vastly prefer the Chrome dev tools output: inline, expandable, and a meaningful representation for objects.

Not a bug, but I think it would be a big improvement :)

There are some interesting, semi-recent (last few years) attempts to fix the pitfalls of using mocks for testing - renaming methods, wrong arity, typos, etc.

rspec-fire for example validates that the object you're mocking responds to the method name you've used, and takes the same number of arguments. It also does it conditionally based on whether the class in question has been loaded, so your unit tests can run in isolation, but when you run your full test suite it will catch any mocking errors.

Pretty handy!

Why should they mention RapGenius? At Heroku, I expect it's very much back to business as usual.

Interesting. I search within a repo (for code or issues) 95% of the time! It'd be interesting to know what their metrics are for usage of the search bar.

A few quick first thoughts, having just flipped the switch. I think the description and website fields should be click to edit (and the labels need to be wired up). And I'm not a fan of the increasing emphasis on % LOC by programming language - this seems like an extremely low value metric to be so prominent, and a terrible way to distinguish between repos!

I'm looking forward to digging more into the redesign in my usage of it today. Glad to see GitHub continuing to improve and happy to re-think the current state of the app.

"We will continue fighting aggressively to keep your information safe and secure." - ...Facebook

Like almost everything, there's no simple answer as to whether requiring a credit card to start a free trial will be net positive.

This is very dependent on your product, market segment, trial length, pricing, and many other variables. You need to test this out for yourself.

Anecdotally, ~1000+ views can be performant in Backbone.

It's hard to say what bottlenecks you were hitting but zombie views that can't be GC'd, rendering to the page thousands of times (instead of to an in memory DOM element), or sorting your collections on dynamic, non-memoized values could have caused those kinds of slowdowns.

Good point - weekly billing implies 9-5, which isn't always going to be the case. It'd be prudent to negotiate overtime rates in the contract.

I think that's a good scenario for a retainer. You have a long term maintenance relationship set up that typically doesn't require chunks of work at a time.

The overheads to doing a 10 minute fix are massive: they email/call you to make a request, you change work contexts, fix the issue, test and release it, notify them that you're done, keep track of the time you spent working, send an invoice at the end of the month, keep an eye out for payment, thank them for paying etc.

Rounding up to the hour mitigates this, but unless you're doing several maintenance requests per client per week, or are charging very high ($250+) hourly rates, your business is probably losing money by keeping this client on the books.

I think it's better to negotiate a monthly retainer that ensures making tiny updates is worth your while, and then just have a set-and-forget invoice that gets sent automatically every month for that amount. Even better if you can get paid by direct debit.