KPIs are generally set on a timeframe where they usually become meaningless by the end of that timeframe. For software, goals set for a year out are almost never going to be meaningful by the end of the year.
Pick your flavor of Agile or whatever process your team can agree to, but I doubt the term "KPI" will ever come up when doing real life planning and work.
1) It's pretty clear then that you don't have much experience with planning at level beyond a few people if you've never heard the term KPI come up in software
Feels like this person completely missed the point of choose boring technology. The point isn't to never use anything new or exciting, the point is to save the excitement for your core value prop so that you're not wasting time e.g. debugging why your customer database keeps losing data instead of iterating on your actual product, where all the excitement is.
Agreed. Their example is that selecting Elixir was a great choice for them. Cool. That was using an Innovation Token.
I'm guessing that in addition to Elixir, they also used plenty of boring technology. Like using `cron` or `at` rather than writing your own scheduling subsystem. Or building on top of a standard OSS database rather than rolling their own.
The point isn't to _never_ to use new technology, but rather to use enough boring tech that you still have mental bandwidth to pour into the new tech, innovation, or product that will be your competitive edge.
A technological aside that's neither here nor there with regards to the broader 'boring' debate: one of the advantages of Erlang/Elixir is that it's more of a self-contained ecosystem than, say, Rails, where you can run a bunch of different "applications" inside the same process, and it's easy for them to talk to one another. There are a number of 'cron' type things that you can easily run within your BEAM system. For some kinds of applications and deployments, this is pretty convenient. It's easier to create jobs programmatically, to introspect them, and to keep track of them all within the same system, without an external dependency.
Being banned from the iOS App Store also doesn't make your software unusable on Windows, or Mac, or any other non-iOS platform. The App Store's exclusivity is precisely the same as that of nearly every video game console.
If you are consistent in your claims and believe that all computing devices, including smartphones, game consoles, e-book readers, GPS watches, car entertainment centers, etc. should be required to provide a way for owners to run unsigned code, then my accusations of inconsistency do not apply to you.
In fact, I see much much less vitriol aimed towards game console store policy than iOS App Store policy. That's why I mention it.
They cannot fight all battles at once. They probably think they have a better chance of winning this battle and setting the precedent for the next battles for other "app store" issues.
And all these devices certainly should be able to run the code their owner wants them to run, full stop.
That this is often not possible is stupid but also incredibly dangerous. Not by the standards of the evil Apple just did, but what even more malicious actors can do to you is they can run code on your device & you can't do anything about it.
It could be state actors pressuring the company making the think & or exploiting vulnerabilities in the closed source firmware running on it.
They're clearly picking their battles. If they are able to win this case against Apple, they can use it as precedent to (hopefully) pressure consoles to open up too.
You are intentionally muddying the water by bringing code signing (a technicality) and devices for which software distribution was never part of the economics. Nevertheless, yes, I think making ebook readers tied to a single store illegal would be a net positive from consumers. It would let stores compete on their merits as stores and readers as readers. More competition is always good.
Pointedly, my argument is simple: the modern concept of plateform, as has been pushed by management consulting firms for the past two decades and successfully been exploited by hightech companies, is a blatant attack against anti competition laws and I believe the whole thing only started because the US government decided it would only meekly enforce them. Rebranding barriers to entry moats shouldn't make artificially building them more acceptable.
As you rightfully pointed, plateforms seem to be popping everywhere nowadays from game consoles to cars. I don't find that surprising: reducing competition is like crack cocaine to companies. It both means less need to innovate and differentiate and a larger share of customers surplus (theorically all customer surplus but it might be too blatant then). Customers are the ones losing there.
As the whole thing strongly goes against one of the core tenant of modern capitalism, it seems obvious to me it is going to end with more regulations as soon as the political zeitgeist regarding economy will lean less towards extrem laissez-faire. Unless of course, we decide to go full-bore towards nineteenth century style capitalism...
Yup. In the Mac OS security settings window, for "Allow apps downloaded from:", you can only choose "App Store" or "App Store and identified developers". The workflow is now:
1. Try to open the application. Get a window that says "APPLICATION can’t be opened because it is from an unidentified developer.", and below that, in a smaller and non-bold font, "Your security preferences allow installation of only apps from the App Store and identified developers." The window only has an "OK" button. (There is also a small "?" button in the lower left, which is present in lots of notification windows and presumably points to a generic help page.)
2. Open Security & Privacy in System Preferences. There is now, magically, a line in it saying "APPLICATION was blocked from opening because it is not from an identified developer", and an "Open Anyway" button.
I only discovered that workaround by accident. Before that, I believed that Mac OS had completely removed the option to run such applications. (As I recall, back when "Allow apps downloaded from: Anywhere" existed, if you did choose it, it would show some kind of warning and also revert itself after 30 days; it seemed obvious they wanted to remove the option entirely.)
I'm tempted to bring out the word "gaslighting" to describe this. Because that line about "Your security preferences allow ..." is in a context where it should be an explanation of why "APPLICATION can't be opened because it is from an unidentified developer", yet your security preferences about apps have only two choices and neither one would permit opening the application; and because a System Preferences pane now shows different options depending on what unrelated user applications you've opened recently, which is insane.
... Turns out there is a second, faster workaround. Right-click (or control-click) on the application, and click "Open". Then, instead of getting the liar window with only the "OK" button, you get a window that has an "Open Anyway" button. This workaround is, in fact, documented in the generic help page that the liar window's "?" button points to. This is also insane because it makes "Open" in its different forms (double-click, command-O, command-line "open", and the right-click "Open" option) no longer a single, uniform operation.
For the sake of argument, is there a limit to the number or kind of extra steps before you'd call it unusable? If "downloading VirtualBox and running a VM of an earlier MacOS version" became necessary at some point, would that be over the line?
I suspect there are corporate users who have policies that forbid running non-notarized software. That probably shouldn't apply to a game like Fortnite—most companies wouldn't consider it important, or perhaps even a positive, for their employees to be able to run Fortnite on their company laptops—but it would apply to other apps.
> For the sake of argument, is there a limit to the number or kind of extra steps before you'd call it unusable?
Surely this comes down to what reasonable expectations are held by the customer. There are microcontrollers you can buy that require a soldering iron and USB breakout board in order to run your own software on them. I think that's pretty reasonable, but it would be a ridiculous requirement for a desktop PC purchased at Best Buy.
The question becomes: what are the reasonable expectations for installing third-party software on an iPhone. Personally, I think the overwhelming majority of iPhone owners expect and even highly value the fact that Apple (supposedly [0]) vets all third-party software on the iPhone, and it's generally more difficult to accidentally install malware or break your device than it is on other computing platforms.
[0] As I've said before, I think Apple actually needs to be more restrictive, because a lot of useless/broken/scammy stuff makes it into the App Store.
Well, this subthread is about running non-notarized software on Macs. And my expectations on that, which I will proclaim to be reasonable, come from using Macs since before Apple notarization existed: i.e. I could run whatever I damn well wanted.
Apple changed behavior on that at least twice. (I skipped several Mac OS versions, so I may have missed intermediate changes.) First, it switched to requiring you to choose, in security preferences, an option to allow apps from anywhere—which, I think, would show a scary warning, and would also revert itself to the default after 30 days. Later, it switched to removing that "Anywhere" option, and instead shows a misleading "you can't open this because of your preferences" error, and provides a couple of insane hidden workarounds. I consider the first change reasonable, if unnecessarily annoying; I consider the second change unreasonable.
It's technically possible yes, but Epic's position is much much worse than that. They won't be able to legally build any app because the SDK is proprietary and only available to registered developers.
We actually have Nintendo to blame for this whole thing. They started the walled garden situation, and people seem oblivious to it and love them as a company.
> In a landmark ruling against Tengen in March of 1991, Judge Fern Smith stated that Nintendo had the right to “exclude others” from the NES if they so chose, thus providing the legal soil on which many more walled gardens would be tilled in the years to come.
Just wish these articles would address the amount of content and utility we get in exchange for our data (instead of our money) and speak to the trade-off. Until we find a better way to financially support all of the things we consume on the web, I'm not sure I see anything changing.
Whether or not this is in dispute, what you're doing here is injecting Trump and an inevitable culture war about him into a thread that's already likely to be contentious.
Unless Trump has specific relevance to this dispute, which I don't think he does, bringing him up is going to just add heat and fuel, not understanding. I think the mods would rather you didn't.
Anything he says about his wealth without also releasing his latest tax returns is up for debate. Whether the debate happens or not is a different question.
Does the requirement of viewing tax returns apply to anyone attempting to claim to be a billionaire or is there specific criteria for which to apply this extra safeguard?
A self-admitted[1] serial liar with a history of failed businesses would require extra scrutiny before anyone should trust their claim of being a billionaire.
Saying someone should show tax returns to run for a high office seems quite a different thing that saying that we should doubt someone's wealth unless they show tax returns.
Are we saying that running for political office is reason to require someone tax returns to prove a claim level of wealth?
I'd generalise a bit and say that anyone running for political office should show evidence for claims of fact, purely because supporting claims with evidence is a critical part of running a rational and informed society.
If you don't want to provide proof, don't make claims.
I see, thanks for clarifiication. Although even with released tax returns, he could have benevelontly committed fraud there as well, to increase his tax contributions. /s
I can believe it. I once worked at an investment bank where, during bonus time, I needed to deal with an issue at a trading desk. While there I had the following conversation with a particularly angry fixed income trader.
Me: Hey Trader, what's got you so pissed off?
Trader: Just got my bonus. I got 13MM, but Trader2 got 16MM! Can you believe it?! I made way more money than Trader2 this year!!!
Me: ...
His anger had nothing to do with total dollar amounts. It was only that someone he rates himself against made more.
To me, something also worth noting is that prior to the Duck Dynasty show, none of the people behind the company had their well known "bearded outdoorsman" looks. There's a widely circulated photo where they look like your average upper middle class suburbanite.
The point on the Democrats celebrity endorsement is true, but I'd argue that the GOP celebrities, including the Duck Dynasty people, are of the same vein and aren't the rural everyman they portray on the show.
I would actually argue that the opposite is true - that their previous personas were an act put on to meet social norms. They are certainly something of a caricature of themselves today, but is likely a lot closer to how they see themselves.
The amount of garbage Scala generates doesn't get enough airtime IMO. There are at least five instances I've been part of where an underperforming Scala component was rewritten in Java for significant performance improvements, mostly due to significant reductions in GC.
Not sure if this applies to their use case since they mention FIFO in the context of it being a simple eviction policy, but if you _require_ FIFO semantics then both Redis and memcached are out of the question since they use nondeterministic LRU policies (memcached's LRU is particularly egregious in its nondeterminism due to the way slab allocation works).
this is rarely a concern for things that are ephemeral in nature to begin with. it's also a 20 line code change to add a similar ttl buffer into memcached.
