Pull to refresh
9
0
Тимур Нозадзе @TimurN

User

Send message
Какая-то работа с датами, например, есть почти на всех страницах сайта. А где-то её даже много (навскидку — форматирование/локализация дат в каком-нибудь большом списке, например, счетов пользователя или операций). Заменить инструмент и получить прирост по скорости даже пусть, условно, 1%, но в очень большом количестве мест — вроде и пустячок, но приятно.

А какие есть причины не использовать более быстрый модуль вместо/параллельно DateTime там, где его можно использовать, и он приносит профит? У нас с DateTime свободные отношения и никаких обязательств хранить друг другу верность.
Спасибо от REG.RU за добрые слова. Мы, кстати, не только няшечки, но ещё и удалёнщиков до сих пор нанимаем, несмотря ни на что. Так что пишите на resume@reg.ru.
$ echo 63 36|perl golf.pl
0

$ echo 33 33 |perl golf.pl
33

$ echo 33 33 33 | perl golf.pl
33


Это один набор домино, там не может быть повторяющихся костяшек.

Хотя на самом деле это моё решение действительно не совсем корректно, есть определённые данные на которых оно фейлится. Есть чуть более длинный вариант, 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 в командной строке.

Вобщем, во что это выльется в конечном итоге пока достоверно неизвестно. Просто хочется адекватной работы с Гитом, и есть ощущение, что действительно хорошего решения эта проблема пока не имеет.
Разворачивать обязательно, об этом было сказано один комментарий назад: habrahabr.ru/company/mailru/blog/239087/#comment_8037645.
Подробные общие правила Гольфа можно посмотреть, например, здесь: thospel.home.xs4all.nl/golf/rules.html. Как раз п. 5-6 про использование модулей. Самописные модули нельзя использовать никогда, модули из базовой поставки Perl — согласно правилам конкретного соревнования.

Вообще, в правилах можно много нюансов накопать, если заморочиться. Но, наверное, не так уже это всё важно, главное, чтобы было интересно участникам.
Серебрянной пули тут не будет. Можно, например, тесты внутри транзакции прогонять и откатывать её после завершения. Можно вручную чистить/восстанавливать именно конкретные изменённые данные. Можно полностью восстанавливать БД. Всё зависит от объёма данных, от частоты прогона тестов, от того, что они делают, и т. п.

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

И, естественно, на искуственном наборе данных у вас будут ровно такие же сложности.

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

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

А кроме БД у нас очень редко что-то кардинально тормозит, как я и сказал. Так что и автоматизацией не заморачиваемся.
У нас скорость работы основных узлов сайта с точки зрения пользователя меряется функциональными тестами. А целью покрыть всю систему «юнит-бенчмарками» мы никогда не задавались. Это вряд ли реально, да и непонятно, зачем нужно. Самые тормозные места у нас в 99,9% случаев — запросы к БД либо сетевые запросы к внешним сервисам. Первое — проверяется в момент разработки. Со вторым, во-первых, всё равно мало что можно сделать, во-вторых, по большей части оно вынесено во всякие асинхронные очереди и т. д., чтобы минимально напрягать пользователя.
Может, я проглядел, но как должны обрабатываться случаи, когда разных последовательностей максимальной длины больше одной?
К Perl — точно не имеет. К каким-то элементам народного фольклора может быть.
А какую статью на эту тему вы бы порекомендовали?
Да и не только Inf. ;)
Да, так оно и бывает. Стоит только начать, и не остановишься.

Ваше решение, на самом деле, 196 символов (шебанг не считается), что уже вполне неплохой результат. Сходу можно снять ещё 6 символов. Дальше надо думать.
Ну, вообще-то, да, конечно. Но условие было, что принимаются решения, проходящие предложенный набор тестов. Да и разбирать, как оно внутри работает, в насыщенный конференционный день времени не было. Так что как есть.

Главное, что было весело. Не Олимпиада, в конце концов.
Кстати, цикл вводных статей по Plack в PragmaticPerl тоже написан основным автором этой статьи (justnoxx). Не думаю, что есть смысл дублировать это на Хабре. Если какие-то более конкретные вопросы интересуют — пишите, может, что и придумаем.
Нет, так пока руки и не дошли допилить. Принимаем патчи. ;)
На этот вопрос вряд ли могут достоверно ответить даже авторы Perl 6, что уж там говорить про авторов статьи.

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

Так что нужно просто включать мозг в каждом конкретном случае. И иметь какие-то правила и отстроенное взаимодействие внутри проекта. А какой-то такой универсальный стиль программирования, позволяющий писать любые программы так, чтобы всё было шоколадно, вряд ли существует.
1

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity