Community report: Smart cities Blockchain hackathon

I was proud to be a sponsor, trainer and mentor at the Smart Cities Blockchain Hackathon

SmartCitiesHack Melbourne brings together the brightest minds to develop innovative solutions, utilising IOT, Blockchain and Big Data to introduce smart technology to solve real world problems, in one of Australia’s largest cities.

An impressive aspect of the hack is that there were 2 teams from a girls high school, one from a college, and one solo university student. It was great to see younger people getting involved and solving problems from their own unique perspective.

The final demos that interested me the most were:

  • Home stay invest
  • Public works platchain
  • Smart space

And of course there was lots and lots of food sponsored by Microsoft


Kick off

A few guest speakers presented at the beginning of the day to help give insights into what type of challenges cities are facing. One of them was the CIO of the city of Palo Alto

Cities of the future need to focus on 3 key things: Liveability, workability & sustainability.

6% of Australia’s GDP goes through Melbourne
How do you prepare a city for autonomous vehicles.
Digital identity. Who owns it, who can use it.
How can gov policy keep up (some industries will be dead before legislation even comes in)

We have such a massive influx of people moving into the cities. If we think traffic congestion is bad now, wait until the future!
Thinks the issue is climate change trumps any other issue.
Users don’t want to deal with governments in giant waiting queues at centrelink. They want to just pull out a smartphone app and renew their license.


  • 3rd place. My Say
  • 2nd place. Owl
  • 1st place. Smart space



The presentations

Smart space
Decentralised way to list rentable spaces e.g. conference rooms, lecture theatres.
Can book it using blockchain, get a QR code, can enter the room.



Team peak
High school student team
Medical insurance fund
Do it peer to per so that you can reduce costs by removing the massive admin overhead costs of existing insurers.
Have people in community randomly validate claim requests.



Property storage rental.
More and more people are moving into cities, people have less living space. People are looking for storage spaces. Allows people who have spare space to rent it out to others


Smart carbon
Solo 2nd year university student.
Tracking carbon emissions from sensors, and keeping a true record on the blockchain. Built a blockchain solution that would allow sensors to store their data. Allows trusted collection of carbon emissions in real time.


Public works platchain
Try and reduce costs and provide better cost certainty through public works tenders.
Tenders and implementations rely on multiple parties (council, telstra, contractor). At the moment parties can delay without incentive to complete on time.
Can use blockchain as an escrow account for payments, and other stakeholders put in a deposit. If the contractor delays, they automatically get a penalty fee taken out of the escrow account. If the stakeholders (council or telstra) are the cause of the delay, they lose a portion of their deposit.


Team Quatr
Tracking home rubbish bin levels, so that garbage collection trucks don’t need to stop at every home, and can be more efficient. Automatic optimised route creation.
People that recycle get 1 “eco token” per recycle bin collected.


Home stay invest
For international students looking for long term housing. And for Australian’s looking to purchase an investment home.
Allows people to invest in their communities and their schools.
Multiple actors, students, people that want to invest, people who have spare rooms to rent.
Fractional property purchase / fractional sale.



Team Owl
Sensors can create streams of data, that they can sell for tokens.
Others can see on a map the list of streams, can click to purchase access rights to the sensor data stream.
Iota IoT network


Team Mysay
Girls high school team
Electronic voting via the Blockchain. Allow more open democracy. Can use for local council meetings for example


Devcon 3 report: Day 1 – core systems

Other reports:

The 2 talks to watch are: “Regulatory update and look ahead” (covering a security is) & Vitalik’s talk at the end of the day on scaling/sharding & Ethereum 2.0.

Format for the week will be:
Day 1 is core tech
Day 2 is research
Day 3 is Dapps
Day 4 is ?

Ethereum team introduction

Vitalik – Founder
We are working on research into what the future of Ethereum will look like, to support the future of Dapps.
Working on Casper, scalability, etc.

Martin Swende – Security Lead
Is across all the projects, to try and keep across security issues. Especially the network protocol.

Peter Szilagyi – Geth team lead
Since Shanghai Devcon 2 last year.
Released mobile library.
Made a new P2P protocol for private networks
Released a light client version
Added Proof of Authority to the plugable consensus, and it is being used by one of the testnets
Focusing a lot on performance bottlenecks.
Reduced DB size by 50%, syncing time by 60%

