Давно прошли те времена, когда можно было получать доступ и хранить информацию о пользователях на своих сайтах без каких-либо ограничений и ответственности. В наши дни мало кто рискнет быть оштрафованным на внушительную сумму, нарушая правила доступа к персональным данным, введенные Европейским Союзом и известные как General Data Protection Regulation (GDPR).

В этой статье мы не будем рассматривать все аспекты того, как сделать ваш сайт удовлетворяющим требованиям GDPR, а рассмотрим только одну конкретную тему — как сделать предупреждение о cookie файлах на вашем сайте в соответствии с этими требованиями. Учитывая объем данных, которые могут содержать cookie файлы, при определенных обстоятельствах они могут считаться персональными данными и, следовательно, подпадать под действие GDPR.

GDPR вступил в силу уже четыре года назад, однако его понимание и практика применения до сих пор развиваются. Как показывают последние новости, далеко не все преуспели в борьбе за соответствие – в январе Google и Facebook получили серьёзные штрафы (на €150 млн и €60 млн соответственно) за нарушения законодательства в отношении cookies, причём для Google это уже второй штраф за них (предыдущий был на €100 млн). Именно тема cookies постепенно становится "горячей": ей занялись не только регуляторы, но и активисты. Правила, действующие в отношении cookies, основываются частью на GDPR, частью – на ePrivacy Directive. В этой статье собрано текущее понимание этих правил для практического применения.

Изменив одно местоимение, можно на 90% увеличить показатель кликабельности (CTR) кнопки, которая приведет новых пользователей. Дописав одно предложение, можно увеличить количество оплаченных покупок и снизить нагрузку на саппорт. Поставив одну запятую, можно было бы сохранить 5 миллионов долларов. ОК, третий пример про договоры, но все равно показателен.

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

Исследование Nielsen Norman Group показало, что лаконичный, объективный (без маркетологического хвастовства) текст, который легко читается пользователем, увеличивает юзабилити сайта на 124%. Только текст. UX и навигацию не трогали.

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

Впервые я задумался об этаком “soft skills starter pack” около года назад. Гугление дало списки из 10-15-20 навыков без пояснений, как их внедрять, и почему список именно такой. Апофеозом для меня стала книга “12 soft skills для 21 века”, которая является кратким изложением 12 других книг. 

С трудом верится, что все эти навыки нужны разом. Если на собеседовании я буду проверять кандидата на 15 навыков, я вообще кого-то найму? За сколько лет я разовью их сам? Эмоциональный интеллект – пару лет? Системное мышление – еще пару лет? Окей, хотя бы со скольки навыков я могу считать себя пригодным к работе в команде? А к роли лидера? В общем, "программу-минимум" я тогда не нашел.

Но как тимлид я слышу множество карьерных историй: на собеседованиях, на 1-to-1 с коллегами, просто консультируя пришедшего с вопросом – везде я узнаю истории успехов и ошибок. А в обмен я стараюсь дать структурированную и понятную обратную связь. Постепенно из этих историй и обратных связей сложился набор минимально необходимых soft skills. Они будут полезны хоть инженеру, хоть лидеру. Вообще говоря, они будут полезны не только IT-специалисту и не только в карьере.

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

В данном посте мне хотелось бы поделиться списком книг, которые (по крайне субъективному мнению) являются полезными и весьма практичными для Engineering Manager’а. При этом акцент хочу сделать именно на современных книгах (выпущенных в последние 5-6 лет). Под Engineering Manager’ом, в моем вольном определении, будем понимать бывшего инженера, ставшего руководителем, решающего как технические (например, внедряем RabbitMQ или Kafka), так и административные вопросы (например, план обучения новичков, сколько еще нанять разработчиков и каких и т.п.). Под такое понятие могут подпадать Tech Lead, Team Lead, Project Manager.

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

На прошедшей в апреле конференции TeamLead Conf 2021 я поделился своим опытом, как вытащить проект из пожара и обойтись без человеческих жертв. Под катом моя история, а если предпочитаете смотреть — вот запись выступления.

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

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

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

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

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

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

