Нужно ли слушать пользователя или не нужно? Конечно же, «слушать» не означает созваниваться лично с каждым пользователем и внимательно выслушивать как вчера рожала его кошка, нет. Разнообразные метрики и всевозможные выводы, собранные со статистики тоже попадают под определение «слушать пользователя».

Вроде бы здравый смысл подсказывает, что пользователи очень часто просят какую-то ересь. Этот же здравый смысл говорит, что по метрикам и статистике можно иногда сделать очень удачные выводы. И гарантировать правильные результаты не поможет ни тот ни тот метод общения с пользователем.

Знаете кто лучше всего знает как делать ваш продукт? Вы. Пользователи могут хотеть вполне здравые вещи в их случае, но совершенно бессмысленные для развития продукта. Тут, наверное, уместнее всего вспомнить Генри Форда и его «более быструю лошадь», но в современном мире она звучит так: «Если бы я делал все то, что хотят пользователи, то мы бы получили более красивенький эксель».

Одно из фундаментальных правил разработки приложений базируется на том, что разработка ведётся, основываясь на настроении текущих клиентах и будущих возможных.

Но есть у данного правила неправильное толкование, в котором разрешается сделать любую фичу как угодно. И только потом слушать жалобы пользователей и внести коррективы.

Во-первых такие итерационные изменения могут привести совсем не к тому результату, к которому хотелось бы. В «Эктраполяции» уже была заметка по этому поводу.

Во-вторых пользователи не любят изменения. Они любят новые фичи только тогда, когда их старые любимые фичи остаются такими, к которым они привыкли.

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

Наконец-то, пройдя семь кругов монтажа и правок, пилотный выпуск шоу «Lambda Night Show» состоялся.

Будущее этого шоу неопределённое и многое зависит от вас. Формат шоу тоже наверняка претерпит изменения, согласно ваши отзывам.

Итак, что я вас прошу сделать:

1. Подпишитесь на канал. Много видео там не выходит, а увеличивающиеся количество подписчиков — это первый стимул снимать ещё выпуски.
2. Поделитесь этим шоу (или форвард этого поста в телеграме сделайте) с друзьями. Больше просмотров, больше лайков — больше стимула снимать шоу дальше.
3. Расскажите что вам понравилось и что не понравилось. Можно личным сообщением или прям там, на ютубе в комментариях. Мы внимательно читаем все и хотим сделать шоу лучше. Без вас это никак не получится.

Собственно, сам выпуск. Приятного просмотра!

https://youtu.be/zMIyqJkN9aY

Ребята. Мы тут сделали сокс-прокси, для всех нуждающихся. Пользуйтесь и раздавайте друзьям. Бесплатный.

@cimon_proxy_bot

Единственная «проблема тысячелетия», которую можно понять без специальной подготовки, это проблема «N и NP». Когда-то уже была заметка по этому поводу в «экстраполяции». Штука, безусловно, интересная, но к повседневному программированию относится весьма слабо. Кроме, пожалуй, того случая, когда получается квадратичная сложность решения.

Полный перебор — это фактически чистосердечное признание собственной беспомощности. Мол, «ребята, все человечество бьется над тем, как мне перебрать вот эти вот массивчики хоть немного быстрее, чем полный перебор». И вот вам лайвхак: чтобы объяснить, что невозможно сделать так, чтобы вот та вот страничка на сайтике не тормозила, говорите, что это проблема класса NP. Все-равно это никто не сможет опровергнуть.

​​По мотивам предыдущего поста есть замечательная матрица компетентности. Матрица компетентности составляющего матрицы, естесственно.

Это свершилось. Долгожданный второй выпуск «Лямбда Найт Шоу» уже на всех ютубах планеты! Поддержите лайком и репостом, друзья!

Буду признателен за любую критику и замечания. Можно прям в комментариях к видео.

Приятного просмотра.

https://www.youtube.com/watch?v=wHB4q8vtuYg

Работа фрилансера часто сопряжена с массой рисков. В основном, конечно, это риски финансовые или связанные с выполнением обязательств и, как следствие, все-равно финансовыми.
По факту, такие разрабочики пытаются найти компромисс между повышением стоимости своих услуг и открытым недоверием к своим клиентам. Ну, эти всякие «оплата 50% до начала работ», «давайте подпишем контракт, где четко распишем все наезды и предъявы» и «давайте работать через посредников, которые что-то там гарантируют». К слову, такое поведение свойственно не только отдельным фрилансерам, но и аутсорс-командам, потому как сейлз отдел ведёт себя приблизительно так же, как и отдельный фрилансер.

Совершенно понятно почему они себя так ведут и я вовсе не хочу сказать, что эти что-то ужасное.

