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

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

Некоторое время назад, когда мы разворачивали наш прототип VPN-сервиса на DO, нас мягко предупредили, что торрент-трафик через них пускать нельзя, хотя кто-то из клиентов это сделал. Нам даже сказали какой фильм качал клиент и, мол, права там принадлежат такой то студии и качать торрентом их нельзя. После первого предупреждения мы, конечно же, сразу же съехали с DO.

К слову, наш VPN-сервис пока ещё бесплатен, пользуйтесь кому нужно. Подписчикам Экстраполяции, которые присоединились к каналу до 10 июня 2019 года, я лично дам четыре месяца бесплатного использования, когда сервис таки станет платным. Думаю, это хороший повод послать ссылку на канал своим коллегам, верно ведь?

А пока там бета-версия и, повторюсь, сервис бесплатен для всех пользователей.

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

Вот бот, с помощью которого VPN можно получить: @cimon_proxy_bot

Попробуйте на слух отличить фразу «идет снег» от «инопланетные существа высадились на соседнем поле» на каком-нибудь суахили. Разница в паре звуков возможно может быть существенна, а может быть всего лишь случайным дефектом речи у конкретного произносящего. А собаки на слух вряд ли смогут отличить между собой слова «интерференция» и «интерпретация», потому как их слух и мозг не рассчитаны на тонкости понимания человеческой речи и конкретно русского языка. Вот даже если у вас никогда не было собаки, то вы наверняка знаете, что есть две основные команды, которым собак учат первыми: «нельзя» и «взять». Также есть вариации этих же самых команд в виде нелепых слов «фу» и «фас». Учить собаку, само собой разумеется, нужно диагональным командам — либо «фу» вместе с командой «взять» либо «нельзя» вместе с «фас». И фишка состоит в том, что случайно взятый человек не знает на какие команды натренирована собака, а ошибка в произнесении неверной команды может быть катастрофической. И естественно, лучше не давать никаких подобных команд чужой собаке, а то укусит поди, и еще и будет права. Пин-код на банковских картах или код блокировки на телефонах выполняют приблизительно ту же функцию, что и вариация собачьих команд — они призваны защитить от случайного постороннего вмешательства. Конечно же, целенаправленное зловредительство никак нельзя защитить никакими в мире паролями на телефонах, собаках или картах.

#перечитываяэкстраполяцию

Ребята, первая #экстравакансия от проекта https://toast.ninja. Просто напоминаю, что такого рода посты в «Экстраполяции» бесплатны, но попасть сюда не просто.

Проект интегрирует между собой гитхаб и слэк и в отличие от официального интегратора, ребята делают это правильно, через личные уведомления, а не в канал. И присылают только то, что должно быть интересно, а не все подряд. Команда небольшая, всего три человека, но это скорее большой плюс. Текущая имплементация написана на Nodejs, RabbitMQ и Postgresql и AWS Lambda. Минимум бюрократии, маскимум свободы и работать предстоит удаленно. Говорят, уже больше пятиста активных пользователей.

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

По всем вопросам пишите Антону (@restuta), он отвечает за технические вопросы в команде.

Недавно был пост про то, как выбирать арбузы, помните? Мне тут подумалось об этом процессе немного с другой стороны.

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

Очевидно, что самый верный способ определить качество арбуза — это вырезать такой маленький треугольничек и посмотреть что же там внутри. А может ещё и попробовать на вкус эту пирамидку из арбуза. Способ, безусловно, результативный, но вот только арбузу не очень нравится, когда от него отрезают кусочек, кусают и кладут назад в кучу кандидатов.

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

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

#экстрасобеседование

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

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

#экстраудаленка

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

Правильный же подход крайне прост. Всего-то нужно полное доверие сотрудникам.

И абсолютно не важно, врет ли начальству сотрудник или не врет. Важно есть ли у начальства сомнения по поводу честности или нет. Если есть хоть какие-то сомнения — нужно сразу же расставаться. Ну, и само собой, сотруднику важно не давать повода сомневаться в своей честности.

#экстраудаленка

В тему предыдущего поста главы подписчик напомнил анекдот в тему:

– Василий Иваныч, как же вы у англичан в карты выиграли?!
– Да понимаешь, Петька, сели мы с ихними лордами в очко сыграть. Один и говорит: «очко!». я ему:
– Покажи! А он мне: «ну что вы, Василий Иванович, мы же тут все джентльмены, а джентльмен верит другому джентельмену на слово».
И вот тут мне, Петька, карта и попёрла...

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

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

Как и предполагалось, реальная должность и выдуманная с первого взгляда неотличимы. Абсурдно (и в то же время довольно пафосно) звучит как и «адвокат талантов», так и «сомелье пользовательских интерфейсов».
Понятное дело, что профессиями эти штуки назвать сложно, это скорее связано с самоидентификацией. Как себя чувствует и к кому причисляет тот или иной специалист.

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

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

Самый дикий и ужасный вид контрактной работы у разработчиков — это аутстаф. Конечно, виды аутстафа бывают разные, но вот хороших среди них все-равно нет.

Аутстаф, когда сейлз-менеджер берет проценты с контракта. Аутстаф — если разработчиков нанимают под проект отдельно. Он же, когда одна аутсорс-компания арендует у другой «срочного ангулар разработчика».
Еще о нём же можно говорить, когда заказчик не знает кто конкретно пишет код, а общается с посредниками, то бишь менеджерской прослойкой.

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

Общение в чатах в большинстве своём придерживается неких норм этикета, соблюдать которые никто не учит и списком такие правила нигде не найдёшь. Некоторые правила настолько естественны, что не соблюдать их — высшее неуважение к собеседнику. Одно nohello.com чего стоит.

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

Сидишь такой, себе работаешь, и тут, бац, приходит ссылка. Надо оно мне? Не надо? Важно открыть её прямо сейчас или можно потом? Там мемасик или секьюрити патч? Объявление о выключении серверов в датацентре или рассуждения на тему того, что аджайл — это плохо? В общем, вопросов много, решение одно. Ссылки без сопроводительного описания посылать в чат нельзя никому.

Дополнить можно, что крайне важно не рассказать что там по ссылке будет (с этим и превью справится) и не свои эмоции передать, а рассказать почему читателю это надо обязательно прочитать. Вместо «Зацените что DO себе позволяет», нужно написать «У кого сервера на Диджиталоушен, берегитесь, в субботу их выключат на час». И ссылку добавить.

Ребята, у меня к вам внезапный вопрос.

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

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

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

Так вот, не отдельный же канал для этого добра заводить? В фейсбук такое писать не принято, линкедин вообще, как соцсеть, отстой дикий.

В общем, непонятно. Напишите мне личным сообщением (@aratak), пожалуйста, что думаете по поводу отдельного канала для новичков. Ленивые, но ответственные просто жмите на кнопочки. Спасибо.

👍 заводи, подпишусь
👨🏻‍💻 пиши прям сюда, норм
🧐 заводи отдельно, мне не интересно
🤮 нафиг надо на джунов время тратить, лучше сюда больше пиши
👽 не нажимайте на инопланетянина!

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

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

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

В-третьих, это не устраняет проблему дублирования, а только прячет её. Если вдруг в пакете будут какие-то изменения, то нужно будет сделать изменения во всех местах, где используется этот пакет.

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

Если уж не удаётся разделить код по-нормальному, можно воспользоваться сабмодулями гита. Эффект будет такой же со всеми преимуществами и отсутствием недостатков.

Ребята, судя по лайкам под постом, тема неоднозначная. Короче я не выдержал и создал чатик для «Экстраполяции». Ссылка на него, вроде как должна быть внизу экрана — кнопочка «Discuss». Там уже, к слову, обсуждение понеслось. Присоединяйтесь!

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

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

2. Обновление сабмодуля выглядит, как замена одного хеша в файлике на другой. Осознать что там поменялось без дополнительных действий тяжелей, чем при обновлении абстрактного пакета с версии 15 на версию 16. Там хотя бы ченджлог почитать можно.

3. При работе с отдельным пакетом проще абстрагироваться от основных проектов и сильно удобней писать независимый код. В отдельном пакете и тесты пишутся легче.

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

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

Самое страшное в таком вот проекте — это неопределенность. Работать с таким проектом, как общаться с множественными личностями Билли Миллигана — каждый раз большая загадка что ждет в следующей строчке повествования. Каждый следующий разработчик видит какой ужас происходит в исходном коде вот этого вот файла и старается новый код писать, как ему кажется, хорошо, чем только усугубляет ситуацию, ведь до него проект был написан в N стилях, а теперь он написан в N+1 стилях. И абсолютно неважно насколько неправы предыдущие разработчики и насколько прав текущий.

Вот вам несколько правил работы с такими вот унаследованными проектами:

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

2. Рефакторить код, на который нет тестов недопустимо. Объяснение очевидно.

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

4. Если хочется рефакторить во время исправления багов, то сначала выполняем пункт 3. Сначала тесты, потом рефактринг, потом фиксы. Или сначала тесты, потом фиксы, потом опять тесты, потом рефакторинг. Отдельными пулл реквестами и в строго такой последовательности.

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

6. Прежде чем сделать пулл реквест на +100000 П -100000 строк кода, в котором вы исправляете все тот же тип кавычек, обойдите коллег и убедитесь что не сломаете никому жизнь таким пулл реквестом. Вдруг у кого-то затянулась текущая разработка и ему придется решать огромную пачку конфликтов. Вам решить эти конфликты будет значительно проще, чем другим.

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

8. Поделитесь этими намерениями с коллегами и убедитесь, что вы с ними на одной волне. Если они не хотят вам помогать в стандартизации, то пусть хотя бы не мешают и примут эти правила. Можно взять вот это сообщение и отправить в рабочий чат с предложением вроде «Как раз про наш проект рассказывают. Давайте так сделаем?». С большой радостью услышу возражения и отговорки коллег, если конечно же такие будут.

#перечитываяэкстраполяцию

Мнение из чата по поводу прошлой заметки, с которым я полностью согласен. Очень хорошо подмечено!

——

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