Top 10 rated games by critics and viewers

1
Fallout 3

2
Rise of the Argonauts

3
Duke Nukem Forever

4
Left For Dead

5
Empire: Total War

6
GTA IV

7
Mount and Blade

8
CoD: World at War

9
Sins of a Solar Empire

10
StarCraft 2 -- Terrans

One of the finest game in my past 5 years

In the case of GTA 4, I think there's a little bit of over hype and expectations being overly high, but when the finished product is as good as what's on offer here, then it's satisfying that GTA 4 certainly delivers a full and rounded package that will please the vast majority

Professional Java IDE

Professional Java IDE

A calculator

import java.awt.BorderLayout;
import java.awt.Container;
import java.awt.GridLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;

import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTextField;

public class Calculator extends JPanel implements ActionListener {
private JTextField display = new JTextField("0");

private String buttonText = "789/456*123-0.=+";

private double result = 0;

private String operator = "=";

private boolean calculating = true;

public Calculator() {
setLayout(new BorderLayout());

display.setEditable(false);
add(display, "North");

JPanel p = new JPanel();
p.setLayout(new GridLayout(4, 4));

for (int i = 0; i < buttonText.length(); i++) {
JButton b = new JButton(buttonText.substring(i, i + 1));
p.add(b);
b.addActionListener(this);

}
add(p, "Center");
}

public void actionPerformed(ActionEvent evt) {
String cmd = evt.getActionCommand();
if ('0' <= cmd.charAt(0) && cmd.charAt(0) <= '9' || cmd.equals(".")) {
if (calculating)
display.setText(cmd);
else
display.setText(display.getText() + cmd);
calculating = false;
} else {
if (calculating) {
if (cmd.equals("-")) {
display.setText(cmd);
calculating = false;
} else
operator = cmd;
} else {
double x = Double.parseDouble(display.getText());
calculate(x);
operator = cmd;
calculating = true;
}
}
}

private void calculate(double n) {
if (operator.equals("+"))
result += n;
else if (operator.equals("-"))
result -= n;
else if (operator.equals("*"))
result *= n;
else if (operator.equals("/"))
result /= n;
else if (operator.equals("="))
result = n;
display.setText("" + result);
}

public static void main(String[] args) {
JFrame frame = new JFrame();
frame.setTitle("Calculator");
frame.setSize(200, 200);
frame.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
});

Container contentPane = frame.getContentPane();
contentPane.add(new Calculator());
frame.show();
}
}

All stuff of undercover

EA's dominating racing series takes a left turn with this uniquely action-oriented entry in the franchise, where players use their driving skills honed in previous NFS games to control their vehicle in dangerous, high speeds encounters. The game features international movie star, Maggie Q, as the lead character in the big-budget live-action sequences that propel the story forward as players get behind the wheel. Undercover takes the franchise back to its roots and re-introduces break-neck cop chases, the world's hottest cars and spectacular highway battles

Reviews of the latest game in market fifa09

With its staggeringly impressive 250 additions and enhancements, Electronic Arts’ launch of FIFA09 has made football gaming fans around the globe sit up and take notice, and it seems that FIFA is now a serious challenge to its main rival, Pro Evolution Soccer.

With the use of real life current data, players are now passing and running in the style of their real life counterparts, with superbly realistic collisions taking the game up to a whole new level. John Erikson of gamingheaven.net is particularly impressed by the animations of the players when they are off ball, running into free space, and calling for the ball, and I agree that this does add some stunning realism to the game.

Not only do players now act like the real life footballers, but they also look like them. The close-to-reality feel of the game is enhanced with the host of leagues that are now included, from the English Premier League to the German Bundesliga, which will surely give the game strong appeal to football fanatics worldwide. The audio of the supporters is very effective too, with the fans of different teams doing their particular chants.

The feel of the online play of FIFA09 is refreshingly free from time lag, and compares very well with PES. All this means better ball movement, and better teamwork.

