Politics of APIs - http://apievangelist.com/2014/03/17/politics-of-apis/
Politics of the API Economy - http://apievangelist.com/2015/07/27/politics-of-the-api-economy/
API Evangelist Thoughts On The Right To An API Key And Algorithmic Organizing - http://apievangelist.com/2014/09/06/api-evangelist-thoughts-on-the-right-to-an-api-key-and-algorithmic-organizing/

I don't believe need to stop kidding ourselves about APIs, we need keep having discussions about why they work, why they don't, and the common building blocks that make things go around.

Something I've been working on for over 3 years.

Kin Lane

The simplest way I can think of is to have two confirmation passwords for the vote: one that means "validate my vote", one that means "I've been coerced". These passwords are used for nothing else, and so the coercer cannot verify that you used the correct password.

And I had also thought about the nature of a public bitcoin blockchain. the problem of public bitcoin transactions seems lessened by the virtue of zero knowledge (and it's ability to generate pointlessness), because trackable aspects of a transaction are always public keys/hashes, for example of the wallet address.

fortunately wallet address hashes are uncapped. they are virtually limitless when they remain free to create/own again and again and discard as well. therefore with a modest provision of computing power any sum could be google-hatted about to new vertexes, hashes with far smaller and different quantities of transaction value than governments could reasonably dedicate to understand. the potential to envelope private bitcoin value is only limited by the creativeness of its owner/programmer. a far reaching premise if you ask me.

I think the most important value derived from unit tests is having a quick feedback cycle. You write code, build it, and immediately get results. If your have nothing but e2e tests, it often takes much longer to verify that the piece you are working on works correctly.

Also, most people overlook this benefit of having good unit tests - easier refactoring. If your unit tests verify the interface of your component, you can confidently refactor and move stuff around - as long as all your unit tests passed, you can be reasonably confident that you have not broken anything. Of course, e2e test will still have to be run, unit tests are not meant to replace them. They are a tool in your arsenal that helps you write better code quickly and efficiently.

So this:

 .foo = bar; if(a == 0) .++foo; if(b == 0) .if (foo == 3) . bar = 0; if(c == 0) .++bar; end .foo = 0; end end 

could become this:

 .foo = bar; if(a == 0) .++foo; if(b == 0) .if (foo == 3) . bar = 0; if(c == 0) .++bar; end .foo = 0; end end 

or this:

 .foo = bar; if(a == 0) .....++foo; if(b == 0) .........if (foo == 3) ......... bar = 0; if(c == 0) .............++bar; end .........foo = 0; end end 

1)

 "this is a\ntwo line 'string' with double quotes" 

2)

 'this is a\ntwo line "string" with single quotes' 

3)

 [[this is a three line string, but the normal escapes sequences aren't interpreted what you see is literally what you get]] 

That last form can actually be embedded, because the actual delimiter is "[" "="* "[" and "]" "="* "]", where the number of equal signs are equal (if that makes sense). Perhaps an example of the code fragment in section 4 will be helpful:

 print [=[print [[print "Hello, world"]]]=] 

(The print() function in Lua automatically adds the newline).

Just a thought.