А вот ужасное то, что такие фрилансеры идут устраиваться на работу и в потенциальном работодателе видят нерадивых клиентов, норовящих их как-то обмануть. И всю свою стратегию поведения строят соответствующим образом. И вот это уже ужасно и с такими людьми не хочется работать вовсе вне зависимости от профессиональных качеств.

Отвечу на вопрос, который задали личным сообщением.

Как по мне, стратегий поведения может быть две: либо «у нас завались работы и становитесь в очередь, клиенты и платите вперёд, в если не хотите, то идите к другим». Либо «у нас простаивают ресурсы и пазязя можно мы ваш проект сделаем, ну очень пазязя. Вот вам скидка и вообще, заплатите только по окончанию, мы все-равно согласимся».

А эти полумеры выглядят, как «я вам не доверяю и практика показывает, что вы плохой клиент. Поэтому мы половину возьмём и если нам что-то не понравится или разонравится, то мы и работы половину сделаем».

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

Ещё, конечно, существует способ оплаты по временным интервалам. Скажем, раз в неделю. И вроде бы он удобнее вообще всем, но речь сейчас не о нем.

Наконец-то смонтировали третий выпуск «Lambda Night Show». Как по мне, он получился лучше предыдущих, но это вы мне расскажите как он получился.

Поддержите лайками и ссылочкой друзьям и коллегам. Спасибо.

https://youtu.be/Mc06z9SsTmo

Один из основных способов коммуникации в проекте естественен для человеческого мышления. Ну, это там, где каждый решает свои проблемы и если для этого нужно знать что происходит в соседнем отделе или нужны результаты работы соседнего подразделения, то этот «каждый» со всех сил старается получить необходимое. Как правило, именно здесь появляются проблемы, вроде того, что «одному мне только тут все и надо, а остальные шевелиться даже не думают». Или когда левая рука делает что-то такое, о чем не догадывается правая.

Болезнь непонятна, симптомы очевидны. И отсюда и появляются правила, которые лечат эти самые симптомы.

- Программисты пилят фичи самостоятельно и не обсуждают решения? Давайте обяжем проводить код-ревью.

- Разбились на маленькие команды и понятия нет что происходит в других командах? Давайте устроим еженедельное собрание тимлидов с обязательным выступлением рт каждого.

- Программист зря зарывается на несколько недель над фичей? Давайте устроим каждодневные письменные отчеты.

- Менеджерам нужны какие-то данные для отчета стейкхолдерам? Утренние митапы решат эту проблему.

Ну, и так далее.

Таких симптомов очень много и лечение многих уже систематизировали и назвали методологиями разработки. И успешно навязывают даже тем, у кого и болезни-то нет.

— Вы используете скрам?
— Нет, у меня в команде только адекватные люди, которые поступают максимально разумно.
— Зря не используете, мне помогло.

Решил поддаться тренду и завёл MTProxy с автопиаром канала. Уверен, что все, кто хотел воспользовался ботом, который бесплатный сокс-прокси раздаёт (@cimon_proxy_bot), но вы здоровски поможете каналу, если порекомендуете наш MTProxy своим друзьям и коллегам. Использовав этот прокси, ваши друзья увидят канал «Экстраполяции» в своём списке каналов и, возможно, подпишутся на него. Спасибо!

https://yangx.top/proxy?server=mtproxy.cimon.pub&port=443&secret=64b764d215a377c1676d3ea45b65fc2d

Категорически неправильно оправлять сообщение непосредственно перед тем, как уйти с рабочего места, хоть такое встречается сплошь и рядом. Ну, это когда «в конце рабочего дня письмо заказчику напишу», «мне пока нечего писать» или «вот доделаю задачу и тогда сразу напишу». И в конце рабочего дня, когда задача еще не доделана и писать все еще нечего, а надо рождаются в муках письма со смыслом «мы делали, делали, но еще не сделали. Есть куча проблем, которые мы героически пытаемся решить». Это, прям, самый ужасный выбор времени для отправки сообщения. Правда, хуже только отсутствие сообщения вообще. А ведь нужно всегда учитывать, что на ваше сообщение и ответить могут!

Самое позднее, когда еще можно отправить сообщение — это где-то за час до того, как закрываете крышку ноутбука. Хорошо писать письма в середине рабочего дня, скажем, сразу после обеда. Конечно же, утренние письма, которые остались должком со вчера, конечно же, не в счет.

Объясняется это очень просто. Собеседник на том конце оптоволокна не всегда готов отвечать и рассчитывать на его молниеносную доступность, впрочем, как и на его отсутствие, мы никак не можем. А вот свою онлайн-доступность мы легко можем просчитать ну хотя бы на пару часов вперед. Вы пишете сообщение, собеседник его читает и, скажем, решает ответить сразу же. Отвечает, а вас уже и след простыл. Как минимум неуважительно и де-факто неэффективно. Имея час в запасе для короткого асинхронного диалога можно выяснить все, что хотелось и с чистой совестью идти отдыхать.

Вроде как все знают, что релизить новую версию в пятницу очень плохо. По той же причине плохо деплоить в шесть часов вечера. С письмами все точно так же.

----

В коммуникациях на расстоянии есть несколько принципиальных отличий от очной коммуникации, которые обязательно нужно учитывать. «Экстраполяция» запускает очередную нерегулярную рубрику «Эктраполяция-коммуникация», в которой можно почитать советы и мнения насчет такого вот взаимодействия в коллективе.

#коммуникация

В тему общения с иностранными партнерами очень хорошо высказался Эдуард Лобас, соведущий в «Вечернем лямбдашоу» и директор компании Webinerds. Очень важно понимать иностранного партнера на том уровне, на котором понимаешь своего хорошего друга. Лайки, подписки, колокольчики и все такое.

https://youtu.be/Riw0XCIh364

Хочу высказать непопулярное мнение в интернете. Аудиосообщения — это очень крутая и полезная фича. Во-первых, их можно переслушивать. Во-вторых, их можно записать, когда нельзя текст набрать. Но есть несколько законов работы с аудиосообщениями, которых крайне желательно придерживаться во время диалога.

1. Аудиосообщения могут быть только ответом на сообщение выше, но никак не первым сообщением диалога. Собеседник должен понимать тему того, что ему предстоит прослушать.

2. Аудиосообщение это всегда хуже, чем текстовое сообщение аналогичного содержания (за редким исключением, когда собеседнику слушать проще, чем читать). Если есть возможность набрать то, что хочется сказать - набирай.

3. Убедись, что вокруг минимум посторонних шумов при записи аудио. Если шумы нельзя убрать — пиши текстом.

4. Сообщения короче пяти секунд не имеют оправдания на существование.

Идеальный пример использования аудиосообщения: коротко описать текстом мысль, а потом сразу после этого голосом рассказать эмоциональные детали.

Четвертый выпуск «Lambda Night Show» с моим участием уже на всех ютубах планеты. Говорим в основном про игры, потому как в гостях у нас продюсер игровой студии Роман Томилин.

К слову, у нас появился режиссер, сценарий и сцена после титров.

Ссылка на полный выпуск

Недостаточная коммуникация — это не причина плохого управления проектом, а тоже симптом. Конечно, «у нас все в проекте плохо, потому что у нас плохая коммуникация», безусловно, немного лучше, чем «у нас все разваливается, потому что нет ежедневных утренних коллективных стэндап-шоу», но все ещё плохо для формулировки Главной Болезни В Проекте.

#коммуникация

Ребята, #коммуникация в «Экстраполяции».

Письмо, как и любое другое сообщение, подчиняется абсолютно всем тем же качествам, что и любое произведение в драматургии. И любое драматургическое произведение делится на пролог, экспозиция, завязка, развитие, кульминация, развязка, эпилог. Этот список и порядок, строго говоря, не являются обязательными, и пролог и эпилог могут вообще отсутствовать. А экспозиция может быть в любом месте и не обязательно целой частью. Получается, что в письме обязаны быть завязка, развитие, кульминация и развязка.

Сегодня будет практический совет со стратегической моралью под эгидой рубрики «Лайфхаки от Экстраполяции».

В гите есть замечательная способность автоматически находить баги. Нет, конечно далеко не все и далеко не всегда, но в некоторых редких случаях это оказывается очень полезным. Это в тех случаях, когда точно понятно и видно, что баг есть, а где он происходит понять не получится. Мне эта штука понадобилась два или три раза всего, но сильно время сэкономила. Главное, что необходимо, чтобы воспользоваться этой штукой — вы точно знаете как воспроизвести баг.

Команда эта — git bisect (документация). Это такой бинарный поиск виноватого коммита. git bisect bad говорит о том, что в коммите баг есть, а git bisect good — что бага нет. И бисект за несколько таких вот маркировок коммитов сам выберет тот коммит, в котором все сломалось. И обещанное «автоматически» можно сделать с помощью команды git bisect run scriptname и бисект сам определит good или bad по коду возврата работы скрипта. Здорово, правда? Скажем, пишете вы новый тест в новый файл (чтобы гит игнорировал его при скачках по коммитам) и запускаете git bisect run bin/mocha test/newfile_test.js. Через несколько минут гит вам скажет где конкретно это сломалось.

И теперь несколько философских выводов.

1. Само наличие этой команды говорит что сам гит подразумевает полную работоспособность кода в каждом коммите. Хотя, как правило, разработчики утверждают, что код должен быть работоспособным только в мастере, а в ветках делайте что хотите.