Zsolt – Geth, Light Client dev
Made lots of progress on light client (syncing, log searching, p2p discovery, etc)
Looking forward to the production release

Dr. Christian Reitwiessner – C++ client / Solidity team lead
Looking to get C++ client working again
Snapshot syncing. Removing race condition bugs.
Improvements to EVM, v1.5
Working on ZK-Snarks

Yoichi Hirai – Formal verification Engineer.
Writes mathematical proofs
Followed the Metropolis changes, wrote test cases against the implementations.
Helping to prove Casper. Will talk further on this later today

Alex Beregszaszi – solidity, eWasm, ethereumJS
Solidity changes so far: Function types, contract metadata, new compiler interface
Solidity futures: new language, new formal verification checker (snt checker?)
EthereumJS – support for Byzanthian fork. Important as other projects rely on it like Remix.

Yann Levreau – C++/Remix developer
Remix is a web based IDE.
Working on improving UI and backend code.

Piper Merriam – Python team lead
Established a spec for packaging smart contracts, and looking to get that implemented across the ecosystem
Responsible for a lot of the Python tooling. Working on bringing it’s quality up to par
Working on an alternative EVM called pyEVM
Looking to bring it online as a new light client

Viktor Tron – Swarm team lead
Swarm has grown beyond the intial scope of a flie store for Ethereum, now covers high bandwidth communication
Tomorrow session will be the main session on it
Developed a network simulation to check things like high node churn.
Main initial release will be around cloud storage to sync between their devices.
3rd party application uses, like live audio streaming.
Working on privacy and censorship resistance communication.

Vlad Gluhovsky – Whisper lead
Whisper is meant to deliver data. Want to make sure no data or metadata is leaked. Tomorrow will talk about this

Everton Fraga – Mist team lead
Been working on bonding some other projects into the Mist browser.
Working on making it more scalable. More info in Friday’s session.

Fabian Vogelsteller – Mist, web3.js
Will do a session later in the week on the 1.0 refactor.
Proposed a new ERC 725 – around identity.

Regulatory Update and look ahead – Jerry Britto
HIGHLY suggest you watch this session if you plan an ICO or any serious Blockchain Dapp

Coin Centre seek to educate policy makers
Year in review:

  • Uniform Law Commission – supplements the money transfer license. Helped define what “control” means, to help be clearer who needs a license. Only if the company “controls” the currency, helps with some exemptions. Defines who is an intermediary and need regulation
  • Helped deliver a bill into congress around tax – examples like using ether to pay for a smart contract execution is technically taxable
    any transaction below $600 you don’t need to track.
  • FCC – talked about securities and tokens.
  • Potential terrorist use of cryptocurrencies – put on a demo day to help educate members of congress. Conclusion at this point, it is a serious potential threat, but isn’t an issue at this moment.


Characterizing issues on the horizons:

  • Regulatory hotspots around securities regulation & AML (Anti money laundering)
  • AML law boils down to Is the token being used as a currency substitute. Is there a centralised issuer tho can also withdraw from circulation. If yes, they are an issuer. Otherwise they are an exchange (like Bitcoin/Ether)
  • Securities law boils down to: is the thing being sold as an investment. Is there a person upon who investors rely?
    No one person is relied on around gold. But a share/stock of Apple is a security, as you rely on the company.
  • Issuer vs. Network
    Money goes in, more goes oug -> Investment
    Money goes in, utility goes out -> Network



Super useful diagram of what is a security.
Coin Center is helping to suggest that FCC should focus on investments controlled by a single issuer, to help protect people, but leave the rest of the ecosystem open.

Ethereum in 25 minutes – Vitalik


