Thursday, May 29, 2014

About NTTF (Nettur Technical Training Foundation)

Referred URL - http://www.nisaptham.com/2014/05/blog-post_29.html

5 Keys to Becoming Indispensable at Work by Chris Gaborit

Referred URL - http://www.linkedin.com/today/post/article/20140528220051-14485653-5-keys-to-become-indispensable-at-work?trk=tod-home-art-list-large_0


here are times when every business is going through a restructure. Some companies seem to do this every few years, some every year, and some seem to be undergoing one eternal restructure!
Have you ever noticed that some people are restructure proof? Fear does not grip their body at the mention of that word. They never leave. They never get demoted. They are important to the company.
This reminds me of a story. Please excuse me; we are a training company, so there is always a story.
A big corporation hired several cannibals. "You are all part of our team now," said the HR manager during the welcome briefing. "You get all the usual benefits and you can go to the cafeteria for something to eat, but please don't eat any of the other employees."
The cannibals promised they would not.
A few weeks later, the cannibals' boss remarked, "You're all working very hard, and I'm satisfied with you. However, one of our secretaries has disappeared. Do any of you know what happened to her?" The cannibals all shook their heads, "No," they said.
After the boss left, the leader of the cannibals said to the others angrily, "Right, which one of you idiots ate the secretary?" A hand rose hesitantly in admission. "You fool!" said the leader. "For weeks, we've been eating managers and no one noticed anything, but noooooo, you had to go and eat someone important!"
Are you someone important to your company? Would they miss you if you were no longer there?
When most people hear that dreaded word ‘restructure,' fear fills their mind and the thought arises: “Am I going to be made redundant?” This is generally followed by a blubbering cry of, “Who will hire me? I have a mortgage to pay, car payments, and I need money to wash the dog!”
How can we make sure that we are someone important? What can we do to be in the best position to remain in the company? How can we be one of those people that are indispensable?
In my preparation for writing this blog, I decided to get some wisdom from people I respect. I asked some of our best clients — senior managers who work for global companies. These people have walked the walk; they have been bulletproof when it comes to restructure.
These are their 5 Keys to Becoming Indispensable at Work:
1. Hold the mindset that change provides opportunity.
There is an ancient wisdom etched into Chinese vocabulary. The Chinese ideogram for crisis consists of two separate characters. One means danger; the other means opportunity. The proper translation is that a crisis is a dangerous opportunity. When confronted with a crisis, you need to recognise both the danger and the opportunity. Often the danger is more readily apparent, while the opportunity can be deftly concealed. The thing to keep in mind is to look for the opportunity as well as the danger. Crisis holds the potential for both.
In studying hundreds of famous people, whether politicians, sportspeople, business people, or spiritual leaders, I have found that crisis comes to every person in some way. Those who rise in the midst of crisis and see it as an opportunity to change and grow become greater and more powerful. They reach heights that they would never have attained had they never experienced that crisis. As masterful innovator Walt Disney put it, “You may not realise it when it happens, but a kick in the teeth might be the best thing in the world for you.”
When change is imminent, hold the mindset that change provides opportunity, remain positive, and don’t dwell on the danger but dwell on the opportunity.
2. Do not overfocus on the next job position but rather on the skills to be developed.
I think that most people today are aware that the company does not have the same amount of loyalty to you that they used to a few years ago. There was a time the company would have a track for your life. You could go and meet with your manager and they could tell you where you are going and when you will get there.
Today, you are your manager and you need to plan out your own career path to your dream job. Therefore, it is important that you are not focused on the job position, but rather on the skills required.
I like to say it like this: “You have to do the job before you get the title.” In other words, if you want to be the CIO, then you need to develop the hard and soft skills required for a CIO; you need the education of a CIO, you need to start dressing like a CIO, acting like a CIO, speaking like a CIO, and then one day, when you have had the right amount of experience, someone is going to say, “I think Jessica would make a great CIO!”
3. Building relationships with key decision makers.
It’s not only what you know but whom you know. I have seen people scoot all the way up the ladder of a company through being connected closely with key decision makers.
Think of football coaches: they build their team and work with players for years, and then they get headhunted to another club as head coach, and what is the first thing they do? They try to get their key players to move to the new club, as well. They are like a positive cliché. Where one goes, they all go. Some coaches and key players move together all the way through their playing life.
Why? Because just as the players think that the coach has made them succeed, the coach thinks that the players have helped him or her succeed. They are a powerful team, and they feel powerful together. Sir Edmund Hillary needed Tenzing Norgay to climb Everest. We all need to find an “internal coach” whom we can work with and who would support us to climb our Everest.
4. Exhibit the ability to get ‘stuff’ done.
How do you build these key relationships? You build them by working on projects with key stakeholders, complimenting their skills, and making them look good.
As one senior manager put it to me, “Over the years, I’ve had the opportunity to work for some great ‘blue sky’ leaders, but they couldn’t project-manage their way out of a lunch bag. While I’ve probably not been the best at brainstorming new and creative ideas, in many situations I’ve been able to take their ‘kernel’ of an idea, pour some fertiliser on it, and make it grow and flourish into a great program and actually implement it.”
In projects, there are two key parts--the front end and the back end, people and tasks, marketing and operations, talkers and doers. If the key stakeholder is a talker, then you need to be a doer. If you are the key doer to the key stakeholder, then you ain't going nowhere fast! They need you to keep making their projects succeed.
5. Treat everyone with genuine respect.
It’s not just about managing well, but also about how you treat your peers, team members, and vendors alike. You never know who you may be working for or with some day, so treat everyone as you’d want to be treated and keep confidences when someone confides in you and wants some advice. As one senior manager in a global I.T. company put it to me, “I believe in creating good karma with those you interact with.”
Along with the other things I have mentioned, this will stand you in good stead with decision makers and bring you allies and supporters in the organisation. When business takes a turn for the worse and they’re considering who to cut, you often won’t make the list if you have built those relationships and have shown the ability to deliver with quality over and over again.

