Jun 282008
 

Since ALA seems to shutdown around noon so folks can go and get some lunch, I decided to try my hand at getting a little run in before heading back.  I’ve tried running in California before (mostly San Francisco), and the number of people and cars always foil me.  I’m use to my afternoon runs in Corvallis where I run on the backroads around the university without having to deal with a single stop light or my 5-6 mile run in Independence where I might cross a single person on my jogging path. 

Anyway, I dug out google maps and mapped out a 3.2 mile trek around Disneyland.  Looking at the outlay of the roads, it appeared to have the fewest number of intersections.  I figured, run it today and if it looks promising, running twice tomorrow morning.  Well, it wasn’t bad.  About 1/2 was uninterrupted save for dodging people — the other 1/2 had a few stops — about 6.  That’s still more than I’d prefer, but not bad for the number of people in this general area — so I think that I’ll definitely loop it twice tomorrow.  Of course, I’ll run earlier tomorrow — maybe 6 – 6:30.  The weather isn’t bad here — but again, I’ve been running in weather closer to 70’s — I don’t think it’s that much hotter here but the air just feels heavy.  Hopefully, running in the morning will be better.

–TR

 Posted by at 1:11 pm

MarcEdit 5.x update

 MarcEdit  Comments Off
Jun 262008
 

I’ve made a few updates that fix a few things with the MARCEngine COM object as well as the Tab Delimited wizard.  The big changes are to the MarcEngine.  I’m slowly starting to roll a few changes into the application that will eventually be used for UniMARC conversions.  Also, I’ve made some changes to the default XSLT files to accommodate some of those changes as well.

You can download from: http://oregonstate.edu/~reeset/marcedit/software/development/MarcEdit51_Setup.exe

 

–TR

 Posted by at 11:12 pm
Jun 132008
 

The pictures say it all right?  We decided to have a little fun before father’s day.  We’ll see how long our new hair cuts last (though, I’ll probably keep my at least for one day of work) :)  But it was a lot of fun cutting them.  :)

 

–TR

 

100_0667

 

100_0669

I always close my eyes when there is a flash. :)

 

100_0673

 Posted by at 9:29 pm
Jun 032008
 

Took a little longer than I thought it would, but I’ve uploaded a new version of MarcEdit that corrects the parsing error.  It took a little longer partly because the problem only occurred when dealing with 15 characters.  Also, I’ve added a new way of rendering the MarcEditor.  When rendering large Unicode files, the loading process gets lengthy.  I’ve updated the process so that loading files 10 mb or smaller will be much faster.  Larger files are still problematic (when dealing with multiple charactersets), but I thinking I’ve found a way to start speeding the process up.  So I’ll be spending the next week or so working this out.

Download locations:

Anyway, I wanted to thank Karin Zwiesler for the bug report. 

–TR

 Posted by at 12:55 am
Jun 022008
 

The people at Nintendo must be geniuses, because their most recent “game”, the Wii Fit, shows off everything that is cool about their console.  I have a Wii — we got it for the boys (ha!) and I love the game play.  I love the simplified controllers, the interactive nature of the games — and I love that my boys (3 and 6) and pretty much pick up a game and start playing right way.

So, it was without reservation that we got the Wii Fit.  I’ll admit, I figured it would mostly be a novelty.  Something to play — but wouldn’t really be much of a workout.  I mean, come on.  It’s a video game and I’m pretty fit to begin with.  As most know, I cycle a lot (~50 miles daily), run (3-5 miles daily) and lift weights as part of my normal fitness routine.  So, I looked at this as something that would be just fun to play.  And, well, it is fun to play.  However, I’m also finding that it really can be used as a fitness tool as well.

So the Good:

First, it’s just plain fun.  The Wii Fit breaks down its “games” into areas of fitness.  There is Yoga (which primarily measures balance), Strength training (pushups, squats, plank, etc) which measure balance, rhythm, etc., Aerobic (these games are fun — Hula hoop, basic step, jogging, rhythm boxing, etc) and finally, Balance (with games like Slalom skiing and snowboarding).  The games are really entertaining and I love the way that the Wii Fit uses balance measurements for the Yoga and Strength training.  I’ve been finding that the Strength training exercises can be a great compliment to my normal weigh training — as the Wii is more resistance (gravity) rather than heavy weights and it’s use of balance tends to force proper positioning. 

As you play the games, you get rated on how you do.  As you do better, it unlocks more games, allows you to play at more advanced levels, etc.  It’s fun — and has kept me coming back.  I’ve only had it since Saturday and have already found that I’ve spent about 2 hours using it and really enjoying it.  Anyway, as you play, it tells you if you are doing well or not.  One thing I love about the Wii — when you lose, it tells you that you’ve lost.  If you’re form wasn’t good or your balance was off — it tells you.  Good stuff.

The Hilarious

While some people might not find this as funny, I got a kick out of the way it determines fitness.  The Wii Fit makes an attempt to measure fitness level, and does so by using the BMI (Body Mass Indicator).  For about 85-90% of the population over the age of 12, this is a pretty good measurement for giving you general fitness.  Basically, the BMI is a simplified formula that measures Weight and Height.  For kids under 12 and people that are generally muscular, the BMI is notoriously inaccurate.  And for some, this has been the one consistent complain that I’ve heard about the Wii Fit so far — that is that kids are being many times improperly classified as overweight or obese by the game.  Fortunately, that hasn’t been the experience that we’ve had with our kids.  Both Nathan and Kenny’s scores were realistic.  The only person whose results were skewed were mine.  On the Wii Fit, my little character is a dough boy (and I’ve got to tell you, Kenny thinks that this is just the funniest thing he’s ever seen) probably because I have a more muscular rather than skinny frame.  It’s actually too bad that the folks at Nintendo didn’t include a way to utilize the U.S. Navy’s BMI settings.  Essentially, the Navy uses Height, Weight, and then measurements around the Neck and waist to calculate BMI.  It might have blunted some of this early criticism about it’s use of the BMI — but I don’t think that it should stop anyone from using the game.  You can actually just not use the body tests if you find that this calculation is inaccurate.

The bad

From my perspective, I’ve yet to find any downsides.  I really like the thing, warts and all.

 

–TR

 Posted by at 11:03 am
Jun 022008
 

*Updated:*  Did a little more testing and this problem is related to characters not in the MARC8 character map (those broken in the MARC8 mnemonic that look like, for example: {88} or {89}.  These will translate to ? on the way back rather than keeping this character.  So, for most folks, you’d never see this problem — but if you are working with UniMARC (where encodings vary — you will.  As I say, will have this fixed this evening.

Call this an oops.  In trying to make sure that the marcengine could guess the users intent for character encoding (even when the user may have passed incorrect values), I created a bug.  For Unicode data — there isn’t a problem.  For data that isn’t unicode, there is. 

So, I’ve temporarily removed the files for both the MarcEdit executable (last night’s builds) and the Runtimes file.  I’m guessing I’ll post and update sometime around 7 pm my time (I’d do it earlier, but I keep my dev. files at home) or so. 

Anyway — sorry about that.  I should have made sure I tested over a much larger swath of files (i.e., not just unicode data). 

 

–TR

 Posted by at 9:41 am

MarcEdit 5.x Update

 MarcEdit  Comments Off
Jun 012008
 

I’ve been doing a little bit of MarcEdit work, refining a few of the function to try to make the program a little smarter when it comes to doing what users are actually wanting to do, rather than what they are asking to do.  One case in point — if a user has a set of MARC record that they want to work with in UTF8, the preferred workflow is to do the following:
* If the file is in MARC8, then running the file through the MarcBreaker, selecting the UTF8 option.  This translates the data into UTF8.  At this point, users can edit the records in the MarcEditor and then simply compile the data (once translated to UTF8, you never have to tell it to do that again.  MarcEdit actually deals with all data in UTF8, MARC8 is only supported as a legacy format) back to MARC.  This can be done from the MarcEditor, or by selecting the MarcMaker and simply compiling the data file (which out checking either the MARC8 or UTF8 options).

What I’ve run into lately is some questions by folks that have been running into problems with UTF8 encoded data due to the way that they are remaking the records.  A handful of users have been Breaking the records (using the UTF8 switch) and then remaking the records (using the UTF8 switch).  This is problematic in MarcEdit, because the assumption made when you check the UTF8 switch from the MarcMaker is that data is *not* in UTF8 so it treats the data as non-UTF8 data.  This flattens UTF8 data (if it is present).  However, that’s obviously not the user’s intent.  So, I’ve added some code that will essentially checks filestreams to see if what the user has asked the program to do is actually what they want to do.  In this case, if a user has a UTF8 encoded file and then checks UTF8 during the Making process — the program will do a cursory check of the data before making assumptions about the data being processed. 

One additional note on this — as noted above, MarcEdit does not assume MARC8.  So, if your data is in UTF8, there is no need to select the UTF8 switch.  These conversion switches really should only be selected if you have data in one format and you want to convert it to another.  For example, if you have data in MARC8 and you want to convert it to UTF8, then select the UTF8 switch.  If you have data in UTF8, but would like to have it converted to MARC8 — then select the MARC8 switch.  If you have data in another format (like Big 5, etc.) then you want to use the MarcEdit Character Conversion tool to translate the data to UTF8, MARC8 or another character encoding.

Other updates…One biggy was some modifications to the Z39.50 client.  I’d made some changes previously that allowed you to edit records directly using Z39.50’s extended services.  I’ve done a bit more work here so now you realistically could use MarcEdit as a cataloging client for something like Koha, a Zebra Server, etc.  Any server that supports the Extended Services should be able to utilize MarcEdit as a cataloging client for direct record maintenance.

OAI Harvesting  — I’ve added some failback processing to help work with OAI servers that are may break their connections during harvest.

Obviously, other changes have been made (a few related to the installer when dealing with 64 bit versions of Vista). 

Download Files:

 

–TR

 Posted by at 11:12 pm
Jun 012008
 

For those using this — I’ve figured out how to get the Access connection to behave better, so now if you will be able to extract as many records as you need to edit and expect all updates to occur.  Prior, the plug-in would occasionally error out and an handful of records wouldn’t get changed in the Connexion file.  This is fixed.  To update the Plugin — open the plugin manager, delete the old Connexion plugin, then close MarcEdit.  Next, open MarcEdit, go to the plugin manager and download the updated version of the library.  Restart MarcEdit — you are now using the current version of the plugin.

Source files for those interested: http://oregonstate.edu/~reeset/marcedit/software/development/plugins/source/oclc_helper.zip

 

–TR

 Posted by at 11:04 pm