NOthingyoumissed

George Mauer is on the Net

QuickTime and a TIFF (Uncompressed) decompressor are needed to see this picture

Microsoft Office on a Mac can’t save imagesQuickTime and a TIFF (Uncompressed) decompressor are needed to see this picture

I have run into this problem a few times and I figured I’d blog about it both to vent my frustration and to make a note for the next time this comes back to haunt me.

So you get a shiny new Macintosh, you fire it up to discover that the friendly folks over at apple have pre-loaded it with the Mac version of Microsoft Office. Including Excel, PowerPoint, and your favorite word processor Microsoft Word! (Oh just admit it, you’ve never tried a different one.) So you fire it up and start pumping out document after document. It’s wonderful; you get the familiarity of MS Office with the slickness of a Mac. You format up your word file, place a nice logo or banner image as a header and you send it to your friends, or Wendy down in marketing, or even worse your boss. They are of course not enlightened like you; they’re still using that old bludgeon, a Windows PC. Oh well, at least you’ll get to brag to them later about your increased productivity and transcendent, almost religious, user experience. And then you get the call: “These pictures aren’t working!” they cry. You send them the file again – perhaps it got corrupted in email transit – but no, the problems persist. After half a day of this you are forced to trek over to the foolish nonce’s computer to witness for yourself how they are possibly managing to screw this simple process up. You make sure the files are identical – same checksum, no corruption and you open it up to see…to see:

“QuickTime and a TIFF (Uncompressed) decompressor are needed to see this picture.”

Huh? Excuse me? Where are your images? Does QuickTime suddenly have something to do with Word? Does the Word spelling dictionary even recognize ‘decompressor’ as a valid term? The answers are, in order: They’re there but invisible, it does on a Mac, and an emphatic no.

I don’t know if it was laziness, an evil marketing ploy, or what but it seems like the team responsible for the Mac version of MS Office used QuickTime image compression for storing some formats of embedded image files. The upshot of this is that those images are not visible on a PC, will never be visible on a PC, and you’re going to be left feeling frustrated, embarrassed, and probably a little violated. God forbid this was a powerpoint file.

The solutions to this quandary aren’t good. You basically have to either reinsert the images into the file on a PC or convert the images on the Mac to uncompressed bitmaps, re-insert them, and re-save the file with no compression. Needless to say this is awful programming. Really like mid-90s Windows 95 level bad. I actually would not be surprised if this WAS a dickish screw you to Mac users from somewhere deep in the Microsoft psyche (read marketing). Either that or they just didn’t feel like porting that part of the software properly. This has also been a problem for a long time with no effort by the powers that be for a resolution. Just when I was starting to think that Micro$oft ain’t all that bad. Sigh.

So in conclusion what’s the final word? Well there is one solution, and – you might have guessed it by now – it’s called Open Office. Presto! Now don’t you definitely feel better than that silly co-worker/boss of yours?

that are viewable on a PC?

Advertisements

May 12, 2008 Posted by | Album | 3 Comments

Oooh! I Wrote Something for Upper Management

Today I was asked to write up a short justification for a rewrite of a godawful piece of software that I have been complaining about to anyone who would listen.  Yay!  Inspired by essays I have been reading by Jim Shore I might have been a bit too agressive.  But here’s the final(?) version:

