After having a BlackBerry for about three years and loving it for work email, calendar, contacts, etc, I recently decided to make a switch and picked up the HTC DROID Eris for Verizon.  I'm a big fan of most things Google, so I knew I would love this device.  I won't go into the details of why or give my own review, but I did want to touch on one thing that really frustrated me.

I have a Google Voice account, which I also love.  It no longer matters if I switch phones or don't get service.  I have one number, and I can set it up to ring anywhere.  Plain and simple.  The downside was not having my Google Voice number show up on peoples' caller ids.  Not a big deal, but irritating.  Enter the Google Voice app (available on many platforms).

When I first installed the app (version 0.2.7) it worked great.  I could make calls from my Eris and people would see my GV number instead of my Verizon number.  After an updated 0.2.8 was released, suddenly, I was receiving, "network busy" or "network unavailable" messages and I couldn't make any calls.

Sure I could browse to the GV webpage and initiate calls from there, have GV call me on my device, then connect the call, but what a huge pain.  After no responses from a Google rep on a thread in the GV help forum, someone figured out that the app was putting a + in front of the bridge number, which was causing the call to fail.

With no way to configure this and still no response, it seemed unlikely that I'd be able to use GV on my device any time soon.  Someone else finally mentioned that there is a way to remove the extra + in front of the number: clear the dialer app data.

Menu -> Settings -> Applications -> Dialer -> Clear Data

Simple as that.  Periodically, I find the app resorts to adding the + in front of the number, but clearing the dialer app data seems to fix it each time.  While this is only a workaround, and hopefully Google will fix this in a near-future release, I am able to use my Google Voice number again, and it works great!

I have been using Windows 7 64-bit since its official release in October and have loved everything about it so far.  I was surprised at first when my PDFs weren't getting indexed, but was happy to know that it took very little work to get it to index them in just a few easy steps.

1. Verify that PDF files are selected for indexing
   
   • Open the Indexing Options by clicking Start and typing, "indexing options" (without the quotes) and hitting enter
   • Click the Advanced button
   • Select the File Types tab
   • Scroll down to .pdf, which should already be selected, but probably says, "Registered IFilter not found"
     
2. Download and install the Adobe PDF iFilter 9 for 64-bit platforms

That's it!  You may need to rebuild the index (click click the Rebuild button in the Indexing Options), but afterwards, you should be able to search on PDF content.  32-bit users should be able to index PDFs out of the box.

In working more and more on our Digital Asset Management initiatives, I've become more involved in working with XMP.  Mostly as an experiment, I wanted to see if I could read and write this embedded metadata from and to a file.  The Adobe XMP Toolkit indicates how this can be done based on the structure of specific types of files.  It also indicates that packet scanning techniques can be used when file structure is unknown, however, is not encouraged. 

I recognize it might not be the BEST way to read the XMP packet, however, all is fair in love and ColdFusion experimentation :)  It's important to note that this code looks only for the FIRST instance of the string <x:xmpmeta and if there are multiple instances of XMP packets, subsequent instances are ignored.  Adobe also indicates that if there are multiple packets, there is no way to know which packet is the correct one.

Needless to say, using the code below, I was able to read and parse XMP packets from all the Adobe sample files included in their toolkit.  It may not be the end-all solution, and may not work for writing back to the file, but it's a start!

<cfparam name="URL.source" default="xmp-asset.jpg">
<cffile action="readbinary" file="#ExpandPath(URL.source)#" variable="data">
<!--- encode the binary data to hex --->
<cfset hex_data = BinaryEncode(data,"hex") />
<!--- string indicating beginning of packet '<x:xmpmeta' --->
<cfset xmp_string_begin = "3C783A786D706D657461" />
<!--- string indicating end of packet '</x:xmpmeta>' --->
<cfset xmp_string_end = "3C2F783A786D706D6574613E" />
<!--- find the starting index in the hex string --->
<cfset idx_start = FindNoCase(xmp_string_begin,hex_data) />
<!--- find the ending index in the hex string --->
<cfset idx_end = FindNoCase(xmp_string_end,hex_data,idx_start) + Len(xmp_string_end) />
<!--- using the start and end indices, extract the xmp packet --->
<cfset xmp_hex = Mid(hex_data,idx_start,Evaluate(idx_end-idx_start)) />
<!--- convert the hex to readable characters --->
<cfset xmp_string = ToString(BinaryDecode(xmp_hex,"hex")) />
<!--- parse the xml string to and xml structure --->
<cfset xmp_xml = XmlParse(xmp_string) />
<cfcontent type="text/xml">
<cfoutput>#xmp_string#</cfoutput>

