1) Analyze your test results Troubleshooting the root cause of failure will lead you to the solution of the problem, thus analyzing is very much needed, proper analyzing may get you out of all the possible mistakes. Bugs in softwares are introduced by both man and machine and some of the other practical reasons for the occurrence of bugs are miscommunication, software complexity, Programming errors, changing requirements, time pressures and reluctance.

2) Maximized Test coverage Make use of the entire possible tool for testing application. It can be done by trial and error method for better results, but practically it is impossible to include all the testing methods therefore it is advised to use the testing methods which gave best results earlier. Selecting a testing tool from a QA perspective will result in producing media verification, release scenario and Decision to release the product.

3) Ensure maximum test coverage Breaking your Application Under Test (AUT) in to smaller functional modules will help you to cover the maximum testing applications also if possible break these modules into smaller parts and here is an example to do so.

E.g: Let’s assume you have divided your website application in modules and accepting user information is one of the modules. You can break this User information screen into smaller parts for writing test cases: Parts like UI testing, security testing, functional testing of the User information form etc. Apply all form field type and size tests, negative and validation tests on input fields and write all such test cases for maximum coverage.

4) While writing test cases First preference should be given to intended functionality before writing a test case and then for invalid conditions. This will cover expected as well unexpected behavior of application under test.

Some of the Cases should be considered while testing web applications. • Functionality Testing • Performance Testing • Usability Testing • Server Side Interface • Client Side Compatibility • Security

5) Error finding attitude Being a software Tester or a QA engineer you must stay curious about finding a bug in an application, existence of subtle bugs may even crash the entire system. So finding such a subtle bug is most challenging work and it gives you satisfaction of your work and to remain positive.

6) Test cases in requirement analysis Designing the pre requirements about the test cases and analysis can help you to ensure that all the cases are testable.

7) Availability of test cases to developers. Let developers analyze your test cases thoroughly to develop quality application. Letting them to do your work will help them to stay vigil while coding. This is also a time consuming scenario which will help you to release a quality product.

8) To ensure quick testing If possible identify and group your test cases for regression testing. This will ensure quick and effective manual regression testing.

9) Performance testing When it comes to the case of applications it consumes critical response time, therefore it must be given highest priority by choosing performance testing. But at many instants performance testing is avoided as it requires large data volume.

10) Avoid testing your own code Developers are not good testers, none of the developers like to be blamed for their work because they remain optimistic when it comes to their product and they tend to skip their bugs as the person who develops the code generally sees only happy paths of the product and don’t want to go in much detail.

11) Testing requirement has no limits Sky is the only limit for testing an application, use all the available means for testing application to improve the quality.

12) Advantage of previous bug graph Using a previous graph will be an aid for finding bugs against different time modules, especially while doing regression testing. This module-wise bug graph can be useful to predict the most probable bug part of the application.

13) Review your Test process Keep in track with your test results, these results may teach you a lot about learning new things. Keep a text file open while testing an application and use these notepad observations while preparing final test release report. This good habit will help you to provide the complete unambiguous test report and release details.

14) Importance of code changes When it comes to the banking projects it requires lots of steps in development or testing environment to avoid execution of live transaction processing. Therefore note down all the changes done for the testing purpose, as testers or developers make changes in code base for application under test.

15) Stay away – Developers If developers don’t have access to testing environment they will not do any such changes accidentally on test environment and these missing things can be captured at the right place.

16) Role of a tester in design When you bring in testers right from software requirement and design phase it is obvious they will also become a part of development hence request to your lead or manager to involve your testing team in all decision making processes or meetings. In this way testers can get knowledge of application dependability resulting in detailed test coverage.

17) Rapport with the other testing team Holding a good relationship with your co testers from other team helps both the parties to share best of their testing experience.

18) Together testers and developers Do not keep anything verbal. To know about more details of the product, testers should relate with the developers, maintaining such kind of relationship will resolve more issues which are coming up in the product in the initial stage, make sure to communicate the same over written communication ways like emails.

19) Timing priority Analyzing all risks helps a lot to prioritize work and it is the first stage of implementing time saving method. From this you can avoid wasting time.

20) Importance of final report Testing is a creative and challenging task and do not fail to create a clear report about the bugs and possible solutions. This will remain as a record for Do’s and Dont’s in testing for future generation.’

AWS Free Usage Tier

To help new AWS customers get started in the cloud, AWS is introducing a free usage tier. New AWS customers will be able to run a free Amazon EC2 Micro Instance for a year, while also leveraging a free usage tier for Amazon S3, Amazon Elastic Block Store, Amazon Elastic Load Balancing, and AWS data transfer. AWS’s free usage tier can be used for anything you want to run in the cloud: launch new applications, test existing applications in the cloud, or simply gain hands-on experience with AWS.

Below are the highlights of AWS’s free usage tiers. All are available for one year (except SWF, DynamoDB, SimpleDB, SQS, and SNS which are free indefinitely):

AWS Free Usage Tier (Per Month):

• 750 hours of Amazon EC2 Linux Micro Instance usage (613 MB of memory and 32-bit and 64-bit platform support) – enough hours to run continuously each month*
• 750 hours of Amazon EC2 Microsoft Windows Server Micro Instance usage (613 MB of memory and 32-bit and 64-bit platform support) – enough hours to run continuously each month*
• 750 hours of an Elastic Load Balancer plus 15 GB data processing*
• 30 GB of Amazon Elastic Block Storage, plus 2 million I/Os and 1 GB of snapshot storage*
• 5 GB of Amazon S3 standard storage, 20,000 Get Requests, and 2,000 Put Requests*
• 100 MB of storage, 5 units of write capacity, and 10 units of read capacity for Amazon DynamoDB.**
• 25 Amazon SimpleDB Machine Hours and 1 GB of Storage**
• 1,000 Amazon SWF workflow executions can be initiated for free. A total of 10,000 activity tasks, signals, timers and markers, and 30,000 workflow-days can also be used for free**
• 100,000 Requests of Amazon Simple Queue Service**
• 100,000 Requests, 100,000 HTTP notifications and 1,000 email notifications for Amazon Simple Notification Service**
• 10 Amazon Cloudwatch metrics, 10 alarms, and 1,000,000 API requests**
• 15 GB of bandwidth out aggregated across all AWS services*

In addition to these services, the AWS Management Console is available at no charge to help you build and manage your application on AWS.

* These free tiers are only available to new AWS customers, and are available for 12 months following your AWS sign-up date. When your free usage expires or if your application use exceeds the free usage tiers, you simply pay standard, pay-as-you-go service rates (see each service page for full pricing details). Restrictions apply; see offer terms for more details.

** These free tiers do not expire after 12 months and are available to both existing and new AWS customers indefinitely.

The HTML

Our HTML document contains an unordered list and each list item is a link with an anchor tag. The span contains the name of the menu item.

1. <ul class=”main-ul”>
2.      <li><a href=”#”><span>Home</span></a></li>
3.      <li><a href=”#”><span>Article</span></a></li>
4.      <li><a href=”#”><span>Blog</span></a></li>
5.      <li><a href=”#”><span>Gallery</span></a></li>
6.      <li><a href=”#”><span>About</span></a></li>
7.      <li><a href=”#”><span>Contact Us</span></a></li>
8.      <li><a href=”#”><span>Alumini</span></a></li>
9.      <li><a href=”#”><span>Portfolio</span></a></li>
10. </ul>

The CSS

Now let’s position menu list items. I am using 25% width for each item, so in each row four menu items can be positioned. I’m aligning text of each list item to center.

1. body{
2.      background: #eee url(../images/white_paperboard.png) repeat top right;
3. }
4. .main-ul li {
5.      float:left;
6.      position:relative;
7.      width:25%;
8.      text-align:center;
9. }

Next let’s position each anchor tag and change text decoration to none. I am using a light gray color background. I am also adding CSS3 transition effects to these elements with a duration of one second.

1. .main-ul li a {
2.      display:block;
3.      padding-bottom:20px;
4.      padding-right:10px;
5.      padding-top:10px;
6.      padding-left:10px;
7.      text-decoration:none;
8.      position: relative;
9.      z-index: 100;
10.      background-color: rgba(164, 164, 164, 0.2);
11.      -webkit-transition: all 1s;
12.      -moz-transition: all 1s;
13.      -o-transition: all 1s;
14.      transition: all 1s;
15. }

I am using ‘Kotta One’ font for span text, normal font size and weight of 20px and 700 respectively. I’ve made the font color for the text in its hover state white.

1. .main-ul li a span{
2.      display:block;
3.      padding-top:10px;
4.      font-weight:700;
5.      font-size: 20px;
6.      color: rgba(120, 120, 120, 0.9);
7.      text-transform:uppercase;
8.      font-family: ‘Kotta One’, serif;
9. }
10. .main-ul li:hover span{
11.      color: #fff;
12. }

Here comes our main part, I have already added transition effect for the anchor tags. Now add hover effects for each anchor tag list item by changing its background color. So when someone hovers over each list menu item it will change background color to a new color. I’m also adding CSS3 transformrotate effects of 3 degrees.

1. .main-ul li:nth-child(1):hover a{
2.      background-color: rgba(175,54,55,0.8);
3.      -moz-transform: rotate(-3deg);
4.      -webkit-transform: rotate(-3deg);
5.      -o-transform: rotate(-3deg);
6.      transform: rotate(-3deg);
7. }

Now repeat the above step for all list items with a new background color of your choice!

1. .main-ul li:nth-child(2):hover a{
2.      background-color: rgba(199, 204, 73, 0.8);
3.      -moz-transform: rotate(-3deg);
4.      -webkit-transform: rotate(-3deg);
5.      -o-transform: rotate(-3deg);
6.      transform: rotate(-3deg);
7. }
8. .main-ul li:nth-child(3):hover a{
9.      background-color: rgba(213, 135, 11, 0.8);
10.      -moz-transform: rotate(3deg);
11.      -webkit-transform: rotate(3deg);
12.      -o-transform: rotate(3deg);
13.      transform: rotate(3deg);
14. }
15. .main-ul li:nth-child(4):hover a{
16.      background-color: rgba(51, 143, 144, 0.8);
17.      -moz-transform: rotate(3deg);
18.      -webkit-transform: rotate(3deg);
19.      -o-transform: rotate(3deg);
20.      transform: rotate(3deg);
21. }
22. .main-ul li:nth-child(5):hover a{
23.      background-color: rgba(117,18,98,0.8);
24.      -moz-transform: rotate(-3deg);
25.      -webkit-transform: rotate(-3deg);
26.      -o-transform: rotate(-3deg);
27.      transform: rotate(-3deg);
28. }
29. .main-ul li:nth-child(6):hover a{
30.      background-color: rgba(33, 136, 215, 0.8);
31.      -moz-transform: rotate(-3deg);
32.      -webkit-transform: rotate(-3deg);
33.      -o-transform: rotate(-3deg);
34.      transform: rotate(-3deg);
35. }
36. .main-ul li:nth-child(7):hover a{
37.      background-color: rgba(109, 109, 109, 0.8);
38.      -moz-transform: rotate(3deg);
39.      -webkit-transform: rotate(3deg);
40.      -o-transform: rotate(3deg);
41.      transform: rotate(3deg);
42. }
43. .main-ul li:nth-child(8):hover a{
44.      background-color: rgba(152, 120, 92, 0.8);
45.      -moz-transform: rotate(3deg);
46.      -webkit-transform: rotate(3deg);
47.      -o-transform: rotate(3deg);
48.      transform: rotate(3deg);
49. }

