Полезные:

• https://httpbin.org/ — универсальная штука для отладки HTTP-клиента. Самый частый кейс у меня был curl https://httpbin.org/ip, но подойдет для кейсов, когда надо выяснить, что ваш клиент сует в данные кроме того, что сказали (например, какой user-agent).
• https://restcountries.eu/ — выводит основные данные о стране: curl -s https://restcountries.eu/rest/v2/name/russia.

И среднего уровня бесполезности:

• Погода: curl -s http://wttr.in
• Зойдберг: curl zoidberg.live
• Fuck off as a service, местами может заменить httpbin: curl 'https://www.foaas.com/zero' -H'Accept: application/json'
• Ну и классика — Звездные Войны, можно сделать аналог самостоятельно: curl https://asciitv.fr

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

К сожалению, не всегда все так радужно, и в ООП-шном коде с кучей DI, IoC и прочими SOLIDами для простого юнит-теста придется пол-графа зависимостей поднимать. Вот и получаются моки, которые по сути работают как перехватчики входов-выходов для нужного метода. А нормальные интеграционные тесты делать дорого и они существенно замедляют билд.

Добавьте сюда еще микросервисы и получится, что надо имитировать и проверять HTTP-вызовы. Появляется специальный web-сервер, вся задача которого — отдавать заранее заготовленный ответ на нужный вызов и записывать все обращения. В качестве примера можно привести WireMock. Хотя если такая штука нужна на 1 раз, то, имхо, гораздо проще взять первый попавшийся скрипт на питоне, поднимающий локальный HTTP, и вкорячить туда нужное, чем возиться с настройкой чего-то посложнее.

Годная статья про пагинацию в SQL, где рассказано про варианты ее реализации. С алгоритмической сложностью!

https://habr.com/ru/post/517900/

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

Припудрю это своим нытьем про java.

Когда делал пулл-реквесты в опенсорсную библиотеку, пришлось писать на java7. В комбинации с местами не очень продуманным кодом это вызвало у меня страдания. Тонны копипасты. Куча бойлерплейта по перекладыванию из одного слоя абстракции в другой. Куча приватных методов, в которых закопано все нужное. Фабрики. Мне действительно пришлось делать фабрику (с интерфейсом для фабрики, с изменением класса для прокидывания фабрики и изменением билдера для класса), потому что по-другому в существующую реализацию и не вкорячишься.

Работа с коллекциями это вообще ад. Мало того, что все надо делать тупыми циклами, так еще и нет элементарных методов типа getOrDefault.

Конечно, если ОЧЕНЬ НАДО, то что-то написать можно. Но плакать и колоться так каждый день лично я не готов даже за большие деньги…

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

Работает это довольно просто — глобально настраивается почтовый сервер, а дальше отдаешь команду вроде

echo "hello" | sendmail general@kenobi.sw

И все, письмо ушло адресату. Звучит весьма клево, но внимательный читатель должен был триггернуться на “глобально”.

Недавно выяснилось, что сервер, где такое настроено, выжирает дневной лимит писем в 50к за сутки, хотя предполагаемая нагрузка — 10 писем в день. Виртуалка выключена админами, и в голове мечутся мысли: взломали? Но кому такое надо? Может, ПО, использующее sendmail, сошло с ума?

Однако после разбирательств выяснилось, что столько писем слал… cron. По умолчанию поведение системы такое, что любой stdout от него шлется пользователю на почту. Но на какую почту, ее же наверно надо задать? Разумеется, тут все предусмотрено: на почту user@host, и плевать, что она не существует. А как себя ведет себя с письмом на несуществующий адрес почтовый сервер? Правильно, пытается послать до посинения.

А надо было всего лишь отредактировать /etc/sysconfig/crond, чтобы отключить отправку на почту и включить редирект в syslog:

CRONDARGS=-s -m off

рестартнуть crond и почистить очередь:

exim -bp | exiqgrep -i | xargs exim -Mrm

Вы все еще любите глобальные настройки? Тогда мы идем к вам:)

Иногда складывается ощущение, что в командной строке есть вообще все. Как import antigravity.

