And I actually do have evidence for my conspiracy theory: iDOS 2. Apple was perfectly fine with it up until someone in tech media posted a guide on how to run ancient versions of Windows on it, then they pulled the app.
Furthermore, "fingers shall not touch mouse apps" was a Jobs decree. It's specifically the reason why Apple got into touch UI. Jobs designed the iPad out of spite due to a friend of his who was on the Windows tablet team around the turn of the millennium. Jobs was so angry that they were just putting Windows on a tablet - and handing people styluses to work around the small touch targets on XP - that he made Apple design a tablet computer demo around finger-only UI. That was then grafted onto the Purple project (which at that point was a clickwheel iPod with a phone modem in it) and we got the iPhone.
So my suspicion is that Apple has an internal "things which make Jobs spin in his grave" list that they would never allow, come hell, high water, or the European Union's antitrust regulators.
That is amazing. I worked with a (different?) finance company that did the same thing - every team was judged on their burndown charts.
From what I saw, it did no good. Teams simply did not use tickets to track work. If a story surfed sprints, its “ticket” was closed at the end of one sprint and a new one was opened for next. If a priority bug came in mid-sprint, we simply worked on it without a ticket.
Careful, though, because you may encounter someone who can sniff out these tricks.
I worked at a place where, like many companies, tracked the bug burndown as one of the measures of project risk. So, the closer you got to the release, the fewer bugs were expected to be open. Having many bugs open early in the project was fine and encouraged. Having few bugs open towards the end was seen as On-track, and having many bugs open towards the end was a red flag, where the program might want to either step in and help organize things or at least raise the risk with higher management. This is a pretty standard scenario you get at a lot of software companies.
Well, one of the teams realized that if they just kept their bug count always at zero, they'd never be bothered by those nasty, annoying project managers. So that's what they did. They were constantly in crisis, fixing problems and committing code, but their bug counts always looked great. A trivial bug tracker query revealed what they were doing: They'd just keep a side bug tracker in a doc rather than filing them in the real tracker, and then seconds before committing the code, they'd quick create a bug and use that as the required bug in the commit message.
So, the following week, these "ninja bugs" were added to the automated reports, and that behavior ended quickly.
Strange… The finance company I work at also does this. And it’s so strange. I feel like they value Jira tickets more than actual work being done. It’s even funnier cause we get asked to close work when we want to go into prod and told to create new tickets to put our work in to prod. which kind of is annoying.
> If a story surfed sprints, its “ticket” was closed at the end of one sprint and a new one was opened for next.
LOL, just joined a team that seems to be doing exactly what you describe. You start attaching performance incentives to how tickets are estimated and closed... people are gonna game the fuck out of them.
I used to work somewhere that different bug severity levels were a KPI. One day after opening some prod/blocker/whatever level bug, I got a slack message from some useless agile coach arguing over it. After that, I created one kind of ticket in Jira. Fuck it. And when I talked to another senior engineer on another team it turns out they had the same experience and came to the same conclusion.
The operator chains remind me of RxJS. Which is great! I love reactive programming. But speaking as someone who spent two years teaching RxJS to a team of frontend newbies, the learning curve is brutal.
(Please do not reply with "I found RxJS easy". Good for you.)
I once used RxJS for a dev tool platform, we had a use case where we had to take a tree-like structure of user data and recursively resolve all the async nodes.
Took it to the RxJS discord after a couple days of pounding my head on it. One of the creators was there and was super helpful.
We went back and forth on the problem at least 6 times each, with new attempts. He tried quite a few variations, but none ever worked.
The team I was teaching struggled with the concept of streams and reactivity. It's kind of like programming backwards, especially if you're used to an imperative mindset. They just had a hard time with the concept of a stream.
They also had a tough time remembering all the operators in the library.
Hmm, I suppose I can see your point. When doing reactive things you have to think "what should this depend on". When doing imperative things you have to think "what depends on this that I need to remember to update". I always found reactive programming to be easier to reason about generally, but I suppose if someone's stuck in an imperative mindset it can be difficult to pick up reactivity.
Apple's lawyer states no such thing, only that they have the right to revoke anyone's developer account for any time and for any reason. They believe Epic will violate their rules in the future and affect iOS users' privacy and safety, so they banned them.
I know this is the internet, and no one actually reads the linked articles, but I really wish people would do so before weighing in. You did not need to make up a non-disparagement clause.
Hey, everyone! I wanted to see when people replied to my comments on here and none of the existing solutions were quite right for me. So, I made an extension that adds a little reply count to the top right of this site. Click it and you see a page with replies to your recent comments and submissions.
Works on Chrome, Firefox and Safari. Free for 14 days, then a $1.99 purchase to unlock forever. No subscriptions, ads or tracking of any kind.
Apple is good about only announcing real products you can buy. They don't do tech demos. It's always, "here's a problem. the new apple watch solves it. here're five other things the watch does. $399."
I agree that Apple does a better job, but wasn't Apple Vision Pro announced 240 days before you could get it? I think it's a pretty safe bet that Gemini 1.5 (or something better) will be available anyone who wants to use it in the next 240 days.
Apple aggressively keeps products under wraps before launch fires employees and vendors for leaking any sort of news to the press .
Also an hardware product that is miles ahead of competition in terms of components and also needs complex setup workflow (for head and eyes) something apple has not done before being 7-8 months after announcing is not really comparable with a SaaS API in terms of delays
Right? Even if you don't like Apple, a perfectly valid viewpoint, the Vision Pro is a huge deal. It should be on the homepage.
Also, if you don't like Apple... read the review! Nilay Patel has a lot of really good critiques of the headset. He concludes by basically saying he's not sold.
No need for making up new theories with no evidence, I think. They just don’t want to grant a third party JIT permission because of security concerns