September 29, 2006

heads up! DST changes coming

in case you missed it, the US will have some significant DST changes in 2007. instead of DST kicking in on april 2nd, in 2007 it will start march 11th and end november 4th (instead of october 29th). those are the actual dates, the "Energy Policy Act of 2005" has the DST starting on the "second Sunday in March" and ending on "the first Sunday in November".

hopefully ColdFusion 8 (aka scorpio) will upgrade it's JDK to a version that includes the new timezone data. if not--which i think is highly unlikely--or you can't upgrade in time you can do it yourself. for MX, upgrading to J2SE 1.4.2_11 or better will do the trick.

you can read more here. an interesting note from that page is that several countries follow US DST rules, something i had never considered before.

September 22, 2006

icu4j 3.6 hits beta

get it while it's hot, icu4j 3.6 has just had a beta release. see the read me for more info.

September 19, 2006

analysis of the olmec hieroglyphs

michael everson, a virtual language encoding machine and leading light in the unicode world, has just posted a brief analysis of the recently discovered "olmec hieroglyphs". while the analysis isn't a "decipherment", i find the way michael attacked the analysis fascinating.

September 09, 2006

icu4j 3.6 hits alpha

the ICU project has announced the release of an alpha version of icu4j 3.6. you can grab this cool java library here. so what's new for 3.6? according to the brief release notes:
  • support for Unicode 5.0
  • 25% more CLDR locale data in 245 locales in ICU
  • a flexible date/time format generator has been added, allowing for multiple date and time format patterns to be generated that are valid for specific locales (sounds interesting)
  • under "Globalization Preferences", a new flexible container for locale data was added
  • for more charset conversion bang-for-your-buck, a preview of the ICU4J implementation of the java.nio.charset.Charset API was added

addendum: apparently the nifty timezone bits proposed earlier this year didn't make it into this release. too bad, so sad, could have been very useful.

September 02, 2006

when is a flex event listener not an event listener?

as i mentioned in my last post, i'm porting a js UI lib over to flex/flash. one of the things this library does is provide several tools for working with images (well map images actually), it does stuff like measure distances, areas, and angles, rubberband zoom boxes (oh how i wish google map et al would wise up and add this functionality natively, click to re-center the map image then do a separate zoom is for the birds), redline maps (mark up the map image with user annotations like "for heaven's sake don't dig here"), etc. the approach we used was to handle each mouse event separately (up, down, move, etc.) and hand off the event processing to whatever the current tool was, essentially a big switch box. well having read up on and researched flex's event processing i thought i'd get "fancy" and add/remove event listeners as a user changed tools. here's the approach i took:
  • create an mxml image object and hang an original set of listeners off it:
    <mx:Image id="theMap" height="400" width="600" source="" toolTip="the map" useHandCursor="false" mouseMove="utils.showCoords(event); utils.doZoomBox(event);" mouseDown="utils.doZoom(event);"/>
  • remove the current listeners and add the new ones as the user changed tools:
    theMap.removeEventListener(MouseEvent.MOUSE_DOWN,utils.doZoom);
    theMap.addEventListener(MouseEvent.MOUSE_DOWN,utils.doPan);

this worked perfectly the first time, then the application would fallback to the original set of listeners defined in the mxml image object (i didn't actually see this at first, i just noticed it fellback on the wrong set of listeners). that is, if i switched to a tool to pan the map image, it would work the first time i panned the image, then it would go back to the zoom tool for the next mouse event. couldn't figure this out after a couple of days, went to the flex-coders list, no joy. another day or so of slowly banging my head against the monitor and i finally had to bother matt the-answering-machine chotin. i guess it took matt about 2 minutes to see my self-inflicted problem.

the problem was that the listener i was removing wasn't the same "listener" as i had originally hung off the mxml image object. when you add a "listener" like that in mxml, it isn't actually a listener, rather it's simply code that will get executed. so when i went to remove it and add a new one, what happened was that only the new listener was added, giving each mouse event two "listeners", the original one in the mxml object and the new one added via actionscript. who knew?

the proper way to handle this is to not define "listeners" on your mxml objects but rather add them during initialization. though in fact matt advised that the original js design was the more "traditional" approach, so that's the method i ended up implementing.

i guess this is another example of the kind of support adobe provides. even though matt is now further up the product food chain he still takes the time to answer technical questions. the same can be said for damon, tom and mike on the ColdFusion team (well when mike was still with adobe anwyay). while i suppose there are other communities with this level of company support, bet you can count them on one hand ;-)

hello flex builder 2, goodbye old workstation

doing mostly ColdFusion work and doing it with cfstudio 5 and occasionally eclipse and lately cfeclipse, i was perfectly happy running an "ancient" workstation. how ancient? an intel pentium III (797 mhz) on an intel motherboard that maxxed out at 512 mb RAM (which i used to think was a lot). it's hard disks got bigger, win2k gave way to xp (way later than everybody else), WIFI supplanted 10T, monitors have come & gone, i've pounded several keyboards to pieces as well as dropped a half a dozen mice off the desk to their doom but that old workstation just stayed dependable, the only thing i've ever done was replace the power supply a couple of years ago. i'd blow the dust out of it 2-3 times a year (Thailand is a fairly dusty place) and maybe defrag the system disk 4-5 times a year but that was it as far as maintenance went.

now along comes flex builder version 2.0 (i won't say anything about 1.5, there might be kids present ;-). while it starts up in an acceptable amount of time (not instantly but snappy enough to get my game face on), compiling apps, especially given the habits i've developed from ColdFusion of testing incremental changes and saving code every chance i get, is getting to be a drag. testing concepts--i'm fairly new to flex, so everything is a "new concept" to me & needs to be tested, i don't believe a word the docs says ;-)--and smaller, focused components, it's not too bad. but boy oh boy, complex stuff is taking longer & longer & l-o-n-g-e-r. i tried doing something else, reading email, blogs, listening to matt & peter's podcasts but that just made things worse, stealing RAM from eclipse. so i took to getting up from my workstation & getting a cup of coffee during compilation but with all that extra caffeine in me, i started scaring people and chasing pets in the neighborhood so i've had to find another solution ;-)

since i've more or less lived in a cave when it came to new hardware developments, i'm not sure which way i should jump (except no macs, too old to learn that much), though i do know i want one of those fancy-pants LCD screens. then there's the psychological berlin wall i'll have to hop over when it comes to years of the apps i've accumulated on this box. i hate the thought of wasting a day or more getting the old stuff installed on the new box as well as rummaging around in file cabinets looking for install CDs and serial numbers, etc. in the end though, i guess it's time to put old yeller to sleep.

so anybody care to hand out some advice on hardware specs for a flex capable workstation?

btw i really like flex. i'm in the middle of porting over an old js GUI library (i guess it might be called AJAX these days) and a couple of days ago i threw out gobs of skanky old code that handled browser brand and version quirks. i suppose the more modern AJAX libs handle this stuff transparently but back then it was all on the developer and i for one, am really glad that this probably won't be something i'll have to think about again. and compared to js, flash/flex just seems simpler and more natural to me (at least since i haven't read much about stage, movieclip or timeline lately).