In 2013 blockchains are useful for ‘stuff’. Not just money but for thigns like Asset issuance, crowdfunding, domain registration, IoT, voting, etc. More than just transferring BTC
Original Blockchains were single function.
Why not make a protocol that works like a programmable smart phone. So that a single blockchain can run multiple use cases / apps. General purpose computation.
Smart contracts that could control digital assets. When to release assets to other people.
Also to program other business logic, like voting, ENS, etc.
Every transaction specifies a TO address. The code at that address executes. Code can send ETH to other contracts, read/write storage, call other contracts
Every full node on the blockchain execute all transactions.
Halting problem was an issue (e.g. infinite loops). So gas was implemented to help constrain it. Charge a transaction fee per computational step.
Logs are an append only data, not readable by contracts. 10x cheaper than storage. Up to 4 topics for bloom searching. Intended to allow efficient light client access to event records (things happened)
You don’t write in DVM bytecode, instead you code in Solidity, Viper, LLL, Bamboo.
The ABI describes the function calls available on a contract, so that clients can call into it.
Byzantium introduced some precompiled functions to verify: Ring signatures, ZK-SNARKS, RSA
Also added new functions like assert(), revert(), require()

Future directions for core Ethreum: Casper, Sharding, EVM & protocol upgrades.
Are still other things in broader ecosystem like Plasma, state channels.

Methods for deterministic parallelizing message processing – Martin Becze
started in ewasm. Plan was to build off web assembly instruction set, to add in metering.
Issue was that you had to run transactions sequentially, not concurrently.
Is a layer that sits between VM instruction set and consensus mechanisms.
For scalability, need to apply locality.
Right now all contracts exist in the same namespace. One way to impose locality could be that each contract has subcontracts that only it can access. Means the subcontracts could all be executed in parallel as they can’t effect others directly. Problems with nested contracts. Inflexible, inefficient.
Next approach Try to build up a graph of how contracts interact, then use that to define shard boundaries. Can create a bigraph from this.
Got very very technical from here on, about different messaging strategies to try and break tings up and be more async.

Practical applications of off-chain computation in the light Client ecosystem – Zsolt Felfoldi
Do computation, do a validation process to verify it.
One application is for event filtering for history searching. If we shard or do state channels, there is going to be a hierarchy of data that needs to be searched.
Currently uses bloom filters. But in a bloom filter you’d need to filter through 4million+ blocks reading all headers (currently 2.2GB). Light servers can search and present it to light clients, but clients need a way to validate it. Bloom trie root hashes can be interactively validated on chain.
Users want to observe multiple subchains (when sharding) and get notified by new events using a complex filtering criteria. Light clients can hire a full node (light server) to validate and certify a subchain. Client specific event filtering can be done server side.
Chain filters. Deterministic operations on an input chain.
Observer chain: belongs to a single node, processes multiple observed chains. Checks the current best heads of observed chains.
Building a filter hierarchy. Observers can build on top of other observed chains. Can have base ones filtering out bulk of stuff, and then further layers refine it further.
Build up a market of services for light clients.


Parity: A Light client for heavy chains – Robert Habermeier

Ethereum clients currently can be defined broadly as:
Full nodes – they check and verify everything. But storage and computation requirements are heavy.
Light client – verify block headers, but not checking transactions. So checking that mining consensus is working.
Thin client – isn’t checking consensus, relies on others to do it for them.

Light clients check validity of headers. Does not check validity of state transitions. Might lead to some targeted attacks, attacks wouldn’t work on full network which is validated, but targeted to a single client.
Protocol goals: minimize roundtrips and bandwidth required. Full nodes are serving data to light clients, need to think how to present denial of service
Put multiple requests into the same request package (I need block X and account Y).
Can use state proofs to get a subset of a state tree.
Metering system, using request credits. Each node can come up with their own pricing. Different requests have different costs.
The average person won’t run a full node, but we need them to support the network of light clients. Needs an incentive system.
Pub/Sub for events. Reduces polling and excess work.
Warp sync: Users usually don’t care about really ancient data. Can just jump to more recent blocks. Ancient block download can happen later (e.g. when on wifi).
RPC pitfalls: on light clients some RPC calls don’t work.
Eth_getLogs can be very expensive if you are checking all history of everything. If just watching the head for events, is much cheaper.
Eth_get*ByHash the hash of the block has no info about the actual block number. So will need to search through the history and maybe forks or uncles. Lots of work to search
Eth_estimateGas need to check state proofs of multiple executions. Lots of computation to guess.
Lightclient+whisper+ecosystem. Light clients are viable for mobile devices (on wifi) whisper makes a powerful tool for messaging and medium latency state channels. Projects like status are already using this and showing how this can be done.
Looking at compiling light client into Web Assembly. Could embed into a web page.


