Wednesday, November 14, 2018

No compiler is provided in this environment. Perhaps you are running on a JRE rather than a JDK

Add 'tools.jar' to installed JRE.

Eclipse -> window -> preference.
Select installed JREs -> Edit
Add External Jars
select tools.jar from java/JDKx.x/lib folder.
Click Finish

Thursday, April 12, 2018

Git - Branching and Merging strategy

GIT

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

The Git feature that really makes it stand apart from nearly every other SCM out there is its branching model.

Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds.

1. Basic Git commands

Following diagram, depicts the git model and the commands

git init: Create a new local repository
git status: List the files you've changed and those you still need to add or commit
git clone: Create a working copy of a local repository
git fetch <remote>: Fetch all commits from remote branch “upstream” into local repository
git commit record your changes to the local repository.
git push: Push the branch to your remote repository, so others can use it:
git merge origin/<current branch>: To merge a different branch into your active branch
git pull <remote>: Fetch the specified remote’s copy of the current branch and immediately merge it into the local copy. This is the same as git fetch <remote> followed by git merge origin/<current-branch>.
tag: described in further section.

2. Branch

A branch is an additional line of development, where the developer can work independently of the main development line. When the developer is happy with the changes he made to the branch, he can push these changes into the main development line.

§ Branching enables parallel software development activities

§ Implement different features on braches for same code base

§ Maintain different releases in branches

§ Branching = ISOLATION

3. Basic Branches

For supporting the different development efforts and versions, the GIT Owner enforces the usage of the following branches:

Master
Development
Feature Branch (1..n)
Hot Fix (1..n)

4. Branching strategy

The workflow is defined below:

This workflow uses mainly 3 branches to track the history:

§ master branch,

§ development branch

§ and feature branch (1..n).

The development branch is the default branch that tracks the development activities and the master branch keeps track of production code activities.
The development (dev and QA) of each feature will reside in its own feature branch. This isolates new development from finished work and also allows development of multiple features at the same time.
Once the development of feature is complete, after QA sign off, should be pushed to development branch.
Once we have enough features for a release and are ready for testing, a release branch is created.

After creating release branch, no new features can be added to it. Only bug fixes, documentation generation, and other release-oriented tasks should be given in this branch.
The code in the release branch is deployed onto a suitable test environment, and tested, and if we find any problems, they are fixed directly in the release branch. This deploy -> test -> fix -> redeploy -> retest cycle continues until code is ready for production release.
Once it is ready to ship, the code is deployed to production and the release branch gets merged into master branch and tagged with a version number.
In addition, it should be merged back into development branch to reflect all the changes (bug fixed) that are made in release branch

§ For any production issues a hotfix branch is created. As soon as the fix is complete, the code is deployed to production and it should be merged into both master branch and development branch.

5. Master Branch

§ Master branch must at all times, reflect what is on the live production site.

§ When a new compiled version of an application is validated and approved in production after its installation, the release branch is merged into this branch

6. Development Branch

§ Is the place where the development team merges all the code.

§ Is the place where the merge issues between all the parallel development efforts will happen.

§ Ideally, no direct development should happen on this branch (just merge issues resolution)

§ The dev team can create as many Feature branches out of this branch as required to support their development efforts.

7. Feature Branch

§ Always create feature branch while working on a new feature and feature branch should have a meaningful feature name for identification.

o Before starting the branch always perform git pull and git status commands to get the latest code from remote repository.

§ Commit the changes to the local repository.

o e.g. git add. (to add all the files, for specific files use file name or folder name instead of ".")

o git commit -m "ABC-1 #comment Initial commit for the feature"

§ After the changes are staged, git push command can be used to push commits made on your local branch to a remote repository

o e.g. git push <REMOTENAME> <BRANCHNAME>

§ Again when more than one person is working on the same branch, whenever a change pushed by one can be consume by the other using git pull command.

§ When the feature completed and review completed it can be merged to the development branch.

8. Release branch

After all the desired features for a release is completed (as in merged in development branch) a release branch has to created.
The focus for this branch is to harden the features within this release and make it ready for the release. This can include testing and bug-fixes.
Code changes related to bug fixes should be done on this branch - git commands are used during this process.
The changes have to be merged to development branch as well once done using git commands.
When the code is ready for production deployment, merge(locally) changes to master and in develop.

Unlike feature branch, when finishing the release branch, release notes should be provided which is then tagged to master when release is merged with master.
To merge the changes to development, use git checkout development and git push commands as shown above.
To merge the changes to master use git checkout master and git push --tags (to push the tags to remote along with the code)

9. The Hot Fix Branch

