Как писать документацию, которую разработчики будут читать

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

https://habr.com/ru/companies/otus/articles/1005780/

#DEVREL #документация_для_разработчиков #техническая_документация #справочник_API #developer_experience

Zod: строгая валидация и удобная типизация. Опыт перехода

Привет, Хабр! Меня зовут Сергей, я фронтенд-инженер в Банки.ру. В этой статье расскажу, как Zod помог нам перестать писать валидацию на уровне полей, подружился с React Hook Form и стал единым источником правды о структуре данных. К Zod мы пришли не сразу. Долгое время типы и валидация у нас жили в разных слоях приложения: TypeScript определял структуру данных во время разработки, а отдельные функции или библиотеки (вроде Yup) проверяли входящие значения в рантайме. Это классическая проблема: дублирование логики и рассинхрон. Типы в interface поменялись, а валидация осталась прежней (или наоборот). Мы пробовали Yup, но он казался громоздким в связке с TS: типы приходилось выводить вручную или мириться с тем, что схемы выглядят непрозрачно. В какой-то момент стало непонятно: зачем тащить отдельную библиотеку, если проще написать if (typeof x === 'string') ? С переходом на Zod всё стало значительно проще: одна схема одновременно является и валидатором, и источником типа данных.

https://habr.com/ru/companies/banki/articles/994886/

#zod #typescript #валидация_данных #runtime_валидация #react_hook_form #типизация_данных #frontend_разработка #валидация_форм #developer_experience #валидация

AI без интернета (офлайн) на своем компьютере

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

https://habr.com/ru/articles/981290/

#Сезон_ИИ_в_разработке #программирование #искусственный_интеллект #ai #developer_experience #software_development #ии #ии_чатбот #ииагенты #ииассистент

Что ждет участников Ural Digital Weekend 2025? Раскрываем детали

Привет! На связи команда Spectr ! 1-2 августа в Перми мы проведем уже традиционную конференцию про разработку и управление в IT-компаниях — Ural Digital Weekend 2025. Сейчас уже готова программа всех секций. Рассказываем, кто выступит в 2025 году. Узнать подробности о программе

https://habr.com/ru/articles/919802/

#backend #мероприятия #разработка #frontend #развитие_карьеры #управление_разработкой #управление_проектами #frontend #devops #developer_experience

Поговорим о DevSecOps и культурной трансформации в мире разработки

Киберугрозы растут, уязвимости в коде дороже, чем когда-либо, а традиционные подходы к безопасности терпят крах. Почему компании теряют миллионы, игнорируя безопасность до финального этапа разработки? Как DevSecOps меняет правила игры, превращая защиту данных в часть повседневной работы разработчиков? В этой статье вы узнаете: Почему «последняя миля» в тестировании безопасности — это провал : статистика OWASP и NIST о том, как 97% приложений содержат уязвимости, а исправление ошибок после релиза обходится в 6 раз дороже. Как DevSecOps убирает барьеры между командами : интеграция безопасности в CI/CD, автоматизация проверок и сдвиг «влево» (Shift Left) — от теории к реальным кейсам Microsoft, Netflix и Capital One. Почему успех DevSecOps зависит не от инструментов, а от культуры : как руководство может создать среду, где безопасность становится общей ответственностью, а не «чужой заботой». Вызовы внедрения и пути их преодоления : от сопротивления изменениям до обучения разработчиков — шаги, которые сделают вашу команду готовой к цифровым угрозам будущего. Статья подойдёт для разработчиков, руководителей IT-команд, специалистов по кибербезопасности и всем, кто хочет превратить уязвимости в прошлое.

https://habr.com/ru/articles/918350/

#devops #devsecops #development #developer #developer_experience #tools_programming #security

Чистый код — красивая архитектура. А работает ли это?

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

https://habr.com/ru/companies/ruvds/articles/902996/

#программирование #код #дизайн_кода #архитектура_ПО #code_style #developer_experience #ruvds_статьи

Чистый код — красивая архитектура. А работает ли это?

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

https://habr.com/ru/companies/ruvds/articles/902996/

#программирование #код #дизайн_кода #архитектура_ПО #code_style #developer_experience #ruvds_статьи

Почему JS (и TS) это плохой язык

Я знаю, что на эту тему уже было сказано много, но настал мой черед. На JS я пишу больше 10 лет, так что терпел я достаточно. Мы называем это “джаваскрипт”, но под капотом скрываются три разные сущности: EcmaScript, среда исполнения и экосистема. Иногда о них стоит говорить отдельно, но сегодня я хочу обсудить всё сразу и объяснить, почему джаваскрипт — это плохой язык. Не в смысле “не работает”, а в смысле “заставляет страдать”.

https://habr.com/ru/articles/905480/

#JS #JavaScript #TypeScript #TS #Go #Backend #Frontend #React #DX #Developer_Experience