LINUX.ORG.RU

Perl meetup, 6 июня

 , ,


0

3

Приглашаем опытных Perl-разработчиков на встречу с единомышленниками. Своим опытом поделятся сотрудники Яндекса. Они расскажут, как работать с зависимостями и вести разработку Perl-приложений с помощью Docker и как они используют Perl для извлечения данных из исходного кода и подготовки их к анализу. Завершится встреча докладом о неклассических способах проверки кода.

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

>>> Подробности

anonymous

Проверено: Shaman007 ()

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

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

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

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

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

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

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

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

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

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

DRVTiny ★★★★★ ()
Ответ на: комментарий от DRVTiny

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

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

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

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

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

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

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

Alve ★★★★★ ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от DRVTiny

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

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

ugoday ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

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

DRVTiny ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от DRVTiny

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

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

docker commit

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

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

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

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

DRVTiny ★★★★★ ()
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от DRVTiny

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ugoday ★★★★★ ()