Заблуждения программистов относительно адресов

Мы говорили о времени, теперь поговорим об адресах. Выдержка из прекрасной статьи https://www.mjt.iss.one.uk/posts/falsehoods-programmers-believe-about-addresses/

• Почтовые индексы всегда состоят из пяти цифр
• У адреса всегда есть почтовый индекс
• Улицы всегда имеют названия, а дома — номера
• У улиц всегда есть название
• В каждом городе есть только один уникальный адрес для каждого местоположения
• Почтовые адреса всегда включают название улицы и номер дома
• Номера зданий идут подряд
• Названия улиц не повторяются в одном городе
• Адрес включает только одну улицу
• В одной стране не может быть двух городов с одинаковыми названиями

Из моего личного опыта. Жил я некоторое время в славном городе Зеленограде (Это часть москвы за пределами москвы, как калининград). Так вот в этом городе у улиц нет названий, а номер дома однозначно определяет место в городе. Это супер удобно, только в онлайне на это мало кто рассчитывает, поэтому Зеленоградцы страдают)

Ссылки: Телеграм | Youtube | Подкаст

Как я положил продакшен базу на выходных
Вчера произошла эпическая история. После планового деплоя в субботу вечером (так было нужно), мне прилетело сообщение “кирилл, у нас почему-то не показываются заявки”. Наверное фильтры слетели, подумал я и пошел проверять. Фильтры не слетели. Я слегка напрягся и пошел в яндекс клауд посмотреть что там в базе. Как я и боялся, таблицы были пустыми. Причем не все, но многие. Самое интересное, что они были не просто пустыми, но у них сбросились счетчики.

Увидел я это не сразу после деплоя, поэтому было не до конца понятно, это деплой привел к удалению данных или что-то другое. Я быстро восстановил снепшот на новом кластере, благо это делается одним кликом и выполнил туда деплой заново. Какого было мое удивление, когда после деплоя база очистилась. Какого хрена подумал я, прикидывая, что могло быть причиной. В этот момент ко мне присоединился второй разработчик проекта, с которым мы весело провели 3 часа за дебагом.

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

Дальше мы полезли изучать код на предмет подозрительных вещей:

1. Логи
2. Изменения в конфигурации
3. Ишьюсы в Laravel (основной фреймворк)
4. Миграции

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

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

Открываем миграцию, а там тот самый пресловутый транкейт, который хоть и выглядел подозрительно, но не касался других таблиц. Смотрю в логи и вижу что транкейт выполняется так: TRUNCATE marketing_discounts CASCADE. И тут я как понял. Не знаю как так получилось, но я даже не был в курсе, что у трункейта есть такая опция. CASCADE приводит к тому, что дропаются все связанные таблицы (рекурсивно) независимо от того, есть ли там данные или нет. Сказать что я был в шоке, ничего не сказать. Тут же нашелся issues в ларавеле, где выяснилось несколько интересных деталей. Мы не единственные кто грохнул базу таким образом. Собственно сам issue появился с целью того, чтобы защитить всех остальных, на что разработчики сказали сорян, обратная совместимость. Самое смешное, что подобное поведение реализовано только для драйвера постгреса, у остальных такого нет.

When you truncate tables using the laravel illuminate db builder it truncates the table as expected. However, postgresql is different because it changes the DEFAULT behavior of truncate from RESTRICT to CASCADE. This means that you can loose all your data in other "related" tables (something that doesn't happen with the other sql drivers)

И ниже смешные комментарии в духе:

3 years passed, Laravel users still truncates their entire databases...

We were also a victim of this behavior this morning, fortunately we were on a test database. Very dangerous!

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

В итоге мы все поправили и восстановили данные, но открыли в себе новый страх. Давно в моей жизни не было таких приключений)

ишью: https://github.com/laravel/framework/issues/35157

Если вдруг пропустили, тут вышел подкаст подлодка про чистый код, где я срываю покровы и вспоминаю дядюшку Боба https://www.youtube.com/watch?v=3deXOXWlHeg хайли рекомендед!

Что такое чистый код?

По горячим следам хочу сделать саммари после выпуска, который породил вопросы: “так что же делать в итоге?”.

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

Но есть проблема, следованием этим вещам не делает ваш код классным, он может быть написан чисто, но при этом быть костылным/бажным/решать следствие а не причину/быть не нужным/дублироваться 100 раз. Поэтому качество кода важнее, чем его стилистическая чистота. Как сделать код качественным?

Универсальный совет такой:

⁃ Непрерывно книги про архитектуру (например совершенный код, программист прагматик, sicp, htdp и другие подобные)
⁃ Работайте в проектах с высокой инженерной культурой, работайте с людьми у которых можно научиться всему этому
⁃ Изучайте языки с другими парадигмами (особенно функциональные + лиспы)
⁃ Вливайтесь в опенсорс, гарантировано поднимает уровень кодинга в небеса
⁃ Пишите тесыт на свой код (и бизнес тут не причем, ему вообще не надо про тесты говорить, хорошие тесты ускоряют процесс написания кода)

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

Набор принципов и методик, которые стоит знать, но еще лучше понимать то, что за ними стоит:

⁃ Функциональное ядро, императивная оболочка
⁃ Программирование с явно выделенным состоянием
⁃ Предметно-ориентированное проектирование (DDD)
⁃ Чистота: Модели > Контроллеры > Вьюхи

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

p.s. А какие еще принципы вы бы добавили?

Ссылки: Телеграм | Youtube | Подкаст

У меня есть веселее история. В Badoo деплой был устроен так, что новые версии файлов докладывались на прод и менялась «карта» с актуальными файлами. Деплоили каждый день. Старые файлы удалялись кронами, проверкой по дате создания, через сколько-то дней. На новогодние праздники кроны потерли все файлы с прода, пока деплоя новых файлов не было…

Вот такой коммент написали мне к посту про мой фейл с деплоем. Я вспомнил еще одну веселую историю, как однажды дизайнер нам сломал продашкен. Дизайнер запустил аб тест на регистрацию в google optimize и когда он там менял блок, какой-то, то зацепил скрытое поле с CSRF, без которого бекенд думал что его ломают и отказывался пропускать запрос.

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

А какие у вас были веселые истории в продакшене? Как вы или ваши коллеги его ломали?

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

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

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

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

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

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

p.s. Кстати я тут организовал страничку в vk если вдруг кому интересно можно подписаться там: https://vk.com/orgprog

Тесты до кода без TDD (твиттер-тред)

Я часто пишу тесты до кода, но при этом не работаю по TDD. Почему?

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

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

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

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

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

Из последнего примера. Последние три месяца мы разрабтывали систему приемки документов от студентов, в которой в итоге сотня роутов, 68 моделей и около 50 тысяч строк кода (laravel/php + react/ts). Понимание доменной области приходило в процессе кодинга, поэтому можно сказать что мы двигались немного в слепую, дорабатывая систему по ходу. И я сошел бы с ума делая все это без тестов, так как проект часто менялся, но сама модель нет, скорее происходило расширение и иногда расщепление сущностей. Мы написали около 300 интеграционных тестов, которые выглядят примерно так:

    #[Test]
    public function store(): void
    {
        // TODO: check for new college without templates
        $uploadedFile = UploadedFile::fake()->create('file.txt');
        $attrs = Arr::except(ContractTemplate::factory()->raw(), ['college_id']);
        $body = [
            'college_contract_template' => [
                ...$attrs,
                'uploaded_file' => $uploadedFile,
            ],
        ];

        $response = $this
            ->actingAs($this->owner)
            ->post($this->route('college.admin.contract_templates.store'), $body);

        $response->assertSessionHasNoErrors();
        $response->assertRedirect();

        $template = $this->college->contractTemplates()->latest()->first();
        $this->assertModelExists($template);

        $this->assertFieldsEqual($attrs, $template);

        $this->assertModelExists($template->file);
        Storage::assertExists($template->file->path);
        $this->assertEquals($uploadedFile->name, $template->file->file_name);
    }

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

И вот что по этому поводу сказал Kent Beck (спойлер: мне платят не за тесты) https://gist.github.com/jordelver/3818839

p.s. Какое соотношение тестов к коду в вашем проекте?

Немного отвлеченный пост. Слухи о том что ютуб могут отрубить становятся все громче, поэтому я начал активнее развивать сообщество в VK. Не знаю как оно пойдет дальше, но если вы сидите в вк или рассматриваете его как запасной аэродром, то обязательно подпишитесь https://vk.com/orgprog Помимо прочего, там удобно слушать видео выложенные в виде подкастов. Кстати, по идее, сегодня будет следующий выпуск. Анонсирую когда зарелизим.

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

Ссылки: Телеграм | Youtube | Подкаст

https://www.youtube.com/watch?v=ImHSnB-uLd4 Второе видео на моем канале, где мы с Мишей Фесенко обсуждаем инжиниринг в букинге. Миллионы строк на перле, тысячи факсов, зарплата, найм, культура devops и многое другое!

Воу, неожиданно сегодня вышел выпуск со мной в мы обречены https://www.youtube.com/watch?v=40QghvScTew

> В первом после долгого перерыва выпуске наши авторитетные эксперты составили для вас список из 10 языков программирования, которые в 2024 году являются самыми высокооплачиваемыми и востребованными на рынке.

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

Совершенный код: отделяем получение данных от их использования

Есть такой код, который я называю "код, который заставляет себя переписывать". Этот код не выглядит плохо и про него нельзя сказать сразу, что он делает что-то плохое. Проблемы проявляются позже — в тот момент, когда нужно внести изменения либо отладить его.
Рассмотрим пример. В проектах Хекслета студенты часто пишут подобный код:

document.getElementById('spinner').classList.add('d-none');

На первый взгляд ничего криминального. Здесь извлекается DOM элемент с идентификатором spinner и затем к нему добавляется новый класс d-none. Теперь представьте, что кроме добавления нового класса, нужно удалить старый. В таком случае код выше часто переписывают следующим образом:

document.getElementById('spinner').classList.add('d-none');
document.getElementById('spinner').classList.remove('d-flex');

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

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

• Извлечение данных
• Манипуляция данными

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

const spinnerElement = document.getElementById('spinner'); // получение
spinnerElement.classList.add('d-none'); // использование

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

// Неправильно
const { output } = state.fileTabsInfo.tabs.find(tab => tab.id === 'output').result;

// Правильно
const outputTab = state.fileTabsInfo.tabs.find(tab => tab.id === 'output');
const { output } = outputTab.result;

// Неправильно
const html = document.querySelector('#alertBox').innerHTML;

// Правильно
const alertElement =  document.querySelector('#alertBox'); // получение
const html = alertElement.innerHTML; // использование

// Неправильно
const name = User.find(5).getName();

// Правильно
const user = User.find(5); // получение
const name = user.getName(); // использование

// Неправильно
const newUrl = `${url.parse(address).protocol}//${url.parse(address).host}`;

// Правильно
const urlParts = url.parse(address);
const newUrl = `${urlParts.protocol}//${urlParts.host}`;

p.s. Домашнее задание: поправьте в своем проекте 2 места, разделив получение данных и использование

Ссылки: Телеграм | Youtube | Подкаст

Партнерка Хекслета и Волчья стая

Вчера произошел курьезный случай в канале Антона Назарова, куда он запостил вот такое https://t.iss.one/m0rtymerr_channel/1646 с вопросом, как вы думаете кто это? Мне стало интересно и я пошел посмотреть комментарии. Там начали называть, в том числе, школы и в какой-то момент промелькнул Хекслет. Как интересно подумал я, пока ниже не увидел ответ Антона “это они”. Я аж подпрыгнул на этом моменте. Внутри компании нет людей, которые занимаются подобными механиками продвижения, поэтому я сразу написал в рабочий чат, чтобы узнать что происходит.

В общем совместный ресерч + доп инфа от Антона показали, что это веб-мастер, который зарабатывает на партнерских программах. Наша партнерка добавлена через популярный на рынке https://advcake.com/ где тусует большое количество веб-мастеров, которые, как правило, привлекают трафик через свои сайты, например рейтинги курсов.