Be sure to check out the Adobe XMP Developer Center for more information.

Having been very intrigued by the experiments of Johnny Lee using the Nintendo Wii remote, I decided to give one of them a try.  I decided the experiment that would be most useful to me was the interactive whiteboard.

Following several instructions by different people online to build an infrared LED pen, I went to Radio Shack, spent about $10, and had a (somewhat) working version after about 5 hours worth of work.  Had I known what I was doing, it should have only taken me about an hour, if that.

The first problems I ran into were due to a lack of understanding of some fundamental principles of electricity.  Initially, I was using a battery housing that holds 3 AAA batteries (thinking that much power was needed) end-to-end outputting 4.5 volts (1.5 volts each).  Each IR LED I used to complete the circuit ended up overloaded and burned out.  Finally, with some advice from my father with a background in electricity, I learned that keeping the positive and negative ends of the batteries separated (laying them side-by-side instead of end-to-end), I could increase the output without increasing the voltage.  Thereby powering the IR LED without burning it out.

That hurdle overcome, I started discovering that sometimes the IR LED was getting power, and sometimes it wasn't.  Had I done some more research online, I could have saved myself a couple hours.  I finally learned that with LEDs, polarity matters.  In other words, the positive and negative charges had to be correctly paired with the tips of the LED.  So, the cathode tip of the LED must be matched up with the positive charge of the battery.  After discovering this, I learned that one AAA battery provided sufficient power for the LED, which made construction of my circuit much easier.

Finally, the last major problem I had was reading.  Yes, reading the packaging on wire I bought to connect the components in the circuit.  Had I read the package, I would have seen that the wire I bought was covered in a protective coating.  So in order for it to conduct the electricity of the circuit, I had to scrape the coating off the tips to make a good contact with the battery and LED and other components.

Back to one of my earlier statements; I had it (somewhat) working.  Was my IR LED pen able to "transmit" data to my Wiimote?  Yes.  Was it consistent?  Somewhat.  Was it as easy to use as a real whiteboard?  No.  It was quite difficult for me to find a position for my Wiimote where it could "see" the IR beam or reflection.  This led me to believe that either the IR LED I purchased wasn't providing sufficient light to be seen by the Wiimote or that something about the circuit I constructed wasn't optimal.  Either way, not being knowledgeable enough about the Wiimote's capabilities, the electrical circuit I was attempting to construct, or the properties and capabilities of the IR LED with which I was working, I just wasn't getting the expected results.

I decided that for my experiment I was at least successful even if my construction was not optimal.  In the end I decided to purchase an inexpensive IR LED pen online that used the same brand and model of IR LED as originally recommended by Johnny Lee (NOT available at my local Radio Shack).  It worked like a charm!  I also found that using the Wiimote with the IR LED pen worked the best with a projector instead of on a computer monitor.

So, if you consider yourself anything of a hobbyist with some basic electrical knowledge, you should give this a shot yourself.  If you just want to see and use a virtual whiteboard with a Nintendo Wiimote and infrared LED pen, save yourself some time and frustration, and buy one online!

After finally getting Cygwin installed on my Windows XP Pro SP 2 laptop, I discovered how difficult it can be to get large open-source projects to correctly compile under Cygwin.  This was exteremely irritating for obvious reasons.

So I decided to try and install Ubuntu 8.10 under Microsoft Virtual PC 2007.  I had previously installed older versions of Ubuntu this way, but was having some trouble getting 8.10 installed.  After some searching, I found this wonderful post and comment thread.

The short story is, I had to add vga=791 noreplace-paravirt to the grub command line for the initial boot.  Then noreplace-paravirt to /boot/grub/menu.lst after installation and any subsequent updates that modify this file.