Thursday, January 20, 2011

Git Essestials


Git Commands
------------

git clone
  clone the repository specified by ; this is similar to "checkout" in
  some other version control systems such as Subversion and CVS

Add colors to your ~/.gitconfig file:

  [color]
    ui = auto
  [color "branch"]
    current = yellow reverse
    local = yellow
    remote = green
  [color "diff"]
    meta = yellow bold
    frag = magenta bold
    old = red bold
    new = green bold
  [color "status"]
    added = yellow
    changed = green
    untracked = cyan

Highlight whitespace in diffs

  [color]
    ui = true
  [color "diff"]
    whitespace = red reverse
  [core]
    whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol

Add aliases to your ~/.gitconfig file:

  [alias]
    st = status
    ci = commit
    br = branch
    co = checkout
    df = diff
    lg = log -p
    lol = log --graph --decorate --pretty=oneline --abbrev-commit
    lola = log --graph --decorate --pretty=oneline --abbrev-commit --all
    ls = ls-files

Configuration
-------------

git config -e [--global]
  edit the .git/config [or ~/.gitconfig] file in your $EDITOR

git config --global user.name 'John Doe'
git config --global user.email johndoe@example.com
  sets your name and email for commit messages

git config branch.autosetupmerge true
  tells git-branch and git-checkout to setup new branches so that git-pull(1)
  will appropriately merge from that remote branch.  Recommended.  Without this,
  you will have to add --track to your branch command or manually merge remote
  tracking branches with "fetch" and then "merge".

git config core.autocrlf true
  This setting tells git to convert the newlines to the system’s standard
  when checking out files, and to LF newlines when committing in

You can add "--global" after "git config" to any of these commands to make it
apply to all git repos (writes to ~/.gitconfig).


Info
----
git reflog 
  Use this to recover from *major* fuck ups! It's basically a log of the
  last few actions and you might have luck and find old commits that
  have been lost by doing a complex merge.

git diff
  show a diff of the changes made since your last commit
  to diff one file: "git diff -- "
  to show a diff between staging area and HEAD: `git diff --cached`

git status
  show files added to the staging area, files with changes, and untracked files

git log
  show recent commits, most recent on top. Useful options:
  --color       with color
  --graph       with an ASCII-art commit graph on the left
  --decorate    with branch and tag names on appropriate commits
  --stat        with stats (files changed, insertions, and deletions)
  -p            with full diffs
  --author=foo  only by a certain author
  --after="MMM DD YYYY" ex. ("Jun 20 2008") only commits after a certain date
  --before="MMM DD YYYY" only commits that occur before a certain date
  --merge       only the commits involved in the current merge conflicts

git log ..
  show commits between the specified range. Useful for seeing changes from
  remotes:
  git log HEAD..origin/master # after git remote update

git show
  show the changeset (diff) of a commit specified by , which can be any
  SHA1 commit ID, branch name, or tag (shows the last commit (HEAD) by default)

git show --name-only
  show only the names of the files that changed, no diff information.

git blame
  show who authored each line in

git blame
  show who authored each line in as of (allows blame to go back in
  time)

git gui blame
  really nice GUI interface to git blame

git whatchanged
  show only the commits which affected listing the most recent first
  E.g. view all changes made to a file on a branch:
    git whatchanged  | grep commit | \
         colrm 1 7 | xargs -I % git show %
  this could be combined with git remote show to find all changes on
  all branches to a particular file.

git diff head path/to/fubar
  show the diff between a file on the current branch and potentially another
  branch

git diff head --
  use this form when doing git diff on cherry-pick'ed (but not committed)
  changes
  somehow changes are not shown when using just git diff.

git ls-files
  list all files in the index and under version control.

git ls-remote [HEAD]
  show the current version on the remote repo. This can be used to check whether
  a local is required by comparing the local head revision.

Adding / Deleting
-----------------

git add ...
  add , , etc... to the project

git add

  add all files under directory