Неприятно то, что он в личке Антону представился как сотрудник Хекслета, что конечно же не правда. Но хорошо что, разобрались. Приятно, то что аудитория Антона Хекслет знает и знает про его репутацию, потому что в комментариях это многих удивило. Будте на чеку. Я уверен что этот веб-мастер пошел много куда + он не один такой.

p.s. На следующей неделе выйдет видео с Антоном, которое мы с ним недавно записали. Подпишитесь на ютуб https://www.youtube.com/@mokevnin/featured чтобы не пропустить ;)

Ссылки: Телеграм | Youtube | Подкаст

5 советов по проектированию функций, которые значительно улучшат ваш код (твиттер-тред)

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

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

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

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

Из этого вытекает логичное, но, почему-то, редко обсуждаемое правило. На самом верхнем уровне, проектирование кода должно идти от слоев, которые 1) имеют четко выраженную ответственность 2) оперируют только абстракциями более низкого уровня 3) не прыгают через уровни

В самом общем виде эта мысль описана в SOC https://en.wikipedia.org/wiki/Separation_of_concerns… Примерами здесь служат: модель OSI, HTML/CSS, Миксины и многое другое. Это очень близко нашей теме, хотя и не один в один. Плюс хорошая адаптация к коду от Мартина: Принцип Single Level Of Abstraction

Возникает вопрос, а на что конкретно ориентироваться чтобы создавать функции хорошо? И у меня есть ответ. Существует довольно много простых и не очень принципов, которые определяют как лучше проектировать функции. Большая часть из них универсальна и подходит для всех языков

Начнем с самого главного правила в программировании: отделение чистого кода от кода с побочными эффектами или "функциональное ядро и императивная оболочка". Чтобы понять о чем тут идет речь, поговорим о том, что такое чистые функции.

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

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

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

Эта логика, сама по себе, не имеет отношения к коду. Она, часто, существует на уровне документов и спецификаций, ее понимают заказчики бизнеса и ради нее, собственно, софт и пишется.

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

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

Другой важный принцип проектирования функций Command-Query Separation (CQS). Он не совсем про слои, но очень в тему. Обычно звучит так: "задавая вопрос, не изменяй ответ". То есть геттеры не должны менять состояние, это противоречит их сути и может ломать детерминированность

Ссылки: Телеграм | Youtube | Подкаст

Как научиться слепой печати на клавиатуре

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

• Хорошая техника позволяет сократить количество ошибок
• С опытом скорость набора текста станет выше
• При необходимости достаточно легко учатся новые алфавиты

Как это работает?

Слепой набор включает в себя несколько важных компонентов:

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

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

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

Наиболее эффективный набор в слепом режиме происходит когда пальцы постоянно чередуются. Попробуйте проверить это сами. Наберите слово "папа" указательным пальцем левой руки (эти буквы находятся в его зоне), а затем слово "гага" (указательные пальцы обоих рук).
Большинство раскладок проектировалось с учетом этого фактора, например, раскладка ЙЦУКЕН. А вот QWERTY создавалась слишком давно, когда приходилось учитывать другие факторы (например, залипание клавиш), и это отразилось на эффективности. Поэтому были созданы альтернативные раскладки, такие как DVORAK и Colemak. Вот что написано в Википедии по поводу последней:

• Скорость. Быстрее QWERTY и несколько быстрее Дворака, так как в Colemak разгружены мизинцы и чаще применяется чередование рук.
• Эргономичность. 10 наиболее распространённых букв английского языка и клавиша Backspace расположены на втором (домашнем) ряду клавиатуры. В Colemak домашний ряд используется в среднем на 3 % чаще, чем в раскладке Дворака, и 40 % чаще, чем в QWERTY. Благодаря этому при печати на Colemak пальцам приходится меньше перемещаться, чем при печати на QWERTY.

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

Как научиться?

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

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

Ссылки: Телеграм | Youtube | Подкаст

