Половнёв—Журнал

Public

Просмотреть канал

2.3K

676

6.3K

Не можете присоединиться? @polovnyov_journal

622 Участники

Обновлено: May 25, 2026 at 6:48 AM

Половнёв—Журнал

Пишу о разработке, тестировании и культуре работы. А еще у меня есть курс о том, как расти самому и выстраивать системный рост команды: https://tough-dev.school/growth Пишите: @vazilla, [email protected]

@polovnyov_journal offers specialized information about vasilypolovnyovru and httpstoughdevschoolgrowth for subscribers interested in Изучение языков

Рейтинг

Глобальный рейтинг

#13853

+10473

Рейтинг по языку

#9929

+8401

Рейтинг по категории

#75

+69

Рост участников (Последние 30 дней)

Всего: 622

Рост за 24ч: +0 0%

Последние посты

Половнёв—Журнал

20 мар. 2026 г., 06:27

let! vs let + before

Последний Ruby Weekly принёс статью о том, что let! лучше заменять на let + before блок:
https://allaboutcoding.ghinda.com/rspec-and-let-understanding-the-potential-pitfalls

Мол, такое:

RSpec.describe Thing do
let(:account_a) { build(:user, email: email) }
let(:account_b) { build(:user, user: email2) }
let(:organisation) { build(:organisation, account: account) }
let(:team) { build(:team, account: organisation) }

before
account_a
account_b
end

it 'returns that specific value that we want' do
# test
end
end


Лучше, чем такое:

RSpec.describe Thing do
let!(:account_a) { build(:user, email: email) }
let!(:account_b) { build(:user, user: email2) }
let(:organisation) { build(:organisation, account: account) }
let(:team) { build(:team, account: organisation) }

it 'returns that specific value that we want' do
# test
end
end


Мне кажется, что это какая-то ерунда. Во-первых, все мы любим Руби за то, что код на нем, читается почти как книга. А тут у нас «сначала акаунт а и б». Это че вообще?

Во-вторых, зачем вообще использовать let, если ни в последующих let, ни в тестах, мы не обращаемся к этим переменным по имени? Если они реально нужны только для того, чтобы создать окружение (скажем, нужны два акаунта, пользователь создаёт третий), то лучше сразу создать их в before блоке:

before do
create(:account)
create(:account)
end


В-третьих, на мой вкус, let! такой же заметный, как и before. А если хочется сделать позаметнее, сделай себе декоратор LET!!!11111.

В-четвертых, мне кажется, что стоит отделять зависимости тестируемого объекта и сетап окружения. Грубо говоря, в let зависимости (пользователь --> организация --> акаунт), а в before — действия, приводящие систему в нужное нам состояние. А размазывать их по let и before — странновато.

Что думаете?

875

Половнёв—Журнал

20 мар. 2026 г., 06:27

📷 Photo

На скриншоте кусочек моего рабочего стола. Все эти папки я не создавал. Я просто запускал Эпл Почту и нажимал Cmd+Shift+N, чтобы получить новые письма. К сожалению, новая Макось справляется с жидким стеклом, но не справляется с передачей фокуса только что запущенному почтовику. Фокус остается у Файндера, а он по Cmd+Shift+N создаёт новую папку. Зато парящие кнопки повсюду.

Я продолжаю верить, что для Эпла хороший дизайн — это не только «хорошо выглядит», но и «хорошо работает». А пока раз в неделю удаляю эти папки

2,480

Половнёв—Журнал

20 мар. 2026 г., 06:27

P. P. S. А пост, о котором говорит Никита, вот этот:
https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align

Но лучше почитайте, как в Фигме с этим мучались:
https://www.figma.com/blog/line-height-changes/

743

Половнёв—Журнал

20 мар. 2026 г., 06:27

📷 Photo

Василий, привет!

Пока жду полную поддержку text-box-trim, использую своё решение на чистом ЦСС. Загружаешь шрифтовой файл, инструмент вычисляет компенсацию метрик в «емах». Это автоматически масштабируется для всех комбинаций кегля и высоты строки:

.metrics-fix {
&::before {
content: '';
display: table;
margin-block-end: calc(-0.37em - (1lh - 1em) / 2);
}

&::after {
content: '';
display: table;
margin-block-start: calc(-0.13em - (1lh - 1em) / 2);
}
}

Подсадил знакомых фронтендеров, довольны. Буду рад, если ребятам в чате тоже поможет :–)

Инструмент: https://lotva.ru/projects/xsize/

Принцип работы: https://lotva.ru/texts/capsize/

888

Половнёв—Журнал

20 мар. 2026 г., 06:27

Как упростить превьюшки мейлеров с помощью #public_instance_methods

Представим, что у нас есть тупейший мейлер с пачкой методов:

class OnboardingMailer < ApplicationMailer
default to: -> { @user.email },
from: "[email protected]"

before_action :load_user

def welcome; end
def onboarding; end
def intro; end
def survey; end
def goodbye; end

private

def load_user
@user = params[:user]
end
end


Раньше я тупо перечислял и делегировал каждый метод в мейлер в превьюшке:

class EventsMailerPreview < ActionMailer::Preview
delegate :welcome, :onboarding,
:intro, :survey,
:goodbye, to: :mailer

private

def mailer
OnboardingMailer.with(user: User.first)
end
end


Получается не очень круто. Если появляются новые письма, приходятся дополнять список методов в превьюшке. Чтобы избавиться от этого гемороя, лучше использовать public_instance_methods(false):

class EventsMailerPreview < ActionMailer::Preview
available_emails = OnboardingMailer.public_instance_methods(false)
delegate(*available_emails, to: :mailer)

private

def mailer
OnboardingMailer.with(user: User.first)
end
end


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

См.:
https://apidock.com/ruby/Module/public_instance_methods

828

Половнёв—Журнал

20 мар. 2026 г., 06:27

Хороший-плохой руководитель

(Осторожно, пост наполнен страданиями вперемешку с рекламой и рассрочкой)

Лет 15 назад я познакомился с чайка-менеджментом — стилем управления, при котором руководитель ВНЕЗАПНО налетает на проект, срёт всем на голову и раздаёт случайные указания уровня «Рельсам нужен грамотный машинист» или «Делай своё, на чужое не попадайся». Работать с такими руководителями сложно, но возможно. Просто не делаешь ничего, ждёшь, пока отменят предыдущие задачи.

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

Но самый ад — руководители, которые не тупо транслируют волю клиента, а додумывают, докручивают и приносят несогласованные и плохие задачи. Я так ДЖВА месяца пилил систему организации событий для католического прихода, а им нужна была табличка в Гугль-таблицах. Работать с такими руководителями сложно, надо всё перепроверять и как можно чаще спрашивать себя: а не херню ли я делаю?

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

В бюро мы растим таких ребят в Школе руководителей. И сейчас самый лучший момент, чтобы туда поступить. Стоимость обучения минимальная, а с рассрочкой ещё выгоднее. Учишься сейчас, а платишь потом:
https://bureau.ru/school/managers/23

Половнёв—Журнал

20 мар. 2026 г., 06:27

Я не придумал заголовок, потому что ПИЧОТ

Дело было так. Никита Прокопов написал пост, а в посте такое:
Туда же эпидемия с центрированием. Раньше были шутки, что на вебе сложно вертикально центрировать div. Сейчас этот вопрос вроде бы порешали, div центрировать можно, а вот с текстом все еще проблемы. Опять же, потому что правила совершенно идиотские, никто не знает, как условный line-height работает. На весь интернет может быть одна статья про него, где человек разобрался, а остальные просто на глазок подгоняют, я уверен. И дизайнеры шрифтов, кстати, тут вообще не помогают.


Этот пост попал в один дико секретный чат. В чате начались бурления, споры и осуждения ЦСС. На что я справедливо возразил, что ЦСС-то предлагает решение проблемы с вертикальным выравниванием текста. Вот же, смотрите, text-box-trim с января 2025:
https://developer.chrome.com/blog/css-text-box-trim

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

