Category Archives: applied coffee making

Peephole security camera from old Android phone


This post is about how to properly recycle your old Android smartphone. By “recycling” I mean not tossing it in the bin at your local electronic store, but giving it a proper new use. It’s been only a few years since explosive expansion of smartphones began, but already a lot of us have one or two “old” models lying around gathering dust. If you give it a bit of thought, you realize that it’s a highly capable supercomputer you have there doing absolutely nothing! People have been flown to the Moon and back using less computing power that your old pocket companion has! I think these old-ish smartphones are great platform for something very useful. For instance, even older ones have quite a decent camera, support several network standards and, when connected to a power source, have a battery-backed power that will allow them to run for hours. It’s a great platform for highly autonomous and powerful surveillance system! Ladies and gentleman, I am proud to present you  the “Peephole Security Camera” application for Android. Get it on Google Play, enter your e-mail in settings and you get yourself an automatic assistant that can be left watching your house when you are out. Unlike most video-surveillance systems that accumulate hours of mostly static video you’ll never watch, it works in a lot smarter way. It analyzes video feed from device’s camera to detect motion in a picture. When something moves, you get an instant e-mail with a few images in it, and it will keep taking pictures and sending you updates until motion stops. And that’s all most people ever need from remove surveillance system.

Use cases

Peephole camera

That was the original intention for this app. It requires no modification to your peephole or your door, just get a pack of these highly versatile Velcro strips with adhesive layer. Attach them to the back of the phone IMG_9685 Read more »

(Русский) Юнит-тестирование. Всем чтить!

Sorry, this entry is only available in Russian.

(Русский) Код: до и после н.э. Зачем на самом деле нужны юнит-тесты.

Sorry, this entry is only available in Russian.

Useful C++ template magic. Hiding nasty global static’s

In C++, often there is a need to provide and support single instance of certain class, accessible on demand from anywhere in the program. That is encyclopedic example given in many books promoting singleton pattern. For instance, if your program has a log file, it is strongly recommended that you make a class that encapsulates all logging and make it singleton. This approach, without any doubts, is much much better than making global static instance of the logger and then referring to it from whatever you need as it reduces number of cross-dependencies, an issue that stays among the most bad techniques making code less maintainable.

This is easy to understand – while there is nothing wrong in static variable, even in global static variable, we must ensure that it is initialized before it is used first, which is especially important if the object has to be created dynamically. And this is the problem Singleton pattern solves.

Take the example

// SomeSourceFile.h
#include "CoffeePlantation.h"
static CoffeePlantation g_Plantation;

// SomeSourceFile.cpp
#include "SomeSourceFile.h"
// Initialize the instance
g_Plantation = CoffeePlantation();

 Note: coffee plantation...
Note – coffee plantation object is created on a stack. Plantation’s constructor will be called before main() and, presumably, any other code that uses g_Plantation. But in order to use this single plantation, you’ll must include this “SomeSourceFile.h” into every file when it is or may be referred from. Moreover, once you added more global statics, you may get lost is you sources as you’ll need to keep in mind which header declares what variable. Having single common header file may help a little, though, but not always.

From the other hand, there are still heaps of cases when you’d rather use global static variable for certain need. For instance, pattern “State” (see “Design patterns” by GoF) assumes that all object represent states have to implement singleton pattern. But at the closer look you may realize that it makes code unnecessary complex and bulky – state machine of that kind assumes that all transitions and states are already known, they don’t change in runtime and can be created once-and-for-all, in other words, they must be static.

Right, how we handle this situation then?

Well, it’s about the time when “template” word, so many developers are still afraid of, should be addressed. C++ template is a great way to ask compiler to generate as many synthetic data types as we want exactly when we need them. For instance, vectorand vectorare two different data types. Which meaning does it have for our task?

Check this out:

// file name: StaticInstance.htemplate 
class  tStaticInstance
        static T* GetInstance();
        static T m_Instance;

T tStaticInstance::m_Instance = T();

That’s it. That’s really all we need to hide ugly global static behind nice looking fence. Now, instead of declaring static variable in designated header and then pushing it *.h around the project, just do this:

#include "StaticInstance.h"/// somewhere somewhentStaticInstance::GetInstance()->SomeMethod();


This code may look a bit scary, but it solves the whole bunch of problems:

  • There is no need to modify either of MyConcreteType or OtherType to implement singleton functionality they may not need generally.
  • Global static variable can be “created” from any place in your program without the need of declaring it anywhere else
  • Does not have singleton’s weaknesses
  • This expression clearly explains that in this particular place we wanted to deal with single global instance of the class. There are quite a few cases when it may be useful
  • Code is very simple
  • Static objects are created automatically and only if they are used. Unlike the case with implicit static declaration, it is now impossible to declare an object that is never used.

Of course, there is a price to pay:

  • The uniqueness of the instance is only guaranteed within single binary and we fully rely on modern compiler and linker
  • Object gets created once a construction with tStaticInstance::GetInstance() appears in the code, even if that code is never going to be used (which is quite bad by itself) or gets called once in a blue moon.

It is also not idiot-proof:

MyType pInstance* = tStaticInstance::GetInstance();

delete pInstance;     // Something bad happens here

That delete will lead to crash, but it will be trivial to track down and fix. You write unit test for you code, aren’t you?

I have been using this pattern in several projects and it works just fine, assuming that it is intended for occasions where your code is allowed to know that is deals with static instance of the class.

Having said that, this is how I would deal with my coffee plantation:

// CoffeeHarvester.h
#include "CoffeePlantation.h"
#include "StaticInstance.h"
// ...
0 visitors online now
0 guests, 0 bots, 0 members