Amazon Flexible Payments Service

Key features include

• Send and receive money using credit card, bank account or Amazon Payments balance transfer as payment methods.
• Create “Payment Instructions” to define conditions and constraints desired for a given transaction, and programmatically obtain payment authorizations or “tokens” that represent these Payment Instructions from customers.
• Execute one-time, multiple, or recurring payments on behalf of customers.
• Aggregate micro-transactions into a single larger transaction using Prepaid and Postpaid capabilities.
• Integrate Amazon FPS into your website in minutes with Amazon Simple Pay, a set of copy-and-paste HTML buttons.
• Build payment applications where you are neither the sender nor the recipient of funds. You can build marketplace applications that enable the movement of money between two third parties. Try Amazon Simple Pay Marketplace.
• View account balances, transaction histories, and transaction details on the Amazon Payments web site.
• Utilize the Amazon FPS sandbox to build and test applications without using real money or incurring any transaction charges.

References

• http://aws.amazon.com/fps/#legal
• http://docs.amazonwebservices.com/AmazonFPS/2007-01-08/FPSDeveloperGuide/

General Process

1. Generate a caller token(Needed once for each application)
2. Generate a recipient token
3. Generate a co-branded UI url with caller and recipient token
4. Redirect to Amazon with a generated co-branded UI url
5. Amazon will redirect to your web site with a sender token
6. Execute Payment using caller, recipient and sender token

Sample Source Code and API can be found here

Plugins

There are 2 plugins amazon_fps_foo and remit. I could not find much documentation for amazon_fps_foo.

Remit

Remit uses a REST implementation of Amazon Flexible Payments Service (FPS).

There is an example for a "simple" implementation of a "marketplace" charge (one in which you are charging a client for a
product on behalf of another party): http://gist.github.com/46941

Testing

You can check your code with out flowing real money. Sandbox is the test server for checking your code regarding FPS.

Developer Resources

• Rails and Amazon: Libraries and Plugins for EC2, S3, SimpleDB, SQS, FPS and DevPay Integration
• WSDL
• Documentation
• Release Notes
• Amazon FPS Sample Code & Libraries
• Amazon Simple Pay Code & Libraries
• Articles & Tutorials
• Community Forum

Additional Product Information

• FAQs
• Amazon FPS Sandbox
• Amazon Payments Account Management web site
• Amazon Simple Pay Integration Guide
• Amazon Web Services Customer Agreement
• Amazon Payments Acceptable Use Policy
• Service Health Dashboard

Collection of some useful jquery plugins

Some of useful jquery plugins I found. I have tested these plugins in IE6 and FireFox.

Datagrids

http://trirand.com/jqgrid/jqgrid.html

http://webplicity.net/flexigrid/

Animations

To animate your web page content flying from left and right Easy Slide demo

You want to flip your content? There you go

Chain your animation. Home Page demo

jTypeWriter gives a type writer effect with your text.

Effects

Gradient effect without images demo

Highlights text within the html

Charts and bars can be drawn with sparkline (need to test in ie)

A gradient effect on text (need to test in ie)

Menu

Fisheye

Picture Gallery

jquery-Fancyzoom

jqgalscroll-photo-gallery

image-slider-player-in-jquery and here is a demo

Rounded Corners

A nice api Home Demo

Really nice to have effect, liquid-canvas demo

jquery-roundcorners-canvas demo

jcorners

jquerycurvycorners

Local scroll

serialScroll nice scroller

jquerylocalscroll demos

jq-liscroll, automatically scrolls text horizontally.

The Silky Smooth Marquee demo, it is like list scroller

jscroller scrolls and show html. used for advertisement.

wslide (need to test in ie)

Facing Issues with migrating rails from 1.2.5 to 2.1.0

We identified some issues while porting one of our projects from rails 1.2.5 to 2.1.0

Rails removed some functions which were deprecated

This affected 3^rd party libraries as well as the application to be migrated. As a result we had to tweak some the libraries

Application was refactored

• rails 1.2.5 supported Project.find_all( :joins=>["…"], ...) which is now Project.find( :all, :joins=>"...", ...)
• render '/controller/action' has changed to, render :controller =>'controller', :action =>'action'

