Thursday, October 18, 2012

Version Control System: For my Ninth Grader - Part 2


Version Control System: For my Ninth Grader - Part 1


Day 2

Teacher: So, writers, let’s see what plan you have to write story in collaborative way.

Yash: After lot of discussion we have come to following plan:

Story will be divided into two sections: Europe and Asia.

Jay, Gil, and Tina will be working on Europe section. Jim and I will be working on Asia section. So we will be maintaining two different word files:

a.       Europe.doc

b.      Asia.doc

To announce to group that some is working on a file, he will append his name in the end of file. So if Jim is working on file then file name will be

Asia_Jim.doc

As soon Jim stops working, he will save the file and change the name to Asia.doc

Using this naming convention, whole group will come to know that who is working on a particular file, so do not mess up.

Teacher: Excellent! Any one has some other idea.

Sheila: I will solve this problem in different way. Instead of updating document file name, I will prefer to keep a ReamMeFirst document. Whenever one wish to start working on a file – say Asia.doc, she will enter her name, file name, date and time of start of work. Once she finishes her work and saves Asia.doc, will need to key in the small details what she has done and when she stopped working, so other can start working on same file if wish. So ReadMeFirst file will contain a table very similar to:



Sr. #
File Name
Who
Start working at (Date and Time)
Stop working at (Date and Time)
Description
1
Asia.doc
Sheila
Oct 1, 2012 8.00 AM
Oct 1, 2012 9.00 AM
Paragraph about landing at Delhi in early morning while airport is covered in dense fog
2
Asia.doc
Joe
Oct 1, 2012 11.00 AM
Oct 2, 2012 3.00 PM
Sightseeing at Delhi
3
Europe.doc
Kale
Oct 1, 2012 8.15 AM
Oct 1, 2012 6.00 PM
Accident at Venice






 
So everyone can keep track of who is working and on what she is working. The way suggested by Group 1 does not keep track of each individual’s workings.

Teacher: Fantastic way of solving a problem. Any other idea!

Saito: I have another idea to solve the same challenge.

Teacher: Go ahead.

Saito: I will take a different route.  As you know when you right click using mouse on a file you encounter a menu

 
Choose properties from that menu. This will open a dialogue box.


 


In this dialogue box, there are two tabs. General and Summary. In General tab, under Attributes heading, there is a check box labeled as Read-only. So whenever one starts working on file, makes a copy of Asia.doc at his computer (may be via email or flash drive) and mark original Asia.doc as Read-only. This will prevent others from changing the file while someone else is working. As soon as one who was working on the file finishes his work, will copy his file to common computer and delete the old file. This will make new file as original file. To keep track of who is working on what, each writer can keep on adding few lines of his work at Comments area at Summary Tab.



Teacher: Wonderful. Any other idea!

Silence....

Teacher: Okay, let us summaries all three approaches and critically analyze each. Let us make a comparison table:



Approach Name
Name Update
ReadMeFirst File
Properties of File
Approach Description
File names will be updated by the writer to indicate that someone is working on this file. Depending upon file name one should work on file or not.
A master file will be maintained, to indicate who is working on which file. Before working on a file, one should go through the ReadMeFirstFile to ascertain that no one is working on the file on which he is planning to work at this point of time.
One will make copy of file on which he is intend to work and mark the original file as Read-Only. Once writer finishes his work, he can bring in new file and delete the old file. So new file becomes original file. For record keeping, one can choose to write few lines of his work in comments section of Properties dialogue box.
  
Is this table is correct representation of approaches.

Students: Yes.

Teacher: Ok, now next step. Each approach has few positives and negatives, let us list them.

Table after a while:


Approach Name Name Update ReadMeFirst File Properties of File
Approach Description File names will be updated by the writer to indicate that someone is working on this file. Depending upon file name one should work on file or not. A master file will be maintained, to indicate who is working on which file. Before working on a file, one should go through the ReadMeFirst to ascertain that no one is working on the file on which he is planning to work at this point of time. One will make copy of file on which he is intend to work and mark the original file as Read-Only. Once writer finishes his work, he can bring in new file and delete the old file. So new file becomes original file. For record keeping, one can choose to write few lines of his work in comments section of Properties dialogue box.
Can multiple persons work on a file at a given time? No No No
Can every one work on his copy of document? Yes, with slight modification in approach. But even then only one person at a time Yes, with slight modification in approach. But even then only one person at a time Yes. But even then only one person at a time
Is history of work maintained? No No. But comments from each writer are preserved No. But comments from each writer are preserved
If many persons (not few) are involved, will this approach be suitable? Yes No. Because ReadMeFirst become too big. No, because comments will become substantially big.
If work is big ( say novel to be written instead of a story), will this approach is suitable Yes No. Because ReadMeFirstFile become too big. No, because comments will become substantially big.
Over writing of work by mistake Yes. One can forget to update the name of the file or One can over write file even if name is suffixed with current writer. Yes. One can forget to update the ReadMeFirst table or One can over write file even if proper entries are made in ReadMeFirst table. Yes. One can forget to mark file read only.
Over writing of work due to bad intentions Yes Yes Yes
Deletion of file (by mistake or bad intentions) Yes Yes Yes