Verifying Casper – Yoichi Hirai
Casper is the planned Ethereum Proof of Stake protocol.
There will be a capser contract on each (divergent) fork. Validators deposit ETH, when they do the right thing they get rewards, bad they lose ETH. Validators can vote for a block. Can’t double vote or they lose.
To avoid losing deposits, just need to be careful about what you sign. Will only really lose if you are doing bad things.
When a block has 2/3 votes from validators, then they are justified and later finalised.
Next 10 minutes is lots of mathematics diagrams. Track the ancestor blocks and votes and punish bad people who vote for divergent forks.

Sikorka: Proof of presence for Blockchain applications – Lefteris Karapetsas

Network of detectors that provide proof of presence. Different types of detecots exist. Contracts choose detectors depending on security requirements.
Users interact via a phone app.
Proving presence for bureaucratic reasons. AR games. Objects directly interacting with smart contracts (smart locks?)
Different detector types that the system can use, contracts select types based on security requirements.
One detector is the “Revealo temporal BLE tracker”. Provides accurate location, uses temporal keys to preserve privacy.
A super cheap detector could be a screen somewhere that generates a new QR code every 10 seconds that you can scan to show you were there.
There is a central Sikorka smart contract controller that indexes all the contracts. And a contract interface you can use to hook into the system.
Basic usage could just use your phones GPS (but can be spoofed).
More secure uses a detector. You interact with the contract to show you are near the detector.

Julia: IR (Intermediate Representation) for Ethereum Contracts – Alex Beregszasci
Why do we need an IR?
Complexity of auditing solidity contracts. Helpers & optimisations of Solidity. Porting Solidity to other VMs.
Auditing that the compiler did convert solidity into the correct bytecode is difficult. EVM bytecode is very cryptic to read.
Compiler pipelines usually go in 3 stages: parse/analyse, optimise, create bytecode.
But the solidity compiler only really does the 1st and 3rd. Smooshes it all together. Julia will sit in the middle to help support other functions.
Benefits are that more of the compiler can be moved out of C++ and written in Julia, for simpler reading.
Also means it is simpler to optimise code before generating bytecode.
Julia currently supports: typed variables, functions, switch statements, if, loops.
Will support output to EVM, EVM 1.5, ewasm, others (like outputting into JS or C for integrating into UI side)
Could get your own DSL to compile into Julia, which could then output into EVM bytecode.

Package management for smart contracts – piper merriam

Last year they got togther and proposed ERC190 smart contracg package spec
ERC190 deterministically create a package that is immutable.
Packages can include: sull source code, compiled assets, compiler info, ABI, address of deployed contracts, link reference info
Useful for public chains, but also for private chains.
Example of the simple inheritable contract.
The .json file of the package defines metadata, and a location of the .sol source on IPFS.
Your contract can have its own package definition, that has a dependency on another pacakge.
Package could not just store the .sol, could embedd the compiled bytecode, or just the deployed address so you can link to it.
Could use it in a wallet, import the package and it will give you the ABI that you can interact with.
Could combine it with ENS and have package indexes that list source of truth for contracts.

Programable incentives: An intro to cryptoeconomics – Karl Floersch
Blockchains have open access. Anyone can deploy a contract or send a transaction.
Trusted execution. All smart contracts and transactions will execute as defined.
Now we have programmable money.
Designing incentives. You can’t talk about blockchain consensus security without reasoning about economics.
So you can combine cryptography (hashing, signatures, etc) + economics (tokens, voting rights).
Want to use cryptoeconomics to enable good outcomes like trusted execution, and protect against censorship.


Example project: Market maker. A simple automated market maker contract.

  1. Design a mechanism
  2. Analyze incentives
  3. Make a website
  4. Observe behaviour
  5. iterate

