Apache Web Service Framework

http://incubator.apache.org/cxf/

vim - recording keystrokes and reusing

http://www.vim.org/tips/tip.php?tip_id=144

The most useful feature that I find in VIM is the "recording" feature (:help recording). I have used this to automatically insert function headers, re-indent lines, and convert some 34 source files into HTML.

This feature is most useful when you want to do some repeated jobs, which you cant do easily using ".". You can set about writing a function, define a mapping, etc, but then these things might take time. By recording, you can try out and find the actual keystrokes that does the job.

To start recording, press "q" in normal mode followed by any of "0-9a-z". This will start recording the keystrokes to the register you choose. You can also see the word "recording" in the status(?) line. You can start the key sequences that you want to record. You can go to insert mode and type if you want.

To stop recording, press "q" in the normal mode.

To playback your keystrokes, press "@" followed by the character you choose. Pressing "@@" will repeat the same again.

subversion : clean non-versioned files from svn source tree

svn status|egrep "^\?"|awk '{print $2}'|xargs rm -rf

ruby - installing from source

1. Download ruby.tar.gz from rubyforge

2. unzip and untar the file

3. Navigate to extracted folder

4. following steps ( like any other source compile on linux)

./configure
make
make install


This will install ruby .

5. To install an extention (say to install openssl on linux)

go to ruby-source/ext/open ssl and execute following steps

ruby extconf.rb
make
make install

unix find - seach based on permissions

All the files in the current directory that does not have a write permission for user and group

find . -not -perm -ug=w

All files owned by 'ssinghal'

find . -owner ssinghal

Code Search Engines

TODO: Edit this post to give a description on special features of each search engine :)

http://www.google.com/codesearch

http://www.koders.com

http://www.krugle.org

http://www.codase.com/

using sun.* packages in java

From : http://java.sun.com/products/jdk/faq/faq-sun-packages.html

The classes that Sun includes with the Java 2 SDK, Standard Edition, fall into package groups java.*, javax.*, org.* and sun.*. All but the sun.* packages are a standard part of the Java platform and will be supported into the future. In general, packages such as sun.*, that are outside of the Java platform, can be different across OS platforms (Solaris, Windows, Linux, Macintosh, etc.) and can change at any time without notice with SDK versions (1.2, 1.2.1, 1.2.3, etc). Programs that contain direct calls to the sun.* packages are not 100% Pure Java. In other words:

The java.*, javax.* and org.* packages documented in the Java 2 Platform Standard Edition API Specification make up the official, supported, public interface.
If a Java program directly calls only API in these packages, it will operate on all Java-compatible platforms, regardless of the underlying OS platform.

The sun.* packages are not part of the supported, public interface.
A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform.

For these reasons, there is no documentation available for the sun.* classes. Platform-independence is one of the great advantages of developing in the Java programming language. Furthermore, Sun and our licensees of Java technology are committed to maintaining backward compatibility of the APIs for future versions of the Java platform. (Except for code that relies on serious bugs that we later fix.) This means that once your program is written, the class files will work in future releases.

Each company that implements the Java platform will do so in their own private way. The classes in sun.* are present in the SDK to support the Sun implementation of the Java platform: the sun.* classes are what make the Java platform classes work "under the covers" for the Sun Java 2 SDK. These classes will not in general be present on another vendor's Java platform. If your Java program asks for a class "sun.package.Foo" by name, it may fail with ClassNotFoundError, and you will have lost a major advantage of developing in Java.

Technically, nothing prevents your program from calling into sun.* by name. From one release to another, these classes may be removed, or they may be moved from one package to another, and it's fairly likely that their interface (method names and signatures) will change. (From the Sun point of view, since we are committed to maintaining the Java platform, we need to be able to change sun.* to refine and enhance the platform.) In this case, even if you are willing to run only on the Sun implementation, you run the risk of a new version of the implementation breaking your program.

In general, writing java programs that rely on sun.* is risky: they are not portable, and are not supported.