Иногда добиться значительного эффекта можно используя совсем незамысловатые средства. Стоит лишь взглянуть на текущее положение дел под другим углом или свежим взглядом.

Я расскажу, как мы в Plesk сократили расходы на AWS-инфраструктуру одного из наших сервисов без применения уличной магии.

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

Эта статья написана по следам онлайн-курса Translation Quality Management от ТГУ и агентства Palex, который я недавно прошла по совету коллеги. Этот курс посвящен обеспечению качества переводов и предназначен как для менеджеров, организующих процесс перевода, так и для переводчиков и редакторов. Поскольку я переводчик и редактор в одном лице, некоторые идеи из этого курса показались мне полезными, и я хотела бы ими поделиться, а также рассказать, как они могут помочь сделать проверку (и самопроверку) переводов эффективнее. Статья может быть полезна тем, кто переводит и проверяет тексты, в частности, в IT.

Несколько лет назад я услышал от одного коллеги историю. Он в то время работал начальником отдела технической документации в IT компании. Дело было на собрании, посвященном знакомству с новым техническим директором. Тот, пожав моему коллеге руку и узнав о его роли, пошутил: “Документация? Так ее же не читает никто! Двадцать первый век на дворе”.

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

Я тимлид вот уже десять лет. И год назад я получил предложение о работе, которое звучало как очень интересный вызов. Но вместе с тем меня терзали сомнения, поскольку был разгар пандемии и я понятия не имел, как стать лидером для новой команды в условиях удаленки. Не добавляли уверенности в успехе новый для меня стек и длинная, 20-летняя история проекта.

Но факторы в пользу успеха тоже были. Во-первых, предыдущий тимлид остается, вернувшись в роль разработчика. Во-вторых, по отзывам, в компании отлаженные и очень “человечные” процессы.

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

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

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

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

Я Community Manager и у меня есть зависимость. Ну хорошо, не зависимость, но хобби: я увлекаюсь автоматизации собственной квартиры с помощью того, что модно теперь называть Умным Домом. Начинал пару-тройку лет назад с чистого Apple HomeKit, затем расширил его возможности с Homebridge и далее, вот уже года два, полностью погружен в дебри HomeAssistant.

Но поскольку я Community Mananger, мне интересна та часть моего хобби, которая касается коммуникаций сообщества людей, имеющих такое же увлечение, как и моё.

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

Не секрет, что чем больше проект, тем с большим количеством проблем он сталкивается даже в самых элементарных аспектах.  В продукте Plesk, над которым я работаю, PHP является одним из основных языков, и количество кода на нем превышает 1 миллион строк. Соответственно, мы активно используем PHPUnit для тестирования. Кроме большого объема кода, поддержка двух платформ (Linux и Windows) доставляет нюансы, как и тот факт, что поддерживается несколько бранчей с приличной разницей возраста (крупные релизы), а активно вносят правки несколько десятков инженеров. В статье я хочу поделиться некоторыми практиками, которые мы используем при работе с PHPUnit.

На волне последних обсуждений темы собеседований, хочу задать аудитории Хабра вопрос: вы помните, как писали в резюме: "коммуникабельный, инициативный, быстро обучаюсь"? 

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

Итак, меня зовут Алексей, я QA Lead одной из команд в Plesk. Хочу поговорить о том, как увеличить пользу от технического собеседования, или что означают софт скиллы, и как они проявляют себя в реальной жизни. 

Добро пожаловать под кат.

Привет, Хабр. Меня зовут Ольга, я работаю в тестировании с 2013 года, специализируюсь на тест-анализе и тест-дизайне. Сегодня хочу рассказать, как при планировании тестирования сохранить фокус на пользователях и их потребностях.

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

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

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

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

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

Вы, возможно, скажете “ШТА?! Я точно на Хабре? Причём тут какой-то фильм о музыкальных сантехниках?”

Да, это Хабр, и это рассказ про музыкальную группу, состоящую из сотрудников одной продуктовой IT-компании.

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

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