Tuesday, May 20, 2014

How to get more Interview calls easily

After I'm completing 2.5 years in Software industry as developer in India, I planned for a Job swap and I was trying out for various tips for getting more calls. I hope this will be useful for you guys as well.

First Remember, Recruiters prefer persons joining immediate/ soon than late. (Immediate Joinees will get more offers and joining bonus.) 

Tip - If you have lengthier notice period, Better apply this below tips, observe for how much calls you get then apply resignation and try attending the interview.

1) Ensure to update your Job Portal profile first. (In My case for India, Naukri and Monster)
  • Step 1 - Add 'Available Earliest' in Resume Headline before your Headline text.
  • Step 2 - Update the Key Skills with all possible applicable and Known technology separated with comma.
  • Step 3 - Update your employment history details with notice period of 'less than 15 days'.
  • Step 4 - Update your profile daily before 10 AM. So the recently updated profile will be listed first for recruiters.  

2) Ensure to get joining bonus, If you are joining immediately or within a one month. (Range - Equal to your one salary will be preferable)

3) If you are relocating, Ask for relocation reimbursement when they are offering.

4) Try for claiming the notice period payout, If you are paying from your pocket.

Feel free to reach me if you need more idea. :)

Wednesday, May 14, 2014

13 Places You Should Visit In India Before You Visit Their Counterparts Abroad

Referred URL - http://www.scoopwhoop.com/news/india-abroad/

Indians are travelling like never before and going to countries all over the world. But a lot of us seem to forget that what we seek abroad, we can find as easily in our own country. This doesn’t mean that one shouldn’t travel abroad, but it does mean that one should travel within India and witness all its marvels before we step out into the world. So here are a few places you should visit in India before you visit their counterparts abroad.

1. Before you get lost in the beauty of Switzerland,


Source

Find your piece of paradise in Kashmir.


Source

2. Before you get drenched at the Niagara Falls,


Source

Get drenched at the Chitrakoot Falls in Chhattisgarh.


Source

3. Before you surf the sands of the Sahara,


Source

Tame the dunes of the Thar.


Source

4. Before you visit the Bonneville Salt Flats in America,


Source

Visit the Rann of Kutch in Gujarat.


Source

5. Before you take a trip to Madagascar,


Source

Take a trip to the Andamans.


Source

6. Before you chill on the beaches of Brazil,


Source

Give the beaches of Goa a chance.


Source

7. Before you go “Woah” about the bridges in Taiwan,


Source

Go “Hoodi-Baba” at Howrah Bridge in Kolkata.


Source

8. Before you feast your eyes on the flowers in Antelope Valley in the U.S.A,


Source

Drink in the colours of the Valley of Flowers in Uttarakhand.


Source

9. Before you hear the roar of the African Lion,


Source

Be awed by the majesty of the Royal Bengal Tiger.


Source

10. If it’s French architecture you crave, why go all the way to Saigon in Vietnam,


