Иван Пономарев IvanPonomarev

IvanPonomarev June 26, 2019 at 04:16 PM

Celesta 7.x: ORM, миграции и тестирование «в одном флаконе»

• Open source,
• Java,
• SQL

Возможно, вы что-то уже знаете про open source библиотеку Celesta. Если нет — не беда, сейчас всё расскажем. Прошёл ещё один год, вышла версия 7.x, много чего изменилось, и настала пора изменения подытожить, а заодно и напомнить о том, что такое Celesta вообще.

Читать дальше →

IvanPonomarev June 22, 2019 at 01:40 AM

Презентация как код, или Почему я больше не пользуюсь Powerpoint-ом

• Abnormal programming,
• Open source,
• Programming,
• DevOps

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

Читать дальше →

IvanPonomarev May 2, 2019 at 01:40 AM

Запускаем инспекции IntelliJ IDEA на Jenkins

• IT systems testing,
• Java,
• DevOps

• Tutorial

IvanPonomarev February 18, 2019 at 02:40 AM

Introduce Static Analysis in the Process, Don't Just Search for Bugs with It

• IT systems testing,
• Java,
• DevOps

This article is an authorized translation of the original post. The translation was made with the kind help of the guys from PVS-Studio. Thank you, guys!

What encouraged me to write this article is considerable quantity of materials on static analysis, which recently has been increasingly coming up. Firstly, this is a blog of PVS-Studio, which actively promotes itself on Habr posting reviews of errors, found by their tool in open source projects. PVS-Studio has recently implemented Java support, and, of course, developers from IntelliJ IDEA, whose built-in analyzer is probably the most advanced for Java today, could not stay away.

When reading these reviews, I get a feeling that we are talking about a magic elixir: click the button, and here it is — the list of defects right in front of your eyes. It seems that as analyzers get more advanced, more and more bugs will be found, and products, scanned by these robots, will become better and better without any effort on our part.

Well, but there are no magic elixirs. I would like to talk about what is usually not spoken in posts like «here are things that our robot can find»: what analyzers are not able to do, what's their real part and place in the process of software delivery, and how to implement the analysis properly.


Ratchet (source: Wikipedia).

Read more →

IvanPonomarev January 21, 2019 at 10:41 AM

Внедряйте статический анализ в процесс, а не ищите с его помощью баги

• IT systems testing,
• Java,
• DevOps

Написать эту статью меня сподвигло большое количество материалов о статическом анализе, всё чаще попадающихся на глаза. Во-первых, это блог PVS-studio, который активно продвигает себя на Хабре при помощи обзоров ошибок, найденных их инструментом в проектах с открытым кодом. Недавно PVS-studio реализовали поддержку Java, и, конечно, разработчики IntelliJ IDEA, чей встроенный анализатор является на сегодня, наверное, самым продвинутым для Java, не могли остаться в стороне.

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

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


Храповик (источник: википедия).

Читать дальше →

IvanPonomarev December 11, 2018 at 03:01 AM

Devops, JUnit5 и тестирование микросервисов: субъективный взгляд на московский “Гейзенбаг”

• IT systems testing,
• Java,
• Conferences

6-7 декабря в Москве состоялась пятая по счёту конференция «Гейзенбаг».
Её слоган — «Тестирование. Не только для тестировщиков!», и за два года регулярного посещения «Гейзенбагов» мне (прежде Java-разработчику, ныне — техническому лиду в маленькой компании, никогда не работавшему в QA) удалось многому научиться в области тестирования и многое внедрить в нашей команде. Я хочу поделиться субъективным обзором запомнившихся мне на этот раз докладов.

Читать дальше →

IvanPonomarev September 3, 2018 at 01:19 AM

Выгружаем данные в Excel. Цивилизованно

• Open source,
• Programming,
• Java,
• ERP-systems

• Tutorial

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

При чём тут ксилофон?!

IvanPonomarev March 25, 2018 at 04:28 PM

Тестирование и непрерывная интеграция для Ansible-ролей при помощи Molecule и Jenkins

• IT systems testing,
• Server Administration,
• DevOps

• Tutorial

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

Вместе с большим количеством кода появляется и старая, знакомая проблема: страх изменений. Люди не желают вносить изменения в «чужую» роль, опасаясь испортить её, вместо этого создают собственную копию. Рефакторинг кода не производится, если код прямо сейчас не находится в фокусе разработки, из-за опасения, что внесённые проблемы могут быть обнаружены спустя слишком большое время. Итог: плохой код растёт как снежный ком.

