Programming Paradigm

Paradigm means a school of thought or model that has distinct features, frameworks, patterns, and style which help you solve a particular problem. The languages may follow a particular paradigm or can be a combination of many paradigms. Programming paradigms are a way to classify the programming languages based on their features. Languages can be classified into multiple paradigms.

Declarative programming is to program on a higher level of abstraction than imperative programming. Neither is better or worse, but both have their places. An example of where declarative programming is necessary would be in web development when you are working with frameworks. An area of where Imperative programming is necessary would be in the engineering of algorithms and other low level necessities.

Declarative and Imperative programming paradigms are nothing but buzzwords for describing coding on different levels of abstraction. Declarative programming refers to code that is concerned with higher levels of abstraction. Imperative programming refers to code that is concerned with lower levels of abstraction.

Some argue that many programming languages cannot be strictly classified into one paradigm, but rather include features from several paradigms. For example c# & java are a multi-paradigm programming language which supports imperative as well as declarative, functional and many other programming paradigms.

Common programming paradigms are Imperative and Declarative.

Imperative:  Programming with an explicit sequence of commands, uses statements that change a program's state. Imperative programming implements algorithms in explicit steps. Computer get a list of commands and executes them in order. Imperative programming is generally described as being concerned with "How to do it, not what to do”.

 Procedural: procedural programming (which is also imperative) allows splitting those instructions into procedures (or functions). Procedural programming is a subset of imperative programming.

 Object-oriented:  which groups instructions with the part of the state they operate on.  It allows  grouping functions around a specific entities named “classes” and is also imperative.

