Accepting Bitcoin with BitPay
End Point recently began discussions with long-time Interchange client FrozenCPU about their desire to accept bitcoin payments. Because of the newness of bitcoin, as well as its non-traditional nature as a cryptocurrency, traditional payment gateways do not support it. While ideally suited to function as an exchange medium for ecommerce, we had to seek solutions that allowed for its integration into the checkout process.
BitPay Payment Gateway
After investigating their options, FrozenCPU elected to partner with BitPay to handle bitcoin payments. BitPay provides merchants with a solution similar in function to PayPal, where users are either redirected to the BitPay servers to complete payment, or the interaction with BitPay can be embedded directly into the merchant site via an iframe. In either case, all communication between customer and payment processor is direct.
Customers with a digital wallet then approve a transfer for the converted amount of bitcoin. Merchants need not display or maintain conversion rates; they can continue to use their native currency and BitPay will manage the exchange rate directly.
The payment negotiation is managed by the creation of an invoice which …
cryptocurrency ecommerce interchange payments
More jQuery confusion: hidden, disabled fields
As you may have read in my earlier post, I have a proclivity for stumbling into oddball bits of jQuery behavior. (Maybe it’s not just me.)
Here’s another I discovered recently. I was debugging an odd AJAX bug in a form, one of those dynamically updating form widgets in a page:
<select name="make">...</select>
<select name="model">...</select>
where the first selector sends off an AJAX query to retrieve data to fill the second selector, and it in turn fires off a query to get data for the next, and so on down the line.
Squirreled away in the form was:
<input type="hidden" name="limitation" disabled="disabled" value="">
Supposedly, this input was filled in to restrict the query on some pages, but not all. I think the original author’s intent was to put data in here as it became available, and to toggle the field’s disabled setting when it was pertinent to limit the query. (Mostly, it was pertinent when the second or third selector was firing off its AJAX query.)
However, a recent change to the code behind this AJAX query created a bug, because the “limitation” parameter was showing up where it wasn’t …
javascript jquery
Python decorator basics, part II
This is a continuation of my previous post: Python decorator basics. Here I’ll talk about a decorator with optional arguments. Let’s say we want to pass an optional argument to the same debug decorator:
def debug(msg=None):
def actual_decorator(f):
def wrapper(*args):
if msg:
print msg
return f(*args)
return wrapper
return actual_decorator
@debug("Let's multiply!")
def mul(x, y):
return x*y
Calling mul:
mul(5, 2)
Let's multiply!
10
Excellent. Now let’s decorate without a msg and call mul:
@debug
def mul(x, y):
return x*y
mul(5, 2)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: actual_decorator() takes exactly 1 argument (2 given)
</module></stdin>
Oh oh. Let’s see what happens at time of decoration:
mul = debug(mul)
Hmmm, mul gets passed to debug as it’s argument and then the arguments (5, 2) are passed to actual_decorator, since debug returns actual_decorator. To resolve this we need to always call the decorator as a function:
@debug()
def mul(x, y):
return x*y
mul(5, 2)
10
Assuming that we always expect the msg …
python
DBD::Pg 3.0.0 and the utf8 flag
One of the major changes in the recently released 3.0 version of DBD::Pg (the Perl driver for PostgreSQL) was the handling of UTF-8 strings. Previously, you had to make sure to always set the mysterious “pg_enable_utf8” attribute. Now, everything should simply work as expected without any adjustments.
When using an older DBD::Pg (version 2.x), any data coming back from the database was treated as a plain old string. Perl strings have an internal flag called “utf8” that tells Perl that the string should be treated as containing UTF-8. The only way to get this flag turned on was to set the pg_enable_utf8 attribute to true before fetching your data from the database. When this flag was on, each returned string was scanned for high bit characters, and if found, the utf8 flag was set on the string. The Postgres server_encoding and client_encoding values were never consulted, so this one attribute was the only knob available. Here is a sample program we will use to examine the returned strings. The handy Data::Peek module will help us see if the string has the utf8 flag enabled.
#!perl
use strict;
use warnings;
use utf8;
use charnames ':full';
use DBI;
use Data::Peek;
use lib …
dbdpg perl postgres unicode
A Git and symlink mistake
A couple of times, I’ve accidentally created an infinite symlink loop and lost files from that directory from a single Git commit. Here’s how it happened:
- First, on the production app, images tied to products in a database were uploaded to the server. Let’s say I was working on a Rails app, so these images were uploaded to the RAILS_ROOT/public/system/ directory. I added “public/system/” to my .gitignore file, and all appeared to be good.
- Next on a camps instance, I created a symlink from CAMP_ROOT/public/system pointing to the production app public/system directory. This is common practice in End Point’s camps setup because we often don’t need the redundancy of uploaded files on our dev camp instance, and we don’t want the extra disk space used up for these types of files. The make camp script is designed to allow a user to toggle symlink functionality on and off for various directories during the make camp process.
- Next, I accidentally committed and push the public/system symlink from my development instance.
- Finally, I pulled the commit onto my production instance. The pull resulted in public/system symlinking to itself, and all of the files vanished (poof). Since they were …
git linux
Java Web app error: “Your security settings have blocked a self-signed application from running”
There’s a growing number people complaining that Java does not seem secure enough and that they feel vulnerable every time they open (and confirm to “Trust”) Java Web applications.
Since after the last update Java had at the end of January, this shouldn’t be a problem anymore as you can read in the Java Changelog for the latest release there has been many efforts toward making “the Web” a safer place for everyone.
Unfortunately is also quite known that security and usability often fight one against each other, so it’s fairly possible that after installing the last Java Update and when trying to use Web Apps that worked until a few minutes earlier, you found yourselves facing the following error: “Your security settings have blocked a self-signed application from running”.
What happened is that Oracle changed the behavior your Java browser plugin will have when dealing with self signed Web applications by actually denying the execution of those since considered harmful by default.
In order to fix this situation you’ll need to launch the command jcontrol. Most Linux distributions will install it under /usr/bin/jcontrol while others will place that binary in different places, as an …
java linux security update
Spree Active Shipping Gem “We are unable to calculate shipping rates for the selected items.” Error
I was recently working on a Spree site and setting up the Spree Active Shipping Gem along with the UPS API. For those not familiar, the Spree Active Shipping Gem interacts with various shipping APIs like UPS, USPS, and FedEx. Due to the nature of Spree—where it does so much for you, and the interaction between the Active Shipping Gem and a shipping API also being “auto-magic”, it is often difficult to debug. As I was recently undertaking the task of setting this up I found a few “gotchas” that I hope, through this blog post, may be able to save others a lot of time.
I have found that there wasn’t a lot of instruction for setting up the Active Shipping Gem and a shipping carrier API like the UPS Shipping API. Ostensibly, there isn’t much to it—the Active Shipping Gem handles much of the interaction between the shipping API of choice and Spree.
First, you’re going to go the Spree Active Shipping Gem GitHub repo and follow the instructions for installing the Active Shipping Gem. It is very straightforward, but do proceed in the order mentioned in the Spree Active Shipping Gem documentation as some steps depend on the successful completion of others.
Second, you’re going to go to the …
ecommerce api rails shipping spree
A Brief Retrospective of Spree
SpreeConf NYC 2014 starts on the 26th and its hard to believe that Spree is almost 7 years old! Here’s a retrospective showing some notable Spree moments and major releases.
July 15, 2007 RailsCart, the precursor to Spree, is created by Sean Schofield and gets its first commit as a Google Code project.
February 1, 2008 Sean is hired by End Point Corporation to work on RailsCart along with its other Rails developers. End Point sponsors Spree for the next year and a half.
February 15, 2008 RailsCart project moves from Google Code to GitHub and is renamed Spree.
June 1, 2008 Spree 0.0.9 released: sophisticated data model for inventory.
June 3, 2008 Product Properties added.
June 5, 2008 Spree 0.2.0 released: adds Spree extensions.
July 4, 2008 Zones introduced.
Sept 8, 2008 Refactored to REST routing added state machine to order.
October 1, 2008 New Taxonomy system introduced.
October 2, 2008 Spree 0.4.0 released: Taxonomy, and VAT-inclusive pricing.
November 26, 2008 Volume pricing introduced as an extension.
November 24, 2008 Spree 0.5.0 released: new shipping framework.
December 3, 2008 SEO friendly URLs.
December 4, 2008 Switched from attachment_fu to paperclip for image …
ecommerce rails spree open-source