Всем привет!

В этой статье хочу поделиться одним из способов запуска тестов производительности JMeter в OpenShift'e с использованием Jenkins'a в качестве автоматизации. Сначала мы проделаем все необходимые действия (создание ImageStreams, BuildConfig, Job и проч) в ручном режиме. После этого напишим Jenkins Pipeline.

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



В ЦФТ эту проблему решили регулярные встречи с инженерами один на один. Встречи помогают: вовремя выявить проблемы в работе, профессионально развиваться, повышать мотивацию и находить новые смыслы. О том, как готовиться ко встречам, какие вопросы задавать и как регулярно их проводить, расскажет Михаил Емельянов. Теперь вы будете знать, что делать, если инженер сказал: «Нам нужно поговорить...»

Михаил Емельянов — Head of Android Department в ЦФТ. В IT-разработке 12 лет, с Android — 10, из которых 2 года руководит командой Android-разработки в ЦФТ. Разрабатывал проект мультимедиа, различные проекты в финтехе и запускал стартапы.

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

Эта лекция в рамках «Вечерней школы Слёрма по Кубернетес». Вы можете просмотреть открытые теоретические лекции Вечерней Школы на Youtube, сгруппированные в плейлист. Для тех же, кому удобнее текст, а не видео, мы подготовили эту статью.

Зовут меня Павел Селиванов, на текущий момент я являюсь ведущим DevOps инженером компании Mail.ru Cloud Solutions, мы делаем «облака», мы делаем мэнедж-кубернетисы и так далее. В мои задачи сейчас как раз-таки входит помощь в разработке, раскатывание эти облаков, раскатывание приложения, которые мы пишем и непосредственно разработка инструментария, который мы предоставляем для наших пользователей.

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

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

Недавно наше внимание привлёк один вопрос, заданный на stackexchange.com. Этот вопрос был направлен на то, чтобы разобраться с влиянием скрама на работу программистов. Автор вопроса, пользователь Qiulang, поднимает довольно смелую тему: «Скрам превращает хороших разработчиков в программистов средней руки. Возможно ли это?».

Основная идея фреймворка скрам заключается в организации процесса разработки для более быстрого выполнения работ на различных этапах жизненного цикла проекта. Но всегда ли такой подход подталкивает разработчиков к правильным моделям поведения? Многие пользователи, присоединившиеся к обсуждению вышеупомянутого вопроса на Stack Overflow, сталкивались с похожими вещами, когда разработчики «срезают углы», слишком большое значение придают высоким баллам, назначенным их тикетам, или даже прикидываются перед менеджерами высокопроизводительными сотрудниками. Как избежать этих опасностей?



Вопрос, о котором идёт речь, перешёл с workplace.stackexchange.com на softwareengineering.stackexchange.com. Это говорит о том, что программисты рассматривают соображения, связанные со скрамом и с его эффективностью, как нечто достаточно серьёзное, выходящее за рамки управления циклом разработки ПО. Они ощущают воздействие этого метода управления проектами на рабочую обстановку в целом.

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

Как обычно тестировщик ищет границы в поле? Если в ТЗ есть ограничения, то тестирует их. А если их нет? С нижней границей все понятно — это пустое поле. А как найти верхнюю? Вставляем большую строку и смотрим, сколько символов сохранится. И всё…

Но если у нас клиент-серверное приложение, то границы разработчик может поставить на каждом звене!



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

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

Содержание

• 1. Границы на клиенте
  
  • Maxlength
  • Ошибки в консоли JS
  • Изменение поведения
  • Итого по границе на клиенте
• 2. Границы на сервере
• 3. Границы в БД
• Итого: чек-лист поиска границ

Перевод статьи подготовлен в преддверии старта курса «Team Lead 2.0».

---

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

Привет, Хаброжители! На этой неделе у нас большие скидки. Подробности внутри.

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

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

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

Все мы любим Spring. Или не любим. Но по крайней мере знаем. Если вы Java-программист, то вероятно используете этот фреймворк каждый день в своей работе. Spring — это огромная платформа, которая предоставляет большой функционал. Тем не менее во главе угла стоят две вещи — это DI (Dependency Injection) и IoC (Inversion of Control). Концепции, которые были призваны, чтобы сделать наш код более читаемым и поддерживаемым. Но к несчастью, все оказалось не так радужно. Именно это мы сегодня и обсудим.

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

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

Переменные в Gitlab можно задать в нескольких местах:

1. В настройках групп
2. В настройках проекта
3. Внутри .gitlab-ci.yml

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

Начнем с простого наследования и будем постепенно усложняться.

С конечным списком уровней приоритетов можно ознакомиться в конце документа.

Привет, Товарищи!

Что будет, если в приложении Spring Boot выставить logging.level.root=TRACE?

Все логи будут записаны в один файл, в котором будет куча-мала из классов.

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


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

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

Цель этого текста – рассказать, что такое SP, как их использовать для оценки задач и почему эта методика получила такое широкое распространение.

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

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

Однажды мне случайно попался на глаза код, которым пользователь пытался мониторить производительность RAM в своей виртуальной машине. Код этот я приводить не буду (там «портянка») и оставлю только самое существенное. Итак, кот в студии!

Ярополк Раш из Wargaming рассказал, кого на самом деле ищут работодатели, чем продакт-менеджер отличается от продюсера и по какому фреймворку он работает.

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


Ярополк Раш на конференции ProductSense