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/

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/

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

Multiple war in an ear file (EJB and Other Java EE Technologies forum at JavaRanch)

Multiple war in an ear file (EJB and Other Java EE Technologies forum at JavaRanch):
"Why Would You Put Multiple War Files in a J2EE EAR?

Why would an ear file have more than one web module?

An ear file can contain any number of web and ejb modules. This begs the question, “should I deploy all of my web content in a common war file, or should I separate my web content into separate war files?”

Well, application partitioning is an inexact science, but there are some rules we can follow.

Take for instance a scenario where your enterprise application provides web access for both your human resources (hr) and accounting departments. Should this web application be separated into an accounting.war and hr.war file, or should everything be packaged together into a single hraccounting.war file?

When it comes to application packaging, there are no ‘right answers.’ There are only ‘wrong answers.’ The best we can do is try not to get the wrong answer.

Here are a few important points to consider when developing and subsequently deploying an application.

The Session Problem

Sessions, a mechanism for storing transient information about the client interacting with your website, are not shared across war files. If session information needs to be shared amongst hr and accounting modules, splitting your Servlets and JSPs across multiple war files is going be a problem.

The Common ServletContext

Servlets and JSPs can share information between each other by using a special scope named the ServletContext. If you are placing information in this ServletContext, such as the IP address of the accounting database, you probably don’t want you’re hr application to be able to access it.

The ServletContext is not shared between war files. If you do not want one set of Servlets to see another set of Servlets ServletContext, you’re going to have to separate the two applications into separate war files.

Forwarding to a JSPs

A common design pattern is to have a Servlet handle a request, and have it forward to a JSP for display. However, Servlets can only forward to JSPs packaged inside of a common war. You can use a special method called ‘redirect’ to send a user to a JSP in a different web module, but the redirection becomes a brand new request, and information about the initial request and response is lost.

Managabitly

Manageability of your applications must always be a prime concern. The cost of any application is not how much money is require to develop it, or the hardware required to run it, but is instead the cost of managing that application over the long-term.

If the two applications you are packaging are large, separating them into two separate war files would make them much easier to manage. Modularity helps facilitate maintainability"

How to Run a War File? : A Sunny Commune - Cheng's Blog

How to Run a War File?

This question has been asked many times, and I figured it's worth repeating. The Simple answer:

1. Start the web server;

2. Deploy the war file to the web server;

3. Visit JSP pages or servlets in the browser.

In more details:

1. It is not possible to run a war file outside of a container.

A war file contains JSP pages, Servlet classes, static html files, and other java classes and resources. It has to live inside of a container provided by application/web servers, just as applets are managed by a browser. For example, you can download and install Glassfish, Tomcat, or Jboss.

Start the web/application server. Start the browser and visit http://localhost:8080 to confirm the server is running. Your server may use a different web server port. If you are not sure, try 8080 first.

2. Copy the war file (say, helloworld.war) to the autodeploy directory of the application/web server.

It's so called auto-deploy or hot-deploy. If you can't find such a directory in your server, look again. If it's really not there, stop using this server immediately. Althoug auto-deploy is not required by J2EE standards, virtually all servers support this. Why choose an inferior one when you have so many choices? See how easy it is to deploy a war file to Glassfish.

3. In the browser visit http://localhost:8080/helloworld/

This is the root of your helloworld web application. You may see errors in the browser if helloworld.war doesn't have welcome page (usually index.html, index.jsp, index.htm), and the server has disabled directory listing.

For individual JSP pages, you can access http://localhost:8080/helloworld/say.jsp, assuming say.jsp is packaged directly inside the war file (that is, not under any subdirectory in the war file).

For individual Servlets, you can visit http://localhost:8080/helloworld/hello, assuming you have configured such a servlet-mapping for the url-pattern (/hello) and this servlet. Usually you have to map the Servlet to a url-pattern in web.xml, and when you visit this url, the Servlet will be invoked."

URI, URL and URN

URI, URL and URN
A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name.

Computer scientists may classify a URI as a locator (URL), or a name (URN), or both. A Uniform Resource Name (URN) functions like a person's name, while a Uniform Resource Locator (URL) resembles that person's street-address. In other words: the URN defines an item's identity, while the URL provides a method for finding it.

eclipser-blog: Automatic generation of BIRT reports

eclipser-blog: Automatic generation of BIRT reports: "Automatic generation of BIRT reports
Automatic generation of BIRT reports is a common task for every company that has reports that should be presented to the customers.

Those reports should be delivered regularly. If howto that I am going to present is available somewhere than I am sorry, but I was not able to find it out and I had to merge knowledgle scattered in a several wiki pages.

But in the ends solution seems to be very easy:

1. Download BIRT runtime and unzip it somewhere. You should have now birt-runtime-2_2_1_1 folder.
2. Set up environment variable to point to that folder either in OS or inside birt-runtime-2_2_1_1\ReportEngine\genReport.bat(sh for linux).
3. Put your jdbc jar file in folder birt-runtime-2_2_1_1\ReportEngine\plugins\org.eclipse.birt.report.data.oda.jdbc_2.2.1.r22x_v20070919\drivers.
4. Execute genReport.bat script to see usage. For all those good computer scientists (and good computer scientist is a lazy one) I present sample command:
genReport.bat -f PDF -o outputfile.pdf -F report_design.rptdesign"