Extreme Programming

Extreme Programming (XP) is the most widely used agile methodology. XP is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

In Extreme Programming, every contributor to the project is a member of the “Whole Team”, a single business/development/testing team that handles all aspects of the development. Central to the team is the “Customer”, one or more business representatives who sit with the team and work with them daily.

Extreme Programming teams use a simple form of planning and tracking to decide what to do next and to predict when any desired feature set will be delivered. Focused on business value, the team produces the software in a series of small fully integrated releases that pass all the
tests that the Customer has defined. The core XP practices for the above are called Whole Team, Planning Game, Small Releases, and Acceptance Tests.

Extreme Programmers work together in pairs and as a group, with simple design and obsessively tested code, improving the design continually to keep it always just right for the current needs. The core XP practices here are Pair Programming, Simple Design, Test-Driven
Development, and Design Improvement.

The Extreme Programming team keeps the system integrated and running all the time. The programmers write all production code in pairs, and all work together all the time. They code in a consistent style so that everyone can understand and improve all the code as needed. The additional practices here are called Continuous Integration, Team Code Ownership, and Coding Standard.

The Extreme Programming team shares a common and simple picture of what the system looks like. Everyone works at a pace that can be sustained indefinitely. These practices are called Metaphor, and Sustainable Pace. 

 

Fig : XP Practices and the Circle of Life

SQL Server 2008 : Policy-Based Management

Policy-Based Management is a new feature in SQL Server 2008 that allows users to define and implement policies across SQL Server infrastructure. Group Policy offers centralized management and configuration of systems, applications, and users via administrator or system-controlled policies, which can then be applied at various levels of managed directory structure. Policy-Based Management adheres to those same principles as Group Policy, in that you can apply a policy against a target (such as a database, table, or stored procedure) and evaluate whether the target complies with your policy. If your target does not adhere to your policy, you can either enforce compliance with that policy or trigger an alert to let an administrator know about the policy violation. You can set up your policy to actively deny any nonconforming actions, or choose to simply log such actions.

Policy-Based Management Components

    There are mainly three components : Policies, Conditions, and Facets. Facets are required in order to create conditions, and conditions are required in order to create policies. Additionally, policies are applied to the targets you specify.

Facets

A facet is a group of logical properties that are related to each other within the context of the specified target. SQL Server 2008 exposes 74 facets, each with one or more properties. This allows you to leverage hundreds of properties in order to create policies.

Conditions

A condition is a specified required state for the policy or facet being evaluated. Basically, a policy checks the condition of a target. If the target does not comply with the specified condition, the policy fails. A policy can evaluate only one condition, but user can evaluate one or more properties within a single condition.

Policies

A policy is a complete package that includes conditions, facets, targets, evaluation modes, and server restrictions. Policies are stored within the msdb system database. Policies can be exported from database and stored in XML format. This portability allows administrators to easily share and compare custom policies.

Targets

Targets are the objects that are managed by a policy. Targets can refer to many objects: servers, databases, instances, stored procedures, and so on. Policies can contain multiple targets. The available targets change depending on the context of the policy.

C# Essentials

Some self explanatory C# fundamentals diagrams:

Introducing C#:

Data Types:

Operators and Control Flow:

Method and Parameters:

Classes:

Inheritance:

Interfaces:

Value Types:

Well-Formed Types:

Exception Handling:

Generics:

Delegates and Lambda Expressions:

Events:

Collection Interfaces with Standard Query Operators:

LINQ with Query Expressions:

Custom Collections:

Reflection, Attributes, and Dynamic Programming:

Multithreading:

Synchronization and More Multithreading Patterns:

Platform Interoperability and Unsafe Code:

The Common Language Infrastructure:

 

High Level Component of SQL Server Architecture

SQL Server is split into two main engines: the Relational Engine and the Storage engine.

The Relational Engine:

    The relational Engine is also sometimes call the query processor because its primary function is query optimization and execution. It contains a Command Parser to check query syntax and prepare query trees, a Query Optimizer that is arguably the crown jewel of any database system, and a Query Executor responsible for execution.

1. Command Parser:

The Command Parser’s role is to handle T-SQL language events. It first checks the syntax and returns any errors back to the protocol layer to send to the client. If the syntax is valid, then the next step is to generate a query plan or find an existing plan. A Query plan contains the details about how SQL Server is going to execute a piece of code. It is commonly referred to as an execution plan.

