MultiBit Merchant: Genesis

June 6, 2012 | Comments
Tags: MBM


Back in October 2011, I decided to write an online shop. Several months on (at the time of writing) I’m still at it.

I’m not doing it because I want to enter the market that already exists. Just looking at Shopify, BigCommerce, and almost every hosting site there is, tells me that it’s ridiculously overcrowded already. I’m doing it because I have a particular itch to scratch.

I want to see how well I can put together a complex application when I have the following restrictions:

Each of those restrictions introduce some tricky, and therefore interesting, design considerations.

RESTful principles

Well that sounded easy enough – anyone who’s anyone is writing a RESTful API these days. What’s so hard about that? Well, let me tell you that writing a proper RESTful API is nowhere near as easy as you first think. I’ll discuss how I approached that in a later article.

MIT license

In short, the MIT license means that anyone can take your code and do whatever they want with it, subject to keeping a copyright notice for original author attribution. That essentially means that it would be unrealistic for me to sell this code because anyone can just make their own copy and compile it. On the other hand, it does mean that I can use it as a showcase for my own work that may interest future clients. Also, it means that anyone would be able to use this software to make their own online shop.

Since it’s all going to be out in the open, I can feel free to blog about my progress and can showcase good agile development techniques as well. This means making use of the best of breed tools for coding (Intellij IDEA), collaborative version control (git on GitHub), continuous integration (Jenkins), scalable deployment (yet to be determined).

When it comes to source control, I believe that nothing beats the power and simplicity of git.  As a result I made the choice to host the [MultiBit Merchant project repository][6] on GitHub. This will give it a wide audience and provide me with good tools to actually work with users and collaborators.

No commercial service

At first, this appears to be the most difficult restriction of all. Selling stuff through an online shop means taking payments online, and that means accepting credit cards. To do that means signing up to a payment gateway. Which leads to all kinds of additional compliance measures: Know Your Customer, PCI regulations, storage of personal data, restrictions on age and location of customers, restrictions on sales items, risk of chargebacks, transaction processing fees (how can a large transaction cost more to process than a small one?). The list goes on.

How can it be possible to meet this restriction? Enter Bitcoin.

For those that are unaware of it, Bitcoin provides an additional payment gateway that has the following features:

That’s good enough for me.

Must be Java

Java seems to suffer under the image of being a stuffy “enterprise” language these days. I could have gone for something else like Clojure, or Scala, but this would have introduced a fairly serious language learning curve. Learning a new language typically means following the “11-step algorithm” and the first few steps are usually quick to accomplish. However, learning the idioms takes a lot longer. I know that I can write a better application in Java than I can in Clojure right now, and that’s important for this project.

Still, Java is on the back foot when it comes to hosted services. In comparison to the number of hosting companies offering support for PHP, Ruby on Rails and Python the ones providing a Tomcat servlet container are few and far between. Is Java forever doomed to remain in the data centers of the large and powerful corporations, or are there alternatives? More about that in the next article which will discuss deployment issues and how they shape the design.

Must be part of a workable business

In short, I must “eat my own dog food”. I’m always on the lookout for new and interesting business opportunities, but I always seem to stop short of getting the business off the ground. Having a quick and easy way of getting a shop up and running to meet a particular need, without all the credit card hassle, would solve a particular problem that I have, and perhaps this would benefit everyone.

Experience has told me that it is essential that any software operating online must be secure by design. This is particularly important when applied to a Bitcoin shop since bitcoins are a frequent target for hackers in just the same way that credit card numbers and PayPal credentials are. Also an online business must be easy to look after since it won’t bring in much money to begin with and the owner must continue with their day job as they build it up. The more automation it can offer the easier it is for that person to build it up into something self-sustaining, and ultimately free them from their day job.

Where next?

So now that I’ve set out my store, so to speak, I am going to keep a blog of my progress. Hopefully, this will help other developers following a similar path for their own projects and maybe I can provide (and receive) some insight that helps make MultiBit Merchant useful.

You can read more about my progress by following the articles labelled with the “MBM” tag. Or jump straight to the next article now.

[6]: <a href=

Tweet

Related Posts

Useful? Consider a small donation: 1KzTSfqjF2iKCduwz59nv2uqh1W2JsTxZH

Got an opinion? Comments are welcome!

Want more? Take a look at the following:

MultiBit Merchant: Implementing HMAC authentication in Dropwizard
MultiBit Merchant: Cheaper in bitcoins
MultiBit Merchant: "Open the pod bay doors, HAL"
MultiBit Merchant: Deployment Driven Design?

comments powered by Disqus