Yes, and they did the refund immediately. They cannot deny it: you don't even need to justify the claim: you just need to say "I want this transaction refunded". Of course if it's a bogus refund you are getting it's then your business with whoever was expecting your money to sort out.
As far as I know the only reason they can refuse this is if you are too late with the request: you have 1 month after you receive the monthly statement with the transaction in question to have it refunded.
Funny fact: the biggest share of that transaction fee is by far interchange, which don't go in the pockets of Visa/Mastercard at all but in the pockets of the card-issuing bank...
I prefer not to "donate" a few percent of the transaction value to MasterCard, VISA & co (and spare me the "handling cash also costs money". Yes it does. But that cost/value is generated locally, not remotely and by a huge financial player)
It's ridiculous to call it a "donation". Credit Card transactions have a fee for good reasons: first of all they do provide a service so it stands to reason for it to be paid for. Far more importantly, if you pay with CC you are covered by their zero liability policy. You just need to contest a transaction to have the money back right away, no questions asked. Basically, all your CC transaction are automatically insured against fraud.
The reason the Swiss National Bank introduced the negative interest rate is well known and very clear: in a time of weak economy when many look at the Swiss Frank to store value, countermeasures have to be put in place to avoid it's excessive appreciation and to ensure money gets invested instead of held in account.
An excessive appreciation of the Swiss Frank would be a problem since it would negatively affects exports. Furthermore, money held in SNB accounts is effectively not being invested as it could, which is not a good thing if you want the economy to ramp up again.
Basically, the Swiss are not being screwed: without that measure the Swiss Frank's value would get far too high. It's a controversial measure, but an effective one for the stated goal.
It makes perfect sense though that if *by your own choice* you have an increased risk you pay for that with your own money and not with society’s money.
The government service not being free doesn't lead to the conclusion it also has to be more expensive than a private company's equivalent. Of course ultimately it must be paid, but the increased taxes are not necessarily higher than the "free and open market" price.
This is especially true when the "free and open market" actually is dysfunctional, with competitors not competing that hard but actually colluding, legislators not keeping things under checks and balances and the consumers getting milked as hard as possible in the name of profits.
Maybe... but my tax office actually spotted and corrected a mistake in my tax filing a few years ago, which ultimately resulted in a *lower* due tax...
If company comes back offering payment in exchange for an NDA, that would be an interesting legal situation.
Isn't that exactly the situation described in the article?
According to the article the original deal between the casino and the researchers did not include any monetary compensation, but neither did include any NDA: the researchers planned to disclose the vulnerabilities found in a security conference.
It's the casino which, without being prompted by the researchers, at some point initiated a negotiation to get a NDA from them. The researchers then provided a quote for it and things seemed to proceed toward a deal.
Now the casino apparently doesn't want to pay anymore for the NDA, but neither wants the researchers to disclose the vulnerabilities they have found, so they went with a C&D legal letter. On the other side the researchers are still not under any NDA and are IMHO pretty justified in stating that if the NDA deal never got finalised they are free to disclose the information as previously planned.
It's time to say get a vaccine or don't go to public schools. The only exceptions should be kids with compromised immune systems that can't be vaccinated. If parents don't like it, they can save the schools money and homeschool.
School is not the only place where children interact, not to mention vaccination is not only relevant to children.
The question is whether unvaccinated people are a serious danger to the public health. The scientific consensus is yes, so vaccination has to be mandatory (except for medical reasons of course). Public health considerations must trump any personal freedom considerations.
Most "free" apps still earn revenue through ads or in-app purchases which obviously generate revenue for Apple too.
You cannot compare the payment transaction fees you pay at a retail store with Apple's: they are very likely to have special deals e.g. for massive amounts of small transactions and other discounts.
Not to mention that if you use Apple Pay the bank has actually to pay Apple back a percentage for the transaction...
The reason retail stores have such high markups is because they also have pretty high costs. You cannot compare them to a digital store, where costs are much lower. A retail shop with 50% markup might barely survive, where a digital store would swim in money...
This is especially true for an application like Netflix, where the actual content is not hosted by Apple, only the application is. The Apple Store merely provides the download for the application plus updates and manages payment transactions: these costs are marginal at best and not nearly enough to justify a 30% cut the first year, nor the 15% cut subsequent years.
It’s actually a good thing IMHO: it trains voters to actually try to understand the consequences of their vote or pay the price for their own shortsightedness. It also in part removes from the equation the usual excuse “politicians did that!”.
The 5 forms of alternative medicine voted in 2009 were included in the basic healthcare coverage for a trial period, pending evaluation of their effectiveness. I think homeopathy got included in the basic coverage due to the “placebo effect” actually having some value, with the majority of medics prescribing it knowing it’s basically fresh water but still obtaining good results. About the others I have no idea.
Furthermore, that inclusion concerns the basic coverage mandated by law: most people actually interested in alternative medicine treatments are likely to supplement the basic coverage with complementary insurance options anyway.
By giving up on teaching how to determine and document requirements, quality is reduced.
An agile team is *still* supposed to determine and document requirements. The main difference in agile is the assumption that these requirements are going to change. In my experience in many fields it's a very wise assumption to do no matter whether you are implementing with agile or not.
By purposely pushing out code before it's done, as soon as it might be somewhat useful, quality is reduced.
An agile team is *not* supposed to push out code before it's done either: it's supposed to factor the requirements in smaller modules which can be pushed out when done before starting with the next. This "done" should include satisfying quality requirements... Note that this factoring is usually the hardest part to do well and the key factor in the success of agile. The difficulty of this step is usually overlooked.
Insurance companies usually don‘t take bets until they have enough data to statistically determine the odds. The risk doesn’t need to be low: it merely needs to be known. The price of the insurance will be calculated from that.
I guess the “no exception” was meant in the sense “no category of worker should be exhempt from the 50/w limit”.
This doesn’t mean you cannot have exeptions to the 50/w limit in some weeks even if your category must comply with it: usually regulations take into account and allowfor emergencies, require proper compensation and might impose fines if overtime work is found to be structural and not exceptional as it should be.
Not all legal rights are a negotiable matter in private contracts: rights which are non-negotiable cannot be foregone no matter which contractual clauses you sign.
This right seems pretty clealry meant to be non-negotiable.
To be more precise with "monolithic" I mean a task which a team considers monolithic, but actually it's not and another team might break down. That's kinda the point I was making: the more "agile" teams usually employ a lot of strategies to break down these kind of tasks. Less agile teams tend to do the break down only in the simpler cases.
Let’s not be ridiculous. Insulting others is still insulting others even if the insult would happen to be the truth.
Abouth the merit of your arguments: nope. A team being “true agile” or “faux agile” bears no prejudice on the quality or value of the team. A very good team can very well fail to implement an agile methodology well for a lot of perfectly valid reasons and there is no shame in that.
“Faux agile” doesn’t mean the team is bad or not valuable: that’s entirely your own misrepresentation of what I’ve written.
There are a lot of instances where a team can actually split a “monolithic” task into smaller pieces successfully. In my opinion being able to do so is a key requisite for being agile. Note that there is no shame in “not being agile” IMHO.
In the cases you actually cannot (or should not for whatever reason), maybe an agile methodology is not the best tool for the job in the first place. Again, no shame in not using an agile methodology if it’s deemed unsuitable for the task.
You are an idiot. You do not value people at all. You treat them like machines. Worse is: you apply your own metric when a person is successful and when he is a true versus faux agile developer, actually you are an asshole.
First of all, learn to disagree without insulting others.
Second, learn to read and disagree on what the other person actually claims. I never claimed anything about personal success or whether a developer is good or bad, be it agile or not. I actually never claimed agile itself is a good thing.
What I claimed is that if you want to be agile and what to figure out if you are doing it right, checking how the dev cycle reacts to changes to the workload is a good metric.
If your workload gets more demanding, your organization/company is doing something wrong: e.g. they forgot to hire more developers.
Organisations cannot predict the future, even assuming they are good at planning. Furthermore, everyone makes mistakes, including those who plan. This can and will happen to most developers. It's definitely not their fault, but I never claimed it's a good thing or something I want, I claim it's reality.
Shortening the cycles increases the "residual load", like wasted time in sprint planing, sprint reviews and sprint retros, integration testing, acceptance testing etc. The shorter the sprint the more relative time you spent in meetings and the less relative time you actually do work. You got all this completely backward. If your team struggles to deliver features every sprint, then you have to lengthen the sprint period, not shorten it. You are simply an complete idiot.
Stop thinking that agile means only Scrum, especially Scrum as implemented in the typical large organisation. Of course if you implement a methodology with high overhead per dev cycle and with a high integration/deployment/release cost, increasing the cycle is going to hurt. Maybe it means you are not as agile as you think, which is exactly my point.
TL;DR: stop insulting others, stop assuming I place blame or judgement where I do not, stop thinking Scrum is the only agile methodology and that Scrum as usually implemented in large organisations is actually a good example of agile (it can be, but usually it's not).
Actually how the dev cycle reacts to the workload is a very good signal for the team "agility": basically, truly agile teams will shorten their dev cycle under demanding workloads, "faux agile" teams will lenghten it.
I worked in a "true agile" company with a 1-week release cycle. Under demanding workloads like rewrites or new big products, dev cycle went from weekly to ad-hoc, which basically meant "every day".
I worked in a "faux agile" company with 2-week release cycles. Under demanding workloads the dev cycle went monthly, or worse.
"True agile" developers have to master how to implement changes in small steps: increasing throughput means implementing more small steps in the same time. "Faux agile" developers don't master that and increasing througput ends up meaning increasing the steps lenght, defeating the whole idea of agile.
Said that, very easy to say, very difficult to master, especially if you depend on choices which are counter-productive to agile, which is very often the case in large enterprises.
TL;DR: if the dev cycle under demanding workload shortens you are doing agile right, if it gets longer you are doing it wrong.
Slashdot Mirror
Yes, and they did the refund immediately. They cannot deny it: you don't even need to justify the claim: you just need to say "I want this transaction refunded". Of course if it's a bogus refund you are getting it's then your business with whoever was expecting your money to sort out.
As far as I know the only reason they can refuse this is if you are too late with the request: you have 1 month after you receive the monthly statement with the transaction in question to have it refunded.
Funny fact: the biggest share of that transaction fee is by far interchange, which don't go in the pockets of Visa/Mastercard at all but in the pockets of the card-issuing bank...
Nowadays it's even easier since contactless terminals are basically ubiquitous in Switzerland, as are contactless cards.
I prefer not to "donate" a few percent of the transaction value to MasterCard, VISA & co (and spare me the "handling cash also costs money". Yes it does. But that cost/value is generated locally, not remotely and by a huge financial player)
It's ridiculous to call it a "donation". Credit Card transactions have a fee for good reasons: first of all they do provide a service so it stands to reason for it to be paid for. Far more importantly, if you pay with CC you are covered by their zero liability policy. You just need to contest a transaction to have the money back right away, no questions asked. Basically, all your CC transaction are automatically insured against fraud.
The reason the Swiss National Bank introduced the negative interest rate is well known and very clear: in a time of weak economy when many look at the Swiss Frank to store value, countermeasures have to be put in place to avoid it's excessive appreciation and to ensure money gets invested instead of held in account.
An excessive appreciation of the Swiss Frank would be a problem since it would negatively affects exports. Furthermore, money held in SNB accounts is effectively not being invested as it could, which is not a good thing if you want the economy to ramp up again.
Basically, the Swiss are not being screwed: without that measure the Swiss Frank's value would get far too high. It's a controversial measure, but an effective one for the stated goal.
It makes perfect sense though that if *by your own choice* you have an increased risk you pay for that with your own money and not with society’s money.
The government service not being free doesn't lead to the conclusion it also has to be more expensive than a private company's equivalent. Of course ultimately it must be paid, but the increased taxes are not necessarily higher than the "free and open market" price.
This is especially true when the "free and open market" actually is dysfunctional, with competitors not competing that hard but actually colluding, legislators not keeping things under checks and balances and the consumers getting milked as hard as possible in the name of profits.
Maybe... but my tax office actually spotted and corrected a mistake in my tax filing a few years ago, which ultimately resulted in a *lower* due tax...
If company comes back offering payment in exchange for an NDA, that would be an interesting legal situation.
Isn't that exactly the situation described in the article?
According to the article the original deal between the casino and the researchers did not include any monetary compensation, but neither did include any NDA: the researchers planned to disclose the vulnerabilities found in a security conference.
It's the casino which, without being prompted by the researchers, at some point initiated a negotiation to get a NDA from them. The researchers then provided a quote for it and things seemed to proceed toward a deal.
Now the casino apparently doesn't want to pay anymore for the NDA, but neither wants the researchers to disclose the vulnerabilities they have found, so they went with a C&D legal letter. On the other side the researchers are still not under any NDA and are IMHO pretty justified in stating that if the NDA deal never got finalised they are free to disclose the information as previously planned.
It's time to say get a vaccine or don't go to public schools. The only exceptions should be kids with compromised immune systems that can't be vaccinated. If parents don't like it, they can save the schools money and homeschool.
School is not the only place where children interact, not to mention vaccination is not only relevant to children.
The question is whether unvaccinated people are a serious danger to the public health. The scientific consensus is yes, so vaccination has to be mandatory (except for medical reasons of course). Public health considerations must trump any personal freedom considerations.
Most "free" apps still earn revenue through ads or in-app purchases which obviously generate revenue for Apple too.
You cannot compare the payment transaction fees you pay at a retail store with Apple's: they are very likely to have special deals e.g. for massive amounts of small transactions and other discounts.
Not to mention that if you use Apple Pay the bank has actually to pay Apple back a percentage for the transaction...
The reason retail stores have such high markups is because they also have pretty high costs. You cannot compare them to a digital store, where costs are much lower. A retail shop with 50% markup might barely survive, where a digital store would swim in money...
This is especially true for an application like Netflix, where the actual content is not hosted by Apple, only the application is. The Apple Store merely provides the download for the application plus updates and manages payment transactions: these costs are marginal at best and not nearly enough to justify a 30% cut the first year, nor the 15% cut subsequent years.
It’s actually a good thing IMHO: it trains voters to actually try to understand the consequences of their vote or pay the price for their own shortsightedness. It also in part removes from the equation the usual excuse “politicians did that!”.
The 5 forms of alternative medicine voted in 2009 were included in the basic healthcare coverage for a trial period, pending evaluation of their effectiveness. I think homeopathy got included in the basic coverage due to the “placebo effect” actually having some value, with the majority of medics prescribing it knowing it’s basically fresh water but still obtaining good results. About the others I have no idea.
Furthermore, that inclusion concerns the basic coverage mandated by law: most people actually interested in alternative medicine treatments are likely to supplement the basic coverage with complementary insurance options anyway.
Note that the “private purpose” protection in Switzerland does not apply to software though.
By giving up on teaching how to determine and document requirements, quality is reduced.
An agile team is *still* supposed to determine and document requirements. The main difference in agile is the assumption that these requirements are going to change. In my experience in many fields it's a very wise assumption to do no matter whether you are implementing with agile or not.
By purposely pushing out code before it's done, as soon as it might be somewhat useful, quality is reduced.
An agile team is *not* supposed to push out code before it's done either: it's supposed to factor the requirements in smaller modules which can be pushed out when done before starting with the next. This "done" should include satisfying quality requirements... Note that this factoring is usually the hardest part to do well and the key factor in the success of agile. The difficulty of this step is usually overlooked.
Does the excessive mounting actually causa problems, e.g. degrading performance since it doesn't scale well?
Insurance companies usually don‘t take bets until they have enough data to statistically determine the odds. The risk doesn’t need to be low: it merely needs to be known. The price of the insurance will be calculated from that.
I guess the “no exception” was meant in the sense “no category of worker should be exhempt from the 50/w limit”.
This doesn’t mean you cannot have exeptions to the 50/w limit in some weeks even if your category must comply with it: usually regulations take into account and allowfor emergencies, require proper compensation and might impose fines if overtime work is found to be structural and not exceptional as it should be.
Not all legal rights are a negotiable matter in private contracts: rights which are non-negotiable cannot be foregone no matter which contractual clauses you sign.
This right seems pretty clealry meant to be non-negotiable.
To be more precise with "monolithic" I mean a task which a team considers monolithic, but actually it's not and another team might break down. That's kinda the point I was making: the more "agile" teams usually employ a lot of strategies to break down these kind of tasks. Less agile teams tend to do the break down only in the simpler cases.
Let’s not be ridiculous. Insulting others is still insulting others even if the insult would happen to be the truth.
Abouth the merit of your arguments: nope. A team being “true agile” or “faux agile” bears no prejudice on the quality or value of the team. A very good team can very well fail to implement an agile methodology well for a lot of perfectly valid reasons and there is no shame in that.
“Faux agile” doesn’t mean the team is bad or not valuable: that’s entirely your own misrepresentation of what I’ve written.
There are a lot of instances where a team can actually split a “monolithic” task into smaller pieces successfully. In my opinion being able to do so is a key requisite for being agile. Note that there is no shame in “not being agile” IMHO.
In the cases you actually cannot (or should not for whatever reason), maybe an agile methodology is not the best tool for the job in the first place. Again, no shame in not using an agile methodology if it’s deemed unsuitable for the task.
You are an idiot. You do not value people at all. You treat them like machines. Worse is: you apply your own metric when a person is successful and when he is a true versus faux agile developer, actually you are an asshole.
First of all, learn to disagree without insulting others.
Second, learn to read and disagree on what the other person actually claims. I never claimed anything about personal success or whether a developer is good or bad, be it agile or not. I actually never claimed agile itself is a good thing.
What I claimed is that if you want to be agile and what to figure out if you are doing it right, checking how the dev cycle reacts to changes to the workload is a good metric.
If your workload gets more demanding, your organization/company is doing something wrong: e.g. they forgot to hire more developers.
Organisations cannot predict the future, even assuming they are good at planning. Furthermore, everyone makes mistakes, including those who plan. This can and will happen to most developers. It's definitely not their fault, but I never claimed it's a good thing or something I want, I claim it's reality.
Shortening the cycles increases the "residual load", like wasted time in sprint planing, sprint reviews and sprint retros, integration testing, acceptance testing etc. The shorter the sprint the more relative time you spent in meetings and the less relative time you actually do work. You got all this completely backward. If your team struggles to deliver features every sprint, then you have to lengthen the sprint period, not shorten it. You are simply an complete idiot.
Stop thinking that agile means only Scrum, especially Scrum as implemented in the typical large organisation. Of course if you implement a methodology with high overhead per dev cycle and with a high integration/deployment/release cost, increasing the cycle is going to hurt. Maybe it means you are not as agile as you think, which is exactly my point.
TL;DR: stop insulting others, stop assuming I place blame or judgement where I do not, stop thinking Scrum is the only agile methodology and that Scrum as usually implemented in large organisations is actually a good example of agile (it can be, but usually it's not).
Actually how the dev cycle reacts to the workload is a very good signal for the team "agility": basically, truly agile teams will shorten their dev cycle under demanding workloads, "faux agile" teams will lenghten it.
I worked in a "true agile" company with a 1-week release cycle. Under demanding workloads like rewrites or new big products, dev cycle went from weekly to ad-hoc, which basically meant "every day".
I worked in a "faux agile" company with 2-week release cycles. Under demanding workloads the dev cycle went monthly, or worse.
"True agile" developers have to master how to implement changes in small steps: increasing throughput means implementing more small steps in the same time. "Faux agile" developers don't master that and increasing througput ends up meaning increasing the steps lenght, defeating the whole idea of agile.
Said that, very easy to say, very difficult to master, especially if you depend on choices which are counter-productive to agile, which is very often the case in large enterprises.
TL;DR: if the dev cycle under demanding workload shortens you are doing agile right, if it gets longer you are doing it wrong.