§ This is a short duration branch created from master branch, and is created specifically for production bugs.
The branch name has to be the bug id to provide tractability
Its purpose is to create a patch (or hot fix) to solve a production issue

o Once the hot-fix is completed, release notes has to provided and is merged to master and development branch.

o For any hot fixes that gets into production during development (feature /release hardening):

ü ensure that changes are pulled down from development to feature branch (git merge) before pushing the feature to develop.

ü ensure that changes are pulled down from master to release branch (git merge) before pushing the release to production.

10. Tagging

Tagging is reference used to capture a point in history that is used for a marked version release (i.e. v1.0.1). A tag is like a branch that doesn’t change. Unlike branches, tags, after being created, have no further history of commits.

Two types of Tagging:

§ Lightweight Tags

Another way to tag commits is with a lightweight tag. This is basically the commit checksum stored in a file — no other information is kept. This is for private, and generally version numbers are stored.

git tag v1.4-lw

§ Annotated Tags

Use every time annotated tags rather than Lightweight Tags. This would store tagger information, the date the commit was tagged, tagger name, date and the annotation message before showing the commit information.

git tag -a v1.4 -m "my version 1.4"

11. Responsibilities

§ Dev Team:

o Maintain all the Feature branches of the Development Branch

o Communication and coordination between the teams working in all the Development Branch children branches

§ Hot Fix Team:

o Require creation of Hot Fix branches only when needed: scheduled maintenance development should happen in a standard development branch

§ GIT Owner:

o Merges to and from Master Branch

o Communicate to Dev team every time a change from a Hot Fix branch is merged back into Production for rapid integration

o Coordinate resolution of any merge conflict that may arise

12. Merge Conflicts

§ Always fix ALL Merge Conflicts.

§ Coordinate with the authors of the changes

§ Consult with the Scrum Master

§ Use a merge tool*

§ When in doubt, have a merge party

§ Communicate, communicate, COMMUNICATE!

13. Best Practices

§ Use meaningful Branch name where applicable

§ Integrate early and often to avoid “Bing-bang merge”

§ Avoid cascading branches

§ Preserve the physical integrity of the branch

§ Isolate Change

§ Isolate Work, Not People

Tuesday, August 26, 2014

ASP.Net Forms Authentication

<configuration>
<system.web>
<authenticationmode="Forms"/>
<authorization>
<deny users = "?" /> ------------- deny all anonymous users
</authorization>
</system.web>
</configuration>

If anonymous access the Default.aspx page, then its redirected to Login.aspx (this is default by rule).

Login_Click()
{
if(IsAuthenticateUser(username, password)) ) -- does the dB lookup validation
{
FormsAuthentication.RedirectFromLoginPage(username, true) -- true means cookie is stored in hard disk. false means cookie is stored in browser.
}
else
{
Invaid user
}
}

LogOut_Click()
{
FormsAuthentication.Signout();
}

User logs into applciation, get the Cookie from the Browser and the Harddisk. Change his User privilege to Admin privilege.......
You are protected by ASP.net, dont worry

ASP.Net

     1                                         2                                          3
SecretKey + ASP.Net hashes Cookie content += Message Authentication code

2 and 3 are stored in cookie... any alteration the User does to the cookie, ASP.net can identify by doing check sum for 1 and 2 and checks the 3 is been is retiried correctly.

Its wise to program in in terms of Roles but Users -- User.IsInRole("Doctors")

<configuration>
   <system.web>
      <authenticationmode="Forms"/>
      <authorization>
          <deny users = "?" /> ------------- deny all anonymous users
      </authorization>
   </system.web>
</configuration>

<location path="Doctors.aspx">
<system.web>
     <authorization>
        <allow roles ="doctor"/>
        <deny users="*" />
   </authorization>
<system.web/>
</location>

In Global.asax, setup the roles for logged in User in the Init() method

Global.ascx.cs
public override void Init()
{
     AuthenticateRequest += new EvenHandler(Global_AuthenticateRequest)
      // AuthenticateRequest -- rip apart the Cookie and give the Identity. This will run after all the
        Modules were run. (ex: Form Authentication)
}

void Global_AuthenticateRequest(object sender, EventArgs e)
{
     if(Request.IsAuthenticated)
          SetupRoles();
}

void SetupRoles()
{
        IIdentity formsIdentity = Context.User.Identity();
        string[] roles = LookupForRoles(formIdentity.Name); // Get the Roles of the user
        IPrincipal principalWithRoles = new GenericPrincipal(formIdentity, roles);
        Context.User = principalWithRoles;
        Context.Items["roles"] = roles;
}

Saturday, May 10, 2014

