A Spike To Learn Blockchain App programming

The goal

Spend 3 hours working thru any free resources I find online to get my feet wet with zero preparation in programming a blockchain app

Guidance chosen

An article on Building a Blockchain DApp using truffle, React, Next.js and MobX that two minutes of Google led me to and that looked promising to leverage my learnings thru recent paid work in React and Mobx-State-Tree because it mentioned React and Mobx in the title (see Retro for how much of a good guess this was).

Errata and my notes on the article

Think of this like Snape’s notes on the Advanced Potions book, except I don’t think I’m a Half-Blood Prince, just someone who used the article as guidance prior to you who’s reading it and worked thru the kinks and gotchas.

First I used my Macbook to do this, so with Homebrew and NVM i ensure I was on the latest version of node and using the 7.10.0 of npm

brew install nvm

nvm use 7.10.0

npm i -g yarn

Notes on the guide:

  1. The URL. Change the line

    git clone git@github.com:liors/tvdapp.git


    git clone https://github.com/liors/tvdapp.git

    since either there was an error in the command or the Wifi network I was on was blocking ssh connections.

  2. Run

    yarn install

    If it kicks an error like it did for me that

    The engine “node” is incompatible with this module.  

    Expected version “7.10.0”.

    error Found incompatible module

    Then go back to the terminal console and run

    node -v

    and if it isn’t listing 7.10.0 follow again the step above to use nvm to install and use that version as the compilation is still using the newer node version so is creating this error.

  3. Opening the folder in Visual Studio Code and opening “Bookmark.sol” file in VSCode, it offered a few recommendations for a code/syntax highlighter for solidity, the contract-oriented programming language used here, so I went with the most downloaded one.
  4. At this point I took the recommendation of the article here of reading the docs with regards to solidarity to get a better grasp of what’s happening here. I’d backup this recommendation to future readers as well.
  5. The article then goes into running the tests, a requirement of which is having “a local instance of testrpc” but it falls short of saying how to go about doing this which also led to me first having to follow these steps to install go-ethereum for a Mac. Fun times.
  6. In the steps for setting up a local instance of testrpc that I referenced, the command to execute

    geth –datadir=”/tmp/eth/60/01″ -verbosity 6 –ipcdisable –port 30301 –rpcport 8101 console 2>> /tmp/eth/60/01.lo

    required that i first create execute

    mkdir /tmp/eth

    mkdir /tmp/eth/60

    to create the /tmp/eth/ and /tmp/eth/60 folders before it would successfully execute.

  7. Run


    to get the Ethereum TestRPC client up and running and then as per the article execute

    yarn test

    and all tests should now successfully pass.


So that was quite a bit for just part 1 of the article. Haven’t even gotten to the stuff I wanted to leverage my knowledge of (React, Mobx etc). But still if there’s one takeaway it’s that I now have a hotlist of things I need to read more about now to get deeper into Blockchain application programming, specifically:

  1. Solidity – and especially mulling over the Solidity by Example sample to grok this better
  2. Geth – not just setting it up, but understanding how Ethereum nodes operate and peer with each other
  3. Probably also stepping back to try something simpler first, like building the Greeter app from Ethereum.org before going further including configuring my browser to run DApps with MetaMask chrome extensions

Quick SharePoint Tip

The shorthand method to execute

Add-PSSnapIn Microsoft.SharePoint.PowerShell

is to instead use

asnp *share*

This is useful if you’re in a Powershell terminal and want to start using SharePoint Powershell commands, you first need to add the SharePoint Powershell snap-in module to get access to those commands.


In the last article I focused on Users, the first entity in the framework for structuring your architectural thinking for Office 365 deployments. In this article, I will start, but probably not finish, focusing on the 2nd entity, Tools. For a recap of why I think this framework is useful to begin with, I’d recommend reading the first article in this series.


