Representational state transfer (REST) is a very popular architecture for distributed hypermedia. Lots of different web services expose their APIs in a RESTful manner. It is very convenient when a service of a choice provides a library for its API, but this is not always so. In this case you have to construct valid requests and parse responses by yourself. Assuming that you are familiar with REST itself, I will tell you how you can make your life easier with the help of Spring and Java annotations.
Unlike Java, which mixes primitive and reference types, Groovy handles everything in common manner — as objects, what makes it truly object-oriented. When a primitive type gets passed into the Groovy world, it is automatically “boxed” into its object equivalent, and vice versa. This allows Groovy to support some interesting concepts like methods on primitives, operator overloading and The Groovy Truth. Let’s look at them more closely.
Hudson is an excellent continuous integration tool and has become an indispensable assistant in software quality control for many organisations. As for this post I will describe how to couple Hudson and Grails to work in effective synergy.
Concurrent programs is not a novelty today, almost every modern application executes in multiple threads. But as concurrency brought us better resource utilization and throughput, it also introduced a number of issues nonexistent in serial execution. One of them is deadlocks. A deadlock is a situation where in two or more competing actions are each waiting for the other to finish, and thus neither ever does.
An immutable object is one whose state cannot be changed after construction. All the beauty in these objects is that they are simple and safe. In multi-threaded applications all concurrency issues boil down to coordinating access to mutable state. The less mutable state, the easier it is to ensure thread safety. That’s why you should always consider making your objects immutable whenever it is feasible. Creating an immutable type is not a complex process, but you should follow a handful of rules to stay away from pitfalls it definitely implies.
In the world of mathematics real numbers have infinite precision and are therefore continuous and nonlossy. Floating-point numbers, which are used in computing, are limited with a finite precision and are not evenly spaced throughout their range. If don't keep this in mind you can get into many numerical blunders.
In the previous post I’ve told how to bill a customer with a minimal fuss. But oftentimes returning customers wish to add or change their billing information or maybe you want to delete the old ones. Let’s dive deeper and see what’s possible to do with Authorize.Net Customer Information Manager by remote procedure calls using, as previously, Java SDK.
JIRA is a popular issue tracking and project management software. It can be used and accessed by lots of different means like IDE, email client or a web browser. Also there are many plug-ins for all sorts of other software products. Such an abundance is explained by the fact that JIRA has open and convenient remote procedure call APIs: REST, XML-RPC and SOAP.
So, it is possible to make your application communicate with JIRA through these APIs, too. If correctly integrate a Java API client, issuing a command to JIRA becomes the same as invoking a local subroutine. Let’s create such a little Java program and do some manipulations with an Issue in JIRA.
Authorize.Net is a popular payment gateway service provider allowing merchants to accept credit card and electronic check payments.
Using such a gateway to issue a one-time transactions doesn't raise any great troubles, but serving returning customers or managing complex subscriptions requires you either to be compliant with the Payment Card Industry Data Security Standard (PCI DSS) or to ask your customer to re-enter his or her billing info every time. Neither is always what you want. Well, among other Authorize's features there is a Customer Information Manager (CIM), which targets that particular problem.