Определение DevOps очень сложное, поэтому приходится каждый раз запускать дискуссию об этом заново. Только на Хабре тысяча публикаций на эту тему. Но если вы это читаете, то наверняка знаете, что такое DevOps. Потому что я — нет. Привет, меня зовут Александр Титов (@osminog), и мы просто поговорим о DevOps, и я поделюсь своим опытом.



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

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

Я руковожу Программным комитетом конференции FrontendConf и хочу рассказать как все работает изнутри, объяснить, что мы вложили в программу, почему выбрали те или иные доклады. Почему, при всем обилии информации в интернете, конференции — не просто тематическая тусовка, а реально полезное мероприятие. Рассказать, зачем, в конце концов, мы этим занимаемся, и кто это мы, потому что конференция — это, в первую очередь, люди.



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

В инвестировании есть понятие «Плохо сейчас — хорошо потом». Инвестор регулярно отщипывает 10, 20% или даже 30% своего заработка на будущее. Эти деньги он инвестирует в облигации, акции, ОФЗ, ETF — кто во что горазд. Сейчас, в моменте, инвестор отбирает у себя свой заработок, лишает себя каких-то благ, чтобы в будущем, на горизонте в 10-20 лет, получить пользу от инвестиций. Прибыль в будущем покроет сегодняшние лишения. Примерно такую же стратегию исповедует Алексей Охрименко (obenjiro), но применительно к разработке — лучше день потерять, а потом за 5 минут полететь.


Источник

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

О докладчике: Алексей Охрименко — разработчик в Avito Frontend Architecture, где немного улучшает жизнь миллионов людей. Ведет подкаст «5 min Angular», а в свободное ото сна и подкаста время организует Angular Meetup вместе с ребятами из Тинькофф, и выступает с огромным количеством разных и спорных докладов.

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

Прежде чем взяться за работу над user story, очень важно определить для себя критерии приемки. Это можно сделать, когда вы детализируете бэклог или планируете  ближайший спринт. Некоторые команды для этого проводят специальные встречи, которые называются 3 Амиго (подробнее о них в прошлой статье), митинги, kick-off по спецификации или встречи-исследования.

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

Но есть простой способ сделать такие встречи короткими и очень продуктивными. И называется этот способ Example Mapping или составление карт тест-кейсов.

В прошлом году PHP-FIG — Группа концепций совместимости PHP, выпустила несколько новых спецификаций. Последняя из них — PSR-14, посвящена диспетчеризации событий. Как и другие PSR, это локальная спецификация, но имеет большое влияние на многие аспекты стандартизации.

От переводчика: Это перевод первой части целой серии публикаций, в которой Larry (Crell) Garfield, один из членов PHP-FIG, объясняет, что такое PSR-14, на что способен, а на что нет, и как лучше всего использовать его в своих проектах.

Представим ситуацию — тестировщик находит баг, начинает обсуждать его с разработчиком — а тот настаивает, что это не баг, потому что в спецификации не было речи об этой функциональности. Знакомо?

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

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

Вы также наверняка знакомы со спорами на тему "баг это или фича". Клиенты обнаружили недоработки, и product owner приходит в команду с замечаниями. А тестировщик с разработчиком защищаются, объясняя это тем, что в изначальной постановке и речи не было о реализации этой фичи. И такие моменты потом заводятся в backlog.

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

Самыми горячими темами Moscow Python Conf++ оказались асинхронная разработка, а также сопоставление Python, его лучших практик и инструментария с аналогами из других языков, и его место в ландшафте современной разработки. Плюс мы пригласили выступить Бенджамина Петерсона, одного из разработчиков CPython, Григория Бакунова из Яндекса и многих других очень интересных людей.



Четвёртая по счёту и вторая, устраиваемая совместно с нашей командой, Moscow Python Conf++ заметно трансформировалась. Что происходило на мероприятии, чем оно выделялось среди отраслевых IT-форумов, какой профит и удовольствие принесло участникам — в нашей короткой фотозарисовке с площадки.

У нас было 2 анализатора кода, 4 инструмента для динамического тестирования, свои поделки и 250 скриптов. Не то, чтобы это всё было нужно в текущем процессе, но раз начал внедрять DevSecOps, то надо иди до конца.



Источник. Авторы персонажей: Джастин Ройланд и Дэн Хармон.

Что такое SecDevOps? А DevSecOps? В чем отличия? Application Security — о чём это? Почему классический подход больше не работает? На все эти вопросы знает ответ Юрий Шабалин из Swordfish Security. Юрий подробно на всё ответит и разберет проблемы перехода от классической модели Application Security к процессу DevSecOps: как правильно подойти к встраиванию процесса безопасной разработки в процесс DevOps и ничего не сломать при этом, как пройти основные этапы тестирования на безопасность, какие инструменты можно применять, чем они отличаются и как их правильно настроить, чтобы избежать подводных камней.

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

В этой статье вместе с экспертом по практической информационной безопасности Лукой Сафоновым LukaSafonov рассмотрим основные угрозы для современных офисных МФУ и пути их предотвращения.

Недавно я рассказала о докладах, которые сформировали программу конференции про управление знаниями в IT компаниях KnowledgeConf. Но не докладами едиными, все таки самое важное на конференции — это общение экспертов, дискуссии, столкновение мнений, на стыке которых возникает что-то новое, интересное и прорывное. Поэтому параллельно в программе у нас будет четыре двухчасовых интерактивных формата — два круглых стола и два мастер-класса.

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



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

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



