Amusingly, that UI in the film is a real piece of Unix software named FSN on IRIX; I used it some around 1994 on Silicon Graphics hosts at Origin Games.
There's a version for OpenGL called fsv, and I made an updated version that works on a somewhat modern Linux system (Gtk+3, core OpenGL 3.x) at https://github.com/jabl/fsv
Yes, I remember that it became available after the movie.. and I tried it and found it completely useless in practice. I don't think a single programmer at our company liked it and it was soon forgotten.
Did anyone here get some use out of it? I seem to remember that part of the problem was that it didn't seem to work as well or efficiently as the movie showed it.
I did exactly the same thing and had a similar experience.
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.
As I mention in a sibling comment, I made an updated version that works on a modern Linux system (https://github.com/jabl/fsv ), but, uh, useful? Nope, it's a gimmick or a toy, not something you'd actually use to increase your productivity.
The level of pressure and requirements are so similar to coding interview challenges (if not more grueling - 14 hours?!) that not only should Elaine be certified as a level 3 judge, but she should also get a pass on the technical round of any future coding interview!
I agree. Initially I though the task was not _that_ hard but you've got to take the circumstances into account. This was not a homework task she was to solve in the serenity of her own home. Not was it pre-specified for her by a teacher trying to address the correct level of learning advancement. This was the real thing, on the fly.
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.
Right. I mean, in the original example I referenced in the title, the main character is just trying to find a particular file, which isn't that hard, but its pretty stressful if there's a dinosaur trying to kill you banging on the door.
I mean I was literally just thinking it would make a cool interview question, and then decided to maybe knock something up to see how it goes. Maybe it's just that I like thinking about playing magic again xD
I kept being distracted by the "why would anyone allow themselves to get so invested in a walled garden, especially one where the garden owner is so obviously hostile and non-responsive?"
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.
The short answer is that Wizards Of The Coast has an extremely tight grip on all Magic The Gathering events.
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.
The main value for Eventlink is that WotC tracks the playerbase of each tournament organizer and distributes promotional materials accordingly and awards higher status to larger organizers, so tournament organizers are heavily encouraged to use Eventlink so WotC can see the numbers.
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.
Because said walled gardens can provide a lot of value. They can still be worthwhile to use despite the hostility of the owner. It's a negative in the consideration but not an absolute dealbreaker for most people.
Ads, group think and social belonging/inclusion. That is just stating the obvious, but yes the problems of this event came from the issues you list.
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.
I was pretty into MTG when I was younger and had a very in-depth understanding of the rules (I could properly work out how layering work for example). I considered becoming a judge, but when I learned that they worked very long hours for free, I couldn’t understand why anyone would do it.
The standard way to pair Swiss tournaments in chess used to be index cards. One card per player. Each round, you write their opponent and their cumulative score, then you keep them sorted by score bucket and put them in pairs by trial and error trying to alternate colours and avoid successive upfloats.
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).
My recollection is that pairing Swiss tournaments manually actually got easier as the tournament got larger.
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.
I had to jump in here, not to argue with the substance of the article[1] but to pull out this one quote that I just can't get behind:
> 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.
I was faced with a problem like that. Heard the description of a task that a colleague was failing utterly to solve, figured I could knock out the bulk of it in a weekend.
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.
In 1989, a freshman in college, I was introduced to the world of TinyMUDs. The creator, Jim Aspnes, was at Carnegie-Mellon at the time; he whipped up a server codebase basically from scratch over a weekend, and spun it up on his desktop NeXTstation. Before he knew it, there were up to 64 concurrent players and the thing was eating all his physical RAM space.
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!
I watch MrPete222 on YouTube. He's certainly capable of whipping things up on the lathe on occasion without drawings, and he's no novice, but it's common for him to spend days or a week making a part that you could design in CAD in fifteen minutes. Same with Abom79, Stefan Gotteswinter, Joe Pieczynski, and Tom Lipton. Dan Gelbart is still using the spot welder he made in his youth 30 or 40 years ago.
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.
What in particular are you referring to that could have been designed on CAD in 15 minutes here?
Normally, whenever I have seen an Abom79 video doing something, it was some big-ass part that they were doing manually because either:
A) they were refurbishing something so they had to kind of cope with any non-idealities that arose
B) the part was very simple but was just a really big-ass part that really didn't fit well on anything so that had to kind of make it up as they went along.
Of course, it could just be that I don't really watch Abom79 videos unless it's about some big-ass part, so I could very well be biased.
Yes, quite commonly he spends several days making a part where he gives you all the dimensions and tolerances in three minutes at the beginning of the video, and the reason it takes several days is that if at any point he screws up, the part will obliterate him, his lathe, both, or his client, so he doesn't rush anything. And, yes, he spends a lot of his time coping with non-idealities. These are among the reasons that whipping up a quick Perl script is so much faster than whipping up a quick hydraulic cylinder.
I'm getting a taste for that since I got into 3D printing. Just type in some math formulas in a text editor, press a few more buttons, and all of a sudden I get a pivot-fence micro adjustable router table for my Dremel tool. Or I get a doo-hickey that holds a nut and washer, and can screw under my full sized router table to hold the nut in place so I can screw in various pivot-posts or other 3D-printed attachments on the top side. Or make a custom connector for something on my bicycle. Essentially I can fabricate products that just aren't purchasable.
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.
You may enjoy reading the non-fiction book, "Hot Tech, Cold Steel", by Chuck Hutchins. It's his story of starting a tech company on the forefront of CNC machining.
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.
Someone writes up an interesting story about a pretty neat achievement in developing a system under extreme time pressure of which they're understandably proud, and your response is to criticise a sentence from the introductory framing paragraph? To make the same point as the rest of the writeup?
Agreed, writing production-grade, user-facing software is slow, which is what we spend lots of our time on. On the other hand, writing small programs to automate boring stuff can be incredibly fast.
Lol. Well, Crash Override also had a group of friends as his wingmen. One that included Matthew Lillard. Probably didn't hurt.
(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)
> Surely, “just whip up a solution in an hour” doesn’t ever happen in reality.
>
> Right?
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.
I've definitely experienced this before! But, like, its dramatically different if you're physically in the space and there's visible pressure. Its not like I was at home dealing with a crisis where I could more easily block out everything. And coding from scratch is significantly more stressful, imo, than bug fixing.
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.
> But, like, its dramatically different if you're physically in the space and there's visible pressure
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!
Exactly! An unfortunate truth about running live and complex services is that they break frequently in strange and weird ways and we need to write a fix as quickly as possible, get it reviewed quickly and then roll it out asap. The term "hotfix" literally comes from that. The time range to develop and apply hotfix can be 30 mins to 48 hours--depends on nature of issue.
But how often can you say with confidence it will take 30 minutes? If the author was wrong about being able to do it in time, the players would waste their time waiting for a solution and eventually leave. It might be better to just tell the players to go home.
IME with a hotfix you have no choice but to fix it, no matter how long it takes.
Oh, the many faces of "DCI Reporter" not working well. Can't believe it's gotten worse since I was playing competitively, but then again, it's Bill Stark and Wizards of the Coast. I should have no problem believing it.
There are some good swiss pairing systems on GitHub, I had to use recently. Written in C, but it works as nice as the system she wrote. Would have saved her some sweat.
There's also one in typescript with very nice UI, but not completely Swiss, just some random swiss with extended constraints (girls prefering to play against girls, and such).
Fair point, but sometimes, especially with a deadline and a rough idea of how you're going to implement something, it's faster to code something yourself, warts and all, rather than sifting through Github to find ones that look good, cloning, installing dependencies, and checking that they have all the features you need, they work correctly, and that you won't need to familiarise yourself with someone else's codebase quickly enough to fix edge cases.
Well, when I faced a similar problem (organizing large table tennis tournaments) which exceeded the limit of the usual free android apps (max 10 players), I prepared beforehand these two apps.
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.
She was a judge, not the organiser, as far as I can tell, although it's great she was able to help, contingency planning is something more for the event organiser.
The contingency planning seemed to have been MTGMelee, with untested further contingency options of Challonge and YuGiOh!, all of which failed.
You were able to find one that looks like the format she needed, but what would you have done if it doesn't? Or if it's broken?
It takes time to review > 300 lines of code, and she was on the clock. Even if she is able to read 1 line per second, it would take her five minutes just to read through the code, without downloading it, running it, testing it.
I absolutely agree that there should be a review of the contingency planning, but having more confidence in your coding abilities than your ability to search Github effectively is not necessarily wrong.
Cool story! For anyone who has been in the competitive speech and debate community for a while (or has ever encountered tech trouble), this a similar thrill/challenge as hand-pairing rounds, keeping side constraints, pull-ups, etc. in mind.
In Magic, cards come in one of 5 colours* - white, blue, black, red, and green. Each colour has specific mechanics associated with it as well as a general play style. Magic players often have a preference for specific colours as a result.
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.
https://en.wikipedia.org/wiki/Fsn_(file_manager)