Declarative:  Programming by specifying the result a user wants, instead of how to get it, expresses the logic of a computation without describing its control flow.  It describes what the program must accomplish in terms of the problem domain, rather than describe how to accomplish it as a sequence of the programming instructions (the how being left up to the language's implementation). Declarative programming is concerned with "what to do, not how to do it."

Common declarative languages include  a subset of SQL (SELECT queries, for example), regular expressions, logic programming, functional programming, CSS and configuration management language. Many markup languages such as HTML, XAML, XSLT or other user-interface markup languages are often declarative. HTML for example only describes what should appear on a webpage - it specifies neither the control flow for rendering a page nor the page's possible interactions with a user. 

Functional programming : functional programming is a subset of declarative programming. Haskell is an example of functional programming language.

Best practices while refactoring legacy code

Separate the new feature changes and code refactoring. Don't mix up both.

If you try to take on all this refactoring at the same time as the change you were originally planning, that’s a lot of stuff to fit in your head. Maybe you’re a refactoring wizard, in which case go for it, but I wouldn’t trust myself to handle that kind of cognitive load without making any mistakes. It’s much safer to split the work into stages: either make the change, then refactor, or vice versa. Don’t try to do both at the same time. Splitting refactoring work and other changes into separate commits in your version control system also makes it easier for you and other developers both to review the changes and to make sense of what you were doing when you revisit the code later.

The Mikado Method

Every software developer with a few years of experience has endured this situation: You want to make a small change that should take you a few minutes. However, when you start you see one problem after the other you need to fix first, then you need to refactor here a bit and something there, and before you know it, a day has gone by and you are no step closer to implement your change.

That extra work is not complicated, but you try to solve a problem on top of an endless list of other problems. Your tests started to fail right after the second refactoring and after hours of work you would be happy if your code just would compile. The longer this takes, the more frustrating it gets.

What I like so much on the Mikado Method is that you need only a slight little change in your routine to prevent those problems. It is so easy that you will not believe that this makes any difference. But trust me, it works. The high-level view on the Mikado Method looks like this:

Set a goal
Experiment
Visualize
Undo

More can be found here https://improveandrepeat.com/2020/12/the-mikado-method-a-great-help-to-work-with-legacy-code/ 

Best Practices In Handling Exceptions

 A well-designed app handles exceptions and errors to prevent app crashes. Below are some of the best practices:

1. Use try/catch/finally blocks to recover from errors or release resources

Use try/catch blocks around code that can potentially generate an exception and your code can recover from that exception.

2. Throw specific exceptions to make it easy for handling.

In catch blocks, always order exceptions from the most derived to the least derived.

3. Avoid return statement inside Finally block as it suppress the exception being thrown out from the method.

4. Avoid exceptions, Avoid returning Null, Handle common conditions

Handle common conditions without throwing exceptions. Design classes so that exceptions can be avoided. A class can provide methods or properties that enable you to avoid making a call that would trigger an exception. For example, a FileStream class provides methods that help determine whether the end of the file has been reached. These can be used to avoid the exception that is thrown if you read past the end of the file.

It may sound obvious to avoid exceptions. But many methods that throw an exception can be avoided by defensive programming.

One of the most common exceptions is NullReferenceException. When we return null, we are essentially creating work for ourselves and foisting problems upon our callers. All it takes is one missing null check to send an application spinning out of control. In some cases, you may want to allow null but forget to check for null. Here is an example that throws a NullReferenceException:

Address a = null;
var city = a.City;

Accessing a throws an exception but play along and imagine that a is provided as a parameter. In case you want to allow a city with a null value, you can avoid the exception by using the null-conditional operator:

Address a = null;
var city = a?.City;

By appending ? when accessing a, C# automatically handles the scenario where the address is null. In this case, the city variable will get the value null.

Do not use exceptions for the normal flow of control, if possible.  Except for system failures and operations with potential race conditions, framework designers should design APIs so users can write code that does not throw exceptions. For example, you can provide a way to check preconditions before calling a member so users can write code that does not throw exceptions.

5. Throw exceptions instead of returning an error code. Exceptions ensure that failures do not go unnoticed because calling code didn't check a return code.

6. Consider the performance implications of throwing exceptions. Throw rates above 100 per second are likely to noticeably impact the performance of most applications.

7. Do document all exceptions thrown by publicly callable members because of a violation of the member contract (rather than a system failure) and treat them as part of your contract.

  Exceptions that are a part of the contract should not change from one version to the next (i.e. exception type should not change, and new exceptions should not be added).

8. Place throw statements so that the stack trace will be helpful.

 The stack trace begins at the statement where the exception is thrown and ends at the catch statement that catches the exception.

Catch (SpecificException specificException)
{
    // .....
    throw specificException;
}

Catch (SpecificException specificException)
{
    // .....
    throw;
}

The main difference here is that the first example re-throw the SpecificException which causes the stack trace of original exception to reset while the second example simply retain all of the details of the original exception. You almost always want to use the 2nd example.

9. Consider using exception builder methods.

It is common to throw the same exception from different places. To avoid code bloat, use helper methods that create exceptions and initialize their properties.

Also, members that throw exceptions are not getting inlined. Moving the throw statement inside the builder might allow the member to be inlined.

class FileReader
{
    private string fileName;
	
    public FileReader(string path)
    {
        fileName = path;
    }
	
    public byte[] Read(int bytes)
    {
        byte[] results = FileUtils.ReadFromFile(fileName, bytes);
        if (results == null)
        {
            throw NewFileIOException();
        }
        return results;
    }

    FileReaderException NewFileIOException()
    {
        string description = "My NewFileIOException Description";

        return new FileReaderException(description);
    }
}

10. Restore state when methods don't complete due to exceptions

Callers should be able to assume that there are no side effects when an exception is thrown from a method. For example, if you have code that transfers money by withdrawing from one account and depositing in another account, and an exception is thrown while executing the deposit, you don't want the withdrawal to remain in effect.

public void TransferFunds(Account from, Account to, decimal amount)
{
    from.Withdrawal(amount);
    // If the deposit fails, the withdrawal shouldn't remain in effect.
    to.Deposit(amount);
}

The method above does not directly throw any exceptions, but must be written defensively so that if the deposit operation fails, the withdrawal is reversed.

One way to handle this situation is to catch any exceptions thrown by the deposit transaction and roll back the withdrawal.

private static void TransferFunds(Account from, Account to, decimal amount)
{
    string withdrawalTrxID = from.Withdrawal(amount);
    try
    {
        to.Deposit(amount);
    }
    catch
    {
        from.RollbackTransaction(withdrawalTrxID);
        throw;
    }
}

This example illustrates the use of throw to re-throw the original exception, which can make it easier for callers to see the real cause of the problem without having to examine the InnerException property. An alternative is to throw a new exception and include the original exception as the inner exception

11. Log exceptions

This seem so obvious. But we can see too much code failing in the subsequent lines when using this pattern:

try
{
    service.SomeCall();
}
catch
{
    // Ignored
}

Logging both uncaught and caught exceptions is the least you can do for your users. Nothing is worse than users contacting your support, and you had no idea that errors had been introduced and what happened. Logging will help you with that.

Ref: https://docs.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions  

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions  ‘

https://blog.elmah.io/csharp-exception-handling-best-practices/ 

Encoding and Charset

 Often we can see in files this encoding, for example one of the frequently used encoding value we often see in messaging systems using xml is encoding="utf-16" or encoding="utf-8"

When we transfer the messages over the wire, the receiving system(i.e. your application may be expecting xml message in a specific encoding) should have an understanding how to process the content, this is done based on the  encoding value found in the message.

  

  
    
      
    
  
  
    
      
        ....
      
    
  

          
  

To understand the "encoding" attribute, you have to understand the difference between bytes and characters.

Think of bytes as numbers between 0 and 255, whereas characters are things like "a", "1" and "Ä". The set of all characters that are available is called a character set.

Each character has a sequence of one or more bytes that are used to represent it; however, the exact number and value of the bytes depends on the encoding used and there are many different encodings.

Most encodings are based on an old character set and encoding called ASCII which is a single byte per character (actually, only 7 bits) and contains 128 characters including a lot of the common characters used in US English.

For example, here are 6 characters in the ASCII character set that are represented by the values 60 to 65.

In the full ASCII set, the lowest value used is zero and the highest is 127 (both of these are hidden control characters).

However, once you start needing more characters than the basic ASCII provides (for example, letters with accents, currency symbols, graphic symbols, etc.), ASCII is not suitable and you need something more extensive. You need more characters (a different character set) and you need a different encoding as 128 characters is not enough to fit all the characters in. Some encodings offer one byte (256 characters) or up to six bytes.

Over time a lot of encodings have been created. In the Windows world, there is CP1252, or ISO-8859-1, whereas Linux users tend to favour UTF-8. Java uses UTF-16 natively.

One sequence of byte values for a character in one encoding might stand for a completely different character in another encoding, or might even be invalid.

For example, in ISO 8859-1, â is represented by one byte of value 226, whereas in UTF-8 it is two bytes: 195, 162. However, in ISO 8859-1, 195, 162 would be two characters, Ã, ¢.

Think of XML as not a sequence of characters but a sequence of bytes.

Imagine the system receiving the XML sees the bytes 195, 162. How does it know what characters these are?

In order for the system to interpret those bytes as actual characters (and so display them or convert them to another encoding), it needs to know the encoding used in the XML.

Since most common encodings are compatible with ASCII, as far as basic alphabetic characters and symbols go, in these cases, the declaration itself can get away with using only the ASCII characters to say what the encoding is. In other cases, the parser must try and figure out the encoding of the declaration. Since it knows the declaration begins with <?xml it is a lot easier to do this.

Finally, the version attribute specifies the XML version, of which there are two at the moment (see Wikipedia XML versions. There are slight differences between the versions, so an XML parser needs to know what it is dealing with. In most cases (for English speakers anyway), version 1.0 is sufficient.

Ref: https://stackoverflow.com/questions/13743250/meaning-of-xml-version-1-0-encoding-utf-8

Use Of Stack & Postfix,Prefix Expressions In Computer Science

We studied theories back in school & college without knowing the practical applications of those theories. Stack in computer science was taught to us it follows a very simple logic called LIFO.

that is the last item in the collection can be removed first. The question is where is the application of this logic is used?. We use infix notation for representing mathematical operations or for manually performing calculations, since it is easier to read and comprehend. But for computers to perform quick calculations, they must work on prefix or postfix expressions.

So here going back to learn the fundamentals.


Calculators employing reverse Polish notation(Postfix notation) use a stack structure to hold values. Expressions can be represented in prefix,postfix or infix notations and conversion from one form to another may be accomplished using a stack.

Prefix notation is invented by a Polish logician & Philosopher hence it's also called Polish notation. In postfix notation Operators are written after their operands. it's called Reverse Polish Notation

Many compilers use a stack for parsing the syntax of expressions, program blocks etc. before translating into low level code.Most programming languages are context-free languages, allowing them to be parsed with stack based machines.

Use Of Postfix Notation In Computer Science>

Because of the existence of this unique interpretation, some compilers first convert arithmetic expressions from the standard infix notation to postfix to simplify code generation. To convert an infix expression to postfix, we must use a stack to hold operators that cannot be processed until their operands are available.

A useful feature of postfix is that the order in which operators are applied is always unambiguous. That is, there is only a single interpretation of any postfix expression. This is not true of infix. For example, the meaning of the infix expression a + b * c is unclear. Does it mean (a + b) * c or a + (b * c)?Without parentheses or additional rules, we cannot say. In Java, precedence rules dictate that multiplication is performed before addition; we say that multiplication “takes precedence” over addition. The corresponding postfix expression is a b c * +, and there is no ambiguity. It is explicit that the multiplication operator applies to the immediately two preceding operands b and c. The addition operator is then applied to operand a and the result (b * c). If we had meant the expression (a + b) * c, we would have written it in postfix notation as a b + c *. Now the + operation is applied to the two operands a and b, and * is performed on the two operands c and the result (a + b).


Rules for Infix to Postfix>
Infix to Postfix Conversion Rules:>
1. We use a stack
2. When an operand is read, output it
3. When an operator is read

Operators are pushed in the precedence order to stack. i.e if the scanned operator has higher precedence than the top element in the stack, push it to stack. Else if the scanned operator is of lower precedence/same precedence than in the stack then pop the elements in the stack until the top of the stack element has lower precedence when compared to scanned operator. Then push the scanned operator.

step 3 in other words:

• When an operator is read
– Pop until the top of the stack has an element of lower precedence
– Then push it

4. When ) is found, pop until we find the matching (
5. When we reach the end of input, pop until the stack is empty.



Infix notation is the common arithmetic and logical formula notation, in which operators are written infix-style between the operands they act on (e.g. 2 + 2). It is not as simple to parse by computers as prefix notation ( e.g. + 2 2 ) or postfix notation ( e.g. 2 2 + ), but many programming languages use it due to its familiarity.
Example: A * B + C / D
Postfix notation (also known as "Reverse Polish notation"): Operators are written after their operands.
Example:  A B C + * D / 
Prefix notation (also known as "Polish notation"): Operators are written before their operands. 
Example:  / * A + B C D 

Convert a prefix expression: A+(B*C)-D to postfix

     Input            Stack         Output
-----------------------------------------------

1.   A                 Empty         A
2.   +                 +                  A
3.   (                   (+                A
4.   B                 (+               AB
5.   *                 *(+              AB
6.   C                *(+               ABC
7.    )                   +                A BC*
8.   -                    -                  ABC*+
9.   D                  -                  ABC*+D
10.   Empty                              ABC*+D-  

In step 7 pop stack up to (
In step 8 pop items in stack up to when top stack element precedence is lower than -.
In step 10 when the input is empty pop all the remaining elements in the stack.





The advantage of converting prefix to postfix:>

1. The need for parantheses is eliminated.
2. The precedence rule is no longer relevant.
3. Evaluation can be achieved with great efficiency.


Priorities is BODMAS i.e

B - Brackets first.
O - Orders (ie Powers and Square Roots, etc.)
DM - Division and Multiplication (left-to-right)
AS - Addition and Subtraction (left-to-right)

i.e for example:
1. ^
2. * /
3. + –



Complex example for converting infix to postfix
Infix> (B^2 – 4 * A * C )^(1/2)
postfix> B2^4A*C*–12/^


Infix> 4 * (2 – (6 * 3 + 4) * 2) + 1
postfix> 4623*4+2*-*1+

1st rule in Converting infix to postfix using stack is:>
1. Begin to Read expression from Left-to-Right.


1st rule in Converting prefix to postfix using stack is:>
1. Begin to Read expression from Right-to-Left.

Rules For Converting Infix to prefix:>

1. Create 2 stacks: 1. OperatorStack & 2. Operand Stack
2. When an operand is read push it to OperandStack.
3. When an operator is read
     Operators are pushed in the precedence order to stack. i.e if the scanned operator has higher precedence than the top element in the stack, push it to stack. Else if the scanned operator is of lower precedence/same precedence than in the stack then pop the elements in the stack until the top of the stack element has lower precedence when compared to scanned operator. Then push the scanned operator.

step 3 in other words:

• When an operator is read
– Pop until the top of the stack has an element of lower precedence
– Then push it

Note>poped item should go to Operand Stack.
4. When ( is found, pop until we find the matching )
5. When we reach the end of the input, pop until the operator stack is empty.


Only difference b/w PreFix & PostFix conversion from Infix is that reading the expression starts from right in prefix where as it's from left in postfix.

Infix to prefix example>

Infix: 4*(2-(6*3+4)*2)+1

          Input          OperatorStack          OperandStack
--------------------------------------------------------------------

1.        1                     Empty                        1
2.        +                      +                               1
3.        )                       )+                             1
4.        2                      )+                           21
5.        *                      *)+                         21
6.        )                       )*)+                        21
7.        4                        )*)+                      421
8.        +                      +)*)+                     421  
9.        3                       +)*)+                  3421 
10.      *                       *+)*)+                3421
11.      6                        *+)*)+             63421
12.     (                          +)*)+             *63421
13.                                     *)+                +*63421
14.      -                        -)+                *+*63421
15.      2                        -)+                *+*63421
16.      (                        +                   -*+*63421
17.      *                        *+                -*+*63421
18.      4                       *+                4-*+*63421
19.    Empty                    +               *4-*+*63421
20.    Empty                Empty         +*4-*+*63421

Prefix:> +*4-*+*63421

Tips To Avoid Mistakes:>

1. Write down the previous operandStack first each time before scanning the symbol.

2. Then add the current input symbol if the scanned item is an operand.

2. Then add the current popped item one by one to the operand stack.

CPU & Hz

The speed of the CPU is measured in Hertz. One hertz means that one operation is performed per one second

About Roles In IT

Well we typically consider ourselves as programmers who develop the software. But we are hearing many other words commonly from the websites or in the recruitment portals words like these:

IT Professional, Developer,Designer, Software Tester, Architect etc. My clarity about these roles was always confusing I mean what is the real difference b/w an IT professional & a developer, to me it both appears same but when I took part in a survey done by asp.net website, I came to know there are differences. Although I know most of the guys in the IT world don't care about these differences.

Here is the explanation for each roles:

IT Professional: Plans, deploys, manages, or supports IT for a company or organization.

Developer: Designs or customizes software applications or Web sites; writes or tests computer code; or manages a software development process.

Business Decision Maker: Makes business decisions that direct a company or organization's strategies; or determines how resources are allocated, but does not work in the IT department. Develop software applications, rich internet applications and/or Web sites or Web applications: This could include creating applications for any computer platform, may also include using a database management software program, writing macros in any environment, creating software or applications for any platform using a programming language or tool, or writing production code (not prototyping). Additionally this could include creating interactive Web sites using Flash or other software development tools and technologies, using Web authoring tools or coding Web sites for server side, database, or client side functionality or creating Web pages or Web sites for the Internet or an Intranet using HTML or a Web authoring tool.

Architecting software applications: This could include architecting applications, creating the guiding design for your organization's technology usage, systems for speed, efficiency, scalability, load, network security, or the hardware and network infrastructure layer for your organization's applications or network. Additionally this may include architecting for individual projects or programs, ensuring integration between multiple applications, the systems that support them and providing strategic direction for enterprise-wide technology projects.

Designing: This could include designing the overall look and feel or user interface for software applications or Web sites. Additionally, this may include creating and/or designing graphics, visuals, layout and/or visual and creative, serving as the overall producer or creative manager of design efforts for applications and/or websites.

Testing software: This could include testing projects and software that you or others have written.

Other software or development activities: This may include activities related to managing software development projects, database design, assessing business needs.

Interesting Facts On C & C++

C has got a major role in the programming world especially in the operating systems where most of the today's OS are written in C. 

Some interesting facts about C & C++:
* The Linux kernel, is written in C as a matter of policy, and not in C++.
* Linux is in C because Linus hates C++. Other operating systems, such as Windows, are in C++.


Opinions>
* For OO abstraction you have Java or C# – and for memory management and low level performance you have C
* The Linux kernel is written in C because Linus says that C++ sucks. For some reason that makes good C++ programmers reluctant to work for him. It has nothing at all to do with performance or anything.
* One of the points Linus has made against C++ is that there are a lot more bad C++ developers out there than C developers, so using C doesn't present as many disadvantages as they gain from keeping bad C++ devs out of their project
* the legitimate arguments that Linus makes against C++ have more to do with the people using it than the language itself. That said, when Linux kernel development started, C++ debuggers and tooling were terrible. It’s still hard to find a good debugger than can handle macros and templates correctly in all cases. 
* C++ is faster than C. You can essentially compile any C as C++ (with changes irrelevant to runtime speed), so it is trivial to show that C++ is as fast as C. Then, C++ gives you extra expressive power with things like templates, enabling things like having the compiler compute things.
* Been thinking about this a bit more and I think I am changing my view even further. We rarely study assembly language in order to understand higher level languages, so I am wondering if tomorrows programmers will even ever need to be concerned with memory or other lower level details. Certainly today it is important, but I could see that basic knowledge becoming less and less valuable. 

* I believe all good programmers always feel the need to dig deeper and not understanding what goes under the hood is unsettling. Like in our days of C/C++, we wanted to learn assembly. In the modern day of C# we want to learn C/C++.

* once you learn C++ to an adequate level, you can pick up any other language really fast and you've developed a deeper understanding of how software works on a lower level – a knowledge that’s much harder to acquire when starting out at higher-level languages; I’ve always frowned upon the idea of starting programmers out on Java for that very reason.


Facts>
* games, which have been traditionally coded in C++.
* C++ has it’s uses for high performance apps that require detailed control over memory management
* C++ never left, but it definitely faded.
It is still in use for many systems as almost all applications need some access to lower level hardware and very perform-ant code in the OS and other subsystems. But, a majority of code we write today is written on top of the back of that C++ code. Just like someone needs to write assembly and actual logical gates that ends up on silicon in order for our CPU's to work. My points is that most developers today don’t need that kind of power, because the price that comes with that kind of power is high.

* A big difference between the two languages is that C++ was not strictly OOPS  it was a multiparadigm language. C# was originally just restricted to OOPS  slowly adding support over recent years for more powerful paradigms, but they still have a long way to go.
* This is indeed not a language for the faint of heart. You need patience, and you need determination. You won’t learn the language by copy/pasting examples for tutorials. You will need to read books and articles. Coding in C# or even Java is more productive than coding in C++. But when you try to make your code stronger (think, *industrial* strength), when “shit happens” is not a viable excuse, when you are trying to reach excellence or perfection, this is the moment the “easy languages” let you down (that is, when they are not actively fighting against you). And this is the moment when C++ really shines.Indeed, C++ is not “back”. C++ is “better”.

*Yes, C++ can still be useful in some problem domains. Yes, C++11 is better than C++98. But we stopped using C++ for a reason, and that reason wasn't “it doesn't have lambda expressions”. The so-called resurgence of C++ is a well-intention ed but horribly misguided attempt to get people to concentrate on exactly the wrong problem.

* Well, I guess it all depends on what kind of applications one aspires to write. If you’re writing a state-of-the-art game, a web browser, a word processor, a digital content creation tool, then C/C++ continues to be the best (if not the only) choice. Sure, not everybody has to write those types of applications but just because you don’t doesn't mean C++ is “not back”


* You cannot write nice GUI's with C++ in a week, do not try to learn it to write GUIs
* C does not solve all the problems, nor is template meta programming or overloading complex. It just takes a little bit time, patience and effort to learn it and appreciate it. It does not come over night. In C you can write fast code, but in C++ you can write fast code that can be maintained better, and extended easily. If you do not want to think in OO or Functional terms do not use C++, use C.
* If you learn C++ as a big brother of C, there is always chance you will suffer. Please learn C++ as C++, this will set the proper learning context in your mind.
* OK, I’m feeling like a dinosaur. When I started, there was a similar article, this time about assembly language. If you absolutely had to squeeze the last cycle out of your hardware, it was the way to go.

Internet's birth year and my birth year are same

1983 -This was the year that I was born and so as the Internet too :) I mean the year the Internet launched its operation. This is true when you consider about the internet which started working on TCP/IP in the year 1983. I always tried to find out whether anything important occurred in my birth year as well as on my birthday, just today I found out this one.

A little bit history about internet

The Internet and Transmission Control Protocols were initially developed in 1973 by American computer scientist Vinton Cerf as part of a project sponsored by the United States Department of Defense Advanced Research Projects Agency (ARPA) and directed by American engineer Robert Kahn.
The design of the Internet was done in 1973 and published in 1974. There ensued about 10 years of hard work, resulting in the roll out of Internet in 1983.  January 1, 1983 was the day computer systems on the ARPANET were required to switch over to the TCP/IP protocol.NCP (Network Control Protocol) was the protocol used on the early ARPANET.

However there is controversy about the birthday of Internet since internet is nothing but a  packet switching n/w based on TCP/IP protocol. And there were many packet switching n/ws before internet. For more details :A Closer Look At The Controversy Over The Internet's Birthday! You Decide

Gems from the Book "Hackers And Painters BIG IDEAS FROM THE COMPUTER AGE"

Today on Spet 11 2011, I just finished reading the book "Hackers and Painters: Big Ideas from the Computer Age" written by Paul Graham. It's an excellent book which as books title indicates is filled with full of ideas and great observations on its pages. I recommend this book if you are reading this post and I guess  you are probably working in software field, you should read it. It gives a new dimension to your thoughts.

I am just collecting some of the best gems found in the book here, so that I can reread and rethink and practice the things he has mentioned in the book.