Deploy a market maker contract with an initial deposit of ETH and tokens. Is an automated exchange to trade ETH for tokens. It will dynamically calculate token prices based on what is left in the contract. The contract owner will get some fees back.
Owner gets a passive fee income. But they have their capital locked up.
Token buyers are happy because they get small transaction fees, it is a trustless exchange.
Can come up with ideas, just deploy it out into production and see how it goes. Make sure you verify your source on Etherscan.
Allows anyone to just come up with ideas and get it out there.
Make sure you share your findings, so the ecosystem learns.

Casper the Friendly GHOST: A correct-by-construction blockchain – Vlad Zamfir

All the Ethereum proof of stake research projects are with the goal around finality safety.
Traditional consensus protocols decide on one block of transactions at a time.
Point of PoS is to incentive nodes to do the right thing. Need to prove that it is fault tolerant, and when there are faults, that it can recover (and penalise the bad actors).
Vlad just talks too fast and clicks back and forth through slides too fast to keep track of notes sorry.


Introducing the TrueBit Virtual Machine – Jason Teutsch

Is now deployed to testnet
Smart contracts can only handle limited computation execution time.
Truebit is a scaling solution for computation. Do the heavy work off chain. Uses interactive verification for large transactions. Help to bypass the gas limit.
Is an ethereum smart contract + a new off chain architecture.
Solver proposes the solution, submits it. Anyone can challenge it and put up a deposit. They play the verification game to see who was correct, loser loses deposit.
Computation runs in a TrueBit Virtual machine. Tasks must compile and run across all machines. The TVM breaks it down so that the smallest piece of execution can run on chain. For when there is a disagreement, the one step where people got a different result can be run on chain to determine the correct result.


Scaling Ethereum Smart Contracts – Joseph Poon

Many blockchains on a blockchain. Can bond your private chain to the public network.
Deploy a plasma smart contract to the main blockchain. Can now run your own child plasma chain. Periodically commit block hashes to the main chain contract.
Big changes can happen on the plasma chain, but just a tiny block hash is submitted onto main chain.
People can submit a merkalised proof if someone tries to commit an incorrect hash to the main chain.
If someone is withholding block data and isn’t letting it continue, then you can exit the child chain, have eth roll back up to the main chain, and then create a new child plasma chain
Could credibly securely spin out these plasma chains to scale computation for specific use cases. Like a Reddit comment chain, ebay chain.
The point is to encompass all worldside computation. Computation can be done on child chains, with final state committed to the main root chain.

ZoKrates: A Toolbox for zkSNARKs on Ethereum – Jacob Eberhardt
On chain processing is submitted as a transaction. Is executed + validated on chain.
Off chain processing, the transaction is executed off chain. Just the validation happens on chain.
Means that private information can be used without revealing it.
Truebit is one way of doing this. Another is using zkSNARKS
zkSNARKS, verification cost is independent of computational complexity. Short & non-interactive proofs.
Define computation as mathematical circuits. But is very complex to create these yourself.
I like thinking of this as: Hashes lets you verify large pieces of data as a small hash value. zkSNARKS allows you to represent a large complex execution as a tiny proof.

ZoKrates wants to provide tooling to make it easy to support zkSNARKS from end to end. And to integrate easily into Ethereum. It has a DSL to specify your computation, has a compiler into provable constraint systems, support for the phases (setup, witness, etc), and a contract to verify the computation on chain.
On chain verification currently costs about 1.6m gas.


Designing Maximally Verifying Light Clients and Sharding- Vitalik Buterin


Watch this session.

Subtitled as “a modest proposal for Ethereum 2.0 over the next 4 years”
Ethereum works. Many applications. High adoption >460k tx/day. Which is about 7tx/sec
Ethereum nodes worldwide. US has 30%, Canada 5%, Australia 2.8%
The Byzantium fork added in privacy preserving features, that will enable zkSNARKS, ring signatures.
Scalability is still a current challenge. Right now every node runs every transaction. And transactions are not parallelisable.
Sharding is a way to split up the blockchain state. Only allow async calls between shards. Each node only processes transactions for a shard, so a small portion of all network transactions.
Governance & protocol evolution has been a challenge. Hard forks making deep changes are hard. Long time to code, test, and a high risk of consensus bugs.
But we want to make some big changes to enable Ethereum 2.0 (EVM upgrades, more precompiles, etc.). How do we handle the trade off.