That’s it, we have accomplished a simple flashy menu, so that when someone hovers over our menu items simultaneously it will change background color and slightly rotate. Thanks for reading!

Amazon DynamoDB is a fully managed NoSQL database service that provides fast performance at any scale. Today’s web-based applications often encounter database scaling challenges when faced with growth in users, traffic, and data. With Amazon DynamoDB, developers scaling cloud-based applications can start small with just the capacity they need and then increase the request capacity of a given table as their app grows in popularity. Their tables can also grow without limits as their users store increasing amounts of data. Behind the scenes, Amazon DynamoDB automatically spreads the data and traffic for a table over a sufficient number of servers to meet the request capacity specified by the customer. Amazon DynamoDB offers low, predictable latencies at any scale. Customers can typically achieve average service-side in the single-digit milliseconds. Amazon DynamoDB stores data on Solid State Drives (SSDs) and replicates it synchronously across multiple AWS Availability Zones in an AWS Region to provide built-in high availability and data durability.

History of NoSQL at Amazon – Dynamo

The Amazon.com ecommerce platform consists of hundreds of decoupled services developed and managed in a decentralized fashion. Each service encapsulates its own data and presents a hardened API for others to use. Most importantly, direct database access to the data from outside its respective service is not allowed. This architectural pattern was a response to the scaling challenges that had challenged Amazon.com through its first 5 years, when direct database access was one of the major bottlenecks in scaling and operating the business. While a service-oriented architecture addressed the problems of a centralized database architecture, each service was still using traditional data management systems. The growth of Amazon’s business meant that many of these services needed more scalable database solutions.

In response, we began to develop a collection of storage and database technologies to address the demanding scalability and reliability requirements of the Amazon.com ecommerce platform. We had been pushing the scalability of commercially available technologies to their limits and finally reached a point where these third party technologies could no longer be used without significant risk. This was not our technology vendors’ fault; Amazon’s scaling needs were beyond the specs for their technologies and we were using them in ways that most of their customers were not. A number of outages at the height of the 2004 holiday shopping season can be traced back to scaling commercial technologies beyond their boundaries.

Dynamo was born out of our need for a highly reliable, ultra-scalable key/value database. This non-relational, or NoSQL, database was targeted at use cases that were core to the Amazon ecommerce operation, such as the shopping cart and session service. Any downtime or performance degradation in these services has an immediate financial impact and their fault-tolerance and performance requirements for their data systems are very strict. These services also require the ability to scale infrastructure incrementally to accommodate growth in request rates or dataset sizes. Another important requirement for Dynamo was predictability. This is not just predictability of median performance and latency, but also at the end of the distribution (the 99.9th percentile), so we could provide acceptable performance for virtually every customer.

To achieve all of these goals, we needed to do groundbreaking work. After the successful launch of the first Dynamo system, we documented our experiences in a paper so others could benefit from them. Since then, several Dynamo clones have been built and the Dynamo paper has been the basis for several other types of distributed databases. This demonstrates that Amazon is not the only company than needs better tools to meet their database needs.

Lessons learned from Amazon’s Dynamo

Dynamo has been in use by a number of core services in the ecommerce platform, and their engineers have been very satisfied by its performance and incremental scalability. However, we never saw much adoption beyond these core services. This was remarkable because although Dynamo was originally built to serve the needs of the shopping cart, its design and implementation were much broader and based on input from many other service architects. As we spoke to many senior engineers and service owners, we saw a clear pattern start to emerge in their explanations of why they didn’t adopt Dynamo more broadly: while Dynamo gave them a system that met their reliability, performance, and scalability needs, it did nothing to reduce the operational complexity of running large database systems. Since they were responsible for running their own Dynamo installations, they had to become experts on the various components running in multiple data centers. Also, they needed to make complex tradeoff decisions between consistency, performance, and reliability. This operational complexity was a barrier that kept them from adopting Dynamo.

During this period, several other systems appeared in the Amazon ecosystem that did meet their requirements for simplified operational complexity, notably Amazon S3 and Amazon SimpleDB. These were built as managed web services that eliminated the operational complexity of managing systems while still providing extremely high durability. Amazon engineers preferred to use these services instead of managing their own databases like Dynamo, even though Dynamo’s functionality was better aligned with their applications’ needs.

With Dynamo we had taken great care to build a system that met the requirements of our engineers. After evaluations, it was often obvious that Dynamo was ideal for many database use cases. But … we learned that engineers found the prospect of running a large software system daunting and instead looked for less ideal design alternatives that freed them from the burden of managing databases and allowed them to focus on their applications.

It became obvious that developers strongly preferred simplicity to fine-grained control as they voted “with their feet” and adopted cloud-based AWS solutions, like Amazon S3 and Amazon SimpleDB, over Dynamo. Dynamo might have been the best technology in the world at the time but it was still software you had to run yourself. And nobody wanted to learn how to do that if they didn’t have to. Ultimately, developers wanted a service.

History of NoSQL at Amazon – SimpleDB

One of the cloud services Amazon developers preferred for their database needs was Amazon SimpleDB. In the 5 years that SimpleDB has been operational, we have learned a lot from its customers.

First and foremost, we have learned that a database service that takes away the operational headache of managing distributed systems is extremely powerful. Customers like SimpleDB’s table interface and its flexible data model. Not having to update their schemas when their systems evolve makes life much easier. However, they most appreciate the fact that SimpleDB just works. It provides multi-data center replication, high availability, and offers rock-solid durability. And yet customers never need to worry about setting up, configuring, or patching their database.

Second, most database workloads do not require the complex query and transaction capabilities of a full-blown relational database. A database service that only presents a table interface with a restricted query set is a very important building block for many developers.

While SimpleDB has been successful and powers the applications of many customers, it has some limitations that customers have consistently asked us to address.

Domain scaling limitations. SimpleDB requires customers to manage their datasets in containers called Domains, which have a finite capacity in terms of storage (10 GB) and request throughput. Although many customers worked around SimpleDB’s scaling limitations by partitioning their workloads over many Domains, this side of SimpleDB is certainly not simple. It also fails to meet the requirement of incremental scalability, something that is critical to many customers looking to adopt a NoSQL solution.

Predictability of Performance. SimpleDB, in keeping with its goal to be simple, indexes all attributes for each item stored in a domain. While this simplifies the customer experience on schema design and provides query flexibility, it has a negative impact on the predictability of performance. For example, every database write needs to update not just the basic record, but also all attribute indices (regardless of whether the customer is using all the indices for querying). Similarly, since the Domain maintains a large number of indices, its working set does not always fit in memory. This impacts the predictability of a Domain’s read latency, particularly as dataset sizes grow.
Consistency. SimpleDB’s original implementation had taken the “eventually consistent” approach to the extreme and presented customers with consistency windows that were up to a second in duration. This meant the system was not intuitive to use and developers used to a more traditional database solution had trouble adapting to it. The SimpleDB team eventually addressed this issue by enabling customers to specify whether a given read operation should be strongly or eventually consistent.

Pricing complexity. SimpleDB introduced a very fine-grained pricing dimension called “Machine Hours.” Although most customers have eventually learned how to predict their costs, it was not really transparent or simple.

Introducing DynamoDB

As we thought about how to address the limitations of SimpleDB and provide 1) the most scalable NoSQL solution available and 2) predictable high performance, we realized our goals could not be met with the SimpleDB APIs. Some SimpleDB operations require that all data for a Domain is on a single server, which prevents us from providing the seamless scalability our customers are demanding. In addition, SimpleDB APIs assume all item attributes are automatically indexed, which limits performance.