Difference b/w Architectures & Engineers

Architects decide what to do and engineers figure out how to do it.

What and how should not be  kept too separate. You are asking for trouble if you try to decide what to do without understating how to do it

How to win over a big company with a start up?

If you want to make money at some point, remember this, because this is one of the reasons startups win. Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low. This is not a problem for big companies, because they don’t win by making great products.Big companies win by sucking less than other big companies.

So if you can figure out a way to get in a design war with a company big enough that its software is designed by product managers, they’ll never be able to keep up with you. These opportunities are not easy to find, though. It’s hard to engage a big company in a design war, just as it’s hard to engage an opponent inside a castle in hand-to-hand combat. It would be pretty easy to write a better word processor than Microsoft Word, for example, but Microsoft, within the castle of their operating system monopoly,
probably wouldn’t even notice if you did.
The place to fight design wars is in new markets, where no one has yet managed to establish any fortifications. That’s where you can win big by taking the bold approach to design, and having the same people both design and implement the product. Microsoft themselves did this at the start. So did Apple. And Hewlett Packard. I suspect almost every successful startup has.

If you want to make money, you tend to be forced to work on problems that are too nasty for anyone to solve for free.

How to identify a person is interested in programming?

It seems surprising to me that any employer would be reluctant to let hackers work on open source projects. At Viaweb, we would have been reluctant to hire anyone who didn’t.When we interviewed programmers, the main thing we cared about was what kind of software they wrote in their spare time. You can’t do anything really well unless you love it, and if you love to hack you’ll inevitably be working on projects of your own.

