Saturday, December 24, 2011

Capacitive vs Resistive Touch Screens

Capacitive or Resistive - Which one is right for you?

Capacitive is best for situations that require high speed response and long lasting reliability. Information Kiosks, Point of Sales Terminals or Equipment Control Rooms. This alternative requires skin contact to operate.

Resistive is designed to allow items other than your finger to activate the touch. Area's that this type is suited to include Industrial locations where the user might be wearing gloves or for a physically challenged person that uses a Head Operated Mouse Alternative device. It also allows touch pens otherwise know as a Stylus to be used.

CAPACITIVE TECHNOLOGY

RESISTIVE TECHNOLOGY


A Resistive touch screen is a type of touch screen that is made of several layers where as a capacitive touch screen is a type of touch screen which consists of an insulator coated with a transparent conductor. Here let me take the opportunity to compare the pros and cons of both resistive touch screen and capacitive touch screen

Resistive Touch Screen

Pros:

The screens are usually inexpensive
It can be easily operated with any pointing devices
They are much more accurate than capacitive touch screens
They are easy to use and are more reliable
Cons:

Multi touch support not available
These are highly sensitive to scratches
Poor visibility in sunlight
Capacitive Touch Screen

Pros:

Multi touch support available
Good visibility even in sunlight
Not affected by dirt and moisture
Glossy looks
Faster and Smoother Response
Cons:

Humidity must be atleast 5% to achieve capacitive effect
Expensive than resistive touch screen
Doesn’t work with pointed objects
So now, as you have some knowledge about the pros and cons of resistive touch screen as well as capacitive touch screen, you can easily judge what is better for you.

Refs:
1. http://www.rycom.com.au/capvsres.htm
2. http://www.techcrates.com/resistive-vs-capacitive-touch-screen/

Thursday, February 3, 2011

Agile Scrum – A brief overview

Scrum is one of the methodologies used for iterative software development within the available set of agile methodologies. SCRUM is not an acronym and it has been derived from the game rugby. Scrum is a project / product development methodology which fits to the current changing paradigm and also gives more importance to project governance.

Unlike the current development team structure, scrum has only 3 roles to play within a team,

  1. Scrum Master – one who maintains the process and works to ensure the realization of goals of the Sprint.
  2. Product Owner – the primary stakeholder of the product. Basically the customer who is responsible for prioritizing the backlog.
  3. Scrum Team – a self organized group who do the analysis, design, implementation and testing.

The other terminologies used by scrum are:-

  • Sprint – a 2 to 4 week cycle where the scrum team works to accomplish a set of tasks. The duration of the sprint can be decided by the team. The output of each sprint must be a working piece of software.
  • Product Backlog – is a high level document of the entire set of requirements for the project / product. This is prepared by the Product Owner and would be the input for arriving with the sprint backlog. Each item in product backlog would be prioritized.
  • Sprint Backlog – is the detailed document of the items that would be performed for the current sprint to accomplish either a set of or a single item in the product backlog. The selected item(s) from the product backlog are broken down into granular tasks which can be accomplished within 8hrs of effort. These tasks would constitute the sprint backlog. This is done by the team.
  • Sprint Burn Down Chart – is a line chart showing the remaining hours available to be burnt for completing the sprint. This chart is owned by the Scrum Master and has to be updated on a daily basis.

The Methodology

The product owner comes up with the story for the scrum. The story meant here is a one liner of the requirement that would be accomplished to meet the specific business need. This requirement is further broken down into detail requirement points called the product backlog.

Now once the product backlog is ready is when the scrum starts. There happens a scrum planning meeting where the product owner meets with the entire scrum team and discusses on the priority of the items in the product backlog. In this meeting it is also decided on the during of the sprint. Once the product backlog is completely created a Sprint Planning Meeting is initialized.