Some libraries are tweaked

• In-Place-Editing see

Regarding Migration

The way rails maintained migration information(latest migration) has changed. Rails 1.2.5 kept latest migration version that is synchronized with database in "schema_info" table. And now it stores in "schema_migrations" table.

" schema_info" has only one row keeping the latest migration synchronized with database. "schema_migrations" has entry for each migration that ran to synchronize the database.

So if we are migrating to rails 2.1 then we should run an insert script to create entries for each migration in "schema_migrations".

Faced problem with rake 0.8.3

We found that rake 0.8.3 creates problem in Linux, so we had to revert the rails version to 0.8.2. Rails 2.1.0 runs with rake 0.8.2.

Faced problem with ActiveMessaging

We faced some problem regarding ActiveMessaging. Here is a group discussion that might help. We fixed it by modifying support.rb in activemessaging according to the latest patch, can be found here

Rails 2.1.0 specifies default character set for database

Rails 2.1.0 sets utf-8 as default database encoding. So some expected result might misbehave.

Faced issues with folder based fixtures

Our project had lots of scenario while testing each controller or model. That is why we used folder based fixture so we can concentrate on particular fixture while testing particular model.

We defined fixture path like,

def fixture_path

File.join(File.dirname(__FILE__), "../fixtures/test_model")

end

It worked in rails 1.2.5. But it is misbehaving in rails 2.1.0. So we introduced scenario plugin to resolve that issue.

Template Pattern

Template pattern is all about encapsulating algorithm or process. It defines a skeleton of an algorithm with some abstract methods, which allows subclasses to redefine certain steps with out changing the algorithm structure. These abstract methods allow subclasses to be a part of the algorithm so that the pre defined algorithm can be reused.

Why Template:

1. Encapsulates algorithm or process, So that it can be reused.
2. Allows sub classes to be a part of the process, so this pattern is often seen in different frameworks.

How to use Template:

It is a common scenario that we need to authenticate and authorize an user before letting him to execute some secured facility. The user only gets to call the method if he is valid. Here the process sequence is the same. First check if he is valid and then let him execute the method depending on validation. We can encapsulate the process and create "hook up" or "plug in" abstract methods. The client sub class can implement the abstract methods and become part of the process. Here what varies is the logic to verify the user and eventually the logic to execute. So we let the client sub classes to define that part by implementing the abstract methods.

Class Diagram :

Java Code :

AbstractPage.cs

public abstract class AbstractPage {

   private String userName;

   public void setUserName(String userName) {
       this.userName = userName;
   }

   public void run() {
       //a simple process for validation
       //which is encapsulated in the template class
       if (isValid(userName)) {
           execute();
       }
   }
   //abstract hook up methods which is defined in sub classes

   public abstract boolean isValid(String name);

   public abstract void execute();
}

Page.cs 

public class Page extends AbstractPage {

   public boolean isValid(String name) {       //my code to validate user is in here      
       return true;//just a dummy return  
   }

   public void execute() {
       //my code to execute is here  
   }
}

TestTemplate.cs 

class TestTemplate {

   private AbstractPage abstractPage;

   public TestTemplate(AbstractPage abstractPage) {
       this.abstractPage = abstractPage;
   }

   public void runProcess() {
       abstractPage.execute();
   }
}

Object Oriented Principals used in Template : 

1. The Hollywood principle(don't call us, we'll call you)
2. Code to interface or abstraction not to concrete class.
3. High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.[Dependency Inversion Principal]

We see the Hollywood principle in this pattern because the client sub class is being used by the template class. The sub class is being called and becoming part of the process. And eventually the control belongs to the template class.

The template class is dependent on abstract methods which is later implemented by client sub classes. Template do not have any idea on concrete implementation, it is coded to abstraction. 

Dependency Inversion Principal is often used in deferent design patterns. In Template Pattern the high level class is the template class and the implementation is lower level class. Template class is not directly dependent on sub classes rather it is dependent on abstract methods or abstraction. And the client sub class is also dependent on the abstract template class. 

Observation : 