Написав код, вы должны убедиться, что он:

1. Работает.
2. Ничего не ломает, в том числе код, который написали ваши коллеги.

Если оба условия выполняются, то вы на пути к успеху. Чтобы легко проверять эти условия и не сворачивать с выгодного пути, придумали Continuous Integration.

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

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

У нас новая важная тема — качественная разработка IT-продуктов. Мы часто говорим на HighLoad++, как сделать нагруженные сервисы быстрыми, а на Frontend Conf — классный пользовательский интерфейс, который не тормозит. У нас регулярно есть темы про тестирование, и DevOpsConf про объединение разных процессов, включая тестирование. А про то, что можно назвать качество в целом, и как над ним комплексно работать — нет.

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

Под катом поговорим с главой программного комитета, руководителем тестирования в Тинькофф.Бизнес, создателем русскоязычного QA-сообщества Анастасией Асеевой-Нгуен о состоянии отрасли QA и миссии новой конференции.

В рамках проекта АйтиХайп мы записали видеоинтервью с Андреем Станкевичем, легендарным тренером команды университета ИТМО по спортивному программированию, которая стабильно из года в год побеждает всех подряд на международных соревнованиях.

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

На следующей неделе стартует Saint HighLoad++ – вторая часть нашего эксперимента по экспансии хайлоада на крупные IT центры страны. Возвышенная приставка в начале названия, как и для других наших конференций, значит, что 8–9 апреля мы едем в Санкт-Петербург. В программе 40 докладов, традиционный трек от Aletheia Business и user generated митапы. Все доклады новые и специально подобраны, чтобы учесть социокультурный контекст IT северной столицы. В чем выражается региональная специфика и как она отразилась на программе, расскажу дальше.

Сначала давайте поделюсь, зачем мы вообще это затеяли. Нормально же было – большая ежегодная сходка всех заинтересованных в том, чтобы веб-сервисы качественно справлялись с нагрузкой и делали миллионы пользователей счастливыми. Когда мы начинали в 2007, таких всех было не очень много – как раз на небольшой хардкорный междусобойчик, но в 2018 году на HighLoad++ в Москве пришло 3 000 человек. Конференция стала не просто большая, а огромная: 10 основных потоков докладов, 10 потоков мастер-классов и митапов. В таком изобилии всевозможных альтернатив очень трудно ориентироваться.

Эксперимент по подготовке докладов на Moscow Python Conf ++ с нуля на финишной прямой. Слайды готовы, прогоны провели, осталось только дождаться премьеры — уже в эту пятницу 5 апреля. В расписании 24 доклада про использование Python в продакшене крупных компаний. Под катом — взгляд на организацию глазами программного комитета и смешные проблемы вроде «кого ставить в параллель хедлайнеру, чтобы не было пустых залов и обиженных спикеров».

Что может заставить такую большую компанию как Lamoda с отлаженным процессом и десятками взаимосвязанных сервисов существенно менять подход? Мотивация может быть совершенно разная: от законодательной до присущего всем программистам желания экспериментировать.

Но это вовсе не значит, что нельзя рассчитывать на дополнительную выгоду. В чем конкретно можно выиграть, если внедрить events-driven API на Kafka, расскажет Сергей Заика (fewald). Про набитые шишки и интересные открытия тоже обязательно будет — не может эксперимент без них обойтись.



Disclaimer: Это статья основана на материалах митапа, который Сергей провел в ноябре 2018 года на HighLoad++. Живой опыт Lamoda работы с Kafka привлек слушателей не меньше, чем на другие доклады из расписания. Нам кажется, это отличный пример того, что всегда можно и нужно находить единомышленников, а организаторы HighLoad++ и дальше будут стараться создавать располагающую к этому атмосферу.

Тема интернета вещей и раньше проскальзывала на конференциях РИТ++ и HighLoad++, но обычно с упором на привычные нам вопросы хранилищ данных или программирования. Но в прошлом году мы решили, что настало время серьезно обсуждать IoT: аппаратное обеспечение, сети передачи данных, промышленное применение, и провели первую конференцию InoThings++ 2018.

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

InoThings++ 2018 показал, что ожидания оправданы, мероприятие прошло на 5 баллов из 5. Как это было, посмотрите и почитайте в статье Олега Артамонова, главы программного комитета и участника всех событий. В этом году, уже 4 апреля, сделаем еще лучше. Наши спикеры — исключительно практики, а в программе только важные темы. Какие именно, читайте под катом.

На нашем рынке нет конференции, которая была бы посвящена PHP. А это все равно что футбольный клуб первой лиги без своего стадиона. Ведь в России PHP на втором месте по числу вакансий для программистов (позади 1C, но впереди Java). У него разветвленная экосистема и гигантская армия «последователей».

Погрустив, участники PHP-сообщества решили исправить ситуацию, для чего скооперировались с нашей командой. Общими стараниями 17 мая в московском «Инфопространстве» пройдет профессиональная конференция для PHP-разработчиков PHP Russia 2019. Перед мероприятием мы поговорили с руководителем программного комитета Александром Макаровым (SamDark) о том, зачем нужен ивент, что он призван изменить, кого на нем ждут с докладами и чем эти доклады будут полезны.