Читать дальше →

IvanPonomarev December 10, 2017 at 10:49 PM

Пять идей «на вооружение», или Впечатления от московского «Гейзенбага»

• IT systems testing,
• Java,
• Conferences

Как убедиться, что на конференции, на которую ты берёшь билет, не будет «лажи»? На мой взгляд, лучший способ — стать спикером одной из конференций того же организатора и на себе протестировать процесс отбора и подготовки докладов. Весной я был спикером на конференции, проводимой компанией JUG.ru Group, а всё происходившее перед этим напоминало защиту учёной степени. Несколько раз мой доклад прослушивал программный комитет, после каждого из прогонов я получал длинный список вопросов и замечаний. Один из членов комитета стал «оппонентом» и в бесконечных дискуссиях в Slack-е требовал дополнительных экспериментов, чтобы получить безусловные доказательства эффективности того, о чём я собирался рассказать в докладе. Когда пришла новость, что доклад одобрен — это был ещё не финал: мне было предложено вместе с другими докладчиками пройти двухдневные курсы ораторского мастерства. Пройдя через это испытание, я знаю: ребята из JUG.ru Group не допустят на своих конференциях ни капли «лажи». И я доверяю им: в этом году я посетил большинство их конференций.

Читать дальше →

IvanPonomarev September 13, 2017 at 01:15 PM

Миграция схемы данных без головной боли: идемпотентность и конвергентность для DDL-скриптов

• Programming,
• System Analysis and Design,
• SQL

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

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

Читать дальше →

IvanPonomarev September 4, 2017 at 10:21 AM

Celesta и Flute: Создание бизнес-логики в Java-экосистеме

• Open source,
• Programming,
• Java,
• SQL

Привет, Хабр! Проект, о котором мы расскажем, с самого начала создавался нами как open-source, но до недавних пор мы использовали его только лишь для своих нужд, не говорили о нём широко и не создавали коммьюнити. Cейчас, спустя несколько лет разработки, мы почувствовали уверенность в том, что настала пора рассказать про него, и надеемся, что он начнёт приносить пользу не только нам.

Читать дальше →

IvanPonomarev July 7, 2017 at 06:27 PM

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

• System Analysis and Design

В проекте, над которым я сейчас работаю, применяется распределённая система обработки данных: сначала несколько десятков машин одновременно производят некоторые сообщения, затем эти сообщения отправляются в очередь, из очереди три потока извлекают сообщения и после финальной обработки выкладывают данные в базу Redis. При этом имеется требование: от «зарождения» события в машине, производящей сообщение, до выкладывания обработанных данных в базу должно проходить не более четырёх секунд в 90% случаев.

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

Читать дальше →

IvanPonomarev September 9, 2016 at 11:11 AM

Сферическое тестирование в вакууме: Как есть, как должно быть, как будет

• JUG Ru Group corporate blog,
• IT systems testing,
• Programming,
• Java

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



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

Николай — специалист в области разработки на Java уже с 12-летним стажем. Помимо основной рабочей деятельности, он — сооснователь и тренер тренингового центра XP Injection, активный участник и докладчик на международных конференциях. При его участии были организованы IT-конференции Selenium Camp, JEEConf, XP Days Ukraine и IT Brunch. Мы поговорили как о том, что можно улучшить в области тестирования в своей команде «здесь и сейчас», так и о том, к каким технологическим переменам нам следует готовиться в будущем.

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

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

Читать дальше →

IvanPonomarev August 11, 2016 at 04:33 PM

Java DevTools: модно не значит хорошо

• JUG Ru Group corporate blog,
• Programming,
• Java

Сегодня с нами Антон Архипов aka antonarhipov — разработчик и менеджер продукта JRebel в компании ZeroTurnaround, — и говорим мы о правильных средствах разработки и их неправильном использовании. Антон профессионально занимается разработкой на Java более десяти лет. Основные интересы связаны с языками программирования и инструментарными средствами разработки ПО. Очень любит vim и IntelliJ IDEA. Часто выступает на международных конференциях — за спиной выступления на таких конференциях как JAX, JavaOne, Joker, JPoint, GeeCON, Jfokus, JavaZone, EclipseCon.