Source

When you can see it all in Pondicherry in India?


Source

11. Before taking a stroll in a Japanese flower garden,


Source

Take a romantic walk in Nainital.


Source

12. Before you get dwarfed by the statue of “Christ The Redeemer” in Brazil,


Source

Get dwarfed by Saint Thiruvalluvar’s statue in Kanyakumari.


Source

13. And before you take selfies at the Arc de Triomphe in France,


Source

Feel proud and take one at India Gate in New Delhi.


Source



“Your vision becomes clear when you look inside your heart. Who looks outside, dreams. Who looks inside, awakens.” - Carl Jung

Abraham Lincon's Letter for Son's Teacher

ஒரு தந்தை தன் மகனைத் துவக்கப் பள்ளியில் சேர்த்தார். அவர் தன் மகனுக்கு அறிவுரை சொல்லவில்லை. பள்ளி ஆசிரியருக்கு அவர் எழுதிய கடிதங்களின் சில பகுதிகள்!

தோல்வியை ஏற்றுக்கொள்ளவும், வெற்றியைக் கொண்டாடவும் என் மகனுக்குக் கற்றுக் கொடுங்கள்.

பொறாமையிலிருந்து அவன் விலகியே இருக்கட்டும்.

வானப்பறவைகள், தேனீக்கள், சூரியன், பசுமையான செடிகள், மலர்கள் இவற்றை ரசிக்க அவனுக்குக் கற்றுக் கொடுங்கள்.

பிறரை ஏமாற்றுவதை விட, தோற்பது கண்ணியம் என்று அவனுக்குக் கற்றுக் கொடுங்கள்.

சுய சிந்தனையில் நம்பிக்கை கொள்ளச் சொல்லுங்கள்.

மென்மையானவர்களிடம் மென்மையாகவும், உறுதியானவர் களிடம் உறுதியாகவும் நடந்து கொள்ளக் கற்றுக் கொடுங்கள்.

குற்றம் குறை கூறுபவர்களை அவன் அலட்சியப்படுத்தட்டும்.
அளவுக்கு அதிகமாய் இனிமையாகப் பேசுபவர்களிடம் அவன் எச்சரிக்கையாக இருக்க வேண்டும்

தன் மனதுக்கு சரி என்று தோன்றுவதை அவன் துணிந்து நின்று போராடி நிறைவேற்ற அவனைப் பழக்குங்கள்.

இதை எழுதிய தந்தை ஆப்ரஹாம் லிங்கன்

Tuesday, May 13, 2014

8 Most common mistakes C# developers make

Referred URL -
http://blog.goyello.com/2013/01/07/8-most-common-mistakes-c-developers-make/

While working with (young) C# programmers I’ve noticed that some mistakes are being repeated by almost every one of them. These are mostly the mistakes, which once you point them, are quite easy to remember. However, if a developer is not aware of them, they can cause many problems with the efficiency and quality of the developed software. Therefore, I decided to gather the 8 most common mistakes made.

1. String concatenation instead of StringBuilder

String concatenation works in such a way that every time when you add something to a string, a new address in the memory is being allocated. The previous string is copied to a new location with the newly added part. This is inefficient. On the other hand we have StringBuilder which keeps the same position in the memory without performing the copy operation. Thanks to the strings’ appending by means of StringBuilder the process is much more efficient, especially in case of hundreds of append operations.
1
2
3
4
5
6
7
//INCORRECT
List values = new List(){"This ","is ","Sparta ","!"};
string outputValue = string.Empty;
foreach (var value in values)
{
   outputValue += value;
}

1
2
3
4
5
6
//CORRECT
StringBuilder outputValueBuilder = new StringBuilder();
foreach (var value in values)
{
   outputValueBuilder.Append(value);
}

2. LINQ – ‘Where’ with ‘First’ instead of FirstOrDefault

A lot of programmers find a certain set of elements by means of ‘Where’ and then return the first occurrence. This is inappropriate, because the ‘First’ method can be also applied with the ‘Where’ condition. What’s more, it shouldn’t be taken for granted that the value will always be found. If “First” is used when no value is found, an exception will be thrown. Thus, it’s better to use FirstOrDefault instead. When using FirstOrDefault, if no value has been found, the default value for this type will be returned and no exception will be thrown.
1
2
3
//INCORRECT
List numbers = new List(){1,4,5,9,11,15,20,21,25,34,55};
return numbers.Where(x => Fibonacci.IsInFibonacciSequence(x)).First();