Right Mode For Collaboration In Software

As far as I know, when painters worked together on a painting, they never worked on the same parts. It was common for the master to paint the principal figures and for assistants to paint the others and the background. But you never had one guy painting over the work of another.

I think this is the right model for collaboration in software too. Don’t push it too far. When a piece of code is being hacked by three or four different people, no one ofwhomreally owns it, it will end up being like a common-room. It will tend to feel bleak and abandoned, and accumulate cruft. The right way to collaborate, I think, is to divide projects into sharply defined modules, each with a definite owner, and with interfaces between themthat are as carefully designed and, if possible, as articulated as programming languages.

How the people is buying things?

You might think that people decide to buy something, and then buy it, as two separate steps. That’s what I thought before Viaweb, to the extent I thought about the question at all. In fact the second step can propagate back into the first: if something is hard to buy, people will change their mind about whether they wanted it. And vice versa: you’ll sell more of something when it’s easy to buy. I buy more new books because Amazon exists. Web-based software is just about the easiest thing in the world to buy, especially if you have just done an online demo. Users should not have to do much more than enter a credit card number. (Make them do more at your peril.)

Marketing method to get rich customers

There is always a tendency for rich customers to buy expensive solutions, even when cheap solutions are better, because the people offering expensive solutions can spend more to sell them. At Viaweb we were always up against this. We lost several high-end merchants to web consulting firms who convinced them they’d be better off if they paid half a million dollars for a custom-made online store on their own server. They were, as a rule, not better off, as more than one discovered when Christmas shopping season came around and loads rose on their server. Viaweb was a lot more sophisticated than what most of these merchants got, but we couldn’t afford to tell them. At $300 a month, we couldn’t afford to send a team of well-dressed and authoritative-sounding people to make presentations to customers.

At times we toyed with the idea of a new service called Viaweb Gold. It would have exactly the same features as our regular service, but would cost ten times as much would be sold in person by a man in a suit. We never got around to offering this variant, but I’m sure we could have signed up a few merchants for it.

A large part of what big companies pay extra for is the cost of selling expensive things to them. (If the Defense Department pays a thousand dollars for toilet seats, it’s partly because it costs a lot to sell toilet seats for a thousand dollars.) And this is one reason intranet software will continue to thrive, even though it is
probably a bad idea. It’s simply more expensive. There is nothing you can do about this conundrum, so the best plan is to go for the smaller customers first. The rest will come in time.

Doubt to create and sell an innovative product/idea?

If you want to change the world, write a new Mosaic. Think it’s too late? In 1998 a lot of people thought it was too late to launch a new search engine, but Google proved them wrong. There is always room for something new if it is significantly better.

