Monthly Archives: May 2012

8 Useful Websites for Testing Code Snippets

As a web developer, having a place to quickly test code can be extremely handy. For this post, we’ve gathered some very useful websites that allow you to do just that. And along with testing a debugging, many of these sties let you share and backup, which is a huge benefit when collaborating with other developers.

jsfiddle

JsFiddle is a playground for web developers, a tool which may be used in many ways. One can use it as an online editor for snippets build from HTML, CSS and JavaScript. The code can then be shared with others, embedded on a blog, etc.

8 Useful Websites for Testing Code Snippets

codepad

codepad is an online compiler/interpreter, and a simple collaboration tool.

8 Useful Websites for Testing Code Snippets

Google Code Playground

8 Useful Websites for Testing Code Snippets

ideone

Ideone is something more than a pastebin; it’s an online compiler and debugging tool which allows
to compile and run code online in more than 40 programming languages.

8 Useful Websites for Testing Code Snippets

PractiCode

8 Useful Websites for Testing Code Snippets

jsdo.it

Our site is engagement-driven. We offer both, vivid environment for developers to showcase their trendy works on JavaScript and HTML5, as well as community to share their codes and learn from each other. That’s why we call our communtiy ‘a coding avenue’.

8 Useful Websites for Testing Code Snippets

cssdesk

8 Useful Websites for Testing Code Snippets

JS Bin

8 Useful Websites for Testing Code Snippets

Did you like this? Share it:

Software Testing and Software Quality Assurance are NOT the same

Many people and organizations usually get confused whether Software Testing and Software Quality Assurance are same or different concepts in the testing domain it’s important to know that these two fields are closely related, but they are different concepts.

Software Quality Assurance (QA):

Software Quality Assurance is a set of activities designed, planned in a systematic way to evaluate quality of the process which is used to produce a quality product.

Why Software Quality Assurance?

This is done in order to ensure that the development or maintenance process is adequate to ensure a system will meet its objectives. Also, making sure that procedures and agreed-upon standards are followed properly.

Goal:

To provide a pledge that the product is meeting all the quality expectations of the customer.

When a product is developed Quality Assurance deals with how tester can prevent errors from occurring. A major responsibility of Software QA Engineer is to build and implement methods and also the standards, to improvise the development methods. There are certain set of activities associated with QA like measuring the quality of the process which can be used to the product development, a process improvement and flaw prevention. It also consists of auditing and reporting procedures. 

Software Testing:

Software Testing is a planned process of executing a system in order to find defects and i.e., used to identify the completeness, correctness, security and quality of a software. It also includes the system or application’s operation under the controlled conditions and evaluating the results.

Why Software Testing?

This is done in order to provide a demonstration that the software is doing what it is intended to do as well as the software is not doing what it is not intended to do.

Goal:

To find or locate the defects and making sure that they get fixed and also to ensure that the functional requirements and metrics are met.

These are some of the major differences between the two concepts and sometimes there could be an overlap of responsibilities between software tester and quality assurance engineer. Based on the need, sometimes software tester might have to do certain quality assurance related works and some QA-ers perform testing of a product.

Source:

http://qa.siliconindia.com/news/Software-Testing-and-Software-Quality-Assurance-are-NOT-the-same-nid-116670.html

Did you like this? Share it:

Top 7 dilemmas facing today’s developers

Your boss wants it yesterday, but it better be good when judged by the standards of tomorrow. Your customers want every feature they can imagine, but don’t you dare confuse them by giving them all the buttons they want. Your fellow programmers want your code documented, but they just respond "tl;dr" to anything you write.

As technology evolves, so too do the dilemmas developers confront. Every choice, from platform to data store to how much control to give your users, is fraught with questions. And thanks to the cloud, the rise of mobile tech, and the hastening cutting edge, it seems as if the programming world faces a new choice — and dilemma — at an increasing pace.

Packaging your problems and giving them a name can help you manage them and maybe even find solutions, or so they say. Toward that end, here is a list of the most significant dilemmas facing programmers today. It is by no means complete — then again, what project related to application development ever is?

Got another dilemma? Add it to the comments.

Developer dilemma No. 1: When to say when on feature requests
If we had a dollar for every feature our customers wanted, we’d still be broke because that would require building an accounting system that matched each dollar with each feature. These would then need to be cross-linked and prioritized because our customers would also demand a sophisticated bug/feature management system for their dollar. Then the database of wanted features would need to be backed up to some cloud and translated into every language.

This is the dilemma: Everyone wants feature-rich code, but no one wants to pay the cost of managing all of it. Anyone who’s tried to build something as simple as a four-button remote control app knows how many zillions of designer years it takes to create something that simple. Making something elegant requires sweat that soaks through everything.

Consumers, the marketing department, sales reps in the field — it doesn’t matter who makes the request. Giving them the button they want may actually be the worst thing you can do for them. Suddenly there might be too many buttons and too much confusion about what each button does. The ideal is to make something easy enough to understand intuitively, but alas, creating something intuitive for those who are prone to ask too much of their software is all but impossible.

You’ve tried quoting the old "rule of 10,000" to your boss. This states that anything worth doing requires at least 10,000 hours of work to become competent. That just brought a laugh because that app store customer or coworker in accounting is going to spend more time drafting a nasty review or email than trying to understand the features you’ve collected in your app, even if they’re features the users said they want.

Sadly, the ideal can often be to convince your customer they don’t actually want the feature they’ve requested. After all, Twitter continues to offer a feature-poor system that imposes a 140-character limit, laughable in the era of terabyte disk drives. Yet it sails on, serene in the knowledge that all those attempts at providing new features are examples of trying too hard.