Чему можно научиться у миграций Rails

Я грозился начать рассказывать про фреймворки, пора это делать. Начнем с такой темы как миграции.

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

В большинстве фреймворков (в микрофреймворках это не так) этот механизм встроенный, но иногда идет как отдельная часть, как в spring boot.

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

Генерация

Rails это db first фреймворк (как. и большинство), то есть модели работают базируясь на структуре базы данных, а не база данных меняется под структуру как в entity framework или django. Поэтому миграцию нужно генерировать самостоятельно, фреймворк этого не сделает.

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

bin/rails generate model Product name:string description:text category:references

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

Автооткат

Сама миграция не содержит привычных up и down. Внутри нее только один метод change. Rails умеет автоматически откатывать почти все, но работает это если мы используем его dsl для описания миграции, чистый sql не подойдет

class CreateProducts < ActiveRecord::Migration[7.1]
  def change
    create_table :products do |t|
      t.string :name
      t.text :description

      t.timestamps
    end
  end
end

Если нужно всегда можно реализовать up и down отдельно

Схема

Вещь, которую после Rails внедрили многие фреймворки, например, Laravel (но сделано это довольно хреново). После того как накатывается миграция, rails автоматически обновляет файлик со схемой schema.rb. Этот файлик позволяет легко увидеть а чо там в базе без необходимости туда лезть. Он автоматически используется при накатывании проекта с нуля или в старте тестов. Работает это так: сначала грузим схему, затем миграции, которые добавились, но еще не применялись в текущем окружении. Наличие такой схемы позволяет легко удалять миграции, которые уже были накачены в продакшене.

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

Еще больше ништяков можно прочитать в офигенном гайде: https://guides.rubyonrails.org/active_record_migrations.html

Удаление

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

Накат/Откат

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

bin/rails db:rollback STEP=3
bin/rails db:migrate:redo STEP=3

p.s. Поделитесь крутыми фишками миграций в ваших фреймворках

Ссылки: Телеграм | Youtube | Подкаст

Ну вы поняли да? https://www.youtube.com/watch?v=dJXV5Y1Pnc8 На самом деле, я попытался собрать от Антона предложения по тому "а как все же сделать чтобы было хорошо" и у нас получился довольно интересный разговор. Мы даже егэ там перемыли

Увидел ссылку на прекрасный пост 2016 года в жж про то как нанимать, который не могу не опубликовать (пришлось чуть подрихтовать чтобы влезло):

1. Читаем резюме. Вырезал чтобы влезло

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

3. Задаем несколько вопросов как в №2, но по теме данной позиции и копаем вглубь пока лопата не зазвенит. Причем годятся любые вопросы, ответы на которые практически невозможно запомнить всухую. "А вы помните в каком релизе там фундепы внедрили?" Правильный ответ "что-то типа NNN или около того, но потом пришлось обратно всем откатываться, потому что оказывается что фундепы сломали тайпчекер, как оно тесты-то прошло, бгггг". Очень хорошо идут вопросы из резюме кандидата (из №2) но в приложении к технологиям из №3: "а вот вы рассказывали что вы делали ХХХ, а как бы вы сделали тоже самое, но уже с использованием YYY, которое нам нужно?". Тут люди очень часто заводятся и начинают увлеченно "проектировать" ибо чувствуют себя в своей тарелке. Вообще говоря, на этом месте иногда можно и закончить и послать человеку оффер (ну или наоборот), если повезет.

