В последние несколько лет в среде технических писателей все больше на слуху концепция Docs as Code. Если вы раньше не сталкивались с этим термином, он обозначает подход к разработке технической документации с использованием тех же инструментов и процессов, что и написание кода. Если DocOps это про процессы и коллаборацию, то Docs as Code — про инструментарий, при помощи которого мы несмотря ни на что. Мы выбрали этот подход, когда создавали портал документации Plesk.

В этой статье я кратко расскажу, что такое Docs as Code и зачем оно нужно, а затем дам несколько советов относительно того, как это чудо враждебной техники внедрять, сдобрив всю историю рассказами о тех граблях, на которые мы наступили, топая в светлое будущее. Я старался писать такую статью, которая пригодилась бы мне в 2017 году, когда мы эту кашу заваривали.

Всем привет, меня зовут Женя Колесников, я из команды Yandex Infrastructure. Сегодня я расскажу, как мы пришли к написанию документации в концепции Docs as Code, придумали для этого набор инструментов, назвали его красивым именем Diplodoc и выложили в опенсорс — теперь вы тоже можете им воспользоваться.

Если вкратце, Docs as Code — это подход к написанию технической документации, который рассматривает её не как набор текстов, а как код. Исходя из этой концепции, к документации могут применяться все те же принципы, инструменты и процессы, что и к самому коду. Расскажу, как это происходит на примере Diplodoc — и чем он может облегчить вам жизнь.

Два года назад мы запустили в школе Metaclass курс «Деплой приложений в Kubernetes». С сегодняшнего дня мы делаем его бесплатным и приглашаем пройти всех, кто хочет прокачаться и попасть на стажировку к нам в команду.

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

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

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

• несколько сервисов для планирования и мониторинга задач;

• сервисы для построения схем (процессы, пользовательские пути, структура миграции данных и тд);

• трекеры времени;

• сервисы по аналитике;

• инструменты для составления списков.

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

Поэтому я загорелся идеей сделать систему, которая облегчит работу.

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

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

Мы выбрали пути развития руководителей разработки темой следующего Team Leader Meetup, который пройдёт вечером 28 ноября в московском офисе Яндекса. Обсудить эту тему можно будет с экспертами из крупных IT-компаний. Регистрация ещё открыта.

В этот раз нашими экспертами стали:

• Николай Крапивный, руководитель бекенд-разработки, Badoo
• Роман romas1982 Ивлиев, CTO, mos.ru
• Александр Поломодов, руководитель отдела исследований и разработки, Tinkoff.ru
• Борис Тоботрас, директор центра программных решений, Инфосистемы Джет
• Виктор Ламбурт, руководитель направления рекомендательных продуктов, Яндекс
• Игорь Кураленок, генеральный директор, Лига Экспертов

Сегодня на Хабре мы задаём им ряд вопросов, чтобы задать тон будущей дискуссии:

1. Какие советы вы бы дали вашему коллеге – сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?
2. Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?
3. Сколько времени стоит уделять работе над техническими задачами, а сколько – над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?

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

Меньше заниматься разработкой

Трудно утверждать, что методология Agile неэффективна. Практически все команды разработки программного обеспечения стараются ей следовать. Простой способ начать внедрять гибкую методологию — это добавить пару ее компонентов в рабочий процесс. Одним из самых популярных и при этом важных компонентов считается оценка в Story Points. Однако сколько команд оценивали ее реальное влияние? На самом ли деле оценка времени, затраченного на каждую задачу, приносит пользу? По моему опыту, это не так.

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

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

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

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

Полезная ссылка с подробным объяснением концепции микрофронтенда.

Фильмы - это лекарство для психики. Что включается у нас в голове, когда мы смотрим фильм? Возможно превратить просмотр кино в индивидуальную психотерапию?

Для начала отделим мух от котлет. Психолог, психотерапевт, психиатр и невролог чем они отличаются? Самое простое отличие в том, что психолог не является врачом. Психотерапевт, психиатр и невролог - это врачи.

Статья про мемоизацию оказалась объёмной и включает в себя разбор hoc memo, хуки useMemo и useCallback, затрагивает тему useRef. Было принято решение разбить статью на 2 части, в первой части разберем когда нужно и когда ненужно использовать memo, какое у него api, какие проблемы решает. Во второй части разберем хуки useMemo, useCallback, а также некоторые проблемы этих хуков, которые можно решить с помощью useRef.

В прошлых статьях мы разбирали как работать с useState и с useEffect. Знаем: код компонента будет выполняться каждый раз при его обновлении. Отсюда возникает проблема - данные и сложные вычисления будут теряться, также будет происходить лишнее обновление дочерних компонентов. Эти проблемы решает хук useMemo и обертка над ним useCallback, но оба работают в связке с memo hoc.

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

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

Привет, друзья!

Представляю вашем вниманию адаптированный и дополненный перевод этой замечательной статьи.

AbortController и AbortSignal предоставляют возможность применения некоторых интересных паттернов, рассмотрению которых и посвящена данная статья.

Однако давайте начнем с типичного примера использования AbortController.

Спрос на бэкенд-разработчиков — а Go неотделим от бэкенд-программирования — стабильно растет. У самого же Golang немало плюсов: простой, строгий, статически типизированный, он обладает развитой стандартной библиотекой и славится поддержкой параллельного и асинхронного программирования. При этом в Golang нет классов и нет поддержки наследования, что значительно повышает удобство поддержки кода. Благодаря этим и другим преимуществам Go в последние годы сохраняет статус популярного и перспективного языка.

В МойОфис мы широко используем Go в качестве основного языка для разработки корпоративной почты нового поколения Mailion. При этом разрабатываем на нём не только микросервисы, но и собственное хранилище с поддержкой дедупликации (про устройство Mailion читайте здесь). В связи с этим мы постоянно следим за книжными новинками и актуальными темами современной бэкенд-разработки. Специальной литературы по теме Golang существует немало, однако с помощью наших разработчиков мы выбрали самые важные, профессионально полезные и увлекательно написанные издания.

Делимся рекомендациями книг под катом!

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

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

В конце статьи делюсь своим личный рейтингом городов для релокации!

Встреча с клиентом - подготавливаемся к встрече с клиентом, проводим первичную аналитику и подготовку.

"Где хорошо начинают, там хорошо и кончают".

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

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

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

В этой заметке я бы хотел остановиться на различных нюансах, полезных при отладке. Какие-то из них я почерпнул в сети (например в комментариях на Хабре), до каких-то додумался сам. Надеюсь вы найдёте для себя что-нибудь полезное.

Под катом:

— Как отладить popup-ы, которые исчезают при потере фокуса
— Как убить повисший JS-цикл, не убивая вкладку
— Различные нюансы работы с breakpoint-ми
— Методы ведения войны с sourceMaps
— Перехват network-запросов
— Как отладить race-condition
— Почему стоит опасаться галочки "disable cache"
— Что делать если у вас не Hi-DPI экран?

Высшее образование я получал в МГТУ, изучал ядерные реакторы и энергетические установки. Однако несмотря на позитивное впечатление от учёбы и в целом неплохие перспективы, после вуза я решил стать разработчиком. И получилось! Вот уже три года я работаю в Java-разработчиком, ни на секунду не прерывая своё обучение профессии. Я расскажу о том, какие способы обучения оказались для меня самыми эффективными. Не факт, что они зайдут всем и каждому. Надеюсь, кто-то почерпнёт для себя что-нибудь полезное.