— Антон, чем вы занимаетесь в области Java-разработки?

— Последние шесть лет я работаю в компании ZeroTurnaround, и по долгу службы занимаюсь любимым делом – разработкой инструментов для Java-разработчиков. Наш известный продукт – JRebel для Java-разработчиков, и наш второй крупный продукт – это XRebel, тоже для Java-разработчиков, но больше для тех, кто занимается веб-разработкой. Я занимался первые три года JRebel, и последние три года участвую в создании XRebel.

Читать дальше →

IvanPonomarev June 27, 2016 at 09:44 AM

Реализация интерактивных диаграмм с помощью ООП на примере прототипа редактора UML-диаграмм. Часть 2

• Programming,
• Java,
• System Analysis and Design,
• Designing and refactoring,
• ООP

IvanPonomarev June 22, 2016 at 09:06 AM

Реализация интерактивных диаграмм с помощью ООП на примере прототипа редактора UML-диаграмм. Часть 1

• Programming,
• Java,
• System Analysis and Design,
• Designing and refactoring,
• ООP

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

В этой статье мы подробно разберём создание «с нуля» компоненты с интерактивными, «перетаскиваемыми» элементами в объектно-ориентированной среде разработки. В качестве примера мы построим прототип UML-редактора.

Читать дальше →

IvanPonomarev May 29, 2016 at 08:32 AM

Электронный «излучатель информации» при минимуме затрат

• Development Management,
• Agile

Когда у нас надёжно заработала непрерывная интеграция на Jenkins и устоялись процессы выпуска релизов продукта, возникла мысль: а почему бы не перенять передовой опыт и не поставить в офисе свой электронный излучатель информации (information radiator): большой красивый экран, на котором автоматически отображаются происходящие с проектом процессы?



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

Читать дальше →

IvanPonomarev April 26, 2016 at 09:14 AM

«А как всё хорошо начиналось...», или О пользе O-нотации не только для анализа алгоритмов

• System Analysis and Design,
• Designing and refactoring

Термин «О-большое», знакомый нам из курса матанализа, был введён Паулем Бахманом в конце XIX века для описания асимптотического поведения функций. В конце 1970-х Дональд Кнут придумал применять этот термин для оценки эффективности и ресурсоёмкости алгоритмов, благодаря чему с «О-большим» знакомо большинство программистов. Понимание асимптотики быстродействия и ресурсоёмкости даёт возможность выбрать наиболее подходящий метод решения задачи в зависимости от текущих потребностей. «Плохая» асимптотика позволяет сразу же отбросить неподходящий метод.



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

Читать дальше →

IvanPonomarev March 21, 2016 at 10:05 AM

Реализация грида для работы с большими таблицами. Часть 2

• Programming,
• System Analysis and Design,
• Designing and refactoring,
• Algorithms

В предыдущей части статьи был разобран общий принцип работы системы: мы увидели, что двумя основными её блоками являются интерполятор и нумератор. Мы построили схему взаимодействия, а также полностью обсудили реализацию интерполятора. В этой части мы разберём реализацию нумератора: обратимой функции, переводящей набор значений ключевых полей в натуральное число (BigInteger) таким образом, что набор меньше набора с точки зрения СУБД тогда и только тогда, когда . Говоря проще — научимся интерполировать наборы значений и, что самое интересное, строки:

Читать дальше →

IvanPonomarev March 14, 2016 at 09:24 AM

Реализация грида для работы с большими таблицами. Часть 1

• Programming,
• System Analysis and Design,
• Designing and refactoring,
• Algorithms

Таблица (грид) с вертикальной полосой прокрутки — наиболее распространённый элемент пользовательского интерфейса для работы с данными реляционной БД. Однако известны сложности, с которыми приходится сталкиваться, когда таблица содержит так много записей, что тактика их полной вычитки и сохранения в оперативной памяти становится неразумной.

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

Мы расскажем об одном из возможных методов реализации табличного элемента управления, обладающего свойствами Log(N)-быстрого 1) первоначального отображения 2) прокрутки на всём диапазоне записей 3) перехода к записи с заданным уникальным ключом. Всё это — при двух ограничениях: 1) записи могут быть отсортированы только по индексированному набору полей и 2) collation-правила базы данных должны быть известны алгоритму.

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

Читать дальше →