Всем привет! Меня зовут Сергей, и в Яндексе я работаю в команде автоматизации тестирования сервисов монетизации. Перед каждой командой, которая занимается задачами автоматизации тестирования, встает вопрос: «Какой [фреймворк|инструмент] выбрать для написания своих тестов?» В этом посте я хочу помочь вам на него ответить. Если быть конкретнее, речь пойдет об инструментах тестирования на языке Python, но многие из идей и выводов можно распространить на другие языки программирования, поскольку подходы часто не зависят от конкретной технологии.



В Python существует множество инструментов для написания тестов и выбор между ними неочевиден. Я опишу интересные варианты использования PyTest и расскажу о его [плюсах|минусах|неявных возможностях]. В статье вы найдёте развёрнутый пример использования Allure, который служит для создания простых и понятных отчётов автотестов. Также в примерах будет применяться фреймворк для написания матчеров — Hamcrest для Python. Надеюсь, что в итоге, те, кто сейчас в поиске инструментов для тестирования, смогут на основе изложенных примеров быстро внедрить функциональное тестирование в своем окружении. Те же, кто уже использует какой-то инструмент, смогут узнать новые подходы, варианты использования и концепции.

Олег Бартунов (zen), Александр Коротков (smagen), Федор Сигаев

Илья Космодемьянский: Сейчас будет самая животрепещущая тема по PostgreSQL. Все годы, что мы занимаемся консалтингом, первое, что спрашивают люди: «Как сделать мультимастер-репликацию, как добиться волшебства?». Много профессиональных волшебников будут рассказывать о том, как это сейчас хорошо и здорово реализовано в PostgreSQL — ребята из Postgres Professional в рамках этого доклада расскажут про кластер все. Название соответствующее — «Сага» — что-то эпическое и монументальное. Сейчас ребята из Postgres Professional начнут свою сагу, и это будет интересно и хорошо.

Итак, Олег Бартунов, Александр Коротков и Федор Сигаев.

Мы не любим ждать в очереди, хотим сделать заказ онлайн, мы не готовы покупать билет в кассе, пусть все будет в приложении, в электронном виде. И вот тут есть важное «Но»! Мы всё хотим здесь и сейчас, но чтобы это работало без сбоев, как часы. Доставку пиццы осуществили вовремя, место в кинотеатре совпало с полученным в подтверждении. Что во всем этом многообразии приложений и сервисов играет одну из ключевых ролей?

Конечно — это тестовое окружение, без чего невозможен быстрый выпуск качественного продукта! Современные инструменты тестирования ворвались в нашу жизнь как ураган и буквально за несколько лет изменили наши возможности. Мы семимильными шагами освоили виртуализацию и контейнеризацию, попробовали линейку Selenium-а, спорили о преимуществах и недостатках Docker-а.

Зачем все это было нужно и к чему мы пришли?
Какое будущее нас ждет?

Поговорим «за тестирование» с гуру профессии. Пройдёмся от А до Я по инструментарию. Помогут нам в этом Игорь Хрол и Антон Семенченко.

Запасаемся кофе, чаем, другими напитками и начинаем. Беседа будет долгой.

Итак, Игорь Хрол — специалист по автоматизации тестирования в Toptal. Игорь имеет большой опыт работы с большинством популярных инструментов (Selenium, HP QTP, TestComplete, JMeter).

Чуть больше месяца назад закончились Олимпийские игры в Бразилии, на которых Cisco уже традиционно отвечала за сетевую и серверную инфраструктуру, включая и их безопасность. И сегодня уже можно поделиться нашим опытом обеспечения сетевой безопасности летних Олимпийских игр в Рио, тем более, что мы уже можем сравнивать происходящее с играми в Лондоне в 2012-м году, где Cisco также обеспечивала сетевую безопасность всех спортивных сооружений и мероприятий.

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

Подобные средства есть для всех распространенных настольных ОС, включая Linux и BSD, и многие из них совершенно бесплатны, так что вряд ли имеет смысл ограничивать себя в Блокнотом Windows, nano или cat.

Однако, в среде поклонников Unix гуляет в разнообразных вариациях мем о том, что «Unix — это IDE», в том смысле, что средства, которыми разработчики располагают в терминале, легко реализуют основные возможности современных IDE. Вы можете соглашаться или отказываться признать Unix «IDE» в том самом смысле, что Eclipse или Microsoft Visual Studio. Так или иначе, вас скорее всего удивит, насколько законченную среду разработки может являть собой скромный Bash.