If only this solution to the dilemma of unending feature requests was available to us all.

Developer dilemma No. 2: How much documentation is enough?
I was sitting in a meeting with an aggressive project manager who really wanted to stick it to a competing project manager. This manager promised that the code coming out of his team would have "documentation," he said, before pausing like James Bond introducing himself and saying, "Extensive documentation."

The only thing worse than no documentation is a bookshelf filled with binders stuffed with extensive documentation. Some project managers love to measure their progress by the pound, and they see more words as better words. Anyone who’s slogged through "Moby Dick" in high school English knows the feeling.

We want to know information about the code, but no one has an acronym for Too Little Information. Everyone on Facebook knows the initials TMI.

There is no easy answer for the programmer. Ideally, the code is clean enough and self-documenting enough to avoid the need for long paragraphs explaining just what the code is doing. Code-based documentation doesn’t get left behind like text documentation when someone rewrites the code but doesn’t get around to the text.

There is hope that an even smarter collection of debuggers and code-analyzing compilers will be able to do a better job understanding our code. The latest versions of the virtual machines keep copious records of which routines are executed. While most of the emphasis is on performance, this kind of meta data can be more useful than real documentation by identifying when data is changed.

But it will be years before we can drink the Kool-Aid and dream about artificial intelligence understanding our code. For now, we’re stuck with the problem of how to create just enough documentation to keep everyone happy without shortchanging the feature set.

Developer dilemma No. 3: To the cloud, or not to the cloud?
It’s so much easier to call up a new server from the cloud than to fill out a requisition form and ask the server maintenance folks to buy a new one. You push a button and you have your own server.

Alas, this approach can be costly. The servers may be only a few pennies for an hour, but they add up when everyone wants their own cluster for each project. The next thing you know, there are hundreds of servers in the cloud, most of them created by people who left for other jobs several years ago. It’s cheaper to keep paying the bills than to figure out what they do.

To make matters worse, the servers aren’t your own. Some companies are famous for writing terms of service that are very one-sided, claiming, for instance, the ability to shut down your machines for "no reason." That seems to be changing as cloud vendors recognize that such overreaching drives away the customers with the most money. But no one knows what happens if you encounter problems in the cloud. Sometimes it helps to control the paycheck and retirement funds of the person responsible for the server staying up.

The more you outsource, the more you lose control and spin your wheels trying to recapture it. The less you outsource to the cloud, the more you spin your wheels keeping everything running.

You’re damned if you do, damned if you don’t.

Developer dilemma No. 4: Maintain old code, or bring in the new?
One of the deepest challenges in running an enterprise stack of software is deciding when to stick with the old and when to switch to the new. Every line of code in the stack is getting older by the minute, and while you might not think so, the reality is that software manages to find a way to go bad, little by little.

The old code really does stop working. Partners start offering slightly different services and sometimes stop supporting features altogether. Twitter, for instance, locked out people who used its old API when the company started insisting on using the OAuth API. These stories are repeated again and again.

The trouble is that replacing the old with the new can be expensive. Programmers of the new are usually forced to maintain compatibility with old code, a challenge that often requires writing two programs: one filled with the old bugs and one filled with new ones that haven’t been discovered yet.

To make matters worse, the new code is often held to higher standards. I’ve seen new fancy AJAX masterpieces that run much slower than old green-screen mainframe code all because they have fancy buttons and tons of images that push the video card. The look is slicker, but the feel is slower.

There is no easy answer to this dilemma. The old code still works. We like it. It’s just that it’s not compatible with the new version of the operating system or a new multicore chip. The new code costs money. We can usually fix a number of glaring problems with the old code, but who knows what new problems might appear?

Developer dilemma No. 5: SQL vs. NoSQL
There is one big challenge for the database administrators of the world: stick with tried-and-true SQL or switch to trendy NoSQL where everything is bigger and ready for endless streams of data.

The new NoSQL databases sound attractive. They can be much faster than older databases, and they often force users to avoid many of the problems that caused so much trouble in the first place. JOINs, for instance, can slow down a database if the schema gets too complicated. NoSQL tosses them out the window along with many parts of the schema. You can store any key-value pair you like, and the NoSQL database will come up with the answer.

But if you look closely, the NoSQL databases aren’t always so wonderful. First, they often don’t offer guarantees that the data will be recorded. It probably will be OK, but not if something happens to a hard drive or a computer in the cluster. Some of the newer NoSQL options from companies like Oracle allow you to ask for a transaction confirmation, but your code will need to twiddle its thumbs and wait just like the code that uses a SQL database.

There are deeper issues. Many of the speed problems came about because programmers didn’t think about the subtle effects of SQL. The way you structure your tables and queries can make a big difference in performance. Linking together multiple tables and forcing the database to JOIN the information slows things down.

But if you try to accomplish the same thing with a NoSQL database, you’ll often be writing data in and out of multiple places and hoping it will all stay consistent. You get to do all of the work of JOINing disparate sections of the database, and that probably means you’ll pay the cost in speed. If you are aware of this and are able to think through the trade-offs when designing code, you’ll be OK. But if you’re not, you may find that your code is even slower and buggier. The database won’t enforce the transactions, and you’ll need to do it yourself.

This dilemma has a simple answer: Applications that need better consistency should rely upon the transaction guarantees of older SQL machinery. Applications that need speed and can handle a few scrambled records can choose the newer NoSQL datastores. But if you need speed and consistency, you might as well start pulling out your hair.

