SVN Modified File Checkins - Guidelines

In any software project development, we use configuration tools such as SVN, ClearCase etc for configuration management activities. We work on the project files and check in them back to configuration server after we are done working on those files. In a bigger projects, there will be thousands of source files that project members will be working on. The activities involved are checking out the source code, work on them and then check-in the modified project source files. Checking in huge number of modified files(Jar, EXE, DLL etc) is sometimes not an easy task if proper guidelines are not followed. Every check in has effect on the existing source base and often developers fail to realize the effect or realize it too late. In this short article, I am going to explain few guidelines while checking in the modified source files keeping SVN(Subversion) as example.

•  Take an SVN update on all the source files that are potentially impacted by your local modifications.

• While taking SVN upate, there are chances of merges being happened. The merges will sometimes be merged well with your changes or there can be conflicts. Resolve the conflicts manually and verify that your changes are appearing. Its best practice to keep a backup of all your modified files since conflicts can be confusing and you tend to revert your changes and freshly want to merge your changes using some tools called beyond compare etc.

• Build all the project modules to verify that there are no compilation errors. 

• If any error occurs (this could usually happen because SVN didn't merge correctly or some dependency between classes broke) then fix those errors and compile again

• Once there are no compile errors commit your changes

The bove steps can also be automated by using SVN commands. The most used SVN command lines are as follows

• svn update [Path to project files]
• svn commit [Path of the file(s) to commit> --message <commit comment]
• svn resolve --accept=ARG [PATH...]
• svn resolve [Path of file(s) to revert]
• svn checkout checkout URL[@REV]... [PATH]
• svn add [Path of files to add]  - Adds non version-ed files to subversion
• svn log [Path of the file location or revision] - Shows the log messages for a set of revision(s) and/or file(s) 
• svn status [Path] - This can be used to print the status of local files or files in the repository.

Furthermore you can also integrate your batch file or ant script with your IDE. In eclipse,

• Go to Run->External Tools->External Tools Configurations.
• Create a new Ant build for ant scripts or Program for your batch file
• Point to your ant script or batch file. Click Apply and then click Run.
• The external tool will now appear in the Run->External Tools->External Tools Configurations menu.

 For a complete guidelines on Configuration Management, visit Configuration Management Best Practices.

Types Of Software Testing

"My Software never had bugs; it just develops random features!" - This is a famous software developer quote. A better way to say there are bugs crept in the software. Let's answer the question 'when software is said to have bugs?' Well, when software behaves in an unexpected manner. In other words when your software produces a behavior that is never ever defined for it. This can happen due to several reasons. Have a look at different types of software errors and how to deal with them. In this article I'm going to explain what are the typical types of software testing methods to detect unexpected software behavior.

Unit Testing(UT)

Well, this is the most powerful and essential testing method. Unit testing is carried out by the developer himself/herself to see if the code written by him/her works as expected. In this type of testing, every method/ function written is tested for boundary conditions and for each conditional statements used in the method. Unit test cases are written prior to unit testing the code. There are two types how unit testing is carried out.(1) Automated Unit Testing - This is done by writing the code to test the code. There are tools/frameworks to do this. For Java code, the tool is called JUnit. (2) Manual Unit Testing - The possible unit test cases are written in a document in English Statements and then executed one by one. Manual unit testing is a time consuming method. The best practice is to use code coverage methods during Unit Testing to see if sufficient test cases are written. See how to collect code coverage reports for Java Code.

Developer Integration Testing(DIT)

In this type of testing all the public interfaces are tested to see they integrate well with all the modules in the project. As the name indicates, this type of test is executed by developers. DIT is very important method of software testing since DIT decides if all the software modules 'integrate' well themselves. DIT is a nightmare if public interfaces are not well defined. The best practice is that public interfaces are to be developed by a person who understands entire software architecture usually by a System Architect.

System Integration Testing(SIT)

System Testing is carried out by testing team and usually not by developers. Testing team develops system test plan and executes them. System testing also comprises  of Capacity and load testing of the software as a whole system apart from testing how well the software system under testing integrates with rest of the systems in the software portfolio. This especially important where a software product needs to work with different software products in an enterprise solution.

Smoke Testing(ST)

This type of testing is also known as acceptance testing. This test is carried out to see if there is any 'smoke' in the software before even full fledged software testing is taken up by the testing team. If the software has smoke, then further testing will be stopped and software build/release will be rejected until the smoke has been removed from the software by the developers.

Regression Testing (RT)

This type of testing is carried out by the system testers. Regression testing does not follow a definite pattern. The regression test cases are developed based on the code changes done. This type of testing very common in maintenance projects where the software is already developed and there some change requests (CRs) done on top of it and is given for testing it. See what should be the quality of regression testing.

The testing methodologies differ based on the type of the software being developed. For example, if its a software product then regression testing applies and usually not for software services. Not all software testing methodologies are mandatory for software testing. Software testing has been a challenge in the software development life cycle. People have hard time dealing with non reproducible software bugs. Have a look at my article on how to deal with non reproducible software bugs/issues.

Hope you enjoyed this article.

Types of US Visas

I've compiled the list of all US visas, hope this helps people looking for US Visa types information.

A Visas (Official Visas)

A-1: For Ambassadors, public ministers & consular officers
A-2: For immediate family members of A-1
A-3: Attendants & servants of A-1 and A-2 holders

B (Business/Visitor) Visa

B-1 Temporary visitor for business
B-2 Temporary visitor for leisure

C & D Visa (For Aliens in transit)

C-1,2: Alien in transit directly through US
C-3: Family of C-1,C-2 in transit
C-4: Transit without Visa(TWOV)

D-1: Sailors departing on vessel of arrival
D-2: Sailors departing by other means

E - Visa (For Traders/Investors)

E-1 Treaty Trader, spouse and children
E-2 Treaty Investor, spouse and children

F Visa (Students)

Want to study or research at a U.S. college? Then F is the visa for
you -
F-1: Academic Student
F-2: Spouse or child of F-1

H (Temporary Worker) Visa

H-1B: Persons in a specialty occupation
H-2B: Seasonal nonagricultural workers
H-3: Trainees other than medical/academic; also training of handicaps
H-4: Dependants of H visa holders

I Visa (Mediapersons) 

Are you a reporter, film person, Editor? Then you require an I-visa -
Essential docs: Your press ID, a letter from the editor.

J & Q Exchange Visitor Visa

J-1 exchange visitors may be academics, scientists, businesspeople or
students.
J-1: Visas for exchange visitors
J-2: Spouse or 'child' of J-1 under 21

K Fiance(e) of US Citizen

K-1 Fiance(e)
K-2 Minor child of K-1
K-3 Spouse of a U.S. Citizen (LIFE Act)
K-4 Child of K-3 (LIFE Act)

Docs: Marriage certificate & Photos, Intent of marrying within 90
days in US(for K1).

L Visa (Intracompany Transferees)

L-1A Executive, managerial
L-1B Specialized knowledge
L-2 Spouse or child of L-1

M Vocational and Language Students

M-1 Vocational student or other non-academic student
M-2 Spouse or child of M-1

O -Visa (For Prodigies)

O-1: For a Genius in Sciences, Arts, Education, Business, or
Athletics.
O-2: Alien's (support) accompanying O-1
O-3: Spouse or child of O-1 or O-2

P Athletes and Entertainers

P-1: Athletes & Entertainment groups
P-2: Entertainers in exchange programs
P-3: Entertainers in cultural programs
P-4: Spouse or child of P-1, 2, or 3

R -Visa (Religious Workers)

R-1 Religious workers
R-2 Spouse or child of R-1

Income Tax Returns E-Filing

Income tax returns are now made easier and quicker.  Avoid giving money to agents. Please use the following E-Filing procedures to submit your returns

1. Open the following URL - https://incometaxindiaefiling.gov.in/portal/index.jsp
2. Navigate the bottom of the page and locate “ e-Filing Process – At a glance”
3. Follow the steps to file your returns

Follow the steps to file your returns

1. Select appropriate type of Return Form
2. Download Return Preparation Software for selected Return Form.
3. Fill your return offline and generate a XML file.
4. Register and create a user id/password
5. Login and click on relevant form on left panel and select "Submit Return"

6. Browse to select XML file and click on "Upload" button

7. On successful upload acknowledgement details would be displayed. Click on "Print" to generate printout of acknowledgement/ITR-V Form.

8. Incase the return is digitally signed, on generation of "Acknowledgement" the Return Filing process gets completed. You may take a printout of the Acknowledgement for your record.

9. Incase the return is not digitally signed, on successful uploading of e-Return, the ITR-V Form would be generated which needs to be printed by the tax payers. This is an acknowledgement cum verification form. A duly signed ITR-V form should be mailed to “Income Tax Department – CPC, Post Bag No - 1, Electronic City Post Office, Bengaluru - 560100, Karnataka, ” BY ORDINARY POST OR SPEED POST ONLY   within 120 days of transmitting the data electronically.
ITR-V sent by Registered Post or Courier will not be accepted.
No Form ITR-V shall be received in any other office of the Income-tax Department or in any other manner. In case, Form ITR-V, is furnished after the above mentioned period, it will be deemed that the return in respect of which the Form ITR-V has been filed was never furnished and it shall be incumbent on the assessee to electronically re-transmit the data and follow it up by submitting the new Form ITR-V within 120 days. This completes the Return filing process for non-digitally signed Returns.

10. To reset the password, click on the forget password link from the login page. In the password reset page, enter either of the following data :
Enter your secret question and answer which you entered during registration
(OR)
Enter the assessment-year and acknowledgement number of any of the e-returns filed by you since assessment year 2007-08.
Then enter the new password twice and then the text from the image below. Click on Reset Password to reset the password of your user.

11. For any assistance in electronic filing please contact the Public Relations Officer of the local Income Tax Office