Thursday, September 11, 2008
Fantastic Microsoft Idiocy
This resulted in a familiar screen to frequent hibernate users to appear upon rebooting. It's the page of text that tells you that the last attempt to restore from hibernation failed, and asks if you want to continue with system restarting or delete the hibernate file and then start the system.
That's all fine and good. In cases like this, I usually want to try one more time to restore from hibernation (which works about 20% of the time), and when that fails, I just cut my losses, delete the hibernate file and continue.
The problem? This menu does not work, at all, if you have a USB keyboard. At first I thought it might be a problem with my KVM switch, so I took that out of the loop and connected my USB keyboard directly to the PC. No luck. Then I thought maybe there was a problem with my new USB keyboard, so I tried accessing the BIOS with it. That worked fine.
Fortunately I still had my old PS2 keyboard laying around, and I could plug it in to respond to that prompt. But anyone without a PS2 keyboard handy would be unable to boot into windows until they got one.
Somehow, Microsoft, one of the largest software companies in the world, with its thousands of engineers working on Windows XP, can't manage to make a simple menu work with standard USB keyboards. Idiots.
Postscript: It seems a number of others have gotten into this particular failure mode. A Google search for windows hibernate "restoration data" "usb keyboard" turns up a number of people experiencing the same problem, and mostly solving it the same way: by plugging in a PS/2 keyboard to respond to the menu.
Labels: microsoft, shitware, stupid, windows
Thursday, July 31, 2008
Mind-Boggling Idiocy
I placed the order with Dell last week, but today it looked like it was seriously stuck in the "in production" phase. What's there to 'produce' anyway? It's just a monitor. There's no customization needed. It just needs to go in a box. So I submitted a web request with Dell Customer Service, which included my name, customer number, order number, home address and so-on. I jokingly asked, "is it being assembled one pixel at a time?"
I got back an automated response telling me that the industry standard for stuck or dead pixels is 5 per screen, and that if I had that many or fewer, I'd just have to live with it. Or if that didn't answer my question, I could reply. I made the mistake of replying.
I say 'mistake' because Dell has outsourced customer service to semi-sentient balls of yarn in India, and what happened next was a colossal waste of my time. The one saving grace is that from a certain perspective, it is a funny waste of my time, especially when the conversation is condensed and all the email headers removed. I shall present the conversation to you now, replacing the Dell representative's name with the word "yarn."
Me: I didn't ask about stuck/dead pixels. I asked why it's taking so long to process my order for a non-customized piece of equipment.
Yarn: To protect your data privacy, we require a Dell identification number. This can be found on any communication you have received regarding this order. A Dell identification number can be an order number, customer number, service tag number, express service code number, case number, or DPS number. In order to resolve your concern I would request you to provide the name on the account as it appears on the original order documents. Please get back in touch with us once you have located this information and we will be glad to assist you.
Me: My name, customer number, order number and address are already in this email if only you would look. What more do you need?
Yarn: In order to resolve your concern I would request you to provide the complete name on the account as it appears on the original order documents.
Me: It's the same name that it's been in all of my emails: Nicklas Johnson.
Yarn: Your order number ######### is currently in production and has an estimated delivery date of 8/8/2008-8/12/2008. You can track the status of your order online by visiting
http://support.dell.com/
and entering your order number ######### and customer number ########.
Me: Yes, I already knew all of that. My question is: why is it stuck in the "in production" state for such a long time? It's been "in production" for almost a week. There's nothing to "produce" since the only thing in the order is a monitor. What takes so long?
Yarn: It is just an estimated delivery date, however, the order might be delivered to you before that also. Orders can be delayed for a variety of reasons.
Me: I appreciate that orders can be delayed for a variety of reasons. My question is, what is delaying MY order?
Yarn: Orders can be delayed for a variety of reasons. Please be informed that we will not be able to specify any particular reason.
Me: Who can?
Yarn: Orders can be delayed for a variety of reasons. Please be informed that we will not be able to specify any particular reason.
Me: You already said that. I asked "who can?" As in, "who can read my email and give me a constructive response that addresses my initial question?" or "who can tell me why it is taking such a large amount of time to fulfill a simple order for one item that requires absolutely no customization of any kind?" Who can investigate further and explain why this order is stuck? How do I contact that person or persons?
Yarn: I apologize you are experiencing this delay. Dell is making every effort to ship your order as soon as possible. The most current information we have is that your order number ######### should ship on or before the Estimated Delivery Date of 8/8/2008-8/12/2008.
(It is at this point that I gave up.)
Hey, Dell: you guys are assholes.
Labels: annoyances, assholes, hate, stupid
Tuesday, August 14, 2007
Keeping Simple Things Simple
For example: I want to read an image, make it smaller, and write it out as a JPG with a given quality. This is a fairly common and simple task. Here's the code:
BufferedImage sourceImage
try {
sourceImage = ImageIO.read(new ByteArrayInputStream(imageData));
} catch (IOException e) {
return new ServiceResult(ServiceResult.STATUS.FAIL_HARD,
"Unable to read image; image is unreadable or an unsupported type", e);
}
// figure out the target width and height
BufferedImage newImage = getScaledInstance(sourceImage, targetWidth, targetHeight, RenderingHints.VALUE_INTERPOLATION_BILINEAR, true);
ByteArrayOutputStream output = new ByteArrayOutputStream();
IteratorimageWritersByMIMEType = ImageIO.getImageWritersByMIMEType("image/jpeg");
if (imageWritersByMIMEType.hasNext()) {
ImageWriter writer = imageWritersByMIMEType.next();
writer.setOutput(new MemoryCacheImageOutputStream(output));
ImageWriteParam iwp = writer.getDefaultWriteParam();
iwp.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
iwp.setCompressionQuality(COMPRESSION_QUALITY);
IIOImage tmpImage = new IIOImage(newImage, null, null);
try {
writer.write(null, tmpImage, iwp);
} catch (IOException e) {
return new ServiceResult(ServiceResult.STATUS.FAIL_HARD, "Exception while creating jpeg content", e);
}
} else {
return new ServiceResult(ServiceResult.STATUS.FAIL_HARD, "Couldn't find a jpeg encoder!");
}
return new ServiceResult(ServiceResult.STATUS.OK, "Created avatar successfully", output.toByteArray());
So we had to use: BufferedImage, ImageIO, ByteArrayInputStream, ByteArrayOutputStream, Graphics2D (inside the getScaledInstance method), ImageWriter, ImageWriteParam, MemoryCacheImageOutputStream and IIOImage. (Not counting any java.lang, java.util or exception stuff.)
Why can't ImageIO read a byte array? (I can almost forgive the design decision to work mainly with streams.) Why does an ImageWriter need to write to a MemoryCacheImageOutputStream (an ordinary OutputStream won't do)? What's with ImageWriter#setOutput taking an Object? Do we really expect to have multiple image writers for a given MIME type such that we need an iterator? Why can't an ImageWriter write a BufferedImage? Why is there a getDefaultWriteParam, if that's the only WriteParam there is to get?
javax.imageio has got to be the absolutely most retarded API I have seen to date, with the closest runner-up being jTidy.
Labels: api, javax.imageio, overengineering, software, stupid
Subscribe to Posts [Atom]