1 blockchain 2 systems:


Have a Validator Manager Contract. Runs a PoS system. Would keep track of validators, to join and leave as a validator. Each validator can gets assigned to shards randomly, can make blocks. Block making protected by rewards and slashing.
Connecting the shards go through the contract via messages.
Gives a way to experiment with this as a contract, with less risk on the main chain, and doesn’t require a hard fork.
Can evolve shards quickly, will letting main chain be more conservative.

Sharding roadmap


Having shards will allow experimentation with backwards incompatible upgrades:
EVM upgrades like EVM1.5 & ewasm.
Stateless clients

For stateless clients, consensus nodes would not need to hold state, only state root.
Would only need to submit merkle branches to submit state changes.
Means you don’t need to store and read state from disk any more. Makes it easy to shuffle validators around as they don’t need to sync down entire state, just accept merkle branches for changes.

Report: Microsoft Australia DX hackfest (July)

An important part of being a Technical Evangelist at Microsoft is continuously upskilling and playing with different technologies. Taking 2 days out a month to sit down together and hack, gives us a chance to learn from each other. For example Simon briefly mentioned that he was playing with Xamarin Forms & Android development, but was having issues with the Intel Android emulators, so I was able to quickly show him the new Visual Studio ones that run on Hyper-V. Conversely I was having issues with NodeJS that Simon & Elaine were able to help me out with.

And of course, we took the time out for our usual #TacoTuesday DE--sUTUAAAmwLR.jpg

Like our previous hacks, the Melbourne team were hosted by Frank Arrigo out at the Telstra Innovation Labs While we also had Azadeh joining in remotely from Sydney, and Hannes remotely from New Zealand. 20170718_152147(0)

David (Me) – Meme classifier

I decided to make a system that could automatically classify Internet Memes. There are whole subcultures on Reddit dedicated to them, one of my favourites being I wanted to use the new Custom Vision service to train it on the different meme types, and be able to upload a meme and be told which category it is.

Training the custom AI was easy, I uploaded samples that I got off Reddit and clicked train. Testing it with other images correctly identifies them. Creating and training only took 10 minutes, I spent way longer browsing Reddit looking at memes ^_^;;

custom vision trainingcustom vision test

Next I wanted to build a chat bot and allow people to upload an image, and have the AI return back the category, and send a link to the correct page on Know Your Meme e.g. Success Kid. I decided it would be a great time to try out the Microsoft Bot Framework for NodeJS. I have used NodeJS & npm to download and use Blockchain toolchains, but never developed directly on it.
I have enough time to fully build out the chat bot, but I learned HEAPS about using VS Code and debugging NodeJS apps using VS Code. Lots of little gotchas when developing with NodeJS for the first time.


Azadeh (remote from Sydney)

I wanted to solve the first world problem that most of us have! have I turned off my hair iron strengthener?
It turned out there are lots of people have the same problem, please read and
to solve the problem I used wemo switch. I created two recipes/applets in ifttt for turning on and turning off the wemo switch. Basically, I got two endpoints for turning on and off the switch.
To make it more user-friendly and accessible, I used azure bot service and created a chat bot that can get commands to turn on and off the switch.
I used LUIS to understand intents and call the proper endpoint based on the command.
I hosted the source code on github and set continues integration to make sure after every push to master, the new code got deployed to azure bot service and updates the bot.
source code:



I used Azure Cognitive Services Text Analytics to analyse Star Wars subtitles tracks. Topic Detection and Sentiment Analysis both seemed like good candidates.
Key Learnings:
1) Topic Detection doesn’t work well with many ‘documents’ of very small size (e.g. lines of subtitles), of as little as one word. A better approach was to approximate scenes and aggregate lines into larger documents.
2) Sentiment data is very noisy. A naive prediction is that such a sentiment analysis would track the cadence of the film. This is not at all the case, as you can see in the graph of the sentiment of the Phantom Menace.
3) Slang/ colloquialisms break topic detection, e.g. Jar Jar Binks’ lines like ‘mesa in trouble’. These should be excluded from the Topic Detection algorithm using Stop Words or Stop Phrases field in the request.