We concluded that an ideal solution would combine the best parts of the original Dynamo design (incremental scalability, predictable high performance) with the best parts of SimpleDB (ease of administration of a cloud service, consistency, and a table-based data model that is richer than a pure key-value store). These architectural discussions culminated in Amazon DynamoDB, a new NoSQL service that we are excited to release today.

Amazon DynamoDB is based on the principles of Dynamo, a progenitor of NoSQL, and brings the power of the cloud to the NoSQL database world. It offers customers high-availability, reliability, and incremental scalability, with no limits on dataset size or request throughput for a given table. And it is fast – it runs on the latest in solid-state drive (SSD) technology and incorporates numerous other optimizations to deliver low latency at any scale.

Amazon DynamoDB is the result of everything we’ve learned from building large-scale, non-relational databases for Amazon.com and building highly scalable and reliable cloud computing services at AWS. Amazon DynamoDB is a NoSQL database service that offers the following benefits:

• Managed. DynamoDB frees developers from the headaches of provisioning hardware and software, setting up and configuring a distributed database cluster, and managing ongoing cluster operations. It handles all the complexities of scaling and partitions and re-partitions your data over more machine resources to meet your I/O performance requirements. It also automatically replicates your data across multiple Availability Zones (and automatically re-replicates in the case of disk or node failures) to meet stringent availability and durability requirements. From our experience of running Amazon.com, we know that manageability is a critical requirement. We have seen many job postings from companies using NoSQL products that are looking for NoSQL database engineers to help scale their installations. We know from our Amazon experiences that once these clusters start growing, managing them becomes the same nightmare that running large RDBMS installations was. Because Amazon DynamoDB is a managed service, you won’t need to hire experts to manage your NoSQL installation—your developers can do it themselves.
• Scalable. Amazon DynamoDB is designed to scale the resources dedicated to a table to hundreds or even thousands of servers spread over multiple Availability Zones to meet your storage and throughput requirements. There are no pre-defined limits to the amount of data each table can store. Developers can store and retrieve any amount of data and DynamoDB will spread the data across more servers as the amount of data stored in your table grows.
• Fast. Amazon DynamoDB provides high throughput at very low latency. It is also built on Solid State Drives to help optimize for high performance even at high scale. Moreover, by not indexing all attributes, the cost of read and write operations is low as write operations involve updating only the primary key index thereby reducing the latency of both read and write operations. An application running in EC2 will typically see average service-side latencies in the single-digit millisecond range for a 1KB object. Most importantly, DynamoDB latencies are predictable. Even as datasets grow, latencies remain stable due to the distributed nature of DynamoDB’s data placement and request routing algorithms.
• Durable and Highly Available. Amazon DynamoDB replicates its data over at least 3 different data centers so that the system can continue to operate and serve data even under complex failure scenarios.
• Flexible. Amazon DynamoDB is an extremely flexible system that does not force its users into a particular data model or a particular consistency model. DynamoDB tables do not have a fixed schema but instead allow each data item to have any number of attributes, including multi-valued attributes. Developers can optionally use stronger consistency models when accessing the database, trading off some performance and availability for a simpler model. They can also take advantage of the atomic increment/decrement functionality of DynamoDB for counters.
• Low cost. Amazon DynamoDB’s pricing is simple and predictable: Storage is $1 per GB per month. Requests are priced based on how much capacity is reserved: $0.01 per hour for every 10 units of Write Capacity and $0.01 per hour for every 50 units of Read Capacity. A unit of Read (or Write) Capacity equals one read (or write) per second of capacity for items up to 1KB in size. If you use eventually consistent reads, you can achieve twice as many reads per second for a given amount of Read Capacity. Larger items will require additional throughput capacity.

In the current release, customers will have the choice of using two types of keys for primary index querying: Simple Hash Keys and Composite Hash Key / Range Keys:

Simple Hash Key gives DynamoDB the Distributed Hash Table abstraction. The key is hashed over the different partitions to optimize workload distribution. For more background on this please read the original Dynamo paper.

Composite Hash Key with Range Key allows the developer to create a primary key that is the composite of two attributes, a “hash attribute” and a “range attribute.” When querying against a composite key, the hash attribute needs to be uniquely matched but a range operation can be specified for the range attribute: e.g. all orders from Werner in the past 24 hours, all log entries from server 16 with clients IP addresses on subnet 192.168.1.0

Performance Predictability in DynamoDB

In addition to taking the best ideas of Dynamo and SimpleDB, we have added new functionality to provide even greater performance predictability.

Cloud-based systems have invented solutions to ensure fairness and present their customers with uniform performance, so that no burst load from any customer should adversely impact others. This is a great approach and makes for many happy customers, but often does not give a single customer the ability to ask for higher throughput if they need it.

As satisfied as engineers can be with the simplicity of cloud-based solutions, they would love to specify the request throughput they need and let the system reconfigure itself to meet their requirements. Without this ability, engineers often have to carefully manage caching systems to ensure they can achieve low-latency and predictable performance as their workloads scale. This introduces complexity that takes away some of the simplicity of using cloud-based solutions.

The number of applications that need this type of performance predictability is increasing: online gaming, social graphs applications, online advertising, and real-time analytics to name a few. AWS customers are building increasingly sophisticated applications that could benefit from a database that can give them fast, predictable performance that exactly matches their needs.

Amazon DynamoDB’s answer to this problem is “Provisioned Throughput.” Customers can now specify the request throughput capacity they require for a given table. Behind the scenes, DynamoDB will allocate sufficient resources to the table to predictably achieve this throughput with low-latency performance. Throughput reservations are elastic, so customers can increase or decrease the throughput capacity of a table on-demand using the AWS Management Console or the DynamoDB APIs. CloudWatch metrics enable customers to make informed decisions about the right amount of throughput to dedicate to a particular table. Customers using the service tell us that it enables them to achieve the appropriate amount of control over scaling and performance while maintaining simplicity. Rather than adding server infrastructure and re-partitioning their data, they simply change a value in the management console and DynamoDB takes care of the rest.

Summary

Amazon DynamoDB is designed to maintain predictably high performance and to be highly cost efficient for workloads of any scale, from the smallest to the largest internet-scale applications. You can get started with Amazon DynamoDB using a free tier that enables 40 million of requests per month free of charge. Additional request capacity is priced at cost-efficiently hourly rates as low as $.01 per hour for 10 units of Write Capacity or 50 strongly consistent units of Read Capacity (if you use eventually consistent reads you can get twice the throughput at the same cost, or the same read throughput at half the cost) Also, replicated solid state disk (SSD) storage is $1 per GB per month. Our low request pricing is designed to meet the needs of typical database workloads that perform large numbers of reads and writes against every GB of data stored.

To learn more about Amazon DynamoDB its functionality, APIs, use cases, and service pricing, please visit the detail page at aws.amazon.com/DynamoDB and also the Developer Guide. I am excited to see the years of experience with systems such as Amazon Dynamo result in an innovative database service that can be broadly used by all our customers.

TM_Elance

Techmodi made it at rank 11th into the top 11 Service Providers out of 29,187   registered providers on Elance across the Globe.

Christmas Greetings

Christmas is an annual commemoration of the birth of Jesus Christ, celebrated generally on 25th December as a religious and cultural holiday by billions of people around the world.  In India also we celebrate Christmas to mark the birth of Jesus Christ, its not only celebrated by the Christians but by all the religions and across all the 28 states of India. At various places people celebrate it in masses to mark the birth of Christ.

Techmodi also celebrates Christmas & the festive season with all its employees in office to ensure that there is fun at work. Techmodi Wishes all a Merry Christmas & Wish a Happy new year 2012.