Чуваки из Хрома сделали text-box (короткий вариант text-box-trim и text-box-edge), который проводит границу текста строго по прописным, строчным и базовой. И запомнить нужно всего два варианта:

p {
text-box: trim-both ex alphabetic; /* Обрезаем по икс-хайту и базовой */
text-box: trim-both cap alphabetic; /* Обрезаем по кап-хайту и базовой */
}


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


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

Покажу на примере. Пусть нам надо задать отступ ровно в 30 пк между h1, h2 сверху и p, img снизу. Отступ считаем от базовой до строчных. Считаем «вытяжки», сколько пикселей отнять сверху и снизу, чтобы воображаемый край проходил по базовым и строчным. Кеглей и интерлиньяжей у нас три пары (h1, h2 и p), получаем шесть вытяжек:

--h1-top-compensator: 5px;
--h1-bottom-compensator: 4px;

--h1-top-compensator: 4px;
--h1-bottom-compensator: 3px;

--p-top-compensator: 4.5px;
--p-bottom-compensator: 2.5px;

--gutter: 30px;


И начинаем описывать все возможные комбинации, чтобы этот отступ случился:

h1 + p {
margin-top: calc(var(--gutter) - var(--h1-bottom-compensator) - var(--p-top-compensator)); /* От 30 пк отнимаем нижний «излишек» у h1 и верхний у p */
}

h2 + p {
margin-top: calc(var(--gutter) - var(--h2-bottom-compensator) - var(--p-top-compensator));
}

h1 + img {
margin-top: calc(var(--gutter) - var(--h1-bottom-compensator)); /* А картинки блочные. Им вытяжки не нужны */
}

h2 + img {
margin-top: calc(var(--gutter) - var(--h1-bottom-compensator));
}


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

А вот, как это решается с помощью text-box:

h1,
h2,
p {
text-box: trim-both ex alphabetic; /* Провели границы строго по строчным и базовой */
}

h1 + p,
h2 + p,
h1 + img,
h2 + img {
margin-top: var(--gutter); /* И просто задали отступ */
}


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

P. S. Можно даже текст внутри кнопки нормально выровнять. Это че за анаконда иууу:

button {
text-box: trim-both cap alphabetic;
padding: 10px;
}

Половнёв—Журнал

20 мар. 2026 г., 06:27

ИИ и LLM: прогрессия в программировании

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

Мне кажется, всё, как в Железном Человеке. Начинаем с бестолковой Алисы, переходим к аугументации, костюму, который тебя делает круче, и наконец, к автономным костюмам-агентам (см. «Протокол семейный праздник» из ЖЧ3).

Прогрессия:
0. Отрицание, гнев, торг, депрессия, принятие. Да, как прежде уже не будет.

1. Время от времени захаживаешь в Дипсик или ЧатГПТ. Просишь что-то посоветовать, объяснить, написать за тебя функцию. Получаешь опыт, учишься формулировать рабочие промпты, снова и снова копипастишь кусочки кода туда-обратно.

2. Задалбываешься копипастить. Добавляешь автокомплит — ставишь GitHub Copilot или Курсор. Автокомплитишь табами, отдаешь LLM бойлерплейт.

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

4. Переходишь на программирование агентом. Сетапишь ВПН, покупаешь Claude Code. Программируешь фичи и рефакторишь с помощью разговора с консолью. Делегируешь агенту всю работу с репозиторием от создания и чтению ишьюс до форс-пушей и создания ПРов.

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

6. Переходишь на флот агентов. Запускаешь несколько инстансов агентов в вебе в Курсоре или локально с помощью Claude Code и git worktree.

7. Прекрасное светлое будущее. События «Мстители: Финал», уходишь в плотники или пивовары.

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

Половнёв—Журнал

20 мар. 2026 г., 06:27

Cursor Rules для хороших тестов с Ruby и RSpec

Делюсь моим набором правил для Курсора, которые помогают писать вменяемые тесты с RSpec. Я пользуюсь ими около месяца, в 9 из 10 случаев получается то, что надо. Больше того, я использовал эти правила, чтобы сделать домашку https://vasily.polovnyov.ru/tests/ и получил хорошие тесты, требующие минимальной доработки.