2. Сплющивать коммиты при мерже, как это стало модным, не очень хорошая идея. Да, это уменьшит количество коммитов и, возможно, станет немного лучше смотреть на дерево проекта, в котором работает тысяча человек, но в команде из тысячи человек и одним репозиторием есть проблемы куда важнее, чем распухшее гит-дерево. В принципе плющить коммиты можно, но нужно это делать осознанно вручную, чтобы объединить некоторые коммиты в один. Это удобно делать в интерактивном режиме гита (git rebase --interactive с документацией). И придумайте мне, пожалуйста, нормальный русский термин для «squash commits».

3. Комментарий к коммиту должен содержать причину сделанного, а не тупо пересказывать содержимое коммита. Комментарий вроде «Добавлен метод такой-то в модуль сякой-то» — плохой и не несет никакого дополнительного смысла. Уж лучше вместо таких комментариев рисуйте смайл какашки: git commit -m "💩", будет не менее информативно. Комментарий «Теперь модуль сякой-то может работать с вон тем вот» – хороший и пояснит зачем нужно было делать то, что было сделано. Сильно экономит время при дебаге.

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

1. Итак, с точки зрения переменной в коде не существует никакого гита, веток и коммитов. Есть только текущая кодовая база и соседи всяческие — переменные, классы, функции и прочее. Окружающая наблюдаемая реальность, так сказать. Каждый коммит в данном случае — изменение окружающего мира во времени.

2. Благодаря тому, что связь коммитов очень напоминает связный список, по истории можно двигаться строго вперед. И история выходит технически неизменяемая.

3. Два коммита, у которых один и тот же родительский коммит, оказываются в параллельных вселенных, где история пошла по-разному.

Стоит заметить очевидное, что ветки и имена веток — это всего лишь удобные динамические метки каких-то конкретных коммитов. Технически они добавляют немного удобства, чтобы можно было не запоминать хеш-сумму коммитов и именовать эти самые «параллельные вселенные» каким-то удобным словом.

4. Итак, у нас существуют параллельные вселенные и наша текущая файловая система умеет отображать содержимое одной из вселенных. С помощью команд гита можно увидеть всю историю той или иной вселенной и увидеть взаимосвязь между ними. С точки зрения переменной в файлике в одной из веток, нет никаких других веток, нет никакого «мастера». Есть только сквозная история от «git init» до текущего момента.

И дальше самое интересное. Что такое «git rebase»? Это такая попытка повторить исторические события одной вселенной в другой. Ну, вот родился некий мальчик Адольф в 1889 году и как-то взаимодействовал с объектами из его вселенной и времени. Если мы сделаем «git rebase --onto v2018 v1889 v1918» то фактически мы попытаемся воспроизвести все события с 1889 года во вселенной 2018 года. Что, естественно приведет к конфликтам, которые нужно как-то решить. Ну, вот в 1889 году была у него мать Клара. В 2018 году той Клары, понятное дело, нет. И чтобы наш Адольф в 2018-м родился, необходимо выбрать другую мать, которая его родит. Или, согласно коммитам ветки v1889...v1918 наша переменная «Адольф» учавствовала в Первой мировой войне. И это тоже прийдется как-то решать программисту, инициировавшему ребейз на ветку 2018-го.

Фактически «git rebase» — это попытка воспроизвести все коммиты старой ветки в новой реальности. И относиться к каждому коммиту нужно так, как будто бы это совершенно новые коммиты, которые делаются по образу и подобию старых. Некоторые коммиты будут просто лишены смысла — для этого есть «git rebase --skip», некоторые коммиты будут выглядеть чуть менее, чем полностью другими. Не стесняйтесь использовать «git rebase --interactive», чтобы переставить коммиты местами, если это необходимо, выбросить лишнее и сплющить несколько коммитов в один, если так будет казаться, что это новая целостная история, а не просто под копирку воспроизведенная старая. Все существа текущей реальности не должны даже подозревать, что существуют какие-то другие вселенные. Если кто-то найдет у себя под домом аномалию вроде «<<<<<<<» и «>>>>>>>», то это может стать причиной кучи бед в этой вселенной.

Что такое «git merge»? А это, друзья, путешествия между параллельными вселенными. Когда результаты одной вселенной единовременно оказываются в другой. И, обратите внимание, это возможно только если между этими вселенными нет конфликтов. Если существует конфликт, скажем, в одной вселенной папы Адольфа не существовало и, следовательно, Адольф и не родился, а в другой его картина висела в спецхранилище американского правительства, то смержить одну ветку в другую система просто не позволит и путешествия между мирами не произойдет. Получится, так сказать, банальный мерж-конфликт.

И мне почему-то кажется, как-то так параллельные вселенные и работают. Да, чуть не забыл, все совпадения имен с историческими личностями и событиями случайны.