Saturday, January 12, 2013

Crockford on Javscript - The beginning

A confession first - I decided to watch this video only because I had 2 hours to kill and didn't have anything better to do. And ended up spending a weekend going through the entire set of videos. If you have the time and a good bb connection, go for it. Crockford's wit is amazing, plus the insights into why Javscript is the way it is make this a good watch. Did you know that Javascript was designed and implemented in less than 2 weeks - I take as long to draft a design document. Oh, and be prepared for some heavy duty Java trashing :)

Crockford on JavaScript - Chapter 2: And Then There Was JavaScript


In order to do that, they hired this guy, Brendan Eich, who had been at Silicon Graphics. Brilliant guy. In his interview he said he wanted to write a Scheme interpreter, and they said ‘that’s great, that’s just what we want’. After they hired him they found out what Scheme was, and they said ‘no, no, no, you can’t do that. People won’t like that. Do something that looks more like Visual BASIC, or Java, something people like.’ So he did that. He combined elements of three languages: Java, because he was told he had to, and two really interesting languages, two failed languages in the sense that they got zero market acceptance, but two brilliant languages and two highly influential languages. They’re known not much to the general programming community, but they’re very well known to program language designers. It was a surprising choice to take features from those two languages. Scheme was a dialect of Lisp, which was inspired by Carl Hewitt’s Actor Model. Brilliant language, probably the best implementation of functions in any language we’ve ever seen. Self was a brilliant language that came out of Xerox Parc originally. It was taking Smalltalk and stripping it down to a simpler language in order to make it go faster. It turned out that in making it simpler they actually made it profoundly better. That project then moved to Sun Labs, so for a time Sun was supporting research into both Java and Self. At some point Sun made a decision and killed one of them, and in my opinion they killed the wrong one. Self was clearly the better language.

Brendan took elements of all three of these languages, and a little bit of his own, and put them together into a new language that was called LiveScript. LiveScript was going to become one of the key technologies for Netscape going forward. It was very clear at the time that there was a lot of excitement about Java and the Netscape browser, and Sun and Netscape decided they needed to work together against Microsoft because if they didn’t join forces Microsoft would play them off against each other and they’d both lose. The biggest point of contention in that arrangement was what to do with LiveScript. Sun’s position was: "Well, we’ll put Java into the Netscape browser, we’ll kill LiveScript, and that’ll be that." And Netscape said no, that they really believed in the HyperCard-like functionality, and they wanted a simpler programming model in order to capture a much larger group of programmers. So there was an impasse, and the relationship almost broke up, when I think Marc Andreessen - and I have not been able to document this, but people have told me - Marc Andreessen, maybe as a joke, suggested: ‘let’s change the name to JavaScript.’ And it worked. 

At Microsoft they’d been watching this with some alarm, particularly when folks at Netscape were saying that Netscape Navigator was going destroy Microsoft. Microsoft said ‘oh, we don’t want to be destroyed’. It turned out Netscape Navigator didn’t destroy Microsoft. In fact, the software that is going to destroy Microsoft is Windows Mobile.

What Microsoft did was they decided they needed to copy the Netscape model in order to be competitive. They reverse engineered the JavaScript engine and called it JScript. They couldn’t call it JavaScript because Sun owned the trademark, and they weren’t getting along very well with Sun at that time, so they called it JScript. Netscape looked at that with alarm: oh no, we’re going to be embraced and extended, so we need to make a standard out of this. So they went to W3C and said OK, we’ve got a language for you to standardize. W3C had been waiting for a long time for an opportunity to tell Netscape to go to hell, so they told Netscape to go to hell.

In copying the Java syntax, JavaScript also copied some bad things about Java. So many of the worst features in JavaScript are actually things it inherited from Java, which it inherited from C, which it inherited from FORTRAN. So there’s a long line of sin-age which affects us today.

Sunday, January 16, 2011

Enable DVD drive or USB drive on your laptop

Goto Start -> Enter regedit

To enable CD/DVD drive
Search for the following key
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E965-E325-11CE-BFC1-08002BE10318}
Back it up (Edit -> Export to your local directory). Delete Lower and Higher Filters
If it doesn't work yet, search for the following key and change the value from 4 to 1
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\cdrom

To enable USB drive
Search for the following key and change the value from 4 to 3
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\USBSTOR

Monday, December 27, 2010

Java DNS Cache

This one is for the record - an issue I had faced and meant to document, so here goes.

From our app (Java version used is 1.4.2_19), we connect to a GSS load balanced url which operates in a round-robin fashion. For e.g., if the url is http://www.twitter.com, which maps to 128.242.240.148/116/20, the app should get a different IP each time or at least most of the time. But it sticks to the first IP it discovers. The reason is Java's DNS cache.

Java caches DNS settings after the app accesses a url so that any subsequent operation uses the cached setting - in our case, if www.twitter.com resolves to 128.242.240.20 the first time, that value is stored in the DNS cache and everytime twitter is accessed, the IP it resolves to remains the same.

Sounds daft, right. Not quite. This cache is maintained in the InetAddress class - there is one each for successful and 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. Refer the javadoc for more on the above.

In cases like ours, where we don't want DNS caching forever, the solution is to set the TTL value for positive caching to a very low value. This much is well documented. There are 3 ways to set this.
- Set the value from command line using the setting -Dnetworkaddress.cache.ttl=x where x is the number of seconds for which the value is to be cached.
- Use the sun property setting. Works the same as above, only use -Dsun.net.inetaddr.ttl=x in lieu of -Dnetworkaddress.cache.ttl
- Modify the java.security file (Path is $JAVA_HOME/jre/lib/security/java.security) to set the value of networkaddress.cache.ttl to a low value. By default the setting is -1 (cache forever). Note that this setting would affect any application which uses this JDK.