---
description:
globs: **/*_spec.rb
alwaysApply: false
---

#  Tests Style Guide
## General
- Always use English in tests.
- Always test edge, valid, and invalid cases.
- Set up RSpec config in `.rspec` and `spec_helper.rb`.
- Follow DRY principles and avoid duplication. Don't over-DRY at the cost of clarity; duplication is acceptable if it improves readability.
- Use shared examples for repeated behaviors.
- Do not test private methods.
- Do not test trivial methods.
- Do not test external dependencies.

## Layout
- Do not leave empty lines after `describe`, `context`, or `feature` declarations.
- Leave one empty line between example groups (`describe`, `context`, `feature`).
- Leave one empty line after `let`, `before`, and `after` blocks.
- Group all `let` blocks together, separate from `before`/`after`.
- Leave one empty line around each `it`/`specify` block.
- Separate test phases (setup, exercise, assertion) with one empty line.

## Example Group Structure
- Do not use `subject`; prefer `let`/`let!`.
- Use `let`/`let!` for setup, not instance variables or `before` for data.
- Order: `let`/`let!`, then `before`/`after`.
- Use `describe` for methods/classes. Use `.` for class methods, `#` for instance methods.
- Use `context` to describe different conditions, starting with 'when', 'with', 'if', 'unless', 'for', 'and', 'but', 'without', or 'otherwise'.

## Example Structure
- One expectation per example (`it`). If an example description contains 'and', it probably contains more than one expectation.
- When an example consists of multiple linked expectations, consider using `have_attributes` or a custom matcher.
- Keep example descriptions short and clear.
- Use `expect` syntax for assertions.
- For change assertions, prefer `expect { ... }.to change { ... }.from(...).to(...)` or `.to(...)`.
- Extract a `context` if an `it` description contains conditions: when, with, if, unless.

## Naming
- Contexts should describe conditions, forming readable sentences with nested blocks.
- Do not use 'should' in example descriptions. Use present tense, third person.
- Be explicit in `describe` blocks about what is being tested.

## Stubbing & Mocks
- Mock/stub only when necessary. Prefer real objects for integration tests.
- Always use `expect(...).to have_received(...)` to verify method calls on double/spy instead of `expect(...).to receive(...)`.
- Stub HTTP requests (e.g., with webmock) instead of hitting real services.
- Use `Timecop` for time, not stubbing `Time.now`.

Половнёв—Журнал

20 мар. 2026 г., 06:27

Зафиксирую для истории. Сегодня ровно месяц, как я не могу работать в обычном режиме «сел за комп утром, встал вечером, зато без перерыва». Теперь работаю короткими интервалами по 20-25 минут с перерывами по 5 минут. Соответственно, поменялся и формат работы с LLM. Вот, что я поменял:

1. Написал системный промпт для Курсора, который просит LLM сначала сформулировать план решения задачи, утвердить его со мной, выполнить, а затем прогнать тесты и линтеры:

## Development cycle
1. Before writing any code, come up with a good plan, review the plan, and then ask the user for permission to execute the plan.
2. After you have executed the plan, run: `bin/rspec` and `bin/rubocop`
3. If there are any linting errors, run `bin/rubocop -A`
4. To run tests: `bin/rspec `


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

2. Стал писать задачи на русском. Если я правильно понимаю, как работает LLM, то никаких проблем с этим быть не должно. car и «машина» в их векторном пространстве смыслов должны быть совсем рядом.

3. Стал писать задачи по формату. Открываю все нужные файлы, делаю /Add Open Files to Context. Кратко формулирую задачу в один абзац, а затем пишу список (буквально!) требований. Часть требований и технических деталей пишу прямо кодом:

...

С вот такими требованиями:
...
- определяет методы в мейлере, используя `define_method` и `@email_chain.steps`
...
- находит нужную цепочку и пользователя, опираясь на переданный mailing_list_subscription и АПИ EmailChain:
def load_data
@mailing_list_subscription = params[:mailing_list_subscription]
@user = @mailing_list_subscription.user
@email_chain = EmailChain.find_by(mailing_list_subscription: @mailing_list_subscription)
end


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

5. Перестал доверять LLM в написании тестов. LLM — мастера находить самые простые и рабочие пути. Они очень часто пишут тесты, которые либо тестируют ненужное, либо тестируют только «золотой путь», игнорируя все краевые случаи. Ощущение, будто LLM пишут тесты, чтобы они проходили с первого раза, а не для того, чтобы найти побольше багов и задокументировать АПИ.

Половнёв—Журнал

19 мар. 2026 г., 15:02

Я как-то пропустил, а в Руби и Рельсах появилось целое движение за нормальную асинхронщину:
https://github.com/socketry

Ключевой, на мой взгляд, продукт — асинхронный веб-сервер Falcon на файберах:
https://github.com/socketry/falcon

Он полезен и крут в случае, когда ваше приложение кучу времени проводит в синхронных вызовах, например, ходя по сети в разные бэкенды. Вроде чуваки из Самоката даже используют его в проде:
https://habr.com/ru/companies/ecom_tech/articles/705510/

Но меня больше порадовало их намерение сделать полноценный HTTP/2 сервер:
https://www.codeotaku.com/journal/2019-02/falcon-early-hints/index

Исторически приложения на Рельсах используют два веб-сервера: прокси, Nginx (Traefik, Thruster, Kamal-proxy) для HTTP/2, TLS, статики и общения с клиентом и апп-сервер, Puma (Unicorn, Pitchfork) для запуска бэкенда. Получается дебильная ситуация: клиент говорит с Nginx на HTTP/2, а Nginx говорит с бэкендом на HTTP/1.1, а если нужны фичи из HTTP/2, их делают костылями поверх 1.1.

Автор Falcon хочет сделать полноценный HTTP/2 апп-сервер, которому не нужен будет прокси. Соответственно, деплоить и поддерживать придется только один компонент.

Больше того, процесс разработки Falcon вскрыл неудачные архитектурные решения в Rack, стандартном интерфейсе веб-приложений на Руби, и помог с разработкой Rack 3:
https://www.codeotaku.com/journal/2024-09/interactive-rails/index

И всю эту революцию делает один (!) человек:
https://github.com/ioquatix

Хау кул из дет?

932

Половнёв—Журнал

19 мар. 2026 г., 15:02

Недавно Anthropic выкатил Claude Code — CLI для разработки с помощью ИИ-агента. А вместе с ним и клевый док с best practices:
https://www.anthropic.com/engineering/claude-code-best-practices

Самое интересное в нем — третья часть с common workflows. Это набор патернов работы с агентским ИИ, которые можно использовать в работе и с другими провайдерами. Меня в нем заинтересовали первые три:
1. Изучи → Подумай, как лучше сделать → Запрограммируй → Закоммить
Первые два шага суперважные. Без них Клод сразу бросается писать код, не особо разобравшись в задаче. Плюс think, think hard, think harder заставляют его реально больше думать о проблеме.

2. Напиши тест → Закоммить. Напиши код, который проходит тест → Закоммить
Классика.

3. Напиши код → Заскриншоть → Меняй код, пока скриншот не попадет в эталон
Фронтендерский вариант. Чтобы не загружать получающиеся скриншоты вручную, стоит взять MCP с Puppeteer:
https://github.com/modelcontextprotocol/servers/tree/c19925b8f0f2815ad72b08d2368f0007c86eb8e6/src/puppeteer

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

Короче, очень советую док, даже если вы не пользуетесь Claude:
https://www.anthropic.com/engineering/claude-code-best-practices

1,170

Половнёв—Журнал

16 мар. 2026 г., 03:01

Как узнать любителя

Любителя легко узнать по запаху. Он пахнет соплями и неуважением.

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

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

Не будьте любителями, будьте профессионалами.

785

Половнёв—Журнал

13 мар. 2026 г., 12:05

Вы используете Курсор неправильно

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

Во-первых, первое, что нужно сделать — включить YOLO, он же Enable auto-run mode. Эта фича разрешит агенту запускать код локально. Соответственно, можно будет делать крутейшие штуки:
Запусти эти тесты и поправь тестируемый класс так, чтобы тесты проходили

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

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

Аналогично с помощью примеров можно подсказать, как должна работать новая функция:
Напиши функцию на JS, которая группирует свойства по ключам во вложенные объекты. Покажу на примерах:
{ vkSrc: 'http://vk.com/123' } превращается в { vk: { src: 'http://vk.com/123' } }
{ vimeoId: '123', kinescopeSrc: 'http://ki.io' } превращается в { vimeo: { id: '123' }, kinescope: { src: 'http://ki.io' } }

В-третьих, чат можно использовать как справочник. Выделили нужный фрагмент кода, например, resolitions в package.json и попросили объяснить, как это работает.

В-четвертых, во вкладке Source Control в поле с текстом коммита есть магическая кнопка. Нажмите на нее, чтобы ИИ сгенерировал нормальный коммит-месседж на основе ваших (или не совсем ваших) изменений.

В-пятых, используйте правила для Курсора. Как минимум, возьмите хороший системный промпт:
https://cursor.directory/

Как максимум, понапишите собственных правил для проекта:
https://ghuntley.com/stdlib/

Короче, если вы используете в Курсоре только автокомплит, присмотритесь к YOLO auto-run mode и .cursorrules. И считайте чат не хитрым интерфейсом к Гуглу, а диалогом со стажером, с которым вы программируете в паре.

Половнёв—Журнал

11 мар. 2026 г., 13:02

📷 Photo

Дебажил утечку памяти. Добавил rbtrace в проект, выкатил и дал настояться, сделал дамп, визуализировал его в reap и получил вот такую красивую свгшку. В ней можно кликнуть и провалиться в нужный фрагмент, можно поискать по словам. Но это же картинка. Как это работает?

Оказывается, все просто. СВГ поддерживает встроенные стили и скрипты, но с небольшими ограничениями. В случае с флеймграфом в свгшку просто вложены все нужные стили и скрипты:
https://github.com/brendangregg/FlameGraph/blob/41fee1f99f9276008b7cd112fca19dc3ea84ac32/flamegraph.pl#L787-L1199

P. S. Память текла на конекшенах в Excon из-за persistent: true.

974

Половнёв—Журнал

6 дек. 2025 г., 16:22

Юникорн не поддерживает Rack 3, хоть и патч есть:
https://yhbt.net/unicorn-public/[email protected]/

Хуже того, он тупо взрывается, когда заголовки приходят массивом. Такое происходит, например, когда контроллер выставляет две куки:
"set-cookie" => ["foo=bar", "baz=zxc"]

Пока можно заманкипатчить http_response_write:
https://github.com/rails/rails/issues/48195#issuecomment-2099749963 (см. value.is_a?(Array)).

А лучше перейти на Pitchfork, Puma или Falcon:
https://github.com/Shopify/pitchfork
https://github.com/puma/puma
https://github.com/socketry/falcon

Кстати, зацените изящное решение с рефорканием:
https://github.com/Shopify/pitchfork/blob/master/docs/REFORKING.md

984

Половнёв—Журнал

6 дек. 2025 г., 16:22

С уходом Дискорда и непреднамеренным старением я стал записывать замечания со встречи прямо в тот же чат в Телеграме. Так как замечаний много, отвечать на каждое из них — безумство. Любого выбесит 20-30 сообщений «Увидел», «Поправил», «Записал». Вместо этого использую реакции на сообщения с замечаниями. Принцип такой:
👌 — поправил, сделал, починил
✍️ — записал, в бэклог, разберусь позже
👀 — увидел
🤔 — че-т подозрительно, проверим
👍 — супер, одобряю, нормас
🔥 — клево

Если в заметках со встречи все в эмодзи, значит, я все разобрал. Если у сообщения реакции нет, значит, пропустил. Изи, ничего не теряется.

927

Половнёв—Журнал

25 нояб. 2025 г., 05:52

Легче починить, чем извиниться

Тут DHH написал пост, да такой, что ПРЯМО В ЧУВСТВА. В нем пара клевых моментов.

Во-первых, Джейсон Фрид на заре Бейскемпа отвечал на 150 писем клиентов в день. Еще раз: сто пятьдесят писем клиентов в день. А мы инбокс разгрести не можем.

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

Пост целиком:
https://world.hey.com/dhh/stick-with-the-customer-4942402f (нужен ВПН)

970

Половнёв—Журнал

6 нояб. 2025 г., 07:12

Отличать дизмораль от трения

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

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

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

884

Половнёв—Журнал

6 нояб. 2025 г., 07:12

Ситуация в проекте. Если тоже прочитали это предложение голосом Коли Товеровского, ставьте класс.

Пользователи регистрируются с именами, которые мы не очень хотели бы видеть у себя в продукте. Например, Чикатило, Гитлер или Филипп Киркоров.

Собираем Базу Данных Стрёмных Имён (БДСИ). Она часто обновляется, поэтому хочется завернуть её в микро-сервис и дать другим сервисам АПИ, с помощью которого можно проверить имя на стрёмность.

Приходит сеньор-техлид-алкоголик и запрещает выносить её в микро-сервис. Говорит, гонять хттп-запросы на каждый чих — ламерство. Говорит, будем держать локальные копии БДСИ и работать с ними.

Джун, прошедший 20 курсов по вёрстке и сдавший добровольный квалификационный экзамен на веб-разработчика, пишет SQL-запрос, выгружает список стрёмных имён в JSON, git add, git commit и git push. В итоге, у нас в коде сервисов 10 копий текста из БДСИ.

Что сделать. Во-первых, список и БДСИ — это данные, им не место в коде и репозитории. Во-вторых, если без локальной копии данных не обойтись, то нужно обязательно убедиться, что данные регулярно и автоматически обновляются из БДСИ. Даже если кажется, что список никогда не будет меняться, тупо зашить его в код — плохая идея. Он 100% поменяется, вам 100% придётся писать модуль, который регулярно синхронизирует локальную версию с БДСИ. Поэтому такие задачи стоит всегда начинать с модуля, отвечающего за синхронизацию данных, а не с локальной копии, собранной вручную.

877

Половнёв—Журнал

28 сент. 2025 г., 20:31

Книги, которые я прочитал в ноябре-декабреВ ноябре-декабре я прочитал всего две книги, но оказались толстенными и отличными:1. The Comfort Crisis. Во-первых, офигенный формат. Чувак отправляется на Аляску, чтобы убить того самого оленя, страдает, превозмагает и фоном вбрасывает тезисы. Мол, вот тут и тут мы стали слишком нежными, а вот я на Аляске ВЫЖИВАЛ. Во-вторых, отличные идеи и лишний повод для оптимизма. Короче, советую.2. Get Better at Anything. Сначала показалось, что это очередная «клюква» о том, как быстрее и эффективнее осваивать навыки. Думал, будут очередные ДЕСЯТЬ ТЫСЯЧ ЧАСОВ HURR DURR. А на деле книга отличная. Все по полочкам и с шикарными примерами от Эдисона до онлайн-покера.

1,060

Showing 21 of 21 posts

No more posts

Рейтинг

Требуется вход

Отзывы пользователей (0)

Пока нет отзывов. Будьте первым, кто поделится своим опытом!

Половнёв—Журнал

Половнёв—Журнал

Рейтинг

Рост участников (Последние 30 дней)

Последние посты

Рейтинг

Отзывы пользователей (0)

Похожие каналы Telegram

Тимуроки: пишем лучше

RadiHola | Испанский язык

Български език с Кристина 🇧🇬

Алтай тил 💙 Altai til

НейроГармония ребенка

два слова

Демонтаж красноречия

Высшая школа перевода МГУ

Похожие каналы Telegram

Тимуроки: пишем лучше

RadiHola | Испанский язык

Български език с Кристина 🇧🇬

Алтай тил 💙 Altai til

НейроГармония ребенка

два слова

Демонтаж красноречия

Высшая школа перевода МГУ

Отзывы пользователей (0)

Последние посты