Developer dilemma No. 6: Go native, or target the mobile Web?
In the beginning, Apple wasn’t going to let anyone develop apps for the iPhone. If you wanted to target the iPhone, you needed to write HTML5 for Safari. It was an elegant answer with a well-understood sandbox for developers to use.

Alas, no one was happy with the locked-down platform. People wanted to write native code, a pathway certainly essential for fast games and useful for slower applications that let you browse information. Apple relented, and now we have the App Store.

The trouble is that the code for the iPhone won’t work on other smartphones and vice versa. Any company that wants to target multiple manufacturers must rewrite their application — a long, slow process prone to incompatibilities. Plus, it’s double or triple the work.

HTML5 is a nice option. If you can write your application as a Web page, there’s a good chance your users can pop them open in the smartphone’s browser. There are already a number of great frameworks that make this a bit smoother.

The trouble is that it’s not necessarily in the interests of the smartphone manufacturers to embrace this interoperability. If the phones are going to stand out, they’ll need to offer something special, and that usually means something different. That won’t happen if everyone runs the same HTML5 apps.

There are plenty of rumors that the performance of HTML5 on the smartphones is not as good as it could be. Some suggest that the HTML5 engines are a bit slower. There is no easy way to test this or even understand the motivation behind any sloggy code. In many cases, the HTML5 is slower because it’s interpreted instead of compiled directly for the hardware.

The answer to this dilemma is guessing how important performance will be to your mobile app. If it’s essential, then custom-compiled native code is the answer. If it isn’t, you have some leeway to explore HTML5.

Developer dilemma No. 7: How much control should users really get?
Software users are like teenagers, it’s said: They want all of the freedom they can get, but they expect you, the good parent, to rescue them from harm. They want all of the advantages of the walled garden, but insist on being able to slip through some backdoor whenever it suits their fancy.

The issue of control is a difficult one for programmers. The ethos of open source permeates the culture, with its insistence that everyone should be able to recompile the stack and tweak anything to fit. Alas, the average user can’t make use of this power no matter how much they want it. Even most programmers have to spend hours finding the right versions of the libraries and the latest edition of the compiler. Control means nothing if you don’t have the time to use it.

Some companies are pushing the ideal of open databases. We’re all supposed to be able to download the information about us. Alas, most of us can’t do anything with the information, and the only ones with the time and energy to use these open doors are other companies.

There is no answer to this dilemma. If you give your users control, they’ll complain about the UI and the features they didn’t get. If you don’t, they keep nagging you for it.

Source:

http://www.javaworld.com/javaworld/jw-05-2012/120521-top-dilemmas-for-developers.html?page=1

Did you like this? Share it:

Use Memcached for Java enterprise performance, Part 2: Database-driven web apps

However you slice it traditional caching requires performance trade-offs that some enterprise applications cannot afford. Find out for yourself why Memcached is a go-to solution for Java developers whose applications need serious scale. After first setting up spymemcached as your open source Java client for Memcached, you’ll use it in two powerful application scenarios: first configuring Memcached as second-level cache for Hibernate (via hibernate-memcached), and then using it to cache the HTML generated for each web page.

We concluded the first half of this tutorial with a look at using Telnet and the Memcached protocol to store and retrieve cache entries in a Memcached server. Accessing Memcached via Telnet is especially useful for debugging, but if you want to use Memcached in a Java enterprise application you’ll need to use a Memcached Java client.

We’ll use spymemcached, a very popular Memcached Java client, for the introductory purposes of this tutorial. Listing 1 shows spymemcached’s main class, MemcachedClient.

Listing 1. MemcachedClient
public static void main(String[] args) throws Exception{
    if(args.length < 2){
        System.out.println("Please specify command line options");
        return;
    }
    MemcachedClient memcachedClient = new MemcachedClient(AddrUtil.getAddresses("127.0.0.1:11211"));
    if(commandName.equals("get")){
        String keyName= args[1];
        System.out.println("Key Name " +keyName);
        System.out.println("Value of key " +memcachedClient.get(keyName));
    }else if(commandName.equals("set")){
        String keyName =args[1];
        String value=args[2];
        System.out.println("Key Name " +keyName + " value=" + value);
        Future<Boolean> result= memcachedClient.set(keyName, 0, value);
        System.out.println("Result of set " + result.get());
    }else if(commandName.equals("add")){
        String keyName =args[1];
        String value=args[2];
        System.out.println("Key Name " +keyName + " value=" + value);
        Future<Boolean> result= memcachedClient.add(keyName, 0, value);
        System.out.println("Result of add " + result.get());
    }else if(commandName.equals("replace")){
        String keyName =args[1];
        String value=args[2];
        System.out.println("Key Name " +keyName + " value=" + value);
        Future<Boolean> result= memcachedClient.replace(keyName, 0, value);
        System.out.println("Result of replace " + result.get());
    }else if(commandName.equals("delete")){
        String keyName =args[1];
        System.out.println("Key Name " +keyName );
        Future<Boolean> result= memcachedClient.delete(keyName);
        System.out.println("Result of delete " + result.get());
    }else{
        System.out.println("Command not found");
    }
    memcachedClient.shutdown();

}

