Will's Blog

Cloud technology has slowly crept its way into nearly every aspect of our digital lives. And why not? It's convenient and easy to use, nothing to install or configure, and it's often free. Email clients are a great example of this. People used to live out of Microsoft Outlook or Lotus Notes , today all you need is a web browser. This starts becoming a problem when you consider your privacy. By using these services, especially the ones that don't cost money, the price is your private information. Consider your family photos and facial recognition, are you comfortable with Google knowing exactly who you associate with? What about your private documents? Even passwords are moving to the cloud with services like LastPass and 1Password ! Another consideration is whether the service will exist in the future. If you keep notes on the cloud, how upset would you be if that service was shutdown? If you don't run it yourself you're beholden to the company providing the servi

After a bit of searching I was unable to find an off the shelf solution to let me browse S3 with a JFileChooser . The closest I found was an S3 FileSystem implementation, but that doesn't seem to be used by JFileChooser. Instead you need a custom FileSystemView , which I implemented using minio as a simple client library. The code is not incredibly complicated so I wont explain it in detail. You can see that the custom S3FileSystemView is simply passed to JFileChooser to insert the S3 logic. The most interesting method is getFiles , that is where I decided to insert the buckets at the top level, so there is one switch which decides whether to call listBuckets or  listObjects . From that point my custom VirtualFile objects are carefully constructed so that the File class plays nicely with JFileChooser. The result from selecting a file is something like s3:/bucket/path/to/file.txt  which you will need to download yourself.  VirtualFile  could probably be extended to work lik

We left off with an immutable data structure storing arbitrary data, you can read about that in part one , or you can view the introduction to this series here . As always,  the companion code for this post can be found on GitHub. In this post, we'll introduce transactions which are the primary feature needed to convert that data into a currency. Although a transaction simply needs to subtract coins from one account and add them to another, the way this is implemented in a blockchain is a little unusual. We'll cover all these details and more during this article before implementing them in the LynxCoin project. This is what we'll be working towards today. The first thing you need to understand about currencies stored on a blockchain is that there is no concept of a balance. Instead, you hold rights to transactions. Specifically, if you received a transaction for 50 LynxCoins, you now have the right to spend them. Our updated block looks like this.

This is the first post in a series building a cryptocurrency from scratch, the series introduction can be found here . Every day new developers are learning just how simple blockchain technologies are. One of the first things you may notice is that the collection of algorithms are profoundly clever , but the mechanics of creating a verifiably immutable chain of data is borderline trivial. If you need proof, take a look at how many introductory  blog posts are building a toy blockchain . These all include working implementations of a blockchain. One good reason to implement your own is to prove to yourself just how trivial the data structure is. Certainly, my first reaction to reading up on bitcoins block header was: is this all? Of course, the answer is no. Creating a blockchain is table-stakes, and from there a series of clever algorithms allow transactions to occur without a central authority. But this structure is the heart of all that follows, so building a blockchain is

In this series of blog posts, the concepts needed to understand and implement the fundamentals of blockchain and cryptocurrency technologies will be introduced. During each post a new cryptocurrency concept will be introduced, then the technical details will be implemented as a practical demonstration of how they work. The currency will be implemented with Kotlin, which I've found to be expressive while maintaining readability. Future iterations of this project may include alternate implementations in other languages. This series will be broken into several parts: Data Structure Currency and Transactions Decentralization and Mining Optimization: Merkle Trees Data Structure An introduction to the mechanisms that allow us to verify that data in the chain has not been tampered with. We'll begin with a high-level explanation of how it works and move onto a succinct implementation which will serve as a stepping stone for the following posts. Currency and Transacti

If you regularly work with REST endpoints you're probably used to a lot of tedium. Between carefully constructing the parameters, encoding data in just the right format, efficiently sending the requests, parsing the results and handling errors at every step along the way; there is a lot of room to make mistakes. For simple APIs, it often makes sense to manually format the request and send it out. Checking a status code, and maybe mapping results to an object aren't that big a deal for a simple API. But what if there are 20 different endpoints? Or you need to manage authorization headers? Eventually, it makes sense to start looking for a wrapper library, or maybe making your own wrapper layer. That's what this post is about. For JVM developers, pairing Kotlin, Retrofit2 and Gson make it easy to bang out a type-safe client wrapper. Let us jump right into the code: // Create data classes for serializing inputs and outputs. data class Results < out T>(