Why I want an autopilot in my racing drone

About a year ago Hobbyking was having one of their "Flash Sale" events. During a few days, they dropped prices on a few hundred items. An online shopaholic in me couldn't miss it. I meticulously studied the offerings until I found something worthy of my attention and money. That was a Jumper 218 Pro racing quadcopter, almost ready to run. A bargain at a just a bit over $100! I just needed to add an RC receiver.

Jumper 218 Pro Quadcopter

I received it a few days later and, as it often happens, put it on a shelf for a few months. From time to time I would take it off the shelf, hold it in my hands, make a few plans for it, and then put it back. At the time I was still concentrating on building my Alien 560 quadcopter, and the smaller drone was a distraction. The "project Alien" appeared to be never-ending. Every time I flew it, I saw a way to improve it. I would disassemble the copter and work on it for a week or two. Then put it back together, fly it, and then dismantle again. Only when I crashed the Alien, I decided to take a break from it and turned my attention to the Jumper.

more ...

Mocking same module ES6 dependencies

There is a subtle issue for which, unfortunately, neither ES6 nor proxyquire provide a solution. It is well described in this stackoverflow.com answer. So far in the previous articles of the series, the dependencies we were mocking were in a separate module from the code we were unit testing. But what if they were in the same module? more ...


Mocking ES6 module dependencies with proxyquire

In part one, I wrote about mocking ES6 module dependencies using the ES6 native import * from construct. It works mostly fine. However, you need to be aware of a potential issue:

  • You need to import modules to mock them, which means that those modules will be evaluated. That may be a problem if you don't want the code in this modules to be executed.

Another method I found to work well is using proxyquire.  It is one of many libraries aiming to streamline mocking dependencies to simplify unit testing. more ...


Mocking ES6 module dependencies with import * from

Not so long ago I faced a problem: I needed to mock ES6 module’s dependencies for unit testing. The reason for mocking dependencies in unit tests is the following: when I write a unit test, I want to test the functionality of a single unit of code, hence a unit test. However, if a module has any dependencies, those dependencies need be satisfied. That may mean importing and executing code in other modules. As a result, the unit test loses its purity – the test results will depend not only on the module I’m focusing on but also on the other code my module depends on. more ...


My midlife crisis

My new Evolve skateboard and I

They say every man goes through a midlife crisis. They used to be associated with flashy purchases like fast cars or motorbikes. But recently a new trend started to emerge. Generation X men coming into a mid-age increasingly choose carbon fibre bicycles over Porsches. This is in part because of the financial pressure - there has been no real wage growth over the last few decades, and at the same time, a larger proportion of the income needs to be allocated towards mortgage payments and other living expenses. Besides, men are chasing their youth, which is the essence of a midlife crisis, while Porsches are frowned upon as a sign of old age since only older men can afford them.

But every man is different. I honestly thought that my midlife crisis was behind me without any flashy manifestations. Well, I bought a red car ten years ago but it doesn't count (sort of, right?). As for a bicycle, I have never been a bike person. I had a decent bicycle, but I barely rode it, and most of the time it was just idly sitting in my garage. Moreover, a geek should have a special kind of geeky midlife crisis, or otherwise, what's the fun in it? more ...