Perl meetup, 6 июня

Perl meetup

Не знал, что хипстеры используют Perl.

Ты кого смузисосом обозвал?

А есть какие-то большие проекты на perl 6?

На лоре разрешен тотализатор?

Можно поставить на:

• Какой процент участников будет не в свитере;
• Минимальную длину бороды у участников;
• Будет ли кто-то младше 40 лет;
• Будет ли хоть одна женщина;
• Сколько участников приедет (из прошлого) на ДеЛориане.

Чтобы попасть на мероприятие необходимо получить приглашение.

Проверено: Shaman007

Иди в сраку. У нас тут не пиндостан. Если женщины не вывозят, то искусственно нагонять бабьё не будут

Они расскажут

как мы используем Perl

Проверено: Shaman007

Срочно внесите jollheef!

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

Что такое скедня?

Они расскажут, как работать с зависимостями и вести разработку Perl-приложений с помощью Docker

Назовите мне 10 причин использовать docker и я назову 15 возможностей его НЕ использовать.

и как мы используем Perl для извлечения данных из исходных кодов и подготовки их к анализу

Ну да, ну да. Анализ исходных кодов на языках, которые вы реально используете, потому что Perl в Яндекс не в ходу, и совершенно непонятно, с какого перепугу вдруг Яндекс решил проводить митапы по Perl'у??

Завершится встреча докладом о неклассических способах проверки кода.

Понятно. О решении нормальных практических задач не будет сказано ни слова, потому что, повторюсь, Яндекс не использует Perl для решения практических задач. Их тесты для собеседований говорят об этом (какая-то полная чушь в стороне от любой практики), их митапы говорят об этом.

Яндекс, весь ваш бизнес за исключением карт в пределах России - бездарное спекулянтское говно или талантливое спекулянтское говно, убейте уже себя об стену и даже не упоминайте Perl, до которого вам дела нет. Лучше сходите на YaPC конкурентов из Mail.ru, а лучше - на международные YaPC и хоть чему-нибудь научитесь, помимо тупого парсинга файликов регулярками!

Perl 6 - он как коммунизм. Светлое будущее, к которому общество ещё не готово.

Да ладно тебе, Олег. У них много годноты, хотя ПРЕДПРИНИМАТЕЛЬСКАЯ ЖИЛКА торчит из всех щелей и это бесит

зачем perl 6 если perl 5 все еще очень хорош

Назовите мне 10 причин использовать docker и я назову 15 возможностей его НЕ использовать.

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

Ваше решение?

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

Ваше решение?

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

Мне как-то попался такой вкусный маффин, что я опоздал на скрам

Nix/Guix

Nix/Guix

Хорошая альтернатива. Им бы пакетную базу по-больше.

docker это удобная штука для создания контейнеров. Фишка не только в дистрибуции но и секурности. Не знаю что такое Nix, но Guix не о том, насколько я понимаю

Ваше решение?

export PERL5LIB=<PATH>/lib
...
rm -rf <PATH>

Enjoy!

Enjoy!

не люблю ручную работу.

А докер по мановению волшебной палочки всё делает? Читает мысли или что?

А докер по мановению волшебной палочки всё делает?

Да. Вжух-вжух и изменения гаранитрованно откатились. Эники-бэники и кривой скрипт не смог нагадить мимо песочницы. Ахалай-махалай и бинарники с либами ставятся куда-надо, а не в /usr/кривая/коза/tmp/tmp2/{bin,lib,share,etc}. Здорово, правда?

У nix'а уже достаточно большая пакетная база, guix же пока отстает в этом плане

Да, но в данно случае nix/guix соревнуются с:

• всей пакетной базой дебиана, если взять контейнер на основе дебиана
• всей пакетной базой редхат, с тем же условием
• pip, rvm, maven etc для языкоспецифичных репозитариев
• всем вообще, что можно спокойно поставить через ./configure && make && make install

не сдюжат они.

А если у тестируемых приложений 90% библиотек совпадают, а 10% различаются - не проще ли библиотеки приложений хранить вместе с приложениями, но не в контейнере, а просто в одном с каталоге с приложением? Ну т.е. те же Mojo-приложения без проблем таскают все библиотеки с собой, что в этом такого хитрого и почему для этого нужно городить докеры с кубернетесами? Ну т.е. я ещё могу понять какие-то проблемы с интеграцией низкоуровневого кода, где ещё нужно обеспечить его линковку с тучей динамических библиотек. А с perl'ом-то что такого хитрого можно придумать? Там же тупо пути правильно в @INC прописать, а XS-ки так даже лучше, если для всех тестируемых сред будут использовать одни версии сишных библиотек. Или именно с этим какие-то заморочки есть?