To Build A Start up Firm, you should have

If you’re a hacker who has thought of one day starting a startup,there are probably two things keeping you from doing it. One is that you don’t know anything about business. The other is that you’re afraid of competition. Neither of these fences have any current in them.

There are only two things you have to know about business: build something users love, and make more than you spend. If you get these two right, you’ll be ahead of most start ups. You can figure out the rest as you go.

Start by making something clean and simple that you would want to use yourself. Get a version 1.0 out fast, then continue to improve the software, listening closely to users as you do. The customer is always right, but different customers are right about different things; the least sophisticated users show you what you need to simplify and clarify, and the most sophisticated tell you what features you need to add. The best thing software can be is easy, but the way to do this is to get the defaults right, not to limit users’ choices. Don’t get complacent if your competitors’ software is lame; the standard to compare your software to is what it could be, not what your current competitors happen to have.
Use your software yourself, all the time. Viaweb was supposed to be an online store builder, but we used it to make our own site too. Don’t listen to marketing people or designers or product managers just because of their job titles. If they have good ideas, use them, but it’s up to you to decide; software has to be designed by hackers who understand design, not designers who know a little about software. If you can’t design software as well as implement it, don’t start a start up

From the Chapter:>How to Make Wealth

Startups are not magic. They don’t change the laws of wealth creation. They just represent a point at the far end of the curve. There is a conservation law at work here: if you want to make a million dollars, you have to endure a million dollars’ worth of pain. For example, one way to make a million dollars would be
to work for the Post Office your whole life,and save every penny of your salary. Imagine the stress of working for the Post Office  for fifty years. In a startup you compress all this stress into three or four years. You do tend to get a certain bulk discount if you buy the economy-size pain, but you can’t evade the fundamental conservation law. If starting a startup were easy, everyone would do it.

There are a lot of ways to get rich, and this essay is about only one of them. This essay is about how to make money by creating wealth and getting paid for it. There are plenty of other ways to get money, including chance, speculation, marriage, inheritance, theft, extortion, fraud, monopoly, graft, lobbying, counterfeiting, and prospecting. Most of the greatest fortunes have probably involved several of these.
The advantage of creating wealth, as a way to get rich, is not just that it’s more legitimate (many of the other methods are now illegal) but that it’s more straightforward. You just have to do something people want.

Until recently even governments sometimes didn’t grasp the distinction between money and wealth. Adam Smith (Wealth of Nations, v:i)mentions several that tried to preserve their “wealth” by forbidding the export of gold or silver. But having more of the mediumof exchange would not make a country richer; if you have more money chasing the same amount of material wealth, the only result is higher prices.

If you want to create wealth, it will help to understand what it is. Wealth is not the same thing as money.
Wealth is as old as human history. Far older, in fact; ants have wealth. Money is a comparatively recent invention. 

Wealth is the fundamental thing. Wealth is stuff we want: food, clothes, houses, cars, gadgets, travel to interesting places, and so on. You can have wealth without having money. If you had a magic machine that could on command make you a car or cook you dinner or do your laundry, or do anything else you wanted,
you wouldn’t need money. Whereas if you were in the middle of Antarctica, where there is nothing to buy, it wouldn’t matter how much money you had.

Wealth is what you want, not money. But if wealth is the important thing, why does everyone talk about making money? It is a kind of shorthand: money is a way of moving wealth, and in practice they are usually interchangeable. But they are not the same thing, and unless you plan to get rich by counterfeiting, talking about making money can make it harder to understand how to make money.

The advantage of a medium of exchange is that it makes trade work. The disadvantage is that it tends to obscure what trade really means. People think that what a business does is make money.
But money is just the intermediate stage just a shorthand for whatever people want. What most businesses really do is make wealth. They do something people want.

A surprising number of people retain from childhood the idea that there is a fixed amount of wealth in the world. There is, in any normal family, a fixed amount of money at any moment. But that’s not the same thing.

What leads people astray here is the abstraction of money. Money is not wealth. It’s just something we use to move wealth around. So although there may be, in certain specific moments (like your family, this month) a fixed amount of money available to trade with other people for things you want, there is not a fixed amount of wealth in the world. You can make more wealth. Wealth  has been getting created and destroyed (but on balance, created) for all of human history.

Suppose you own a beat-up old car. Instead of sitting on your butt next summer, you could spend the time restoring your car to pristine condition. In doing so you create wealth. The world is—and you specifically are—one pristine old car the richer. And not just in some metaphorical way. If you sell your car, you’ll get
more for it.

In restoring your old car you have made yourself richer. You haven’t made anyone else poorer. So there is obviously not a fixed pie. And in fact, when you look at it this way, you wonder why anyone would think there was.

What a Job Is?

Someone graduating from college thinks, and is told, that he needs to get a job, as if the important thing were becoming a member of an institution. A more direct way to put it would be: you need to start doing something people want. You don’t need to join a company to do that. All a company is is a group of
people working together to do something people want. It’s doing something people want that matters, not joining the group.

Measurement And Leverage

To get rich you need to get yourself in a situation with two things, measurement and leverage. You need to be in a position where your performance can be measured, or there is no way to get paid more by doing more. And you have to have leverage, in the sense that the decisions you make have a big effect.

Measurement alone is not enough. An example of a job with measurement but not leverage is doing piecework in a sweatshop. Your performance is measured and you get paid accordingly, but you have no scope for decisions. The only decision you get to make is how fast you work, and that can probably only increase your earnings by a factor of two or three.

An example of a job with both measurement and leverage would be lead actor in a movie. Your performance can be measured in the gross of themovie. And you have leverage in the sense that your performance can make or break it.

I think everyone who gets rich by their own efforts will be found to be in a situation with measurement and leverage. Everyone I can think of does: CEOs, movie stars, hedge fund managers, professional athletes. A good hint to the presence of leverage is the possibility of failure. Upside must be balanced by downside,
so if there is big potential for gain there must also be a terrifying possibility of loss. CEOs, stars, fund managers, and athletes all live with the sword hanging over their heads; the moment they start to suck, they’re out. If you’re in a job that feels safe, you are not going to get rich, because if there is no danger there is almost certainly no leverage.

