I must admit, if there is one feature that makes you scratch your head and wonder what the heck the folks at microsoft were smoking on the day they dreamed up that wonderful set of tools called Accessibility Options within XP.
It may be a great set of tools that for those who need them because of unfortunate handicaps, but the boneheaded folks at microsoft sure did goof on common sense interfaces.
It behaves like a virus for it can hose your computer without your knowledge and there is no way to permanently disable it. I am sure many of users have been burned by it.
I saw that I am not alone in this common snake pit, for the following person summed it up quite nicly:
http://www.classicdosgames.com/blog/?p=3
I think this one feature alone could cause many folks to seriously consider the Mac platform, if not for any reason other than a good grasp of the concept behind a common human interface design.
Or perhaps it could also be one of the greatest marketing ploys ever devised, MS to harward manufacturers: "Bundle our OS with your hardware and we will include a software feature that would be sure to increase sales due to physical abuse by users to their hardware."
Monday, February 11, 2008
Microsoft's attempt to drive customers to buy macs
Thursday, January 10, 2008
Eclipse v3.3.x PermGen Memory Errors
Out-of-the-box Eclipse v3.3.x was giving me on average 12 to 16 crashes per day! I was even seriously considering dropping Eclipse altogether and finding something more stable.
I was using Eclipse v3.3.1 with the WST extension and tigris.org's subclipse v1.2.0 (since the v2.x has serious bugs that prevents it from installing) on a Windows XP Pro platform.
The short of the problems came down to a mistake in the eclipse.ini file that had the
--launcher.XXMaxPermSizestatement come before the
-vmargsstatement. It is a little more involved that that, one issue was that the duel-level launch configuration that Eclipse uses does not always do a great job of detecting Sun VMs, of which the
--launcher.XXMaxPermSizeonly works with a Sun VM, which defaults the PermGen space to a size of 64MB.
The suggested fix is to remove
--launcher.XXMaxPermSizeand replace it with
-XX:MaxPermSize=256mafter
-vmargsit should now pickup the change.
This change and usage of
-XX:MaxPermSizeis said to be universal (to some degree) to other VM's such as the mac.
An example of my config which works, which is "fairly" close to the original eclipse.ini:
-showsplash org.eclipse.platform
-vmargs
-Xms512M
-Xmx1028M
-XX:MaxPermSize=256M
One area of great disappointment with all of this, is that it appears like they were spending a fair amount of time arguing how and when to apply this fix or even announce this potential problem instead of just getting it done. I really do enjoy the Eclipse experience, but because of this problem, I was about to drop it and probably never give it another chance. Good thing I went snooping through their Bugzilla!
References
Eclipse's Bugzilla Entry on this bug
Tuesday, January 01, 2008
FireFox Add-On worth trying - FireBug
For the last few months I have been wishing that the PC version of Safari had the same full robust HTML and CSS debugging tools as the mac counterpart. Well, I have just found in the last week a tool that should make any Mac Safari user quite envious.
The tool's name is FireBug.
What is great about it? Here is a very short list:
- JavaScript Error Console
- JavaScript profiler
- View source code for HTML, CSS, JavaScript, Images, etc...
- HTML Source hover-highlighting
- Select an DOM element, and it can show the CSS styles that contribute to it, the Box model layout, and DOM hooks
- Dynamically modify CSS elements without modifying any source code or reloading the page to see the results
- Set JavaScript breakpoints for debugging
- See Network performance stats on object/page loads
- Review dynamic AJax calls: parms, headers, and response
This is a really useful tool. If you spend any time in HTML, JavaScript, CSS, this tool is well worth looking in to. I don't think many would be disappointed.
References
FireBug's Website
Prototype v1.6 Ajax.Updater and textarea in FireFox v2.x
There is a slight issue with how Prototype v1.6 (and prior) deals with textarea form elements when used in combination with Ajax.Updater. This appears to only be an issue with FireFox v2.0.0.x and not IE7 or Safari v3 for Windows. I have not tested to confirm if this is an issue on non-windows versions of FireFox or other browsers or platforms.
The problem enters when Updater is successful in putting the results content in to the textarea innerHTML, but the contents are not displayed. Most of the solutions that I have been able to find on the web suggests to use a onSuccess: callback then within there, pull the responseText from the response object and shove it in to the value of the textarea.
Example of a BAD use of Ajax.Updater with the textarea:
<form id="formid">
<textarea id="textareaid" />
</form>
Ajax Status: <div id="ajaxStatus"></div>
...
new Ajax.Updater( 'textareaid', 'anSOAapp.jsp', {
parameters: { id: anId, afield : avar },
onFailure: function(){
$('ajaxStatus').update('An error occurred.');
},
onSuccess: function(response) {
$('textareaid').value = response.responseText;
$('ajaxStatus').update( response.status );
}});
How wasteful! Not only in redundant processing (the contents of the textarea is being updated twice!), but also in memory that JavaScript is now having to allocate and use. What is the point of using the Ajax.Updater function if you are just going to overwrite its output?! For small tidbits of data, it may not be noticeable, but for larger data sets, then you can not only risk the out of memory exceptions, but also a non-functional page.
The whole point of utilizing the Ajax.Updater function is to help streamline the whole data flow and to offset the needs to keeping the data in a variable or as a String in JavaScript, which is what occurs when using the responseText field.
There is an easy solution that helps to avoid these problems of redundancy and excessive memory utilization. It is actually quite simple.
Example of the correct use of Ajax.Updater with the textarea:
<form id="formid">
<textarea id="textareaid" />
</form>
Ajax Status: <div id="ajaxStatus"></div>
...
new Ajax.Updater( 'textareaid', 'anSOAapp.jsp', {
parameters: { id: anId, afield : avar },
onFailure: function(){
$('ajaxStatus').update('An error occurred.');
},
onSuccess: function(response) {
if ( Prototype.Browser.Gecko ) {
$('formid').reset();
}
$('ajaxStatus').update( response.status );
}});
Notice that the key element was
$('formid').reset(); inside a conditional to ensure it only is performed for FireFox browsers.Give it a try.
Resources
Prototype API Docs
Prototype's Form.reset() function API Docs
Tuesday, December 11, 2007
Lead in Children's Toys and Books
Sad. It is really sad the extend to which manufacturers are willing to put our children's health and lives in jeopardy to just make a profit.
The current batch of recalls tend to be related to paint that has high amounts of lead, which brings me to wonder what about the children's books and ink? How much lead are in those? Is anyone even testing children's books?
Here is a site that is trying to list toys that have been independently tested to be free from surface lead and embedded lead. Unfortunately they do warn that even though these toys tested OK, that does not necessarily mean other batches of the same product (future or past) will not contain lead.
http://www.toyportfolio.com/
Get the Lead Out - Reply
I came across the following post:
http://atatude.wordpress.com/2007/12/10/get-the-lead-out/
It had a reference to the following CNN article on Lead in Christmas Lights:
http://www.cnn.com/2007/HEALTH/12/10/christmas.lights/
My reply:
Nice find on the CNN article!
Who do they think we are? A bunch of mindless idiots who will blindly buy their products irrespective to the toxins they are willing to dump in to them so they can make a bigger buck? Sure sounds like it from some of the responses given by Wal-mart and other companies that were interviewed.
I think the only way these arrogant companies will learn is through the bottom line. When parents stop spending "their" money on these tainted products and even return the products that have been recalled, their profits will suffer. Please do not just throw away recalled products, but try to return them. There is no better way to make the irresponsible retailers and manufacturers realize what the true impact of their "mistakes" will cost them.
If surface lead can come off with a wipe test, just imagine how much lead comes off upon contact with the tree or other decorations? How much of that lead is microscopic to the point it is easily airborne too? How much lead are they putting in the artificial trees? How safe are the non-electrical ornaments? Since lipstick and children's toys has been found to have high levels of lead, what can we trust?
One point that should be made about blood tests for lead, is that the body completely absorbs all lead within about 30 days of exposure so blood lead tests can only check for recent exposures and is no good at prior exposures. Once the lead is absorbed in to the tissue, I don't think even detoxification treatments can remove it.
Last year I found some extension cords that were rated for indoor and outdoor use that had a label that specified that they were lead-free. Lead-free products can be made if the manufacturers want to. Personally, I'd be more than happy to pay a 20% or even 40% premium if the product can be guaranteed to be lead-free.
Wednesday, September 05, 2007
PermGen Exception
Here are a few good links that discuss this in more detail.
The dreaded “java.lang.OutOfMemoryError: PermGen space” exception.
Classloader leaks: the dreaded "java.lang.OutOfMemoryError: PermGen space" exception
How to fix the dreaded "java.lang.OutOfMemoryError: PermGen space" exception (classloader leaks)
Thursday, August 30, 2007
Go for the Bitter Coffee
Just wanted to share something interesting about how healthly a bitter cup of coffee may actually be. It turns out the higher the bitter content, the greater the amount of anti-oxidants. It appears that the bitterness is caused by the roast, so the darker the roast, the more anti-oxidants it may contain.
Check out the original story at Bitter Coffee Better Health with references back to the original studies (just in case this sounds too good to be true and you want to read it yourself ;-) ).
Also, as a note, there are many other interesting articles of note, all with a good dose of references too.
Thursday, July 19, 2007
Status of Safari and some comments about JavaScript and AJax
Sorry to say, but I have not been working with Safari for a while now. I did get a few comments pointing out some flaws in what I have done in the past. I am not too surprised, but luckily that is one of the best ways to learn and grow. I'll be activating those comments shortly.
As some background, I have tended to keep away from JavaScript in the past. The same holds true today, but at a lesser degree. The primary reason was cross browser compatibility and the fact that sometimes the JavaScript can get quite complex when you start to include all of the variations for past browsers and future ones.
One thing that has been winning me over is the JavaScript tools that are focused on prototype.js and the use of AJax. It also helps that the advanced features in CSS 2.0 and what will be coming with CSS 3.0 specifications will help reduce the need for scripting.
I have continuously been on the hunt for a good JavaScript based code set that allows table scrolling. I found a bunch of bad stuff out there. I found a few good ones too. One of which actually does work with AJax. I am wanting to post reviews and links to these tools for they are hard to find, and I think the information will be beneficial. The tool that works with AJax utilizes prototype.js which is great, but I have some enhancements that I am working on that will be increasing the performance by about a factor of 10 or greater (I think. Need to benchmark.) when dealing with rowsets greater than 1000 when the will be needing to deal with 40,000+, probably up to 100,000 rows... I know... I don't write the specs, just follow them :-(
For now I'll provide some links...
References:
http://www.sergiopereira.com/articles/prototype.js.html
- Excellent independent documentation on prototype.js!
- Using version 1.5.1
http://www.tetlaw.id.au/view/blog/table-sorting-with-prototype/
- Excellent! Uses prototype.js and the code is very clean and readable.
- Works with AJax
- Sluggish with 1000+ rows. I have some fixes in the pipeline that once I get them tested I'll see about getting the code changes adopted.
- Using version 1.0 with Prototype version 1.5.1 instead of 1.5.0_r
- Works great with IE5, IE6, IE7, FireFox v2 (Windows and Mac OSx), and Safari
- Low impact. Just call the function with passing the ID for your table and it does the rest.
- Problem? It does not work with AJax. Works great with static HTML tables. Honestly, the code is a bit cluttered since it does not utilize prototype.js so it has to handle so much more internally.
- Another problem appears to be that it was last updated in 2004.
- Sad, it has strong potential if it was not for the lack of AJax support.