Наткнулся недавно абсолютно случайно на команду для факторизации чисел:

$ factor 1224234
1224234: 2 3 3 3 3 3 11 229
$ factor 24342342342342342342342342534512312123
24342342342342342342342342534512312123: 11 43053238739605007 51400086909245973599
$ factor 243423423423423423423423425345123121241
factor: ‘243423423423423423423423425345123121241’ is too large

Business Process Model and Notation — еще один способ описания алгоритма или процесса в виде схемы. Разрабатывался с прицелом на то, чтобы нотация была понятна и бизнесу, и разработчикам, и даже менеджерам. TLDR в виде cheatsheet.

Продолжением этой идеи являются BPMN-движки: чтобы схема была не только в документации, но по ней генерировалсь и само управление процессом, вместо какого-нибудь самопального конечного автомата. Звучит неплохо: аналитик нарисовал, разработчик интегрировал где надо, и все готово. Реальность, конечно, немного посложнее, и код все равно надо будет писать. Как и с любым фреймворком, нужно потратить некоторое время на его изучение, за абстракции придется платить производительностью, а при столкновении с ограничениями придется выдумывать костыли. Однако разработку это неплохо ускоряет и плюшка в лице наглядности довольно значимая.

Один из самых популярных BPMN-движков сейчас — это Camunda. Оперсорс, Java, REST API, внутренний API, web-морда для админки — вот, наверно, основные ключи к успеху в текущих реалиях индустрии.

Подробнее про все это можно почитать, например, в блоге о BPMN.

У Xorg есть противный баг: горячие клавиши работают при нажатии, а не отжатии. Я его особо не замечал, потому что в большинстве приложений это не заметно (хотя было что-то подобное лет 10 назад в Firefox).

Однако когда постоянно начал использовать Slack, приложение которого написано на поганом электроне, то этот баг начал прям дико бесить: при переключении раскладки клавиатуры окно теряло фокус. По классике, есть открытый баг в трекере электрона, и даже не один. С одной стороны, вроде проблема не совсем в нем, но с другой — UX это портит конкретно, тем более, что проблема поправима.

Поправить баг на уровне системы можно установкой PPA.

Например, проверку покрытия или отправку отчета куда-нибудь.

Очевидный вариант — сделать кастомную задачу в gradle/sbt/maven, которая оборачивает или перезаписывает старую задачу test. Но если писать таск неохота, то есть и другой вариант, если у вас JUnit5.

Можно сделать кастомный TestExecutionListener, переопределив testPlanExecutionFinished. Чтобы его обнаружил JUnit, добавить полное имя класса в src/test/resources/META-INF/services/org.junit.platform.launcher.TestExecutionListener. Такая штука полезна для составления отчета по покрытию, например.

Но, как всегда, есть нюанс: ассерты работать не будут, потому что в движке все вызовы листенеров обернуты в try-catch. Но если нельзя, но очень хочется, то можно пойти на совсем грязный трюк: запустить движок тестов внутри движка тестов:

val launcherConfig = LauncherConfig.builder().enableTestExecutionListenerAutoRegistration(false).build()
val launcher = LauncherFactory.create(launcherConfig)

val request = LauncherDiscoveryRequestBuilder.request()
        .selectors(selectClass(CoverageTest::class.java))
        .build()

launcher.execute(request)

Тут еще отключается обнаружение листенеров, чтобы это не превратилось в бесконечную матрешку. Звучит как извращение, но чего только не сделаешь, лишь бы не писать кастомный таск для maven…

UPD: таск все-таки пришлось написать, с использованием exec-maven-plugin на фазе test, потому что вложенный движок тестов иногда не успевает отрапортовать о результатах до того, как основной завершил свою работу.

Нашел прикольный способ найти пересечение двух файлов:

grep -Fxf file1 file2

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

Принцип работы довольно прост: берем паттерны из file1 (-f file1), говорим, что это строки, а не регулярки (-F), и ищем точное совпадение строк (-x) в file2. В интернете пишут, что это быстрее, чем приколы с сортироками и однострочниками на питоне.

Мне это пригодилось без -x, чтобы поискать в логах данные из CSV.