Sorupottajava's Blog

July 13, 2009

Wanna buy Zagg invisibleshield for Iphone 3Gs and Others Phone very chep Price

Filed under: iphone — sorupottajava @ 12:59 am

Pls visit this website for more Info

http://www.invisibleshieldsg.blogspot.com/

Contact Person:
*Meet ups
* Fast Delivery
* Installation Service
* Friendly Coordinator

Will – 93884912

July 8, 2009

We can’t do this ever because we have brains!!!!!! !!!

Filed under: General — sorupottajava @ 10:39 pm

It was a sports stadium.

Eight Children were standing on the track to participate in the running event.
* Ready! * Steady! * Bang !!!

With the sound of Toy pistol , all eight girls started running . Hardly have they covered ten to fifteen steps, one of the smaller girl was slipped and fell down, due to bruises and pain she started crying .

When other seven girls heard this sound , stopped running, stood for a while and turned back , they all ran back to the place where the girl fell down.

One among them bent, picked and kissed the girl gently and enquired. Now pain must have reduced’ .

All seven girls lifted the fallen girl , pacified her, two of them held the girl firmly and they all seven joined hands together and walked together and reached the winning post.

Officials were shocked . Clapping of thousands of spectators filled the stadium.

Many eyes were filled with tears and perhaps it had reached the GOD even!

YES. This happened in Hyderabad [ INDIA ], recently!

The sport was conducted by National Institute of Mental Health .

All these special girls had come to participate in this event and they are spastic children .
Yes, they were mentally retarded Challenged.

What did they teach this world?

Teamwork?

Humanity?

Equality among all?Huh?

Successful people help others who are slow in learning so that they are not left far behind. This is really a great message… spread it!

We can’t do this ever because we have brains!!!!!! !!!

July 2, 2009

Singapore to get iPhone 3GS next week-July 10

Filed under: iphone — sorupottajava @ 11:54 pm

Singapore to get iPhone 3GS next week-July 10

Singapore operator SingTel has announced that it will launch the iPhone 3GS next Friday, July 10. That’s the extent of its announcement so far, with other details like price to follow early next week

Steve Jobs officially back at Apple

Filed under: General — sorupottajava @ 1:19 am

Steve Jobs officially back at Apple

Steve Jobs, co-founder and chief executive of Apple, officially returned to work this week after almost six months sick leave.

“He’s at Apple a few days a week and working from home the rest of the week,” an Apple spokesman said. “We are very glad to have him back.”

Mr Jobs, who received a liver transplant following a hormonal imbalance, has been off work since January. Apple, which has been criticised for being secretive about the nature of Mr Jobs’ illness and treatment, refused to disclose any further details.

In January Mr Jobs, who previously survived pancreatic cancer, said that he was seeking treatment for the illness again, but said it would be “relatively simple and straightforward”.

About a week later Mr Jobs told staff that the problem was more complex than he initially thought and he would have to take time off work.

Mr Jobs has been given an “excellent prognosis” by doctors after receiving a liver transplant in the US.

The US Securities and Exchange Commission (SEC) is investigating Apple’s handling of Mr Jobs’s illness

July 1, 2009

IBM Rational Functional tester-RFT

Filed under: Technology — sorupottajava @ 10:50 pm

Introduction

Rational Functional Tester is an object-oriented automated testing tool that tests Windows, .Net, Java, HTML, Siebel and SAP applications, and lets you record reliable and robust scripts that can be played back to validate new builds of a test application.

The object-oriented recording technology in Functional Tester lets you generate scripts quickly by recording applications against the application-under-test. The recorded events are captured in the form of java code which is played back during testing.

Advantages in using RFT

Accuracy in functional testing.
Efficiency in the Regression testing.
Less time in setting up tests
Quicker execution.
Mapping of System Test Cases and Requirement Traceability Matrix.
Test accuracy is more and chances of human error are less.
Very less human effort is required (Creation of test code).

To record a script:

You can first set any recording options you may need. Click Window > Preferences to access the Functional Tester options.

Click the Record a Functional Test Script button or click File > New > Functional Test Script Using Recorder. The Record a Functional Test Script dialog box opens.