The sheer accuracy of the FIFA09 has led to rave reviews, and if you are in the market for a football game, it is now a pretty tough call to decide between FIFA and PES. Paul Vale, of the UK newspaper The Daily Star, is one critic that feels that his allegiance has now changed, describing FIFA09 as “one of the most complete sports simulations ever created”, citing the game’s smoothness.

With the launch of FIFA09, FIFA has thrown down the gauntlet to PES

Web Hosting

Introduction to Web Hosting

Who are Web Hosts?

Web hosts are companies that provide space on a server for hosting a website. They own large space on the server, which they share it to their customer's providing Internet connectivity, typically in a data center.

Scope of Web Hosting
The most basic is webpage and small-scale file hosting service, where files can be uploaded via File Transfer Protocol (FTP) or a Web interface. The files are usually delivered to the Web . Many Internet service providers (ISPs) offer this service for free to their subscribers and also obtain such hosting cheaply. Web page hosting is generally sufficient only for personal homepages. Complex website uses more comprehensive package to provides database support and forum's etc. These facilities allow the customers to write or install scripts for applications like forums and content management. For e-commerce, SSL is also required. The host also provides a Web interface control panel ( e.g. cPanel, Hosting Controller, Plesk) for managing the Web server and installing scripts as well as other services like e-mail.



Hosting Reliability and Uptime
Hosting Reliablity and Uptime is very important. The Uptime refers to the percentage of time the host is accessible via the internet. Many hosting providers state that they provide 99.9% uptime. If the server goes down the website will not be accessible through internet. There may be server restarts or maintenance in any web hosting environment which affects the Uptime.
Types of hosting

Free web hosting service
This is free hosting mostly advertisement-supported web hosting. It is extremely limited when compared to paid hosting.

Shared web hosting service
In shared web hosting Web site is placed on the same server as many other sites. It may range from a few to hundreds or thousands wbsites. All domains share a common server resources, such as RAM and the CPU and IP.

Reseller web hosting
Reseller web hosting allows clients to become web hosts themselves. Resellers are those who take affiliate with as a provider and serve as web host.

Virtual Dedicated Server
Here a server is sliced into virtual servers. Each user feels like they're on their own dedicated server, but they're actually sharing a server with many other users.

Dedicated hosting service
In dedicated web hosting, the user gets his or her own Web server and gains full control over it. The user gets the root or administrator access according to Linux or Windows hosting.

Colocation web hosting service
It is similar to the dedicated web hosting service, but the user owns the server. The hosting company provides physical space for the server and takes care of the server.

Clustered hosting
Clustred hosting uses multiple servers hosting the same content for better resource utilization. This make the website easly accessible and fast.


Specific Web services

File hosting service
Hosting service to hosts files not web pages.

Image hosting service
Hosting service to hosts images only.

Video hosting service
Hosting service to hosts video only.

Blog hosting service
Hosting service to hosts blog


Best 10 Web Hosting Sites

My focus is on providing a simple, easy to follow web site to help users choose the best web hosting plan most suitable for a small site or for a large e-commerce web site.
The web hosting sites, which were rated highest in the industry, are listed below and are rated based on affordability, reliability, uptime and tech support.


Rank Web Host Price Setup Domain Disk Space Data Transfer

1 Visit Fat Cow Hosting Visit Site $4.83 Free Free Unlimited Unlimited

2 Visit Just Host Visit Site $4.95 Free Free Unlimited Unlimited

3 Visit Host Monster Visit Site $4.95 Free Free Unlimited Unlimited

4 Visit Inmotion Visit Site $6.95 Free Free Unlimited Unlimited

5 Visit Blue Host Visit Site $4.95 Free Free Unlimited Unlimited

6 Visit Startlogic Visit Site $4.95 Free Free Unlimited Unlimited

7 Visit Web Hosting Pad Visit Site $4.95 Free Free Unlimited Unlimited

