Delhi Chapter Meeting on Replication and Client Interaction

Followed by the overwhelming response from our meetings in Mumbai and Trivandrum, we are held our first Delhi chapter meeting on 7th January. The presentations are interspersed with relaxed discussion over snacks and soft drinks. What makes each of these meetings worthwhile is the high quality of the work that is performed by users for users.

The chapter meeting provides an opportunity to mingle with fellow members, get your technical questions answered, learn new skills, and discuss & share your opinions. Every website has their online presence but what is more important is to connect and interact with the users directly.

To start the session, we had a short introductory speech by Kamal Rawat who is associated with site from last one year or so. 

 

Please don't complain about the above picture because that is the only one of the introductory speech. J

The first technical session was on "Replication in SQL Server" and was presided over by Shivom Agarwal. 

 

Shivom talked about:

1. Replication scenarios.
2. Types of replication.
3. Updating data at Subscribers.

Replication Scenarios

It is divided into two categories:

1. Server to server Scenarios
   
   • Improving scalability and availability
   • Data warehousing and reporting
   • Integrating data from multiple sites
   • Offloading batch processing
2. Server and Client Scenarios
   
   • Exchanging data with mobile users
   • Consumer point of sale (POS) applications
   • Integrating data from multiple sites

Types of Replication

In SQL Server three types of replication

    

1. Snapshot Replication

This process is commonly used to provide the initial set of data and database objects for transactional and merge publications, but it can also be used by itself. It supports the following points.

• Data changes infrequently.
• It is acceptable to have copies of data that are out of date with respect to the Publisher for a period of time.

2. Transactional Replication

This Process is typically used in server-to-server environments and is appropriate in each of the following cases:

• The application requires low latency between the time changes are made at the Publisher and the changes arrive at the Subscriber.
• The application requires access to intermediate data states. For example - firing a trigger
• The Publisher has a very high volume of insert, update, and delete activity.
• Subscribers to transactional publication should be treated as read-only

Merge Replication

This Process is typically used in server-to-client environments. Merge replication is appropriate in any of the following situations:

• Multiple Subscribers might update the same data at various times and propagate those changes to the Publisher and to other Subscribers.
• Subscribers need to receive data, make changes offline, and later synchronize changes with the Publisher and other Subscribers.
• Each Subscriber requires a different partition of data.

Updating Data at Subscribers

 

This Process is typically used in Transactional replication with updating subscriptions

• There are a small number of Subscribers.
• Replicated data is mostly read-only at the Subscriber.
• Subscriber, Distributor, and Publisher are connected most of the time (for immediate updating subscriptions).

-----------------------------------------------------------------------------------------------------------------------------------------------------

Ankur Malik, Tech Lead at MCN Solutions talked about "How to work with clients" from his experience of client interactions from last five years.

Ankur mentioned about four basic pillars that define success of a project: Time, Cost, Deliverables and communication. 

So a successful project can be defined as:

Delivery of deliverables in timely and cost effective fashion with keeping client involved throughout the development lifecycle with effective two-way communication involving continuous feedback and information.

 

Deliverables:

Deliverables depend on "how well you understand the requirements?" The understanding should be Complete and Correct.

Below points will help in better understanding the requirements.

• Ask as many questions as possible, no matter how silly they sound.
• Know the "Existing System" before adding new feature or changing it.
• Keep your requirements organized. This will not only help in future references but also help you organize stuff.
• Break the requirements to smaller standalone tasks.
• Prioritize the tasks, and Involve client in this process. Identify tasks that are dependable on others to complete first. Priority is sometimes client driven and sometime driven by complexities of implementation or both.
• Be adaptable to requirement changes in later stages also.
• Identify changes for current release or put them for next release. If changes are not of high priority then mark them for next release else incorporate in current release.
• Take approval if time exceeds your expectations from what is initially anticipated for changes that client requests or you oversee.
• Don't surprise the client. Keep him in loop as much as you can take his approval before working on a feature. 
• It's sometimes said that it's easier to ask for forgiveness than it is to seek permission.

Time and Cost:

Cost depends on time. So take utmost care about time that was initially anticipated.

• Give reasonable estimates at the first place. 
• Inform client "when estimates exceed", tell then the reason why it is exceeding and take approval. Sometimes complications occur during development and more time is needed then please inform client ASAP.
• Stick to the time you committed. 
• Do NOT wait until you have met or exceeded an estimate before you notify the client that the project is running late. 
• Never keep the client in the dark when you exceed your estimates as it will only arouse suspicion and mistrust when the project deadline whooshes past!
• Release Plans are required to be formally approved before work commences. Similarly, any changes to the release plan need approval. Changes to the release plan can take following form:

Communication:

Happy customers = paycheck.

• Who Are Your Customers? 
• Also Identify customers as Technical or Non-technical. Put yourself in their shoes and think as you were them and draft your communication accordingly.
• Every Customer is Your Favorite Customer
  Treat each customer as if he or she is your favorite customer. Put enthusiasm in your voice when Favorite Customer calls you for the 10th time in a week asking where his document or her training device is. It's tough to be cheerful all the time, but put your best attitude out there. Nobody wants to deal with a cranky, grouchy, bad-asp attitude. 
• Be Polite.
• There is nothing called more communication. Clear all your doubts and accept things only when they are clear to you. This may sometimes be like bugging the client, but in long run it always helps.

After heavy technical sessions, the time was perfect for some snacks and cold drinks.

 

 

The speakers and some users were presented by mementos from C# Corner.

 

Attendees were:

Praveen Kumar(Admin/Editor), Kamal Rawat, Dinesh Beniwal(Editor), Manish Dwivedi, Gaurav Sharma, Pradeep Pandey, Purushottam Rathore, Deepak Verma(all C# Corner Team), Arjun Panwar, Manish Singh, Deepak Dwij, Vikas Mishra, Manoj Panwar, Amit Maheswari, Rajesh, Vineet Saini, Akshay Tewatia, Virendra Kumar Patel, and Rakesh Kumar.