AngularJs Part - I

No Classes or IDs in the HTML to identify where to attach event listners
No event listeners or call backs
Web applications create their HTML by assembling and joining it with data on the server, and then shipping the finished pages up to the browser
In Angular js, the template and data get shipped to the browser to be assembled there.

<!

DOCTYPE html>

<

html ng-app>

<

head>

<title>Hello World, AngularJS - ViralPatel.net</title>

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/angularjs/1.0.7/angular.min.js"></script>

</

head>

<

body>

<div ng-controller="HelloController">

<input ng-model='greeting.text'>

<p>{{greeting.text}}, World</p>

</div>

<script type="text/javascript">

function HelloController($scope) {

$scope.greeting = { text:
'hi' };

}

</script>

</

body>

</

html>

Thursday, May 8, 2014

C# - Generics

Concept of type parameters

// Declare the generic class. 
public class GenericList<T>
{
    void Add(T input) { }
}
class TestGenericList
{
    private class ExampleClass { }
    static void Main()
    {
        // Declare a list of type int.
        GenericList<int> list1 = new GenericList<int>();

        // Declare a list of type string.
        GenericList<string> list2 = new GenericList<string>();

        // Declare a list of type ExampleClass.
        GenericList<ExampleClass> list3 = new GenericList<ExampleClass>();
    }
}

You can create your own generic interfaces, classes, methods, events and delegates.

Generic classes may be constrained to enable access to methods on particular data types.

Information on the types that are used in a generic data type may be obtained at run-time by using reflection.

Generic classes and methods combine reusability, type safety and efficiency

Generics are most frequently used with collections and the methods that operate on them.

System.Collections.Generic

Generics provide the solution to a limitation in earlier versions of the common language runtime and the C# language in which generalization is accomplished by casting types to and from the universal base type Object

By creating a generic class, you can create a collection that is type-safe at compile-time.

ArrayList is a highly convenient collection class that can be used without modification to store any reference or value type.

// The .NET Framework 1.1 way to create a list:

System.Collections.ArrayList list1 = new System.Collections.ArrayList();

list1.Add(3);

list1.Add(105);

System.Collections.ArrayList list2 = new System.Collections.ArrayList();

list2.Add("It is raining in Redmond.");

list2.Add("It is snowing in the mountains.");

But this convenience comes at a cost. Any reference or value type that is added to an ArrayList is implicitly upcast to Object. If the items are value types, they must be boxed when they are added to the list, and unboxed when they are retrieved. Both the casting and the boxing and unboxing operations decrease performance; the effect of boxing and unboxing can be very significant in scenarios where you must iterate over large collections.

The other limitation is lack of compile-time type checking; because an ArrayList casts everything to Object, there is no way at compile-time to prevent client code from doing something such as this:

System.Collections.ArrayList list = new System.Collections.ArrayList();

// Add an integer to the list.

list.Add(3);

// Add a string to the list. This will compile, but may cause an error later.

list.Add("It is raining in Redmond.");

int t = 0;

// This causes an InvalidCastException to be returned.

foreach (int x in list)

{

t += x;

}

Although perfectly acceptable and sometimes intentional if you are creating a heterogeneous collection, combining strings and ints in a single ArrayList is more likely to be a programming error, and this error will not be detected until runtime.

In versions 1.0 and 1.1 of the C# language, you could avoid the dangers of generalized code in the .NET Framework base class library collection classes only by writing your own type specific collections. Of course, because such a class is not reusable for more than one data type, you lose the benefits of generalization, and you have to rewrite the class for each type that will be stored.

What ArrayList and other similar classes really need is a way for client code to specify, on a per-instance basis, the particular data type that they intend to use. That would eliminate the need for the upcast to T:System.Object and would also make it possible for the compiler to do type checking. In other words, ArrayList needs a type parameter. That is exactly what generics provide. In the generic List<T> collection, in the N:System.Collections.Generic namespace, the same operation of adding items to the collection resembles this:

// The .NET Framework 2.0 way to create a list

List<int> list1 = new List<int>();

// No boxing, no casting:

list1.Add(3);

// Compile-time error:

// list1.Add("It is raining in Redmond.");

For client code, the only added syntax with List<T> compared to ArrayList is the type argument in the declaration and instantiation. In return for this slightly more coding complexity, you can create a list that is not only safer than ArrayList, but also significantly faster, especially when the list items are value types.

class Program

{

static void Main(string[] args)

{

var add1 = new Add<string>();

add1.AddNumbers("var");

}

public class Add<T>

{

public void AddNumbers(T input)

{

Console.WriteLine(input);

Console.ReadKey();

}