State Machine Compiler

SMC lets you modularize states, transitions and actions in a neat way that will let you maintain any complex system of several objects which have their own state flow mechanism.
Key thing is - it lets you capture all possible states, transitions and actions that will be triggered (not the complete implementation details of actions) in one file that helps for anyone to understand the system easily. Even maintaining it is very easy, since you can update the same file any changes in state transitions definition. Check out more here for details - http://smc.sourceforge.net
Do checkout presentations at - http://smc.sourceforge.net/slides/SMC_Tutorial.pdf and http://smc.sourceforge.net/slides/smc.pdf

Open Closed Principle

Open for Extension, Closed For Modification - Simple But Strong OOD principle

Explained very well in easy to understand about this more at http://www.objectmentor.com/resources/articles/ocp.pdf 

Android Architecture

Neat videos to get started on understanding Android Architecture - http://www.youtube.com/watch?v=Mm6Ju0xhUW8 

CVS - Simple explanation of Trunk, Branch and Tag

Copied from URL - http://www.bioinf.uni-freiburg.de/~mmann/HowTo/cvs_branches.html

CVS Branch and Tag Primer

Jeff Semke
Pittsburgh Supercomputing Center
4/21/98

In attempting to construct a CVS repository containing multiple versions of original NetBSD source distributions, as well as our own custom modifications to each of these, I found that the CVS man page was vague and unclear.

This document assumes general familiarity with the CVS system, including the concepts of modules, the repository, and basic checkout and commit operations.

Branches and tags are very different things, though they appear similar on the outside. Understanding the difference is the key to being able to support a multi-branched repository that can change as our custom code is modified for all versions of NetBSD.

The main concepts that are addressed in this document are:

Tree structure

Code in a CVS repository can be thought of as a tree. The tree shape is not based on the directory structure of the code, but rather on the versions of the code.

Trunk

As code gets modified and is committed back to the repository, it adds another revision to extend the tree. If no branches are specified when checking out working directories, the tree simply grows in a line along the main trunk of the tree.

Tags

A tag can be used to name a particular revision of the code. This tag can later be used to compare different revisions, to go back to an earlier version, or to specify a place to create a branch.

Branches

Branches allow different development paths to be tried. They can be created from the main trunk, or from other branches.

1. The trunk of the tree

As the code gets modified, each revision extends the trunk of the tree. The trunk itself is named only by the module name, not by tags or branches. You can get a copy of the latest revision of the main trunk to work on with the command
cvs checkout my_module
This creates a working directory called my_module, and it contains the files and subdirectories of my_module. After you make your changes, you enter them into a new revision on the main trunk with the command
cvs commit

2. Branches

2.1 Creating a Branch

Branches can be added to the repository tree in order to allow different development paths to be tried, or to add parallel development of code to different base versions. To create a branch, you can use
cvs tag
or
cvs rtag
with the -b option.
Do not be fooled! Even though the same commands can be used to create tags, branches are completely different than tags.

2.1.1 rtag

To create a branch from the main trunk of my_module at the revision that was last committed, use the command
cvs rtag -b Branchname my_module
To create a branch from a tagged revision of my_module, use the command
cvs rtag -r Tagname -b Branchname my_module
Both commands immediately create a branch in the repository without requiring a cvs commit to enact. You do not need to be in a checked-out working directory to do this.

2.1.2 tag

