Diffy and Thrift [Bookmarks]

Hey, I came across an interesting piece of technology, I don't have time to experiment with it immediately (and fully understand how we could make use of it), but I wanted to share this with you right away, in case any of this rings a bell to something that might apply to things you are working on:

1. Diffy

First, there is this thing called Diffy (developed by Twitter), which tackles some problems I am actually familiar with, in terms of Non-Regression Testing:

"Diffy: Testing services without writing tests"
https://blog.twitter.com/engineering/en_us/a/2015/diffy-testing-services-without-writing-tests.html

Diffy finds potential bugs in your service by running instances of your new and old code side by side. It behaves as a proxy and multicasts whatever requests it receives to each of the running instances. It then compares the responses, and reports any regressions that surface from these comparisons.

The premise for Diffy is that if two implementations of the service return “similar” responses for a sufficiently large and diverse set of requests, then the two implementations can be treated as equivalent and the newer implementation is regression-free.

Illustration from Twitter's blog:

2. Apache Thrift

Second, when you look at how Twitter is implementing WebServices, they go through something called Thrift (developed by Facebook and "given" to the Apache Software Foundation)... I've looked up how this could interoperate with IIS, and it appears that can be used through IIS Handlers:

"Apache Thrift - Home"
https://thrift.apache.org/


"Thrift over HTTP with IIS | codealoc"
https://codealoc.wordpress.com/2012/04/06/thrift-over-http-with-iis/

The Apache Thrift software framework, for scalable cross-language services development, combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages. 

The Thrift .Net library includes an HttpHandler THttpHandler which implements the IHttpHandler interface for hosting handlers within IIS. Documentation of how to use the handler is very sparse. Below are instructions of how to create a Thrift service using THttpHandler.

Preview of a sample IIS config:

Summary

Both Diffy and Thrift are interesting since they tackle problems I am familiar with:

• Diffy addresses the problem of comparing past and present versions of software while removing the random/noisy content from the output.

• Thrifts addresses the problem of generating client plumbing code for "talking" to webservices. There is so much difference between server and client code, that writing them in the same language doesn't actually help the slightest bit.

Anyway, just wanted to say that's something we should look into, and understand, for when we design testing strategies...

Syncthing Firewall Settings

I had a problem on a Windows Server 2016 machine where the Firewall configuration was not properly set for Syncthing.

As said on the website, you need to ALLOW

• TCP Port 22000
• and UDP Port 21027.

WARNING: Application to authorize is actually located in the AppData directory of the current user

 C:\Users\[USER_NAME]\AppData\Roaming\SyncTrayzor\Syncthing.exe

WARNING BIS: As there might be a misunderstanding as to which user is allowed to run the
application, avoid using %APPDATA% environment variable altogether and state explictely the location of the executable!

Bots and automated commits – Continuous Integration for Quality Assurance and Performance

The idea of having bots writing code is only the continuation of code analysis. In this mindset, 1/ one creates levels of abstractions and let automated systems write the actual code (eg. through snippets, custom DSLs, etc.) and 2/ one associates its code with tests that are run on automated systems and let the "bots" auto-merge features when tests pass.

For those who are interested, this information comes from the following article (a very long, but interesting thing to read btw): "Why Google Stores Billions of Lines of Code in a Single Repository | July 2016 | Communications of the ACM" - https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext

Things you will gain and things you will lose by switching from CVS to DVCS

1. What you will gain

It's easy to make one short-lived branch per ticket.

When switching to Git, you are encouraged to use branches extensively, in fact you can/should create one branches per ticket, and merge everything back into dev (and eventually in the master branch) in one click when you finished all your work (instead merging individual “associated changesets”, which is a tedious process.)

2. What you will lose

Central info is not supported in Git.

If you need edit binary files (eg. images, icons, etc.) or files that are famous for being hard to merge (eg. complex xml files, unfiltered log files, etc.), know that when you use a distributed version control system you will stop being aware of whether a file is currently locked for edition, or not. [This is one of the two reasons that makes Git unsuitable for game development because of all the binary assets – the other reason being that versioning binary files is not among Git’s strengths, even if the Git-LFS project kind-of bridged the gap there].