YAGNI Principle - An Xtreme Programming approach

"You ain't gonna need it" or “You aren't gonna need it”(acronym: YAGNI) is a principle of extreme programming (XP) that states that a programmer should not add functionality until it is deemed necessary.

"Always implement things when you actually need them, never when you just foresee that you need them."

YAGNI is a principle behind the XP practice of "doing the simplest thing that could possibly work". It is meant to be used in combination with several other practices, such as continuous refactoring, continuous automated unit testing and continuous integration.

Used without continuous refactoring it would lead to messy code and massive rework. Continuous refactoring in turn relies on automated unit tests as a safety net and continuous integration to prevent integration problems.

YAGNI is not universally accepted as a valid principle, even in combination with the supporting practices. The need for combining it with the supporting practices, rather than using it standalone, is part of the original definition of XP.

It was never claimed that standalone YAGNI was a good idea.

According to those who advocate the YAGNI approach, not following YAGNI may lead to following disadvantages:

 The time spent is taken from adding, testing or improving necessary functionality.

The new features must be debugged, documented, and supported.
 Any new feature imposes constraints on what can be done in the future, so an unnecessary feature may preclude needed features from being added in the future.
 Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work correctly, even if it eventually is needed.
 It leads to code bloat; the software becomes larger and more complicated.
 Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
 Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards feature creep.

Difference between Passimistic and Optimistic locking

Optimistic Locking is a strategy where you read a record, take note of a version number and check that the version hasn't changed before you write the record back.

When you write the record back you filter the update on the version to make sure it's atomic. (i.e. hasn't been updated between when you check the version and write the record to the disk) and update the version in one hit.
If the record is dirty (i.e. different version to yours) you abort the transaction and the user can re-start it.

This strategy is most applicable to high-volume systems and three-tier architectures where you do not necessarily maintain a connection to the database for your session. In this situation the client cannot actually maintain database locks as the connections are taken from a pool and you may not be using the same connection from one access to the next.


Pessimistic Locking is when you lock the record for your exclusive use until you have finished with it. It has much better integrity than optimistic locking but requires you to be careful with your application design to avoid Deadlocks.

To use pessimistic locking you need either a direct connection to the database (as would typically be the case in a two tier client server application) or an externally available transaction ID that can be used independently of the connection.

In the latter case you open the transaction with the TxID and then reconnect using that ID. The DBMS maintains the locks and allows you to pick the session back up through the TxID.

WCF Interview Question

What are the various ways of hosting a WCF service?

How do we host a WCF service in IIS?

What are the advantages of hosting WCF Services in IIS as compared to self-hosting?

What are the major differences between services and Web services?

What is the difference WCF and Web services?

What is one-way operation?

Can you explain duplex contracts in WCF?

How can we host a service on two different protocols on a single server?

Can you explain transactions in WCF?

What different transaction isolation levels provided in WCF?

What is a poison message?

What is service and client in perspective of data communication?

What is address in WCF and how many types of transport schemas are there in WCF?

What are the important principles of SOA (Service oriented Architecture)?

What are ends, contract, address, and bindings?

Which specifications does WCF follow?

What are the main components of WCF?

Explain how Ends, Contract, Address, and Bindings are done in WCF?

What is a service class?

What is a service contract, operation contract and Data Contract?

How to define a service as REST based service in WCF?

What is the address formats of the WCF transport schemas?

What is Proxy and how to generate proxy for WCF Services?

What are different elements of WCF services Client configuration file?

What is Transport and Message Reliability?

How to configure Reliability while communicating with WCF Services?

 

What are meta MAX attributes in WCF?

 

How to return an exception from WCF to the client?

 

What is the use of Message Inspector in WCF?

Send Email From SQL Server Database(Configuration and sending)

In this article I would show how to setup the Database Mail which is used to send the Email using SQL Server. Database mail is the replacement of the SQLMail with many improvements. So we should upgrade to the Database Mail.

In order to configure mail using Database Mail in SQL Server, there are three main steps that need to be carried out.

1) Create Profile and Account

2) Configure Email

3) Send Email.

1) Create Profile and Account:

First we need to create a profile and account using the Configure Database Mail Wizard which can be accessed from the Configure Database Mail context menu of the Database Mail option in Management option. This wizard is used to manage accounts, profiles, and Database Mail global settings as shown below:

Open the Database mail configuration wizard -

Enter profile details to be created


Add/Manage mail account



Manage Profile Security settings

Verify/Specify Parameters


Wizard Completion
Wizard Finish/Success

2) Configure Email:

After the Account and the Profile have been created successfully, we need to configure the Database Mail. For this, we need to enable the Database Mail XPs parameter through the sp_configure stored procedure, as shown here:

sp_CONFIGURE 'show advanced', 1
GO
RECONFIGURE
GO
sp_CONFIGURE 'Database Mail XPs', 1
GO
RECONFIGURE
GO

After all configurations are done, we are ready to send an email. To send mail, we need to execute a stored procedure sp_send_dbmail and provide the required parameters as shown below:

USE msdb
GO
EXEC sp_send_dbmail @profile_name='test',
@recipients='test@gmail.com',
@subject='Test message',
@body='This is the body of the test message.'

After all validations of the parameters entered are done, certain stored procedures are executed and the mail is queued by Service Broker.

Database Mail keeps track of outgoing e-mail messages in the sysmail_allitems, sysmail_sentitems, sysmail_unsentitems, sysmail_faileditems .

The status of the sent mail can be seen in sysmail_mailitems table, when the mail is sent successfully the sent_status field of the sysmail_mailitems table is set to 1 which can again be seen in sysmail_sentitems table. The mails that are failed will have the sent_status field value to 2 and those are unsent will have value 3.
The log can be checked in sysmail_log table as shown below:

SELECT *
FROM sysmail_mailitems
GO
SELECT *
FROM sysmail_log
GO

Status can be verified using sysmail_sentitems table