June 17, 2008
whose june 17th was that again?
june 17th has been touted as "firefox download day". while i'm a long term firefox user, this june 17th business just annoys me no end. june 17th where? what time? what timezone? i've looked fairly hard for any details but all i see is this standalone, kind of useless date of june 17th.

how on earth do you think you can coordinate a global project by not giving folks useful info? geez.

i've been hitting the download link throughout the day, thinking maybe the mozilla folks were all east US coasters (really no idea, just a WAG) & i'd see something around noon here in bangkok. nope. nothing. butkis. just version 2.0.0.14.

oh well. in case anybody's missed the link, go here: http://www.spreadfirefox.com/.

Posted At : 11:17 AM. | Link | , | Comments (4)

May 14, 2008
a "mostly" compliant java based email parser
if you've ever had to deal with email addresses you know it's sometimes a black black art to verify RFC-2822 compliance. ColdFusion's isValid() function is certainly handy for this but it's not 100% (actually i don't think anything is 100% RFC-2822 compliant, just have a read thru RFC-2822 to see what i mean).

well today on the javamail list someone announced The only more-or-less-2822-compliant Java-based email address extracter/verifier with some header verification as well. i did "some" testing on it w/our "crazy" email address suite & it passed but as for being more-or-less-2822-compliant i guess i'll have to take the author's word for that ;-)

have a look at EmailAddress.java and see for yourself.

Posted At : 12:03 PM. | Link | | Comments (0)

May 5, 2008
the death of codepages?
mark davis, via the unicode mailing list, mentioned an offical google blog posting that shows that unicode "was the most frequent encoding found on web pages" since dec-2007 (unicode, utf-8, is the blue line on the graph below). wow. i guess people really do get it :-)

reference: Moving to Unicode 5.1

Posted At : 11:52 PM. | Link | , | Comments (0)

April 10, 2008
math precision out your ears
we very often have to deal with scientific data that's been gathered by various sensors or lab equipment, some of it needing math done with a fairly high precision that ColdFusion sometimes couldn't handle. flopping down to java BigDecimal was the usual way of dealing with this. but yesterday in the ColdFusion support forums, Hemant Khandelwal causally mentioned that cf8 had added a new method, precisionEvaluate() for just such cases. i guess it was one of those "senior momements" that made me skip right past this puppy when i was reviewing the new stuff in cf8. in any case, "wow".

<cfscript>
// the old way if you needed the precision bd=createObject("java","java.math.BigDecimal");
bd1=bd.init("234.567890123456");
bd2=bd.init("123.67141525678901345");
x=bd1.multiply(bd2);
// "high" precision math y=precisionEvaluate(234.567890123456*123.67141525678901345);
// "normal" cf math
z=234.567890123456*123.67141525678901345;
writeoutput("<table border='1'>
<tr><td>old fashioned java way</td><td>#x#</td></tr>
<tr><td>new precisionEvaluate</td><td>#y#</td></tr>
<tr><td>normal cf math</td><td>#z#</td></tr>
</table>");
</cfscript>

which produces something like:

old fashioned java way29009.34294536678530209026494448320
new precisionEvaluate29009.34294536678530209026494448320
normal cf math29009.3429454

i would imagine that cf's handling the expression parsing and data type casting in the background similar to the above example using BigDecimal.

ps: coldfusion 8 added BigDecimal as one of the data types for javaCast(), so you could ditch the createObject() and use something like this:

zz0=javacast("BigDecimal","234.567890123456");
zz1=javacast("BigDecimal","123.67141525678901345");
zz=zz0.multiply(zz1);

Posted At : 4:43 AM. | Link | | Comments (0)