Stimulating Pixels

Even though I do a ton of work with XML files, I don’t use actual XML Schema documents very often. It seems like this is the case with most people who work with XML files. After spending some time working with schemas, it’s not hard to see why. They are tedious and it is very easy to get by without having to use them. In day-to-day operation, they offer very little value. Especially considering the language is dense to start with and bulky to work with.

One plays where Schemas are very valuable is in testing software while it’s still in development or when a change is being put in place. The language has a lot of potential for catching little errors that would otherwise be missed in high level test suites.

The impression I get is that a lot of other folks are running XML without really worrying about created Schemas. One of the main reasons is that I had to search for a couple hours to find a good command line tool that validates an XML document against a schema. The one I found and have so far been pleased with is Sun’s “Multi-Schema XML Validator” known as “msv”. The most recent version can be downloaded here. Note, if you are using a Mac with it’s standard Java install, the latest version won’t work out of the gate. Instead you can use the older version which is available here as msv.zip.

The core of msv is stored in a .jar file that is included with the zip. To run msv, the command would be something like:

java -jar /path/to/msv.jar /path/to/schema.xsd /path/to/doc.xml

If the XML doc is valid, you’ll see a message like:

start parsing a grammar.

validating /path/to/doc.xml

the document is valid.

If there is an error, msv will report it and let you know what’s wrong. Sometimes these can be a little cryptic, but when they are, they have enough info to get you started in the right direction.

If you have ever formatted a compact flash card that had photos on it you still needed, the first thing to do is make sure you don’t mess with the card at all. Then,  check out PhotoRec. An open source tool that tries to recover photos that have been deleted. It’s a bit cryptic to use, but there is a step-by-step procedure in the documentation that’ll walk you thru it. I’ve used it once with success to help get photos off a friends card.

If things get corrupted, there is also TestDisk, which is bundled with PhotoRec. I haven’t used it, but it’s worth a shot if you run into real issues with a card.

Other than being Free Open Source Software, these apps have the added bonus of being available on multiple operating systems including Mac and Windows.

On Macs, there are two great hot-key combinations that can be used for doing screen captures.

• command + shift + 3 = full screen capture
• command + shift + 4 = a partial screen capture based on a box you draw.

By default, when you make a grab with these commands the output files are saved directly to your desktop. If you have a messy desktop, they can be hard to find. Using a little command line magic, you can change this output location to any directory you choose. The command itself is:

defaults write com.apple.screencapture location /output/path/directory

You would just need to change “/output/path/directory” to the location where you want the screen grabs to go.

I got found this command on this page from the Mac Developer Tips site. Just putting it here so that I can find it easier in case I ever need it again.

I work on Mac, Linux and Windows machines during the course of an average day. A lot of this work is done on the command line. Since underneath a Mac is the heart of a Linux type machine, the basic commands that work on one also work on the other. Windows machines are a different story. Lots of commands that work on Mac/Linux are different on Windows machines or simply don’t exist at all.

For example, when you want to see what’s in a directory from the command line the Mac/Linux command is “ls”, but on Windows, it’s “dir”. Since most of my time is spent with Mac/Linux I end up trying to use “ls” frequently when I’m working on a Windows machine. This doesn’t hurt anything, but it doesn’t work and it is a little break in the concentration.

The good news is that since most of the command line tools on a Linux machine are open source, they can be ported to different operating systems. This is exactly what was done with the Open Source project UnxUtils. It’s a collection of most of the key command line tools Linux folks are used to working with. If you spend most of your time on Mac/Linux but have to bounce around the Windows command line on occasion, I highly recommend them.

Doing a little Java development on the Mac. Just making a note to myself about XOM (an XML Object Model). According to the web site, “XOM™ is a new XML object model. It is an open source (LGPL), tree-based API for processing XML with Java that strives for correctness, simplicity, and performance, in that order.”, and “XOM is designed to be easy to learn and easy to use. It works very straight-forwardly, and has a very shallow learning curve. Assuming you’re already familiar with XML, you should be able to get up and running with XOM very quickly.”