The plot below tracks sentiment across all pseudo-scenes throughout the film. You can see the data is highly variable and does not seem to follow the cadence of the film. A further research question might be to vary the size of pseudo-scenes (i.e. to aggregate lines into variable sized batches), and run sentiment analysis on all these pseudo-scenes. The result may better approximate the cadence of the film.

MicrosoftTeams-image (2).png


Hannes (remote from NZ)

hannes hololens.png

The app is made using Unity, and the HoloToolkit.
You can see how far along progress currently is in this video.
The idea is to bounce a table tennis ball on a paddle that you drag around with your hand. It has a scoreboard that tracks your high score for the session.
When you open the game, you are presented with a paddle and a ball hanging in the air above it. To start the game, you simply tap and hold on the paddle, which starts the ball falling. Keep the paddle under the ball to make it bounce. You get a point for every time the ball bounces on the paddle. Releasing the paddle resets the position of the ball.




Report: Microsoft Australia DX hackfest

An important part of being a Technical Evangelist at Microsoft is continuously upskilling and playing with different technologies. Each of us are usually off speaking to different customers or attending developer events, so to give us a chance to work together as a team and learn from each other we decided to set up a regular internal hackfest.

Last month we had our first, and the Melbourne team were hosted by Frank Arrigo at the Tesltra Innovation Labs. It is an awesome space, and we plan on hosting a LOT of future hackfests there. We also had our remote team mates working away and keeping in touch during the event.

20170419_115014 (2)

Each of us hacked away on our own experiments, which gave us a chance to check out the latest toolchains and APIs. But it was great being able to just ask each other for advice.
At the end of the 2 days we all jumped onto a conference call and showed off what we were able to throw together. The valuable thing was just hearing the learnings from each person on the “gotchas” they discovered when working with the tools/tech.

Here is a little summary of what each of us worked on and learned:

David (me)

I wanted to build a little utility that utilised the Microsoft Graph The idea being that you want to compare what distribution lists you and your peers are on, as it may make suggestions on ones that you should join (like Azure insiders). I worked through the graph documentation and used the graph explorer to figure out the set of queries I would need to pull out the data I needed:  – lists distribution lists that I am on – gets my manager<manager email from above>/directReports – returns who my peers are<peer email>/memberOf – loop through the returned list of peers, and get each of their DL subscriptions

I’d then be able to compare the DLs that I’m on, with the ones that my peers are on. And flag which ones we have in common, and which ones we don’t share as suggestions.
The next step was to build a web app to do this. I jumped onto the Microsoft Graph quickstart to generate a skeleton app as my starting point. This required registering my app on which would allow my to request permissions from the user, to access the graph on their behalf.


I was able to get my application to authenticate, and query details about myself and my manager. However to retrieve what DLs other people are on requires the Directory.Read.All delegated permission, and because that can potentially leak sensitive information about your organisation, only Admins can great that permission. This meant I was stuck as I don’t think the Microsoft Admins will grant me permission for my dinky little utility to run on the corporate tenant 😉
But it was still a good exercise as I was able to see each of the pieces working, and got some basic queries working.


Wanted to learn more about how to use Unity (as a lot of our customers are using it now for things like Hololens). She built a 2D Tetris Game, by following the tutorial at



Wanted to play around with Conversations as a Platform and learn more about what is possible with bots.

On day 1 lost a fair bit of time with some visual studio 2017 issues. These seemed to be related to having a pre-release installed side by side with VS 2015 and then installing the full release version.
I intended to test more .Net core items but with the time lost I pivoted on to an area I was comfortable I could rapidly progress.

Further tested this github project which I have contributed to for generating a bot and tab for Microsoft Teams
used this to generate a Tab and Bot and deploy it to one of my development O365 tenancies. 
This included hosting the Bot and Tab an Azure tenancy and deploying via a local Git repository (via this  ). This was a nice simple option that I hadn’t used before as had previously only used VSTS and full GitHub. This was exactly as easy as expected to get running so was a nice option to tick off the list.

As part of the testing of the Tab I confirmed that I could get the Tab Theme switching working (as per ).
This worked quite well although on a slow internet connection the event firing was delayed hence there would sometimes be a several seconds of the tab showing before it changed colours to match the teams client.