Plan Cache: Creating execution plans can be time consuming and resource intensive, so The Plan Cache, part of SQL Server’s buffer pool, is used to store execution plans in case they are needed later.

2. Query Optimizer:

    The Query Optimizer is one of the most complex and secretive parts of the product. It is what’s known as a “cost-based” optimizer, which means that it evaluates multiple ways to execute a query and then picks the method that it deems will have the lowest cost to execute. This “method” of executing is implemented as a query plan and is the output from the optimizer.

3. Query Executor:

    The Query Executor’s job is self-explanatory; it executes the query. To be more specific, it executes the query plan by working through each step it contains and interacting with the Storage Engine to retrieve or modify data.

The Storage Engine:

    The Storage engine is responsible for managing all I/O to the data, and contains the Access Methods code, which handles I/O requests for rows, indexes, pages, allocations and row versions, and a Buffer Manager, which deals with SQL Server’s main memory consumer, the buffer pool. It also contains a Transaction Manager, which handles the locking of data to maintain Isolation (ACID properties) and manages the transaction log.

1. Access Methods:

    Access Methods is a collection of code that provides the storage structures for data and indexes as well as the interface through which data is retrieved and modified. It contains all the code to retrieve data but it doesn’t actually perform the operation itself; it passes the request to the Buffer Manager.

2. Buffer Manager:

    The Buffer Manager manages the buffer pool, which represents the majority of SQL Server’s memory usage. If you need to read some rows from a page the

Buffer Manager will check the data cache in the buffer pool to see if it already has the page cached in memory. If the page is already cached, then the results are passed back to the Access Methods. If the page isn’t already in cache, then the Buffer Manager will get the page from the database on disk, put it in the data cache, and pass the results to the Access Methods.

Data Cache: The data cache is usually the largest part of the buffer pool; therefore, it’s the largest memory consumer within SQL Server. It is here that every data page that is read from disk is written to before being used.

3. Transaction Manager:

    The Transaction Manager has two components that are of interest here: a Lock Manager and a Log Manager.

The Lock Manager is responsible for providing concurrency to the data, and it delivers the configured level of isolation by using locks. The Access Methods code requests that the changes it wants to make are logged, and the Log Manager writes the changes to the transaction log. This is called Write-Ahead Logging.

The Protocol Layer:

When the protocol layer in SQL Server receives your TDS (Tabular Data Stream) packet, it has to reverse the work of the SNI at the client and unwrap the packet to find out what request it contains. The protocol layer is also responsible for packaging up results and status messages to send back to the client as TDS messages.

TDS (Tabular Data Stream) Endpoints: TDS is a Microsoft-proprietary protocol originally designed by Sybase that is used to interact with a database server.

Dynamic Programming

Dynamic Programming is method of solving complex problems by breaking them down into a series of overlapping sub-problems, and build up solutions to larger and larger sub-problems.
    It is a powerful design technique that can be used to solve problems of computational nature. And it is typically applied to optimization problems.

Keys of Dynamic Programming:
1. Optimal substructure
    An optimal solution to a problem (instance) contains optimal solutions to subproblems.
2. Overlapping subproblems
    A recursive solution contains a “small” number of distinct subproblems repeated many times.
3. Bottom Up Fashion
    Computing the solution in a bottom-up fashion to solve the problem.

Areas:

• Bio-informatics
• Control theory
• Information theory
• Operations research
• Computer science: theory, graphics, AI, systems

Some famous dynamic programming algorithms:

• Unix diff for comparing two files
• Viterbi for hidden Markov models
• Smith-Waterman for sequence alignment
• Bellman-Ford for shortest path routing in networks
• Cocke-Kasami-Younger for parsing context free grammars

HTML/XHTML Declaration

According to HTML standards, each HTML document requires a document type declaration. The "DOCTYPE" begins the HTML document and tells a validator which version of HTML to use in checking the document's syntax.

• The doctype declaration should be the very first thing in an HTML document, before the <html> tag.
• The doctype declaration is not an HTML tag; it is an instruction to the web browser about what version of the markup language the page is written in.
• The doctype declaration refers to a Document Type Definition (DTD). The DTD specifies the rules for the markup language, so that the browsers can render the content correctly.

Document Type Definitions (DTD)

• A DTD specifies the syntax of a web page in SGML(Standard Generalized Markup Language)
• DTDs are used by SGML applications, such as HTML, to specify rules for documents of a particular type, including a set of elements and entity declarations
• An XHTML DTD describes in precise, computer-readable language, the allowed syntax of XHTML markup

