DON'T STOP AND CODE pinned «[Про жизнь] Жизнь - интересная, непредсказуемая, удивительная штука, которая с завидной регулярностью заставляет пересмотреть некоторые свои взгляды на 180 градусов. Спустя годы выясняется, что многие принципы, которые ты считал единственно верными, оказываются…»
[Итоги года 2025]🪞
1) Работа
С июня этого года я поменял роль с DE на разработчика внутренних сервисов платформы. Этого я хотел несколько лет. Много работал с кодом. К концу года удалось добить до релиза с нуля один проект. Самостоятельно настроил деплой в кубер. Получил за этот неполный год хороший опыт, которому я очень рад.
2) Обучение
Завершил 2 внешних обучения:
- DDD
- Kubernetes для разработчиков
Полученные знания применяю в работе.
Также, в рамках вечерних активностей после работы активно осваивал LLM.
Изучал как и из чего строятся ИИ-приложения. Прогресс очень хороший. Это особенно чувствуется как в работе, так и просто в общении с коллегами. Полученные знания и навыки успешно применяю.
3) Тренажерный зал
Этой весной я достиг пика своей физической формы. В жиме лежа удалось дойти до КМС в своей весовой категории. Этому я очень рад. Получал регулярно комплименты в зале. Это приятно.
Летом были очередные изменения из-за которых был нарушен режим тренировок.
Смог вернуть режим только в ноябре (с 20 числа). За это время удалось восстановить форму (было 20 тренировок), но до весенних результатов мне еще далеко.
Как я писал ранее, для меня занятия в тренажерном зале стали обычной привычкой. Занимаюсь без фанатизма, без употребления каких-либо препаратов, просто в свое удовольствие для поддержания формы. При этом есть спортивный интерес вернуть весеннюю форму).
4) Канал
Этой осенью возобновил публикацию в канал. Кол-во подписчиков перевалило за 100. Хоть канал небольшой, но я очень рад общению, которое иногда случается с кем-то из вас. Всем огромное спасибо.
Итого:
Этот год я бы обозначил как "взросление". Многое удалось принять, успокоиться, осмотреться. Осенью вернулись энтузиазм, проактивность, интерес. Это проявляется в работе, обучении и даже в этом канале. Я получаю огромное удовольствие от работы. Это реально очень интересно).
P.s. что по целям?
Целей как таковых не было. Точнее были, но я не был сфокусирован на их достижение. Об этом писал. Да, вот так. Как есть)
Идем дальше.
С наступающим)
🎄 🎄 🎄 🎄 🎄 🎄 🎄 🎄
1) Работа
С июня этого года я поменял роль с DE на разработчика внутренних сервисов платформы. Этого я хотел несколько лет. Много работал с кодом. К концу года удалось добить до релиза с нуля один проект. Самостоятельно настроил деплой в кубер. Получил за этот неполный год хороший опыт, которому я очень рад.
2) Обучение
Завершил 2 внешних обучения:
- DDD
- Kubernetes для разработчиков
Полученные знания применяю в работе.
Также, в рамках вечерних активностей после работы активно осваивал LLM.
Изучал как и из чего строятся ИИ-приложения. Прогресс очень хороший. Это особенно чувствуется как в работе, так и просто в общении с коллегами. Полученные знания и навыки успешно применяю.
3) Тренажерный зал
Этой весной я достиг пика своей физической формы. В жиме лежа удалось дойти до КМС в своей весовой категории. Этому я очень рад. Получал регулярно комплименты в зале. Это приятно.
Летом были очередные изменения из-за которых был нарушен режим тренировок.
Смог вернуть режим только в ноябре (с 20 числа). За это время удалось восстановить форму (было 20 тренировок), но до весенних результатов мне еще далеко.
Как я писал ранее, для меня занятия в тренажерном зале стали обычной привычкой. Занимаюсь без фанатизма, без употребления каких-либо препаратов, просто в свое удовольствие для поддержания формы. При этом есть спортивный интерес вернуть весеннюю форму).
4) Канал
Этой осенью возобновил публикацию в канал. Кол-во подписчиков перевалило за 100. Хоть канал небольшой, но я очень рад общению, которое иногда случается с кем-то из вас. Всем огромное спасибо.
Итого:
Этот год я бы обозначил как "взросление". Многое удалось принять, успокоиться, осмотреться. Осенью вернулись энтузиазм, проактивность, интерес. Это проявляется в работе, обучении и даже в этом канале. Я получаю огромное удовольствие от работы. Это реально очень интересно).
P.s. что по целям?
Целей как таковых не было. Точнее были, но я не был сфокусирован на их достижение. Об этом писал. Да, вот так. Как есть)
Идем дальше.
С наступающим)
Please open Telegram to view this post
VIEW IN TELEGRAM
🏆13🔥5👍4
[Вы знакомы с Expression Problem?]
Правда, чем больше я работаю, чем больше я погружаюсь в тему программирования, тем больше пониманию сколько всего. Например, сегодня узнал о том, что обыденная проблема безопасного и удобного внесения изменений в готовый код имеет классическое определение и решение. Тема оказалась крайне интересной.
"Expression Problem показывает фундаментальное ограничение как объектно-ориентированных, так и функциональных языков: ни один из них не поддерживает удобное расширение как по оси типов, так и по оси операций."
-- Philip Wadler, 12 November 1998
Обратите внимание на год.
Оказывается Expression Problem - это лакмусовая бумажка выразительности языка. Идеальный язык должен позволять:
- добавить новый тип данных, не трогая старые функции
- добавить новую операцию, не трогая старые классы
Если язык программирования имеет решение, то его называют expressive (выразительным).
В Python есть решение - структурная типизация через Protocol (добавили в 2017 году в версии 3.8).
Например, вот мой путь:
1️) ООП с наследованием (ABC) - легко добавлять новые типы, но операции сложно
2️) ФП с матчингом - легко добавлять новые функции, но типы сложно
3️) Protocols - золотая середина в Python
Если погрузиться в "PEP 544 – Protocols: Structural subtyping (static duck typing)", то можно сделать вывод что это по сути официальное решение Expression Problem в Python.
Лайфхак:
Когда проектируешь систему, нужно спросить себя: "Что вероятнее будет расширяться - типы данных или операции над ними?" Исходя из ответа, нужно выбирать один подход из перечисленных выше.
Кажется, в современном быстроменяющемся мире, при проектировании систем нужно предпочтение отдавать Protocols. Так система должна легко поддерживать "удобное расширение как по оси типов, так и по оси операций".
Правда, чем больше я работаю, чем больше я погружаюсь в тему программирования, тем больше пониманию сколько всего. Например, сегодня узнал о том, что обыденная проблема безопасного и удобного внесения изменений в готовый код имеет классическое определение и решение. Тема оказалась крайне интересной.
"Expression Problem показывает фундаментальное ограничение как объектно-ориентированных, так и функциональных языков: ни один из них не поддерживает удобное расширение как по оси типов, так и по оси операций."
-- Philip Wadler, 12 November 1998
Обратите внимание на год.
Оказывается Expression Problem - это лакмусовая бумажка выразительности языка. Идеальный язык должен позволять:
- добавить новый тип данных, не трогая старые функции
- добавить новую операцию, не трогая старые классы
Если язык программирования имеет решение, то его называют expressive (выразительным).
В Python есть решение - структурная типизация через Protocol (добавили в 2017 году в версии 3.8).
Например, вот мой путь:
1️) ООП с наследованием (ABC) - легко добавлять новые типы, но операции сложно
2️) ФП с матчингом - легко добавлять новые функции, но типы сложно
3️) Protocols - золотая середина в Python
Если погрузиться в "PEP 544 – Protocols: Structural subtyping (static duck typing)", то можно сделать вывод что это по сути официальное решение Expression Problem в Python.
Лайфхак:
Когда проектируешь систему, нужно спросить себя: "Что вероятнее будет расширяться - типы данных или операции над ними?" Исходя из ответа, нужно выбирать один подход из перечисленных выше.
Кажется, в современном быстроменяющемся мире, при проектировании систем нужно предпочтение отдавать Protocols. Так система должна легко поддерживать "удобное расширение как по оси типов, так и по оси операций".
👀3👍2
[Parse, Don't Validate]
Оказывается, привычка везде вставлять if (isValid(...)) - это системная ошибка.
Сегодня открыл для себя философию «Parse, Don't Validate».
Как это работает:
1) На границе (API, форма, БД) мы парсим «сырые» данные.
2) Создаём объекты специальных типов (например, Email, NonEmptyList, PaidOrder), которые невозможно создать в некорректном состоянии.
3) Вся бизнес-логика внутри системы работает только с этими доверенными типами. Никаких if-ов.
Лайфхак:
Когда проектируешь систему, спроси себя: "Где настоящая граница моей системы?".
Именно там нужно парсить данные. Всё, что внутри - должно быть уже валидным.
Идеальная система должна:
- Преобразовывать сырые данные в "богатые" типы на границе
- Работать внутри только с гарантированно валидными данными
- Иметь 0 проверок в бизнес-логике
P.s.
Рекомендую прочитать статью-первоисточник: Parse, don’t validate
Оказывается, привычка везде вставлять if (isValid(...)) - это системная ошибка.
Сегодня открыл для себя философию «Parse, Don't Validate».
Вместо того чтобы постоянно спрашивать «корректны ли данные?», нужно один раз на границе системы преобразовать их в гарантированно корректный, «богатый» тип. После этого можно просто ему доверять.
Как это работает:
1) На границе (API, форма, БД) мы парсим «сырые» данные.
2) Создаём объекты специальных типов (например, Email, NonEmptyList, PaidOrder), которые невозможно создать в некорректном состоянии.
3) Вся бизнес-логика внутри системы работает только с этими доверенными типами. Никаких if-ов.
Лайфхак:
Когда проектируешь систему, спроси себя: "Где настоящая граница моей системы?".
Именно там нужно парсить данные. Всё, что внутри - должно быть уже валидным.
Идеальная система должна:
- Преобразовывать сырые данные в "богатые" типы на границе
- Работать внутри только с гарантированно валидными данными
- Иметь 0 проверок в бизнес-логике
P.s.
Рекомендую прочитать статью-первоисточник: Parse, don’t validate
👍5👀3🔥1
[А вы используете логику Хоара в разработке?]
Я с ней знаком уже пару лет.
Хочу сейчас поделиться размышлениями по данной теме.
Что скрывается за терминами "предусловия", "постусловия" и "инварианты"? Если я скажу, что это та самая штука, которая превращает программирование из гадания на кофейной гуще в инженерную дисциплину, то это не будет преувеличением.
Вот в чём прикол:
1) Ваш код может "работать" и при этом быть полным фарсом
Вы когда-нибудь писали функцию, которая вроде бы делает что надо, но при этом где-то в глубине души понимаете, что она может сломаться в любой момент? Вот это и есть отсутствие гарантий. Логика Хоара говорит: давайте чётко прописывать, при каких условиях функция работает ("предусловие") и что она гарантирует на выходе ("постусловие").
2) Функции - это не чёрные ящики, а контракты
Каждая функция должна чётко заявлять: "Я принимаю вот это, и обещаю вернуть вот это". Если она начинает делать что-то ещё (например, менять глобальное состояние или выбрасывать неожиданные исключения), это как если бы вы заказали пиццу, а получили бутерброд. У меня, кстати, недавно так было - заказывали нагетсы, а получили картошку).
3) Инварианты - это правила, которые нельзя нарушать
Ваш код - это игра с правилами. Инвариант - это такое правило, которое должно выполняться всегда, что бы ни происходило.
Почему это важно?
Потому что когда начинаете мыслить в терминах логики Хоара, вы перестаёте надеяться на удачу и начинаете строить систему, которая действительно надёжна. Это как перейти от "авось пронесёт" к "я знаю, что это сработает, потому что я продумал все условия".
Лайфхак:
В следующий раз, когда будете писать функцию, спросите себя:
- Какие условия должны выполняться на входе? ("предусловие")
- Что я гарантирую на выходе? ("постусловие")
- Какие правила нельзя нарушать? ("инварианты")
Тогда код перестанет быть лотереей и станет предсказуемым, как швейцарские часы.
Но это не точно))
Я с ней знаком уже пару лет.
Хочу сейчас поделиться размышлениями по данной теме.
Что скрывается за терминами "предусловия", "постусловия" и "инварианты"? Если я скажу, что это та самая штука, которая превращает программирование из гадания на кофейной гуще в инженерную дисциплину, то это не будет преувеличением.
Вот в чём прикол:
1) Ваш код может "работать" и при этом быть полным фарсом
Вы когда-нибудь писали функцию, которая вроде бы делает что надо, но при этом где-то в глубине души понимаете, что она может сломаться в любой момент? Вот это и есть отсутствие гарантий. Логика Хоара говорит: давайте чётко прописывать, при каких условиях функция работает ("предусловие") и что она гарантирует на выходе ("постусловие").
2) Функции - это не чёрные ящики, а контракты
Каждая функция должна чётко заявлять: "Я принимаю вот это, и обещаю вернуть вот это". Если она начинает делать что-то ещё (например, менять глобальное состояние или выбрасывать неожиданные исключения), это как если бы вы заказали пиццу, а получили бутерброд. У меня, кстати, недавно так было - заказывали нагетсы, а получили картошку).
3) Инварианты - это правила, которые нельзя нарушать
Ваш код - это игра с правилами. Инвариант - это такое правило, которое должно выполняться всегда, что бы ни происходило.
Почему это важно?
Потому что когда начинаете мыслить в терминах логики Хоара, вы перестаёте надеяться на удачу и начинаете строить систему, которая действительно надёжна. Это как перейти от "авось пронесёт" к "я знаю, что это сработает, потому что я продумал все условия".
Лайфхак:
В следующий раз, когда будете писать функцию, спросите себя:
- Какие условия должны выполняться на входе? ("предусловие")
- Что я гарантирую на выходе? ("постусловие")
- Какие правила нельзя нарушать? ("инварианты")
Тогда код перестанет быть лотереей и станет предсказуемым, как швейцарские часы.
Но это не точно))
🔥6👍3👀2
[Какие пред- и пост-условия должны быть? И почему это вообще важно?]
Продолжаю рассматривать данную тему. Она правда крайне интересна в практическом применении.
Слышали рекомендации "ослабляй предусловия и усиливай постусловия"?
1) Предусловия (Preconditions): Будьте либеральны на входе
- Какими должны быть: Максимально слабыми (широкими).
- Пример: Вместо "принимаю только массив строк", скажите "принимаю массив, одиночную строку или даже null".
- Почему это важно: Это делает ваш код удобным. Другим разработчикам (и вам через месяц) не нужно обкладывать вызов вашей функции кучей проверок
2) Постусловия (Postconditions): Будьте строги на выходе
- Какими должны быть: Максимально сильными (узкими и точными).
- Пример: Вместо "возвращаю объект и null", гарантируйте "возвращаю валидный объект".
- Почему это важно: Это дает уверенность. Вызывающий код точно знает, чего ожидать. Ему не нужно гадать "а что, если вернется undefined?". Это снижает когнитивную нагрузку и количество багов.
Оказывается есть золотое правило:
Советую почитать об этом законе подробнее.
Этот принцип работает не только в протоколах интернета, но и в архитектуре любой надежной программы.
Но есть один нюанс.
Всегда ли нужно быть "либеральным" и принимать любые данные? Где именно нужно ослаблять предусловия? Неужели во всех функциях проекта?
В следующем посте разберем, где нужно ослаблять предусловия, а где этого делать не следует.
Продолжаю рассматривать данную тему. Она правда крайне интересна в практическом применении.
Слышали рекомендации "ослабляй предусловия и усиливай постусловия"?
1) Предусловия (Preconditions): Будьте либеральны на входе
- Какими должны быть: Максимально слабыми (широкими).
- Пример: Вместо "принимаю только массив строк", скажите "принимаю массив, одиночную строку или даже null".
- Почему это важно: Это делает ваш код удобным. Другим разработчикам (и вам через месяц) не нужно обкладывать вызов вашей функции кучей проверок
if (x !== null && Array.isArray(x)). Вы берете эту рутину на себя, делая систему устойчивой к "грязным" данным.2) Постусловия (Postconditions): Будьте строги на выходе
- Какими должны быть: Максимально сильными (узкими и точными).
- Пример: Вместо "возвращаю объект и null", гарантируйте "возвращаю валидный объект".
- Почему это важно: Это дает уверенность. Вызывающий код точно знает, чего ожидать. Ему не нужно гадать "а что, если вернется undefined?". Это снижает когнитивную нагрузку и количество багов.
Оказывается есть золотое правило:
"Будь строг к тому, что производишь, и либерален к тому, что принимаешь."
(Закон Постела)
Советую почитать об этом законе подробнее.
Этот принцип работает не только в протоколах интернета, но и в архитектуре любой надежной программы.
Но есть один нюанс.
Всегда ли нужно быть "либеральным" и принимать любые данные? Где именно нужно ослаблять предусловия? Неужели во всех функциях проекта?
В следующем посте разберем, где нужно ослаблять предусловия, а где этого делать не следует.
👍8
[Где и когда применять ослабление предусловий?]
Неужели нужно придерживаться ослабления предусловий в каждой функции?
Зачем мы продумываем систему типов, если мы должны ослаблять предусловия?
Есть ответы на вопросы.
Этот подход критически важен на границах системы или модулей. Там, где я не контролирую вызывающий код.
1. Публичные библиотеки и утилиты:
- Функции типа
- Почему: Ими пользуются разные части системы. Если утилита падает от
2. Обработчики данных из внешних источников (API, User Input):
- Парсеры ответов бэкенда, валидаторы форм.
- Почему: Мы не доверяем внешнему миру. Соседний микросервис может прислать мусор. Пользователь может ввести что угодно. Код на границе должен быть готов принять "любой" вход и безопасно его обработать (или отвергнуть с понятной ошибкой).
(Вспоминаем подход Parse, don't validate, о котором писал выше)
А вот внутри ядра системы, где я полностью контролирую потоки данных, лучше использовать сильные предусловия (Design by Contract).
1. Бизнес-логика и ядро (Domain Model):
- Методы сущностей (
- Почему: Если метод
2. Приватные методы и внутренние хелперы:
- Функции, которые вызываются только из одного-двух мест, которые вы контролируете.
- Почему: Лишние проверки замусоривают код и снижают производительность. Если вы гарантируете (через типы или логику), что
Есть еще правило "Баррикады"
(погуглите или спросите у LLM)
1) Стены замка (Границы):
Здесь стоят стражники (ослабленные предусловия). Они проверяют всех входящих, отсеивают врагов, чистят грязные ботинки (нормализуют данные).
2) Внутри замка (Ядро):
Все доверяют друг другу. Не нужно носить оружие и проверять документы на каждом шагу (сильные предусловия). Они ожидают, что стража на входе уже сделала свою работу.
Итого:
- На границах (UI, API, Utils):
Нужно быть либеральным (принимать многое - "слабые предусловия").
- В ядре (Domain):
Нужно быть строгим (требовать валидных данных - "сильные предусловия").
Не зря же я тратил время и продумывал систему типов))
Неужели нужно придерживаться ослабления предусловий в каждой функции?
Зачем мы продумываем систему типов, если мы должны ослаблять предусловия?
Есть ответы на вопросы.
Этот подход критически важен на границах системы или модулей. Там, где я не контролирую вызывающий код.
1. Публичные библиотеки и утилиты:
- Функции типа
formatDate, parseJson, safeDivide.- Почему: Ими пользуются разные части системы. Если утилита падает от
null, это заставляет каждого потребителя писать проверки. Лучше один раз обработать null внутри утилиты.2. Обработчики данных из внешних источников (API, User Input):
- Парсеры ответов бэкенда, валидаторы форм.
- Почему: Мы не доверяем внешнему миру. Соседний микросервис может прислать мусор. Пользователь может ввести что угодно. Код на границе должен быть готов принять "любой" вход и безопасно его обработать (или отвергнуть с понятной ошибкой).
(Вспоминаем подход Parse, don't validate, о котором писал выше)
А вот внутри ядра системы, где я полностью контролирую потоки данных, лучше использовать сильные предусловия (Design by Contract).
1. Бизнес-логика и ядро (Domain Model):
- Методы сущностей (
Order.calculateTotal(), User.changePassword()).- Почему: Если метод
calculateTotal вызван для заказа без товаров - это баг в логике программы, а не "допустимый случай". Здесь лучше упасть (fail fast) или выбросить исключение, чтобы разработчик сразу нашел ошибку. Замалчивание проблемы (возврат 0) может привести к потерям.2. Приватные методы и внутренние хелперы:
- Функции, которые вызываются только из одного-двух мест, которые вы контролируете.
- Почему: Лишние проверки замусоривают код и снижают производительность. Если вы гарантируете (через типы или логику), что
null сюда не придет - не надо его обрабатывать.Есть еще правило "Баррикады"
(погуглите или спросите у LLM)
1) Стены замка (Границы):
Здесь стоят стражники (ослабленные предусловия). Они проверяют всех входящих, отсеивают врагов, чистят грязные ботинки (нормализуют данные).
2) Внутри замка (Ядро):
Все доверяют друг другу. Не нужно носить оружие и проверять документы на каждом шагу (сильные предусловия). Они ожидают, что стража на входе уже сделала свою работу.
Итого:
- На границах (UI, API, Utils):
Нужно быть либеральным (принимать многое - "слабые предусловия").
- В ядре (Domain):
Нужно быть строгим (требовать валидных данных - "сильные предусловия").
Не зря же я тратил время и продумывал систему типов))
👍4💯1
[Важное дополнение. Ослабление предусловий]
Одни пропагандируют и рекомендуют "ослаблять предусловия и усиливать постусловия" (закон Постело), другие с таким же успехом критикуют и пишут что так делать нельзя.
1) "Марсианские наушники" Джоэла Спольски (2008) (перевод на habr)
На мой взгляд это не прямая критика, а иллюстрация системной проблемы. Спольски показывает, что когда в экосистеме "многие-ко-многим" (много разработчиков браузеров и много сайтов) все следуют принципу "будь либерален в том, что принимаешь", но интерпретируют его по-разному из-за неточных спецификаций, это приводит к хаосу. Стандартом де-факто становятся баги и хаки самого популярного участника (в статье - IE6), что тормозит развитие всей сети. Это критика бесконтрольного применения закона.
Обращаю внимание на год статьи и на уточнение модели "многие-ко-многим".
2) Майкл Т. Нигард, "Release It!" (2007)
Нигард утверждает, что попытки быть "либеральным" и обработать любые ошибочные данные часто приводят к тому, что система переходит в некорректное или деградировавшее состояние, а потом падает в гораздо более сложном для диагностики месте. Гораздо надёжнее быстро и явно отказать при первом же нарушении контракта (например, при получении невалидного сообщения), чем пытаться его "понять и починить". Это повышает наблюдаемость и упрощает восстановление.
3) Статья "The Harmful Consequences of the Postel Prescription" (Вредные последствия предписания Постела)
Это прямая критика. Автор утверждает, что принцип Постела был ошибочным с самого начала для протоколов, где есть несколько независимых реализаций (тот самый "рынок многие-ко-многим").
Что в итоге?
Прочитав критику, хочется подумать что это очередная тема для холивара. Но данная критика однозначно достойна внимания. И помнить об этом точно нужно.
Одни пропагандируют и рекомендуют "ослаблять предусловия и усиливать постусловия" (закон Постело), другие с таким же успехом критикуют и пишут что так делать нельзя.
1) "Марсианские наушники" Джоэла Спольски (2008) (перевод на habr)
На мой взгляд это не прямая критика, а иллюстрация системной проблемы. Спольски показывает, что когда в экосистеме "многие-ко-многим" (много разработчиков браузеров и много сайтов) все следуют принципу "будь либерален в том, что принимаешь", но интерпретируют его по-разному из-за неточных спецификаций, это приводит к хаосу. Стандартом де-факто становятся баги и хаки самого популярного участника (в статье - IE6), что тормозит развитие всей сети. Это критика бесконтрольного применения закона.
Обращаю внимание на год статьи и на уточнение модели "многие-ко-многим".
2) Майкл Т. Нигард, "Release It!" (2007)
Нигард утверждает, что попытки быть "либеральным" и обработать любые ошибочные данные часто приводят к тому, что система переходит в некорректное или деградировавшее состояние, а потом падает в гораздо более сложном для диагностики месте. Гораздо надёжнее быстро и явно отказать при первом же нарушении контракта (например, при получении невалидного сообщения), чем пытаться его "понять и починить". Это повышает наблюдаемость и упрощает восстановление.
3) Статья "The Harmful Consequences of the Postel Prescription" (Вредные последствия предписания Постела)
Это прямая критика. Автор утверждает, что принцип Постела был ошибочным с самого начала для протоколов, где есть несколько независимых реализаций (тот самый "рынок многие-ко-многим").
Что в итоге?
Прочитав критику, хочется подумать что это очередная тема для холивара. Но данная критика однозначно достойна внимания. И помнить об этом точно нужно.
👀4👍2
[Где я был и что делал за последние 2 месяца]
Привет! Пингую. Я жив.
За эти 2 месяца перепробовал практически все модели и ии-инструменты в разработке, которые сейчас на слуху.
Активно знакомился с cli-инструментами:
- opencode
- claude code
- qwen code
Попробовал работу с большим кол-вом моделей:
- glm-4.7
- grok-code-fast
- minimax-m2.1
- deepseek-v3.2
- claude-opus-4-5
- claude-sonet-4-5
- gpt-5.2
- gpt-5-pro
- gpt-5-codex
- qwen3-max
- qwen3-v1-235b-a22b-thinking
- devstral-2512
- gemini-3-pro
- gemini-3-flash
Пока работал была волна релизов новых моделей. Их еще не пробовал)
Как за всем успевать?
Привет! Пингую. Я жив.
За эти 2 месяца перепробовал практически все модели и ии-инструменты в разработке, которые сейчас на слуху.
Активно знакомился с cli-инструментами:
- opencode
- claude code
- qwen code
Попробовал работу с большим кол-вом моделей:
- glm-4.7
- grok-code-fast
- minimax-m2.1
- deepseek-v3.2
- claude-opus-4-5
- claude-sonet-4-5
- gpt-5.2
- gpt-5-pro
- gpt-5-codex
- qwen3-max
- qwen3-v1-235b-a22b-thinking
- devstral-2512
- gemini-3-pro
- gemini-3-flash
Пока работал была волна релизов новых моделей. Их еще не пробовал)
Как за всем успевать?
👍5
Чем больше ты работаешь в одной теме, тем больше прокачиваются мысленные представления в голове.
Каждая новая строка кода, каждая новая выполненная таска, каждая новая прочитанная книга - шаг за шагом, кирпичик за кирпичиком из примитивной карты в голове делают 3D-модель местности со спутниковой съемкой высокого разрешения. Это позволяет ориентироваться быстрее, видеть скрытые пути и мгновенно замечать, если допущена ошибка.
Каждая новая строка кода, каждая новая выполненная таска, каждая новая прочитанная книга - шаг за шагом, кирпичик за кирпичиком из примитивной карты в голове делают 3D-модель местности со спутниковой съемкой высокого разрешения. Это позволяет ориентироваться быстрее, видеть скрытые пути и мгновенно замечать, если допущена ошибка.
💯3
[2 недели я использовал Claude Code с Opus4.6]
Первые впечатления крайне положительные.
На мой взгляд, стоимость высока.
Можно ли было выполнить эту работу c другими моделями/инструментами?
- Да, однозначно можно.
Было бы качество хуже?
- Скорее всего да, но это не точно. Зависит от задач.
Больше бы времени было потрачено на задачи при использовании других инструментов?
- Скорее всего да, но не критично.
CC + Opus4.6 практически всегда предлагал лучшее решение и без ошибок.
Обратил внимание на самостоятельность.
В одной из задач СС решил проверить корпоративную дизайн-систему, самостоятельно подключившись к ней по MCP. (Хотя я такую задачу не ставил). Это вызвало у меня удивление.
В итоге было предложено лучшее решение, которое для меня было неочевидным.
Первые впечатления крайне положительные.
На мой взгляд, стоимость высока.
Можно ли было выполнить эту работу c другими моделями/инструментами?
- Да, однозначно можно.
Было бы качество хуже?
- Скорее всего да, но это не точно. Зависит от задач.
Больше бы времени было потрачено на задачи при использовании других инструментов?
- Скорее всего да, но не критично.
CC + Opus4.6 практически всегда предлагал лучшее решение и без ошибок.
Обратил внимание на самостоятельность.
В одной из задач СС решил проверить корпоративную дизайн-систему, самостоятельно подключившись к ней по MCP. (Хотя я такую задачу не ставил). Это вызвало у меня удивление.
В итоге было предложено лучшее решение, которое для меня было неочевидным.
👍4
[Handy. Хотите испытать новые ощущения? Ставим задачи голосом]
Handy - это бесплатное приложение с открытым исходным кодом для преобразования речи в текст, которое работает полностью в автономном режиме.
Если хотите говорить со своими агентами голосом, то рекомендую handy.
Можно установить различные модели, которые будут заниматься самим преобразованием голоса. Рекомендую Parakeet v3 - это модель автоматического распознавания речи от NVIDIA, способная работать в режиме реального времени.
Работает правда быстро. Текст вставляется автоматически там где установлена каретка. Русский язык преобразует достаточно хорошо.
P.s.
Правда испытал очень странные ощущения от такого взаимодействия с ноутбуком)
Попробуйте.
Ссылки:
сайт: https://handy.computer/
github: https://github.com/cjpais/Handy
Handy - это бесплатное приложение с открытым исходным кодом для преобразования речи в текст, которое работает полностью в автономном режиме.
Если хотите говорить со своими агентами голосом, то рекомендую handy.
Можно установить различные модели, которые будут заниматься самим преобразованием голоса. Рекомендую Parakeet v3 - это модель автоматического распознавания речи от NVIDIA, способная работать в режиме реального времени.
Работает правда быстро. Текст вставляется автоматически там где установлена каретка. Русский язык преобразует достаточно хорошо.
P.s.
Правда испытал очень странные ощущения от такого взаимодействия с ноутбуком)
Попробуйте.
Ссылки:
сайт: https://handy.computer/
github: https://github.com/cjpais/Handy
👍3❤2
Поднял свой прокси-сервер для телеги.
Посмотрим сколько будет работать.
Посмотрим сколько будет работать.
❤4👍2
Увеличил пропускную способность прокси-сервера.
Работает стабильно.
Работает стабильно.
❤7👍1
Телеграм выкатили обновление 12.6.4, в котором исправили старую проблему с прокси.
У меня андроид. Обновление уже доступно. Подтверждаю что после обновления недоступные прокси-сервера снова работают.
У меня андроид. Обновление уже доступно. Подтверждаю что после обновления недоступные прокси-сервера снова работают.
👍2