8 Visit Host Gator Visit Site $4.95 Free Free Unlimited Unlimited

9 Visit GoDaddy Visit Site $6.95 Free Free 100 GB 1000 GB

10 Visit Yahoo Hosting Visit Site $11.95 Free Free Unlimited Unlimited

Softwre Testing

XP Testing Without XP

In the rocket-fast late 90s, I struggled with using traditional software process and testing practices on e-commerce applications. Then I read Kent Beck’s Extreme Programming Explained and had an amazing ‘aha’ moment. Ron Jeffries sums it up best:

Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

Applying more discipline to traditional waterfall process had not helped my team. A new kind of discipline based on values such as communication, simplicity and feedback might be the answer! I immediately took an opportunity to join an XP team as a tester, and enjoyed working on XP teams for the next 18 months. Indeed, XP did allow us to produce high-quality e-commerce applications on time and on budget! Our customers were happy! We were happy! We struggled some with how I, as tester, could best contribute to the team, as the XP literature at the time didn’t say much on that subject. With the whole team focused on quality and testing, we came up with some great solutions. I was so excited about XP testing that I co-authored a book on it (Testing Extreme Programming, with Tip House).

How XP Testing is Different

I found that XP testing was different in many ways from ‘traditional’ testing. The biggest difference is that on an XP project, the entire development team takes responsibility for quality. This means the whole team is responsible for all testing tasks, including acceptance test automation. When testers and programmers work together, the approaches to test automation can be pretty creative!

As Ron Jeffries says, XP isn’t about ‘roles’, it’s about a tight integration of skills and behaviors. Testing is an integrated activity on an XP team. The development team needs continual feedback, with the customer expressing their needs in terms of tests, and programmers expressing design and code in terms of tests. On an XP team, the tester will play both the customer and programmer ‘roles’. She’ll focus on acceptance testing and work to transfer her testing and quality assurance skills to the rest of the team.

XP Tester Activities

Here are some activities testers perform on XP teams.
XP Testing Without XP

Values

Earlier in this article I referred to the values by which XP teams develop software. These were defined by Kent Beck in "Extreme Programming Explained":

* Communication
* Simplicity
* Feedback
* Courage

Some people have added their own values to this list – the one I liked best is ‘enjoyment’. Extreme Programming is the only ‘official’ agile method I have actually practiced, but from what I have learned of agile software development in general, you can always turn to these values for guidance.

Communication is usually your first job. Whether you’re new to a position or you just want to try something new, you’re going to have to talk to your coworkers and your customers. Most importantly, you need to listen. As you proceed in your agile journey, remember the XP mantra: "Do the simplest thing that could possibly work". As a tester, feedback is your core function. You’ll need plenty of courage to try agile practices in a less-than-agile environment.

Let’s explore a typical project life cycle and see how XP practices can help you with testing, whether or not your development team is taking advantage of them.

Project Planning

Most projects begin with some kind of requirements gathering. The business experts may write business requirements. This is often followed by the development team producing functional specifications and/or technical specifications. If you’re working on a project which is producing documents like this, try to get in on the planning meetings. I know, the last thing you need in your life is more meetings. Requirements gathering meetings can be a great opportunity to put your agile skills to work. You’ll get a head start in understanding the project. By alternately looking at the requirements from the point of view of the end users, business experts and programmers, you can ask questions that flush out hidden assumptions.

Testing the Documentation

Whether or not you attend the meetings, you can add value to the project by ‘testing’ the documentation. This isn’t an XP concept, but it is linked to flushing out hidden assumptions during XP planning games. One way to test documents is to read through the document, writing a list of assertions. For example, maybe you’re reading requirements for an order entry system and have come up with these assertions:

* "The system will capture the customer service agent’s name".
* "The new system will be 50% faster than the old system".
* "The billing address will be required."
* "The zip code will automatically populate the city name".

