Привет, Хабр! Я управляю командами разработки уже 10 лет.

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

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

Поэтому выключаю тумблер «не будь выскочкой» и делюсь «секретами».



Тут не будет стандартных «делегируй», «налаживай процесс», «стой в правильной позе на стендапе» — об этом написано уже достаточно. Будет о другом.

Я думаю, многие из Вас слышали мнение о том что кода в контроллерах быть не должно, и потому контроллер с методами в одну строку считаются «Best Practice».Я в свою очередь сомневаюсь в том, что польза от этого так уж велика. Если у Вас возникали похожие мысли, прошу под кат.

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

Клиент: Привет, как поднять VPN на сервере?
Поддержка: Ваш сервер в порядке, мы не занимаемся серверным администрированием [закрывает тикет].

Поддержка права? Права. Но клиент обиделся. Потому что можно было то же самое написать нормально:

Клиент: Привет, как поднять VPN на сервере?
Поддержка: Добрый день! Я не могу помочь вам настроить VPN, потому что мы оказываем поддержку только в случае, если что-то не работает на нашей стороне. Но у нас есть статья в базе знаний, как просто поднять VPN. Спасибо за обращение [закрывает тикет].

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

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

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

Привет, Хабр! Меня зовут Богдан, я работаю в ПИК Digital Front-End тимлидом. Большую часть проектов мы разрабатываем на Angular и недавно я решил пересмотреть наши стайл гайды, а также добавить новые инструменты для более удобной работы.

В качестве линтера я решил использовать ESLint, так как в скором времени на него планируют перевести Angular. И в этой статье я хочу поделиться инструкцией по переходу с TSLint на ESLint, а заодно рассказать, как запускать Prettier из ESLint, как добавить правила стайл гайда AirBnB, и как сделать линтинг удобным и незаметным с помощью настройки VS Code и Git хуков.

Дисклеймер:

Я не программирую с трёх лет, не знаю наизусть Кнута, не являюсь призёром олимпиад по информатике и чемпионатов по спортивному программированию, не училась в MIT. У меня за плечами образование по информатике и 6 лет опыта в коммерческой разработке. И до недавнего времени я не могла пройти дальше первого технического скрининга в IT-гиганты из FAANG (Facebook, Amazon, Apple, Netflix, Google и подобные), хотя предпринимала несколько попыток. 

Но теперь всё изменилось, я получила несколько офферов и хочу поделиться опытом, как можно к этому прийти. Речь пойдёт о позиции Software Engineer в европейских офисах перечисленных компаний.

Мы широко используем микросервисную архитектуру, хоть и не считаем ее панацеей, и чуть больше 2 лет назад начали переходить на язык Go. Он сравнительно прост и, на мой взгляд, очень хорошо подходит для создания простых, небольших и быстрых микросервисов. Эта простота имеет и обратную сторону: из-за неё возникает множество способов решить одну и ту же задачу.

Казалось бы, насколько сильно может отличаться один микросервис, который ходит в базу данных, от другого микросервиса, который ходит в соседнюю базу данных? Например, одна команда использует Go 1.9, glide, стандартный database/sql и одну структуру проекта, а в это же время другая команда использует Go 1.13, modules, sqlx и, конечно же, другую структуру проекта.

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

Меня зовут Алексей Партилов, я техлид команды web-разработки в компании Lamoda. В этой статье я расскажу, как мы справляемся с разношерстностью около 40 наших микросервисов на Go. Статья будет полезна разработчикам, которые только вливаются в Go и не знают, с чего начать более сложный проект, чем “helloworld”.

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

Опытные продакты знают, что просто пальцем в небо не ткнёшь и среди всех горящих задач нужно выделить самые весомые. Миша Карпов, ex-Product Director Skyeng, через одно из исследований выяснил, что российские и зарубежные компании разбивают приоритизацию на два этапа: быстрая и медленная оценка.



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

В этой статье я опишу процесс создания сервера с gRPC и RESTful JSON API одновременно и Swagger документацию к нему.

Эта статья — продолжение разбора различных способов реализаций API-сервера на Golang с автогенерацией кода и документации. Там я обещал более подробно остановиться на этом подходе.

grpc-gateway — это плагин protoc. Он читает определение сервиса gRPC и генерирует обратный прокси-сервер, который переводит RESTful JSON API в gRPC. Этот сервер создается в соответствии с пользовательскими параметрами в вашем определении gRPC.

Это выглядит вот так:

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

Другие считают — ты делаешь коммиты как хочешь, это часть твоего личного рабочего процесса. А вот пул реквесты описываются детально: что сделано, как сделано, зачем сделано. Как протестировано, какую проблему решает, на что стоит обратить внимание.

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

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

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

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

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

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



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

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

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

Что мы говорим Богу смерти? — Не сегодня.
Сирио Форель, сериал «Игра престолов».

