Giving up to Visual Studio Code

About a month ago I decided to give it a try with some modern code editor than my favorite VIM+TMux combo. And after some research I chose VS Code.

It's lean, it's fast, and it has the Console built-in, so no need for TMux.

It also has the Intellisense working fine with Python, which is a must.

Finally, it has several VIM-emulation plugins allowing to use the most important VIM motions:
h,j,k,l, /, gg, G, [n]g, etc.

Setting it up is very straightforward.

I usually run it from iTerm2 terminal under a virtual environment, so that the packages, dependencies, and python version is correctly recognized.

Vim + Tmux on Mac OS - an IDE

Per directory configuration for VIM

The standard article that describes how the per-directory configuration works

http://vim.wikia.com/wiki/Open_vimrc_file

Add copy/past support in Vim + Tmux 

https://evertpot.com/osx-tmux-vim-copy-paste-clipboard/

Setup on Mac + brew for python

• install iTerm2
• install Vim (brew install vim)
• install tmux (brew install vim)
• install Vundle ( see https://github.com/VundleVim/Vundle.vim)
• update .vimrc (see https://gist.github.com/amamaenko/f427c633c1e0cb1505ea5e25e667998f) 

Use Case

Use sesssions of Tmux and per-directory configuration of Vim to enable current directory

How many Acceptance Tests do I need?

[Upd. 11 Dec, 16]: fixed the naming of Integration Tests erroneously used by me to the more appropriate "Acceptance Tests".
[Upd. 16 Dec, 16]: changed "fork" to "branch" for the flow

Overview

This post describes one of the guiding quantitative principles that I have regarding writing acceptance tests, and that helps to understand how "good" my acceptance tests are.

The principle is: "I need a separate auto-test for every branch in the business logic flow."

I started forming these principles back in the days when I was still mainly a coder, regardless my title then, continued through my managerial career, and are currently unceasing to develop, while I am doing coding for a hobby. So I have a positive experience with it both first-hand both during authoring the code itself and looking at the resulting product from a more high-level, managerial perspective.

Terminology

• Auto-tests - any test that is scripted in a computer language and executed automatically at will
• Acceptance Tests - a subset of auto-tests where the scripted operations are expressed in high-level domain terms

When to start writing tests?

When starting to work on an application, an engineer typically analyzes the future structure and thinks through the architecture. At this point we have key components and data structures figured out.

The next step is to understand the data flow between key components. Sometimes it is a simple one-way flow, and sometimes it's a complicated web of two-way flows. Outcome of this phase is a list of all interactions between components.

Step three is to try and model the application model composed of the components and data flows on a sample input. This is the point where one should start writing auto-tests. The process of application design reduces intricacies of code into a limited set of domain-specific terms. Thus, first tests should be an expression of desired business logic in those high-level terms.  I call them the Acceptance Tests.

Separate auto-test for every branch in the flow

If I am designing a chat bot that helps the user to figure out the best route from point A to point B then my business logic will be the following:

1. Wait until requested by a user
2. Get A from the user
3. Check if A is valid, if not - return to step 2
4. Get B from the user
5. Check if B is valid, if not - return to step 2
6. Compute the best route(s)
7. Display the result to the user
8. Wait until the next request

This is a fairly straightforward application with only two branch points. At the steps 3, and 5 my application validates user input against some input data template and returns to the previous step if the user's input is invalid. This is important when writing Integration Tests.

Test scripts must be non-branching. That is, for each condition with two possible outcomes there should be two separate scripts execution. Each execution is making sure that it checks its test condition. In our example that means 4 auto-test execution passing through all possible workflows.

Note that having no branches does not mean that one cannot parametrize scripts or not using any predefined fixtures! Rather it means that to test the logic properly auto-tests must walk through each scenario. That gives me at least four separate scenarios.

Plain-text email experiment

[20161115]
About two weeks ago I started an experiment of using only plain-text in my emails. The rationale behind this experiment is that in 2016 AD terminal-based apps seem to be the one most efficient way to compose information-rich messages including code, documentation, and even diagrams.

- VIM seems to be my favorite choice for text editor
- Mutt seems to be my favorite email client

However, using mutt after long history of html-based editors (gmail, MS Outlook, etc.) is not that easy, so before switching to that thing of beauty completely, I'd like to see for myself that plain-text indeed is a good choice for a crazy working environment of a project manager.

Couple of things that I learned so far:

* [Nov 15] Most people do not realize that I am using plain-text only mode, so they keep sending back HTML-formatted messages that break the thread
* [Dec 02] Email clients are not too great at handling hard line breaks. If one changes the windows size, then the client would add soft breaks that will look ugly combined with hard ones

Methodologies are text-books, not religious texts

Here we go. Another team to manage. It always starts with the same pattern: engineers are cautious to their new manager and they have a good reason to be.

...And the methodology practitioners are teachers rather than priests. That is - its no magic how they are working in real life.

Each of them - from RUP to XP - are thought-out combinations of ideas that work in concert.

The articles like "Top 7 programmers bad habits", or similar "Top 10 errors", "Top 23 tit-bis", etc. are no harm, of course. But these are too shallow, unlike books on coding practices, such as The pragmatic programmer, or The Mythical Man-Month they resemble Grand-Mother's advice rather than sound technology.

Who has the time to teach

This is a post of bitterness. Just realized that the hardest part to teaching is to find a time for this. The more knowledge one gets to share - the less time he has to spend sharing. Or ,ay be it's a question of greed? When someone gets his knowledge for himself only, he gets more greedy and greedy and is not very willing to share.

Setting up vim on Fedora 17

Introduction

Dealing with setting up vim to work according to my tastes on Fedora 17 First of all replaced the standard compact vim (does not include syntax highlighting for example) with the full package, using this article as a cheat-sheet: http://www.if-not-true-then-false.com/2012/vi-vim-syntax-highlighting-on-fedora-centos-red-hat-rhel Then modified some settings looking at another article for the rough outline: http://www.slackorama.com/projects/vim/vimrc.html

Yet another useful setting to enable autoindent in c-style:

set cindent

More info: http://vim.wikia.com/wiki/Indenting_source_code

Configuring for make files

By default I configured vim for using expandtab option to expand tabs into spaces. That would work perfectly in Python but cause some troubles when working with make-files as they use Tab symbol as command-separator. To work around this I created a file-type plug-in for make files. On Fedora it means creating a ~/.vim/ftdetect/ folder and putting file named make.vim in there. This file only contains one line:

au BufRead,BufNewFile make  set filetype=make

This detection would run before loading the ~/.vimrc file, and condition for the expandtab is set as following:

:if &ft != "make"

:    set expandtab    " spaces instead of tabs

:endif

All pretty straightforward.

 

Setting up mp3 on Fedora

Just installed Fedora 17 onto my home desktop. Frankly there are some annoying mishaps in usage, but they are totally compensated for me by all the perks a Linux can give to an advanced user. Another surprise came when I realized there is no "simple" way of installing mp3 codec on Fedora 17. Codec for GStreamer that includes mp3 and many more is considered to be "ugly" and is not distributed over Fedora package manager. However, one can get it from rpmfusion. See details on rpmfusion page http://rpmfusion.org/Configuration

Software Development as Diplomacy

Seriousely, the world of software is a complicated environment, made out of tiny bits of other people's work. And much more often than producing a truly novel program, the software developer poises as a diplomat trying to arrange negotiated peace in between those modules developed by others.

API is the language of one culture, and making use of it to connect to another API takes no less effort than figuring out how to make Israelis, and Palestinians withstanding each other without an open confrontation.

How to build Python modules with MinGW

Often a Python module includes C/C++ libraries that have to be built using a C/C++ compiler. That might lead to problems on Windows, when resulting .DLL libraries conflict if built with a "wrong" compiler http://boodebr.org/main/python/build-windows-extensions

I prefer using MinGW compiler for all libraries. To make it default building instrument there is an instruction (from boodebr.org)

To use the Cygwin/MinGW compiler when building Python module, create a file c:\frank\py25\lib\distutils\distutils.cfg:

[build]
compiler = mingw32

Now just execute setup.py file on the module, and it will do the rest