Tuesday, June 23, 2015

Do Think OUT of BOX

These are few questions asked in an interview! The answers are really stunning and inspiring.

Thinking out of the box! A must read…

Question 1:

You are driving along in your car on a wild, stormy night, it’s raining heavily, when suddenly you pass by a bus stop, and you see three people waiting for a bus:

  1. An old lady who looks as if she is about to die.
  2. An old friend who once saved your life.
  3. The perfect partner you have been dreaming about.
Which one would you choose to offer a ride to, knowing very well that there could only be one passenger in your car?

This is a moral/ethical dilemma that was once actually used as part of a job application.

He simply answered:
I would give the car keys to my Old friend and let him take the lady to the hospital. I would stay behind and wait for the bus with the partner of my dreams.

Sometimes, we gain more if we are able to give up our stubborn thought limitations. Never forget to Think Outside of the Box.?

Question 2:

What will you do if I run away with your sister?

The candidate who was selected answered, “I will not get a better match for my sister than you sir”

Question 3:

Interviewer (to a student girl candidate) : What if one morning you woke up & found that you were pregnant.

Girl – I will be very excited and take an off, to celebrate with my husband.

Normally an unmarried girl will be shocked to hear this, but she managed it well. Why I should think it in the wrong way, she said later when asked.

Question 4:

Interviewer: He ordered a cup of coffee for the candidate. Coffee arrived kept before the candidate, then he asked what is before you?

Candidate: Instantly replied: “Tea”

He got selected.

