Мій друг та колега Всеволод веде канал «Сімпозіум», у якому розмірковує об освіті взагалому та об освіті дітей окремо. Йому та мені буде дуже приємно, якшо ви підпишетесь на його канал. Так, це реклама. Ні, вона не за гроші, а від усього серця. Хлопчіки та дівчатка, підписуйтесь!

@uasymposium

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

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

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

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

К слову о волонтёрстве. Найдётся ли у кого ГоуПро, который готовы пожертвовать воинам? Деньги собирать на такое, вроде бы, не так правильно, потому как есть куда более важные штуки, а вот ежели у кого лежит ненужный, я с большой благодарностью прийму и передам его ребятам. Напишите мне в личку (@aratak), пожалуйста. Спасибо.

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

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

Есть ещё «бритва Хайнлайна», которая очень близка предыдущей бритве. Там в конце добавляется «… но не исключай злонамеренности».

У нас все авто, которые мы покупали, имеют клички. Ну или имена. А может это позывные? Хрен разберёшь, пусть будет имена. Так вот:

— Шеврон (Т5 бусик) уже на пенсии.
— Пиксель (XTrail, который) сейчас на ремонте капитальном после двух обстрелов серъёзных. Вместо стёкол уже решётки у него.
— Йода (Санйонг-пикап) ездит и на днях я вам его покажу, если руки к видеомонтажу дойдут. Ему двигатель поменяли, фара разбита, но он ездит и задачи свои выполняет.
— Крокодильчик (Шевроле-пикап старенький), который реально похож на крокодильчика, сейчас в глубоком ремонте из-за поведённой рамы. В его кузов очень хорошо влезает другой агрегат, поэтому отказаться от старенького шевроле пока не получается.

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

Спасибо.

https://send.monobank.ua/jar/4QxM3tuPTR

На всякий случай напомню как авто выглядит.

Так, ну больше всего вопросов «а почему Крокодильчик?». Вон он, смотрите. Похож на Крокодильчика? :-)
Это старое видео, это он тут всего после пары выездов. Сейчас он в ещё более плачевном состоянии находится. У него раму повело и что-то там ещё. Но его ремонтируют и обещали поставить на ноги, то есть на колёса.

Так, ладно, признаю, что моё фирменное обзывательство «джаваскриптизёр» — не самое лучшее в мире.

Стало трошки краще.

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

https://send.monobank.ua/jar/4QxM3tuPTR

#реклама #підтримуємозсу

Приєднуйся до NIX Coding Challenge!

Здається, ми стали забувати, за що полюбляємо програмування… Запрошуємо тебе відчути кайф від невпинного кодинґу 😉

Покажи, на що ти здатний, на NIX Coding Challenge!

Коли: 15 жовтня, з 11:00 до 18:15
Де: онлайн

На тебе чекає алгоритмічних 5 задач. Кожна наступна буде складнішою за попередню. Але ми віримо у твої сили, так само, як і в Перемогу України!

Ти прокачаєш навички логічного мислення і зможеш отримати приз — сертифікат на купівлю ґаджетів! Свій результат дізнаєшся того ж дня у Telegram.

Для участі необхідно:
🔹 мати практичний досвід в IT від 1,5 року;
🔹 уміти програмувати будь-якою мовою;
🔹 знати, як розв'язувати алгоритмічні задачі.

До початку змагання встанови на ноутбук чи комп'ютер інтерпретатор або компілятор тієї мови, якою будеш кодити.

Приймай Ніксовий челендж уже зараз — реєструйся за посиланням!

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

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

Там, в этой теории систем, скорее рассказывается о физическом и биологическом уровне абстракции. Ещё там много внимания уделяется переходу от неживого к живому, мол эмерджентность, как свойство хорошо объясняет появление жизни из неживых материалов, но это тема отдельного поста (ставьте ⚡️, если хотите об этом пост).

А вот, что круто, что эмерджентность в коде — это невероятно крутой способ сказать насколько ваш код хорош. Если имплементировав фичу А и фичу Б, пользователь получит нечто большее, чем две фичи, то с уверенностью можно сказать, что ваш код хорош.

Ладно, кит тоже засчитывается за молнию :-)

Современный человек использует свой смартфон лишь на 10% от его потенциала.

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

За подробностями в личку (@aratak). Спасибо.

Самая проклятая профдеформация у разработчиков — умение делать выводы по неполным данным.

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

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

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

Маленькие пулл реквесты и рабочий мастер.

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

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

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

А фишка в том, что в мастере не должно быть законченное целое количество фич, а мастер просто должен быть рабочим.

Нормальным будет сделать пулл реквест, в котором появляется абстрактный класс, а реализация — отдельными пулл реквестами. Если новые css стили вместе с описаниием и примерами появятся в одном пулл реквесте, а поголовноое приименение этих стилей — в другом.

В общем, правила такие:
1. Пулл реквест должен быть как можно меньше. Если пулл реквест можно разбить на два отдельных — бейте.
2. В мастере должны проходить все тесты. Ну, или мастер должен технически запускаться и не падать, если вдруг у вас нет тестов.
3. Вполне допустимо в пулл реквесте сделать код, который не используется по назначению прям в этом пулл реквесте, а будет использоваться в следующих. И убедить коллег в работоспособности этого кода проще всего с помощью тестов. Или пистолета.
4. Технические изменения пулл реквеста должны описываться одним предложением. Не «сделал фичу», а «поменял сигнатуру метода» или «обновил библиотеку и зависимости». Человеческие описания оставьте задачам, а в пулл реквестах говорите о коде.

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