Object oriented pattern is all about encapsulation. Template is a trick to encapsulate process or algorithm, so that the process can be re used, which is achieved by inheritance. But one object oriented principal states that, "prefer composition over inheritance". In template we are using inheritance, which can be replaced by Strategy pattern. A template needs some feed or it needs to provide some hook up, which are achieved by abstract methods. These methods can be interfaced out of the abstract class of Template and convert inheritance in to composition. But it is always a design choice and context dependent decision.

Template is widely used in frameworks for it's ability to allow others to become a part of the system. Similar implementation is seen in Spring controllers, where the frameworks has the control and client controllers are plugged in the system by instantiating the abstract controllers. 

References : 

http://sourcemaking.com/design_patterns/template_method

Strategy Pattern

Strategy is one of the elegant design patterns which uses the polymorphism feature of object oriented language. This pattern allows you to change the strategy of how the class will behave at run time, so that your code can keep up with change.

Why "Strategy" :

1. Can change how the class will behave at run time
2. Makes your code reusable and extendable

First let's make a simple scenario that is appropriate for us to use Strategy Pattern. Suppose you need to write a simple copy function that copies a file from one place to another. The problem is that your boss wants to support different OS platform. You can say why need strategy I can write a simple code like,

public class FileCopier {

   public void copyFile(File source, File destination) {
       if (platform == windows) {
           copyWindowFile(source, destination);
       } else if (platform == linux) {
           copyLinuxFile(source, destination);
       }
   }

   public void copyWindowFile(File source, File destination) {
       //here is your windows copy code 
   }

   public void copyLinuxFile(File source, File destination) {
       //here is your Linux copy code 
   }
}

Now what if your boss tells you to add support for Mac OS. Then you will have to change the FileCopier class and re-test it. This surely will not make your boss happy as FileCopier is a very important class and people don't want it to change. One other thing is that change in FileCopier class to add support for Mac will also impact the software for other platforms, which is not desired.

One of the key feature of using real good object orientation is that it reduces change. And adding endless if-else block will make your code lengthy and fragile and you will also face the wrath of the other programmer who might have to change your code.

How to use "Strategy" :

Class Diagram:

Java Code:

IFileCopier.java:

public interface IFileCopier {
   void copyFile(File source, File destination);
}

WindowsFileCopier.java

public class WindowsFileCopier implements IFileCopier {

   public void copyFile(File source, File destination) {
       //copy file in Window machine
   }
}

LinuxFileCopier.java

public class LinuxFileCopier implements IFileCopier {

   public void copyFile(File source, File destination) {
       //copy file in Linux machine
   }
}

When IFileCopier is used in any context, it is coded using the interface IFileCopier. So it works for all the implementations of IFileCopier. When you will pass an instance of LinuxFileCopier it will have the behavior of copying file in Linux and an instance of WindowsFileCopier it will have the behavior of copying file in Windows. Now you can create another implementation of IFileCopier and pass the new implementation. As long as your implementation is OK the existing code will be OK : ). So here you are actually reducing the amount of change in existing code. So the amount of test is reduced and you can cope up with the change faster.

Object Oriented Principals used in Strategy :

1. Code to interface or abstraction not to concrete class. 2. High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.[Dependency Inversion Principal] 3. Single Responsibility Principal(SRP) 4. Encapsulate what varies from what stays the same 

We see the first principal in Context class as there we did code to interface(IFileCopier). Context is high level class and WindowsFileCopier or LinuxFileCopier is lower level class as Context uses them. But Context is actually dependent on an interface not to a concretion. So Strategy follows Dependency Inversion Principal. Single Responsibility Principal states that, "a class should have only one reason to change". In other words a class should do one thing and do it very well. Here we used this principal as we separated the OS dependant logic to separate class. So change in one part will not effect change in other parts. One other important thing is that we should identify parts that varies in a system. So that we could encapsulate what varies from what stays the same. Here we encapsulated the behavior to copy files, so that it could give us flexibility to re use it to support different OS platform. This will allow us to minimize change and maximize flexibility.

References:

http://sourcemaking.com/design_patterns/strategy http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/StrategyPattern.htm http://en.wikipedia.org/wiki/Strategy_pattern