Craig Wright, Satoshi, and Turing Completeness

I am only passingly familiar with Bitcoin technology, but I have been intrigued by recent claims that Craig Wright is the elusive Satoshi Nakamoto.  I was also intrigued last December, when the first claims came out.  At that time, I knew even less about Bitcoin  then I do now, and I knew nothing about the people who were involved in its creation.  But I watched this video,




and at around 17 minutes, I thought it was funny that "some guy" (who I now know is Nick Szabo, another Satoshi candidate - who denied it.) was arguing with "Satoshi".  Here is an approximate transcription at 16:34:

Architecture Viewpoints for Documenting Architectural Technical Debt

Introduction

Architecture Viewpoints for Documenting Architectural Technical Debt is a chapter in Economics-Driven Software Architecture.  The authors are Zengyang Li, Peng Liang, and Paris Avgeriou (LLA).  In this chapter, the authors propose a set of viewpoints which are meant to facilitate the documentation of architectural technical debt.  This blog post provides a summary and commentary.

There are three stated contributions for this work.  They are:

1. Identify architectural technical debt stakeholders and their concerns.
2. Propose their architecture viewpoints.
3. Provide evidence for the effectiveness of their viewpoints.

Following a common pattern for articles on technical debt, the authors begin by describing what they mean by their use of the term.  In this case technical debt is taken to mean the compromise of some quality attribute (QA) in exchange for a business advantages.  Quality attributes can include things like modularity, encapsulation, maintainability or evolvability.  Business advantages can include things like time to market and cost savings.  Architectural technical debt (ATD), specifically is when architectural decisions are made that incur or repay technical debt.  As seen in this work, architectural debt normally influences maintainability or evolvability.

Architectural Debt Viewpoints

Hello World

What is there to say about Cunningham's 1992 paper, Experience Report -- The Wycash Portfolio Management System, except that it started it all?  That's enough.  It is now impossible to write a paper (or blog) about technical debt that doesn't begin by citing Cunningham:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

With that short excerpt, Cunningham introduced three ideas with staying power.

1. "not quite right" code is like a form of debt.
2. Time spent maintaining this code is like a form of interest.
3. Technical debt can have positive or negative effects.  Negative effects can be crippling.

Over the years, not quite right code has evolved into not quite right technology, and this phenomenon developed the name technical debt.

It is interesting to see how interest in the concept has developed over time.  In A systematic mapping study on technical debt and its management, Zengyang Li, Paris Avgerioua, and Peng Liang provided this graph with the number of studies from 1992 through 2013.

Ad-blockers, firewalls, and anti-virus programs should be toll bridges

This is what happens to World Community Grid statistics when someone decides to monetize their computer processor cycles by mining cryptocurrency instead of donating the cycles.  After 11 years of donating CPU and electricity, I've begun playing around with nicehash.com to monetize those resources instead.  I'm not expecting to make any substantial earnings unless or until I buy some mining hardware, but it's a good way to start learning the ins and outs of bitcoin and other cryptocurrencies.  Almost certainly, I'm not the only one who's reallocating resources in this way.

Technology Review - Spritz: A Year and a Half Later.

In March, 2014, I first heard about Spritz and Rapid Serial Visual Presentation (RSVP) when I came across this article.

The reading game is about to change forever. Boston-based software developer Spritz has been in “stealth mode” for three years, tinkering with their program and leasing it out to different ebooks, apps, and other platforms.

Now, Spritz is about to go public with Samsung’s new line of wearable technology.

Product Review: Symform Cloud Backup

Interesting product: Symform Cloud Backup.

A couple of months ago, I figured that a product like this had to exist, so I Googled for “peer to peer RAID” and found Symform. According to Forbes, the product was created by two ex-Microsoft software engineers, and it is now owned by Quantum Corporation, a business with a long track record (for tech) and a fairly solid reputation.

I looked over the web page and thought it was interesting, so I decided to try it out. I’ve now been using it for free for a couple months and I have successfully used it to keep files synchronized between two PCs and the cloud, including copying files between the PCs, synchronizing files between PCs, and restoring deleted files.

Here’s how it works: