Did this blog help you solve a problem? Tip me with Bitcoins at: 17dQktcAmU4urXz7tGk2sbuiCqykm3WLs6

Friday, August 2, 2013

How Bitcoin Works

I recently found one of the best technical explanations of Bitcoin and wanted to share...


Sunday, January 20, 2013

Unit Testing with HSQLDB

The latest release (2.0.0) of Yank - the Ultra-Light JDBC Persistance Layer for Java, finally contains unit-tested code. This blog is about how HSQLDB was used for performing in-memory unit tests using JUnit. Just like most things, once you know the few tricks, it's really easy.

Once nice feature of HSQLDB is that you can set up 100% in-memory tables, which makes unit testing a snap because you don't need to worry about having a database setup on the machine running the database. The following code snippets show how easy it was to setup a unit test for testing the core JDBC persistance layer code in Yank. While this is specific to Yank, this example should help you unit test any of your JDBC code using HSQLDB. After all, the main trick is to have your database properties setup correctly, as shown in HSQL_DB.properties below.

TestBooksTable.java

package com.xeiam.yank.unit;

import static org.hamcrest.CoreMatchers.equalTo;
import static org.hamcrest.MatcherAssert.assertThat;

import java.util.ArrayList;
import java.util.List;
import java.util.Properties;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

import com.xeiam.yank.DBConnectionManager;
import com.xeiam.yank.PropertiesUtils;
import com.xeiam.yank.demo.Book;
import com.xeiam.yank.demo.BooksDAO;

/**
 * @author timmolter
 */
public class TestBooksTable {

  @BeforeClass
  public static void setUpDB() {

    Properties dbProps = PropertiesUtils.getPropertiesFromClasspath("HSQL_DB.properties");
    Properties sqlProps = PropertiesUtils.getPropertiesFromClasspath("HSQL_SQL.properties");

    DBConnectionManager.INSTANCE.init(dbProps, sqlProps);
  }

  @AfterClass
  public static void tearDownDB() {

    DBConnectionManager.INSTANCE.release();
  }

  @Test
  public void testBooksTable() {

    BooksDAO.createBooksTable();

    Book book = new Book();
    book.setTitle("Cryptonomicon");
    book.setAuthor("Neal Stephenson");
    book.setPrice(23.99);
    int i = BooksDAO.insertBook(book);
    assertThat(i, equalTo(1));

    List<Book> books = new ArrayList<Book>();

    book = new Book();
    book.setTitle("Cryptonomicon");
    book.setAuthor("Neal Stephenson");
    book.setPrice(23.99);
    books.add(book);

    book = new Book();
    book.setTitle("Harry Potter");
    book.setAuthor("Joanne K. Rowling");
    book.setPrice(11.99);
    books.add(book);

    book = new Book();
    book.setTitle("Don Quijote");
    book.setAuthor("Cervantes");
    book.setPrice(21.99);
    books.add(book);

    int[] returnValue = BooksDAO.insertBatch(books);
    assertThat(returnValue.length, equalTo(3));

    List<Book> allBooks = BooksDAO.selectAllBooks();
    assertThat(allBooks.size(), equalTo(4));

    book = BooksDAO.selectBook("Cryptonomicon");
    assertThat(book.getPrice(), equalTo(23.99));

  }
}

HSQL_DB.properties

driverclassname=org.hsqldb.jdbcDriver

# 100% in memory DB
myconnectionpoolname.url=jdbc:hsqldb:mem:aname;shutdown=true
myconnectionpoolname.user=sa
myconnectionpoolname.password=
myconnectionpoolname.maxconn=10

HSQL_SQL.properties

BOOKS_CREATE_TABLE=CREATE TABLE Books (TITLE VARCHAR(42) NULL, AUTHOR VARCHAR(42) NULL, PRICE DECIMAL(10,2) NOT NULL)
BOOKS_SELECT_BY_TITLE=SELECT * FROM BOOKS WHERE TITLE = ?

Ultra-Light JDBC Persistance Layer

Yank is a very easy-to-use yet flexible Java persistence layer for JDBC-compatible databases build on top of org.apache.DBUtils. Yank wraps DBUtils, hiding the nitty-gritty Connection and ResultSet details behind a straight-forward proxy class: DBProxy. "Query" methods execute SELECT statements and return a List of POJOs. "Execute" methods execute INSERT, UPDATE, and DELETE (and more) statements.

Usage is very simple: define DB connectivity properties, create a DAO and POJO class, and execute queries.

Features

  • Depends on light-weight and robust DBUtils library
  • ~13KB Jar
  • Apache 2.0 license
  • Batch execute
  • Automatic POJO and POJO List querying
  • Works with any JDBC-compliant database
  • Write your own SQL statements
  • Optionally store SQL statements in a Properties file
  • Built-in Connection pool