Насколько действительно опасен коронавирус COVID-19? Сколько людей умрёт от коронавируса в мире? А сколько – в России? Так ли необходимы жесткие меры, принимаемые для борьбы с коронавирусом в большинстве стран мира? Что принесет больше ущерба: смерть людей от коронавируса или падение экономики, вызванное ограничительными мерами?

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

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

In my previous post I mentioned that I had started my freelance career as a senior full stack software engineer. The first problem I faced was clients – it's a pretty tough job to find them. I will show you my trial and error approach to getting a first paid contract. It’ll start from paid ads on social networks, going through content marketing and surprisingly ending on free promotional channels. At each step I will share with you my thoughts, tips and samples. The whole journey from zero to one client took me three weeks.

At the start of the journey I had a portfolio site, several photos for ads, and a lot of optimism. I need to mention that I decided to avoid freelance marketplaces such as UpWork and Freelance.com as their rates are too low. I also avoided TopTal and Turing.com as I don’t want to spend my free time on their several-stage interviews (I've played this game with Google once, and don’t want to do it again).

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

Однако описанный мною метод громоздкий и сложный для восприятия. Пришло время переписать фильтрацию на декораторы.

Как все начиналось

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

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

Документация

Уверен, что никакой другой framework для тестирования не имеет такой понятной, объёмной и обширной документации. Она написана на простом английском языке, содержит описание API, тонну полезных гайдов от разработчиков проекта, к примеру — настройка конфигурации.

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

Ecma International, Technical Committee 39 или по-простому TC39 — это группа JavaScript-разработчиков, создателей реализаций технологий, академиков и других заинтересованных сторон, которые вместе с сообществом поддерживают и развивают JavaScript как платформу.

Участники TC39 обычно рассказывают что-то интересное, пользуясь своим глубоким пониманием JavaScript. Но кое-кому кажется, что они слишком далеко ушли от проблем простых разработчиков. Где разработчик языка, и где человек, который каждый день на практике пишет фронтенды?

Давайте познакомимся с докладом, который сочетает и глубину понимания, и высокую практическую применимость. Встречайте новый рассказ Romulo Cintra о проблемах интернационализации, которые будут решены новым API, которое вскоре появится в JavaScript.



Romulo Cintra — делегат TC39, работает в разработке и архитектуре уже более 10 лет, специализируется на вебе, мобильной разработке и облаках. В этом докладе из первых рук сопредседателя MessageFormat Working Group вы узнаете, какие варианты решения существующих проблем есть уже сейчас, и в каком виде их собираются решать посредством нового API в самом JavaScript.

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

Далее повествование от лица спикера.

Many dev teams get split over formatting. And their typical day looks like this: you come to work, have some coffee, write some code, everything’s fine — then bam! Code review where you’re told you put a brace in the wrong place.



It was an everyday reality for one of Skyeng dev teams a year ago. Then someone had enough and said, “Guys, from now on we use Prettier. Is everyone ok with that?” And then there were no more debates about formatting. We’ve installed Prettier in the frontend repo and all the teams use it.

Если вы регулярно пишете приложения на Angular и потратили на это не одну сотню часов, вы, скорее всего, знаете об этих функциях. Но, всё же, чтобы убедиться — прочтите :)

Прежде чем мы перейдем к функциям Angular, стоит упомянуть один очень полезный инструмент. Bit (Github) позволяет с легкостью работать над Angular-компонентами вместе и делиться ими. От души рекомендую его для поддержания консистентного интерфейса, ускорения разработки и минимизации количества ошибок в коде.


Пример: Круговые загрузчики для Angular с bit.dev

Доброго времени суток, друзья!

Вместо введения (постановка задачи)

Все началось с изучения чужих слайдеров (готовых решений в сети, типа bxslider, owlcarousel и slick). Когда-нибудь я напишу подробные руководства по работе с этими инструментами (sweet dreams). Появилось желание написать свой слайдер. Однако вскоре (в том числе, после прочтения нескольких статей на Хабре) пришло осознание, что просто слайдер — это для слабаков. Нужно что-то более радикальное.

В итоге придумал себе такую задачу: написать генератор адаптивной галереи со встроенным слайдером.

Условия:

• Возможность загружать любое количество изображений (из любого места на жестком диске).
• Галерея состоит из загруженных изображений, разметка формируется «на лету» с соблюдением семантики HTML5.
• Галерея одинаково хорошо смотрится на экранах с различным разрешением.
• При клике на любом изображении генерируется слайдер.
• При генерации слайдера затемняется фон.
• Изображение, по которому кликнули — первый слайд.
• Переключение слайдов реализовано через DOM.
• Слайды переключаются плавно.
• Возможность управлять переключением слайдов с помощью кнопок и клавиатуры.
• Возможность вернуться к галерее при клике на текущем слайде и кнопке, а также с помощью клавиатуры.
• Чистый JavaScript (вся разметка через JS).
• Минимум кода.

Итак, поехали (как сказал Гагарин, отправляясь в космос).