So, is there any solution which can solve all of the challenge thrown by collaborative nature of work?

Yash: What if we combine all of the solution into one.

Teacher: Yes. Few of the challenges will be solved but one big challenge will crop up.

 Yash: Which one?

Teacher: Too much of human intervention. And more human interventions means more chances of error and vandalism.

Yash: We can automate these tasks!

Teacher: Yes. That will solve few of the problems and human intervention can be reduced to minimum. Before moving to automated solution let us design a solution which can solve most of the challenges we have listed in table.

We will meet tomorrow and will develop a system or technique and then try to understand what parts can be automated.

Tuesday, October 16, 2012

Version Control System: For my Ninth Grader - Part 1




Teacher: In this week we will try to understand how hundreds of people work collaboratively and achieve the result.

One of the students: That will be fun.

Teacher:  Yep. So, let us divide the class into two groups. One group will write a story on topic of its choice as a collaborative effort while second group will observe their workings while completing the story over time period.  Okay, so in here are members of story writing group

Group 1: Yash, Jim, Jay, Tina & Gil à Writers

Group 2: Ram, Joe, Sheila, Kim, Scott, Kale, Aziz, Vijaya, Kale, & Saito à Observers

Now we will meet after break. By that time, Group 1 will provide high level view of story and methodology of their working while writing story.
Any question?

Yash: What do you mean by methodology of working?

Teacher: hmm. Methodology means how your group manages the story writing efforts if more than one person is writing the story at a given point of time. How your group will sync up the works of each person without breaking the story theme, etc.
I hope this answers your question.

Yash: Kind of, but still not very clear.

Teacher: Let you start with this understanding and present the case, during your presentation whole class will help you to refine the methodology.

Yash: Okay

Teacher: So let’s meet after break.

Day 1: After break

Teacher: So everyone is in the room, so let’s start. I hope each group is ready with high level view of story and working methodology to be adopted to complete the story.  Let’s start with Group 3. Who is presenting the case?

Yash: Gil and I will be talking on behalf of group.

Teacher: Okay.

Yash: So, folks as you are aware our group has five members – Jay, Gil, Jim, Tina and me. We will be writing a story about a boy who is travelling around the world with his uncle. This story will talk about his experiences.

Gil: We will be dividing story into five sections so each of team members can write a section in separate MS Word document which can be merged later. To keep the flow of story intact, we will be meeting daily and discussing.

Teacher: That’s great. I have few comments to make. First Group 1 is consisting of smart folks. You have chosen a theme of story which is easy to write by multiple persons simultaneously and second you have divided story into five sections which is equal to number of writers. But in real life you do not get both advantages even one. In almost all scenarios work is not divisible so clearly among workers. To make whole thing more realistic, we need to write two sections and at a given day more than one person can work on a section.

You can come with solution to resolve this conflict in tomorrow’s class. Is it fair!

Gil: Yep.

Teacher: So let us meet tomorrow.

Thursday, October 11, 2012

Enterprise Systems - How to distinguish between various environments?

Fact 1: In any enterprise we have at least three environments – development (dev), test (tst), and production (prd). I know in real life we have more like UAT, Stage, Load & Performance, Disaster recovery, etc. You can add few more environments for development and test to keep up the pace with multiple releases running simultaneously. For brevity let’s stick to three.

Fact 2: Developers, testers and support personnel have access to more than one environment at a given point of time. Developers may have read only access to tst and prd. Support people might have full access to prd and tst and read only to dev. Testers might have full access to tst environment and read only to prd. Developers, testers and support personnel access more than one environment at a given point of time.

Fact 3: Most of the enterprise system today have web interface which is accessed by developers and support personnel. Take for example oracle fusion middleware - BPEL PM, ESB, OSB, WebLogic’s various functionality are exposed via web (http and/or https).



Enterprise Manager
http://<>.example.com/em
BPELAdmin
http:// <>. example.com/BPELAdmin
BPELConsole
http:// <>. example.com/BPELConsole
Enterprise Service Bus
http:// <>. example.com/esb
Oracle Webservice Manager
http:// <>. example.com/ccore
Oracle Service Registry
http:// <>. example.com/registry/uddi/web
AIA console
http:// <>. example.com/AIA


Similar interfaces exist for WebSphere, jBoss and many more enterprise class systems.

Now consider a scenario. One bug is reported by testers. To understand the bug and reproduce there is a meeting in which developers, testers and support personnel are present. Say on developers’ computer screen, all three environments are open in browser. And to more, multiple tabs are open for same environment. Now consider amount of confusion it can create. On a single computer in a single browser window multiple environments are open and each environment’s different views in multiple tabs of browser! Oh my….

Yes this confusion can be tackled up to some extent using multiple browsers (say a developer can decide that he will open dev in FireFox, tst in Opera, and prd in IE) and multiple desktops. But even there is no visual marker to distinguish one environment from another except address bar.

So, what is the solution? Simple mechanism of changing background color or web page as per environment ( say green for dev, blue for tst, and red for prd) and various shades in case of permissions ( read only permission gives lighter shade while read write permission gives darker shades).

What do you think?