(http://bp-la.ru/bespilotnyj-apparat-danem)

Билд => Тест => Не пройден => и километры логов, разбросанных по разным системам, и десятки минут сведения концов с концами в поисках причины сбоя. Знакомо?

А если иначе?

Билд => Тест => Не пройден => Тикет в JIRA — и разработчик берет баг в работу, потому как вся информация у него уже есть.

Работая в команде Acronis Kernel, я задался целью создать именно такой автотест.
Под катом — моя история.

Люди: — Эй, Тойота, мы тут посчитали, у вас из-за корявой электроники и софта 89 человек погибло с 2000 по 2010.
Тойота: — Да они сами виноваты, путают педали.
Люди: — Хьюстон, у нас проблемы.
NASA: — Ща разберемся, нам надо 10 месяцев и 3 миллиона долларов.
Люди: — На.
Тойота: — 3 миллиона мало, вот вам еще сверху кэшем.
(прошло 10 месяцев)
NASA: — Эй, Тойота, мы у вас пару ошибок в коде нашли, а точнее 7134 нарушения стандартов MISRA, рекурсию, функцию на 740 строк и 9000 глобальных переменных.
Тойота: — А у нас свои стандарты. А вы ваще на Луну летали?
NASA (публично): — Тойота ни в чем не виновата.
(Акции Тойота подскочили на 4,6%)
Люди: — Ну ё-моё.
(спустя 3 года)
Два американских тестировщика (у которых дедушки погибли в Перл-Харбор): — Нет багов? А если найдем?

Один из наших клиентов, эксплуатирующий PostgreSQL под большой нагрузкой, столкнулся с проблемой, связанной с переполнением счетчика транзакций (xid wraparound), причем выхода из нее штатными средствами не существовало. Мы решили проблему с помощью хирургического вмешательства и выпустили патч, предотвращающий возникновение таких ситуаций в будущем.

В этой заметке мы расскажем, как и почему может произойти проблема и как ее не допустить.

От переводчика:

Некоторое время назад на Хабре публиковался перевод статьи под названием "Искусство командной строки". Среди прочего, в статье было рекомендовано освоить vim. Исходник статьи, выложенный на Гитхаб, по иронии судьбы, оказался совершенно непригодным к редактированию именно этим редактором, так как в нём на один абзац приходилась ровно одна строка.

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

Хочу предупредить, что не все ссылки в статье работоспособны, но я решил оставить их как есть — мало ли что.

О пользе внедрения DevOps уже написано немало статей на Хабре и других IT-ресурсах, и она не ставится под сомнение. Это понятно: творческому беспорядку с подчас неочевидными зонами ответственности «обычной» разработки, где разные люди отвечают за код, бранчи, тестовые стенды, сборку и деплой и не очень-то хотят лезть на «поляну» коллег, противопоставляется высокий уровень организации.

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



Но мало просто захотеть работать «правильно», нужно еще каким-то образом к этому прийти. А здесь все совсем не так просто.

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

Надо “SELECT * WHERE a=b FROM c” или “SELECT WHERE a=b FROM c ON *” ?

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

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

SELECT members.firstname || ' ' || members.lastname
AS "Full Name"
FROM borrowings
INNER JOIN members
ON members.memberid=borrowings.memberid
INNER JOIN books
ON books.bookid=borrowings.bookid
WHERE borrowings.bookid IN (SELECT bookid
  FROM books
  WHERE stock>(SELECT avg(stock)
    FROM books))
GROUP BY members.firstname, members.lastname;

Буэ! Такое спугнет любого новичка, или даже разработчика среднего уровня, если он видит SQL впервые. Но не все так плохо.

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

В этой статье я хотел бы рассказать о том, как выглядит процесс разработки PostgreSQL глазами одного из контрибьютеров в этот самый PostgreSQL. Заниматься разработкой этой СУБД я начал в декабре 2015 года, когда устроился работать в компанию Postgres Professional. То есть, не так уж давно. А значит, еще свежи воспоминания о моментах, которые поначалу казались мне не вполне очевидными. Хотелось бы их законспектировать, чтобы новым людям, приходящим в нашу команду, а также всем тем, кто желает попробовать себя в роли разработчика открытой реляционной СУБД, было легче. Я расскажу о том, как выглядит процесс разработки PostgreSQL, какие инструменты я использую в своей повседневной работе, как следует оформлять патчи, и так далее. Заинтересовавшихся прошу проследовать под кат.

Приветствую сообщество! Давным давно, в 2013 году на Хабре был опубликован пост «Reverse engineering на собеседовании: как мы нанимаем на работу». В нём был предложен тестовый crackme для претендентов на позицию вирусного аналитика. Убедившись, что полного разбора тестового файла в интернете нет, я решил написать свой разбор. Итак, приступим. Crackme 64-разрядный. Запустим его в IDA Pro.

Привет. Меня зовут Алексей Маланов, я пять лет проработал руководителем Отдела антивирусных исследований в «Лаборатории Касперского». Хочу поделиться с вами своим опытом найма вирусных аналитиков. Пост, надеюсь, будет интересен и полезен в первую очередь молодым специалистам, которые только собираются сделать первый шаг в карьере. Ну а матерым IT-шникам тоже может быть любопытно, какие же вопросы задают на собеседовании в ЛК. В свое время у меня в команде было несколько десятков человек и нанимали мы постоянно. Я стремился присутствовать на каждом собеседовании лично, чтобы быть уверенным, что человек будет что надо.

(Решил перевести популярную статью Serge Wroclawski об ОСМ. Хоть она и вышла в январе, перевода на Хабре я не видел.)

Каждый раз, когда я рассказываю кому-нибудь об OpenStreetMap, меня неизменно спрашивают «Почему бы не использовать Google Maps?» С практической точки зрения это вполне уместный вопрос, но на самом деле это не просто вопрос практичности, а вопрос того, в каком обществе мы хотим жить. Я обсуждал эту тему в 2008 году в моём докладе об OpenStreetMap, который я представил на первой встрече MappingDC. Здесь я хочу изложить те же мысли в расширенном варианте.

После почти года планирования, разработки и тестирования, представители сообщества OSM в компании Telenav представили свободную и открытую платформу OpenStreetView для съёмки и публикации окружающих видов со смартфона. Это замечательная новость для всего сообщества OSM: на свободных картах теперь появятся фотографии окружающей местности, привязанные к картам. Сделано не так красиво, как на проприетарных картах от Google, но это вполне естественно: корпорация Google ежегодно тратит около 1 миллиарда долларов, поддерживая свои карты в актуальном состоянии, чтобы стать эталонным источником карт для всего мира.

Vulners задумывался как поисковик для Security Content-а: уязвимостей, бюллетеней безопасности, эксплоитов, плагинов детекта и прочей полезной информации. Но мы подумали: если у нас уже есть разобранные бюллетени безопасности для основных Linux-дистрибутивов, почему бы нам не сделать сервис, который будет брать данные о системе, а на выходе отдавать список уязвимостей. Также, как это делают привычные сканеры уязвимостей, только быстрее и бесплатно.


Откуда мы получаем информацию об уязвимостях Linux? Для этого мы парсим бюллетени вендоров. Покажем процедуру разбора на примере бюллетеня безопасности Debian DSA-3638.

Прочитав множество постов о нынешнем «выгорании» программистов, я начал думать, как же я сумел сохранить интерес к этой профессии даже после столь долгой карьеры — с 1981 года (!). Почему интерес к коду у меня ещё не угас?

Конечно, я частично объяснил это в моём посте «Да, я в мои 56 всё ещё хочу делать это», получившем известность почти три года назад. Но тот пост был о стороне жизни профессионального программиста, связанной с самим процессом программирования; здесь же речь пойдёт не о самом написании кода, а о том, как я всё ещё выдерживаю «программистское бытие». Что же это за работа, которая захватывает так, что утром ждёшь не дождёшься открыть текстовый редактор или IDE или же испытываешь благоговейный ужас от мысли отправить свой зад в офис?

Оглядываясь назад на мои места работы — те, которые мне нравились, те, которые я ненавидел, и те, с которыми просто было можно жить, — я думаю, в чём же различие между ними? Что я делал такого, что позволило мне так долго идти по этому пути?

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



Конечно, это был не совсем я, но близко. Дело в том, что давным-давно мне предложили помочь Вымпелкому с блогом. На немного необычных условиях. Первым стало отсутствие всякой официальщины – отсюда и совершенно отрывные посты (за часть из которых в корпоративном сегменте смело оторвали бы руки и не только), и самые актуальные темы (Базовая станция вредная? Ещё как!), и вообще много всего.

Но начну с самого начала. Итак, Хабр тогда был торт — большой и зверски агрессивный, хабов не было, а корпоративные блоги были чем-то вроде раздела «тупиковый отстой». За любую ссылку или рекламу тогда почти банили. Или забивали до -50 за час, например. С корпоративным рылом в такой калашный ряд было никак нельзя.

И ещё – Билайн, как и любой сотовый оператор, имел тысячи людей, не очень довольных его существованием. Поэтому первый пункт стратегии был довольно необычным, и мало кто мог позволить себе его повторить. Всё просто: пишут исключительно технари, а маркетинг на пушечный выстрел не подходит к постам.

Технари, кстати, оказались совершенно офигенные. Только плевать они хотели на Хабр, по большому счёту. Как и везде.