Simplicity is complicated. In the Golang community, this statement is most often
attributed to Rob Pike
but it turns out a lot of people said something like that. A couple of weeks ago
I encountered this yet again in a debate with a colleague (someone with lots of
experience and whose opinion I respect a lot). Both of us considered ourselves
advocates for simplicity, yet we were leaning towards radically different
technical approaches. Both, of course, were sure that our own solution is much
simpler than the other, and even had a good set of technical arguments to
Without going into too many details, we needed a bunch of small business logic
snippets executed ever so often against a certain dataset. The whole thing was
supposed to be pretty small and simple (no high-load, out of the critical path,
latency insensitive, etc.), so the main concern was to minimize maintenance and
debugging effort. In this particular case, the language was Go, but frankly, this
can be applied to any language. The two options at the table were:
Define a concrete struct type to hold snippet metadata and snippets
themselves would be stand-alone, stateless functions. Execution manager will
be another struct that would hold a list of snippets and manage their
execution. The execution manager would also hold a bundle of all extra
dependencies (e.g. static data, RPC clients, etc.) a snippet function might
need and that bundle would be passed over to all snippets as a function argument.
Pros: Everything is explicit and visible at-a-glance: all external
dependencies (which should be very few) are in one place, every snippet is a
stateless function; minimal amount of indirection. Concrete implementation
leaves minimal amount of “creative freedom” for those who will be writing
the snippets, discouraging them from using the system for things it wasn’t
supposed to be used for.
Read more →
Not so long ago I’ve discovered FSEconomy, an economy meta-gate for flightsim fans. Despite of somewhat simplistic core mechanics and unfancy look, it has a very active community and a lot of depth to it. I’ve spent last couple of weeks reading the manual, watching community forums and doing some assignments in the game itself. And the more I was learning the more questions I was having: where to fly? Which aircraft? Rent, buy or lease? What about FBOs? How to find the best assignments? The manual and community forums have some advices, but I want more definite answers.
I mean, staying net positive is not so difficult, but being efficient is a whole another story. And I want to be as efficient as I can. Luckily, FSE offers a treasure trove of data to support decision-making in a form of data feeds. So I armed myself with Python and spend a few evenings getting some answers.
Since I’m still quite a noob in this game, my high-level plan is this:
- Find the most efficient way to build up initial capital without owning any assets.
- Find out which assets (FBOs or aircraft, which ones) would provide the most significant cost reduction.
- Invest and explore less involved methods of gaining revenue: rent/lease business, FBOs and all other fun.
Read more →
Recently I’ve stumbled upon a code snippet in my C++ code, which I’d call “comment branching”. For example, you are experimenting with two implementations of the same functionality represented by a relatively small pieces of code and you need to switch between them back and forth until you decide which one will end up in final version.
Consider following snippet:
If you simply remove first slash from the second line, it turns into this:
Read more →
Finally, I’ve completed transition of this blog to GitHub pages, planned over two years ago. I did the first step — migration to a static site engine (specifically, Acrylamid) — back in March 2014. And since than I’ve been saying to myself “one day I must move it to a GitHub as it’s a best free hosting for a static site”.
I couldn’t tell for how long I’d continue slacking like this, but now I had to do this. This site was hosted at free hosting service provided by EOMY.net since it’s very beginning and recently I’ve received a notification, that EOMY shuts down it’s shared hosting, completely focusing on VDS. It’s a bit sad news, as EOMY managed to provide fantastically stable and reliable hosting for all this years, so great thank you for them and good luck with VDS business!
By the way, I have plans on implementing an automated process of site generation and deployment using TravisCI the way it’s done for GCB-JS. If i do this, I’d be able to blog right from GitHub interface, which would be pretty cool :-)
In a past few years I’ve been using C++ as my main programming language and during this time I’ve been in constant search for better IDE for it which would run on Linux. I was very happy when Jetbrains released CLion IDE and immediately gave it a try. Though there is a lot to improve yet, I’d say that it has best autocompletion and modern C++ support among C++ IDEs on Linux. The only problem I had with it was a build toolchain which it uses.
Currently CLion supports only CMake projects (with is totally fine for me) with GNU Make generator (which is sad). When using CMake, I always preferred Ninja build system, especially for large projects like one I work on as my main job. For some reason Make does not a very good job at incremental builds. For example, even if there is nothing to rebuild, it spends 5 seconds to only verify this fact, which is pretty annoying. On other hand, Ninja does this in like 200 ms.
Unfortunately, CLion developers currently have no plans on supporting Ninja (I realize that they have many things to do way more important than Ninja support), so I decided to solve this problem by myself.
CMake-Ninja wrapper for CLion
Read more →