Category Archives: Development

Interesting Findings #2


Huge disappointment here, because of circumstances that is not under my control, I didn’t got v2. So only v1 real experience for the moment.

  1. As I mentioned before we need some gestures. And we actually did this with some heuristic algorithms. What I can say. People are very different. It is very hard to extract unique characteristics of the gesture. Surprisely, too many gestures are actually conflict with each other. Next time I will probably try to apply some learning or tree based decision making technics.

Kinect 2.0

There were chances to get v2, so I downloaded SDK 2.0. Few interesting findings here:

  1. Skeletons now bodies. Also bodies now include interaction information. This is quite good.
  2. For some reasons there is no prebuilt gestures. Probably MS will include them next time.
  3. SDK now distributed as one package. Developer Toolkit bits are now included in main package.


I tried to use D3. Well… I am not sure that I like it’s API. Some strange intersections with JQuery and AngularJS. I was using D3 to visualize joint points in Kinect. Looks quite nice, but also feels a bit slow. Probably this is by design.

Example snipped that I came up to ensure that all additions/removes/updates are rendered,


I am on the final stage of my labs project for Lviv Polytechnic. I still hate API. But results looks much better.


I am doing from edX. It does not take too much time and looks quite promising.

Tagged , , , ,

Interesting Findings #1


Last few weeks at ELEKS I am playing with Kinect to help our UX team to implement exciting stuff they need. So my finding here:

  1. It is very easy to work with. No magic, just works. Easy to setup, easy to start.
  2. Kinect SDK is very nice. It has super abstraction of user skeleton as well as raw data. With skeleton it is very easy to implement cool gestures and funny interactions. It took me few days to get comfortable and implement basic stuff with WPF. Microsoft.Kinect.Toolkit and Microsoft.Kinect.Toolkit.Controls provide usable stuff like handling connection to the Kinect, showing skeleton and interaction.
  3. There are many libs that actually work with Kinect. OpenCV, OpenNI and others. Many cool experiments. I have not tried this yet, but it definitely on my todo list.
  4. I was quite disappointed not to find good control sets for WPF and Kinect. There are some controls in Microsoft.Kinect.Toolkit.Controls library, but they are not super polished. Animations, feedback effects, transitions are boring. What is even more disappointing is lack of high quality entertainment controls even just for WPF. For example carousel control. for WPF it is – damn, it looks 80th… Compare to dozens of HTMLcarousels.. And this moves us to next point.
  5. It might look funny, but it is quite easy to use Kinect with HTML. Idea is simple, you have application that actually connects to Kinect and you have static HTML page that talk though WebSocket to that application. You can implement logic on application side and just notify HTML app with changes or you can stream everything form Kinect to HTML page and implement logic in JavaScript. Anybody who concerned about performance of such solution, do not worry, it just works, even raw video(color) stream works fine without any lags. In Kinect SDK there is kinect.js and sample server that actually implement this, but it looks a bit overcomplicated, so I implemented my own, took me few hours of work.

Kinect 2.0

On next week I will have Kinect 2.0 on my hands. I will probably have much more interesting things, but for the moment here is it:

  1. Kinect 1.0 libs were only distributed though SKD download. For Kinect 2.0 many libraries are actually distributed though NuGet. No more Microsoft.Kinect.Toolkit.dll in real projects. Yay.
  2. Kinect 2.0 has gestures support built-in. It provides tooling to teach it with new gestures. I do not know if SDK will have some gestures built in, but this is good start. It uses ML instead of heuristics so possible it will work for not so obvious gestures. Gestures support is actually what I will research next week. Wish me lack.
  3. More points to track. For example it now tracks your big thumb.
  4. Better quality of the depth stream. I hope this will boost implementations of small gesture detection like sign language.


  1. MVVM is still hot. Also I tried MVVM Light and well… do not feel that it provides more value then it requires to learn. So probably next time vanilla MVVM.
  2. Open source WPF controls in general are very low quality. Many of them is not even on NuGet. After tons of HTML controls and frameworks it looks disappointing.
  3. WebBrowser control does not work with WPF layouts. Disappointing. Awesomium has issues with rendering in full screen at least on my computer. Actually I was not able to find solution that will be able to show local HTML and feel natural to WPF.
  4. Grid is quite ok, but for now CSS grid systems found a way better expression of such layouts. Syntax of CSS grids is more simple and less verbose.


