Posts

Why We Use TDD

Love Test Drive Development

Ever since I started working as a developer for Clearent, I’ve been an adamant supporter of Test Driven Development (TDD).  I adopted this development practice a very long time ago and have seen its benefits over and over again.

What is TDD?

Test Driven Development is a coding practice where a developer writes a failing unit test before writing the production code to make the test pass.  Ideally, the unit test is built up slowly, adding a failing test condition that drives the next incremental feature in the code being created.  (We achieve this incremental build-up by practicing a coding pattern called red-green-refactor.)  The design of the code is “discovered” as the test is built-out, and the end product is a well-designed piece of functioning code.  A by-product of this practice is a unit test that can be repeatedly run to ensure future changes don’t break the existing code base.
Read more

Integrating Payments into a Spring Boot Service

RESTful Interface Flow

This is a quick tutorial showing how easy it is to integrate with Clearent’s secure payments gateway. Clearent has designed a language agnostic RESTful online payments gateway, meaning developers of almost any language should be able to start processing with Clearent.

Today we’ll be using Spring Boot and a handful of other libraries to get a payments service up and running fast. Spring Boot provides an opinionated implementation of the Spring framework in an embedded JAR file. We’ve been using it internally here at Clearent for over a year now, and has reduced our development time and has provided quick integration with thousands of popular libraries and tools. We’re going to assume some basic familiarity with Spring Boot, but if you’d like an introduction, Spring’s Tutorial on Building REST Services demonstrates all of the topics covered in this post.

Read more

Working Toward Continuous Delivery

continuous delivery

One of the biggest difficulties in software development is deployment.  Figuring out how to package an application, transfer it around, install it, etc. has been a challenge from the dawn of programming.  Continuous delivery is a term used to describe an environment where software flows from a developer into production, through all of the necessary gates, with minimal manual work.  Clearent has always worked to simplify the software deployment process so that we can deliver new features to our customers quickly and efficiently with minimal disruption.  As the underlying technology stack evolves, we are able to move toward a true automated continuous delivery system.

 

Software is typically difficult to release.  The process flow is generally:

  1. A developer creates or makes changes to a piece of software and tests it on a local system.
  2. The software is moved to an integration system to ensure it works with the rest of the software available.
  3. The software is moved into an environment where quality assurance testing can be performed.
  4. The tested software is moved into the production environment.

Read more

10 Common Mistakes in Web Development

 Web-Development

10 Common Mistakes in Web Development

Carl Armbruster

Senior Software Engineer, Clearent LLC.

I began my web development career in 2001. Back then FrontPage was still a thing (although no one actually liked it), websites used “mystery-meat” flash navigation and someone everyone though a splash screen for your website was a good idea. A lot has changed but I still see too many common mistakes web developers make. Here are 10 of the most common mistakes I have noticed when browsing the web and in my own work experience.

Trying to make your company website the next social media sensation

I get it . . . we all have big egos. You are really proud of your bookstore (café, clothing store, candle shop, etc.) – and you should be! It takes a lot of effort to run your business. But your customers generally come to your website for information, not to hang out. You are not Facebook (unless you work on Facebook’s website in which case you are Facebook). Stop it with the animations. Quit with the music automatically playing in the background. Stop making me register just to browse your website.

Not eating your own dog-food

Read more

Distributed Systems for Clearent Payments

Distributed systems is an area of computing that attempts to address the problems some companies have with scaling computer resources once they grow beyond what one machine can handle.  Issues of scale can appear when the number of users, amount of data, or computation requirements grows to a level in which one machine, however large, is incapable of meeting service demands.  For some companies, the amount of data that is required to be online and accessible for reporting or research is so massive that a single database or filesystem cannot store it.  Other companies that handle requests on-demand from users via an API or hosted service find that the number of requests made within a period of time has grown to a point where the system cannot react to every request in a timely fashion.   Computation in some industries can be so large or intense that if one machine is asked to perform it would take so long that the results of the computation are irrelevant by the time it is complete.

 