Tried Option 1 - added the -Dnetworkaddress.cache.ttl=60 setting to the weblogic startup file, which should have cleared the cache every 60 seconds. But it did not have the intended effect. There is a related bug 6247501 reported, but that's Windows specific and we were on Unix, so shouldn't have affected us. Looked through the InetAddress caching mechanism, but could not quite figure out why it failed. Gave up after an hour.

Modified the JVM to use the sun setting -Dsun.net.inetaddr.ttl=60 and restarted the domain. Worked like a charm.

Can only conclude that -Dnetworkaddress.cache.ttl does not work from the command line but only from within the java.security file. If you do not wish to change the java.security setting, which would be the case if multiple domains reference the same JDK, a safer option is to use the -Dsun.net.inetaddr.ttl setting from the command line.

Happy caching.

Eclipse Memory Issues

JDK 5 was the default Java version in use, upgraded to JDK1.6.0_21-b06 today and Eclipse started tanking. Starts up fine but after a few minutes would fail with the error 'Internal plug-in action delegate error on creation. PermGen space'. Right, seemed to indicate that I wasn't allocating enough memory for permgen. But the same program works fine with the very same memory settings under JDK 5, so this was definitely an upgrade problem. So much for my support of auto updates :-|

The default setting in eclipse.ini was
--launcher.XXMaxPermSize
256m
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms40m
-Xmx256m

And 256m is generally sufficient for permgen, so what gives. Checked the configuration file to confim if the settings had taken effect (Click on Help -> About Eclipse -> Installation Details -> Configuration). Shows up the Xms and Xmx, but no MaxPermGen, hmmm... interesting.
eclipse.vmargs=-Dosgi.requiredJavaVersion=1.5
-Xms40m
-Xmx256m

Googled a bit. The eclipse wiki indicated that it was a bug with Oracle/Sun JDK 1.6.0_21 (had to be my version, duhhh), being tracked as 319514. The bug link is a pretty interesting read.

Apparently, as part of Oracle's rebranding of Sun's products, the Company Name property of the java.exe file, the executable file containing Oracle's JRE for Windows, was updated from "Sun Microsystems" to "Oracle" in Java SE 6u21. Now on Windows, Sun VM is identified using the GetFileVersionInfo API, which reads the company name (present under version details) from jvm.dll or the java executable and compares it against the string "Sun Microsystems". Post update 21, the company name was "Oracle" and the launcher does not recognize this string, hence the -XX:MaxPermSize setting is not honoured.

The workarounds are
- Switch back to '1.6.0_20'
- Change the commandline for launching or add the following line after "-vmargs" to your Eclipse.ini file:-XX:MaxPermSize=256m
- For 32-bit Helios, download the fixed eclipse_1308.dll and place it into (eclipse_home)/plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.0.v20100503
- Download and install any of the upgraded versions i.e. version 1.6.0_21-b07 or higher from the java site (alternative link is http://java.sun.com/javase/downloads/index.jsp). Make sure you have b07 or higher by running java -version.

Went with the last option and so far life's good. The MaxPermSize setting shows up under vm options
eclipse.vmargs=-Dosgi.requiredJavaVersion=1.5
-Xms40m
-Xmx256m
-XX:MaxPermSize=256m

But got this bad feeling that when I move to JDK 7, there'll be a newer set of problems cropping up (From the Oracle site: In consideration to Eclipse and other potentially affected users, Oracle has restored the Windows Company Name property value to "Sun Microsystems" in further JDK 6 updates. This value will be changed back to "Oracle" in JDK 7.) Sigh, so much for compatibility.

Monday, June 21, 2010

Google CL rocks

Refer Isaac Truet's post Setup GoogleCL on WinXP if you plan to setup GoogleCL on Windows. Tried it on XP, yet to check on Windows 7.

This post is just to indulge my fantasy of posting a blog from the command line :-)

Command used to post
google blogger post --blog "TechRamblings" --title "Google CL rocks" --tags "python, googlecl, development" googlecl.html

Sunday, June 13, 2010

Eclipse Decompiler Plugins

JADClipse plugin worked fine with Eclipse Galileo (3.5) on my old laptop, but failed on the Dell. The funny thing is JAD works fine from the command line, but cuts no ice with Eclipse. Tried by pointing Eclipse to the JADClipse update url, it downloads the jars yes but decompile it does not. Tried an eclipse -clean, still no luck.

All I can assume is JADClipse does't work on 64 bit machines, weird yes, but true.

An option you can choose to go with is JD-Eclipse plugin. Use Eclipse Update Manager to download JD and change the .class association to the JD Class File Editor.

BTW, if interested, steps to follow for setting up JAD with Eclipse on win32 machines.

SyntaxHighlighter on Blogger

If you intend to post code snippets on your blog, SyntaxHighlighter is the best option available.

Steps to enable it in your blogpost
1. Download the latest version and unzip in a local folder.
2. Upload all the files to either your domain or to sites.google.com.
3. Edit your template (In blogger, click on Design -> Edit HTML) and paste the following snippet under the closing div tag.


4. And finally, at the start of your code snippet, add the <pre class="brush: js"> tag. Close the code snippet with the corresponding </pre> tag.