Office 365, if I remember correctly, started as a rebranding of BPOS, a Microsoft product offering where cloud-hosted versions of SharePoint, Exchange and Lync (now Skype for Business) servers were offered to customers as a packaged deployment, having initially been offered individually as SharePoint Online, Exchange Online and Lync Online. The noticeably reduced per-user licensing and the lack of a comparable infrastructure deployment effort and resources costs to their on-premises counterparts is something that to today drives the popularity in shift to a SaaS (Software as a Service) licensing model for most software vendors, not just Microsoft.

Office 365 has since evolved tremendously, both in terms of tiers of licensing, and the tools these tiers cover. This list is a bit exhaustive, but the graphic below gives a fair idea of what’s there.

Office 365 Portal Menu.png

Since we’re talking Intranet architecture, I’ll keep it high level and not go into each individual tool unless I’ve got some grokked insights into it I’d share that’s applicable for this framework and probably mention SharePoint a lot since that was my area of expertise in the on-premises deployment days.

One challenge more seasoned SharePoint, Exchange or other architects/consultants with more familiarity of the on-premises versions of only one server software will face is shifting the rules we’ve already established as second nature from our experiences in past deployments that may seem a bit frightening to leave behind in the cloud model.

However, with the change to Office 365 and cloud-hosted server software, also comes a necessary change in structuring the thinking of Office 365 deployments, that differ from the olden days of on-premises counterparts. Even “hybrid” deployments that combine on-premises and Office 365 hosted versions of tools such as SharePoint need to take stock of these changes.

For an Intranet project that was hosted on premises in the past, the core collaboration participation tool was probably SharePoint, and the child entity of focus was the SharePoint Intranet Team or Publishing site. Indeed, many experienced consultants still choose to stick with the SharePoint Intranet Team or Publishing site as the core area of focus during an initial deployment of Office 365. However, I believe that to keep this thinking leads to some significant technical debt when trying to include some of the newer tools like Delve, Planner and Teams that are becoming increasingly popular within Microsoft Office 365 later down the line. Intranets have evolved with Office 365, and it’s time for SharePoint architects and consultants to evolve their thinking as well on this.

I evolved my thinking in this space so that the core collaboration participation entity in Office 365 is now, well, Office 365, or more appropriately the Office 365 portal (as viewed in the screen above), and so now logically, my child entity of focus becomes the Office 365 Group, not the SharePoint Site when I start thinking of the Intranet experience, and to what Office 365 Groups a user should belong.

Office 365 Groups

This makes sense as creation of an Office 365 Group, whether thru a portal or thru Powershell, will also create the instances of, and associations with, Outlook Online, SharePoint, Onedrive for Business, Planner and Microsoft Teams, which means that I’m touching several of the tools in the Microsoft Office 365 suite, and not pigeon-holing my users to working in only one tool.

Credibility to this adjusted thinking can be seen today in the SharePoint Modern Team Sites, where it may seem like you are creating just a SharePoint Team Site when you use the SharePoint tab in the Office 365 Portal page, but you are in fact creating an Office 365 Group that has an associated SharePoint Team Site. This is a good thing, since you will want to use the right tool for the right job, and while SharePoint is good for some collaboration tasks, other task like a continuous running discussion may be more suited to a tool like Teams, while sharing files and documents may be better suited to. OneDrive for Business, and the overhead to get users in one tool configured for another should be minimal. This behavior where the entity we are creating is actually creating a parent Office 365 entity behind it happens as well with other tools, like Planner and Teams, where creating a new Plan or Team is in essence creating a new Office 365 Group with this tooling enabled.

Office 365 Groups has been excellently documented by Microsoft and partner blog posts alike, and I’d highly recommend reading and getting into the weeds of these articles to really clarify in your own mind how these are used best, so that in structuring your thinking on Office 365 deployments you ensure these take front and centre stage and are not forgotten like your 23rd birthday.

So this post started off as the discussion on Tools, and branched slightly to talk about Office 365 Groups, but hopefully with this foundation in mind, in the next post where we dive into actual tools such as SharePoint, the reasoning behind this deviation becomes a little more clear.