aneth

I'm not sure what attitude you are referring to. You may be reading a bit too much into this.

I was simply trying to draw some perspective - "really pathetic" is a bit of an overstatement for not linking to Chrome on a browser recommendation page, and we all make plenty of oversights each and every day, so shitting on others for them is bound to undermine your karma.

Thank you. I'd like to agree :)

Nothing personal about it.

As an employee, you certainly take a "risk" that your job will not last forever. You may be fired, downsized, or the company may go bankrupt.

Fortunately, since we live somewhere where you can fire, downsize, and go bankrupt, there are companies willing to hire you for some period of time between when they need you and when they don't need you anymore. Otherwise, who would hire anyone if they could never fire them (here's looking at you France)?

The possibility of losing a job is inherent and essential to the concept of employment.

"really pathetic"?

I'm going to assume you've never done anything so pathetic in your life as to leave a web page with something less than the latest, greatest, most open sourcey, freedom-loving information.

Who the hell cares? Take a deep breath of chill the fuck out and don't read so much into things.

I doubt they spent much time debating which browsers to add here, or that this came out of a strategy meeting with Zuckerberg. I wouldn't be surprised if this was designed before Chrome was popular (perhaps with some styling fixes since then).

Even if they did exclude Chrome intentionally, they are entitled to promote whichever browsers they want to promote for whichever reasonable non-evil reasons they want.

Tips can't both be discretionary and an entitlement. That's a contradiction, and I think where the discomfort arises.

Either they are an entitlement - in which case they should be disclosed and added as a fee, or they are discretionary, in which case the servers wages should not be reduced because of the expectation.

Not really. The 10% is required and disclosed, so it is no difference than raising the prices. Tips on the other hand are an imposition since they are both expected and discretionary.

Sure, the 10% could be included in the price and wages raised, but it doesn't make much difference. It's the difference between a VAT tax and a sales tax - in the end the amount is the same - sales tax is just more apparent to the consumer.

I agree. Treat trolls and snappy shitheads like they didn't do anything offensive or annoying. Reward their good behavior and don't respond to their bad. Most will quickly realize that constructiveness instead of belligerence is getting them the attention and respect they seek. Challenging trollish behavior will just force them to attempt to justify their behavior through argument and attitude.

Regardless of anything else, it's wrong that servers are paid less per hour just because tips are common. This places an unfair burden on customers, and took tips from being part of a culture of discretionary generosity to being enshrined law. Since the tip is now required for the server to earn minimum wage, it is no longer a tip but a sort of marginally optional "fee."

IMO, a 10% service charge without expectation of a tip makes much more sense and is much fairer.

The entitlement culture in the service industry is so great that servers will angrily say things like "if you can't afford to tip on a bottle of wine, don't order it or stay home." Yikes. How about I just don't tip you.

> "because of the demographic of people who use rails right now"

What do you see as the problem with the demographic?

While I know historically Rails had a heavy conceited, dickhead user base (in Seattle particularly), the demographic has expanded so much that it doesn't seem to be the case overall anymore.

I occasionally venture into the IRC rooms for Rails, node.js, or some other technology when I need a quick answer that can't be found elsewhere.

I'm always shocked at how stereotypically asinine and snarky the responses to legitimate questions are. Yes it's IRC, yet somehow I expect it not to live up to its reputation - yet it does every time.

Redis is far more feature-ful, and can serve the purpose as memcache. Why have two parts when you only need one?

Redis offers persistence, set operations, namespacing, you can delete multiple entries with wildcards...

I'd say Backbone is a library. Ember is more of a framework.

For example, create 100 todos in their demo app, then check the select all button. Notice the instance response. This is because Ember consolidate actions and executes them once at the end of the event loop. This is not possible in Backbone without basically reimplementing that functionality.

I believe this is what they mean by "ambitious," because it's designed around issues that will arise in an ambitious Backbone project.

Backbone:Sinatra as Ember:Rails for a rough analogy.

Yes, the Iraq war had much to do with protecting the world oil supply. While the oil and gas industry is heavily subsidized, that war did not give the US a better deal on oil than anyone else. While it may have impacted oil prices, it did so globally.

I generally agree that this process doesn't sound all that terrible for code that controls a large, live manufacturing line. Try changing the code that runs a pacemaker - you'll learn all sorts of things about process.