1
2
//PARTLY CORRECT
return numbers.First(x => Fibonacci.IsInFibonacciSequence(x));

1
2
//CORRECT
return numbers.FirstOrDefault(x => Fibonacci.IsInFibonacciSequence(x));

3. Casting by means of ‘(T)’ instead of ‘as (T)’ when possibly not castable

It’s common that software developers use simple ‘(T)’ casting, instead of ‘as (T)’. And usually it doesn’t have any negative influence because casted objects are always castable. Yet, if there is even a very slight probability that an object can be under some circumstances not castable, „as (T)” casting should be used. See Difference Between C# Cast Syntax and the AS Operators for more details.
1
2
//INCORRECT
var woman = (Woman)person;

1
2
//CORRECT
var woman = person as Woman;

4. Not using mapping for rewriting properties

There are a lot of ready and very powerful C# mappers (e.g. AutoMapper). If a few lines of code are simply connected with rewriting properties, it’s definitely a place for a mapper. Even if some properties aren’t directly copied but some additional logic is performed, using a mapper is still a good choice (mappers enable defining the rules of rewriting properties to a big extend).

5. Incorrect exceptions re-throwing

C# programmers usually forget that when they throw an exception using „throw ex” they loose the stack trace. It is then considerably harder to debug an application and to achieve appropriate log messages. When simply using „throw” no data is lost and the whole exception together with the stack trace can be easily retrieved.
01
02
03
04
05
06
07
08
09
10
//INCORRECT
try
{
   //some code that can throw exception [...]
}
catch (Exception ex)
{
   //some exception logic [...]
   throw ex;
}

01
02
03
04
05
06
07
08
09
10
//CORRECT
try
{
   //some code that can throw exception [...]
}
catch (Exception ex)
{
   //some exception logic [...]
   throw;
}

6. Not using ‘using’ for objects disposal

Many C# software developers don’t even know that ‘using’ keyword is not only used as a directive for adding namespaces, but also for disposing objects. If you know that a certain object should be disposed after performing some operations, always use the ‘using’ statement to make sure that the object will actually be disposed.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
//the below code:
using(SomeDisposableClass someDisposableObject = new SomeDisposableClass())
{
   someDisposableObject.DoTheJob();
}
//does the same as:
SomeDisposableClass someDisposableObject = new SomeDisposableClass();
try
{
   someDisposableObject.DoTheJob();
}
finally
{
   someDisposableObject.Dispose();
}

7. Using ‘foreach’ instead of ‘for’ for anything else than collections

Remember that if you want to iterate through anything that is not a collection (so through e.g. an array), using the ‘for’ loop is much more efficient than using the ‘foreach’ loop. See Foreach vs For Performance for more details.

8. Retrieving or saving data to DB in more than 1 call

This is a very common mistake, especially among junior developers and especially when using ORMs like Entity Framework or NHibernate. Every DB call consumes some amount of time and therefore it’s crucial to decrease the amount of DB calls as much as possible. There are many ways to do so:
  • Using fetching (Eager Loading)
  • Enclosing DB operations in transactions
  • In case of a really complex logic, just moving it to the DB by building a stored procedure
It goes without saying that there are hundreds of other types of mistakes made by C# programmers. If you know any interesting ones or you want to share your opinion about the subject, feel free to leave a comment below! 
If you would like to read more about common mistakes of C# developers read this post.

Friday, May 2, 2014

C# FTP Library from CodePlex

Referred URL - http://ftplib.codeplex.com/

Project Description This library wraps the wininet.dll functions for FTP to create an effective way to interact with FTP servers using the C# language and the .Net framework.

Sample Code
using (FtpConnection ftp = new FtpConnection("ftpserver", "username", "password"))
            {
               
                ftp.Open(); /* Open the FTP connection */
                ftp.Login(); /* Login using previously provided credentials */

                if (ftp.DirectoryExists("/incoming")) /* check that a directory exists */
                    ftp.SetCurrentDirectory("/incoming"); /* change current directory */

                if (ftp.FileExists("/incoming/file.txt"))  /* check that a file exists */
                    ftp.GetFile("/incoming/file.txt", false); /* download /incoming/file.txt as file.txt to current executing directory, overwrite if it exists */

                //do some processing

                try
                {
                    ftp.SetCurrentDirectory("/outgoing");
                    ftp.PutFile(@"c:\localfile.txt", "file.txt"); /* upload c:\localfile.txt to the current ftp directory as file.txt */
                }
                catch (FtpException e)
                {
                    Console.WriteLine(String.Format("FTP Error: {0} {1}", e.ErrorCode, e.Message));
                }

                foreach(var dir in ftp.GetDirectories("/incoming/processed"))
                {
                    Console.WriteLine(dir.Name);
                    Console.WriteLine(dir.CreationTime);
                    foreach (var file in dir.GetFiles())
                    {
                        Console.WriteLine(file.Name);
                        Console.WriteLine(file.LastAccessTime);
                    }
                }
            }