You know how and why did he say TEA, when he knows very well that coffee was kept before.
(Answer: The question was What is before you (U, alphabet) Reply was TEA ( T, alphabet). Alphabet T is before Alphabet U.

Question5:

Interviewer said: “I shall either ask you ten easy questions or one really difficult question.”

Think well before you make up your mind! The boy thought for a while and said, my choice is one really difficult question.?

Well, good luck to you, you have made your own choice!

Now tell me this. What comes first, Day or Night?

The boy was jolted into reality as his admission depends on the correctness of his answer, but he thought for a while and said, “It’s the DAY sir!?”

How? the interviewer asked.

Sorry sir, you promised me that you will not ask me a SECOND difficult question!?

Sometimes just thinking out of the box is all it takes!
Share with your friend and give them a special moment of thinking…!!

.

Source: http://funnychutkule.com/1990/very-difficult-questions-with-amazing-answers-out-of-the-box-thinking/

Who the hell is Agile?

Agile Methodology

The goal of Agile Methods is to allow an organization to be agile, but what does it mean to be Agile? Agile means being able to “Deliver quickly. Change quickly. Change often” While Agile techniques vary in practices and emphasis, they share common characteristics, including iterative development and a focus on interaction, communication, and the reduction of resource-intensive intermediate artifacts. 

Developing in iterations allows the development team to adapt quickly to changing requirements. Working in close location and focusing on communication means teams can make decisions and act on them immediately, rather than wait on correspondence. Reducing intermediate artifacts that do not add value to the final deliverable means more resources can be devoted to the development of the product itself and it can be completed sooner. These characteristics add maneuverability to the process, whereby an Agile project can identify and respond to changes more quickly than a project using a traditional approach. 

Agile Methods

Agile Methods have much in common, such as what they value, but they also differ in the practices they suggest. In order to characterize different methods, we will examine the following Agile Methods:
  • Extreme Programming
  • Scrum
  • Crystal Methods
  • Feature Driven Development
  • Lean Development
  • Dynamic Systems Development Methodology.

Extreme Programming

Extreme Programming is undoubtedly the hottest Agile Method to emerge in recent years. Introduced by Beck, Jeffries, and further popularized by Beck’s Extreme Programming. XP owes much of its popularity to developers disenchanted with traditional methods looking for something new, something extreme. The 12 rules of Extreme Programming, true to the nature of the method itself, are concise and to the point. In fact, you could almost implement XP without reading a page of Beck’s book.

• The planning game: At the start of each iteration, customers, managers, and developers meet to flesh out, estimate, and prioritize requirements for the next release. The requirements are called “user stories” and are captured on “story cards” in a language understandable by all parties.

• Small releases: An initial version of the system is put into production after the first few iterations. Subsequently, working versions are put into production anywhere from every few days to every few weeks.

• Metaphor: Customers, managers, and developers construct a metaphor, or set of metaphors after which to model the system.

• Simple design: Developers are urged to keep design as simple as possible, “say everything once and only once”.

• Tests: Developers work test-first; that is, they write acceptance tests for their code before they write the code itself. Customers write functional tests for each iteration and at the end of each iteration, all tests should run.

• Refactoring: As developers work, the design should be evolved to keep it as simple as possible.

• Pair programming: Two developers sitting at the same machine write all code.

• Continuous integration: Developers integrate new code into the system as often as possible. All functional tests must still pass after integration or the new code is discarded.

• Collective ownership: The code is owned by all developers, and they may make changes anywhere in the code at anytime they feel necessary.

•On-site customer: A customer works with the development team at all times to answer questions, perform acceptance tests, and ensure that development is progressing as expected.

• 40-hour weeks: Requirements should be selected for each iteration such that developers do not need to put in overtime.

• Open workspace: Developers work in a common workspace set up with individual workstations around the periphery and common development machines in the center. Because the development team needs to be co-located, team size is limited to the number of people that can fit in a single room, generally agreed to be from 2 to 10.

Iteration length: XP has the shortest recommended iteration length of the Agile Methods under consideration, 2 weeks.

Support for distributed teams: Because of XP’s focus on community and collocation, distributed teams are not supported.

System criticality: XP is not necessarily geared for one system or another. However, most agree that there is nothing in XP itself that should limit its applicability. 

Scrum 

Scrum, along with XP, is one of the more widely used Agile Methods.

Pre-sprint planning: All work to be done on the system is kept in what is called the “release backlog.” During the pre-sprint planning, features and functionality are selected from the release backlog and placed into the “sprint backlog,” or a prioritized collection of tasks to be completed during the next sprint. Since the tasks in the backlog are generally at a higher level of abstraction, pre-sprint planning also identifies a Sprint Goal reminding developers why the tasks are being performed and at which level of detail to implement them

Sprint: Upon completion of the pre-sprint planning, teams are handed their sprint backlog and “told to sprint to achieve their objectives”. At this point, tasks in the sprint backlog are frozen and remain unchangeable for the duration of the sprint. Team members choose the tasks they want to work on and begin development. Short daily meetings are critical to the success of Scrum. Scrum meetings are held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.

Post-sprint meeting: After every sprint, a post-sprint meeting is held to analyze project progress and demonstrate the current system.

Key principles of Scrum:

• Small working teams that maximize communication, minimize overhead, and maximize sharing of tacit, informal knowledge.

• Adaptability to technical or marketplace (user/customer) changes to ensure the best possible product is produced. Frequent ‘builds,’ or construction of executables, that can be inspected, adjusted, tested, documented, and built on.

• Partitioning of work and team assignments into clean, low coupling partitions, or packets.

• Constant testing and documentation of a product as it is built.

• Ability to declare a product ‘done’ whenever required (because the competition just shipped, because the company needs the cash, because the user/customer needs the functions, because that was when it was promised.

Team size: Development personnel are split into teams of up to seven people. A complete team should at least include a developer, quality assurance engineer, and a documenter.Iteration length: While Schwaber originally suggested sprint lengths from 1 to 6 weeks, durations are commonly held at 4 weeks.

Support for distributed teams: While Scrum’s prescription does not explicitly mention distributed teams or provide built-in support; a project may consist of multiple teams that could easily be distributed.

System criticality: Scrum does not explicitly address the issue of criticality. 

The Crystal Methods

To the extent that you can replace written documentation with face-to-face interactions, you can reduce the reliance on written work products and improve the likelihood of delivering the system. The more frequently you can deliver running, tested slices of the system, the more you can reduce the reliance on written ‘promissory’ notes and improve the likelihood of delivering the system” As you add people to the project, you translate right on the graph in to more opaque versions of crystal. As project criticality increases, the methods “harden” and you move upwards on the graph. The methods can also be altered to fit other priorities, such as productivity or legal liability. All Crystal methods begin with a core set of roles, work products, techniques, and notations, and this initial set is expanded as the team grows or the method hardens.

Team size: The Crystal Family accommodates any team size; however, Cockburn puts a premium on premium people.

Iteration length: Up to 4 months for large, highly critical projects.

Support for distributed teams: Crystal Methodologies have built in support for distributed teams.

System criticality: Crystal supports 4 basic criticalities: failure resulting in loss of comfort, discretionary money, essential money, and life.  

Feature Driven Development 

FDD’s core values:

• A system for building systems is necessary in order to scale to larger projects.

• A simple, well-defined process works best.

• Process steps should be logical and their worth immediately obvious to each team member.

• ‘Process pride’ can keep the real work from happening.

• Good processes move to the background so the team members can focus on results.

• Short, iterative, feature-driven life cycles are best.

Develop an overall model: The FDD process begins with developing a model. Team members and experts work together to create a “walkthrough” version of the system.

Build a features list: Next, the team identifies a collection of features representing the system. Features are small items useful in the eyes of the client. They are similar to XP story cards written in a language understandable by all parties. Features should take up to 10 days to develop. Features requiring more time than 10 days are broken down into sub features.

Plan by feature: The collected feature list is then prioritized into subsections called “design packages.” The design packages are assigned to a chief programmer, who in turn assigns class ownership and responsibility to the other developers. Design by feature & build by feature: After design packages are assigned, the iterative portion of the process begins. The chief programmer chooses a subset of features that will take 1 to 2 weeks to implement. These features are then planned in more detail, built, tested, and integrated.

Team size: Team size varies depending on the complexity of the feature at hand

Iteration length: Up to two weeks.

Support for distributed teams: FDD is designed for multiple teams and, while it does not have built-in support for distributed environments, it should be adaptable.Criticality: The FDD prescription does not specifically address project criticality. 

Lean Development

Lean Development’s12 principles focus on management strategies:

(1) Satisfying the customer is the highest priority.

(2) Always provide the best value for the money.

(3) Success depends on active customer participation.

(4) Every LD project is a team effort.

(5) Everything is changeable.

(6) Domain, not point, solutions.

(7) Complete, do not construct.

(8) An 80 percent solution today instead of 100 percent solution tomorrow.

(9) Minimalism is essential.

(10) Needs determine technology.

(11) Product growth is feature growth, not size growth.

(12) Never push LD beyond its limits.Because LD is more of a management philosophy than a development process, team size, iteration length, team distribution, and system criticality are not directly addressed.   

Dynamic Systems Development Method 

DSDM lifecycle has six stages: Pre-project, Feasibility Study, Business Study, Functional Model Iteration, Design and Build Iteration, Implementation, and Post-project.  

Pre-project: The pre-project phase establishes that the project is ready to begin, funding is available, and that everything is in place to commence a successful project.  

Feasibility study: DSDM stresses that the feasibility study should be short, no more than a few weeks. Along with the usual feasibility activities, this phase should determine whether DSDM is the right approach for the project.

Business study: The business study phase is “strongly collaborative, using a series of facilitated workshops attended by knowledgeable and empowered staff who can quickly pool their knowledge and gain consensus as to the priorities of the development”. The result of this phase is the Business Area Definition, which identifies users, markets, and business processes affected by the system.

Functional model iteration: The functional model iteration aims to build on the high-level requirements identified in the business study. The DSDM framework works by building a number of prototypes based on risk and evolves these prototypes into the complete system. This phase and the design and build phase have a common process:(1) Identify what is to be produced.(2) Agree how and when to do it.(3) Create the product.(4) Check that it has been produced correctly (by reviewing documents, demonstrating a prototype or testing part of the system)

Design and build iteration: The prototypes from the functional model iteration are completed, combined, and tested and a working system is delivered to the users.

Implementation: During this phase, the system is transitioned into use. An Increment Review Document is created during implementation that discusses the state of the system. Either the system is found to meet all requirements and can be considered complete, or there is missing functionality (due to omission or time concerns). If there is still work to be done on the system, the functional model, design and build, and implementation phases are repeated until the system is complete.

Post-project: This phase includes normal post-project clean-up, as well as ongoing maintenance.Because of DSDM’s framework nature, it does not specifically address team size, exact iteration lengths, distribution, or system criticality. 

Agile Modeling 

Agile Modeling (AM) is proposed by Scott Ambler. It is a method based on values, principles and practices that focus on modeling and documentation of software. AM recognizes that modeling is a critical activity for a project success and addresses how to model in an effective and Agile manner.

The three main goals of AM are:

(1) To define and show how to put into practice a collection of values, principles and practices that lead to effective and lightweight modeling.

(2) To address the issue on how to apply modeling techniques on Agile software development processes.

(3) To address how you can apply effective modeling techniques independently of the software process in use.

AM is not a complete software development method. Instead, it focuses only on documentation and modeling and can be used with any software development process. You start with a base process and tailor it to use AM. Ambler illustrates, for example, how to use AM with both XP and Unified Process (UP) The values of AM include those of XP—communication, simplicity, feedback and courage—and also include humility. It is critical for project success that you have effective communication in your team and also with the stakeholder of the project. You should strive to develop the simplest solution that meets your needs and to get feedback often and early. You should also have the courage to make and stick to your decisions and also have the humility to admit that you may not know everything and that others may add value to your project effortsSince AM is not a complete software process development method and should be used with other development methods, the team size, exact iteration lengths, distribution and system criticality will depend on the development process being used. 

Conclusions
Agile Methods are here to stay, no doubt about it. Agile Methods will probably not “win” over traditional methods but live in symbiosis with them. While many Agile proponents see a gap between Agile and traditional methods, many practitioners believe this narrow gap can be bridged. Glass even thinks that “[t]raditionalists have a lot to learn from the Agile folks” and that “traditional software engineering can be enriched by paying attention to new ideas springing up from the field”. 

Why will Agile Methods not rule out traditional methods?
Agile Methods will not out rule traditional methods because diverse processes for software engineering are still needed. Developing software for a space shuttle is not the same as developing software for a toaster. Not to mention that the need to maintain software, typically a much bigger concern than development, also differs according to the circumstances. Software maintenance is, however, not an issue discussed in Agile circles yet, probably because it is too early to draw any conclusions on how Agile Methods might impact software maintenance. 

Where is Agile going?
Agile is currently an umbrella concept encompassing many different methods. XP is the most well known Agile Method. While there may always be many small methods due to the fact that their proponents are consultants who need a method to guide their work, we expect to see some consolidation in the near future. We compare the situation to events in the object-oriented world in the 1990s, where many different gurus promoted their own methodology. 

In a few years, Rational, with Grady Booch, became the main player on the method market by recruiting two of the main gurus: James Rumbaugh (OMT) and Ivar Jacobsson (Objectory). Quickly the “three amigos” abandoned the endless debates regarding whose method was superior, which mainly came down to whether objects are best depicted as clouds (Booch), rectangles (OMT), or circles (Objectory), and instead formed a unified alliance to quickly become the undisputed market leader for object-oriented methods. 

We speculate that the same can happen to the Agile Methods, based, for example, on the market-leader XP. Even if the Agile consolidation is slow or non-existent, what most likely will happen, independent of debates defining what is and is not Agile, practitioners will select and apply the most beneficial Agile practices. They will do so simply because Agile has proven that there is much to gain from using their approaches and because of the need of the software industry to deliver better software, faster and cheaper.                                                         

Looks like the Explorer is jumping to No man’s Land..

Here comes the amplification of Microsoft's product Internet Explorer getting obsolete.

With the development of Windows 10, microsoft has its plan to bring in alternate for Internet explorer. Hence bringing a light weight browser (yet to be named officially, but unofficially called as spartan), which is similar to Google chrome (or) Mozilla firefox. With windows 10, both the browsers will be available for use along with the operating system pack.

After windows 10, microsoft is thinking whether to continue with internet explorer or not. But the existing OS services, where the IE is available, the services and support would still continue.

So the long continued browser started in 1994 with version 1.0 has made its all its way to version 1.12 here in 2015. Lets hear for further updates from Microsoft.

Source: http://www.techradar.com/news/internet/microsoft-is-going-to-kill-internet-explorer-1288578

Wednesday, November 13, 2013

Sizeof Class / Data Members

Sizeof Class / Data Members

There are many factors that decide the size of an object of a class in C++. These factors are:
  1. Size of all non-static data members
  2. Order of data members
  3. Byte alignment or byte padding
  4. Size of its immediate base class
  5. The existence of virtual function(s) (Dynamic polymorphism using virtual functions).
  6. Compiler being used Mode of inheritance (virtual inheritance)
1. Sizeof Class with No data members:

Generally, for class without any data members, the size of the object of the class would be equals to 1.

i.e Have a look at the below example

Class Student
{
        //Function Definition
};

int main()
{
       Student S1;
       cout<<"The size of Empty class is "<<sizeof(S1);
       return 0;
}

The o/p would be 1. sizeof can never return 0. Logically, structure/class with 0 bytes does not exists. Hence minimum memory is allocated for a character data type which is one byte. That will be provided for an empty class.

2. Sizeof Class with data members:

Generally, for class with any data members, the size of the object of the class would be equals to amount of bytes the data members occupy.

i.e Have a look at the below example

Class Student
{
        private:
            int rollno;
        
        public:
            int getrollno()
            {
                 return rollno;
            }
            void setrollno(int rlno)
            {
                 rollno=rlno;
            }
};

int main()
{
       Student S1;
       cout<<"The size of this class is "<<sizeof(S1);
       return 0;
}

The output of the code would result to 4. i.e sizeof(int)= 4 bytes for the rollno.

3. Sizeof Class with data members without padding:

Generally, for class with any data members, the size of the object of the class would be equals to amount of bytes the data members occupy.

i.e Have a look at the below example

Class Student
{
        private:
            char section; 
            int rollno;
            char grade;
        
        public:
            int getrollno()
            {
                 return rollno;
            }
            void setrollno(int rlno)
            {
                 rollno=rlno;
            }
};

int main()
{
       Student S1;
       cout<<"The size of this class is "<<sizeof(S1);
       return 0;
}

If you compute the sizeof class as 6, (int-4, char-1) then you are absolutely wrong. Generally the order of data members defined place a vital role in allocating memory.

In our example, first character is declared. Although character takes only one byte, it allocates 4 bytes of block of memory in which only the first byte is used, the remaining three bytes are used with filler bits.

For integer, it will allocate 4 bytes. And again for the character 'grade', it allocates 4 bytes of memory.
The output of the above will result to 12.

Hence padding concept can be used to avoid this kind of high memory usage.

4. Sizeof Class with data members with padding:

Padding - Data members with higher memory usage are declared first followed by the lower order.

Generally, for class with any data members, the size of the object of the class would be equals to amount of bytes the data members occupy.

i.e Have a look at the below example

Class Student
{
        private:
            int rollno;
            char section;  
            char grade;
        
        public:
            int getrollno()
            {
                 return rollno;
            }
            void setrollno(int rlno)
            {
                 rollno=rlno;
            }
};

int main()
{
       Student S1;
       cout<<"The size of this class is "<<sizeof(S1);
       return 0;
}

Now integer will allocate 4 bytes, and the remaining two characters fills another two bytes.
The output would be 8.

Hence padding concept can be used to avoid this kind of high memory usage.


5. Sizeof Class with one virtual member function:

For the class with virtual functions, it allocates additional 4 bytes of memory for the pointer to virtual table.

Class Student
{
        private:
            int rollno;
        
        public:
            virtual void display()
            {
            }
};

int main()
{
       Student S1;
       cout<<"The size of this class is "<<sizeof(S1);
       return 0;
}

The output would be equals to 8.



6. Sizeof Class with two or more virtual member functions:

For the class with virtual functions, it allocates additional 4 bytes of memory for the pointer to virtual table.
Any number of virtual functions are available, the pointer remains only one.

Class Student
{
        private:
            int rollno;
        
        public:
            virtual void display()
            {
            } 

            virtual void treatsignal()
            {
            }
};

int main()
{
       Student S1;
       cout<<"The size of this class is "<<sizeof(S1);
       return 0;
}

The output would still be equals to 8.

7. Sizeof Derived Class:

The size of derived class will occupy space for data members of immediate base class + memory allocation for its own class.

Class Student
{
        public:
            int rollno;
        
        public:
            virtual void display()
            {
            }
};

Class Marks : public Student
{
        private:
            int mark1;
            int mark2;

        public:
            virtual void display()
            {
            }
};

int main()
{
       Marks m;
       cout<<"The size of this class is "<<sizeof(m);
       return 0;
}

The output would be Baseclass member (rollno)(4) + Virtualptr (4) in baseclass + Ownclass members (4 + 4) equals to 16.


8. Sizeof Derived Class inherited twice:

The size of derived class will occupy space for data members of immediate base class + memory allocation for its own class.

class Student
{
       int rollno;
};

class  marks : public Student
{
};

class performance: public marks
{
     char grade;
     char rank;
};

The size will be Baseclass member + own class will be equals to 8.

9. Size of all non-static data members:
Only non-static data members will be counted for calculating sizeof class/object.

class A 
{
private:
        float iMem1;
        const int iMem2;
        static int iMem3;
        char iMem4;
};


For an object of class A, the size will be the size of float iMem1 + size of int iMem2 + size of char iMem4. Static members are really not part of the class object. They won't be included in object's layout.

Mode of inheritance (virtual inheritance):

In C++, sometimes we have to use virtual inheritance for some reasons. (One classic example is the implementation of final class in C++.) When we use virtual inheritance, there will be the overhead of 4 bytes for a virtual base class pointer in that class.

class ABase{
        int iMem;
};

class BBase : public virtual ABase {
        int iMem;
};

class CBase : public virtual ABase {
        int iMem;
};

class ABCDerived : public BBase, public CBase {
        int iMem;
};


And if you check the size of these classes, it will be:

    Size of ABase : 4
    Size of BBase : 12
    Size of CBase : 12
    Size of ABCDerived : 24

Because BBase and CBase are derived from ABase virtually, they will also have an virtual base pointer. So, 4 bytes will be added to the size of the class (BBase and CBase). That is sizeof ABase + size of int + sizeof Virtual Base pointer.

Size of ABCDerived will be 24 (not 28 = sizeof (BBase + CBase + int member)) because it will maintain only one Virtual Base pointer (Same way of maintaining virtual table pointer).       

SS7 Layers / Architecture

SS7 Layers/Architecture :


Thursday, November 7, 2013

Script Command in UNIX for creating LOG files

 How to Use Script Command in UNIX:

:/root>script mylogfile.txt
Script started, file is mylogfile.txt
:/root>pwd
/root
:/root>cd SARAVANAN/
:/root/SARAVANAN>ls -lrt
total 20
drwxr-xr-x    5 root     root         4096 Mar 21  2013 SARAVANAN_RQ011305
drwxr-xr-x    4 root     root         4096 Apr 30  2013 65456A_T38
drwxr-xr-x    5 root     root         4096 Oct 15 06:13 SARAVANAN_RQ011308
drwxr-xr-x    3 root     root         4096 Nov  6 05:50 SARA_SIP_SIP_RQ011308
drwxr-xr-x    2 root     root         4096 Nov  8 04:24 3GPP_TEST
:/root/SARAVANAN>
:/root/SARAVANAN>
:/root/SARAVANAN>
:/root/SARAVANAN>exit
Script done, file is mylogfile.txt



mylogfile.txt in /root/ folder will contain the snapshot of all commands entered during the script is made ON/OFF

 :/root/vi mylogfile.txt
Script started on Fri Nov  8 04:56:04 2013
:/root>pwd^M
/root^M
:/root>cd A^H ^HSARAVANAN/^M
:/root/SARAVANAN>ls -lrt^M
total 20^M
drwxr-xr-x    5 root     root         4096 Mar 21  2013 SARAVANAN_RQ011305^M
drwxr-xr-x    4 root     root         4096 Apr 30  2013 65456A_T38^M
drwxr-xr-x    5 root     root         4096 Oct 15 06:13 SARAVANAN_RQ011308^M
drwxr-xr-x    3 root     root         4096 Nov  6 05:50 SARA_SIP_SIP_RQ011308^M
drwxr-xr-x    2 root     root         4096 Nov  8 04:24 3GPP_TEST^M
:/root/SARAVANAN>^M
:/root/SARAVANAN>^M
:/root/SARAVANAN>^M
:/root/SARAVANAN>exit^M

Script done on Fri Nov  8 04:56:21 2013




Note : Script captures every keystroke including Backspace, DELETE. (see cd SARAVANAN, ^H is for Backspace. The user had typed A instead of S. So he pressed backspace)

How to clear history in unix terminal

How to clear history in unix terminal

Run the command

history -c

This will clear the history of commands already entered in unix terminal.