4. Даем тестовое задание. Тестовое задание не должно быть больше 8 часов при требуемом вами уровне квалификации, а лучше меньше. Идеально - 4-5. Если есть возможность - не говорить кандидату на этапе №2 сколько именно вы рассчитываете займет задание. Просто отделайтесь "небольшое" и попросите его на этапе №5 оценить время самому. Я стараюсь иметь бюджет на оплату тестовых заданий и плачу по разумной рыночной ставке, чтобы человеку было не обидно и замечено что люди даже за небольшие деньги гораздо внимательнее относятся к выполнению, включается психологический паттерн "работа". Задание даю так, чтобы его можно было сделать за отведенное время аккуратно, без висящих соплей. Стараюсь давать из существующего проекта, либо что-то новое (поскольку заплачено, то не стыдно и использовать будет) либо уже существующее (зато есть reference implementation и можно отдать на глубокое ревью тому, кто писал оригинал). Задание должно быть вырезано из существующего проекта аккуратно и не требовать экзотического тулинга и строго заданных ОС. Человек будет делать задание из дома, а там у него может не быть рабочего окружения, а просто игровой компутер с виндой. Можно дать доступ на EC2 инстанс, где уже все готовое установлено, а потом его просто убить. Задача должна быть реальная, делать что-то полезное, а не сортировать массив пузырьком, прости господи.

5. Ревью задания с кандидатом. Почему вы сделали так, а не иначе, что бы вы сделали если бы было больше времени, покрытие тестами, точки интеграции в "большой" проект, то есть обычная рабочая рутина. Посмотреть как человек вертится, как и что предлагает, насколько хорошо оценивает риски, и т.д. Желательно конечно убедиться что задание компилируется, работает и делает что обещано 🙂

p.s. https://kika.livejournal.com/152388.html

Ребят, хочу порекомендовать канал https://t.iss.one/MicroservicesQuestions в котором собираются вопросы с собеседований и архитектурные решения связанные с базами данных, распределенными системами и проблемами микросервисных проектов. Рекомендую подписаться если вы готовитесь к собесам или учитесь решать подобные задачи. Из последних тем там:

> Взаимно-рекурсивные внешние ключи
> Каскадное удаление за один запрос
> Caching patterns

Bootstrap подходит только для админок

Хекслет и все его сайд-проекты: cv.hexlet.io, code-basics.com, codebattle.hexlet.io, guides.hexlet.io реализованы с помощью Bootstrap. Причем, в основном, это стандартный бутстрап

Почему мы это делаем?

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

Это особенно важно, учитывая, что для современных it-бизнесов наиболее критичная метрика — time to market, то есть скорость, с которой изменения доставляются до пользователей. Быстрые и частые релизы позволяют не тратить время на ненужные вещи и делать только то, что пользователям нужно по-настоящему.

С плюсами понятно, а что насчет минусов? Ведь сайт выглядит не “круто”.

Как показывает практика, влияние дизайна на успешность продукта нередко переоценивается. Более того, на Хекслете происходит ровно наоборот. Сейчас дизайн более стандартный для Bootstrap, чем был в начале 2018 года (у нас была попытка сделать что-то совсем своё), и мы получаем много положительных отзывов:

> Хороший материал, интересные задачи, приятный интерфейс - мне нравится

Но еще большему числу людей это вообще не важно:

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

Наличие контента и его качества решают

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

Проще и быстрее написать свое

Проще ли написать свое? Конечно! Если у вас стоит задача прямо здесь и сейчас заверстать какой-то кусок, который решает конкретную задачу, то намного проще накидать пару-тройку своих классов и радостно перейти к следующей задаче.

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

Как только в проекте появляется своя верстка, то все, кто не принимают участие в ее создании, будут вынуждены ждать тех, кто ее пишет. То есть замедляется time to market. Чем больше верстка заточена под конкретные ситуации, тем меньше возможностей для маневра.

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

- Bootstrap создается тысячами разработчиков, внутри него решены все распространенные проблемы, причем наиболее универсальным способом. Все это благодаря огромному коммьюнити.
- У Bootstrap очень подробная документация. Разобравшись с ним один раз, это будет помогать всю последующую жизнь, так же как и владение git. Своя документация никогда не дойдет до такого уровня.
- Стоимость создания общего решения во много раз дороже создания частного решения. Обычно программисты недооценивают, во что им выльется сделать нечто универсальное. В итоге время будет тратиться на обкатку этого решения, а не на выполнение задач проекта.
- Bootstrap настолько популярен, что для него существуют библиотеки под каждый фронтенд-фреймворк и темы под все популярные виджеты. Еще минус куча работы.

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

Ссылки: Телеграм | Youtube | Подкаст