How To Fix Martin Fowler's Estimating Problem in 3 Easy Steps by Martin Fowler

Referred URL - http://herdingcats.typepad.com/my_weblog/2014/04/how-to-fix-martin-fowlers-estimating-problem-in-3-erasy-steps-1.html

Martin Fowler has a nice post about estimating software development projects in an agile paradigm.
It starts like this
Screen Shot 2014-04-30 at 9.36.54 AM
First Bullet
When asked to produce or handed an estimate, respond with the following:
  • What confidence level are you needing for the estimate you're asking us to do?
  • What confidence level have you assign to those estimates you handed me?
  • What is the shape of the Probability Distribution for those estimates you want me to use?
  • No answers to these questions from the High School Statistics class? These are pure guesses and we're going to be late and over budget before we start.
Here's how to fix this
  • Look to similar past performance work to see if we can extract classes of work that can be used as the basis of estimating the new work.
  • Don't have any past performance, ask if this project is inventing new physics, because that's the only reason it hasn't been done before. Go ask someone, go on the web forums and search around, go down to the cafeteria and ask, go across the street to Star Bucks and ask. 
  • Better yet, go cobble together a walking skeleton to see if we can build our own reference class.
  • DO NOT GUESS, use agile to find out before we proceed.
  • Assign a confidence interval to all the estimates so we can determine where the problem children are and record that confidence for later.
  • Establish agreement - this is an agile team and full and open communication with the customer and management is part of any functioning agile team - on the credibility of the estimates and their proper use.
  • The Straw man of management misuse in an agile paradigm is just that a straw man, don't let it happen, stop whining, stop being Dilbert. Insist on behaving in the agreed manner as members of the agile team, otherwise we are just AINO (Agile in Name Only).
Second Bullet
Using estimates during development
Here's how to fix this
  • When those statistically acceptable set of estimates are arrived at, make them part of the release plan. And make sure their confidence intervals are publicly visible and can't be ignored - the BIG VISIBLE CHART is one way.
  • Color coding can work. Standard Deviations from the Mean can work. Anything can work as long as it is recorded in the plan, agreed to by the team - remember those agreement processes we did when we formed the agile team.
  • Revisit those confidence intervals and the Most Likely † value for the estimate every time we release something, start to work on the next release, or do anything that impacts our confidence in the estimates. 
Third Bullet
Misuse of a statistical estimator is common in communities that don'y understand the nature of project work - all variables on projects are probabilistic.
Here's How to Fix This
  • Actuals HAVE to be different than the estimate. That's why it's call an ESTIMATE
  • Go back to the High School Statistics book and reread the definition of an estimate. Don't let anyone tell us estimating is guessing. If they do, they didn';t take that High School Stats class
An estimate is an indication of the value of an unknown quantity based on observed data or a model of the possible values that would be observed.
  • Adjust those estimates for actual work. Adjust them for anything and everything that impacts the work.
Estimating the furture is not about controlling the future, it's about being prepared to respond to the emerging possibilities of the future
When we fail to recognize that all project work is probabilistic, and we have a need to know about about what might probabilistically happen we will always be responding to changes, rather than anticipating the changes and being prepared to respond.
But always remember, every number of a project, including our confidence that we've got bullet proof code ready to put into production on a moments notice is a probabilistic number. Speaking about any number in the absence of the confidence interval of the number is Guessing.  
Probability and Statistics
And as that building sized safety poster at Rocky Flats Environmental Technology Site used to say
Don't Do Stupid Things On Purpose
† Most Likely is NO the average. Never use average or allow anyone to speak to us about the average. The most likely number is the Mode. That's the number that will occur most often in all probabilistically driven work. Learn to think like a developers working in a statistically driven world - that's called the Real World, where uncertainty reigns. Remember the difference between probability and statistics in the picture above. We are subject to both in everything we do.
Probability Distribution