Давно пишу на питоне. У него есть большое количество несомненных плюсов и минусов. Но за его Дзен, я думаю, стоит ценить особенно. Как так просто и компактно можно сформулировать идеологию языка?

Красивое лучше, чем уродливое.
Явное лучше, чем неявное.
Простое лучше, чем сложное.
Сложное лучше, чем запутанное.
Плоское лучше, чем вложенное.
Разреженное лучше, чем плотное.
Читаемость имеет значение.
Особые случаи не настолько особые, чтобы нарушать правила.
При этом практичность важнее безупречности.
Ошибки никогда не должны замалчиваться.
Если не замалчиваются явно.
Встретив двусмысленность, отбрось искушение угадать.
Должен существовать один — и, желательно, только один — очевидный способ сделать это.
Хотя он поначалу может быть и не очевиден, если вы не голландец (намек на создателя Гвидо ван Россума).
Сейчас лучше, чем никогда.
Хотя никогда зачастую лучше, чем прямо сейчас.
Если реализацию сложно объяснить — идея плоха.
Если реализацию легко объяснить — идея, возможно, хороша.
Пространства имён — отличная вещь! Давайте будем делать их больше!

Полезная тулза под linux и mac os. Создать новую сессию

screen
#CNTRL+A, D - выйти из сессии.
#Подключиться к ранее созданной сессии
screen -r

Бывает, работаешь над задачей долгое время, наделаешь дофигище промежуточных коммитов, потом еще и замечания по ревью поправить не одним придеться.
Хочется все-таки чтобы история была более или менее информативной. Поэтому сквошу коммиты по каким-то крупным фичам.
Для этого есть простой, как по мне, способ:

git fetch # забираем изменения
git merge origin/master # подмерживаем ветку, куда мы делаем в дальнейшем pull request
git reset --soft origin/master # подчищяем ветку и оставляем только изменения
git commit -am "Message text" # коммит все это дело в наш бранч, с хорошим коммит сообщением о сделанных изменениях
git push --force # удаленный репозиторий должен принять все наши изменения

В истории пулл реквеста на битбакете, как показала практика, коммиты остаются, они просто помечаются удаленными, как и замечания по коду.

Из записной книжки мистера Томпкинса
Извращенная политика

1. В любой момент нужно быть готовым отказаться от работы и попросить расчет…
2. …однако это не означает, что тем самым вы сумеете избежать последствий извращенной политики.
3. Извращенная политика достанет вас везде, даже в самой здоровой и чистой организации.
4. Главный признак извращенной политики: во главу угла ставятся личные цели и влияние, а не общие интересы компании.
5. Это может произойти даже тогда, когда личные цели напрямую противоречат целям организации.
6. Один из побочных эффектов извращенной политики: иметь хорошо укомплектованную команду становится небезопасно.

Ограничения на пароли - это клевая идея. Обязательно цифры, заглавные буквы и спец символы. Это увеличивает крипкостойкость и исключает любую возможность брутфорса.
Но почему существуют требования на длину пароля 8-16 символов? Не первый раз с этим сталкиваюсь, и вот снова наткнулся при установке ORIGIN. Зачем?
Теперь снова думай, как мой 16+ символьный пароль сократить или же придумать новый.
Кажется, я снова воспользуюсь функцией восстановления пароля :(

https://habr.com/ru/post/269097/
О роли тимлида в команде.
Очень понравился один из комментариев:
"На самом деле, в команде могут быть программисты, которые сильнее тимлида, но все эти управленческие заботы им даром не нужны."
Тимлид в первую очередь организатор работы команды. Высокий профессиональный уровень (как программиста) может служить поводом заслужить уважение и взять лидерство на себя, но это не обязательный (хоть и важный пункт).

https://habr.com/ru/company/touchinstinct/blog/332056/
Можно ли обойтись без менеджеров в команде? При малом размере команды и достаточно высоком уровне сознательности - да.

Нельзя сделать forward declaration на класс, объявленный через using.

https://en.cppreference.com/w/cpp/memory/shared_ptr/pointer_cast
Down cast shared_ptr

Как автоматизировать тестирование питоновского пакета на разных питонах?
Для этого есть https://tox.readthedocs.io/en/latest/ и https://github.com/pyenv/pyenv.
В tox можно указать все версии питона, на которых следует тестировать, а с помощью pyenv установить любую версию.

Язык Си — как секс для подростков:
— Он у всех на уме
— Все постоянно о нем говорят
— Все думают, что все остальные это делают
— Никто на самом деле этим не занимается

А те немногие, кто правда это делают — делают это плохо, небезопасно и думают, что в следующий раз будет лучше.
:)

IWOMM — It works on my machine!

https://www.appveyor.com/
Клевый инструмент для CI, бесплатен для open source, поддерживает винду и убунту.
Интеграция из коробки с гитхабом.
Пример:
https://github.com/zifter/expression_fetcher/pull/2

Понравился проект? Купи пиво в благодарность!
Именно такой слоган мог бы быть у сервиса https://beerpay.io. По факту это интересный сервис для мейнтейнера опен сорс проекта получить денежное вознаграждение за свои труды.
Со стороны донатера все выглядит очень просто - кидаешь денег за спасибо или кидаешь денег на какие-то фичи, которые можно так же предложить реализовать. Так сказать голосование рублем.
Со стороны мейнтейнера все почти так же радужно, нужно всего лишь:
1. Подключить сервис к своему github аккаунту
2. Указать проект за который хочется получать пожертвования. При этом сервис предложит добавить в README.md бейджи с ссылками (Пример)
3. Подключить аккаут beerpay к аккаунту stripe (новая платежка).
4. Для мейнтейнеров из СНГ - расстроиться, что stripe не доступен для них.
5. Понять, что бесполезен без возможности вывести деньги :)

