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

Большинство предложений разбивались о какие-то специфические особенности Хабра и ситуации, которые изначально не брались в расчёт. Иногда присутствовало здоровое зерно логики. Встречались и чрезмерно сложные фантазии. Мы читали каждый такой пост и комментарии к нему, мотали на ус, делали какие-то расчёты, но всё же не спешили вносить изменения. В функцию, которая может и не идеально, но всё же 15 лет проработала основой пользовательской регуляции.

Но сегодня мы анонсируем два изменения в механизме кармы.

Привет, Хабр!

На связи Андрей Рыжкин, CTO AGIMA. В нашей компании более 30 команд разработки, и у каждой свой тимлид (или несколько). Людей много, а значит, их нужно нанимать, развивать, мотивировать, а иногда – расставаться с ними. Работа с людьми на мой взгляд – это одна из важнейших и при этом самых сложных функций тимлида или технического руководителя. Эта статья – об одном из аспектов этой работы: о том, как искать и нанимать разработчиков. В основе материала мой контент для курса «Руководитель команды разработки», а также мой опыт за весь карьерный путь от разработчика до CTO.

Исторически мы использовали GitLab 8, который работал на хосте Mac на VirtualBox. Потом конфигурация перестала устраивать, поэтому в локальной сети завели отдельную полноценную Ubuntu-машину. Заодно и GitLab обновили до версии 11.2.1-ee.

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

Эта статья является переводом материала «What is functional programming?».

В этой статье Владимир Хориков попытается ответить на вопрос: что такое функциональное программирование?

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

Математические функции не являются методами в программном смысле. Хотя мы иногда используем слова «метод» и «функция» как синонимы, с точки зрения функционального программирования это разные понятия. Математическую функцию лучше всего рассматривать как канал (pipe), преобразующий любое значение, которое мы передаем, в другое значение

_{Иллюстрация из мультфильма «Про бегемота, который боялся прививок», Союзмультфильм, 1966. Режиссёр Л. Амальрик, Художники-постановщики: Н. Привалова и Т. Сазонова.}

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

Риски вакцинации несоизмеримы с рисками смерти и тяжелых осложнений covid-2019. Официально в России на конец июля зарегистрировано 154 тыс смертей на 6,140 млн заболевших, это соответствует летальности 2,5% (цифры по избыточной смертности намного печальнее). Эпидемия не остановится пока не сформируется коллективный иммунитет, но у нас есть выбор между минимальными рисками, связанными с вакцинацией, и высокими рисками covid-2019.

Простой способ, на который решится каждый. 

Почему я отделяю вакансии в крупных компаниях от вакансий в компаниях поменьше?

Крупные vs маленькие и средние

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

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

Широкая воронка найма

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

Такую позицию я не разделяю. И как программист (тимлид немного тоже программист), я вижу, какие вакансии мне регулярно присылают рекрутеры, и понимаю, откуда эти сотни в цифрах воронки найма.

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

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

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

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

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

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

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

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

С горем пополам он закрыл одну позицию, потом вторую. Но закрыл как? Закрыл имеется в виду нашел человека и согласовал дату выхода.

Итак, найденные специалисты вышли. Руководитель провел им вводную экскурсию и со словами: "Ну, за работу" - отпустил их в свободное плавание. А что? "Ведь они профи и сами знают, что нужно делать, а моя задача им не мешать" - считал руководитель.

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

Прошло еще немного времени и в компании начали происходить разные странности. Специалисты, которых он нанял, профессионально делали то, что не нужно: первый начал трансформировать структуру, второй запустил неприоритетный проект, на третьего вообще поступали жалобы, что он слишком жесткий… . Руководитель рвал на себе волосы и не понимал, как так мог ошибиться в людях. Теперь ему, пришлось идти на крайние меры и увольнять их. Но что делать с последствиями от их деятельности и их ухода?..."

Привет всем заинтересовавшимся! Меня зовут Константин, я заместитель директора по разработке в компании «ВИСТ» (входит в ГК «Цифра»). Недавно я столкнулся с несколькими противоречивыми мнениями о проведении собеседований и подборе персонала в ИТ. В этом посте я хотел бы поделиться своим подходом к этому процессу, основанным на личном опыте участия в собеседованиях по обе стороны стола и собственных шишках, оставшихся на память от граблей, на которые я успел наступить. Не берусь никого учить и утверждать, что мой взгляд единственно верный. Всегда готов выслушать противоположное мнение — пишите в комментариях. 

Удивительно, но некоторые разработчики до сих пор считают, что коммуникации в работе не нужны или даже вредны. «Наша задача кодить, а не болтать». Конечно это эффективнее некуда, сидеть три часа и пытаться самостоятельно разобраться, как работает соседний сервис, вместо того чтобы просто спросить у коллеги и получить ответ за 15 минут. Или додумывать за ПО спорные моменты в задаче, а потом выкинуть 90 % работы и переделать заново после первого демо. Или не услышать или не понять критику на обсуждении технического решения, а потом переделывать, костылить, велосипедить и получать критические ошибки и блокеры в середине спринта. Или начать сразу разрешать инцидент, не рассказав про него владельцу продукта и бизнесу, и получить тонны негативной обратной связи от клиентов и бизнеса. Или внезапно узнать, что можно было бы обойтись меньшей кровью, ничего не разрабатывая, а решив проблему административными методами.

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

Agile строится на многих идеях (Кайзден, Lean, канбан и т.д). Но одним из наиболее важных аспектов является совокупность исследований человеческой мотивации. В этой статье я рассмотрел некоторые их этих идей и подчеркнул, что очень легко применять Agile, но упускать из виду эти мотивационные факторы.

Привет, Хабр! Меня зовут Андрей Ревяшко, я СТО сети Эльдорадо. Мы регулярно встречаемся с командой и обсуждаем различные окологиковские темы. Совсем недавно мы говорили про психотипы членов команды разработки и их влияние на общий результат. Поделюсь этим материалом и с вами. Уверен, что часть из вас точно возьмет его на вооружение.

Одной из интересных и полезных традиций нашей компании является проведение лекций. И они проводятся не только по темам из области технологий и программирования, но и по так называемым soft skills. Недавно наш пунктуальный и системный project менеджер Антон Белоусов делился приемами, которые помогают эффективно выстраивать день и не сбиваться с ритма. Спешим поделиться основными тезисами из его выступления.

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

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

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

В практической части мы реализуем простое Express-приложение, развернем его на Heroku и оценим безопасность с помощью WebPageTest и Security Headers. Также, учитывая большую популярность сервисов для генерации статических сайтов, мы настроим и развернем приложение с аналогичным функционалом на Netlify.

Исходный код приложений находится здесь.

Демо Heroku-приложения можно посмотреть здесь, а Netlify-приложения — здесь.

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

• Security headers quick reference — Google Developers
• OWASP Secure Headers Project
• Web security — MDN

Привет, Хабр!

Меня зовут Татьяна, я Team Coach R&D компании Plesk, и большую часть конфликтных ситуаций в командах мы проживаем и решаем с тимлидами вместе. 

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

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

На TeamLead Conf 2021 я поделилась преградами, которые мы преодолели, сделанными ошибками, выработанным подходом и рецептами, которые сработали. Неожиданно доклад попал в ТОП-3. Можно совместить чтение и прослушивание видео с выступления.

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

color: OldLace;
background: rebeccapurple;