In the Record a Functional Test Script dialog box, select the project you want the script to be part of. Type a name for the script. (Note: Script names cannot contain space or any of the following characters: $ \ / : & * ? ” | # % -)

Click the Display Help icon on the Recording toolbar in the monitor for information on the toolbar buttons and how the monitor works.
On the Recording toolbar, click the Start Application button to start your test application.
Perform any actions in the application.

If you want to record a verification point, locate the object in your application you want to test, and click anywhere in the application window or dialog box. Next, click the Insert Verification Point or Action Command button.

If you want to insert any features into the script, such as a call script command, log entry, timer, script delay command, or comment, click the Insert Script Support Commands button.

Close your application, if you want closing the application to be part of the script.

When you are finished recording, click the Stop Recording button.

Recording in an existing script

With Functional Tester, you can start recording at the cursor location in the current script, which enables you to start applications, insert verification points, and add script support functions.

To start recording in an existing Functional Tester script:
Place the cursor in the script where you want to begin recording.
Start recording in either of these ways:
In the Functional Tester menu, click Script > Insert Recording.
In the Functional Tester toolbar, click the Insert Recording into Active Functional Test Script button .
Functional Tester opens the Recording Monitor and starts recording.
To start your test application, on the Recording toolbar click the Start Application button .
Perform any actions in the application.
To record a verification point, locate the object in your application you want to test and click the Insert Verification Point or Action Command button.
To insert any features, such as a call script command, log entry, timer, script delay command, or comment into the script, click the Insert Script Support Commands button.
Close your application, if you want closing the application to be part of the script.
When you are finished recording, click the Stop Recording button.

To run a script from Functional Tester:

Run the script in any of the following ways:
In the Functional Tester Projects view, click a script and click Run Functional Tester Script in the Functional Tester toolbar.
In the Functional Tester Projects view, right-click a script and click Run.
In the Functional Tester Projects view, click a script and then click Script > Run.
The Script Launch Wizard appears.
Optionally, if you want to prevent the Script Launch Wizard from displaying when you run a test script, do the following:
In Functional Tester, Java Scripting, click Windows >Preferences or in Functional Tester, click Tools > Options.
Click Functional Tester > Playback > Logging.
On the Logging options page, click the Don’t show script launch wizard check box.
On the Select Log page, keep the default log name or select a log name.
Optionally, you can enter run arguments or set a “Datapool” iteration count:
Click Next to display the Specify Playback Options page.
In the Run arguments field, enter or select command-line arguments to pass to the script if required.
In the “Datapool” Iteration Count field, select a number or Iterate Until Done to specify how many times a test script runs when you run the test script.
Click Finish to begin running a test script.

Recording and playing back double byte characters on Chinese systems

The following information pertains to record and playback of DBCS on Chinese systems.

Simplified Chinese:

The only Input Method Editor (IME) that is supported for recording and playing back scripts using Functional Tester on Simplified Chinese systems is the MS-PinYin IME. During script playback this IME will automatically be activated for the input of Chinese characters, provided the IME is present on your system. Use of other IMEs for recording is not supported and may yield unexpected results.

Traditional Chinese:

Two IMEs are supported for the recording and playback of Traditional Chinese characters: the New Phonetic and New ChangJie IMEs. During script playback the New Phonetic IME will automatically be activated for input of Chinese characters and if that is not present, the New ChangJie IME will be used. Use of other IMEs for recording is not supported and may yield unexpected results.

Writing messages to the log

A log is a file that contains the record of events that occur while a Functional Tester script is playing back. There are several different methods you can use to write messages to the log.

Functional Tester supports several types of log files, or no logging at all. You select the type of log file (TestManager Log, HTML Log, or Text Log) through the user interface. Each logged event has an associated message. In a TestManager log, you can see this message by right-clicking the event in the log and selecting Properties.
Functional Tester automatically logs the following events:
Script start
Script end
Calls to the callScript method
Calls to the startApplicaction method
Timer start
Timer end
Exceptions
Verification points

Data-driving tests overview

When you data-drive a test, the script uses variables for key application input fields and programs instead of literal values so that you can use external data to drive the application you are testing.
Data-driven testing uses data from an external file, a datapool, as input to a test. A datapool is a collection of related data records which supplies data values to the variables in a test script during test script playback.
Because data is separated from the test script, you can:
Modify test data without affecting the test script
Add new test cases by modifying the data, not the test script
Share the test data with many test scripts

Regular expressions

You can replace a recognition property with a regular expression or a numeric range to allow for a pattern-based recognition. The pattern allows for more flexibility in the object recognition. You can convert properties to regular expressions and numeric ranges from within the Verification Point Editor or the object map.

Using API in functional test scripts

All the objects of the application under test, used during recording are mapped in the test object map. How to pick up an object at runtime?
Reading various properties of an object at runtime.
Using the Test Object Inspector.
Creating your own log file.
Calling an another script from within a script.
Calling a script with arguments.
Calling a script with datapool options [e.g. callScript(“script_name", DEFAULT_ARGS, DP_ALL);]
Reading data from a Html table.
Iterating through the datapool with test script.
Using Regular expressions to avoid recognition error.( This is needed as the tool captures the full URL of any object while recording. In case playing back the script has to be done on a different environment the script starts failing.)

Testing an Defect Analysis

Filed under: Technology — sorupottajava @ 7:40 am

Testing Fundamentals

Process

Testing is a process used to help identify the correctness, completeness and quality of developed computer software.

Testing helps in Verifying and Validating if the Software is working as it is intended to be working. This involves using Static and Dynamic methodologies to Test the application.

Objectives

Testing is a process of executing a program with the intent of finding an error.
A good test case is one that has a high probability of finding an as yet undiscovered error.
A successful test is one that uncovers an as yet undiscovered error

Test Strategy

Common Synonyms for Test Strategy are Test
Approach and Test Architecture

A good Test Strategy is

Specific
Practical
Justified

The Test Strategy provides the overall guidelines from which all future testing decisions are made. A well-crafted Testing Approach allows the rest of the testing process to be defined more effectively.

Fundamentals of Test Strategy

Creating Test Strategy
Defining Test Strategy

Below is the example of a poorly stated (and probably poorly conceived) Test Strategy:

“We will use black box testing, cause-effect graphing, unit testing and white box testing to test this product against its specification.”

Creating Test Strategy

Inputs for this process:

A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data.

A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules.

Testing methodology. This is based on known standards.

Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents.

Requirements that the system can not provide, e.g. system limitations.

Outputs for this process:

An approved and signed off test strategy document, test plan, including test cases.

Defining Test Strategy

A high level Test Strategy should include
Business Risks
Testing Milestone
Testing Method
Testing Environment

A detailed Test Strategy should cover the following:

Project Scope
Test Objective
Testing Method
Testing Process and Procedures
Test Compliance

Project Scope:

Restate the business objective of the application and define the scope of the testing. The statement should be a list of activities that will be in scope or out of scope. A sample list would include:

* List of software to be tested
* Software configurations to be tested
* Documentation to be validated
* Hardware to be tested

Test Objectives:

The system under test should be measured by its compliance to the requirements and the user acceptance criteria.

Every feature and function must be listed for test inclusion or exclusion, along with a description of the exceptions. The list should be grouped by functional area to add clarity. The following is a basic list of functional areas:

Backup and recovery
Workflow
Interface design
Installation
Procedures (users, operational, installation)
Requirements and design
Messaging
Notifications
Error handling
System exception and third-party application faults

Testing Methods:

The methodology provides the detail necessary to describe the levels and types of testing and should identify types of testing that are needed to validate the system.

Some of the more specific test types include

Static Testing
Dynamic Testing
Black Box Testing
White Box Testing
Unit Testing
Requirement Testing
Regression Testing
Error Handling Testing
Intersystem Testing
Parallel Testing
Stress Testing
Volume Testing
Performance Testing
Manual Testing

Testing Process and Procedures:

The order of test execution and the steps necessary to perform each type of test should be described in sufficient detail to provide clear input into the creation of test plans and test cases.

Procedures should include how test data is created, managed and loaded.

Test cycles should be planned and scheduled based on system availability and deliverable dates from development.

All application and environmental dependencies should be identified along with the procedures necessary to gain access to all the dependent systems.

Test Compliance:

Every level of testing must have a defined set of entry/exit criteria which is used to validate that all prerequisites for a valid test have been met.

All mainstream software testing methodologies provide an extensive list of entry/exit criteria and checklist.

In addition to the standard list, additional items should be added based on specific testing needs. Some common additions are, environmental availability, data availability, validated code which is ready to be tested.

Test Plan

A test plan is a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of what the eventual workflow will be.

In software testing, a test plan gives detailed testing information regarding an upcoming testing effort, including

Scope of testing.
Schedule.
Test Deliverables.
Release Criteria.
Risks and Contingencies

Test Methods

In order to decide on the Test Methods needed for the project/product during Test Strategy Analysis, It is very important to understand various Test Methods and how it works.

Let’s go through some of the Industry Standard Test methods which are being used.

Static Testing

The Verification activities fall into the category of Static Testing. During static testing, you have a checklist to check whether the work you are doing is going as per the set standards of the organization. These standards can be for Coding, Integrating and Deployment. Review’s, Inspection’s and Walkthrough’s are static testing.

Static testing involves review of requirements or specifications. This is done with an eye toward completeness or appropriateness for the task at hand. This is the verification portion of Verification and Validation.

Dynamic Testing

Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. These are the Validation activities.

Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.

In dynamic testing the software must actually be compiled and run; this is in contrast to static testing. Dynamic testing is the validation portion of Verification and Validation.

Black Box Testing

Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need any knowledge of internal design or code etc.

As the name “black box” suggests, no knowledge of internal logic or code structure is required. The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application.

Black box testing is sometimes also called as “Opaque Testing”, “Functional/Behavioral Testing“ and “Closed Box Testing”

Black Box Testing Approach

Testing methods where user is not required

Functional Testing:

In this type of testing, the software is tested for the functional requirements. The tests are written in order to check if the application behaves as expected.

Load Testing:

The application is tested against heavy loads or inputs such as testing of web sites in order to find out at what point the web-site/application fails or at what point its performance degrades.

Ad-hoc Testing:

This type of testing is done without any formal Test Plan or Test Case creation. Ad-hoc testing helps in deciding the scope and duration of the various other testing and it also helps testers in learning the application prior starting with any other testing.

Exploratory Testing:

This testing is similar to the ad-hoc testing and is done in order to learn/explore the application.

Usability Testing:

This testing is also called as ‘Testing for User-Friendliness’. This testing is done if User Interface of the application stands an important consideration and needs to be specific for the specific type of user.

Smoke Testing:

This type of testing is also called sanity testing and is done in order to check if the application is ready for further major testing and is working properly without failing up to least expected level.

Recovery Testing:

Recovery testing is basically done in order to check how fast and better the application can recover against any type of crash or hardware failure etc. Type or extent of recovery is specified in the requirement specifications.

In this type of testing, the software is handed over to the user in order to find out if the software meets the user expectations and works as it is expected to.

Alpha Testing:

In this type of testing, the users are invited at the development center where they use the application and the developers note every particular input or action carried out by the user. Any type of abnormal behavior of the system is noted and rectified by the developers.

Beta Testing:

In this type of testing, the software is distributed as a beta version to the users and users test the application at their sites. As the users explore the software, in case if any exception/defect occurs that is reported to the developers.

Advantages of Black Box Testing

More effective on larger units of code than glass box testing
Tester needs no knowledge of implementation, including specific programming languages
Tester and programmer are independent of each other
Tests are done from a user’s point of view
Will help to expose any ambiguities or inconsistencies in the specifications
Test cases can be designed as soon as the specifications are complete

White Box Testing

White box testing can be performed to validate whether code implementation follows intended design, to validate implemented security functionality, and to uncover exploitable Vulnerabilities

White box testing includes analyzing data flow, control flow, information flow, coding practices, and exception and error handling within the system, to test the intended and unintended software behavior.

White box testing requires knowing what makes software secure or insecure, how to think like an attacker, and how to use different testing tools and techniques.

Techniques

Data Flow Analysis
Code-Based Fault Injection
Abuse Cases

Checkpoints

Data
Component Interfaces
Configuration
Error Handling

White Box Testing – Results to Expect

The types of errors uncovered during white box testing are several and are very context sensitive to the software under test.
Some examples of errors uncovered include

data inputs compromising security
sensitive data being exposed to unauthorized users
improper control flows compromising security
incorrect implementations of security functionality
unintended software behavior that has security implications
design flaws not apparent from the design specification
boundary limitations not apparent at the interface level
White box testing greatly enhances overall test effectiveness and test coverage. It can greatly improve productivity in uncovering bugs that are hard to find with black box testing or other testing methods alone.

Pros and Cons of White Box Testing

Pros
White box testing uncovers programming and implementation errors.
Finding ”unintended” features can be quicker during white box testing.
White box testing is typically very effective in validating design decisions and assumptions from the security context.

Cons
White box testing is time consuming and expensive and requires specialized skills.

Unit Testing
Unit testing is a procedure used to validate that individual units of source code are working properly.

A unit may be an individual program, function, procedure, base/super class, abstract class or derived/child class.
The goal of unit testing is to isolate each part of the program and show that the individual parts are correct.
It simplifies integrations. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

Limitations of Unit Testing

By definition, it only tests the functionality of the units themselves. Therefore, it may not catch integration errors, performance problems, or other system-wide issues.

Unit testing is more effective if it is used in conjunction with other software testing activities.

Requirement Testing

Requirement Testing starts at the beginning of the project, not at the end of the coding.
It apply tests to assure the quality of the requirements. Then the later stages of the project can concentrate on testing for good design and good code.

To pass through the quality gateway and be included in the requirements specification, a requirement must pass a number of tests.

Quality Measurement
Quantifiable Requirement
Non Quantifiable Requirement
Coherency and Consistency
Completeness
Relevance
Requirement or Solution
Stakeholder Value
Traceability
Ordering / Grouping

Advantages of Requirement Testing
The key advantage of this approach is that we minimize expensive rework by minimizing requirements-related defects that could have been discovered, or prevented, early in the project’s life.

Regression Testing

Regression testing is any type of software testing which seeks to uncover regression bugs.

Typically regression bugs occur as an unintended consequence of program changes.

One of the common methods of regression testing is re-running previously run tests and checking whether previously fixed faults have re-emerged.

During development, this kind of re-emergence of faults is common. Sometimes it occurs because a fix gets lost through poor revision control practices or simple human error in revision control.

Strategies and Factors
Some strategies and factors to consider during regression testing include the following:

Test fixed bugs promptly.
Watch for side effects of fixes. The bug itself might be fixed but the fix might create other bugs.
If two or more tests are similar, determine which is less effective and get rid of it.
Identify tests that the program consistently passes and archive them.
Focus on functional issues, not those related to design.
Make changes (small and large) to data and find any resulting corruption.

Error-Handling Testing

Usage
It determines the ability of applications system to process the incorrect transactions properly
Errors encompass all unexpected conditions.

Objective
Determine Application system recognizes all expected error conditions.

How to Use

A group of knowledgeable people is required to anticipate what can go wrong in the application system.
Then logical test error conditions should be created based on this assimilated information.

When to Use

Throughout SDLC

Examples

Create a set of erroneous transactions and enter them into the application system then find out whether the system is able to identify the problems.

Using iterative testing enter transactions and trap errors. Correct them. Then enter transactions with errors, which were not present in the system earlier.

Inter-System Testing

Objective

Determine Proper parameters and data are correctly passed between the applications.
Documentation for involved system is correct and accurate.
Ensure Proper timing and coordination of functions exists between the application system.

How to Use
Operations of multiple systems are tested.
Multiple systems are run from one another to check that they are acceptable and processed properly.

When to Use
When there is change in parameters in application system.
The parameters, which are erroneous then risk associated to such parameters, would decide the extent of testing and type of testing.

Example
Develop test transaction set in one application and passing to another system to verify the processing.

Parallel Testing

Parallel/audit testing is a type of testing where the tester reconciles the output of the new system to the output of the current system, in order to verify the new system operates correctly.

Parallel testing is common in many HRMS applications

When to Use

Parallel testing is not so much about finding problems, but acts as a “dry run” for production.
How to Use
The new system is tested alongside the legacy system it is replacing with all the same variables.
The validation compares the output of the legacy system to the output of the new system and the results should match.
Who to Use
People running a parallel test are the same people that will
be responsible for the system once it is in production.
QA is still involved, but their role is more in the process than in the execution.

Stress Testing

Stress testing deals with the quality of the application in the environment. The idea is to create an environment more demanding of the application than the application would experience under normal work loads. This is the hardest and most complex category of testing to accomplish and it requires a joint effort from all teams.

Objective

The primary objective of the stress testing is to ensure the software doesn’t crash in conditions of
Insufficient computational resources (such as memory or disk space),
Unusually high concurrency, or denial of service attacks.
Example

A web server may be stress tested using scripts, bots, and various denial of service tools to observe the performance of a web site during peak loads.

Volume Testing

Volume testing refers to testing a software application for a certain data volume. This volume can in generic terms be the database size or it could also be the size of an interface file that is the subject of volume testing.

Volume testing comes under non-functional requirements testing and Performance testing.

Volume testing will also be undertaken (normally) as part of the User Acceptance test. Stress testing is closely related, as it seeks to find out how the software will behave beyond its specified limits.

Why to Use

To identify where the behavior of the software deviates from that expected for a specified volume of data.

Who to Use

Developers through to customers and end-users can do it.

How to Use

Volume testing needs two things.
Firstly clear expected outcomes of how the software is to behave for a given level of data.
Secondly, data, and lots of it.

Performance Testing
System performance is generally assessed in terms of response time and throughput rates under differing processing and configuration conditions.
Performance testing is the process of determining the speed or effectiveness of a computer, network, software program or device.
Performance testing can verify that a system meets the specifications claimed by its manufacturer or vendor.

Benefits

Removal of serious functional flaws related to data volume and synchronization issues not identified by functional testing.

Collection of performance metrics for the system under increasing load that enable system administrators to make and validate tuning decisions prior to deployment.

Using realistic data volumes and transaction rates enables identification of processing bottlenecks.

Manual Testing

Manual testing is the oldest and most rigorous type of software testing. Manual testing requires a tester to perform manual test operations on the test software without the help of Test automation.

Q: Can Manual Testing be directly replaced by automated testing?

A: Manual testing can be replaced by test automation. It is possible to record and playback manual steps and write automated test script(s) using Test automation tools. Although, test automation tools will only help execute test scripts written primarily for executing a particular specification and functionality, it lacks the ability of decision-making and recording any unscripted discrepancies during program execution.

Defect Analysis
Defect Analysis is nothing but the data on number of defects in a typical system, percentage of time spent on testing, rate of finding defects, etc.

Three essential components are to be in place in order to do a proper Defect Analysis.

Defect Detection
Defect Reporting
Defect Abstracts

Defect Detection

The typical defect detection process involves

Identifying the defect
Recording the defect details
Recording the defect type
Recording the defect priority
Setting the status for defect
Fixing the defect
Resetting the status of defect

Defect Reporting

Defect reports are among the most important deliverables to come out of test.
Effective defect reports will:
Reduce the number of defects returned from development.
Improve the speed of getting defect fixes.
Improve the credibility of test
Enhance teamwork between test and development
Why do some testers get a much better response from development than others? Part of the answer lies in the defect report.

Here are some key points to make sure the next defect report you write is an effective one.

1. Condense – Say it clearly but briefly
2. Accurate – Is it a defect or could it be user error, misunderstanding, etc.?
3. Neutralize – Just the facts. No zingers. No humor. No emotion.
4. Precise – Explicitly, what is the problem?
5. Isolate – What has been done to isolate the problem?
6. Generalize – What has been done to understand how general the problem is?
7. Re-create – What are the essentials in triggering/re-creating this problem?

Environment, steps, conditions
8. Impact – What is the impact to the customer? What is the impact to test?
Sell the defect.
9. Debug – What does development need to make it easier to debug?
Traces, dumps, logs, immediate access, etc.
10. Evidence – What will prove the existence of the error?

Defect Abstracts
The short one line abstract that gets associated with most defects is a very powerful communication tool. Often times, the abstract is the only portion of the defect that gets read by the decision-makers.

Example 1: The following abstract is true but doesn’t provide nearly as much information as it could.
Abstract 1: Problems found when saving and restoring local data.
Example 2: Perhaps a more descriptive abstract would be.
Abstract 2: Save/Restore of Local data on Quotation fails.

H1N1 FAQ for Singaporeans

Filed under: General — sorupottajava @ 1:37 am

H1N1 FAQ for Singaporeans

What is the A (H1N1) influenza?

It is a respiratory disease of pigs caused by type A strains of the influenza virus. It regularly causes high flu outbreaks in pigs but with low death rates. There are four main sub-types of the virus, but the most recent isolated influenza viruses from pigs have been H1N1 viruses.

How does it spread?

Influenza A (H1N1) viruses do not typically infect humans though they do occur through close proximity or contact with infected pigs or contaminated areas. Cases of human-to-human spread have been documented.

What are the symptoms?

The symptoms are similar to those of regular flu:
- Fever
- Lethargy
- Runny nose
- Cough
- Sore throat
- Lack of appetite
- Vomiting and diarrhoea in some cases.

How common is the A (H1N1) flu infection in humans?

In the past reports of about one human A(H1N1) flu virus infection had been received every one to two years in the United States. From December 2005 till February 2009, 12 cases have been reported.

Has this strain of flu been seen before?

No. Flu mutates constantly, so it is common for new strains to emerge. Pigs can also be infected with both human and avian influenza, and the current circulating A (H1N1) flu strain appears to contain genetic elements from all three.

Can the A (H1N1) flu be treated with antiviral drugs and flu vaccine?

The A (H1N1) flu is resistant to two common drugs – Amantadine and Rimantadine. The A (H1N1) flu viruses are very different from human H1N1 viruses. Therefore, vaccines for human seasonal flu would not provide protection. However, a “seed vaccine” has been specifically tailored to this swine flu and will be manufactured if officials deem it necessary.

Can people catch A (H1N1) flu by eating pork?

No. The A (H1N1) influenza viruses are not transmitted by food. Eating properly handled and cooked pork and pork products is safe. Cooking pork to an internal temperature of 70ºC and above kills the swine flu virus.

How long is someone with the A (H1N1) flu considered contagious?

People with the A (H1N1) influenza virus infection should be considered potentially contagious as long as they are symptomatic; possibly for up to seven days following the onset of the illness. Children, especially younger children, might potentially be contagious for longer periods.

What can I do to protect myself from the A (H1N1) flu?

There is no vaccine available right now to protect against the A (H1N1) flu.

However, you can help prevent the spread of germs that cause respiratory illnesses like influenza by:

- Covering your nose and mouth with a disposable tissue or handkerchief when you cough or sneeze. Throw the tissue in the waste basket after you use it.

- Wash your hands often with soap and water, especially after you cough or sneeze. Alcohol-based hand cleaners are also helpful

- Try to avoid close contact with sick people. – If you get sick with influenza, stay at home and limit contact with others to keep from infecting them.

- Avoid touching your eyes, nose or mouth.

- Consult your nearest healthcare facility if you think you have any of the symptoms.

What precautions are in place in Singapore Hospitals?

Enhanced Screening & Visitation Measures

Enhanced triage and screening measures for fever and flu-like illness for visitors to clinical areas.
Hospitals will enforce visiting hours and limit the number of visitors to 2 visitors per patient at any one time.
Visitors to clinical areas will have their particulars recorded to help facilitate contact tracing.
Hospital Operations and Patient Care

Elective admissions have been reduced to increase hospital capacity.
All patients with flu symptoms AND travel history to affected areas will be isolated and managed appropriately.
Inter-hospital movement of patients restricted to emergencies.
Inter-hospital movement of doctors and healthcare workers restricted to essential services.
Enhanced Infection Control Measures

Healthcare workers in high risk areas will use full personal protective equipment (PPE)
Healthcare workers will use the appropriate PPE in other clinical areas.

In Primary Care Clinics:
Patients will be screened for fever and flu-like illness at the clinic reception.
Patients are to declare symptoms, contact and travel history in Patient Declaration Form
Patients with flu-like illness are to wear surgical masks and be separated from other patients while in the clinic
Staff will exercise strict infection control precautions (ie. temperature screening for all staff; triage staff to don full PPE; doctors to don PPE while attending to high risk patients)

In Community Hospitals and Nursing Homes:

Visitors are to fill in a self-declaration form indicating their NRIC, contact numbers and travel history.
Patients with flu-like illness are to wear surgical masks and be separated from other patients.
Staff will exercise strict infection control precautions (ie. temperature screening for all staff; triage staff to don full PPE; doctors to don PPE while attending to high risk patients)

At our Borders:

Temperature screening will be carried out for all incoming travellers at air, sea and land checkpoints
Passengers with fever symptoms will undergo a more thorough onsite medical assessment by the medical teams.

Where can I get more information?

For more information, go to the Health Ministry (www.moh.gov.my) or call the Ministry’s hotline at (03) 8881-0200/300.

Useful Links:
Ministry of Foreign Affairs: http://www.moh.gov.sg/.
World Health Organization: www.who.int
WHO A (H1N1) flu page: http://www.who.int/csr/disease/swineflu/en/index.html

Top 10 Reasons to buy iPhone 3GS

Filed under: iphone — sorupottajava @ 1:16 am

Top 10 Reasons to buy iPhone 3GS

The iPhone 3G S is the fastest iPhone, yet. I hate stuffing multiple gadgets into my jeans. But it is uncool for a tech guy living in Silicon Valley to carry around a manbag. I’ve tried and it feels a bit awkward. So far my iPhone has been the best all-in-one pocketable device but with a few areas that needed improvement. The weakest feature of the iPhone 3G is the camera–it sucks. The new iPhone 3G S has a much improved camera and a whole lot more. If you want just one device in your pocket (or purse) that does it all and does it well the iPhone 3G S, in my opinion, is simply the best pocketable do-everything gadget available. Yes, better than the Palm Pre. Here are ten reasons why you should seriously consider getting the iPhone 3GS, in no particular order:

3.2 Megapixel Camera: Autofocus. You can also manually focus. It has macro that get you real close. Bokeh? Yup.

Video: Flip? Good bye. The iPhone 3GS can take video with a 640 x 480 resolution at 30fps. That’s good enough for most applications. You can trim the video and then tap to upload to YouTube. Nice.

Voice Control: You like your RAZR because it has voice control? It took a long time (too long actually) but the iPhone 3GS has it too. Just press the button until you hear a tone. “Call Mom.” And you’ve got Mom on the line.

GPS: The full-blown kind. With a compass to make it more accurate. Tom Tom announced its Tom Tom for iPhone. No need to have a separate GPS device.

Voice Memos: A student and need to tape lectures? Or just want to record your own? This feature save a lot of hassle.

7.2mbps HSDPA: Data transmission speeds are twice as fast. That’s always nice in a Web 2.0 world. Let’s hope AT&T delivers.

Longer Battery Life: 3 more hours of data on WiFi to 9. 6 more hours of audio to 30. 3 more hours of video to 10. talk time is the same at 5 hours.

Water & Oil Resistant: Wow, this is a surprise. You don’t have to worry about water or oil spills on the iPhone 3GS.

Nike+: Built-in support. Great for those that love to walk, jog and run.

Faster Processor: Everything is faster up to twice as fast. The fact that you have to close an app to get another running takes much less time. You almost don’t miss background processes with fast task switching.

Top 10 Firefox 3.5 Features

Filed under: Technology — sorupottajava @ 1:03 am

Top 10 Firefox 3.5 Features

Firefox 3.5 is a pretty substantial update to the popular open-source browser, and it’s just around the corner. See what features, fixes, and clever new tools are worth getting excited about in the next big release.

UPDATE: A previous version of this list had Taskfox, an integrated version of Ubiquity, included as a Firefox 3.5 feature. It’s still in the experimental phase, in fact, as readers pointed out, and we regret the confusion (and false optimism!). This new list includes an additional item, and the rankings have been shifted slightly.

1.Video superpowers with HTML 5

If you’re viewing a page coded in HTML 5 with video in an open-source format like Ogg Vorbis or Theora, Firefox 3.5 treats that video like it’s just part of the page, not a separate little island of Flash content. That means instant commenting on videos. It could also mean offering links from inside a tutorial video that offer more details on what’s being shown—soldering tips on an iPhone repair guide would be keen. In general, it’s just a promising step forward into a seamless melding of video and text on a future web.


2.Geo-location

If you type post office into a maps site, you probably don’t want the headquarters of the U.S. Post Office, or post office listings from two towns over. Integrated geo-location, powered by Google’s Wi-Fi triangulation and simple IP address information, looks to know roughly where you are and help you when you’re looking for something local. You can disable it if you’d like, but, realistically, signing on from any IP address reveals a bit about where you are anyways. If a good number of sites pick it up, geo-location could bring to the browser what a lot of people are already enjoying on their phone.

3.TraceMonkey JavaScript engine

Months ago, Mozilla said its still-in-development JavaScript engine, TraceMonkey, was “20 to 40 times” faster than the SpiderMonkey engine installed in Firefox 3. That hasn’t shown up in our speed tests, which themselves rely on a Mozilla-assembled testing suite, but JavaScript testing suites are often like drag races—they don’t really tell you what a browser runs like in a real daily sense, just pure timings. Even if TraceMonkey is ultimately outpaced by Chrome and/or Safari, its innovations push the whole browser market forward and give us all a bit less load time to complain about.

4.Color profiles that pop

Different cameras, monitors, and capture devices grab and set colors in different ways. On the web, most colors look the same, though, because they’re filtered and optimized for quick viewing in every browser. Firefox 3.5 introduces dynamic color profiles for each picture, meaning that whatever the graphic designer or photographer saw when they were doing their work, you’ll see it on their web page.

5.Private browsing mode

The snarky types (i.e. my editor) can call it “Porn Mode,” but this feature, already in a number of competing browsers, has uses beyond the prurient. Beyond obvious situations, like gift buying and sensitive research, logging onto a friend’s browser for a quick email check or bill pay is made a lot more secure if you can get to the private mode. Likewise, anonymizing some of your searches and cookie collection on your own machine isn’t a bad idea, and a private mode can do that too. You don’t need it all the time, but you might be glad it’s available.

6.Smarter session restore

What good is it to bring back all the tabs you just lost to a crash if the tab that brought everything down comes back too? Firefox’s developers took a cue from the users and turned the session restore feature into more of a crash recovery tool, allowing users to select which tabs should come back. If you don’t know who’s the culprit, here’s a hint: It’s probably the one with Flash on it.

7.Keyword AwesomeBar filters

Firefox 3′s AwesomeBar/address bar offers a speedy list of suggestions to complete whatever you’re typing. That’s great, but that list comes from your page history, bookmarks, and tags, and can be matched by URL or name, leaving some results almost uselessly cluttered. This gets fixed with special character filters in the next Firefox. Restrict a search by typing “life *” for just your bookmarks with the words “life” in them, or just your tagged “lh” items with “lh +”. Anything that really makes getting back to importantly web destinations quickly is a welcome upgrade.

8.Tab tearing

Google Chrome (Update: And Safari, as our readers note) somewhat stole the thunder out from under this feature, but it’s still a nice one: Grab a tab and drag it out a bit to create a new browser window from it. Drag windows into tabs again, and open any tab in a new window from the right-click menu, if clicking and dragging isn’t your style.

9.Forget this site

Tools like Private Browsing Modes and history wipers are good for what they do, but sometimes it would be great to have just one site wiped off your history—either because it’s hogging your quick address bar results, or because you’d rather your coworker be unaware of your workday LOLcat browsing. Firefox 3.5′s history browser offers a convenient “Forget this site” option, erasing your browser’s memory of particular domains. It doesn’t cover subdomains, and your network traffic and Flash memory would still hold some details, but it’s a handy tweak however you cut it.


10. Undo closed window

If you accidentally close a tab you’d meant to keep open, Firefox 3, at least through extensions like Tab Mix Plus, can bring it back. Update: To clarify, Firefox can resurrect closed tabs without Tab Mix Plus (just hit Ctrl+Shift+T, for example); the extension simply adds more fine-grained control. If you accidentally kill a separate window full of tabs, though, you’ve been pretty much out of luck. Firefox 3.5 implements a restore feature for both tabs and windows from the History menu, which would (hopefully) also restore any text you’ve typed into them.

June 29, 2009

IIM Interview Question

Filed under: General — sorupottajava @ 9:56 am

Interviewer said “I shall either ask you ten easy
questions or one really difficult question.
Think well before you make up your mind!” The boy
thought for a while and said, “my choice is one really
difficult question.”
“Well, good luck to you, you have made your own
choice! Now tell me this. “What comes first, Day or Night?”
The boy was jolted into reality as his admission
depends on the correctness of his answer,
but he thought for a while and said,
“It’s the DAY sir!”
“How” the interviewer asked,
“Sorry sir, you promised me that you will not ask me a
SECOND difficult question!”
He was selected for IIM!

Next Page »

Theme: Rubric. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.