Being a developer whose primary focus is business and data intensive applications means I do not get as much time as I would sometimes like to play around with some of the more 'designish' aspects of Flash development. Case in point, the BitmapData class that was introduced in Actionscript 2.0. I had seen the help documentation and came across some really neat examples of what you can do with bitmaps in Flash, but had never really had a chance to try it out on my own. Well the wait is finally over.
What it does: reads the all the pixel colour values in 10x10 squares, calculates the dominate colour value and sets the square to that colour.
What it does: draws an image line by line from right to left, using the rightmost pixel as the colour for each line being drawn
What it does: covers an image with a coloured layer, allows the top layer to be gradually 'scratched' off to reveal the image layer.
The BitmapData class and it's related classes provide developers with some really great tools for manipulating images and applying effects that would have been impossible or extremely difficult in previous versions of Flash. It just takes a little time and some creative juices to come up with some really neat concepts.
I just ran across this issue again, CFHTTP requests to a hostname work from one Coldfusion server but not from another. The JVM caches hostname-to-IP address resolution for infinity, by default. This means that if you have a local DNS server with a host name mytest.mydomain.com and it is set to resolve to 127.0.0.1 each CFHTTP request (or CFFTP, CFLDAP, CFINVOKE) to mytest.mydomain.com after the first call will resolve to the IP 127.0.0.1. If you change the DNS entry at some point to resolve to a different IP, Coldfusion never picks up on this change, but instead continues to try and resolve to the old IP address, unless you restart Coldfusion.
You can change the caching policy by editing the networkaddress.cache.ttl value in the cf_root\runtime\jre\lib\security\java.security config file.
The InetAddress class has a cache to store successful as well as unsuccessful host name resolutions. The positive caching is there to guard against DNS spoofing attacks; while the negative caching is used to improve performance.
By default, the result of positive host name resolutions are cached forever, because there is no general rule to decide when it is safe to remove cache entries. The result of unsuccessful host name resolution is cached for a very short period of time (10 seconds) to improve performance.
Under certain circumstances where it can be determined that DNS spoofing attacks are not possible, a Java security property can be set to a different Time-to-live (TTL) value for positive caching. Likewise, a system admin can configure a different negative caching TTL value when needed.
Two Java security properties control the TTL values used for positive and negative host name resolution caching:
A value of -1 indicates "cache forever".
A value of 0 indicates "never cache".
A value of -1 indicates "cache forever".
Read the TechNote from Adobe for more information.
As a senior developer I am constantly on the lookout for things to:
Derrick Grigg is a Rich Internet Application (RIA) freelance contractor based in Toronto, Canada. He specializes in architecting and developing applications using a variety of technologies, most notably Flash, Flex and Coldfusion.