In Listing 1, we first create a MemcachedClient object with hostname:portname as its argument. Once we have the object we can start calling its methods to set and get cache entries. Note that MemcachedClient has equivalent methods for every method supported by the Memcached protocol:

  • MemcachedClient.set() is used to store a Java object into the Memcached server. In Listing 1, we stored an instance of a Contact object with the string contactId-1. The second parameter of this set method is time-in-seconds.
  • MemcachedClient.get() is used to get the value of the key from a Memcached server. In Listing 1 the value of the key is an object of Contact.java, so the client will first retrieve the value and then deserialize it and return the object. The get() method returns null if the value is not found or is expired.
  • MemcachedClient.add() is used to add an object to the cache only if it does not already exist. In Listing 1 the contactId-1 key exists in the cache already, so it won’t be added.
  • MemcachedClient.replace() replaces an object with the value for the given key (if there is already such a value). In Listing 1, contactId-1 is already in the cache, so its value would be replaced.
  • MemcachedClient.delete() deletes a given key from the cache. In Listing 1, the call is used to delete the contactId-1 key.
MemcachedClient.set()

You can use MemcachedClient.set() to store a simple string or a complex object. When you store a complex object, MemcachedClient will first serialize the object and then store it. As a result, every object that you store in Memcached must be serializable, and the key must also be a string. In Listing 1, the set() method returns an object of Future<Boolean>. When we call the set method, it is executed asynchronously, so the control moves to the next line without waiting for a response from the Memcached server. If you needed to know the result of the set operation, then you would call setResult.get() on the Future object instance.

Spying under the hood: spymemcached

Before we move on to the web application exercise, let’s look under the hood to see how spymemcached works. Figure 1 is a sequence diagram showing what happens in spymemcached when a client issues a get().

Figure 1. get() under the hood (click to enlarge)

Spymemcached is an asynchronous, single-threaded Memcached client. When you call any caching-related method on spymemcached’s MemcachedClient, it will be handled asynchronously. The client call method handles writing the details of the operation that should be performed into a queue and returning the control back to the client making the call. The actual interaction with the Memcached server, meanwhile, is handled by a separate thread that runs in the background.

Notice that the sequence diagram in Figure 1 has two different threads. The first thread shows the method sequence for what happens when a client makes a get() call. The second thread displays a method sequence for the daemon thread that communicates with the Memcached server. Both threads are worth a closer look.

Sequence of events in a client thread

When you call MemcachedClient‘s get() method it takes the arguments and forwards control to the asyncGet() method on the object of Memcached class. The asyncGet() method then forwards control to either AsciiOperationFactory or BinaryOperationFactory, depending on the Memcached protocol your client uses to communicate with the server. AsciiOperationFactory is the default value.

The AsciiOperationFactory constructs an object of the command-specific operation object. In this case, since the client issued a get command, it creates an object of GetOperationImpl and returns it. The MemcachedClient.asyncGet() method then takes care of attaching a callback function to the operation. This function will be called when MemcachedClient gets data back from the server and returns a java.util.concurrent.Future object. The client uses the java.util.concurrent.Future to retrieve the data returned from server.

Once MemcachedClient has the object of GetOperationImpl, it first tries to validate the key by ensuring that the length of the key is less than 250 characters and does not contain any special characters. Once the key is validated, the next task is to figure out which server the request should go to. For that MemcachedClient passes control to an instance of the NodeLocator class with the key. The NodeLocator class calls the HashAlgorithm.hash(key) method to get the hashCode for the key. By default, NodeLocator will call the hashCode() method on the key, which is a String object. Once it has the hashCode it will divide that by the number of servers; for example, if the hashCode were 10 and the number of servers three, then the remainder would be one. So the cache entry would be located in Server 1. The MemcachedNode object representing Server 1 would be selected. The MemcachedConnection object would then add the get operation to the queue of Server 1 and return control to the client code.

Sequence of events in daemon threads

If you take a look at the MemcachedClient source code, you will notice that it implements the java.lang.Thread interface. When you create a new instance of the MemcachedClient it kicks off a new thread by calling a start() method on the current object, at which point the JVM will call a MemcachedClient run() method from the newly created thread.

Inside the run() method, MemcachedClient checks the value of the running flag. If it is true, MemcachedClient calls the handleIO() method of the MemcachedConnection object. handleIo() looks at the current job queue to get a list of pending tasks and tries to optimize them. For example, if more than one get() request is pending then this method will combine them into one call. The handleIO() method uses the java.nio methods to communicate with the server. When you call the MemcachedClient shutdown() method, it changes the value of the running flag to false, which results in stopping the run() method and the background daemon thread. It also closes the connection with the Memcached server.

Using Memcached in an enterprise web application

This section introduces you to integrating Memcached into an enterprise architecture. Using the Contact web application introduced in Listing 1, we’ll add, remove, update, and view records in a CONTACT table. Next I’ll show you how to use Memcached to alleviate database load by configuring it as second-level cache for Hibernate. Finally, I’ll explain how to use Memcached to store custom Java objects and cache the HTML generated for each web page.

Start by downloading ManageContact-NoCaching.zip. The ManageContact application contains a ContactServlet that looks at incoming requests and decides what database interaction is required to execute each one. It then forwards control to ContactDAO in order to execute the required database interaction. ContactDAO uses Hibernate to execute select, insert, and update functions on the Contact table. When control is returned to ContactServlet, it forwards control to the appropriate JSP in order to generate markup on the web page. The ManageContact application has a Maven script that takes care of downloading all of the necessary dependencies; you can execute a mvn install command to download these dependencies and then run the application in an embedded Glassfish server. Once the server is started you should be able to access the application at http://localhost:8080/ManageContact/contact.

Enter hibernate-memcached

