Как объяснить, что ту или эту функциональность приложения лучше оформить эдак вот так? Особенно если сейчас вовсе не требуется городить сложные системы, а достаточно лишь пару строчек костылей. Еще когда другие варианты кажутся проще в реализации и менее трудозатратными. Но вот эдакий вариант в будущем возможно окажется настолько удачнее любых аналогов, что текущие дополнительные затраты на реализацию сейчас окупятся с лихвой. Естественно нужно не переборщить и понимать, что в будущем разработка системы действительно окупится. Еще таких вот возможно-вариантов маги вне категорий видят несколько и каждый видимый возможный вариант развития событий возможен с разной вероятностью. Поэтому необходимо сейчас совершить такой набор действий (читать: «так спроектировать систему»), при которых в будущих вероятностных хитросплетениях будет максимальная выгода. И тот вариант, который кажется сеньорам магам правильным делать нужно не потому, что благодаря этому варианту развития событий лучше решается текущая проблема (и как правило наоборот), а из-за того, что этот вариант порождает минимальное количество проблем в будущем. Конечно же я говорю о «Дозорах» Лукьяненко, а никак не о программировании.

Лайвхаки от Экстраполяции

Гит прекрасен в консоли. Безусловно, интеграция с рабочими инструментами полезна и часто сокращает количество кликов, но консольная работа с гитом крайне базовая и иногда незаменимая. Самая насущная проблема в консольном гите — древовидное визуальное представление веток и коммитов. Для этого я использую два подхода.

Первый — GitX. Только не оригинальный, а форк. Хоть даже форк давно уже не поддерживается, с визуализацией он справляется отлично. Кроме того крайне легковесен, что немаловажно в эру реакт-нейтивов и электронов. http://rowanj.github.io/gitx/

Второй — консольная команда git log --graph --abbrev-commit --date=relative --all. Конечно же, запоминать ее вообще не обязательно, а лучше добавить в глобальный gitconfig. Мой гитконфиг публично доступен и лежит в репозитории dotfiles на гитхабе. С таким конфигом, чтобы увидеть дерево коммитов, я использую команду git la.

Еще один клёвый инструмент для работы с гитом от читателей «Экстраполяции» — tig (https://jonas.github.io/tig/). Работает в консоли и позволяет все то, что полноценные оконные инструменты вроде GitX. Выглядит просто отлично! Попробуем?

Во всех псевдоинтеллектуальных системах нужно сначала ответить на вопрос о том, какие результаты нам можно видеть, а какие нельзя: ложноотрицательные или ложноположительные. Если ложноположительные можно видеть, а ложноотрицательные нельзя, то система будет указывать на те места, на которые она не должна указывать, но точно не пропустит настоящую ошибку. Если же ошибки просачиваться могут (ложноотрицательные результаты), то систему стоит воспринимать, как помощника, но точно не как заменителя. В системах, которых окажется, что можно пропускать и ложноположительные и ложноотрицательные результаты, будет слишком мало смысла за редким исключением.

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

Wrong number of arguments — объективно худшая ошибка в Руби.
Худший дизайн сообщения, который вообще мог бы быть.
Ошибка при вызове метода на nil прекрасна.
Ошибка wrong number of arguments могла бы быть не менее прекрасной, но нет.

Мы не говорим "передали вот это: тыц, тыц, тыц, пердыц, но надо было три аргумента".

Мы говорим "передали четыре аргумента, а надо было три".

И это в среднем 15-20 человеко-минут на одну такую ошибку.
Серийные убийцы.

Ребята, #хайринг. Воспользуюсь служебным положением и расскажу, что нам в команду (cimon.io) нужен дизайнер.

Чтобы хороший был, добрый и с бородой. Или без. И не обязательно «был», можно чтобы и «была». Но дизайнер. Ещё главное, чтобы добрый. Хотя, если будет злой, то тоже хорошо. Но только если дизайнер.

Работать нужно будет над одним из нескольких проектов, вроде riter.co или vault8.io. Работы вагон и маленькая тележка, прийдется много думать и принимать самостоятельные решения.

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

Дизайнеры, присылайте ссылку на работы свои личным сообщением в телеграме (@aratak). Отдельное спасибо за форвард сообщения друзьям-дизайнерам и в подконтрольные каналы и группы.

В каждом уважающем себя трекере задач всегда есть место для маркёра важности задачи. Ну, там «minor» или «important» или вообще «critical». Такие маркировки задач лишены смысла почти полностью и следующими несколькими постами давайте разберём почему.

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

Если проблема действительно критически важна, то разработчик, расслаблено набирая class MySuperSer..., должен немедленно это бросить и, как пожарник, броситься срочно тушить пожар. Там уже не до трекеров, оформлений багов, стикеров и оценок. Бумаги заполняются после пожара, а не до него.

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

Если постоянно кричать «Волки!», то люди перестанут обращать на это внимание.

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

С автором канала «Айти без галстуков», Дмитрием, мы знакомы лично и я уверенно могу сказать, что ему есть что рассказывать интересного ещё очень долгое время.

https://yangx.top/notieinIT

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

Подпишитесь на Дмитрия, уверен, это очень сильно мотивирует его больше писать клевых постов.

​​Утверждение, от которого отталкиваются большинство менеджеров, разработчиков и всех, кто стоит рядом, состоит в том, что сроки постоянно срываются и это очень и очень плохо. Прям настолько плохо, что невозможно работать в таких условиях. От менеджеров постоянно слышно, что разработчики такие-эдакие говорят одно и это приходится умножать на два. Разработчики постоянно жалуются на коллег и соседние отделы. Мол, работа стоит, потому как вон тот козёл дэдлайны срывает постоянно. Причем этот процесс настолько естественный, что люди, у которых получилось несколько раз подряд выполнить обещанное, считают себя мегапунктуальными и супер-пупер обязательными, хотя по факту на следующий раз же срывают сроки в виде исключения из своей мегапунктуальности.

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

Сойдет за рубрику #полныйаджайл?

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

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

К слову, в тизере один из засветившихся в кадре — это я. Справа или слева?

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

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

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

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

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

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

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

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

Наконец-то, пройдя семь кругов монтажа и правок, пилотный выпуск шоу «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