←back to thread

669 points danso | 1 comments | | HN request time: 0s | source
Show context
coffeefirst ◴[] No.23261776[source]
"Our system broke, you're screwed now, sorry" is never an acceptable answer. Do they really not have anyone who knows how to get stuff done?

1. Take the files and figure out what to do with them so they can be read. This isn't a hard problem.

2. Ask everyone affected to email you the photo or a new photo of the documents. We'll just take it on trust that you do so honestly because there's no way you would've seen this coming.

replies(9): >>23262323 #>>23262343 #>>23262428 #>>23262479 #>>23262627 #>>23262802 #>>23263229 #>>23263339 #>>23263882 #
xienyc ◴[] No.23262428[source]
>"Our system broke, you're screwed now, sorry" is never an acceptable answer.

That's not what happened at all. The college board admitted their fault and are letting students take the test again. Even without that, they mentioned in their FAQ that JPEGs and PNGs are the only file types acceptable and even sent out a tweet (which should have been an email) a week before especially for iPhone users to let them know how to take pictures as JPEGs.

I agree with the people blaming the board for not having a standard image input field that lets the OS know when to convert images to JPEG but that is their only fault and I wouldn't have thought of that as a bug deal if not for this issue. While I'm all for open source media formats replacing what we have, HEIC certainly isn't big enough to be considered as among standard input options. Also, isn't Apple themselves infamous for not supporting certain formats throughout their devices?

replies(13): >>23262512 #>>23262557 #>>23262647 #>>23262683 #>>23262686 #>>23262913 #>>23263022 #>>23263295 #>>23264032 #>>23267061 #>>23267152 #>>23267311 #>>23268141 #
pwthornton ◴[] No.23262512[source]
If they had enough time to warn people ahead of time, they had plenty of time to push a fix to their system for this. We are literally talking about adding support for one more image format.

Emails, tweets, texts are no excuse for broken products. The iPhone is the best selling model in the United States. It is on College Board to support its default image format.

Good product design is owning your users' success. It is not sending people workaround emails.

The bare minimum would have to be to do a warning before every single AP test about this and giving students a few minutes to change their default image format. Sending a tweet (!!!) out does not count as doing any work.

This is a failure. An abysmal failure.

replies(14): >>23262634 #>>23262713 #>>23262885 #>>23262935 #>>23263736 #>>23263796 #>>23263816 #>>23263831 #>>23263848 #>>23263933 #>>23264038 #>>23264438 #>>23265745 #>>23265965 #
CoolGuySteve ◴[] No.23264438[source]
Even more strange is that when the file failed to parse after uploading, they just threw out the files instead of keeping them to analyze later.

If they still had the uploads they could go back and convert them properly and apologize for the delay.

It's just bad engineering all around. Even if there was a less glaringly obvious bug that caused parsing to fail, how would they debug that parsing bug without a sample file?

replies(1): >>23265229 #
root_axis ◴[] No.23265229[source]
I mean it's not that odd when you think about how software is typically written. The parsing logic probably threw an exception that was never handled and just pops everything uploaded off the stack by default.
replies(1): >>23269766 #
thaumasiotes ◴[] No.23269766{3}[source]
I'm not sure how you typically write software, but I don't consider it typical for software that opens a file and encounters unexpected input to throw an exception and then delete the file.

If an exception is thrown and not caught, the software should stop doing anything.

replies(1): >>23271956 #
root_axis ◴[] No.23271956{4}[source]
As I said, the file data was likely popped off the stack automatically, no need to write any extra code.
replies(1): >>23273688 #
thaumasiotes ◴[] No.23273688{5}[source]
In your model, what's happening to the data in the file system?
replies(3): >>23275286 #>>23275366 #>>23281294 #
root_axis ◴[] No.23275286{6}[source]
In the scenario I'm describing nothing is ever written to disk. The uploaded image data is streamed into memory directly from the socket and is processed in situ, when an exception occurs the stack unwinds and deallocates the memory storing the image data.

Writing extra code to delete a file in a catch block doesn't seem like something someone trying to account for failure scenarios would do, it's much more likely that the data was living in memory and no thought was put into failure scenarios in that part of the code.

replies(1): >>23279291 #
thaumasiotes ◴[] No.23279291{7}[source]
But it is incredibly unlikely that web uploads are piped directly into custom software rather than just being written as files which are processed later. That would be an extreme amount of extra work for no benefit at all.
replies(2): >>23281317 #>>23284779 #
1. root_axis ◴[] No.23284779{10}[source]
It's not at all unlikely, this is the default behavior for various setups, e.g. nodejs with express which is primarily a streams based system where you'd have to do extra work to write to disk.