Наверное все замечали бейджики на страницах проектов github с клевыми статусами "codecoverage 100%", "build: passing", "python: 27".
Зачем это и самое главное как сделать?
Ответ на первый вопрос для меня оказался самым удивительным, так как он нашелся в научной статье, посвящённой конкретно этой теме. Можно посмотреть сокращенную и более удобную для чтения версию здесь.
Авторы разделяют бейджы по типам сигнала, которые они несут:
* уловные - предоставляют информацию или указывают на принятые соглашения (лицензия, стандарт языка, код стайл);
* оценочные - ассоциированы со сторонними сервисами, которые вычисляют какие-либо метрики проекта (тестовое покрытие, статус тестов, свежесть зависимостей).
И на основе проекта npm они статистически доказывают, что есть корреляция между, например, качеством тестового покрытия, свежестью зависимостей и вовлеченностью контрибьютеров. В общем, советую ознакомится.
А вот "как сделать?" оказалось достаточно простым вопросом - есть сервис тех же авторов научной статьи, который позволяет сделать интеграцию с кучей существующих сервисов (travis-ci, teamcity, appveyor, github, pypi, beerpay и пр.). Можно выбрать бейдж из существующих или сделать кастомный. Все элементарно, к счастью 🙂
Если у вас есть своей проект и вы желаете его развивать - смело интегрируейте. И первым, с чем нужно интегрироваться, автоматизированный запуск тестов. Выше я привел пример с appveyor, а дальше будет пост про travis-ci.

DDD - Domain-Driven Design

Как можно поднять приоритет оверлей значка на иконке в Windows? Очевидно же влепив кучу пробелов перед именем оверлея иконки в регистре! Первое место занимает OneDrive с 4-мя пробелами, второе место Dropbox c 3-мя и почетное третье TortoiseGit c 2-мя! Неудачная логика оверлеев иконок приводит вот к таким костылям :( И при этом эти оверлеи иконок постоянно еще и восстанавливаются, если удалять неугодные.

C++
Примеры частых ошибок (по мотивам статьи C++ Antipatterns)
* Чтение из istream без проверки результата
Всегда нужно проверять, что в итоге прочитали, так как велик шанс получить мусор в переменных

int i, j, k;
if (in >> i >> j >> k)
{
  std::cout << calculate(i, j, k);
}

* Проверка istream.eof() в цикле
Мы можем уже достигнуть конца потока при чтении, поэтому правильно проверять результат чтения сразу

while (in >> x)
{
  process(x);
}

* Явная блокировка и разблокировка std::mutex
В примере ниже в случае бросания исключения в секции // do мьютекс не будет освобожден:

std::mutex mtx;
void func()
{
  mtx.lock();
  // do
  mtx.unlock();
}

Поэтому всегда используем RAII для захвата ресурсов

{
  std::lock_guard<std::mutex> lock(mtx);
  // do...
}

* Вставка в контейнер умного указателя через emplace_back(new X)
Если в процессе вставки происходит переаллоцирование памяти, в результате которого неожиданно не хватит памяти, то будет кинуто исключение std::bad_alloc.
В таком случае умный указатель не будет создан, поэтому объект, созданый через new, утечет.
Правильнее сначала создавать умный указатель, а потом его вставлять в контейнер.

{
  v.push_back(std::make_unique<X>())
}

Кстати, здесь безразницы что использовать, emplace_back или push_back.
* Реализция оператора меньше (больше, равно и прочее)
Этот код работать не будет:

inline bool operator<(const X& l, const X& r)
{
  if (l.a < r.a)
    return true;
  if (l.b < r.b)
    return true;
  return false;
}

X x1{1, 2};
X x2{2, 1};
assert( x1 < x2 );
assert( x2 < x1 );

Правильный путь, который гарантирует порядок:

inline bool operator<(const X& l, const X& r)
{
  return l.a < r.a && l.b < r.b;
}

А вот это С++11 try-way

inline bool operator<(const X& l, const X& r)
{
  return std::tie(l.a, l.b) < std::tie(r.a, r.b);
}

* Использование std::string("") для создания пустых строк
Дефолтный конструктор уже создает пустую строку, а вот конструктор с const char *, скорей всего, сделает аллокацию памяти.

В машине мне нравится слушать АвтоРадио, где проигрываются хиты (и не только) рок музыки.
И самое приятное что на приемнике я всегда вижу название и исполнителя песни. Но как? Это ведь радио.
Оказывается, есть стандарт RDS, который описывает передачу информационных сообщений по каналам радиовещания.
Благодаря этому стандарту мы как раз и можем принимать названия станций, исполнителей и песен. Кроме этого можно передавать любую другую текстовую информацию - рекламу, расписание передач, заказчика песни, информацию о дорожной обстановке, предупреждение о чрезвычайных ситуациях. Позволяет слушателю осуществлять поиск интересующих его станций по типу (музыка, развлечение, новости и пр), автоматически настраивать громкость и даже осуществлять навигацию транспорта.
Очень рекомендую почитать для ознакомления
Как кодируется и декодируется сигнал
На что способен и чуть подробностей