Не понимаю, почему это язык до сих пор живёт? Зачем он это делает? На встрече отвечают на эти вопросы как думаете?

Я не спорю, действительно, манипулируя PATH, LD_LIBRARY_PATH, языкоспецифическими средствами можно наколхозить свою песочницу. Если ещё selinux (тут я плаваю) навернуть, можно даже запретить доступ в обход песочницы. Но зачем? Серьёзно, какие у этого преимущества перед простым 'docker run -it debian bash'?

pip, rvm, maven etc для языкоспецифичных репозитариев

У nix даже с quicklisp интеграция, не говоря уж о пипах, цпанах, нпмах.

всем вообще, что можно спокойно поставить через ./configure && make && make install

Ну и будешь пересобирать всё с зависимостями по каждому коммиту? А если понадобится продублировать окружение? Написать никсоебилд намного проще, по-моему

Ну и будешь пересобирать всё с зависимостями по каждому коммиту?

Я говорю о разовой работе. Городить энтерпрайз реди сиай солюшен в данном случае не нужно.

А если понадобится продублировать окружение?

docker commit

«Не создавай лишних сущностей без крайней на то необходимости». При этом содержимое docker-контейнеров выключено из нормального цикла администрирования, обновления, накатывания патчей безопасности. Что если нужно вкатить новую версию библиотеки X во все Perl-приложения, использующие эту библиотеку - например, из-за того, что X стал работать в разы быстрее или там были пофикшены баги, которые при неправильном положении закрылок приводили к падениям в рантайме? При этом ситуация «мне нужно держать в каждом контейнере свою версию X, потому что у неё везде разный API», под которую вроде бы и заточен докер, представляется мне крайне надуманной: у хороших библиотек API - стабильно, и бы они там не изменялись внутри, снаружи это будет работать одинаково. А библиотеки с нестабильным API наверное и не стоит использовать.PATH, PERL5LIB, LD_LIBRARY_PATH, относительные пути - это элементарные вещи, которые прозрачным образом настраивают приложение на работу в рамках своего каталога, но при этом дают ему возможность использовать хоть 90, хоть 95% общих ресурсов, администрируемых централизованным предсказуемым образом.

С docker'ом, который можно использовать конечно для построения своеобразного слоёного дистрибутива, история чаще всего такая: «мы не умеем в Linux, но мы умеем в докер». При этом то, что образуется внутри контейнеров нельзя назвать иначе как помоечным складом какой-то рухляди, взаимодействующей с кодом основного приложения - это никто не обслуживает, не анализирует, этому никто не ищет более быструю замену, потому что «работает - не трожь» (и ещё обязательно молись, чтоб все тесты сошлись).

docker для большинства - это просто реализация какого-то эскапистского подхода, возможность сосредоточиться на приложении и забить на всё остальное. Такой подход не очень хорош, потому что он не о том, чтобы вообще забить на системное администрирование, он о том, что нужно в таком случае нанять в системного администратора в 2 раза дороже - того, который не только в осях силён, но ещё и на докерах с кубернетесами собаку съел. Иначе вы рано или поздно будет сами вынуждены стать системными администраторами и будете тратить на скрипты оркестрации контейнеров то время, которое было бы гораздо разумнее потратить на разработку собственно программного продукта.

«Не создавай лишних сущностей без крайней на то необходимости»

Ну так ваша колхозная альтернатива и есть лишняя сущность.

При этом содержимое docker-контейнеров выключено из нормального цикла администрирования, обновления, накатывания патчей безопасности.

Прекрасно всё работает. CI и докер превосходно сочетаются друг с другом.

Что если нужно вкатить новую версию библиотеки X во все Perl-приложения,

Мы всё ещё обсуждаем мой пример или переключились что-то ещё? Anyway, обновляешь библиотеку в базовом образе и пересобираешь дочерние.

у хороших библиотек API - стабильно

Странно, что у вас нет пони на аватарке.

PATH, PERL5LIB, LD_LIBRARY_PATH, относительные пути - это элементарные вещи,

Я всё ещё не увидел преимуществ, которые они дают. Какие конкретно я получу преимущества?

С docker'ом, который ....

Бла-бла-бла, автомобили для ламеров которые не владеют благородным искусством верховой езды.

docker для большинства - это просто реализация какого-то эскапистского подхода, возможность сосредоточиться на приложении и забить на всё остальное.

Сволочи, гады, кататься хотят, а говно за лошадками убирать не хотят.

Впрочем, я согласен с вашим посылом. Глупые люди могут использовать докер неправильно.