If you are in a working directory, you can create a new branch in the branch or trunk from which you checked out your working directory (not including the changes you've made to your working directory since the last commit) by using the command
cvs tag -b Branchname
Like rtag, the change is immediate, and does not wait for a commit command.
Your working directory remains on the old branch, at a point after the branch you just created. To move your working directory to the new branch, use the command
cvs update -r Branchname
When you are finished making changes to your working directory, save it as the next revision on the new branch with
cvs commit

2.1.3 Both rtag and tag

Note that both rtag and tag work directly on the repository and take effect immediately without a commit command. Rtag takes effect at the specified place (the end of the main trunk by default), while tag takes effect at the place where the working directory was checked out or last committed.

2.2 Checking Out a Branch to Work On

To check out the latest revision of a branch to work on, use the command
cvs checkout -r Branchname my_module
When you do a cvs commit, the changes are merged in on the branch from which they were checked out.

2.3 General

Note that branch names refer to the latest revision of the branch they are on, not the state they were in when the branch was created.

3. Tags

A tag provides a means to name a certain revision of the code, or take a "snapshot" of it at a certain point in time. This tag only applies a named handle to the code at that point in time, it does not create a new branch of code.

3.1 Creating a Tag

In order to name the current end of the main trunk of a module, use the command
cvs rtag Tagname my_module
In order to name the current end of a branch of a module, use the command
cvs rtag -r Branchname Tagname my_module
Otherwise, to name the code that your working directory was checked out from (without the changes you made to your working directory since the last commit), use the command
cvs tag Tagname

3.2 Using a Tagged version of code

You can check out tagged versions of code with the command
cvs checkout -r Tagname my_module
This creates a working directory with the code as it was when the tag was created. While branch names refer to the latest code at the end of a branch (and as such, are dynamic), tag names refer to the static version of code that existed upon the tag's creation. As a result, you cannot commit changes back into the tree at the tagged place that you checked them out from.
If desired, a new branch can be created at the place the tag was applied, then changes can be committed into the new branch as follows:
cvs rtag -r Tagname NewBranchname my_module
cvs update -r NewBranchname
Finish changes to the working directory, then
cvs commit
To access this version of the code again later (along with any changes that were made by others since you last accessed it), use
cvs checkout -r NewBranchname my_module

4. Merging branches

4.1 Using Update

cvs update -j TagOrBranch1 -j TagOrBranch2 my_module
The above command will locate the differences between TagOrBranch1 and TagOrBranch2. Of the lines that are different between them, the lines in TagOrBranch2 will be patched, or merged, into the sources in your working directory.
An annoying problem that I have not yet solved is that new files that appear in TagOrBranch2 but not in TagOrBranch1 do not get created by the merge. The only thing I know of to get these files into the new version is to checkout TagOrBranch2, copy the files into the merged working directory, and do
cvs add filename

4.2 Using Checkout

cvs checkout -j TagOrBranch1 -j TagOrBranch2 my_module
The above command will locate the differences between TagOrBranch1 and TagOrBranch2. Of the lines that are different between them, the lines in TagOrBranch2 will be patched, or merged, into the latest revision on the main trunk of my_module.
In order to have these differences merged into a different branch, and then have that branch checked out, use
cvs checkout -r BranchToMergeTo -j TagOrBranch1 -j TagOrBranch2 my_module
Like update, file that were created between TagOrBranch1 and TagOrBranch2 do not get created automatically.

Alternative to PInvoke for C++ - .NET Managed code integration

If you are looking for integrating between C\C++ libraries/code and Microsoft.NET managed code, you might want to try C++\CLI which seems to be really native way of approaching it than pInvoke.
Refer to some of links for some good starting point -

http://en.wikipedia.org/wiki/C%2B%2B/CLI

 http://www.codeproject.com/Articles/19354/Quick-C-CLI-Learn-C-CLI-in-less-than-10-minutes

http://manning.com/sivakumar/

subversion - clearing already cached credentials

wondering how to remove the existing cached credentials by svn client ? go to /home/<user>/.subversion. look for auth folder. it will have different folders like svn.simple or svn.ssl.client-passphrases etc. based on your server configurations, your cached credentials are present in one of these folders. delete that manually, which will force svn to ask for credentials again and it will cache it from then on.
if you do not want it to be cached, edit config file at the same path as you found your auth folder. note that some of settings in client side config will be overridden with server side config file settings.

Icecream

Wanna leverage peer machine's computing power for your compilation?! Icecream on openSuse helps you connect peer-peer computers in node fashion which will be leveraged for distributed compilation.
Just follow the link - http://en.opensuse.org/Icecream , setting up is a breeze and when you see your make command triggering distributed compilation on icemon, you see magic happen :-)

Changing RunLevel

Two sets of init scripts are involved in switching runlevels: K-scripts from the runlevel on which we are currently running and S-scripts from a new (target) runlevel. It is important to understand that there are two runlevels involved in switching:

• runlevel from which we switch. Let's call it l_from
• runlevel to which we switch. Let's call it l_to

Simplifying the rc script which is responsible for changing runlevels performs the following two operations.

1. All K-scripts that exist on the current runlevel l_from are processed. For each K-script for which S-script does not exists at the target runlevel l_to, the  K-script froml_from is executed.
2. Each S script that exist at target runlevel l_to is executed

In other words when you change the runlevel first stop scripts of the current runlevel are launched, closing down some daemons running on the current runlevel that are not necessary on a new runlevel (do not have S-script defined for them). Then all start scripts of the new runlevel are run in the order defined by their numeric priorities (lexographic order).

For example, the following occurs when changing from runlevel 3 to 5:

1. The administrator (root) enter the command init 5 which tells init to change the current runlevel to 5. 
2. The init consults its configuration file (/etc/inittab) and determines it should start /etc/init.d/rc with the new runlevel as a parameter.
3. Now rc calls all the stop scripts of the current runlevel, but only those for which there is no start script in the new runlevel. In this example, these are all the scripts that reside in /etc/init.d/rc3.d (old runlevel was 3) and start with a K. The number following K specifies the order to start, because there are some dependencies to consider.
4. The last things to start are the start scripts of the new runlevel. These are, in this example, in /etc/init.d/rc5.d and begin with an S. The same procedure regarding the order in which they are started is applied here.

When changing into the same runlevel as the current runlevel, init only checks /etc/inittab for changes and starts the appropriate scripts. 

Q & A

What CPU(s) is the system running on?
less /proc/cpuinfo

How much RAM does it currently use?
less /proc/meminfo

How much swap space do you have?
free

How many hours has the system been running?
uptime

How will you see all mount points?
cat /proc/mounts

Which filesystems are known by your system?
cat /proc/filesystems

What drivers are loaded?
cat /proc/modules

View all users and groups
cat /etc/passwd
cat /etc/group

Where is the time zone information kept?
cat /etc/sysconfig/clock

Which version of bash is installed on this system?
bash --version

sub-directories of / directory

Directory	Content
/bin	Common programs, shared by the system, the system administrator and the users.
/boot	The startup files and the kernel, vmlinuz. In some recent distributions also grub data. Grub is the GRand Unified Boot loader and is an attempt to get rid of the many different boot-loaders we know today.
/dev	Contains references to all the CPU peripheral hardware, which are represented as files with special properties.
/etc	Most important system configuration files are in /etc, this directory contains data similar to those in the Control Panel in Windows
/home	Home directories of the common users.
/initrd	(on some distributions) Information for booting. Do not remove!
/lib	Library files, includes files for all kinds of programs needed by the system and the users
/lost+found	Every partition has a lost+found in its upper directory. Files that were saved during failures are here.
/misc	For miscellaneous purposes.
/mnt	Standard mount point for external file systems, e.g. a CD-ROM or a digital camera
/net	Standard mount point for entire remote file systems
/opt	Typically contains extra and third party software.
/proc	A virtual file system containing information about system resources. More information about the meaning of the files in proc is obtained by entering the command man proc in a terminal window. The file proc.txt discusses the virtual file system in detail.
/root	The administrative user's home directory. Mind the difference between /, the root directory and /root, the home directory of the root user.
/sbin	Programs for use by the system and the system administrator
/tmp	Temporary space for use by the system, cleaned upon reboot, so don't use this for saving any work!
/usr	Programs, libraries, documentation etc. for all user-related programs.
/var	Storage for all variable files and temporary files created by users, such as log files, the mail queue, the print spooler area, space for temporary storage of files downloaded from the Internet,or to keep an image of a CD before burning it.

you were thinking "sh" was the only shell?

sh or Bourne Shell
bash or Bourne Again Shell
csh or C Shell
tcsh or Turbo C Shell
ksh or Korn Shell and much more...

run cat /etc/shells to see the various shells available on your linux installation..

Commonly used commands from shell...

find, grep, which, locate, file, ls, Ctrl+R, echo, export, df, ln, man, pwd,quota, wc ..

chmod - change file permissions
id - displays current user, groups
newgrp - change the group
umask - display standard file permisssion
chown, chgroup - change ownership and group
<command> & - command
bg, fg, kill, jobs - various commands to control job/process
pstree, ps, top - viewing process related commands
fdisk -l | grep Disk - see harddisk size

Running a command at a specified time, using the "at" command. Execution of the job(s) depends on
system time, not the time of submission. atq, atrm, batch
Regularly running a command on a monthly, weekly, daily or hourly basis, using the "cron" facilities

More ways to view file content from shell..

cat, pg, less, more, head, tail ... explore n have fun !

sticky bit mode, suid, sgid - special bit modes on files besides "rwxrwxrwx"

ebook on intro to linux

Read this ebook on getting started..it covers even basics of stuff, but covers some important concepts that need to be understood..
http://tldp.org/LDP/intro-linux/intro-linux.pdf

Virtualization Rocks!!

I wanted to try out ubuntu, slitaz and opensuse for some hands on experience.

Oracle Virtual VM box (https://www.virtualbox.org/wiki/Downloads ) helped me a lot. My laptop has good config of RAM and hard disk space and VM box helped me to set up these several instances. Its cool to switch to whichever OS i want to set up and play with.

Virtualization Rocks!!

Boot Linux from USB

Its awesome experience to install slitaz cooking.iso on usb. Set your machine boot device to USB. There you go! The entire process took hardly 10 mins!

Follow link for more details - http://www.pendrivelinux.com/install-slitaz-to-usb-from-windows/

Linux

Close to decade of experience on working on Microsoft Windows Platform and allied technologies...
Looking for some fresh wave of excitement to feed my restless and curious brain...
Heard buzz words about Hadoop, Big Data, Ubuntu, LAMP technology stack, VoltDB Architecture, Android architecture, etc etc..and started reading theory about all of them, one by one...
There is one thing common that I realize how I missed out exploring all these years...Linux!!
Though Microsoft technologies abstract (closed source) all beautiful concepts to developer (letting him worry about only right click and add web service reference), I find happiness in exploring the underlying concept. And here is an Open Source Operating System (used on all sorts of h/w devices from laptops, pcs to servers, embedded, mobile devices and list will continue to grow forever) which was baring it all, waiting to be explored and where was I/what was I doing!!
Open Source vs Closed - I am not the type of guy who thinks there is only one way of doing things or there is only one solution to solve all problems. Its all about chosing the right approach based on your strengths/weakness. If you have a great talented set of people and are as capable as Apple in being innovative, execution and terrific marketing, you are better of being Closed Source and controlling end-end. Otherwise, I think Open Source will let you attract great talent across the world to evolve your Open Source project to the best - If it is truly great concept, it will attract the best!