This line however is the road to hell:

"if the company wants to spend $50,000 to change 1 line of code, and it's not going under, then that's obviously the right decision"

Just because a company is successful does not mean it does everything right and does not contain the seed of its own destruction.

This is a claim that requires some justification.

Gas in many countries is far cheaper than in the US, and the reason it is more expensive in others is heavy taxation and regulation, not lack of coercive negotiations.

This seems extremely conspiratorial and likely wrong.

iPhones can already be locked to a carrier. Whether the SIM card is virtual is irrelevant. If the carriers want to screw you, they already have means to do so.

In fact, I suspect a phone with a virtual SIM card may be easier to unlock than a physical one since Apple must distribute software designed to program the virtual SIM card. You also won't need to physically get a SIM card to use a network and you'll be able to use multiple networks with the same phone. That sounds like a plus to me.

Regardless, the SIM card is certainly not the limiting factor in carrier portability or locking. It's essentially a floppy disk, and is quite unnecessary given data connectivity these days.

The idea that Apple wanted a smaller SIM as a step closer to no SIM is ridiculous. What difference does the size make? Having a card or not having a card is binary.

Because if you did not sign, there is no written contract for that transaction, so there is far less of a case that the charge is valid. Regardless of what the signature looks like, you are liable if it was you (or someone you authorized) who signed and you are not liable otherwise. You are even liable if you charged for the transaction but did not sign - there is just no written, signed contract, so you are presumed not to have agreed to the charge.

None of the above is legal advice as IANAL, however I do believe it is correct.

Do you really think a merchant can verify those electronic scribbles on a tiny, crappy pen input device? No. Any mark made by you with the intent to sign is a legal signature.

Read more here:

http://www.npr.org/templates/story/story.php?storyId=9227832...

Given the fact that your signature is on the card, this seem rather ineffective. Approximate signatures are easy to forge and no merchant will deny a transaction based on a different signature.

In fact, that is not the purpose of your signature. The purpose is that you are signing a contract and agreeing to pay. It has nothing to do with security or fraud and merchants are not supposed to check signature matches - only that you signed.

A smiley face is a valid signature, as long as it is you and you agree to the credit card contract.

Likealittle seems to have died. It was a very clever, savvily marketed, but faddish idea that probably could have been leveraged into a college dating platform, but the product never seems to have evolved.

http://www.alexa.com/siteinfo/likealittle.com

Circle looks like a great pivot though. From my brief experiment with Highlight (deleted for being a useless battery drain,) this looks like it got a few more things right.

I think the idea of a pin at checkout is a good one to reduce fraud. However this is more work for the consumer, and reduces the bank's liability. Most consumers would probably prefer this, as it makes their card more secure and reduces the possibility of fraud hassles, which are annoying regardless of liability. Having something that is more work for the consumer and could save the bank money switch the liability to the consumer is just obnoxious.

I'm not familiar with this service. What is the advantage to the consumer in exchange for losing their fraud liability protection?

> No, it's a service, provided by Square, that you pay for.

Just because you pay a company doesn't mean you have an unconditional right to do anything you want with a company's resources. You do not pay for unconditional money from customers via Square. Part of what you pay for, in fact, are the resources Square requires to defend disputed charges on your behalf. Part of what you agree to when you join Square is to comply with chargeback procedures.

You pay for the service, yes. You also agree to operate within certain parameters, and don't have a right to demand anything you want just because you are a paying customer.

This seems to be a common fallacy on HN - that any paid customer is deserving of bend-over-backward support, even if the payment amount was less than $1 - Square's net revenue from this transaction.

That would be clever way to quickly fund his Square account, although it wouldn't avoid the overdraft fee after the ECH was initiated.

You are not expected to keep a month sales, just some small percent that will vary by your customer's tendencies to chargeback. Since almost every merchant account will have some chargebacks, and high volume ones will usually have some persistent level of funds in chargeback limbo, having some billing process to ask for funds is expensive and unnecessary. And what would happen when Jason refuses to find his account because he didn't agree with the chargeback?

Square was out the funds immediately. Jason could have avoided fees by funding his account the same day, or by simply keeping some reasonable amount in the account for potential chargebacks.

Square should not be required to keep a person on call to handle special cases like this or to ask merchants nicely for funds for every chargeback to an unfunded Square account. Automated ECH transfer from a linked account is fair and efficient, and once it is initiated can't be stopped.

