The nice thing about Kochiku is that it is a free open source project whereas CircleCI is a paid hosted solution. If you have hardware available to use as workers on then Kochiku is free to use. There is a real cost to the time required to setup and maintain Kochiku but, at scale, within a larger company, this route can make sense.
I am sure CircleCI takes security very seriously but it also nice (and a requirement for certain companies) that with a self hosted CI server, that your source code does not leave the company.
This is revolutionary because it is the first time that merchants have been ever been given the option to pay a flat fee per month in lieu of paying a percentage fee on each transaction. While that may not seem like a big deal you, merchants really love the simplicity of it.
A business that processes 60K a year is below the size that is targeted by this pricing structure. They are better off continuing to pay 2.75% per transaction.
Actually the merchant is only liable for the loss if they did not follow all of the rules and regulations for processing the credit card.
From wikipedia (http://en.wikipedia.org/wiki/Credit_card_fraud#Merchants):
"The liability for the fraud is determined by the details of the transaction. If the merchant retrieved all the necessary pieces of information and followed all of the rules and regulations the financial institution would bear the liability for the fraud. If the merchant did not get all of the necessary information they would be required to return the funds to the financial institution. This is all determined through the credit card processory."
From what I have seen, it is very common for the merchant to be liable for losses on a card not present transaction (e.g. online retail) but the credit card company stomaches the losses for a card present transaction.
I suspect that online merchants could reduce their liability by implementing things like Verified by Visa but choose not to because it causes them to lose too many legitimate sales.
Square users only keep the device into their phones when they are taking a payment. When it is not needed they will carry it in their pocket, backpack, purse, or even put it on their keychains.
Even if someone were to keep the device in their phone all the time I do not think it would wear out their headphone jack. It is no different than keeping headphones plugged in all the time.
Joel slams Twitter's blog as boring, saying it's essentially rewritten press releases but Twitter does have an engineering focused blog that has much more interesting content (for Programmers anyways).
"There will be somebody that will contribute code actually, but most of the times this code will be about features you don't want to implement, or will not look like sane enough to be merged without a profound review, or will solve a good problem in a way that is not general enough, or simply the coder does not understand enough of the Redis internals or about your future plans to provide an implementation that is acceptable."
When this happens should the maintainer write back to the contributor and explain to them how they would like to code to be written instead (can be very difficult to explain). Or if the maintainer has time should they fix the code up themselves and merge it in?