Sounds worthy of looking into.

From a higher perspective, in order to utilize XOM the xom-1.2.1.jar file (which can be downloaded from the XOM page), must be added to the Java class path. On Macs, one possible location for this is ‘/Library/Java/Extensions/’.

I’ve added one more piece of software to my Mac’s Toolbox: Max from http://sbooth.org/. Max is CD ripping and encoding software. For the technically minded, it’s really a front end to other process like ‘LAME‘ and ‘cdparanoia‘. To the person using it though, all you see is Max.

While iTunes has ripping and encoding functionality built in, I’m not confident that it’s producing the quality of MP3s that I’m looking for. When I’m ripping my CDs I only want to do it one time and be sure the MP3s are the highest quality I’m like to ever want. On Windows, I used Exact Audio Copy. The goal of that software is to produce MP3s that your general audiophile would find indistinguishable from the original CD. Since EAC is Windows only, I was very happy to find Max which looks to be a nice Mac replacement.

A quick note about cdparanoia, the ripper that Max uses. It’s really good at dealing with scratched CDs. Unless you go after a disk with 60 grit sandpaper, cdparanoia can usually fight through it to ensure the ripped version of the song matches the CD. In addition to ensuring the final MP3 is as close to the CD as possible, this also helps prevent those weird digital garbles that pop up in MP3s from time to time. The trade off for this insurance is that ripping a scratched up CD can be very, very slow. Like I said before, I’m more interested in only have to go through the process once, so I don’t mind that might take longer to get the track into the computer if it means I don’t have to go back and repeat the process later.

I’m still in the process of deciding what software to use on my machine since my transition back to using a Mac. Today, I installed “ecto“, a desktop/offline blog editor. If you blog and you haven’t tried this type of software, you really should. As nice as the browser editors in blogging software has gotten, the desktop experience for creating blog posts is a even better.

A few of the high points:

• You don’t have to be online.
  Posts are created and edited “locally” on your computer with no need for an internet connection. While you could do this type of offline editing with a word processor that would mean having to jump through additional hoops later. With software like ecto, you simply hit a “Publish” button when you have a connection and are ready to send the post to your blog.
• Software on your computer move faster.
  Browser based editors are decently fast but they have to communicate with a remote server which causes latency. These delays are usually minimal, but compared to software that is running directly on your computer it’s a dramatic difference.

• Software on your computer behaves better.
  The online edit pages for blogs try their best to prevent you from doing stupid things, but they are limited by the the functionality that’s built into the browser they are running in. It’s all too easy to select and delete text that you can’t get back via “Undo” or to navigate away from a page and loose an entire post. The safeguards protecting you from yourself from this kind of behavior are more robust when using local software. They can’t entirely prevent you from doing something stupid and loosing a bunch of work, but they are better at preventing it.

While there are other advantages, those are the main ones I’ve in the short time I’ve been using desktop blogging software.

Ecto is the second piece of desktop blogging software I’m trying out. The first one was “Mars Edit“. The biggest difference right off the back is that ecto has a What-You-See-Is-What-You-Get edit window. Mars Edit is a basically an HTML editor. While I’m a geek and can easily move around in code, when I’m making blog posts I much prefer a W.Y.S.I.W.Y.G. editor.

Writing and thinking about code are two different mental modes. Even if you are really good at both, having to switch gears imposes a state change cost on your mental processing. It’s a great way to break concentration and kill a thought before you get it out.

Both Ecto and Mars Edit are commercial pieces of software which cost $19.95 and $29.95, respectively. While I’m a huge fan of Free and Open Source Software, I’ve got no problem paying a reasonable price for good software. Especially when there isn’t a viable Open Source alternative. Just based on the W.Y.S.I.W.Y.G editor in ecto, I’m probably going to purchase it after the trail expires. It’s well worth $20 to gain the benefits of as desktop blog editor.