Most web applications spend a good chunk of their time interacting with databases. Caching data can help you speed up that interaction, as well reduce load on your database. Hibernate provides a nice interface for caching that allows you to use your own caching framework. You instruct Hibernate on which caching framework to use by specifying the name of a class that implements org.hibernate.cache.CacheProvider with the property hibernate.cache.provider_class. From there, you have two options: you can either create your own class that implements the org.hibernate.cache.CacheProvider interface and stores the cache entries in the Memcached server, or you can use the hibernate-memcached framework, which is an open source framework based on the spymemcached client. hibernate-memcached supports entity and query caching.

Configure hibernate-memcached as a caching framework

By default caching is disabled in hibernate-memcached, so our first step is to enable Hibernate’s second-level cache. We’ll also need to configure Memcached as a caching implementation for Hibernate. We can handle both of these requirements in the Hibernate configuration file (hibernate.cfg.xml), which is used to configure application-level settings for Hibernate:

Listing 2. Hibernate config
<property name="cache.provider_class">com.googlecode.hibernate.Memcached.MemcachedCacheProvider</property>
 <property name="hibernate.Memcached.servers">localhost:11211</property>
 <property name="hibernate.Memcached.cacheTimeSeconds">300</property>
 <property name="hibernate.Memcached.connectionFactory">BinaryConnectionFactory</property>

Now let’s take a closer look at each of the properties set. You can enable the second-level cache by setting a value of cache.provider_class to com.googlecode.hibernate.Memcached.MemcachedCacheProvider. The properties that start with "hibernate.Memcached" are specific to the Memcached provider:

  • cache.provider_class: The value of this property defines which class should be used as a cache implementation. In this case we set it to com.googlecode.hibernate.Memcached.MemcacheddCacheProvider, which is provided by the hibernate-memcached framework and uses Memcached as a caching framework.
  • hibernate.Memcached.server: The properties starting with hibernate.Memcached are used by the hibernate-memcached framework. The value of hibernate.Memcached.server should be a space-delimited list of Memcached instances in host:port format. This Memcached server is running on my localhost at port 11211, so I set the value to localhost:11211, which is the default value.
  • hibernate.Memcached.cacheTimeSeconds: The value of this property defines the default number of seconds that each item should be cached. I want the CONTACT record to be cached for 300 second.
  • hibernate.Memcached.connectionFactory: This is the "simple" name of the spyMemcached ConnectionFactory class. It must be one of DefaultConnectionFactory, KetamaConnectionFactory, or BinaryConnectionFactory. The BinaryConnectionFactory performs much better by using a binary protocol
More configuration properties

See "Adding hibernate-memcached to your application" on the hibernate-memcached wiki for a list of all the configuration properties supported by hibernate-memcached.

Develop a caching strategy

Once you have enabled caching your next step is to choose which data you want to cache and what caching strategy you will use. In my case, I want to cache the data from my CONTACT table. Since that will be regularly updated, I set my cache strategy to read-write by adding a cache element in the Contact.hbm.xml, like this:

Listing 3. Configure the caching strategy
<hibernate-mapping package="com.javaworld.Memcached">
    <class name="Contact" table="CONTACT"  >
    <cache usage="read-write"/>
        <id name="contactId" column="CONTACTID">
            <generator class="increment"/>
        </id>
        <property name="firstName" column="FIRSTNAME"/>
        <property name="lastName" column="LASTNAME"/>
        <property name="email" column="EMAIl"/>
    </class>
</hibernate-mapping>

After you’ve updated your own Contact.hbm.xml file (which you can download with the article source), start the Memcached server by executing a Memcached -vv command. This will start Memcached in verbose mode so that it prints every client interaction on the console. Next, execute mvn clean install to start the application. Go to http://localhost:8080/ManageContact/contact and add couple of records. When you click on the record to go to the details, you should notice that no SQL query is executed; instead those records are coming back from the cache. On the Memcached server console, you should see an interaction similar to what is shown in Figure 2.

Figure 2. A view from the Memcached console (click to enlarge)

Using Memcached for server responses

So far you’ve seen how to reduce the load on your database by using Memcached as a second-level cache in Hibernate. Not all application scenarios are quite so simple, however. For instance, how should you handle web pages that process and display data from a web service? You’ll find your application using CPU-intensive logic to build markup for every response, which probably would be better off cached. If you cache the generated markup then the next request for that markup will return from the cache instead of going to a servlet.

The first step is to build a simple Servlet filter to intercept the request. Start by copying the CachingResponseWrapper.java and CachingResponseWriter.java into a com.javaworld.Memcached.filter package. Together these two classes will collect the responses generated by ContactServlet into a String.

Next, create a CacheFilter.java in the com.javaworld.Memcached.filter package and change its doFilter() method so that it looks like this:

