Home © Rinat Abdullin 🌟 AI Research · Newsletter · ML Labs · About

Self-Improvement Process

Lately I've been doing a little bit of new and well-forgotten old things, while trying to become a better me. They also help me to reduce work pressure by offering something new for the brain to chew on.

I just wanted to share these things (at least for the sake of writing down the links). We'll talk a little bit about:

  • git;
  • vim;
  • LMAX and Martin Fowler;
  • VerseQ;
  • Lokad.CQRS and functional approach.

Git

I've started using git on a number of new learning projects. As I've mentioned it on a couple of occasions already, I start liking git more than mercurial, despite its steeper learning curve.

By the way, Google Code has finally added git to their project support. Although they are way too much behind github both in usability and commits.

Vim

Subj, the good old editor coming from the terminal era. Exactly the one, where "the best way to generate a random string is to ask a student exit vim" (by the way, it is ":x" to exit with save-if-modified).

I find using it more and more for common text editing tasks. That's where I'm writing articles and blog posts these days.

And I'm getting really tempted to start replacing IDEs with vim in non-.NET environments. Developer's mind is better than any IDE anyway, especially when he or she deliberately keeps projects dead-simple.

Now, if you got interested in vim, then that's what your future will look like. If this didn't scare you, here's a quick intro from the eyes of guy from VS environment.

LMAX and Martin Fowler

It seems that all this CQRS/ES stuff is getting mainstream, since Martin Fowler wrote a bliki post on CQRS and really good overview of LMAX architecture: the latter is essentially an in-memory circular buffer that also acts as a queue for the event sourcing messages; processed by a single writer and multiple readers. All workers have access to each other location pointers and this avoid any locks altogether. Predefined buffer size and one-writer-only approach allows to achieve high hardware affinity (in other words, CPU likes it a lot).

The study is highly recommended for a read.

By the way:

  • bliki is term for versioned blog/wiki coined by Martin Fowler a while ago. These days people just use github with markdown (for example, this Lokad.CQRS Study isn't a page, but just a markdown file in a github repository).
  • Don't read Martin's pounding on branch-per-feature. I believe he got it wrong (and got quite a bit of pounding from the community afterwards).

VerseQ

To keep up with the learning process, I've stepped back on improving my keyboard typing skills. I believe it would be a wise investment of my time to improve on something that is so tightly related to the job and thinking as the typing is. This (when coupled with vim) feels like reducing VS development friction by introducing ReSharper.

For this task I'm currently sticking to VerseQ, which was recommended to me by Vsevolod. VerseQ tutor simply keeps on generating pseudo-random strings for you to type. However these strings are not entirely random:

  • they include chords common to the language you practice (i.e.: "jg" is not common to English, while "li" is more common);
  • next random string is based on the statistics captured so far. It will force you to practice your slowest keys and key combinations (or most erroneous ones).

Recommended to give it a try, if you are typing more than 50 lines of text per day (emails or code alike).

Functional Stuff

In the previous post I've mentioned that it is possible to get a whooping number of messages per second on a single thread in Lokad.CQRS using lambda dispatchers. This comes from a simple realization that everything is either an aggregate/saga or a function. For example, handlers are just functions partially resolved from the container and executed against the message.

Now, to be true with this kind of development you can easily achieve much higher throughput, if you switched to some other platform. I'm currently looking at akka for the small specific cases where extremely high performance would be needed (i.e.: message routing for Lokad.CQRS or doing some high-frequency data transfer). Fortunately enough, envelope and data formats of Lokad.CQRS are relatively cross-platform (protobuf to the rescue).

With akka you can get something like a few millions of messages processed per second. The latter might be another life-saving option for devs and start-ups (constrained on resources) who are using Lokad.CQRS and are hitting some throughput limitations on elements of a decoupled/cloud system that are a bit hard/expensive to scale (load balancers and routers, for instance).

Obviously I'm not planning to switch anything in Lokad.CQRS to akka and dead-simple functions editable in vim (no matter how tempting this might look, there always are real-world costs associated with such dreams). Yet, where possible to simplify things (i.e.: by throwing another framework out of the window) the experience and ideas will be reused in the approach. Especially, if they provide a clear and simple path of massively boosting performance of certain nodes in a decoupled app by switching them to the non.NET stacks.

PS: if you post a comment and it does not show up within a day, please drop me a line. I get the feeling Squarespace has messed up it's spam protection badly again.

Published: July 17, 2011.

🤗 Check out my newsletter! It is about building products with ChatGPT and LLMs: latest news, technical insights and my journey. Check out it out