.NET Garbage Collection

blog garbageIn an unmanaged runtime, such as C or C++, you allocate and free up memory for your application through code. A managed runtime, on the other hand, typically has a process governor that manages memory for your application so that you don’t have to. The mechanism that does this is usually referred to as the garbage collector. The .NET runtime has a configurable garbage collector that usually does just fine without software developers caring very much about it. Normally, it just works and does a very good job of managing memory for your app. It can be important, however, to understand how the garbage collector works at times, even if you never need to change the way it operates.

.NET Garbage Collection Basics

The garbage collector is invoked by the runtime to clean up unused memory and defragment the heap generally whenever the application feels pressure to do so. While you can request that garbage collection happen at specific points in your app, you cannot explicitly start garbage collection yourself. And, that being said, it is generally frowned upon to make calls to GC.Collect(). Read more

Using Continuous Delivery for Our Online Payment Gateway

edited quoteOver the last few months at Clearent we’ve been rolling out new features like crazy, and have launched a handful of exciting new products to our online payment gateway. But, with the pace at which we’re developing new technology, we’re realizing one of our biggest pain points–our release process. We often look to the industry leaders to seek guidance, and one of the software development leaders that we look to is Martin Fowler. His favorite soundbite is “if it hurts, do it more often.” It essentially means to do painful things more frequently so that they eventually become less painful. What we needed was a way to reduce the pain associated with releases. So we’ve made big strides towards implementing continuous delivery for our development team.

What is continuous delivery?

As we’ve been building out our online payment gateway, we’ve been talking about this topic a lot. The basic concept is that every time a developer commits a new feature to our codebase, we take that and create a deliverable product. We want to automate our process of building our code, running our tests, staging our environments, and promoting our products to our higher environments. Read more

EMV: A Multitude of Payment Solutions

Clearent Payments API

What is EMV?  EMV, by definition, “is a global standard for credit and debit payment cards based on chip card technology taking its name from the card brands Europay, MasterCard, and Visa – the original card brands that developed it.” That definition doesn’t tell us much. Most of us understand EMV to mean chip cards that can be inserted into a slot in the payment terminal. Chip cards allow additional verification to prevent fraud in card-present transactions. They are much harder to copy than the traditional magstripe.  They also have additional verification built into each transaction so that each use can’t be reused, like magstripes can be.

EMV has disrupted the industry because as of October 2016 the Card Brands (MasterCard, Visa, Discover and Amex) have required their merchants to either accept EMV chip cards, or be responsible for additional fraud liability. This has been referred to as the liability shift. This liability shift has rattled the payments industry. It’s the first time in years that U.S. merchants will be forced to upgrade their point-of-sale (POS) equipment and terminals. Vendors of terminals are scrambling to support the technology and grab more market share; merchants that are forced to buy new equipment start looking at new vendors. Read more

Using Feature Switches for Code

Code

Using feature switches fore code development is a technique used by software developers or DevOps professionals to turn portions of code on or off without requiring a rebuild of the application.  There can be many reasons for using this technique. Often, a feature may need to be released but is in the same build as a feature that cannot be released.  In other cases important code releases require customer notification that may not have happened yet.  Releasing the code with the ability to turn certain features off can clear it as a work item for the IT team while leaving the business with the flexibility to release the feature at a later date.

Feature switches for the Clearent back end development team typically come in two parts: a configuration setting indicating the state of the feature and a dependency swap or IF statement to switch the behavior out based on the configuration setting.  Here is a simple example of what a feature switch could look like:

Read more

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

Switching to Distributed Version Control

Distributed Version Control

One of the best parts of being a developer at Clearent is being part of a culture of constant improvement and growth. This culture allows us to consistently improve our payments platform and the products we as developers create for other developers to accept payments. We are not a company that refuses to change simply because “that’s the way we’ve always done it”. Every day is an opportunity to try something new, whether it’s a new framework, a new platform, or a new toolkit. All of this, in the name of creating the best possible payments platform.

A couple years ago, we decided to make the transition from a centralized version control system (subversion) to a distributed version control system (git).  And in that transition was a real opportunity to change the way we use source control.

We started with three assumptions:

  1. Branches are Cheap
  2. Merges are Easy
  3. Conflicts are Rare

If you have only used centralized version control systems (VCS), those first two assumptions sound crazy.  Most of the popular centralized VCSs are either incredibly slow to branch or make it very difficult to manage to multiple branches. We had actually built our own internal tool to help us manage merging our long-lived development branch into our testing and release branches. Version control systems are supposed to be a tool that helps developers do their jobs, but for us it almost more of an obstacle.

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

Succeeding with Failure for Developers

Clearent Developers Failure to Succeed

Developers hope (and pray) that when facing system application failure it does so in a predictable and recognizable way.  Nobody wants to get the 3 a.m. phone call from a sysadmin saying that a core process failed and reported an “unknown error.”  As Clearent has grown we have learned a few things about failure.  We’ve also had to rethink what failure means and how we adapt to the unexpected.  We are continually learning, so I can’t provide a definitive guide on how to write fault-tolerant systems but here are a few things we’ve learned along the way.

Logging

Have a top-level exception handler that logs any error that causes your application to fail.  Hopefully it is never exercised but nobody wants an application that fails and doesn’t say why.  This can get tricky as processes spawn threads, so be aware that it may not always be near the entry point of your application.

Take advantage of logging levels to throttle the amount of data you emit.  Most logging frameworks have the ability to write out messages at levels such as Debug, Info, Warn, Error, or Fatal.  When the going gets tough in production your operations staff can make the logging more verbose to gain insights into what the application is doing.  When everything is operating normally it can be turned back down again without requiring development time to add and remove logging.
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