Proposal for a Rewrite of the {Program Name} Software
The purpose of software is to make our lives easier; it is a tool like a hammer or a screwdriver and far more malleable than either. This is generally a good thing as it allows us to mold it to our specific needs and particular processes. If software is a screwdriver meant to do screwdriver-type activities it should be with a minimal amount of effort that we can get it to work on a phillips or a flat-head screw. Unfortunately even screwdrivers can be poorly made, their handles can disintegrate as we apply too much torque, they can be made to poor standards so they don’t grip the screw quite right and slip frequently, and they can be made out of cheap material so that any attempts to remedy the above only compounds the problems as the shaft bends and warps in unexpected ways. Without taking the metaphor any further, it is my professional opinion that – external appearances aside – our current {Program Name} Software is this sort of unwieldy tool and in need of an urgent re-working.
Current Problems and Future Implications
The current implementation of our {Program Name} software has a multitude of problems. First and foremost, it seems to have been created as a prototype rather than a lasting project. As such, it is not meant to be extended to work in the ways that we need it to work. It is also not possible to use it with automated testing software to check the various contingencies we need it to work under and to ensure that future features do not break already existing ones. Without the ability to write automated self-tests, keeping the system operating across the conditions at the various terminals and feed company locations will continue to become more and more of a burden that will continue depleting our already low development time.
Furthermore, under the current system, when a bug is encountered, it is notoriously difficult to troubleshoot. For a problem at a site, our only recourse is to attempt to recreate it by simulating the conditions from user testimony. This is a painstaking and highly uncertain process. Take as example the multitudes of issues caused by poor network connectivity. The current system has no plan for dealing with short-term outages which, while inexistent when the software is developed in-house, are ever-present in the field. As such, it frequently ends up acting in bizarre ways that get reported infrequently and incompletely. Under these conditions they can be nearly impossible to repair. The software was simply not produced with the idea that it would require in-the-field maintenance and diagnosis; although expedient attempts to remedy this situation have been made, deep architectural flaws severely limit their possibilities.
The bottom line is that behind-the-scenes the {Program Name} is poorly designed and implemented. Much of the inner-workings are extremely confusing and no attempt has been made to consistently use established industry or even the developer’s own standards. There is no documentation anywhere. The problems are deep-rooted enough to need to be addressed immediately. In saying this I want to make it absolutely clear that in my opinion our difficulties arise not from the inescapable need to add features, but from the fact that the scope of the initial design completely omitted considerations of clarity, extensibility and in-the-field testing.
Proposed Changes
I propose a complete redesign of the {Program Name} system with an emphasis on the creation of a system that is simple, easy to maintain, extend, and troubleshoot. We will of course address all of our current needs but we will use established techniques to create software that works well with a model of continuous development. The new system would also be designed to streamline troubleshooting and include automatic self-testing to ensure that it is shipped out with as few bugs as possible. We will achieve this by sticking close to C# .NET best practices making the application truly object oriented, using Agile planning techniques and test-driven development, and optionally integrating with a dependency injection framework to ensure extensibility. While the changes experienced on the user side will be minimal, the payoff on the development and maintenance side will be almost immediate. I fully expect development time under a redesigned system to shrink by at least a factor of four, for new deployments to become seamless instead of taking days to configure properly, and for maintenance time to fall from over 5 hours per week to well under one. As a tentative schedule I would propose the following: Half a week of design (much of it has already been done), one to two weeks of implementation and a week of testing. I believe that by working on this project 80-90% of my time I should be able to finish it and have it ready to go in three to four weeks.

Thank You Very Much,
George Mauer
Software Developer

May 5, 2008 Posted by | Programming | , , | 1 Comment

Let’s try to start this nice and simple

So since I registered this blog name I have proven empirically that I am incapable of actually writing to it so I figure I’ll start simple – with a list.  And – because this is what i’ve been reading and thinking of a lot lately – its going to be programming related.  Weeee.   So here we go.

Technologies that I HAVE to learn:

  • NHibernate – The alt.net list, podcasts, and .NET blogs have been a buzz about this for so long that its barely even mentioned anymore, but yes, through argument and experience I’ve been convinced, dynamically generated SQL is the way to go.  Time to get a crackin’.
  • MbUnit – Apparently that’s what a lot of the pros use and I want to  be a pro right?  Well, I’ve got the basic [TestFixture] – [Test] – [RowTest] stuff down but guys like Phil Haack have to love it for more than just a few neat features and a nice GUI right?  How about reading the documentation?  Also, what the fuck is Gallilo and how come I can’t get it to run?
  • StructureMap or Castle Project – Inversion of Control / Dependency injection frameworks.  This is what you use if you want an extensible application.  And I do.
  • F# – A couple months ago, I realized that I kinda like programming in Javascript. Apparently, I’m not the only person that thinks so.. I guess it was because I was finally starting to get an understanding of what this functional programming thing is all about. And now that that I know, I like it!
  • And in a similar vein – JQuery. – Yeah, I’ve gotten some practice with this amazing toolbox in working with my personal site and The Roots Of Music and I think there’s something there. I want more, a lot more.
  • Git or Mercurial – Distributed Version Control Systems.  These seem to be the new thing in version control, no pressing need to switch from SVN, but I should start getting familiar with them.  It seems like for the time being, Mercurial is the shiznit.  Not sure if any of them have nice TortoiseSVN-style support though.
  • TypeMock – Commercial mocking software.  Type mocking is really just something that I need to learn about as I’ve run into the limits of non-mocking unit tests already.  I’ve heard this product is good in a few places and they have a good learning section the web-site as well as a free download version.  Could be worth trying it out.  As an alternative, we’ve also got Rhino Mocks which is free.

May 3, 2008 Posted by | Music, Programming | , , , | Leave a comment