to the project, including subdirectories

git add .
  add all files under the current directory to the project
  *WARNING*: including untracked files.

git rm ...
  remove , , etc... from the project

git rm $(git ls-files --deleted)
  remove all deleted files from the project

git rm --cached ...
  commits absence of , , etc... from the project

Ignoring
---------

Option 1:

Edit $GIT_DIR/info/exclude. See Environment Variables below for explanation on
$GIT_DIR.

Option 2:

Add a file .gitignore to the root of your project. This file will be checked in.

Either way you need to add patterns to exclude to these files.

Staging
-------

git add ...
git stage ...
  add changes in , ... to the staging area (to be included in
  the next commit

git add -p
git stage --patch
  interactively walk through the current changes (hunks) in the working
  tree, and decide which changes to add to the staging area.

git add -i
git stage --interactive
  interactively add files/changes to the staging area. For a simpler
  mode (no menu), try `git add --patch` (above)

Unstaging
---------

git reset HEAD ...
  remove the specified files from the next commit


Committing
----------

git commit ... [-m ]
  commit , , etc..., optionally using commit message ,
  otherwise opening your editor to let you type a commit message

git commit -a
  commit all files changed since your last commit
  (does not include new (untracked) files)

git commit -v
  commit verbosely, i.e. includes the diff of the contents being committed in
  the commit message screen

git commit --amend
  edit the commit message of the most recent commit

git commit --amend ...
  redo previous commit, including changes made to , , etc...


Branching
---------

git branch
  list all local branches

git branch -r
  list all remote branches

git branch -a
  list all local and remote branches

git branch
  create a new branch named , referencing the same point in history as
  the current branch

git branch
  create a new branch named , referencing , which may be
  specified any way you like, including using a branch name or a tag name

git push :refs/heads/
  create a new remote branch named , referencing on the
  remote.
  Example: git push origin origin:refs/heads/branch-1
  Example: git push origin origin/branch-1:refs/heads/branch-2

git branch --track
  create a tracking branch. Will push/pull changes to/from another repository.
  Example: git branch --track experimental origin/experimental

git branch -d
  delete the branch ; if the branch you are deleting points to a 
  commit which is not reachable from the current branch, this command 
  will fail with a warning.

git branch -r -d
  delete a remote-tracking branch.
  Example: git branch -r -d wycats/master

git branch -D
  even if the branch points to a commit not reachable from the current branch,
  you may know that that commit is still reachable from some other branch or
  tag. In that case it is safe to use this command to force git to delete the
  branch.

git checkout
  make the current branch , updating the working directory to reflect
  the version referenced by

git checkout -b
  create a new branch referencing , and check it out.

git push :
  removes a branch from a remote repository.
  Example: git push origin :old_branch_to_be_deleted

git co
  Checkout a file from another branch and add it to this branch. File
  will still need to be added to the git branch, but it's present.
  Eg. git co remote_at_origin__tick702_antifraud_blocking
  ..../...nt_elements_for_iframe_blocked_page.rb

git show --
  Eg. git show remote_tick702 -- path/to/fubar.txt
  show the contents of a file that was created on another branch and that 
  does not exist on the current branch.

git show :
  Show the contents of a file at the specific revision. Note: path has to be
  absolute within the repo.

Merging
-------

git merge
  merge branch into the current branch; this command is idempotent
  and can be run as many times as needed to keep the current branch 
  up-to-date with changes in

git merge --no-commit
  merge branch into the current branch, but do not autocommit the
  result; allows you to make further tweaks

git merge -s ours
  merge branch into the current branch, but drops any changes in
  , using the current tree as the new tree


Cherry-Picking
--------------

git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x]
  selectively merge a single commit from another local branch
  Example: git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544


Squashing
---------
WARNING: "git rebase" changes history. Be careful. Google it.

git rebase --interactive HEAD~10
  (then change all but the first "pick" to "squash")
  squash the last 10 commits into one big commit