But you don’t have to become a CEO or a movie star to be in a situation with measurement and leverage. All you need to do is be part of a small group working on a hard problem.

So all other things being equal, a very able person in a big company is probably getting a
bad deal, because his performance is dragged down by the overall lower performance of the others. Of course, all other things often are not equal: the able person may not care about money, or may prefer the stability of a large company. But a very able person who does care about money will ordinarily do better to go off and work with a small group of peers.

Technology = Leverage

What is technology? It’s technique. It’s the way we all do things. And when you discover a new way to do things, its value is multiplied by all the people who use it. 

If you look at history, it seems that most people who got rich by creating wealth did it by developing new technology. 

Big companies can develop technology. They just can’t do it quickly. Their size makes them slow and prevents them from rewarding employees for the extraordinary effort required. So in practice big companies only get to develop technology in fields where large capital requirements prevent startups from compet-
ing with them, like microprocessors, power plants, or passenger aircraft. And even in those fields they depend heavily on startups for components and ideas.

Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way. At Viaweb one of our rules of thumb was run upstairs. Suppose you are a little, nimble guy being chased by a big, fat, bully. You open a door and find yourself in a staircase. Do you go up or down? I
say up. The bully can probably run downstairs as fast as you can. Going upstairs his bulk will be more of a disadvantage. Running upstairs is hard for you but even harder for him.

What this meant in practice was that we deliberately sought hard problems. If there were two features we could add to our software, both equally valuable in proportion to their difficulty,  we’d always take the harder one. Not just because it was more valuable, but because it was harder. We delighted in forcing big-
ger, slower competitors to follow us over difficult ground. And I’d be delighted, because something that was hard for us would be impossible for our competitors.

This is not just a good way to run a startup. It’s what a startup is. Venture capitalists know about this and have a phrase for it: barriers to entry. If you go to a VC with a new idea and ask him to invest in it, one of the first things he’ll ask is, how hard would this be for someone else to develop? That is, how much difficult
ground have you put between yourself and potential pursuers?

And you had better have a convincing explanation of why your technology would be hard to duplicate. Otherwise as soon as some big company becomes aware of it, they’llmake their own, and with their brand name, capital, and distribution clout, they’ll take away your market overnight. You’d be like guerillas caught in the open field by regular army forces.

Here, as so often, the best defense is a good offense. If you can develop technology that’s simply too hard for competitors to duplicate, you don’t need to rely on other defenses. Start by picking a hard problem, and then at every decision point, take the harder choice.

When you’re running a startup, your competitors decide how hard you work. And they
pretty much all make the same decision: as hard as you possibly can.

Why Some People Are Good At Making Money?

Like chess or painting or writing novels, making money is a very specialized skill. But for some reason we treat this skill differently. No one complains when a few people surpass all the rest at playing chess or writing novels, but when a few people make more money than the rest, we get editorials saying this is wrong.

Why? The pattern of variation seems no different than for any other skill. What causes people to react so strongly when the skill is making money?

I think there are three reasons we treat making money as different: the misleading model of wealth we learn as children; the disreputable way in which, till recently, most fortunes were accumulated; and the worry that great variations in income are some how bad for society. As far as I can tell, the first is mistaken, the
second outdated, and the third empirically false. Could it be that, in a modern democracy, variation in income is actually a sign of health?

Ideas for Tracking the projects

I think it's helpful to implement Continous Integration CI

i.e

* Run test cases every day by using automation control

* And Build the source entirely every night

* Send automated mail to all team members if any test failed or the source checked in cause a build error

Major Tech Events/TakeOvers/Histoical Dates

Programming Joke

I got this from my friend really intersting & exact to the point about a funny logic followed by sometimes we programmers including me!

Joke

---------

There was an engineer, manager and programmer driving down a steep mountain road.

The brakes failed and the car careened down the road out of control.

Half way down the driver managed to stop the car by running it against the embankment narrowing avoiding going over a cliff.

They all got out, shaken by their narrow escape from death, but otherwise unharmed.

The manager said "To fix this problem we need to organize a committee, have meetings, and through a process of continuous improvement, develop a solution."

The engineer said "No that would take too long, and besides that method never worked before. I have my trusty pen knife here and will take apart the brake system, isolate the problem and correct it."

The programmer said "I think your both wrong! I think we should all push the car back up the hill and see if it happens again."

A Debugging Issue

Well I faced an issue which is that code is working locally fine but after hosting in the server it's not working. Me & my team lead sat together to findout what is the reason for this. We checked the code & did'nt found any bug. There was no log feature impleneted in the system then.

The application is a webservice consuming a service of provider which lists all the Hotels in a city. We were tired after spending some time to find out the issue & later called some one to check this issue. He said if it's working locally fine & after hosting it's not working, then check is there any FILE SYSTEM SPECIFIC path is mentioned any where.!!

Yes there was that hard coded!!!

LEARNT LESSON FROM THIS>> iF IN YOUR LOCAL CODE WORKING & HOSTED NOT WORKING CHECK FOR FILE SYSTEM SPECIFIC CODE IS ANY WHERE

Best practices for software development projects

Most software projects fail. In fact, the Standish group reports that over 80% of projects are unsuccessful either because they are over budget, late, missing function, or a combination. Moreover, 30% of software projects are so poorly executed that they are canceled before completion. In our experience, software projects using modern technologies such as Java, J2EE, XML, and Web Services are no exception to this rule.

This article contains a summary of best practices for software development projects. Industry luminaries such as Scott Ambler, Martin Fowler, Steve McConnell, and Karl Wiegers have documented many of these best practices on the Internet and they are referenced in this article. See also the Related information section at the end of this article. The companion article, Guide to Running Software Development Projects, describes the top ten factors that help improve the success of your project.

Best practices

