Friday, May 25, 2018

Cleaning up your local repo from too many dead branches

You'll eventually have too branches in your local that's untracked - ex. Not in origin or Github. This gets annoying since too many of these branches are often dead. So time to prune them:

git remote prune origin

You would assume that would work but nope. This only works on the remote repo and not your local. But you can to do this:

git branch --merged master | grep -v '^[ *]*master$' | xargs git branch -d

This is uncomplicated since this just soft deletes all branches that are already merged - the -d flag in git branch.

But if you need to check against the remote repo then a more complex command is called for:

git branch -r | awk '{print $1}' | egrep -v -f /dev/fd/0 <(git branch -vv | grep origin) | awk '{print $1}' | xargs git branch -d

The only rub here that is only works on bash or zsh shells. Also you need to run git remote --prune first because using this.


Reference:

  • https://stackoverflow.com/questions/13064613/how-to-prune-local-tracking-branches-that-do-not-exist-on-remote-anymore/16906759#16906759

Wednesday, May 9, 2018

Understanding the two kinds of smart contracts

Stellar is a platform built with Blockchain that enabled someone to build a financial system like say a payment system. One feature on Stellar is Stellar Smart Contracts (SSC) and I've been trying to wrap my head around it.

So what is a smart contract? An SC is just an agreement between 2 or more parties formalised over a computer network. Think paper contracts but with a computer network as a witness. The catch is that there are TWO kinds of smart contracts - Turing complete OR non-turing.

Turing complete SCs like Ethereum's Solidity include code that EXECUTES ON THE CONTRACT when given certain inputs. What can be executed is still subject to constraints on the contract like say time - ie. You can execute this contract after 48 hours.

Non-Turing complete SCs like Stellar's do not include code with the contract. So you have to execute the contract on your side - ie. your own server. But similar to the other type of SC, what can be executed is still subject to constraints.

Turing complete SCs are like self contain black boxes with buttons and sensors. It does stuff on it's own based on what button is pressed or what the sensors pick up.

Non-Turing SCs on the other hand are like those hand-crank jack-in-box toys, who (when, how, etc.) can crank it defined is identified on the toy. On it's own it doesn't do much. It just sits there.

So what use cases are talking about?

Non-Turing SCs seem to be pretty good for escrow type transactions. Stellar's SC examples are in fact, escrows.

Turing complete SCs seem to fit into long term, repeating type transactions like retirement payments.

Which one to use? I can't say. I've been learning Stellar via a Python SDK. It's been interesting so far.

Monday, March 26, 2018

Why use the middleware approach for Django analytics?

Because of either proxy servers, ad blockers (like ABP, uBlock, etc.), or browser settings that stop JS scripts. Depending on the level of users and how much value they place on their privacy, they can outright BLOCK all forms of analytics. This ends up with our analytics data being unreliable or at least viewed with less confidence.

But why the middleware?

Django middleware is a good place because it's called for all request and response cycle.

The upside to this is:

  1. It's easy to customise. Django middleware is just a plain Python class with some methods. 
  2. The Django middleware is well-documented. 
  3. Allows us to setup whatever rules like exclude errors and only track HTTP 200 responses.
  4. We can setup tracking to be asynchronous. This way, our pages are not at the mercy of an external resource.
Writer's note: If your analytics needs are simple, you can install django-google-analytics and follow Usage #2 - Middleware + Celery.

There are a couple of downsides to this though:
  1. We could be impacting performance in a big way if the analytics middleware is doing too many things or worst, is misconfigured. 
  2. Not as bad as #1 but if we went down the asynchronous path, we will end up with a Celery server with some message broker like RabbitMQ on the tech stack. Another thing we'll have to manage. 
TL:DR For analytics with Django, HTML tag slows down pages and could be blocked; better to use a middleware approach.