What's Next?

Now go ahead and study some examples, download the thing and provide feedback.



Piece of Cake!!!

Thursday, January 17, 2013

XChange Release 1.3.0

Our Financial Exchange Library for Java, XChange, has seen a lot of active development since the previous release in October 2012. We went from 2 to 7 exchange implementations thanks mostly to the growing community starting to support the project more.

Here's a list of the supported exchanges. More detailed info can be found here, which includes planned future exchange implementations.
  • MtGox - polling and streaming market data, authenticated trading
  • Bitstamp - polling market data, authenticated trading
  • BTC-E - polling market data, authenticated trading
  • VirtEx - polling market data
  • CampBX - polling market data
  • BitcoinCharts - polling market data (Bitcoin Exchange Rates)
  • OpenExchangeRates - polling market data (Fiat Currency Exchange Rates)

Internally, we introduced a new and improved REST interface that sits between our xchange classes and the HttpTemplate class responsible for fetching JSON. It also gives XChange clients access to the raw unmarshalled JSON data if they want it, which was something XChange needed for a long time.

All exchange implementations have full-coverage unit tests.

We've been able to reduce the number of dependencies a lot. One of the main focuses of XChange is to be very lightweight. Most notably is the outdated org.json jar. We dug into the Socket.io code, and painstakingly swapped out the old code with our already-used Jackson JSON code. This is good news for apps like Bitcoinium and Multibit, which both use XChange, for keeping their executable footprint small.

Another major accomplishment with this release, is that the artifacts are now hosted on Maven Central: XChange artifacts on Maven Central

We're thinking about adding an arbitrage API within XChange next as the MtGox, BTC-E, and Bitstamp implementations all contain trading functionality.

Relevant Links

Detailed Exchange Support
Bug Reports and Feature Requests
XChange Home on xeiam.com
XChange artifacts on Maven Central
XChange project on Github

Monday, October 29, 2012

Unit Testing Runtime Exceptions with JUnit4 and Hamcrest

Junit and Hamcrest make unit testing with Java almost enjoyable. In this post, I show how to unit test Exceptions with JUnit4 and Hamcrest. In this over-simplified example, I'm testing a method that always throws an IllegalArgumentException. In real-life the IllegalArgumentException would only be thrown under special circumstances given certain arguments, and those are the ones you want to test with the unit test.

The basic idea is to surround the method you want to test with a try catch block and pass it an argument that will trigger the IllegalArgumentException to be thrown. The fail method call should never be reached, and if it does the unit test should fail. What should happen is that the IllegalArgumentException is caught, followed by a check for the correct message.

import static org.hamcrest.CoreMatchers.equalTo;
import static org.hamcrest.CoreMatchers.is;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.junit.Assert.fail;

import org.junit.Test;

/**
 * The following example code demonstrates how to unit test Exceptions with JUnit and Hamcrest
 */
public class ExceptionUnitTesting {

  @Test
  public void test() {

    try {
      blah("asdf");
      fail("Expected exception");
    } catch (IllegalArgumentException e) {
      assertThat(e.getMessage(), is(equalTo("Argument foo is not valid!")));
    }
  }

  /**
   * @param foo
   * @throws IllegalArgumentException - in this test case always
   */
  private void blah(String foo) {

    throw new IllegalArgumentException("Argument foo is not valid!");
  }
}


Piece of Cake!!!

Monday, October 1, 2012

Import a Maven Git Project Into Eclipse

The Easy Way


Prerequisites
Install M2Eclipse

Step 1: Clone or create Git Repo. First, you need to clone a Git repo into an empty folder in your workspace. You need to use a Git client such as SourceTree or TortoiseGit for this. Create you workspace first if it isn't already, and clone the git repo directly into a new folder labeled with the project name.

Step 2: Import Into Eclipse. In the Package Explorer view, right-click and choose Import... In the wizard choose Maven -> "Existing Maven Projects" as the project type. Search for the project home directory and click though the wizard.

The Hard Way


Prerequisites
Install M2Eclipse
Install egit

Step 1: Right-click in the Package Explorer area and select Import..., select Maven -> Check out Maven Projects from SCM, and click Next.


Step 2: Choose "git" as the SCM connector next to "SCM URL:" and type in the Git repo URL. If there are no connectors to choose from you have to first install that Eclipse plugin. To do that, click on the "m2e Marketplace" link in the lower right hand corner of the dialog box.


Step 3: Check m2e-egit and click Finish.


Step 4: Select "git" as the SCM connector and type in the Git repo URL.


Step 5: After asking you for the passphrase for ssh access to the Git repo, it will download and import the Java project as a Maven project into your workspace.

Piece of Cake!!!