In 15+ years of building and maintaining SWIFT-connected systems that run SWIFT-provided software, I’ve never encountered a situation where a SWIFT message has “just disappeared”.
CD ripping. Initial audio pass in an older version of EAC, which hands off to the scripts. Those validate the audio against the AccurateRip + CUETools databases and file the rip appropriately if there's a failure (e.g. "might be a different pressing" vs. "few enough bad samples to be repairable" vs. "completely aborted the rip", etc.). Then a second pass on the disc to extract subcode data and embed any TOC/subcode differences as comments in the cuesheet. Then, based on that, automatically generate a de-emphasized version for discs with the PRE flag set anywhere, then extract additional metadata (full release date, disc number, featured artists) from the title data I manually entered in EAC, compress to FLAC, embed the cuesheet, transcode .m4a copies, and file.
Automatically adding sort-artist fields to the cuesheet/.m4a files is next (I have a good source in the software that I use for cataloging the collection). I also need to write something that backports changes made to the tags in the .m4a files to the original cuesheet...
The pro-open-plan side is armed with hard numbers; cost-per-employee for one buildout vs. another is easy to measure up front. The anti-open-plan side has no way of generating the equivalent numbers for lost productivity and even their best attempts at estimating them (relying on studies, etc.) are vulnerable to being dismissed as "just guessing". Hard numbers win over soft numbers.
Uh, no. Bit-perfect ripping is trivial and routine, and tools like the AccurateRip DB (which has checksums for around three million different titles you can use to verify the checksums on your own rips) and the CUEtools database (which has recovery records you can use to correct bit errors on your own rips) prove it. I routinely get bit-accurate single-pass high-speed rips--no "paranoid" settings or re-reads--of discs dating back thirty years or more, and so do hundreds of thousands of other people. If you get different checksums on successive rips of the same CD, either the disc is damaged or the drive you're using is failing.
I saw this implemented at (I think) Times Square Tower a few years back. It had you enter your floor at a podium in the main lobby on the way to the elevators, and it worked beautifully. 49 floors and not once did I have to wait more than ten or 15 seconds for an elevator.
Then they retrofitted a similar system back at my corp HQ. It had you enter your floor on a screen on the wall right in the middle of the elevator lobby and it was (and is) kind of a pain in the ass...because when there's a crush of people waiting for the elevators, you can't get to the screen to enter your floor. When it was just the "up" and "down" buttons in the same location, the odds were pretty good that someone in the crush had already pushed the button you need, but...
(That's a serious question, BTW. I would check it myself but I can't upgrade to iOS5 until I figure out how to get Windows DEP to stop killing iTunes 10.5 every time I launch it.)
The search bar is ridiculously large, especially given how rarely I suspect most folks actually run searches against their calendar. I'm sure some people are doing it constantly but if I've even done it once I'd be surprised.
There's an awful lot of unused horizontal space in that black bar. Seems like a good location for a search box.
Most web discussion boards are just GUI on top of a message store, and the reading/posting pieces of NNTP are a stable, standardized API for interacting with just such a message store. If every VBulletin instance also exposed an NNTP interface to its message content, I think it would be a huge step forward for discussion-board usability. (Well, once the NNTP-client world woke back up again. Are there even any actively-developed NNTP clients left that aren't focused on guzzling pirated media from the .binaries. groups?)
Unless you've actually used a decent newsreader like trn, It's difficult to appreciate just how much we've given up by moving most online discussions to the web. Loss of threaded discussions isn't the worst of it -- many of the web-based discussion boards I frequent don't even properly track which messages you've actually read, using a vague "last time you visited" heuristic instead.
I miss being able to catch up on all my discussion topics using almost nothing except the space bar.
That's a huge assumption that I doubt very much will survive the EULA you'd need to agree to in order to use iTunes Match. It seems unlikely that the labels have licensed Apple to run the world's biggest pirated-music-laundering service.
The vast majority of the articles I add to Instapaper, I add from Firefox on my desktop at work. And virtually all the articles I read in Instapaper, I read when I'm off-network completely (I have an iPod touch). I don't think Marco has much to worry about yet.
People have actually paid me to do editing (the fools!), and I know the standard proofreading marks backwards and forwards, but I still didn't read the graphic on the key as "delete". I might have been able to suss it out if you told me it was supposed to represent an editing mark but looking at it absolutely cold? No way.
The person who designed the keycap probably had to cobble it together from a set of standard characters/symbols. If they'd used a more freehand representation, like the one shown on the 6110344 layout further down the page, it would have been immediately obvious.