There are three DTDs:

• STRICT : Use the strict DOCTYPE when you want really clean markup, free of presentational clutter. Use it together with CSS.
• TRANSITIONAL : Use the transitional DOCTYPE when you want to still use HTML's presentational features.
• FRAMESET : Use the frameset DOCTYPE when you want to use HTML frames.

Doctypes Available in the W3C Recommendations:

HTML 4.01 Strict

This DTD contains all HTML elements and attributes, but does NOT INCLUDE presentational or deprecated elements (like font). Framesets are not allowed.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 

"http://www.w3.org/TR/html4/strict.dtd">

HTML 4.01 Transitional

This DTD contains all HTML elements and attributes, INCLUDING presentational and deprecated elements (like font). Framesets are not allowed.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 

"http://www.w3.org/TR/html4/loose.dtd">

HTML 4.01 Frameset 

This DTD is equal to HTML 4.01 Transitional, but allows the use of frameset content.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" 

"http://www.w3.org/TR/html4/frameset.dtd">

XHTML 1.0 Strict

This DTD contains all HTML elements and attributes, but does NOT INCLUDE presentational or deprecated elements (like font). Framesets are not allowed. The markup must also be written as well-formed XML.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

XHTML 1.0 Transitional

This DTD contains all HTML elements and attributes, INCLUDING presentational and deprecated elements (like font). Framesets are not allowed. The markup must also be written as well-formed XML.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

XHTML 1.0 Frameset

This DTD is equal to XHTML 1.0 Transitional, but allows the use of frameset content.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" 

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

XHTML 1.1

This DTD is equal to XHTML 1.0 Strict, but allows you to add modules (for example to provide ruby support for East-Asian languages).

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 

"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

SQL Server : Transform Columns into Rows

Suppose, we have the table “tblSample” with the following data.

Seq	Month	New Policy Count	New Premium	Claims Recorded	Claims Cost	Loss Ratio
1	2010/06/01	1000	100000.9	5	66666.98	66.66
2	2010/05/01	1100	200000.9	10	55555.98	27.77
3	2010/04/01	1200	300000.9	15	44444.98	14.81
4	2010/03/01	1300	400000.9	20	33333.98	8.33
5	2010/02/01	1400	500000.9	25	22222.98	4.44
6	2010/01/01	1500	600000.9	30	11111.98	1.85

The query to transform the Columns of this table to Rows:

SELECT   Seq

        ,ROW_NUMBER() OVER(PARTITION BY [Month] ORDER BY Seq) AS 'RowNumber'
        ,CONVERT(VARCHAR, [Month], 111) AS [Month], Title, aValue

INTO #temp

FROM

     (SELECT  Seq 
             ,[Month]
             ,[New Policy Count]

             ,[New Premium]          
             ,[Claims Recorded]    
             ,[Claims Cost] 
             ,[Loss Ratio]

      FROM tblSample) p

      UNPIVOT      
     (aValue FOR  Title IN ([New Policy Count],[New Premium],[Claims Recorded],[Claims Cost],[Loss Ratio]))

AS unpvt

DECLARE @SQLQuery     VARCHAR(MAX)

       ,@PivotColumns VARCHAR(MAX)

SET    @PivotColumns = ''

SELECT @PivotColumns = @PivotColumns+ '['+ [Month] +'],' FROM (SELECT
DISTINCT [Month] FROM #TEMP) a

SET    @PivotColumns = SUBSTRING(@PivotColumns, 1,LEN(@PivotColumns) - 1)

SET @SQLQuery = 'SELECT Title,' + @PivotColumns +

             'FROM (SELECT [Month], RowNumber, Title, aValue FROM #temp) s
              PIVOT (SUM(aValue) FOR [Month] IN (' + @PivotColumns + ')) p
              ORDER BY RowNumber'

EXEC (@SQLQuery)

DROP TABLE #temp

The final output looks like:

Title	2010/01/01	2010/02/01	2010/03/01	2010/04/01	2010/05/01	2010/06/01
New Policy Count	1500	1400	1300	1200	1100	1000
New Premium	600000.9	500000.9	400000.9	300000.9	200000.9	100000.9
Claims Recorded	30	25	20	15	10	5
Claims Cost	11111.98	22222.98	33333.98	44444.98	55555.98	66666.98
Loss Ratio	1.85	4.44	8.33	14.81	27.77	66.66