At Clearent we use techniques from distributed systems to help level out the time it takes to process batch transactions as our merchant base grows.  Our backend system receives transactions numerous times each day in large data dumps.  Our desire to help merchants get their funds the next day and strict bank funding windows puts pressure on our system to qualify, bill, and settle all transactions within limited timeframes despite the fact that our transaction volume continually increases.  We therefore parallelize the processing of transactions across a network of machines, configured to coordinate and ensure exactly-once transaction processing.  In the event that our system cannot meet the timeliness demands of our partners we can add new processing nodes to bring the completion time back down to acceptable levels.

Read more

Development Goodness

Developer Pie

Aptitude + Attitude + TDD + Pairs = Software Development Goodness

Hi my name is Mark Sundt and I’m the Chief Technology Officer of the credit card processor Clearent. I’ve been in this role for the last two and half years and have been lucky enough to be in an industry that is undergoing incredible changes and with it new and exciting opportunities.

During my tenure here at Clearent, I’ve had a fairly simple job philosophy / mantra. I really believe my job boils down to focusing on three general things; People, Process and Technology. I’ll talk about technology and process in a future blog post. Right now I would like to briefly discuss what I think makes Clearent one of the greatest places I’ve ever had the opportunity to work, and that’s the people I am fortune enough to work with every day!

Read more

Understanding DNX

Getting a handle on the new .NET Execution Environment (DNX) is difficult. I’ve been following the project for a while, and still get twisted around trying to explain it to other developers. I believe the following analogy and diagram help to understand the environment.

Keep in mind, this is a tenuous comparison meant to help people understand the environment. It is not a comparison of the technologies in question.

I often compare DNX and its ecosystem to the MEAN development stack (MongoDB, ExpressJS, AngularJS, and NodeJS). This development stack consists of a runtime environment (NodeJS) that hosts a framework for creating server-side applications (ExpressJS). These server-side applications can be accessed using client-side frameworks such as AngularJS. The entire stack can be backed with MongoDB for permanent storage.

The DNX environment is similar, but much richer. DNX is the runtime environment, much like NodeJS is for the MEAN stack. MVC can be used to create an API (formerly WebAPI*) that runs on the server in DNX, much like ExpressJS is used in the MEAN stack. The client-side component can still be AngularJS that calls the API. This is where the comparison ends.

Read more

Why Clearent Developers Went With Angularjs

It’s 2:00 am and the dog woke me up about a 1/2 hour ago to go to the bathroom. How is it that I can go from being dead asleep to wide awake because of a simple walk downstairs. So while the dog is already back in bed passed out, I’m left to my thoughts. Unsurprisingly, I find myself thinking about our new Virtual Terminal product.

I’m not sure why it popped into my head at this hour, but it was an interesting project for us. We wanted to build a mobile first client that used our public API’s to run transactions, view transaction history, batch history, and more.  Surely if we expected our clients to use our API’s to write rich POS and payment apps, we should be able to write one using the public API’s too, no cheating. If we need additional functionality we would make that public for our client as well.

Naturally as a band of self-proclaimed back-end developers we wanted to avoid JavaScript as much as possible.  I mean seriously dealing with the browser compatibility issues and the quirkiness of JavaScript’s undefined errors did not sound appealing at all to myself or the members of my team.  Having worked at various large corporations throughout my career, I had successfully avoided any difficult JavaScript solutions by passing off that front-end headache to front-end developers, and I was more than happy to do so. I wanted to focus on security, testing, and other concepts that interested me.

Read more

Reflections on Strange Loop and Clearent

Strange Loop Conference

Reflections on Strange Loop 2015:  3 Topics relevant to Clearent’s Payment Processing systems.

 

2015 was my first Strange Loop conference.  Many interesting presentations were given on topics ranging from tech activism, to functional programming – and everything in between!  However, three topics were particularly relevant to our present work at Clearent: microservice architecture, distributed systems, and container based virtualization.

Many of us have experienced the challenges of developing or maintaining large, tightly coupled, monolithic applications.  As an alternative to a monolithic approach, Clearent relies on a microservice architecture for much of its payment processing infrastructure.  Our Gateway, Vault, and Virtual Terminal are all microservices – running independently of each other. Martin Fowler’s article (http://martinfowler.com/articles/microservices.html) nicely describes the microservice architecture and some of the pros and cons when comparing with alternative approaches.

Read more