It is first time I work for production AngualrJS. My findings could be naїve, but anyways.

  1. I was able to start quite fast. Two way binding, templates in HTML, ng- attributes looks dirty but they work.
  2. It is more or less easy to learn when you have template or example. For me it is very hard to remember all this directives and assumptions that AngularJS put on you.
  3. Looks like nice and free introduction course for AngularJS on CodeSchool.
  4. Hope AngualJS 2.0 will do better.
  5. There is no EventEmmiter built. Quite sad. And because of lack of normal modules you cannot use something that does not made with AngularJS in mind.


  1. I found amusing where Adelaide located. I failed even with continent.


  1. I tried to build mock screens with actual HTML. It uses Twitter Bootstrap and few other JS frameworks(e.g. ChartJS). It uses real links for navigation. And result looks very good. You need bower install before user. It even have responsive design! Examples screens in docx(sic!) format.
  2. Solidworks has very bad API for automation for .NET. Full of unobvious states magic strings and so on. And for the end methods with 27 parameters without default values and names like dX1, rQur and so on.
Tagged , ,

Apache Thrift journey on .NET

I needed fast protocol for cross-process communication. There are many options, and Apache Thrift one of them. So I decided to give it a try. This is quote from project site:

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.

How to start

First thing to know is that Thrift has simple DSL to define contracts and called the Thrift interface description language (IDL). DSL is quite powerful and self explanatory. Most easy way to get familiar with syntax is to read tutorial.thift. Another place to learn it IDL page. For playing purposes you may end with something like this (default file extension is .thrift):

namespace csharp PlayWithThrift.Contracts

struct Work {
  1: i32 num1 = 0
  2: i32 num2
  3: optional string comment

service Calculator {   
   i32 add(1:Work work)   

Save this to something like test.thrift. IDL file can also have service(RPC) definitions, enums, namespaces and constants. You can use inheritance and include other thrift files.

Second is how to turn IDL file to something that can work. Thrift uses code generation to produce DTOs, serializers for them, client and server classes. To generate code Apache Thrift compiler is necessary. You can download one from downloads page. Or if you have Chocolatey installed, just use:

cinst thrift

This will add thrift to your PATH, so you can just use thrift executable form anywhere. So to compile our test.thrift execute:

thrift --gen csharp test.thrift

Result will be in gen_csharp folder. I should say result is ugly, but a bit later on this.

Now, third. Now when we have code in place, lets make it dance.  First of all you need implementation of the server side. It uses ugly named interfaces, but let us pretend that all is good. We have only one method defined and so has implementation:

public class CalculatorHandler : Calculator.Iface
    public int add(Work work)
        Console.WriteLine("add({0},{1}) // {2}", 
            work.Num1, work.Num2, work.Comment);
        return work.Num1 + work.Num2;

Now it is time to start serving stuff to the wire!

    var handler = new CalculatorHandler();
    var processor = new Calculator.Processor(handler);
    var serverTransport = new TServerSocket(9090);
    var server = new TSimpleServer(processor, serverTransport);

    // Use this for a multithreaded server
    // server = new TThreadPoolServer(processor, serverTransport);

catch (Exception ex)

And finally client part:

using (var transport = new TSocket("localhost", 9090))
    var protocol = new TBinaryProtocol(transport);
    var client = new Calculator.Client(protocol);


    var sum = client.add(new Work
        Num1 = 12,
        Num2 = 13
    Console.WriteLine("12+13={0}", sum);    



When run compiler, you might get error:

[ERROR:C:/Users/Mike/Projects/PlayWithThrift/PlayWithThrift/ContractMsg.thrift:1] (last token was ‘∩’)

Unexpected token in input: "∩"

It looks like this means that you have unsupported encoding for thrift file. Change it to something without signature fixes the problem.

Main problems

  1. Generated code is awful, strange naming conventions, strange base classes. Lack of correct capitalization. And T prefix – it probably means Thrift, but for me it reminds Delphi. Async code is generated only under SILVERLIGT symbol.
  2. Lack of UTF-8 support for .thrift files
  3. Looks like implementation is blocking


There is no love at first sight. Usability is quite good, but implementation kills the whole idea. I will try to find better implementations for my needs. Next is probably protobuf.

Please note, Apache Thrift project permanently moves all things around. So many links to tutorials, readmes repositories may not be available at the time of reading. Ping me with any problem, I will update post.