Kirill Pimenov kirushik

Где-то уже недели 4 (с тех пор как у меня самого "щёлкнуло") я уделяю 3-5 часов в неделю тренировке подчинённых (и, при случае, более "отдалённых" коллег) пониманию связи ролей, интересов и практик — и удержанию во внимании связанных с этим изменений. Естественно, это подводит их к пересмотру собственных практик и планированию постепенного (и согласованного между разными людьми/командами!) обновления их стека.

Важная практика, которую приходится ставить практически "с нуля" (с очень примитивной, нигде не описанной, ad-hoc системы, наросшей эволюционно без какого-то дизайна для затыкания дырок "в моменте") — управление знаниями (knowledge management). Команда растёт, проекты и задачи всё более разнообразны — и полагаться на дедовские методы ("я просто подсмотрю в коде" и "я найду, у кого спросить" в основном) больше не выходит.

При этом большая часть "традиционных" knowledge management практик очевидно противоречат остальным инженерным Agile-практикам, который мы применяем: "по классике" Agile предполагает

Уже какое-то время я применяю подходы системного мышления ко всему прочитанному “менеджерскому” нон-фикшену, и не могу остановиться.

Эффект забавный: ментальная реинтерпретация в категориях системного подхода делает многие статьи не только компаче, но и гораздо тривиальнее, нежели оригинальное авторское изложение.

Я несколько беспокоюсь что эта тривиализация на самом деле сжатие с сильными потерями (и я рискую недобрать опыта, читая статьи таким образом — там же мог быть какой-то слой мудрости/опыта, который потерялся при интерпретации).

Отсюда и афоризм в заголовке; но я успокаиваю себя тем, что (по крайней мере пока) мне полезнее получить пусть несколько обеднённую, но консистентную картинку менеджмента в голове — это заметно лучше, чем никакой.

А то обычно менеджмент размножается по мозгам абсолютно бессистемно, в формате афоризмов ("Учить → Лечить → Мочить" для разрешения проблем с Командой) и анекдотов из жизни (все эти “кейсы из практики”), и далеко не любая книга (что уж говорить про более мелкую

Самое полезное для меня в курсе пока — пятнадцатиминутное упражнение по выделению моих основных рабочих ролей и распределению времени по ним. Тут как с тренировками с тренером в спортзале — нет ничего такого, что нельзя бы было делать самому, но “в серии из десяти отжиманий самое последнее — одиннадцатое”, и (по крайней мере мне) нужен кто-то внешний, чтобы "дожать".

За эту неделю я успел начать сразу несколько процессов, чтобы сместить баланс времени в пользу ролей, в которых меня трудно/невозможно заменить. Для этого, как вполне очевидно, я работаю над уменьшением времени, приходящегося на роли, в которых меня з

(Большое спасибо одногруппнику Петру за разговор, который заставил меня полностью переосмыслить прочитанное и выбросить прошлый вариант этого текста.)

Довольно несложно понять, почему книга даётся в качестве “входной” литературы к курсу системного мышления (на самом деле — даже нижележащего по стеку курса онтологики и коммуникации):

Автор работает в какой-то своей, достаточно уникальной терминологии. В частности, его истолкование ключевого термина Object-Oriented достаточно далеко как от “типового” понимания в современной индустрии, так и от оригинального значения этого термина, введённого Аланом Кеем (который описывал этим системы из акторов и шин передачи сообщений, см. например http://xahlee.info/comp/Alan_Kay_on_object_oriented_programing.html). Более того, в предисловии ко второму изданию автор честно признаётся, что изначально использовал слово “парадигма” в значении “онтология” — но ко второму изданию переименовал всё обратно (а на самом деле — не всё, и “уши” оригинальных именований проступают

Keybase proof

I hereby claim:

I am kirushik on github.
I am kirushik (https://keybase.io/kirushik) on keybase.
I have a public key whose fingerprint is 655D F5CB FECD 6718 CFC8 2949 FBF0 C4CB 6A37 5D79

To claim this, I am signing this object:

Keybase proof

I hereby claim:

I am kirushik on github.
I am kirushik (https://keybase.io/kirushik) on keybase.
I have a public key ASBISvcxSpUwUP5DhJqCMHuGjL0JsrP9FUuJd2WtGpm-pQo

To claim this, I am signing this object:

Баллада о Бравом Блокчейне

Автор — [email protected]
Лицензия — CC BY-SA 4.0, https://creativecommons.org/licenses/by-sa/4.0/deed.ru

Во-первых, гит — это тоже такой себе блокчейн.

Собственно блок-чейн, цепочка блоков — это структура, где каждое текущее положение определяется хешем, который вычисляется из прошлого по функции new_block = hash(old_block+metadata+data)

Где data — это собственно полезная нагрузка, скажем информация из каких файлов в какие какие строки переместились, или с каких кошельков на какие деньги переводятся.

	New GPG key for [email protected] email

	At Parity we’re always looking for ways to improve our security. As phishing exploits continue increasing in sophistication, we have been thinking about how to ensure the trustability of our critical security messages.

	We receive critical security messages through [email protected]. In order to ensure that the recipient can trust that we are the only receiver of these emails, they encrypt their message with GPG keys, which enable signing and encrypting emails.

	GPG keys have a two-year lifespan. While it’s possible to extend the lifetime of the keys, when facing the end of our [email protected] key lifespan, out of an abundance of caution, we decided to issue a new key instead of extending the existing key.

	Up until Sunday July 21, 2019, our [email protected] GPG key has this fingerprint:
	DAE5 1560 28CF 37A0 7C69 3883 5D0F 0301 8D07 DE73

	#!/usr/bin/env ruby

	require 'rubygems'
	require 'mechanize'
	require 'uri'

	a = Mechanize.new

	root = URI.parse('https://en.wikipedia.org/wiki/List_of_Star_Trek:_The_Next_Generation_episodes')

	#!/bin/bash

	gnote --search="`xsel`"