Go over your assertions with the document’s author and clarify any ambiguous or contradictory assertions. Will the system capture the agent’s name by means of the agent logging into the system? What exactly in the new system will be 50% faster – the response time on each page? The time for placing an order? Do we have a baseline for the old system? If not, how do we quantify this requirement so we know it’s met? What about cases where multiple cities share the same zip code? Are there any optional fields in the address (such as the second address line)? Clearing up these issues now will save time for the programmers later, just as it does during an XP planning game.

If you’ve got a big project where the team sees a problem with finishing on time, see if there is a way you can suggest an XP approach to the planning. If the requirements can be grouped into story-like chunks, estimated by the programmers, and prioritized by the stakeholders, the team can take an iterative approach which will help ensure that some percentage of the necessary features are 100% ready by the deadline, even if less critical features are not yet implemented. If you’re new to agile processes or new to this team, it might not be the right time to take such a bold step, but keep it in mind.

Acceptance Tests

Write the acceptance tests (meaning any tests needed beyond unit and integration tests: system, functional, end-to-end, performance, security, whatever) during the planning phases of the project, rather than after development is complete. More importantly, if you’re trying an agile approach, write executable acceptance tests.

Executable acceptance tests serve two purposes. First of all, they’re a mechanism to involve your ‘customer’ or business expert in defining the tests which will verify that the level of quality and functionality he has specified is met. Secondly, they are a part of your automated acceptance test framework. If you can, avoid having to re-work your acceptance test cases into input to test automation tools.

There are quite a few test tool frameworks which allow this. The concept of data-driven testing isn’t new to XP, and there are plenty of tools which let you define tests in an Excel spreadsheet and then use these as input to your automated tests. XP-style test frameworks abound, as well. Here are a couple of sample JUnit tests:

assertTrue( login("bob","bobspassword"))

assertFalse( login("bob",""))

The first test proves that logging in with a valid userid and password works correctly. The second proves that logging in without a valid password fails. If you have fairly savvy business users, you can train them to read this syntax. If not, it’s not hard for your programmers to write a tool to suck data out of an Excel test case and input it to JUnit.