I have to land squarely on Square's side on this one. As far as I can tell, Square has handled this matter exactly as I would expect and hope. They communicated professionally and clearly with Jason. Jason responded with empty threats and demands, and clearly does not understand or respect his responsibilities in his business relationship. Getting money quickly from a merchant account is a privilege, not a right. That privilege is afforded in exchange for honoring the chargeback process, which for good reason initially favors the consumer by provisionally reversing the transaction. When a chargeback occurs - as clearly stated in Square's initial email - "The respective financial institution notifies Square and debits the funds from Square."

Chargebacks are not fun, but they are a fact of life. When a consumer challenges are credit card charge, the consumer is entitled by law and contract to have their case heard, and in the meantime the middlemen must make sure they won't be left holding the empty moneybag.

It is entirely reasonable for the Square to make sure funds are available to pay the consumer debt should the consumer prevail - Square will be out that money regardless of whether Jason pays up.

To be frank, based on his attitude, Jason seems like the sort of guy who would refuse to pay up if the dispute had been decided against him and he disagreed with the determination. This is exactly the reason Square was and always will be justified in freezing the amount associated with any chargebacks. There is a process for handling chargebacks that you submit your self to in exchange for the convenience of getting money quickly from the credit card system. That money is only yours if the consumer does not challenge the charge - usually they don't, but you are responsible to pay if they do, and you are responsible for funding your account to cover whatever level of chargebacks your business sustains.

It is entirely reasonable for: 1) Square to freeze funds associated with chargeback attempts. At this point, Square is out those funds. 2) Square to withdraw funds from a link account if the Square account is empty. It's the responsibility of the merchant to keep funds available to handle chargebacks, as I'm sure is clearly stated in their agreement. If the merchant has kept all funds out of reach of Square, by withdrawing all their money from the account and keeping the associated bank account empty, the merchant is indicating that they do not intend on fulfilling their end of the bargain on having a merchant account - namely honoring chargebacks and the determination process for chargeback disputes. If this withdraw results in NSF fees, particularly for a chargeback of such a small amount, that is the merchant's fault for not funding their account. Furthermore, NSF fees are easily avoidable by depositing funds the same day - why Jason did an electronic transfer is beyond me.

Based on Jason's ignorance of his own responsibilities, his refusal to keep money available to handle chargebacks, his empty and immature threats to "go to the press" among other things, and his general disregard for his role in the business relationship, I would expect Square probably wants to terminate his account, but will decide against that as it would be more bad PR than it's worth. They would be justified, however, holding funds for a longer period of time, since it's clear he refuses to keep funds available to handle chargebacks and to honor the largely fair chargeback process.

The only counter point I can think of is that, for a certain chargeback/total charge ratio, it does seem Square could take the risk and absorb any funds deficit. That is not traditionally how things work though, and since Square is doing their best to get merchants paid as quickly as possible, it only seems fair that merchants would do their best to ensure Square they intend to honor their end of the bargain. If Square did take on this risk for small chargeback amounts for merchants in good standing (say < 3% of total charges,) this would delay someone like Jason's understanding of the chargeback process until a real problem occurred - like a large number of customers demanding refunds. That might ultimately hurt Square more than it helps, both financially and in PR.

What does it mean to "not support" a browser?

Does it mean you know your site is broken in the browser? Does it mean you block that browser? Does it mean you intentionally broke your site in that browser?

None of the above. It means you don't want to waste your QA time testing and fixing minor quirks in the browser and you don't want your users having a degraded experience on that browser. To protect your users, you may or may not provide a warning or block the browser entirely.

Products are in constant development, and every CSS change or javascript feature has the potential to break a browser and require fixes. Just because it works now, doesn't mean it always will.

It appears they successfully attempted to support IE, but decided it was not worth continuing, perhaps because of some breakage OP did not discover. Should they have stripped out any IE supporting code? That seems unnecessary.

Or anyone who used any of the myriad of social networks before facebook became dominante - Friendster, Orkut, MySpace, etc.

I'm not sure I understand your point. "SOPA sucks. Just like PHP/Java" is a useless statement, since the only thing the two have in common is "sucking."

The Bible is an alternative theory of the origin and purpose of existence, and is directly analogous to the matter of this thread.