Also included Office UI Fabric ( ) to check if that would have any issues working in a tab inside teams. I only had time to test a few elements including the spinner but these all worked well on the Tab. The main consideration is the theming may not  automatically flow through to these elements as the Teams Style sheets have very specific classes that they target hence things need to be wrapped in the elements for them to be able to change colour when needed.  This is especially important if you want your tab to work on the high contrast setting.

Finally I tried to extend the bot via  some deep linking scenarios following this , however was not as successful.   Asking the bot to send the url taken via manually grabbing a deep link for the tab worked well but that had a different format to the article.

default themedark themecustom theme
Screenshots of playing with the themes


Simon being Mr. DevOps, wanted to explore combining VSTS with chat bots. Whenever a build was kicked off in VSTS, he wanted to report back if the build was successful or not, and allow users to instruct the bot to trigger Release Management to push the successful build to different environments.

He was able to get the chatbot reporting new events in a Microsoft Teams channel, and having the bot trigger certain things back on VSTS.

Reghack “Down Under” event roundup

Reghack was a 3 day hackfest that ran in Melbourne, Australia

The problem statement asked:
Do you have an interest in helping solve regulatory issues in the Financial Services and the Energy Sector in Australia?
How do we use RegTech to make regulatory compliance a strategic advantage that’s a win for the regulator, market participants and the consumer?

The focus of the event was to try and invigorate local innovation in the energy & financial services sectors, by allowing people to come together and explore how Blockchain could be utilised in these areas. The event was the brainchild of Chami Akmeemana who is a director of ConsenSys, the largest Blockchain focused consulting company in the world. Chami came to Melbourne and asked for local community support to help him organise and run the event. I was lucky enough to be tapped by Chami and invited to assist. I helped out by providing sponsorship for the meals via Microsoft, and delivered training to help upskill the community beforehand (more about that below).

The event had around 90 participants, with many more volunteers on the day. In the end 14 teams pitched their ideas which ranged from energy trading systems, ways to authenticate documents, to ways to eliminate GST during B2B transactions.
A big thanks to Chami for organising it all, and to all the volunteers that helped make the event a resounding success.


Note: The roundup of the teams pitches are at the bottom of this post.

Continue reading

Build 2017 keynote day 1


My main takeaways:

  • serverless computing and the CosmosDB are going to allow you to quickly create new ultra scalable applications.
  • AI, cognitive services and Cortana skills will allow you to build some real Sci-Fi things.
  • Microsoft graph is improving and adding more features that will allow you to build more personal apps.

Continue reading

Videos and notes of my Blockchain presentations at Microsoft Ignite Australia

As I previously mentioned, I was scheduled to deliver 2 talks at Ignite Australia. The talks both went well, and I’ve been getting a lot of great feedback about them. Now that the dust has settled and the content is all online I thought I should share the media to make it easier for other to watch and learn from them.

Saved image from Tweetium

Blockchain 101 & Azure Blockchain as a Service

Chris Zhong & I covered off an introduction to Blockchain 1.0 & 2.0. Covering off how Blockchain 1.0 technologies like Bitcoin are able to store state. But the rise of Blockchain 2.0 technologies like Ethereum, is what has gotten people’s attention as they are able to store state and embedded logic within “smart contracts”. I had heaps of fun with this session as I spent days putting together a scenario showing how multiple DApps (Decentralised Apps) could be linked together via on chain smart contracts, to build up an ecosystem of Blockchain apps that are able to leverage each other seamlessly.
A thanks to Chris Zhong for putting together and presenting the section on “Azure Blockchain as a Service”.




Blockchain Development on Azure Blockchain as a Service

Going into Blockchain development blind can leave you stumbling around on the net not knowing where to even begin to look. The purpose of this session was to take the knowledge I’ve picked up from doing Blockchain projects, and the months and months I’ve spent replacing and refining tools down to the easiest development experience, and distil it down for the audience. It was an awareness session “these are all the tools, here is why I use these ones, this is how you create a skeleton of a Blockchain app, interact with it, test it, etc.”. It wasn’t as clean as I would have liked, and subsequent repeat presentations have been smoother, but it is still a great starting point.