But wait a minute, you aren’t on an XP team where your programmers are totally on board to help you with acceptance testing. That might rule out Fit (http://fit.c2.com) and FitNesse (http://www.fitnesse.org) as well. Fit allows you to define acceptance tests as HTML tables, which are input to fixtures written in Java, Ruby or some other language that executes the tests. FitNesse goes one better by letting you define the Fit tests as a Wiki page, a sort of modifiable HTML page that’s even easier to handle than HTML. It will also let you define tests in an Excel spreadsheet and paste them onto the Wiki page. Here’s a sample FIT test:
fit.ActionFixture
Start Page
Enter Location http://www.searchme.com
Enter Userid bob
Enter Password bobspassword
Check Title Welcome to SearchMe



If you really can’t get any programmer support to write the simple fixtures that drive these ‘behind the GUI’ tests, check out Canoo WebTest http://webtest.canoo.com/webtest/manual/WebTestHome.html., This allows you to define test cases in XML format. Again, users might not be totally comfortable with XML format, so you might have to do the spreadsheet-to-test tool conversion.

It doesn’t matter what tool you’re going to use. Defining acceptance test cases up front helps your programmers write the correct code. It gives you a huge jump on your testing too.

A word about test plans. Nobody ever reads them, so try not to write them. They’re cumbersome to write and impossible to maintain. Just write test cases. If your organization requires you to deliver a test plan, try to include information that will be useful to you, such as a release plan, and refer to the test cases as much as possible.

Technical Design

Depending on your technical skills, technical design meetings may be painful for you. Try to attend them anyway, if you have the opportunity. If you can even ask one question or make one comment that leads to a more testable design, you’re way ahead of the game.

XP has the wonderful benefit of making everyone on the development team conscious of testability. If you have to automate and perform acceptance tests, and it’s hard to do because your GUI is thick or hooked up to the back end in a way that you can’t test much behind the GUI, your next application is bound to be designed to be more testable. Unfortunately, your traditional development project won’t give you this golden opportunity. You can still raise these issues yourself (tactfully, of course) at design meetings. You can also continue to help facilitate communication between the business stakeholders and the programmers. You understand the application pretty well by now, and you probably are more familiar with the technical issues than the folks on the business side. Remember that communication value!


* Negotiate quality with the customer (it’s not YOUR standard of quality, it’s what the customer desires and is willing to pay for!)
* Clarify stories, flush out hidden assumptions
* Enable accurate estimates for both programming and testing tasks
* Make sure the acceptance tests verify the quality specified by the customer
* Help the team automate tests
* Help the team produce testable code
* Form an integral part of the continuous feedback loop that keeps the team on track.

The Nature of XP Testing

The biggest difference between XP projects and most ‘traditional’ software development projects is the concept of test-driven development. With XP, every chunk of code is covered by unit tests, which must all pass all the time. The absence of unit-level and regression bugs means that testers actually get to focus on their job: making sure the code does what the customer wanted. The acceptance tests define the level of quality the customer has specified (and paid for!)

Testers who are new to XP should keep in mind the XP values: communication, simplicity, feedback and courage. Courage may be the most important. As a tester, the idea of writing, automating and executing tests in speedy two or three week iterations, without the benefit of traditional requirements documents, can be daunting.

Testers need courage to let the customers make mistakes and learn from them. They need courage to determine the minimum testing that will prove the successful completion of a story. They need courage to ask their teammates to pair for test automation. They need courage to remind the team that we are all responsible for quality and testing. To bolster this courage, testers on XP teams should remind themselves that an XP tester is never alone – your team is always there to help you!

XP Testing Without an XP Team

After my rewarding, if challenging, experience as a tester on XP teams, the bad economic times caught up with me and I had to take a job back on the "dark side". Oh, my new company was great and they were interested in XP, but they were a tiny shop with a huge job to do and it felt to me like barely controlled chaos. My initial attempts to apply XP practices, such as having daily XP-style stand-ups with my test team, were disasters. I just had to hunker down, hire people that I thought would be able and willing to try agile test practices, and wait for my opportunity.

Things eventually slowed down enough for my team to have time to spike test automation solutions. Many of our applications are written in Tcl. Tcl is a powerful scripting language which can lend itself to test automation, so we taught ourselves Tcl. We needed a way to load bulk data for volume testing, and one of the programmers helped out with a Tcl script; we took over maintenance for it and started expanding its functionality. Some of our test automation could be handled with fairly simple shell scripts. Other automation requirements demanded more robust tools. As we started down our own path of exploring test automation, the programmers started writing automated unit tests.

I learned the hard way that being an advocate for XP or any kind of agile development doesn’t introduce change. Instead, you and your team need to identify what hurts and look at what XP or agile approaches could help heal that pain. By adopting XP-style planning and writing acceptance testing up front.

Let’s look at testing practices might help you, no matter what style of software development process you are using.
XP Testing Without XP
Executing Tests

Hopefully, you had the opportunity to write executable tests. If so, when code is delivered to you for testing, you’ve got a major jump on the test automation.

You’re not on an XP team, but maybe there are still ways you can benefit from the advantages of ‘pairing’. Collaborate with a fellow tester to spike some test automation solutions. Engage a programmer in brainstorming automation solutions.

The refactoring practice, changing code for the sake of maintainability or efficiency, is important for test automators. Take a little time every day to make little changes to your automated test scripts that will help you maintain them and run them effectively in the long term. You never really get the chance for that big modification, so take tiny steps as you go.

Start Early

Can the developers give you little bits and pieces to test? If you were able to convince them to take an XP-style approach to planning, this part is easy. They’ll develop testable chunks in short iterations and you can race along. If not, see what you can get delivered to you early. Maybe a programmer has a solution in mind but isn’t sure if it will scale well. Help by doing a performance test.

Involve the business experts as much as possible in testing. Keep simplicity in mind: What’s the simplest way to execute these tests? I hate to have to say it, but automation isn’t always the answer. You may have a one-time test, or you may need intelligent exploratory testing by a subject matter expert. Just remember to keep it as simple as possible! In most software projects, no matter what the methodology, you only have time to test the minimum.

Let Worry Be Your Guide

Risk assessments will help you and your stakeholders from worrying. Take a deep breath and determine what the minimum amount of testing will prove to the customer that the system behaves as specified. Lots of people have a negative view of the word ‘minimum’, but if it weren’t ‘good enough’, it wouldn’t be the minimum. Have courage: in most software projects, if you pull off the minimum testing, you’re golden.

XP builds risk assessment into the system with the planning game. The programmers always estimate all the stories and state their potential velocity, and the business experts or customers choose the ones most important to them that will fit into each iteration. With a more traditional project, look to a traditional risk assessment to help you. Identify risk areas, assessing the probability and impact of each. Work to mitigate the top one or two risks, then tackle the next one or two. Here’s a sample risk assessment:
Item Impact Probability Risk
Search produces no results 4 3 12
System capacity exceeded 5 2 10
Data out of date 4 4 16

Numbers like these often get management’s attention when nothing else will.

Retrospectives

Retrospectives are so important, some gurus such as Martin Fowler consider them to be one of the XP practices. Quality assurance is all about learning from history. Retrospectives let your team continually improve how you do your jobs.

Identifying Areas of Pain

There are different approaches to retrospectives (I much prefer this positive term to the oft-used ‘post-mortem’). Generally, your team looks at what went well, what didn’t go so well, what the team should start doing, what the team should keep doing, and what the team should stop doing. It’s sometimes hard to find time for retrospective meetings, but they’re a giant opportunity for the agile tester. I’ve found they are an ideal place to demonstrate how XP or other agile practices helped testing on the project. The goal of retrospectives is to identify areas of pain and form an action plan to mitigate the top two or three. This is a great opportunity to look to agile practices for solutions.

In my case, over the course of many months, our test team built up credibility by doing a super job of manual testing. Then, we had a chance to show what value we could add with test automation. We did our own internal retrospectives, and demonstrated improvement by focusing on our problem areas. I also took every opportunity to expose the technical management and the programmers to agile techniques, by encouraging attendance at XP Denver meetings, distributing links and magazine articles, and taking advantage of an XP/agile consultant who offered a couple hours of his time to demonstrate test-driven development.

As a result, the leaders of the development team are curious about what agile practices might help them. Retrospectives are an ideal time to talk about these. Are requirements documents always inadequate, or take too long to produce? Writing acceptance tests up front, if you haven’t been able to do this up to now, is the ideal solution! This isn’t an article on how to introduce agile practices, but as a tester who benefits from XP testing practices, you can help your team improve quality by seeing what else it can borrow from the XP and agile world.

Celebrating Success

My favorite aspect of XP is how it celebrates success. When programmers or testers complete a task, they ring a bell or go play a round of Foosball (maybe nobody plays Foosball anymore in this economy!) I like to bring treats such as brownies to celebrate a release or just making it through a hard week. We’re often too busy going on to the next project(s) to notice, but it’s a nice lift for our team to go out to lunch or a little happy hour after a retrospective meeting to toast our accomplishments. Like all creatures, we do better with positive reinforcement than with negative punishment.

Perhaps the most important aspect of XP, which should be applied across all software development processes, is the one-team approach. Testers aren’t a separate, after-the-fact entity. They’re an integral part of the development team. As my buddy Mike Clark says, there is no "QA" in "team". Do whatever you can to help your whole team work towards delivering high-quality software on time.

Testing provides continuous feedback to help your whole team do their best work. Take baby steps if you have to – any progress is hugely rewarding! Above all, remember to follow Kent Beck’s advice, and embrace change!