Conflicts
---------

git mergetool
  work through conflicted files by opening them in your mergetool (opendiff,
  kdiff3, etc.) and choosing left/right chunks. The merged result is staged for
  commit.

For binary files or if mergetool won't do, resolve the conflict(s) manually 
and then do:

  git add [ ...]

Once all conflicts are resolved and staged, commit the pending merge with:

  git commit


Sharing
-------

git fetch
  update the remote-tracking branches for (defaults to "origin").
  Does not initiate a merge into the current branch (see "git pull" below).

git pull
  fetch changes from the server, and merge them into the current branch.
  Note: .git/config must have a [branch "some_name"] section for the current
  branch, to know which remote-tracking branch to merge into the current
  branch.  Git 1.5.3 and above adds this automatically.

git push
  update the server with your commits across all branches that are *COMMON*
  between your local copy and the server.  Local branches that were never 
  pushed to the server in the first place are not shared.

git push origin
  update the server with your commits made to since your last push.
  This is always *required* for new branches that you wish to share. After 
  the first explicit push, "git push" by itself is sufficient.

git push origin :refs/heads/
  E.g. git push origin twitter-experiment:refs/heads/twitter-experiment
  Which, in fact, is the same as git push origin but a little
  more obvious what is happening.
  
Reverting
---------

git revert
  reverse commit specified by and commit the result.  This does *not* do
  the same thing as similarly named commands in other VCS's such as "svn 
  revert" or "bzr revert", see below

git checkout
  re-checkout , overwriting any local changes

git checkout .
  re-checkout all files, overwriting any local changes.  This is most similar 
  to "svn revert" if you're used to Subversion commands


Fix mistakes / Undo
-------------------

git reset --hard
  abandon everything since your last commit; this command can be DANGEROUS.
  If merging has resulted in conflicts and you'd like to just forget about
  the merge, this command will do that.

git reset --hard ORIG_HEAD
  undo your most recent *successful* merge *and* any changes that occurred
  after.  Useful for forgetting about the merge you just did.  If there are
  conflicts (the merge was not successful), use "git reset --hard" (above)
  instead.

git reset --soft HEAD^
  forgot something in your last commit? That's easy to fix. Undo your last
  commit, but keep the changes in the staging area for editing.

git commit --amend
  redo previous commit, including changes you've staged in the meantime.
  Also used to edit commit message of previous commit.


Plumbing
--------

test = $(git merge-base )
  determine if merging sha1-B into sha1-A is achievable as a fast forward;
  non-zero exit status is false.


Stashing
--------

git stash
git stash save
  save your local modifications to a new stash (so you can for example
  "git svn rebase" or "git pull")

git stash apply
  restore the changes recorded in the stash on top of the current working tree
  state

git stash pop
  restore the changes from the most recent stash, and remove it from the stack
  of stashed changes

git stash list
  list all current stashes

git stash show -p
  show the contents of a stash - accepts all diff args

git stash drop []
  delete the stash

git stash clear
  delete all current stashes


Remotes
-------

git remote add
  adds a remote repository to your git config.  Can be then fetched locally.
  Example:
    git remote add coreteam git://github.com/wycats/merb-plugins.git
    git fetch coreteam

git push :refs/heads/
  delete a branch in a remote repository

git push :refs/heads/
  create a branch on a remote repository
  Example: git push origin origin:refs/heads/new_feature_name

git push +:
  replace a branch with
  think twice before do this
  Example: git push origin +master:my_branch

git remote prune
  prune deleted remote-tracking branches from "git branch -r" listing

git remote add -t master -m master origin git://example.com/git.git/
  add a remote and track its master

git remote show
  show information about the remote server.

git checkout -b /
  Eg git checkout -b myfeature origin/myfeature
  Track a remote branch as a local branch.
  
git pull
git push
  For branches that are remotely tracked (via git push) but
  that complain about non-fast forward commits when doing a 
  git push. The pull synchronizes local and remote, and if 
  all goes well, the result is pushable.

Submodules
----------

git submodule add
  add the given repository at the given path. The addition will be part of the
  next commit.

git submodule update [--init]
  Update the registered submodules (clone missing submodules, and checkout
  the commit specified by the super-repo). --init is needed the first time.

git submodule foreach
  Executes the given command within each checked out submodule.

Remove submodules

   1. Delete the relevant line from the .gitmodules file.
   2. Delete the relevant section from .git/config.
   3. Run git rm --cached path_to_submodule (no trailing slash).
   4. Commit and delete the now untracked submodule files. 

Patches
-------

git format-patch HEAD^
  Generate the last commit as a patch that can be applied on another
  clone (or branch) using 'git am'. Format patch can also generate a
  patch for all commits using 'git format-patch HEAD^ HEAD'
  All page files will be enumerated with a prefix, e.g. 0001 is the
  first patch.

git am
  Applies the patch file generated by format-patch.

git diff --no-prefix > patchfile
  Generates a patch file that can be applied using patch:
    patch -p0 < patchfile
  Useful for sharing changes without generating a git commit.

Git Instaweb
------------

git instaweb --httpd=webrick [--start | --stop | --restart]


Environment Variables
---------------------

GIT_AUTHOR_NAME, GIT_COMMITTER_NAME
  Your full name to be recorded in any newly created commits.  Overrides
  user.name in .git/config

GIT_AUTHOR_EMAIL, GIT_COMMITTER_EMAIL
  Your email address to be recorded in any newly created commits.  Overrides
  user.email in .git/config

GIT_DIR
  Location of the repository to use (for out of working directory repositories)

GIT_WORKING_TREE
  Location of the Working Directory - use with GIT_DIR to specifiy the working
  directory root
  or to work without being in the working directory at all.

Wednesday, January 19, 2011

Monday, January 17, 2011

installing gparted(Gnome Partition Editor) and formatting USB on Ubuntu

 launch a terminal and type

sudo apt-get install gparted


(Above step requires Administrator privileges)



open terminal and type gparted or go to  System->Administration->Partition Editor


Right-click on the device in the GParted window.


then click "Unmount." 


Right-click on the device (after it is unmounted) and then hover over "Format to."


Select the desired file system type (RiserFS, linux-swap, Ext 2/3 or FAT16/32).


click "Apply".


Flash drive is formatted. 


To mount the flash drive, unplug it and then plug it back in.





Monday, December 27, 2010

Gitorious Commands


what is gitorious

Gitorious is the name of a web based project host for collaborative opensource projects using the  Git[Fast Version control system]

 Gitorious provides projects with wikis, a web interface for merge requests and code reviews, and activity timelines for projects and developers
http://gitorious.org/about About - Gitorious] 


Git Common Commands
 . Create a repository in the current directory
git init

. Create a local copy of a git repository
git clone [user@domain:/path]

. View the log
git log

. View log with ASCII graph
git log –stat

. View log with diffs
git log –p

. View branches
git branch

. View all branches
git branch –a

. Create a branch
git branch [branch_name]

. Delete branch
git branch -d [branch_name]

. Force delete a branch
git branch -D [branch_name]

. Create a tracking branch
git branch --track [branch_name] [repo/branch]

. Switch to a branch
git checkout [branch_name]

. Create and switch to a branch
git checkout -b [branch_name]

. Add all content to the index
git add .

. Add specific content to the index
git add [file_name]

. Save changes queued to the index
git commit

. Save all uncommitted changes
git commit –a

. Commit and show diff of changes
git commit –v

. Quick commit message
git commit -m "Message"

. Restart branch with code in another branch
git rebase [branch_name]

. View the difference between branches
git diff [branch1] [branch2]

. Combine code from a branch into the current one
git merge [branch_name]

. Undo last commit or merge
git reset --hard ORIG_HEAD

. Save uncommitted changes
git stash "Description"

. Show stash
git stash list

. Merge the stash with working directory
git stash apply

. Delete stashed code
git stash clear

. Send commit objects to another repository
git push

. Send commits to a specific repo and branch
git push [repository] [branch_name]

. Fetch objects and merge with current branch
. (if tracking)
git pull

. Fetch and merge from a specific repo and branch
git pull [repository] [branch_name]

. Get objects from a repository
git fetch [repository]

. Create a git repository based on a Subversion repo
git-svn clone [url]
. Send git commits back to Subversion
git-svn dcommit
. Get changes from Subversion
git-svn rebase


 How do I share my local Git repository at Gitorious.org?
Easiest way is to put something like the following in your .git/config file of the repository you wish to push:
[remote "origin"]
       url = git@gitorious.org:project/repository.git
       fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
       remote = origin
       merge = refs/heads/master
and then git push origin master to push the code to Gitorious.
You can also just run "git push git@gitorious.org:tumbline/mainline.git", or you can setup a remote by doing the following (add --fetch to the add call to get the config from above):

  git remote add origin @gitorious.org:project/repository.git
  # to push the master branch to the origin remote we added above:
  git push origin master
  # after that you can just do:
  git push


Wednesday, December 15, 2010

Scrum Terminology

Stakeholders
Stakeholders have investment in the product being developed, but are not directly related to the development of the product. Stakeholders make up the Customer Team that provides input into the product backlog.

Product Owner
A single person who has the final authority representing the customer's interest in prioritizing and answering questions about stories. This person must be available to the team at any time, but especially during the Sprint Planning Meeting and the Sprint Review.
on-site customer and stakeholder representative are also the terms for product owner

Acceptance Test
An acceptance test is a test that verifies that the story respects the Product Owner acceptance criteria. These acceptance criteria should be included with each story as early as possible in a Sprint, or before taking the story in sprint is ideal. Using acceptance criteria is essential to confirm a team-wide understanding of each story. For teams who have automated testing setup, it is recommended to automate the acceptance test cases so that the status of the story can be verified anytime in the future by simply running its acceptance test.

Agile Modeling (AM)
Agile Modeling is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices. At a more detailed level AM is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner.

Burn-down Charts
Burn-down Charts show work remaining over time (work remaining is the Y axis and time is the X axis).Burn-down can be charted for the story points remaining in a release (see Release Burn-down) or hours remaining in a sprint (see Sprint Burn-down). Displaying burn-down charts in the team area provides high visibility of progress to the team and its stakeholders."

Continuous Integration [CITA]
A fully automated build and test process that allows a team to build and test their software many times a day on a shared code stream.

Daily Scrum
A short daily meeting where each team members stands and answers the three questions:
1. What have I done for the sprint since the last Scrum meeting?
2. What will I do for the sprint before the next Scrum meeting?
3. What impediments are preventing me from performing work for the sprint as efficiently as possible?
All side discussions should be tabled until after the meeting.
Anyone can attend the daily scrum meeting, but the meeting should be focused on the work of the sprint team.

Epic [A Large Story]
A Story that is too large or complex to be estimated. Before scheduling for a sprint, such large stories should be broken down into smaller sub stories, some of which may also have to be broken down further. The hierarchical relationships among the sub stories that result from repeated breakdowns is valuable because it provides product context for each sub story and allows progress on the entire epic to be tracked.

Impediment
Anything that prevents a team member or the team as a whole from performing work as efficiently as possible is an impediment. The Scrum Master is typically responsible for clearing impediments.

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Operational Backlog
The Operational Backlog, or Parking Lot, is contains the work required in the product that may not have direct customer value and would not be written or represented by the customer. Examples of items in the Operational Backlog are code re-factoring or other technical debt, environmental or infrastructure setup, ongoing maintenance activities, etc. When pulling work for a sprint, balance the work in the Product Backlog with the work in the Operational Backlog.

Product Backlog
The Product Backlog is the as yet unfulfilled customer requirements, expressed as a prioritized list of stories. Although there are multiple sources of inputs to the Product Backlog, it is the sole responsibility of the Product Owner to prioritize the Product Backlog.

Pair Programming
When two team members work on a programming task together. The driver role implements the code while the navigator role identifies potential issues, enforces standards, and anticipates next steps. The team members should alternate roles frequently. Pair programming has been shown to increase quality, and thereby eventually pay for itself in future productivity. Pair programming also reduces the impact of losing a developer, because the people who paired with him/her have acquired much of his/her knowledge. Pair programming is also a valuable technique for bringing a new developer up to speed more quickly.
Potentially Shippable Product Increment
Software with sufficient quality and utility to be potentially shippable. Each sprint should deliver a potentially shippable product increment. This has two consequences
1. Quality – Untested software is not potentially shippable, so the software produced in each sprint must be fully tested.
2. Utility – Unusable software is not potentially shippable. Implementing horizontal slices of stories will lead to sprint deliveries with functionality that cannot yet be used because the slices could not be delivered for every architectural component in the same sprint. On the other hand, implementing vertical slices will make the functionality delivered by every story in every sprint potentially usable, at least for some user scenarios.

Re-factoring
Systematic transformations that change the structure of code without changing its execution behavior. It is recommended that the code being re factored is well covered by automated Unit Tests - the higher your unit test coverage, the more likely that you will discover when a re factoring inadvertently changes the behavior of an object. Re-factoring is useful for retrofitting design patterns into code when the implementation of new stories would tend to violate Once And Only Once or other design principles.

Release
The transition of a potentially shippable product increment from the development team into routine use by end customers. Releases typically happen when one or more Sprints has resulted in the product having enough value to outweigh the cost to deploy it. Releases can also be used as milestones in the development of a product - these are generally call internal releases.

Release Backlog
The Release Backlog is a subset of the Product Backlog assigned to a specific release for a specific time period. It can be represented as a line in the Product Backlog, or as a separate backlog artifact.

Release Burn-down Chart
The Release Burn-down Chart presents the progress of a release by showing how many story points of work has been done and how many are left to do in the release at the beginning of each Sprint. Note that the total number of story points in a release is not necessarily constant over the lifetime of the release.

Scrum Master
The Scrum Master is a facilitator for the team. Rather than manage the team, the Scrum Master works to assist the team in the following ways:
• Help the Product Owner drive development in order to maximize ROI.
• Facilitate team creativity and empowerment.
• Remove impediments.
• Drive improvements to the process, engineering practices and tools.
• Keep information about the team's progress up to date and visible to all parties.

Scrum of Scrums
A Scrum of Scrums is a team of compose of one or more Team Members of regular Scrum teams. The usual purpose of a Scrum of Scrums is to identify, track, and resolve dependency issues across the represented teams.

Spike
When a story cannot be accurately estimated due to a lack of knowledge (rather than sheer size like an epic), a common approach is to define a story for attaining the knowledge required to provide a good estimate. Such a story is a spike.

Sprint
An iteration of work during which a potentially shippable product increment is implemented. Currently, the recommended practice is 2-weeks.

Sprint Backlog
The set of Stories from the Product Backlog that the team has committed to complete during the Sprint.

Sprint Burn-down Chart
A Sprint Burn-down Chart depicts the total task hours remaining per day. This shows you where the team stands regarding completing the Sprint Backlog. The X-axis represents days in the Sprint, while the Y-axis is estimate hours of effort remaining.

Sprint Planning Meeting
The Sprint Planning Meeting is where the team negotiates with the Product Owner what they will commit to doing in the next Sprint.
The team generally proceeds as follows
1. Determine how many work hours each member will be available during the Sprint.
2. Select stories from the Product Backlog in the order determined by the Product Owner,
3. Break each story into tasks, and
4. Estimate how many hours it will take to complete each task,
5. Repeat steps 2 through 4 until the cumulative number of task hours gets as close to the total available work hours as the team is comfortable committing to.
Breaking the stories into tasks often requires asking the Product Owner clarifying questions. Sometimes, the team can suggest changes in which stories are selected for a sprint to the Product Owner which will make implementation easier."

Sprint Retrospective
The Sprint Retrospective is held at the end of every Sprint after the Sprint Review. The Team Members and Scrum Master meet to discuss what went well and what to improve in the next Sprint.

Sprint Review
The Sprint Review is where the Team Members demonstrate the software that they produced during the Sprint to the Product Owner and Stakeholders. Feedback is welcome, but since the meeting is usually constrained to an hour or less, detailed discussions should be tabled until after the meeting. Note that software completed days before the Sprint Review can and should be demonstrated to the Product Owner and interested Stakeholders earlier in order to be able to negotiate acceptance criteria.

Sprint Task
A Sprint Task (or Task) is a standalone unit of work needed to complete a storie, generally estimated to take between 1 and 18 hours. Team Members select their own tasks. They update the estimated number of hours remaining on each of their tasks on a daily basis. The Sprint Burndown Chart displays the sum of all the updated estimated hours each day.

Stakeholder
A Stakeholder is a person or another team who has an interest in some or all of the Stories that a team is implementing, but is not the Product Owner.

Story
A Story is a customer requirement expressed in the form: "As a , I want so that ." A story should be small enough to estimate its size, comfortably implement in a Sprint and have a single priority.

Story Points
Relative estimate of size of a Story. A recommended practice is to use Fibonacci Numbers or powers of 2 to avoid trying to estimate too finely.

Team Member
Anyone working on any Sprint Tasks. Typically includes developers, testers, documentors. Technical Debt Technical Debt is the difference between doing something the "right-way" versus getting it released quickly. This must be minimized. Minimal technical debt is the single most important factor in delivering a maintainable system. Keeping technical debt to a minimum and re-factoring (below) creates a system that is easier to change and is responsive to customer needs. Technical Debt may be prioritized in the Operational Backlog.

Test Coverage
The percentage of the code which is executed by at least one automated unit test. Usually measured as the percentages of lines of code.
Test Driven Development (TDD)
A programming technique where you:
1. Write a unit test for a class,
2. Make sure the unit test fails,
3. Write the most straight forward, principled code to make that unit test pass,
4. Repeat step 1 through 3 above until the suite of unit tests form a satisfactory specification of the class.

Unit Test
An automated test that verifies a single responsibility of a single unit of code.

Velocity
Velocity is a history-based estimate of how many Story Points a team can complete in one Sprint.
velocity is usually estimated by averaging the number of Story Points the team completed over the last several sprints. Once the velocity for a team stabilizes, the velocity can be used to forecast release and product completion dates, assuming that both the team composition and the number of story points in the releases also remain stable.

The Classic Story of the Pig and Chicken
www.implementingscrum.com -- Cartoon -- September 11, 2006 - English Translation of the Chicken and Pig Story in Scrum.
Here
Pig roles are considered core team members. Performers. People who “do” work
The roles of both Product Owner and the Scrum-Master are considered to be pigs in the team instead of chicken.
A Chicken is someone who has something to gain by the Pigs performing, but in the end, really do not contribute day to day to “getting things done.” Their “eggs” are a renewable resource.

Wednesday, November 10, 2010

SCP&SSH to the Qemu runtime

MADDE stands for Maemo Application Development and Debugging Environment and offers the following features:


Command-line cross-compiling
Multi-platform support (Linux (32-bit/64-bit), Windows, Mac OS X)
Configurable for different targets & toolchains
Client for the device to simplify the development process


Mad is frontend to madde execution environment. 
Usage: mad [-t TARGET] COMMAND [args]
 COMMAND may be one of the internals listed below
 or system command (such as 'make')


  remote     command set to handle runtime
  info       print madde configuration in xml format
  query      query variables
  list       list components in cross-compilation environment
  set        set default target
  pscreate   create project skeleton