Listing 4. CacheFilter.java
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        log.debug("Inside CachingFilter.doFilter() " );
        try {
            HttpServletRequest httpServletRequest = (HttpServletRequest)request;
            HttpServletResponse httpServletResponse = (HttpServletResponse)response;
            ObjectPool<MemcachedClient> MemcachedClientPool = MemcachedHelper.getMemcachedConnectionPool();
            MemcachedClient  MemcachedClient = MemcachedClientPool.borrowObject();
            StringBuffer cacheKeyBuffer = new StringBuffer();
            cacheKeyBuffer.append(httpServletRequest.getContextPath());
            cacheKeyBuffer.append(httpServletRequest.getServletPath());
            if(httpServletRequest.getQueryString() != null){
                cacheKeyBuffer.append("?");
                cacheKeyBuffer.append(httpServletRequest.getQueryString());
            }
            
            String cacheKey = httpServletResponse.encodeURL(cacheKeyBuffer.toString());
            System.out.println ("Get Path Info  " + cacheKey);
            String cachedResponse =(String) MemcachedClient.get(cacheKey);
            
            if( cachedResponse == null){
                System.out.println("Response is not cached forwarding control to servlet");
                CachingResponseWrapper cachingResponseWrapper =new CachingResponseWrapper((HttpServletResponse)response);
                chain.doFilter(request, cachingResponseWrapper);
                CachingResponseWriter collectResponseWriter = (CachingResponseWriter)cachingResponseWrapper.getWriter();
                String collectedResponseStr = collectResponseWriter.getCollectedResponse();//.replaceAll("\n", "") ;
                System.out.println( "Set value in the Memcached for key " + httpServletResponse.encodeURL(collectedResponseStr));
                
                System.out.println("Result of set" + MemcachedClient.set(cacheKey, 0, collectedResponseStr).get());
                //MemcachedClient.flush().get();
            }else{
                System.out.println("Returning cached response ");
                response.setContentType("text/html");
                response.getWriter().println(cachedResponse);
            }
            //MemcachedClient.flush().get();
            MemcachedClientPool.returnObject(MemcachedClient);
        } catch (NoSuchElementException e) {
            e.printStackTrace();
        } catch (IllegalStateException e) {
            e.printStackTrace();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

Note that in the doFilter() method you’re first building the URL that the client used to access the ContactServlet; this URL is used as a key for caching. Once the URL is built, you’ll execute MemcachedClient.get(cacheKey) to check if the response for the given URL is already cached. If it is, then return it; if it isn’t, then wrap the response object into a CachingResponseWriter and pass control to a servlet that will generate the necessary markup. After the control returns from the servlet, call a collectResponseWriter.getCollectedResponse() method. This method will return the response generated by the servlet as a String. Take that response and save it in your cache with its URL as the key. The next time this query is used, the response will come from your cache and not from the servlet.

source:

http://www.javaworld.com/javaworld/jw-05-2012/120515-memcached-for-java-enterprise-performance-2.html?page=1

Did you like this? Share it:

Five Steps to Managing Third-Party Application Security Risk

How secure is your 3rd party code? What are the major security vulnerabilities present in SDLC today?

Can you trust that the code delivered to you was tested for security risks? 3rd-Parties are the Achilles’ Heel in the Software Supply Chain. 40% of all software submitted at the request of large Enterprises is from third parties, but very little security testing is ever performed on this software.

This whitepaper outlines a five step process that enterprises can apply to their third-party application portfolio to gain visibility into their security state and make informed purchase, integration, deployment and maintenance decisions. From software risk assessments to embedding specific contract language into procurement contracts, these key steps provide guidance that enterprises can swiftly implement to simply and cost-effectively meet regulatory requirements, establish a third-party governance framework and protect their critical assets.

Read More:

http://www.informationweek.com/whitepaper/Security/Application-Security/five-steps-to-managing-third-party-application-sec-wp1337796521?articleID=191704892&itc=SBX_iwk_fture_wp_Security_security

Did you like this? Share it:

Test leaders reveal Google’s approach to testing software

Technologies continue to evolve, but does the way we test software change? Leaders at Google, a company known for its innovation, have broken the mold and their unique test strategies are revealed in the new book, How Google Tests Software. Authors James Whittaker, Jason Arbon and Jeff Carollo discuss the book and what readers can learn from Google’s approach to testing software.

SSQ: You mention in the introduction that Microsoft also has a book about how they test software, but “the approaches to testing couldn’t be more different.” Can you highlight some of the major differences?

James Whittaker/Jason Arbon/Jeff Carollo: At Google, testing is owned by everyone on the development team. Developers have to take responsibility for their unit tests and testers take responsibility for making developers productive testers. It’s not a dev-test model; everyone is a tester at Google.

SSQ: Are many of the differences in test processes that you describe only for Web-based test efforts or do you recommend them universally for all types of software testing efforts?

Whittaker/Arbon/Carollo: At the end of the day, all software does only four things: accept input, produce output, store data and perform computation. Thus, many of the things in the book speak to this general problem and thus apply universally. Google may be known as a Web company, but Chrome is a client app, Android is an OS, App Engine is a platform…Google test processes have to span the gamut. That said, Web testing is a large part of the Google mission and in many ways the Web makes testing easier: We can deploy fixes instantaneously, we can test in production, we can utilize crowd source testing to great effect. The Web is a special case but it is still basically the same testing problems and lessons in testing that apply universally.

SSQ: You recommend that testers learn to code and that developers learn to test and that the functions of development and test are both performed by each engineer. This works if you hire people with both of these skills, but if a team is transitioning, how do you deal with testers that don’t have the aptitude or interest in coding?

Whittaker/Arbon/Carollo: Their role is limited. A single manual tester acting like a user is likely to be much less effective than a tester who can also apply their skill using automation. Coding isn’t that hard to learn and testers should actively want to expand their impact. That’s what careers are made of!

SSQ: You say, “The first piece of advice I give people when they ask for the keys to our success: Don’t hire too many testers.” However, shouldn’t that be, ‘Don’t hire too many dedicated testers?’  It seems the real key is to hire people who can perform both development and test functions. Would you agree? If so, how do you assess this in your hiring process?

Whittaker/Arbon/Carollo: In the old days, Chrome had a dedicated team of manual testers. The cost to the company was astronomical. They found lots of bugs pretending to be users and soon enough the dev team got used to relying on them. In the end, it just made developers lazier and helped them write more bugs. When developers were given the tools to perform self-service testing (described in the book) they wrote fewer bugs and we needed fewer testers. When internal dog food users were given better bug reporting tools (also described in the book) they found more and better bugs than the manual testers and were much cheaper. A combination of automation and crowdsourced testers keeps the costs of testing software down.

Read More:

http://searchsoftwarequality.techtarget.com/news/2240150801/James-Whittaker-and-other-test-leaders-reveal-Googles-approach-to-testing-software

Did you like this? Share it:

Adventures in Mobile-Payment App Field Testing

Since I began reporting and writing about the payments industry in late 2007, I’ve come across what seems like an infinite number of products and services that either fall flat on their face shortly after launch, slowly gain traction over a number of months or skyrocket to immediate success. Tabbedout, which is a mobile-payment application intended for the hospitality sector, falls somewhere between the latter two outcomes I described.

The idea behind Tabbedout is simple. You link a credit or debit card to the app, which you then can use to pay your bill at a participating bar or restaurant. When you open a tab on the app, you receive a unique code to give the server or bartender so they can track your order through the corresponding software on the merchant’s point-of-sale system. At the end of night when it’s time to leave, you simply press a button to pay your tab. That’s it. No waiting around a busy bar and fending off others to get the bartender’s attention to pay your bill. But what sounds good on paper does not always work in real-world situations.

A couple of weeks ago, three Mercator analysts, our friends and me decided to test Tabbedout in Cambridge, Mass. at Charlie’s Kitchen, which is a stone’s throw away from Harvard University. Our mission was to test Tabbedout’s limits. We learned at the end of the night that the merchant might have a large part in how successful any mobile-payment application can become in the long-term.

Trouble immediately greeted us when we arrived on a Friday night after work. When I told the server I intended to pay my portion of the bill with Tabbedout, she was unfamiliar with the app. Only one staff member really understood how it worked. And that’s something Tabbedout recognizes as a problem.

“We know staff turnover at these places is high,” Arturo Coto, Tabbedout’s vice president of marketing, told me in an interview.

Tabbedout created an online learning management system that bar and restaurant staffers can access through Facebook. The company also is engaged with the establishment throughout the entire implementation process through phone calls and site visits.

Coto also noted one challenge Tabbedout faces is in its own market-by-market penetration strategy. For example, Tabbedout users in cities such as Portland, Seattle and Austin, Texas have little to no problems using the app because many merchants in the area accept it as a payment option and are familiar with it.When Tabbedout has multiple bars and restaurants in one city accepting the app as payment, “the consumer experience is much better,” Coto said.

In the Boston area, only Charlie’s Kitchen and Red Lantern, a sushi restaurant, accept Tabbedout. Coto anticipates in the next year that more merchants in Boston and the city’s immediate surrounding areas such as Cambridge will accept Tabbedout. “That will help lower the problems you faced,” he said.

Back to the experiment, which got a bit more rocky as the night went on.

Once my server returned after asking someone behind the bar about Tabbedout, she told me we could try it out and see what happened at the end of the night. I proceeded to give her the unique code so she could keep track of my order. But no items were ever entered into the system.

We learned this when David Kaminsky, an analyst for the Emerging Technologies practice, tried to join my tab, which the app enables you to do. He could not, which meant my items, and really the everyone’s in general, were not put into Tabbout’s corresponding register software. Had the process worked as it was intended, Kaminsky at the end of the night could have paid his portion of the bill from my tab from his phone.

At some point during the night, I noticed my tab timed out on the app because no items were added. Tabbedout does this as a security measure, Coto said.

Read More:

http://www.paymentsjournal.com/Content/Blogs/Mercator_Blog/11747/

Did you like this? Share it:

Mobile Application Testing: Should The Device Matter?

At the STAR EAST conference this year, mobile solutions saturated the vendor exhibition area. It’s no wonder that mobile application testing is the hot in the testing community right now. Testers are now faced with the task of testing mobile versions of their applications and figuring out how to adapt to the new paradigm (and challenges) mobile applications bring. It’s not as if they didn’t have enough to test already, right?

After listening to some of the conversations around mobile and seeing some interesting questions being raised, I’m wondering if this has become more difficult than it should be. A common question I hear is “How do I figure out how to test all of these different devices with various screen sizes by different manufacturers with a different OS on each?”  A quick look at the market reveals at least four major operating systems (Apple, Android, Windows, and Blackberry), with multiple versions for an untold number of devices for each.  I think every tester would agree, automation is a must.

So, should the device matter? For years we have been testing applications on various laptops, desktops, and servers without regard to the model, size, or parts inside. Aren’t we just replacing the PC with a mobile device? The reason I could see the specific device playing a key role today has to do with the way automation is being accomplished – namely through bitmap recognition and/or OCR technologies. These technologies are useful, and serve their purpose for building automated test scripts. However, when screen sizes change (i.e. iPhone to iPad), this breaks the scripts. Worse case, multiple versions of the script need to be in place to accommodate different devices.

As an HP reseller, we’re focused on the automation capabilities of HP’s Unified Functional Test, which includes QuickTest Pro and Service Test. There are a few add-ins that can be purchased to add mobile automation. They include ZAP-fiX, DeviceAnywhere, and Perfecto Mobile. All of these handle automation using bitmap recognition and/or OCR. They also currently require the device to be jail broken (iPhone) or rooted (Android) to start testing. This causes a major dilemma for the QA Manager committed to quality. How can you start with a fundamental change to the OS code? It’s a hack, which means it is an undocumented change to the release being tested that does not reflect the production end user build (unless they have the exact jailbreak too) with no control over that changed code. Nevertheless, testing must get done.

What if there was one solution that approached this problem a little differently? JAMO Solutions provides code that is integrated into the application as it is delivered to the device. This code allows for object recognition so that an automation product like QuickTest Pro can “hook” into the application and see all of the objects, their name, and many other properties. Why is that important? Now we have access to all the objects of the application various known properties that bitmap recognition methods could never be aware of (like hidden objects that might still need some form of verification). Scripts won’t break due to screen size because the object’s property is still the same. This means the OS matters, but the device doesn’t. If the device supports the OS, then the script will still work even when the device changes. This is much like how testers approach web based application test automation. They are not concerned whether they are testing against a Dell desktop, a Lenovo laptop, or an HP Proliant server. They obviously do care with regards to if the OS is Windows 2008, Windows XP, or Red Hat Linux.  However, if the OS supports the test case, that is what matters.

The leadership team at Northway Solutions Group spent a great deal of time and research in determining what type of partner we wanted for mobile testing solutions. Jamo Solutions was the obvious choice.  Offering JAMO as our mobile automation solution exemplifies our commitment to meeting the ever increasing needs in the Software Quality Management marketplace. It allows us to talk to our existing customers who already use HP’s QuickTest Professional and help them understand how they can extend its use into mobile applications in a pretty seamless fashion. It doesn’t require they rethink how they test applications today, so they can use the same approach, and the code for the OS is exactly the same in production.

What do you think? Should the device matter? Why or why not? We look forward to your comments.

Source:

http://northwaysolutions.com/our-work/blog/2012/05/mobile-application-testing-should-the-device-matter/

Did you like this? Share it:

Software Testing Certification

There is lots of Software Testing Certification courses are available in market for different reasons or for different countries but the main certification course for Software Testers for all reasons is ISTQB (International Software Testing Qualification board). ISTQB certification is a global certification course which treated as Software Testing professional degree for any tester. Apart from this there is multiple testing certification courses, below are few

1. CSTE : Certified Software  Test Engineer
2. CSQA:  Certified Software Quality Analyst
3. ISEB: Information Systems Examination Body
4. SSBB: Six Sigma Black Belt Certification
5. CSTP: Certified Software Test Professional
6. CTFL: ISTQB Certified tester Foundation Level
7. QAI: Quality Assurance Inspector
8. Brain Bench

Apart from these there are few certification courses for Automation tools also from vendors from HP (QTP, load runner, Quality Center and Win runner), IBM (rational robot).

Now a day’s most of the companies not asking for certifications but still there are lot of companies prefers Software Certified testers.

Did you like this? Share it:

Test Factors in Software Testing

Introduction

For designing Test Cases the following factors are considered:

  1. Correctness
  2. Negative
  3. User Interface
  4. Usability
  5. Performance
  6. Security
  7. Integration
  8. Reliability
  9. Compatibility

Correctness : Correctness is the minimum requirement of software, the essential purpose of testing. The tester may or may not know the inside details of the software module under test e.g. control flow, data flow etc.

Negative : In this factor we can check what the product it is not supposed to do.
User Interface : In UI testing we check the user interfaces. For example in a web page we may check for a button. In this we check for button size and shape. We can also check the navigation links.
Usability : Usability testing measures the suitability of the software for its users, and is directed at measuring the following factors with which specified users can achieve specified goals in particular environments.

  1. Effectiveness : The capability of the software product to enable users to achieve specified goals with the accuracy and completeness in a specified context of use.
  2. Efficiency : The capability of the product to enable users to expend appropriate amounts of resources in relation to the effectiveness achieved in a specified context of use.

Performance : In software engineering, performance testing is testing that is performed from one perspective to determine how fast some aspect of a system performs under a particular workload.
Performance testing can serve various purposes. It can demonstrate that the system needs performance criteria.

  1. Load Testing: This is the simplest form of performance testing. A load test is usually conducted to understand the behavior of the application under a specific expected load.
  2. Stress Testing: Stress testing focuses on the ability of a system to handle loads beyond maximum capacity. System performance should degrade slowly and predictably without failure as stress levels are increased.
  3. Volume Testing: Volume testing belongs to the group of non-functional values tests. 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.

Security : Process to determine that an Information System protects data and maintains functionality as intended. The basic security concepts that need to be covered by security testing are the following:

  1. Confidentiality : A security measure which protects against the disclosure of information to parties other than the intended recipient that is by no means the only way of ensuring
  2. Integrity: A measure intended to allow the receiver to determine that the information which it receives has not been altered in transit other than by the originator of the information.
  3. Authentication: A measure designed to establish the validity of a transmission, message or originator. Allows a receiver to have confidence that the information it receives originated from a specific known source.
  4. Authorization: The process of determining that a requester is allowed to receive a service/perform an operation.

Integration : Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested.

Reliability : Reliability testing is to monitor a statistical measure of software maturity over time and compare this to a desired reliability goal.

Compatibility : Compatibility testing of a part of software’s non-functional tests. This testing is conducted on the application to evaluate the application’s compatibility with the computing environment. Browser compatibility testing can be more appropriately referred to as user experience testing. This requires that the web applications are tested on various web browsers to ensure the following:

Users have the same visual experience irrespective of the browsers through which they view the web application.

In terms of functionality , the application must behave and respond the same across various browsers.

Source:http://www.c-sharpcorner.com/UploadFile/face6d/test-factors-in-software-testing/

Did you like this? Share it: