Однажды мой знакомый, который на тот момент администрировал некое веб-приложение на сервере под управлением GNU/Linux, пожаловался на одного вредного администратора сервера. Тот ни в какую не хотел устанавливать htop, несмотря на все просьбы.

Я немного удивился и поинтересовался, в чём причина такого странного поведения. Если упростить, то дальнейший наш диалог получился вот таким:

Немного теории о проектах и VFS. Предыдущая часть тут.

Структура проекта

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

Модули

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

«Скажи мне кто твой друг и я скажу, кто ты.»
Еврипид 480—406 до н. э.

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

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

У нас в компании есть уже довольно большой отдел Site Reliability Engineering (SRE), инженеров по доступности сервисов. Мы отвечаем за непрерывную и бесперебойную работу сервисов компании и решаем много других интересных и важных задач:

Некоторое время назад на Quora я отвечал на вопрос: как успевать записывать за лектором конспект по математике на LaTeX. Там я объяснил свой рабочий процесс по конспектированию в LaTeX с помощью Vim и Inkscape (для рисунков). Но с тех пор многое изменилось, так что я хочу опубликовать несколько постов в блоге с описанием нового процесса. Это первая из статей.

Я начал использовать LaTeX для конспектирования во втором семестре курса математики, и с тех пор написал более 1700 страниц. Вот несколько примеров, как выглядит конспект:

Автор: Денис Цыплаков, Solution Architect, DataArt

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

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

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

В сегодняшней части перевода серии материалов о Docker мы поговорим о работе с данными. В частности — о томах Docker. В этих материалах мы постоянно сравнивали программные механизмы Docker с разными съедобными аналогиями. Не будем отходить от этой традиции и здесь. Данные в Docker пусть будут специями. В мире существует множество видов специй, а в Docker — множество способов работы с данными.

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными

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

Потому в жизни встречается не очень часто. Я смог вспомнить только четыре примера, и не все они из моей личной практики, но эти истории я видел своими глазами. Разумеется, люди, о которых пойдет речь, никогда не читали «Хагакурэ» (кодекс самураев), но их истории, поведение, принципы и подходы лежат очень близко к философии древних японских воинов.



Для начала немного расскажу о самураях и их философии.

Есть в IT-отрасли задачи, которые на фоне успехов в big data, machine learning, blockchain и прочих модных течений выглядят совершенно непривлекательно, но на протяжении десятков лет не перестают быть актуальными для целой армии разработчиков. Речь пойдёт о старой как мир задаче формирования и выгрузки Excel-документов, с которой сталкивался каждый, кто когда-либо писал приложения для бизнеса.

В чём идея сортировок выбором?

1. В неотсортированном подмассиве ищется локальный максимум (минимум).
2. Найденный максимум (минимум) меняется местами с последним (первым) элементом в подмассиве.
3. Если в массиве остались неотсортированные подмассивы — смотри пункт 1.

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

Allure-framework успешно применяется в работе автоматизатора функционального тестирования в программе ЕФС и значительно упрощает разбор результатов тестовых прогонов.

В нашей первой статье мы расскажем, что такое Allure, для чего он нужен и как его подключить к вашему проекту. Также мы рассмотрим сборку самого отчета – как на локальной машине, так и с помощью Jenkins. И проведем обзор всех страниц отчета.
Поехали!

Привет, Хабр! Меня зовут Дмитрий Химион, я руковожу отделом обеспечения качества в Avito. Cегодня я хочу рассказать про автоматизацию тестирования в рамках работы с микросервисной архитектурой. Что мы можем предложить разработке для того, чтобы облегчить контроль качества? Читайте под катом.

Введение

Всем Buenos Dias! В своей статье я хотел бы максимально лаконично и просто рассказать о том, как построить процесс автоматизированного тестирования web-приложения с нуля. Первым делом нужно правильно расставить приоритеты и выбрать приемлемое соотношение цена/качество. Сразу определимся — это будет не решение «на коленках» из зоопарка скриптов, которыми часто пользуются при ручном тестировании. В тоже время мы не будем тратить много усилий на проектирование нашего «фреймворка» для автоматизации. Наша цель — предоставить результаты своей бурной деятельности перед руководством в максимально короткие сроки, при этом система должна быть:

• максимально простой, чтобы тесты могли писать даже специалисты по ручному тестированию
• гибкой и расширяемой, поскольку мы не можем адекватно оценить весь объем работ на данном этапе
• кроссплатформенной (Selenium WebDriver C# поддерживает Firefox, Chrome и IE)

В своем примере я буду успользовать .NET (Microsoft Unit Testing Framework) и Selenium WebDriver C#.