The next day is Dhana Trayodashi. This day is of special importance for traders and business people. It is also considered an auspicious day for making important purchases, especially metals, including kitchenware and precious metals like silver and gold.

This is followed by Naraka Chaturdashi. On this day people get up early in the morning and take their bath before sunrise while stars are still visible. Bathing is an elaborate process on this day with abundant use of ‘ubtans’, oils and perfumes, and is preceded by an Aarti performed on the person by some lady, usually mother or wife. The whole process is referred to as ‘abhyanga-snaan’.

Then comes Lakshmi- pooja. It occurs on Amavasya i.e. no moon day. The dark night is illuminated by lamps and at dusk firecrackers are burst. New account books are opened after a pooja. Generally the traders do not make any payments on that day (according to their belief Lakshmi should not be given away but must come home). In every household, cash, jewellery and an idol of the goddess Lakshmi is worshipped. Friends, neighbours and relatives are invited over and celebrations are in full swing. The broom used to clean one’s house is also worshipped as a symbol of Lakshmi in some places .

Padwa’ is the 1st day of the new month – Kartik in the Hindu calendar. It marks the start of Hindu financial year. Its a special day for Husband and wife. The wife puts tilak on her husbands forehead and gets an expensive gift. In recent times there is a growing trend of organising a cultural event called ‘Diwali Padwa’ early in the morning.

Bhaubeej – it is the time when the bond of love between a brother and sister is further strengthened as the sister asks God for her brother/s’ long and successful life while she receives presents from her beloved brothers.  More can be checked at :- http://en.wikipedia.org/wiki/Diwali

TechModi has an official holiday on the 26th, 27th & 28th of August 2011 on the occasion of  Diwali.

TechModi has an official holiday on the 15th of August 2011 on the occasion of Independence Day & would compensate for the same by working on the 20th August 2011.

TM_Elance

Techmodi made it at rank 15th into the top 15 Service Providers out of 29,187   registered providers on Elance across the Globe.

Gudi Padwa or Gudhi Padwa (Marathi: गुढी पाडवा often mis-pronounced as guDi padwa because ढी sounds like डी while speaking) is the Marathi name for the Hindu holy day of Chaitra Shukla Pratipada.^[1] It is celebrated on the first day of the Chaitra month to mark the beginning of the New year according to the lunisolar Hindu calendar.

gudi padwa

The word padwa is derived from the Sanskrit word Pratipada for first day of a lunar month i.e. first day after new moon day (Amavasya). A Gudhi is also erected on this occasion giving this festival its name. The term padwa or padavo is also associated with Balipratipada the third day of Diwali which is another celebration that comes at the end of the harvesting season.

Known as Gudhi Padwa in Maharashtra, this festival is also known as

• Samvatsar Padvo among Hindu Konkanis of Goa
• Yugadi among the rest of Konkani diaspora in Karnataka and Kerala
  
• Nav Varsha Samvat among the North Indian states of Uttar Pradesh, Himachal Pradesh, Haryana, Madhya Pradesh, Rajasthan, Uttarakhand, Bihar and Chhattisgarh
  

In other parts of India this festival is celebrated during

• Nau Roz in Kashmir
• Yugadi in Karnataka
• Baisakhi in Punjab
• Cheti Chand among the Sindhi people
  
• Goru Bihu in Assam
• Puthandu in Tamil Nadu and
• Yugadi in Andhra Pradesh
• Vishu in Kerala.

Being the first day of the first month of a year, Gudhi Padwa is the New Year’s Day for Marathi people. India is a predominantly agrarian society. Thus celebrations and festivals are often linked to the turn of the season and to the sowing and reaping of crops. This day marks the end of one agricultural harvest and the beginning of a new one. In this context, the Gudhi Padwa is celebrated at the end of the Rabi season.

TechModi has an official holiday on the 4th of April 2011 on the occasion of Gudi Padwa & would compensate for the same by working on the 9th April 2011.