Какая-то работа с датами, например, есть почти на всех страницах сайта. А где-то её даже много (навскидку — форматирование/локализация дат в каком-нибудь большом списке, например, счетов пользователя или операций). Заменить инструмент и получить прирост по скорости даже пусть, условно, 1%, но в очень большом количестве мест — вроде и пустячок, но приятно.
А какие есть причины не использовать более быстрый модуль вместо/параллельно DateTime там, где его можно использовать, и он приносит профит? У нас с DateTime свободные отношения и никаких обязательств хранить друг другу верность.
Спасибо от REG.RU за добрые слова. Мы, кстати, не только няшечки, но ещё и удалёнщиков до сих пор нанимаем, несмотря ни на что. Так что пишите на resume@reg.ru.
Это один набор домино, там не может быть повторяющихся костяшек.
Хотя на самом деле это моё решение действительно не совсем корректно, есть определённые данные на которых оно фейлится. Есть чуть более длинный вариант, 134 символа:
#!/usr/bin/perl -pl
sub c{$_=pop;s/\d\d/c("@_ $&",$'.$`)/eg;$_=pop;$m=$1 if!/(\d)(\d).*\2\1/&/^ ((.)((.) \4)*\2)$/&y///c>length$m}c$_.reverse;$_=$m//0
Вот для него я пока фейлящих его данных не нашёл. Если кто-нибудь найдёт — мне было бы очень интересно.
Вообще, задача для тестирования нетривиальная — граничных и специфических случаев очень много, и скорость выполнения тестов падает драматически при увеличении их размера.
Да, о нём и пойдёт речь в том числе. Но Git::Raw — просто низкоуровневый байндинг, а хочется чего-то, интерфейсно близкого, например, к работе с Git в командной строке.
Вобщем, во что это выльется в конечном итоге пока достоверно неизвестно. Просто хочется адекватной работы с Гитом, и есть ощущение, что действительно хорошего решения эта проблема пока не имеет.
Подробные общие правила Гольфа можно посмотреть, например, здесь: thospel.home.xs4all.nl/golf/rules.html. Как раз п. 5-6 про использование модулей. Самописные модули нельзя использовать никогда, модули из базовой поставки Perl — согласно правилам конкретного соревнования.
Вообще, в правилах можно много нюансов накопать, если заморочиться. Но, наверное, не так уже это всё важно, главное, чтобы было интересно участникам.
Серебрянной пули тут не будет. Можно, например, тесты внутри транзакции прогонять и откатывать её после завершения. Можно вручную чистить/восстанавливать именно конкретные изменённые данные. Можно полностью восстанавливать БД. Всё зависит от объёма данных, от частоты прогона тестов, от того, что они делают, и т. п.
А самый главный вопрос — как результат выполнения теста влияет на последующие тесты (и влияет ли вообще как-то)? Функциональные тесты в большинстве случаев не делают ничего такого, чтобы друг другу помешать. Консистентность базы они не ломают, количество данных не меняют заметно. Так что восстанавливать если и есть необходимость, то только после прогона всей порции тестов.
И, естественно, на искуственном наборе данных у вас будут ровно такие же сложности.
Впрочем, это уже с тестированием производительности мало общего имеет, это общая специфика любого тестирования, завязанного на БД.
Ну вот у нас автоматизированно проверяется производительность только функциональными тестами. Тесты эти работают на сервере с копией боевой БД (а некоторые даже на продакшне прогоняются). Так что специально данные для них мы не готовим, а работаем на реальных (или их копии).
Да и как ещё можно тестировать производительность работы с БД, если не на реальных данных? На частичной копии вы ведь производительность всё равно не проверите, потому что она напрямую зависит от количества данных. Попытки автогенерации данных, соответствующих объёму продакшн-базы, тоже вряд ли будут удачными — очень сложно будет добиться таких же характеристик данных, такого же распределения и т. п. А если не добиться — то результаты бенчмарка опять же будут иметь мало общего с реальностью.
А кроме БД у нас очень редко что-то кардинально тормозит, как я и сказал. Так что и автоматизацией не заморачиваемся.
У нас скорость работы основных узлов сайта с точки зрения пользователя меряется функциональными тестами. А целью покрыть всю систему «юнит-бенчмарками» мы никогда не задавались. Это вряд ли реально, да и непонятно, зачем нужно. Самые тормозные места у нас в 99,9% случаев — запросы к БД либо сетевые запросы к внешним сервисам. Первое — проверяется в момент разработки. Со вторым, во-первых, всё равно мало что можно сделать, во-вторых, по большей части оно вынесено во всякие асинхронные очереди и т. д., чтобы минимально напрягать пользователя.
Да, так оно и бывает. Стоит только начать, и не остановишься.
Ваше решение, на самом деле, 196 символов (шебанг не считается), что уже вполне неплохой результат. Сходу можно снять ещё 6 символов. Дальше надо думать.
Ну, вообще-то, да, конечно. Но условие было, что принимаются решения, проходящие предложенный набор тестов. Да и разбирать, как оно внутри работает, в насыщенный конференционный день времени не было. Так что как есть.
Главное, что было весело. Не Олимпиада, в конце концов.
Кстати, цикл вводных статей по Plack в PragmaticPerl тоже написан основным автором этой статьи (justnoxx). Не думаю, что есть смысл дублировать это на Хабре. Если какие-то более конкретные вопросы интересуют — пишите, может, что и придумаем.
На этот вопрос вряд ли могут достоверно ответить даже авторы Perl 6, что уж там говорить про авторов статьи.
Пока Perl 6 — это академический проект. Взлетит — хорошо, не взлетит — для пользователей Perl 5 всё равно вряд ли что-то кардинально от этого изменится. Строить же свои проекты или свою карьеру с расчётом на Perl 6 пока однозначно не стоит.
Написать проблемный, потенциально бажный, неотлаживаемый, неподдерживаемый и т. п. код можно и с использованием самых простых конструкций языка. Причём, наверное, любого языка.
Так что нужно просто включать мозг в каждом конкретном случае. И иметь какие-то правила и отстроенное взаимодействие внутри проекта. А какой-то такой универсальный стиль программирования, позволяющий писать любые программы так, чтобы всё было шоколадно, вряд ли существует.
А какие есть причины не использовать более быстрый модуль вместо/параллельно DateTime там, где его можно использовать, и он приносит профит? У нас с DateTime свободные отношения и никаких обязательств хранить друг другу верность.
Это один набор домино, там не может быть повторяющихся костяшек.
Хотя на самом деле это моё решение действительно не совсем корректно, есть определённые данные на которых оно фейлится. Есть чуть более длинный вариант, 134 символа:
Вот для него я пока фейлящих его данных не нашёл. Если кто-нибудь найдёт — мне было бы очень интересно.
Вообще, задача для тестирования нетривиальная — граничных и специфических случаев очень много, и скорость выполнения тестов падает драматически при увеличении их размера.
Вобщем, во что это выльется в конечном итоге пока достоверно неизвестно. Просто хочется адекватной работы с Гитом, и есть ощущение, что действительно хорошего решения эта проблема пока не имеет.
Вообще, в правилах можно много нюансов накопать, если заморочиться. Но, наверное, не так уже это всё важно, главное, чтобы было интересно участникам.
А самый главный вопрос — как результат выполнения теста влияет на последующие тесты (и влияет ли вообще как-то)? Функциональные тесты в большинстве случаев не делают ничего такого, чтобы друг другу помешать. Консистентность базы они не ломают, количество данных не меняют заметно. Так что восстанавливать если и есть необходимость, то только после прогона всей порции тестов.
И, естественно, на искуственном наборе данных у вас будут ровно такие же сложности.
Впрочем, это уже с тестированием производительности мало общего имеет, это общая специфика любого тестирования, завязанного на БД.
Да и как ещё можно тестировать производительность работы с БД, если не на реальных данных? На частичной копии вы ведь производительность всё равно не проверите, потому что она напрямую зависит от количества данных. Попытки автогенерации данных, соответствующих объёму продакшн-базы, тоже вряд ли будут удачными — очень сложно будет добиться таких же характеристик данных, такого же распределения и т. п. А если не добиться — то результаты бенчмарка опять же будут иметь мало общего с реальностью.
А кроме БД у нас очень редко что-то кардинально тормозит, как я и сказал. Так что и автоматизацией не заморачиваемся.
Ваше решение, на самом деле, 196 символов (шебанг не считается), что уже вполне неплохой результат. Сходу можно снять ещё 6 символов. Дальше надо думать.
Главное, что было весело. Не Олимпиада, в конце концов.
Пока Perl 6 — это академический проект. Взлетит — хорошо, не взлетит — для пользователей Perl 5 всё равно вряд ли что-то кардинально от этого изменится. Строить же свои проекты или свою карьеру с расчётом на Perl 6 пока однозначно не стоит.
Так что нужно просто включать мозг в каждом конкретном случае. И иметь какие-то правила и отстроенное взаимодействие внутри проекта. А какой-то такой универсальный стиль программирования, позволяющий писать любые программы так, чтобы всё было шоколадно, вряд ли существует.