The duration of the Sprint planning meeting is 8 hours. During the first half, the product owner describes the goal of the product and the details of the product backlog to the team. The second half of the meeting, the team selects specific requirements from the product backlog that can be accomplished per sprint based on the priority. The selected requirements are broken down into tasks which are called the sprint backlog. It is to be kept in mind that each sprint is expected a deliver a shippable product / feature.

The Sprint begins and lasts of the agreed duration. There is no change allowed or entertained to be added / modified to the sprint backlog.

Daily scrum meeting happens among the stake holders of the sprint, i.e., the product owner, scrum master and the scrum team. The during of the daily scrum meeting (also called as the stand up meeting) should not be more than 15 minutes. There is no excuse for any of the stake holders to skip the meeting. This is MANDATORY. The scrum master is required to initiate this meeting and also update the burn down chart based on the outcome of the meeting. The three questions that needs to be answered by each team member are:-

1. What did I do since yesterday?

2. What have I planned to do today?

3. Is there any issue that is obstructing my task?

Each sprint team member is expected to answer this question.

At the end of each sprint a Sprint Review Meeting happens where each discusses their accomplishments during the sprint and also a demo of the product/feature is planned to the product owner and the other business stakeholders.

· A scrum cycle can have multiple sprints. But the duration of each sprint should remain the same.

· There is nothing called schedule variance or effort variance for a sprint. It is only the Sprint Burndown chart.

Ref: http://ganeshrajmohan.blogspot.com/

Thursday, January 20, 2011

easy_install tip - setting up own repository

One of the really cool features of easy_install is that you can install packages from thePython Cheese Shop, which is a web-based repository of Python packages. For example, in order to install IPython using easy_install and the Cheese Shop, you would simply type `easy_install ipython`. It’s all fine and dandy for open source projects to put their source code out there for the world to look at, but what if you work on (gasp) closed source code? Do you have to miss out on all this easy_install remote repository goodness? Not at all.

First, you have to setup a web server that will serve up your packages. I am using lighttpd on my laptop, which misses the point in practice since i could just as easily install the eggs locally rather than by pointing at http://localhost, but it works for example purposes. I have lighttp serving up a directory that contains a repository directory called “repo”. So,http://localhost/repo will give a directory listing of all the packages I can serve up.

Second, you need to build your packages and put them in a directory that your webserver can serve up, the “repo” directory in my case. I have 2 packages, foo v0.1 and bar v0.1, that I made into eggs. The filenames are bar-0.1-py2.5.egg and foo-0.1-py2.5.egg. In this example, foo has a dependency on bar. Since easy_install handles dependencies so well, I would expect an easy_install of foo to resolve the bar dependency and install them both. Step three will prove this assumption either correct or incorrect.

Third, and finally, you simply tell easy_install to look at your local repository for packages. Here is the command and output from installing from my local repository:

root@lanik:/usr/lib/python2.5/site-packages# easy_install -f http://localhost/repo foo Searching for foo

Reading http://localhost/repo Best match: foo 0.1

Downloading http://localhost/repo/foo-0.1-py2.5.egg

Processing foo-0.1-py2.5.egg

Moving foo-0.1-py2.5.egg to /usr/lib/python2.5/site-packages

Adding foo 0.1 to easy-install.pth file

Installed /usr/lib/python2.5/site-packages/foo-0.1-py2.5.egg

Processing dependencies for foo Searching for bar==0.1 Best match: bar 0.1

Downloading http://localhost/repo/bar-0.1-py2.5.egg

Processing bar-0.1-py2.5.egg Moving bar-0.1-py2.5.egg to /usr/lib/python2.5/site-packages

Adding bar 0.1 to easy-install.pth file

Installed /usr/lib/python2.5/site-packages/bar-0.1-py2.5.egg

Finished processing dependencies for foo


The “-f” flag tells easy_install where else it can look for packages. That’s it!

Ref: http://www.oreillynet.com/onlamp/blog/2007/11/easy_install_tip_setting_up_yo.html