I think this is broadly applicable to most, probably all stylized movie user interfaces. Minority Report, Tron and Star Trek come to mind. They look really cool on the big screen and are inspiring but once you get home and try to actually use something like it in real life for something productive and it's an impediment more than an inspiration.
She points out how she had to put on headphones just to cancel out some of the noise, which gives an indication of the environment. Also, this happened after over an hour of trying other solutions with a presumably impatient mob of players getting increasingly nervous. So, for sure the pressure was on.
In that light, I think it's a pretty impressive achievement.
I understand that literally millions get invested in various walled Microsoft, Apple, Google, and even Facebook gardens, not to mention McDonalds, Nintendo, etc. But that doesn't make the answer any clearer.
To organize an mtg event, you must use their shitty app, otherwise you cannot be an official tournament, and AFAIK are actually forbidden from calling it an MTG event alltogether. Supposedly this is the nintendo way of doing things where under cover of "quality assurance" and under threat of trademark litigation, you can enforce a very tight grip on your product ecosystem.
The longer answer is that as a judge, OOP has no control over the solution " chosen "by tournament organisers and the org has no control over the solution imposed on them by wotc. Wotc in turn has no incentive to improve their product for a lack of viable competition and here you are.
Its not even that WotC has no incentive to improve their program; its more that the people in charge there have actively made the decision to not have certain features because they've decided that the nebulous possibility of abuse is more harmful than the concrete need to have certain features in place in order to fix things. Though the last project manager quit (got fired, if the rumours I've heard are true) and I've had a very long meeting with some of the current guys and they seem very open to change.
There are definitely tournament organizers who do not care about this and will simply run on a different platform, but F2F is not one of them.
On a side I wonder why it is so hard to make event software like this. I looked at reimplementing a race manager used to track times for cars in Pinewood Derby rally for something akin to this, it take a lot of work to make it "usefull". Especially considering the index card solution mentioned for Swiss pairing seems to be such an easy concept when done manually.
The racing manager software was called DerbyNet, and works great for its purpose.
Some arbiters, particularly in the UK, still did this at least as of ten years ago. Either they don't want to learn the computerised tools or they think humans give "better" pairings - not impossible, as humans can look ahead to reserve some combinations for future rounds.
135 players is a lot to handle manually, though, and this would make the last round pairing system almost impossible. (Calculating tiebreaks for a handful of players in the prizes is OK).
More players did make the mechanics of manipulating the index cards harder: splitting into score groups, sorting each score group by rating, splitting each group in half and matching to make the preliminary pairings all would be more work the more players you had but those steps are all routine steps.
It was the next part, where you adjust the preliminary pairings to ensure things like not having anyone playing someone they already played (a requirement you must meet), having people play someone in their score group, alternating colors, not playing the same color three times in a row if you cannot give them alternating colors, and whatever other ones I've forgotten about where having a lot of players made it easier.
When you've got lots of players you'll have bigger score groups. If you have to shuffle some players in the pairings to get things to work out you've got a lot more room with a big score group to do such shuffles while still keeping the players involved playing in the right score group and close to the same position in their respective halves of the rating-sorted score group.
When the score groups are small you've got a lot less room to move within the score group to shuffle people.
The net result was that a larger tournament made the easy parts of pairings harder but made the hard parts easier so was a net win.
> In popular media, a genius hacker codes some solution from scratch in the space of an hour or two, solving a problem that would otherwise doom the other protagonists. But in reality, programming is slow.
I mean, sure, it's not like The Movies. But hacking is fast! In no other profession can you wake up, sit down at your keyboard, be presented with a new problem no one else has addressed before, and build a machine to solve it. All before dinner. That's just magic. Who else gets to do that? No other engineering profession for sure. Maybe some artists can work that fast, but they're shackled to ideas about the subjective value of their work to others whereas we can watch our creations do their magic with our own eyes.
It's the best job there is.
[1] Which is broadly the same point I just made here, but expressed as one anecdote. I'm saying that this is something we can all share.
Wrapped up the project 6 months later.
I don’t disagree with you, it really is magic what we can do with computers. Just doesn’t always work out like we think it will.
It’s not necessarily always obvious which one.
His famous quote was: "It was a weekend hack that got out of hand!" and with hindsight, that motto ruled the lives of many MUD hackers. Whether or not we stayed in college, for better or worse, we took on coding projects as weekend hacks, and they took over our lives!
You've never met that wizard with the machine shop, have you? He'd be insulted if you called him an engineer, but he eats engineers for breakfast.
Some of these guys "eat engineers for breakfast" but they still can't "wake up, ... be presented with a new problem no one else has addressed before, and build a machine to solve it, all before dinner." The timescale for solving novel problems just seems to be a lot longer. Even building a steam engine from a kit is a matter of weeks on a manual machine.
If you need a key copied, a lock pick ground from a street sweeper bristle, a transfer punch made from drill rod, or a weird left-hand screw with a strange thread pitch, they can probably do that before dinner, yeah. But that's because those are well-understood and fairly simple problems.
CNC machining opens up more possibilities, but the timescale is still longer. You don't want to find out your G-code is buggy by crashing a US$150k milling machine; crashing a mill is more like crashing a truck than crashing a computer. So machinists are generally methodical, patient, and careful.
But I really wish I had machine shop skills, as there is so much more you can do with a lathe, stamper, roller, and other equipment with basic input materials.
One of the chapters talks about Chuck's experience in his first job after graduating from college. He accepted a relatively low compensation offer at a machine tool manufacturer, on the condition that he would spend his first year sequentially shadowing every other employee. There's an anecdote about him being handed a power tool by a machinist and told to go ahead and cut metal on a several hundred thousand dollar linear rail (in 1950s dollars), and the boss running and screaming across the shop to stop him.
I thought it was a pretty cool story.
That's an incredible difference.
(also, for all the jokes we make about how (wonderfully) cheesy the depiction of tech in that film is, with all the smart homes these days I wonder if the hacked lighting at the ending would make more sense nowadays than back then)
(edit: also also, I recall reading somewhere that the creators of the film said they never tried to be fully accurate, they were going for "fairy tale about hacking subculture that communicates the vibe of the scene to non-nerds" and I while I was never part of it I would like to believe it succeeded pretty well in that regard)
Err, maybe the author hadn't experienced that before, but IMO that happens pretty frequently, even for projects that have been in production for years.
In addition to my (former) day job, one of my side projects is a live service with ~60k monthly users, and it has broken in prod multiple times.
For sure. Not dismissing the author’s achievement here, just noting that it does happen frequently in our industry.
P.S: I once had to fix something in prod during a demo of upcoming features to paying customers. Nothing like using Remote Desktop (yep not even SSH) into four servers to manually change a line in a bundled and minimised Nodejs app!
IME with a hotfix you have no choice but to fix it, no matter how long it takes.
Great article, though!
I need to remember that for the future: if you have a competitor, make sure you can absorb the traffic if they go completely AWOL.
And in one cases I even needed it then, because too many players showed up. Using a lame closed-source app causes always sweat, so I'm better well prepared.
https://github.com/search?q=swiss+tournament&type=repositori... => 667 results
https://github.com/JeffHoogland/pypair/blob/master/pypair.py uses the exact same format she needed.
The colours are analogous to factions in strategy games, or to the different heroes in Hearthstone, but with more flexibility to mix colours in a single deck.
* or colourless, or multicoloured combinations
