The problem that seems to be being missed here is that while fraud is one reason Visa has say over what they accept, the much much much bigger issue is ATF, Money laundering and Sanctions.
Cards like the Freedom card will never fly with either the Networks or the Issuing Banks as these kinds of payment instruments are immediately used to wash illicit funds.
Visa's stance with Steam is bollocks, and it is another example of the monopoly they hold over payment processing. They shouldn't have the ability to impact a legit merchants catalogue.
But the idea that we can have a Freedom card also doesn't checkout. The less known about what the money is spent on the higher the risk. And cost of complying with Suspicious Activity Reports regulations is really high (as the costs of you breach the requirements), so any attempts to create / run this kind of thing often don't stack up.
I don't know that I completely follow on this comment, in particular how code reuse comes into it.
I think the biggest thing is about deciding whether you have one or many.
There are a lot of cases where having many doesn't just mean there is a list to show.
In a lot of cases, having many means you now need to choose "the right one" to show/edit/action whatever.
This brings up all sorts of complications beyond "just return a list instead of a single item".
Even if you don't end up building it out, I think it always a good thought experiment during the design phase to think about how things would behave if there where multiple of key resources, rather than just one.
Would it have implications elsewhere? Are there low cost alterations to the design that can be made now that make space / allow for this key resources to be a list later on? How hard would it these be to do later?
I'm many cases the conclusion might be it isn't worth it and that's the right choice (yagni applied judiciously), but every now and again this might highlight a valuable early stage change that would have cost a lot to make later on.
These patterns and practicee generally aren't intend for _you_ as the developer of the app right now.
They are intended for the poor shmuck 18 months later who has to work with a tangled mess of copy text stored in JS, server side yaml files and a CMS.
I've been that person at least 3-4 time now. I've waded through changes where having static strings got the UI would have simplified things immensely, and _none_ of these have had anything to do with internationalisation.
They have been far more prosiac (Legal request, product changes, rebranding, just general things like "where did this text under interest rate calculator come") but have still taken significantly longer than they should have.
When you are writing these apps it can feel like it's not that hard to go back later and pull out strings, just some grunt work.
But once you munge your code through three refactors and a framework change it becomes so much harder.
I graduated a double degree of EE and Comp Science. My final year thesis was a project with a local company integrating their custom designed GPRS module with a GPS module to demonstrate mobile tracking tech (it was 2003).
Because of the project I went straight into a hardware design job out of uni. I was designing boards for mobiles! Working on circuit design, prototyping PCBs, I was psyched!
Problem is the company was run _terribly_. 3 months in we all got put on 2 weeks forced leave and then given redundancies. Aside from dinner pretty terrible management, the economics of doing mobile hardware design in Australia just didn't stack up (we were the only company trying).
In the end there were probably 10:1 software jobs for every hardware job. Given my experience so far, I opted for software.
It has been great, I love software, but I sometimes wish I had lived somewhere that had a higher critical mass of EE work.
The scale of the work being done to dilute the population is astounding.
We were there at Christmas time, having driven from Kathmandu. That trip was telling in itself: there was only one way to get a visa to do that trip, and all of the trips were run by a single Chinese government run tour agency.
Even with terrible roads, your can do the trip in 3 days of about 4 hours driving each. Instead they try and force most people into a 7 day tour. Luckily we got a driver we managed to haggle with and cut it down to 3 days.
Those who did the 7 days ended up staying in weird empty towns that had large hundred room hotels that were _completely_ empty, but also fully staffed.
The closer we got to Lhasa the more of this we saw. Huge infrastructure that appeared to serve no purpose other than to get people into the region.
You've also got to consider that this is putting _a lot_ of eggs in one basket.
Would 4-5 families really pool all their savings for 10 years to invest in one childs potential business?
Maybe. I think what is more likely is that 250k would represent a portion of the money a family could save and then put at risk. I would say this adds another order of magnitude on the earnings needed to be able to do this.
So I don't think it's worth quibbling over whether 50k or 100k is middle class. To do this I honestly think your parental income needs to be $1M+ a year.
> If code reviews aren't an expected part of the development process and there's pressure on delivering, it won't happen.
This hits at the heart of why I strongly agree with this post and think PRs and code reviews are ultimately destructive.
Reviews are going to get dropped _regardless_ of whether they are in the process or not. Pressure makes code reviews and quality worse, not better.
More than that, the need to "appear" to review is going to slow things down and can cause an exponential back up. I saw this happen about a mouth ago: 3 day release cycle got bogged down and then took _3 weeks_ to get a single release out.
Process goes out the window when pressure hits. You are then operating in foreign environment at the most critical point and your safety net of useless.
Your safety net when things need to go fast should be highly automated fast build and deploy, coupled with great test coverage, from unit to end to end.
The only exception might be if you work in highly regulated field where you legal required to have a very low Mean Time To Failure. In that case things move slow unless you are very well resources.
Otherwise (ie the majority of products) focus that effort on having a very low Mean Time to Resolve. If you absolutely need some form of quality assurance, Pair. Do continuous PRs and knowledge sharing rather than out of context after the fact reviews.
> Have you considered that... _you_ just like having your camera on, and like seeing other people?
Yes, I think this is the whole point here. This is a bidirectional relationship.
We all have biases, and for a lot of people wanting some physical concept of the person they are working with is one of them, so yeah, they might just like seeing your face.
It's your prerogative to turn it off, but there is a very real chance this will impact your relationship with other people.
The biggest change for me is that I now hide my self video 100% of the time. I can't see myself in an irl meeting, so I don't need to see myself online either.
Don't this kind of makes the whole problem go away.
I've got some direct personal experience in this one. A few key points from how I saw it play out inside:
- there was a lot of noise made about this by the bsafe crypto team when it was first implemented (anecdotal, but I trust the people that were there and the context below helps reinforce this). From what I heard there was clear communication that adding EC drbg to the toolkits the way nsa wanted was insecure.
- that happened before my time, but by the time I got there it was kind of an inside joke that EC drbg was an NSA backdoor (I think this was around 2010)
- the above was tempered by the fact that it was so horrendously slow, no one could imagine it being used
- even though RSA demanded it was the default RNG for the toolkit, the first part of documentation strongly suggested changing this default
- my memory is that this work on EC drbg funded development bsafe SSL toolkits. So while the money may have been relatively small, it opened up a new product for BSAFE
The smoking gun and the bit that made it really obvious that something was off about this came in its use as part of the TLS toolkits.
There was an explicit, but unexplained, requirement that the _first 20 bytes_ of random generated during the handshake were sent unencrypted as part of the handshake.
EAY led that crypto team, they knew their stuff and they knew that this was off and there was no legitimate reason for doing this.
My take: this team new what was happening and they made it clear to management. As a really the people who made the decision to take NSA money knew what it was and the implication and went ahead anyway.
As a foot note, when we did the cleanup on this we found that in some of the toolkits the way that the 20bytes was sent was flawed and would have meant that an attempted backdoor using this would have failed. Whether this was intentionally or not _shrug_.
But what are you fusing? If you want efficiency I guess you'll be using deuterium etc, of which we only have so much.
After that your efficiency declines until... Well you end up with fusion reactors that look like the sun. You also end up fusing all the mass that we need to live our lives on and make stuff out of.
If you don't think a civilisation could ever need the amount of energy that a Dyson sphere could provide, that's fine, we don't need one.
But if you imagine a civilisation that does need the energy a Dyson sphere can provide, then they make a lot of sense.
Points for most people are a zero sum or losing game.
I worked for a points loyalty program, and the customer always pays. The bank knows their market well, they know the redemption rate of points for different demographics and they set the annual fees on points earning cards appropriately.
For a small number of very diligent points hack customers, the bank loses money on this and the customer wins. For a larger proportion customers get back roughly what they paid in fees.
Then for the remainder the points eventually get written off or redeemed for value that is far lower than the fees they paid.
In my own anecdotal experience, I think it comes down to what the product you are working on needs, and how your team works.
Recently, I spent 3 years on Scala then switched jobs and spent 3 years in Ruby.
It was a shock to go back to dynamic languages, but after 3 months, I honestly couldn't tell which felt more productive or led to more stable high quality product.
In Ruby, we had all the issues people point out about dynamic languages, but the product didn't lean heavily on complex data structures or algorithms. We embraced complexity and failure and get good processes, designs and practices to deal with this.
In Scala, we had more rigour, but I also know I spent a lot of time on type design. Once things were sorted there was a lot of confidence in it, but generally, it took a lot longer to get there.
For certain systems that is absolutely worth it, for others (and in my case) it did feel like the evolution of the product meant this effort never really paid off.
It was possible and even made sense to use XML as the format for a build tool, however, it got stretched way to far. The idea was applied in use cases that were less and less appropraite, as a result years later you end up with something that is unwieldy and doesn't make sense and, generally, thought of as "terrible".
There are use cases were JsonLogic might make a lot of sense, and for those that is great.
Generally, I'm sceptical as there is high risk of increasing couplings in a way that will make change much harder. This will be particularly true if it is applied to use cases that don't truly warrent this kind of solution.
Given the ease and severity of this I don't think being technical does anything for you.
I am grateful for the "upgrade now" message being pushed it. As a technical user I can't trust my skills and knowledge to truly keep me safe from this one.
That sounds amazing, sadly in a lot of organisations that isn't how it pans out.
Either the engagement with technology doesn't happen early enough, or when it does, the technology point of view isn't given the weight it deserves. The ideas have already caught and too many people are invested and have 'faith' it will all work out.
The crux of this is that many of those people who carry the weight in decision making don't actually carry any risk or responsibility for delivery. Given the scale of engineering and time to deliver, by the time it comes to fruition they've moved on, so they never experience accountability for ignoring the advice.
I can never find the source, but I'm certain I've seen a study that linked the tactile nature of books to stronger recall. Smell, texture, weight, cover art, all these things aid with placing the book in the context of your life which, supposedly, would help with recall.
If true, I can imagine with physical note books that roughly the same thing applies.
Thing is, at their heart, these are document editing tools. They don't actually need an on ongoing operational cost (yes, maintenance, but as a number of people point out you can take the jet brains approach and lock to versions).
The supposed benefit of my data being hosted is not a benefit to everyone. I already have multiple solutions to backup and sharing, I don't need another silo where my data lives. I don't need another vendor hosting arbitrary data which means I now can't use the product because the megacorp I work for won't let that through their legal.
Key point I was making above was that one off payment is an option and can be successful, we don't need to fall straight into the free vs subscription dichotomy.
Whether we agree with it or not, I think what is strange is how subscriptions models have become the norm.
There _is_ an alternative that isn't free and that is one off payments (rember when we used to buy software?). I happily pay in the order of $50 to $120 for one off payments, often locked to a version.
In many cases this is _more_ than I've ended up paying for subscriptions I've used, then abandoned after 6-12 months.
Cards like the Freedom card will never fly with either the Networks or the Issuing Banks as these kinds of payment instruments are immediately used to wash illicit funds.
Visa's stance with Steam is bollocks, and it is another example of the monopoly they hold over payment processing. They shouldn't have the ability to impact a legit merchants catalogue.
But the idea that we can have a Freedom card also doesn't checkout. The less known about what the money is spent on the higher the risk. And cost of complying with Suspicious Activity Reports regulations is really high (as the costs of you breach the requirements), so any attempts to create / run this kind of thing often don't stack up.