you can scp to the Qemu runtime using the following commands
The ssh port for Qemu is 6666.


"scp -P 6666 filename developer@localhost:/home/developer/ "
 (or) you can do 
"mad remote send  "filename"  "for copying files into Qemu
"mad remote remove "filename" " for deleting files from Qemu
"mad remote install" will install DEBIAN_PACKAGE on runtime
"mad remote uninstall" will uninstall DEBIAN_PACKAGE on runtime   


"ssh -p 6666 developer@localhost"  for logging into Qemu


Here notice the difference, 
for ssh use "-p" (lowercase)for scp use "-P"(highercase)


"mad remote poweron" , "mad remote poweroff "
will turn qemu on and off 


"mad remote shell" opens a login shell on Qemu runtime
"mad ping shell"  checks if Qemu runtime is up and connectable


"mad info"
Prints madde configuration to stdout. The output is in xml format based on schema documented in madinfo.xsd.


"mad list"  will list the components i.e all the targets and runtimes in cross-compilation environment
"mad set"  will set default target.

Wednesday, November 3, 2010

Accounts & SSO


Accounts & SSO(Single Sign On) Framework

The Concept of  “unified account model

The Accounts & SSO (Single Sign On) project provides a framework to implement a unified account management system with secure authentication functionality. The account and SSO subsystems are orthogonal, in a sense that they can be used independently of each other. 
Both come with C and C++
Through C (glib/GObject based) and C++ (Qt based) APIs for client applications.
Accounts(How Meego will handle account settings)
Firefox, Thunderbird, Empathy/Pidgin, F-Spot Picasa export plugin: different applications asking for the same data, your Google account settings. The Accounts framework introduced in MeeGo aims at simplifying this situation, allowing application writers to rely on a unified solution for storing/managing accounts settings.
A centralized accounts UI is used to create accounts and edit their settings, while applications are just left with the task of enumerating existing accounts and using them.
SSO(Single Sign On)
A system for centrally storing authentication credentials and handling authentication on behalf of applications as requested by applications. This is a not only a centralized secure password storage; it’s also a framework of authentication plugins which help applications to login to remote servers while preserving user credentials from being exposed to the application.
Overview of "Accounts framework"
The accounts subsystem provides a storage solution for user accounts. Applications which need to store and access user settings for the service they provide over a user account will use the Accounts API. All applications acting on user accounts (such as instant messaging, e-mail, calendar and social networking applications) can benefit of the unified account model provided by this framework.

Design of the possible UI for Unified Account Model

This framework makes it possible to have only one account UI for creating and editing all user accounts; instead of configuring part of the user’s Google (for instance) account in Thunderbird (for e-mail), Empathy or Pidgin (for IM), F-Spot (for photo/video sharing), etc., we'd like to offer the user the possibility to have all of an account’s settings in a single place, divided by sections specific to every service type.
So, we'd have one section with all the settings that are global for the account: username, password (although for password storing we'd recommend using the SSO framework, and just store the ID of the credentials in the accounts DB), display name, maybe avatar, and a switch to enable/disable the account.
Then, every service provided by the account would add its own settings (if any); for sure there should be a switch to toggle the service on/off, plus any settings that makes sense for the service. For instance, the image sharing section could contain a setting for the maximum image resolution to be used when uploading.
These service-specific sections could be implemented via dynamically loadable plugins, or constructed at run time from XML descriptions.
This account UI could be in the control panel of the device, but it could also offer some IPC so that applications could invoke it for configuring a specific service type; for instance, e-mail application could have a menu item “Edit e-mail accounts” which would bring a view of all the accounts providing the e-mail service, and only the e-mail sections of each account could be shown.

Signond single signon daemon

Single Signon Daemon development files Single Signon Daemon provides password storage and credential retrieving service for applications. Provides authentication plugins for passwords and NokiaAccount.