1. Development process - It is important to choose the appropriate development lifecycle process to the project at hand because all other activities are derived from the process. For most modern software development projects, some kind of spiral-based methodology is used over a waterfall process. There are several choices, including the Rational Unified Process (RUP), IBM® Global Services Method, and eXtreme Programming (XP). Having a process is better than not having one at all, and in many cases it is less important on what process is used than how well it is executed. The commonly used methodologies listed above all contain guidance about how to execute the process and templates for artifacts. In addition, the RUP has a series of books that describe the best practices for using RUP [1][2][3][4] although if you do not choose to use RUP, these books still provide an excellent source of best practices. It is also possible to add plugins to the RUP. For a list of available plug-ins, see Plug-in Central.

2. Requirements - Gathering and agreeing on requirements is fundamental to a successful project. This does not necessarily imply that all requirements need to be fixed before any architecture, design, and coding are done, but it is important for the development team to understand what needs to be built. Quality requirements are broken up into two kinds: functional and non-functional. A good way to document functional requirements is using Use Cases. Note that Use Cases are used for non-OO projects. A definitive book on the subject of use cases is by Armour and Miller [5]. Non-functional requirements describe the performance and system characteristics of the application. It is important to gather them because they have a major impact on the application architecture, design, and performance. See the non-functional requirements checklist on the Construx Web site.

3. Architecture - Choosing the appropriate architecture for your application is key. Many times IBM is asked to review a project in trouble and we have found that the development team did not apply well-known industry architecture best practices. A good way to avoid this type of problem is to contact IBM. Our consultants can work side by side with your team and ensure that the projects get started on the right track. Tried and true practices are called patterns and they range from the classic Gang of Four [6] patterns, Java patterns [7], to EJB design patterns [8]. Sun's equivalent is the Core J2EE Patterns catalog [9]. Many projects fail as discussed in the introduction. The study of these failures has given rise to the concept of antipatterns. They are valuable because they provide useful knowledge of what does not work, and why.

4. Design - Even with a good architecture it is still possible to have a bad design. Many applications are either over-designed or under-designed. The two basic principles here are "Keep it Simple" and information hiding. For many projects, it is important to perform Object-Oriented Analysis and Design using UML. There are many books on UML, but we recommend UML User Guide [11] and Applying UML and Patterns [12]. Reuse is one of the great promises of OO, but it is often unrealized because of the additional effort required to create reusable assets. Code reuse is but one form of reuse and there are other kinds of reuse that can provide better productivity gains.

5. WebSphere application design - IBM has extensive knowledge of the best practices and design patterns for the WebSphere product family. Each project is different and our consultants have the experience to help you. There is still a tremendous return on investment (ROI) even if you only use the consultants for a short time because you save the costs later in the project. Our experts have also published a great deal of this wisdom, including considerations for high-performance Web sites and guidelines for autonomic computing.

6. Construction of the code - Construction of the code is a fraction of the total project effort, but it is often the most visible. Other work equally important includes requirements, architecture, analysis, design, and test. In projects with no development process (so-called "code and fix"), these tasks are also happening, but under the guise of programming. A best practice for constructing code includes the daily build and smoke test. Martin Fowler goes one step further and suggests continuous integration that also integrates the concept of unit tests and self-testing code. Note that even though continuous integration and unit tests have gained popularity through XP, you can use these best practices on all types of projects. I recommend using standard frameworks to automate builds and testing, such as Ant and JUnit.

7. Peer reviews - It is important to review other people's work. Experience has shown that problems are eliminated earlier this way and reviews are as effective or even more effective than testing. Any artifact from the development process is reviewed, including plans, requirements, architecture, design, code, and test cases. Karl Wiegers paper on the Seven Deadly Sins of Software Reviews explains the correct ways to perform peer reviews. Peer reviews are helpful in trying to produce software quality at top speed.

8. Testing - Testing is not an afterthought or cutback when the schedule gets tight. It is an integral part of software development that needs to be planned. It is also important that testing is done proactively; meaning that test cases are planned before coding starts, and test cases are developed while the application is being designed and coded. There are also a number of testing patterns that have been developed.

9. Performance testing - Testing is usually the last resort to catch application defects. It is labor intensive and usually only catches coding defects. Architecture and design defects may be missed. One method to catch some architectural defects is to simulate load testing on the application before it is deployed and to deal with performance issues before they become problems.

10. Configuration management - Configuration management involves knowing the state of all artifacts that make up your system or project, managing the state of those artifacts, and releasing distinct versions of a system. There is more to configuration management than just source control systems, such as Rational Clearcase. There are also best practices and patterns [13] for configuration management.

11. Quality and defects management - It is important to establish quality priorities and release criteria for the project so that a plan is constructed to help the team achieve quality software. As the project is coded and tested, the defect arrival and fix rate can help measure the maturity of the code. It is important that a defect tracking system is used that is linked to the source control management system. For example, projects using Rational ClearCase may also use Rational ClearQuest. By using defect tracking, it is possible to gauge when a project is ready to release.

12. Deployment - Deployment is the final stage of releasing an application for users. If you get this far in your project - congratulations! However, there are still things that can go wrong. You need to plan for deployment and you can use a deployment checklist on the Construx Web site.

13. System operations and support - Without the operations department, you cannot deploy and support a new application. The support area is a vital factor to respond and resolve user problems. To ease the flow of problems, the support problem database is hooked into the application defect tracking system.

14. Data migration - Most applications are not brand new, but are enhancements or rewrites of existing applications. Data migration from the existing data sources is usually a major project by itself. This is not a project for your junior programmers. It is as important as the new application. Usually the new application has better business rules and expects higher quality data. Improving the quality of data is a complex subject outside the scope of this article.

15. Project management - Project management is key to a successful project. Many of the other best practice areas described in this article are related to project management and a good project manager is already aware of the existence of these best practices. Our recommended bible for project management is Rapid Development by Steve McConnell [14]. Given the number of other checklists and tip sheets for project management, it is surprising how many project managers are not aware of them and do not apply lessons learned from previous projects, such as: "if you fail to plan, you plan to fail." One way to manage a difficult project is through timeboxing.

16. Measuring success - You can measure your development process against an industry standard known as the Capability Maturity Model (CMM) from the Software Engineering Institute at Carnegie Mellon University. Most projects are at level 1 (initial). If you implement the best practices described above and the guidelines in the companion article, Guide to Running Software Development Projects, then you could be well on the way to achieving a higher maturity level and a successful project.