Что должен знать начинающий Perl разработчик о перловой инфраструктуре

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

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

    Конечно бывает что технологии умирают, однако если посмотреть на даты в истории коммитов в репозитории перла и даты в ленте заливки/обновления дополнительных модулей, то не скажешь что перл зачах — жизнь кипит ежедневно. Как-то я специально мониторил модули на CPAN — десятки модулей обновляются/заливаются ежедневно.

    Также отмечу что весь свободный софт, и перл не исключение, делается для Unix-подобных ОС, на винде всё это можно делать, но не нужно, рекомендую сразу осваивать нормальную для девелопера ОС (GNU/Linux, FreeBSD).

    Как обычно всё будет в шпаргалочном стиле, ссылки будут в основном на официальные доки, всяких док для быстрого старта полно в сети:

    — Ньютон говорил что он увидел дальше, потому что стоял на плечах гигантов, имея ввиду Галилея и других. Таким образом Ньютон намекал разработчикам не писать, то что уже написано. А то что уже написано для перла обычно лежит на CPAN, ставить это можно как из репозитория вашего дистрибутива (но там обычно есть не всё), так и родной утилитой cpan и её вариациями cpanp, cpanm (+ полезная тулза cpan-outdated). Писать своё конечно можно, но только если текущие реализации чем-то не устраивают или хочется хорошо понять как это работает.
    — И хотя о необходимости отладчика нет единого мнения, отладчик в перле есть, и желательно хотя бы минимально владеть им: perl -d имя_скрипта
    — Померить производительность кода можно с помощью модуля Benchmark или Dumbbench, которой по мнению автора даёт более надёжные результаты.
    — Найти узкие места можно с помощью профайлера Devel::NYTProf, на эту тему есть презентация (для поиска утечек памяти тоже есть модули, но не знаю какой сейчас правильный, вроде Devel::Leak)
    — для модульного тестирования есть Test::More и mock модули типа Test::MockObject, ну и пара статей: про mock и нефункциональные тесты.
    — Минимальный заголовок перлового скрипта/модуля
    use strict;
    use warnings;
    use utf8;
    use open (:utf8 :std);
    use v5.16; # тут указать установленную версию: perl -v
    
    Есть модули для того чтобы одной строкой подключить всё что нужно (Modern::Perl, uni::perl, common::sense), но они подключают разный набор модулей — мне например отключение undefined варнингов не подходит, но нет никакой проблемы сделать свой модуль.
    — нужно понимать как перл работает с utf-8 (точнее хотя бы знать что не всё так просто) — дока, статья (в конце статьи ссылка на ещё одну статью)
    — стоит знать и юзать хорошие практики и нарушать только понимая почему и зачем, утилита perlcritic может подсказать где отступили от «священного писания» (надеюсь не оскорбил никаких верующих)
    — стиль кодирования это отдельная тема, за основу нужно брать этот документ. Утилита perltidy умеет приводить стиль кодирования к описанному в конфигурации = ей можно быстро причесать чей-то криво форматированный код.
    — перл имеет достаточно удобную документацию, которой можно пользоваться и без коннекта к сети:
    perldoc -f имя_функции
    perldoc perlre
    perldoc perlvar
    и т.д.
    

    Понятно что то же самое есть в красивом виде в сети: perldoc, для запоминания всяких особенностей возможно будет полезна такая шпаргалка, или расширенная шпаргалка и шпора по ссылкам, также всегда может помочь сообщество, в частности есть рассылка московских перловиков.
    — создание модулей описано в документации, хотя думаю сейчас их чаще делают в ООП стиле, читать тут и тут, если не юзать тяжёлые модули, типа Moose, то грамотное ООП это use fields и Class::XSAccessor.
    — интернационализация, стоит прочитать search.cpan.org/perldoc?Locale::Maketext::TPJ13
    — документирование — POD
    — свои модули разумно оформлять также как модули для CPAN (вполне вероятно что туда их и будете заливать), для упрощения это процедуры есть куча модулей типа ExtUtils::MakeMake и Module::Starter (ещё есть Dist::Zilla, но он без инсталлятора)
    — Обработка исключений это eval (они имеет две формы, одна с аргументом-строкой это именно eval, а вторая с аргументом-кодом это уже больше try), есть неплохой вариант Try::Tiny.
    — модуль Carp предоставляет аналоги warn и die со значительно более информативным выводом.
    — Однострочки позволяют вам быстро сделать что-то небольшое, например проверить есть ли модуль в системе perl -E 'use SOAP::Lite'.
    — вывести сложную структуру в лог/на экран можно модулем Data::Dumper, Data::Dump немного красивше + ещё есть DDP, JSON::XS много быстрее и больше подходит для маршалинга, но и для отладочного вывода можно использовать.
    — неплохой формат для конфигов YAML, модуль YAML::XS.
    — Бывает нужно понять от каких модулей зависит скрипт/модуль, тот могут пригодится модули типа Module::ScanDeps
    — самый актуальный на данный момент web-framework Mojolicious, ещё есть Dancer, ну и Catalyst вроде жив.
    — event loops & parallel programming — см. коммент от vividsnow
    — валидировать параметры функции можно готовыми модулями, например Params::Validate, правда он не умеет валидировать сложные структуры, для этого можно юзать Data::Validate::Struct.
    — для логгирования есть готовые модули, например Log::Log4perl, Log::Dispatch и универсальная обёртка над разными логгерами Log::Any.
    — для разбора параметров командной строки есть модуль Getopt::Long.
    — работа с базами данных DBI и ORM типа DBIx::Class.
    — поиск абсолютного пути к скрипту из скрипта FindBin и lib::abs.
    — Шаблонизаторы Template и Text::Xslate, в случае использования Mojolicious стоит пользовать его Mojo::Template (хотя его и отдельно можно пользовать).
    — многие часто используемые функции есть в стандартных модулях, например для работы со списками есть List::Util и List::MoreUtils.
    — IDE? настраивайте vim, emacs или любой иной продвинутый консольный редактор, не нужно монстров.
    — базовая книга это «Programming Perl» Larry Wall, Tom Christiansen, Jon Orwant она же книга с верблюдом, если хочется понимать больше «Advanced Perl Programming» Sriram Srinivasan.

    Про понятные названия, разумные размеры функций и т.п. тоже нужно говорить, но это не привязано к перлу и уже много раз сказано, посему не здесь.

    Конечно, как обычно, ожидаю помощи коллективного разума — устал уже вспоминать что ещё по крупному нужно, а в мелочи ударяться не хочется.

    UDP: Благодарности человекам: UncleAndy, Андрей Ковбович, Pilat, Akzhan Abdulin,
    полезный коммент от afiskon
    ещё комент от biophreak
    и ещё о шаблонизаторе, PSGI, про Test::More на русском, защиту исходников, документацию, стартовые доки.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 120
    • 0
      Ну это для продвинутых, я не для начинающих. Хотелось бы что-то типа например:
      1. #!/usr/bin/env perl
      2. PPM
      3. Под виндой — ActivePerl
      4. волшебный $_
      5. полезный =>
      6. различные виды кавычек
      7. модификаторы (print if)
      8. специальные выражения ($. $! $$ и т.п.)
      9. пояснить идиомы вроде:

      while (<*.txt>) {
      print if -s;
      }
      • +2
        Не про сам язык хотел написать, а по инфраструктуре, по языку достаточно написано
        • 0
          $_, $., $!, $$ — просто почитайте perlvar perldoc.perl.org/perlvar.html

          А вообще хорошо-бы прочитать (или хотя-бы просмотреть):
          perlintro, perlfunc, perlop, perlvar, perlsyn, perlreftut, perlre/perlrequick
        • 0
          Шаблонизатор — Template
          Менеджер процессов для FastCGI — FCGI::ProcManager
          Работа с мемкэшем — Cache::Memcached (Cache::Memcached::Fast я пробовал, но он падал при нагрузке)
          • 0
            Шаблонизатор добавить это идея, но не только TT, но и Text::Xslate нужно упомянуть
            • 0
              Ну, я только с TT работал и он меня не подводил. Поэтому в сторону других шаблонизаторов и не смотрел. :)
        • +2
          — Однострочки позволяют вам быстро сделать что-то небольшое, например проверить есть ли модуль в системе perl -E 'use SOAP::Lite'.
          Можно и так например
          perl -MFoo -eexit

          По поводу
          use utf8; use open (:utf8 :std); use v5.16;

          Во-первых, не надо бездумно всегда слепо использовать use utf8; и use open, не понимая как оно работает.
          Во-вторых прагма use v5.16 будет работать если используется перл 5.16 или выше.
          А если в компании, в которую вы устроились, используют 5.8.8?

          perlcritic тоже надо «уметь» использовать.
          Просто так взять и пулять все свои либы и скрипты под perlcritic-brutal не нужно.
          • 0
            Согласен, старался это отразить, про utf и PBP сказал отдельными пунктами, ну а версия перла естественно зависит от возможности, там где другой скорректируют
            • 0
              Думаю, главное отметить что при написании скриптов обязательно нужно использовать «use strict». :)
              • 0
                С этим сложно спорить конечно :)
                Но иногда нужно бывает «сказать» no strict 'refs'; в редких случаях (когда например вам нужно сделать символическую ссылку).
                Так же я бы добавил в статью небольшой абзац про indirect method call, важно помнить что он есть. Иначе можно натолкнуться на подобное и долго искать багу:
                use strict;
                use warnings;
                
                Syntax error!
                exit 0;
                

                Оно выполнится без ошибок, как раз из-за специфики indirect вызовов.
                • 0
                  Я не осилю, сейчас точно, написать такой абзац, напишете — добавлю
                  • 0
                    Ну раз уж пошла такая пьянка, пожалуй добавлю «узких» моментов перляки:
                    — Очень важно помнить про autovivification при работе с перловыми хешами.
                    — Важно также помнить про «пустые» return-ы:
                    --- ~ » perl                                                                                                                                                                                          
                    use warnings;
                    use strict;
                    use Data::Dumper;
                    sub foo { return }
                    warn Dumper({a => foo(), b => 2});
                    
                    __END__
                    Odd number of elements in anonymous hash at - line 5.
                    $VAR1 = {
                              'a' => 'b',
                              '2' => undef
                            };
                    

                    В данном случае нам поможет use warnings;, но если например функция делает return; в какой-то исключительной ситуации, то ворнинга мы не увидим при первом запуске например.

                    — Чтение файлов, например. Нужно понимать различие между конструкциями:
                            for(<$fh>) {}
                    # и
                            while(my $row = <$fh>) {}
                    

                    В первом случае, если вы откроете большой файл, то высока вероятность oom.
          • 0
            Отладка — perl -d:ptkdb, хотя бы, а лучше разобраться с отладкой на удалённом сервере

            Базы данных — DBI

            Разворачивание приложений — perlbrew (хотя бы чтобы тот же 5.16 поставить), App::cpanminus — для установки своего набора модулей в домашнюю директорию

            OOP — Moose, хотя бы для того чтобы знать что это такое (о пользе Moose вопрос дискуссионный)

            Нахождение пути к выполняемому скрипту — FindBin

            Шаблонизатор — Mojo::Template, остальные можно и нужно выкинуть (хотя Древние их и любят, ну так они и HTML::Template любят ...), так как пользы от языка над языком мало, разве что иллюзорная простота для верстальщиков (TT с моей точки зрения, например, сложнее перла)

            Минимальный заголовок перлового скрипта/модуля — v5.14, так как 5.16 в debian/stable нет и в ближайшее время не будет (в testing 5.14), а несовместимости в нём со старыми версиями сильно больше чем хотелось бы

            IDE — Eclipse, иные рекомендации отталкивают многих людей, а выгоды от vim/emacs мало, консоль это прошлое

            • 0
              Дополнил немного

              > Отладка — perl -d:ptkdb, хотя бы, а лучше разобраться с отладкой на удалённом сервере

              не понял что означает эта фраза, perl -d на удалённом сервере и можно выполнять
              • 0
                >не понял что означает эта фраза, perl -d на удалённом сервере и можно выполнять
                На удалённом серверер отладку с помощью perl -d делать можно, но это как удалять аденоиды через анальный проход. Есть же инструментарий для упрощения — тот же Eclipse + EPIC, в идеале. Вот эти инструменты я и предлагаю изучать.

                >В Gentoo текущая стабильная версия 5.12.4. А Vim и консоль это и прошлое и настоящее и будущее.
                Я удивлён, что в Gentoo вообще есть понятие стабильности :) но я ориентируюсь на майнстрим, а там в ближайшем будущем 5.14. Насчёт консоли… если программировать всерьёз, то это на любителя, я слышал о программистах, которые в виме пишут, но как только с ними встречался в больших проектах они сразу исправлялись.

                • +2
                  Gentoo как минимум не менее стабилен, чем другие дистрибутивы — конечно, если используется стабильная версия для абсолютного большинства пакетов. А если по умолчанию ставить самые свежие и ещё не тестированные версии всех пакетов — ССЗБ, думаю будет работать так же, как аналогичные testing/unstable варианты других дистрибутивов (впрочем я этого делать не пробовал, мне работать надо а не дистрибутив отлаживать).

                  Кстати, а что вообще такого ценного добавили в 5.14/5.16, чтобы требовать минимум эти версии? В 5.10 действительно было много всего полезного (оператор //, рекурсивные regex, именованные () в regex, жадные множители без отката в regex, my $_), в 5.12 не было ничего полезного (интересное — было, например оператор… (но им можно пользоваться в процессе разработки, а в релизе его быть не должно, так что требовать 5.12 в релизе необходимости нет) и указание версии в package (но это мелочь и ради неё ломать совместимость с 5.10 смысла нет)).

                  Что касается Vim… насколько я знаю, многие его используют не просто на больших, а на громадных проектах, причём даже не Perl, а C/C++. То же ядро линуха, думаете, большинство разработчиков пишет в Visual Studio или Eclipse? :) Кроме того, если в файлах/коде проекта невозможно ориентироваться без навороченной IDE, это чаще всего означает проблемы в организации кода.
                  • +1
                    > На удалённом серверер отладку с помощью perl -d делать можно, но это как удалять аденоиды через анальный проход. Есть же инструментарий для упрощения — тот же Eclipse + EPIC, в идеале. Вот эти инструменты я и предлагаю изучать.

                    Я такого советовать не готов, специалист должен уметь решать проблемы без этих монстров
                    • –1
                      Слесарь, конечно, может сделать трепанацию черепа топором и отвёрткой. А хирургу для этого потребуется куча инструментов и помощников.И кто из них специалист?
                      • 0
                        Предлагаю вам написать пост с голосованием по этой теме — там и обсудим
                        • 0
                          А это имеет смысл? Всё равно кто пользовался нотепадом — будет им пользоваться, кто эклипсом — им. Да и репрезентативную выборку не получить.
                          • 0
                            Точно могу сказать только одно — холивар будет отменный :-)
                            Но может и получится подискутировать предметно
                • +1
                  В Gentoo текущая стабильная версия 5.12.4. А Vim и консоль это и прошлое и настоящее и будущее.
                  • 0
                    Надо-же, никогда не обращал внимания.
                    Под ~x86 всегда собираю
                • +2
                  базовая книга это «Programming Perl» Larry Wall, Tom Christiansen, Jon Orwant она же книга с верблюдом


                  ее скорее можно считать справочником, чем учебником.
                  годная книга по перлу: Damian Conway — Perl Best Practices
                  • 0
                    Ещё отличная книга Learning Perl the Hard Way (книжка под GNU FDL, так что ссылка легальная :) ).
                    • 0
                      Меня еще Perl Cookbook выручает. Забыл что-то — опа тебе рецептик, вспомнил как работает.
                    • 0
                      Второе название книги — Perl Broken Practices ;)
                    • +2
                      А мне интересно было бы узнать — есть ли нынче спрос на совсем начинающих перловиков. Вот например средней руки системный администратор решил переквалифицироваться в программиста, давно писал на перле пару программок в 500-1000 строк, но совсем из головы уже выветрились детали самого языка. Есть ли конторы нынче, которые заинтересованы в становлении программистов такого типа в своих стенах? И какой уровень зарплат могут позволить себе такие конторы на то время, пока человек разберётся?
                      • 0
                        Спрос есть на тех кто готов учится, пишите в личку
                        • 0
                          В личку.
                          • 0
                            Нанимают — и бывших программистов на PHP и админов, и физиков и врачей. В том числе в крупные компании. Было бы желание. Про зарплату сказать не могу — тут уж зависит от опыта и как договоритесь.
                          • –5
                            — IDE? настраивайте vim, emacs или любой иной продвинутый консольный редактор, не нужно монстров.

                            сомнительный совет, учитывая задекларированные цели
                            берут способную молодёжь для превращения в перловиков

                            с тем же успехом можно посоветовать использовать монохромные АЦПУ дисплеи 25x80 вместо fullHD мониторов
                            • 0
                              Возможно это чуток сурово, но это вопрос для отдельной темы — насколько велика ценность IDE
                              • +1
                                я пробовал с и без IDE, c IDE — было удобнее

                                в перловых проектах, где файлов больше сотни и используется OOP — IDE необходим
                                навигация по коду удобнее всего была в sourceinsight, дебагер — приятнее было использовать в eclipse

                                notepad++ — предоставлял только необходимый минимум для написания скриптов (считаю, что посветка синтаксиса не роскошь, а необходимость)

                                vim — имел смысл, только если ничего иного использовать нельзя (небольшие коррекции кода на удаленном сервере, где вообще ничего нет и доступ только через ssh)
                                • –1
                                  IDE нужен, когда много файлов и директорий, согласен.
                                  Мне уже когда больше десятка файлов, скакать между ними удобнее в дереве проекта, а не переключаясь между окнами и т.п.
                                  Плюс я не знаю, как без ide в отладчике можно запустить один скрипт а в другом поставить брейкпоинт.
                                  • –1
                                    я тоже.
                                    Но погодите, вот сейчас подтянутся убежденные сторонники парсинга логов, и объяснят, почему отладка с брейкпоинтами — это не труЪ.
                                    • 0
                                      Да, я с удивлением встретил их здесь.
                                      По-моему, единственный аргумент против такой отладки — программист не думает, а сразу лезет в отладчик, и правит после этого программу, только чтобы она в нужном месте работала, вместо того чтобы задумчиво глядя в экран, найти ошибку более общего характера.
                                      По-моему, этот аргумент несостоятелен — то же самое можно сделать и при помощи логов…
                                      Только с логами надо больше телодвижений, постоянно добавлять туда какие-то переменные, вместо того чтобы сразу посмотреть их в визуальном дебагере.
                                    • 0
                                      Может поможет soft breakpoint: $DB::single = 1
                              • +2
                                Годная шпаргалка. Я бы также упомянул Padre (just in case), сборку Citrus Perl для Windows, утилиту prove, Catalyst, Mouse (не путать с Moose), Devel::REPL. Ну и раз вы в одной заметке упомянули Perl, Linux и VIM, не лишним будет назвать и Git. Для новичков я осмелюсь порекомендовать мою серию уроков по Perl.
                                • +1
                                  сослался на коммент в конце статьи
                                • –6
                                  В CPAN может и заливают что-то каждый день, но сам Perl еле дышит.

                                  Качество модулей в CPAN лучше не становится, достаточно вспомнить такую эпичную штуку, как поддержку кодировок в zip архивах — rt.cpan.org/Public/Bug/Display.html?id=35334 когда патч лежит с 2008-го года, но никто не чешется.

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

                                  А мало с чем сравнимый треш с кодировками и юникодом, если вы вдруг решите писать под Linux и Windows могут порадовать любого искателя приключений на мягкую точку.

                                  Говоря иначе — советую сто раз подумать, прежде чем становиться начинающим разработчиком Perl.
                                  • +3
                                    Да ладно.
                                    Если патч лижит с 2008 года и никто не чешется — значит патч никому не нужен.
                                    Быстрые веб фреймворки? Вспомним про скорость RoR до выхода Ruby 1.9. Советы использовать JRuby так как он быстрее MRI — это ли не трэш? И это при весьма неслабой тогда популярности RoR… Да щас _мода_ сменилась, щас все любят Node.js… И это при том, что я в принципе весьма за RoR, Node — но и Mojolicious с Dancer весьма неплох — да и старичок Catalyst никуда не делся…
                                    Для меня было откровением узнать что такой жа треш с кодировками и юникодом творится в Python 2.x — и ничего, тоже, живет двойка, несмотря на призывы переходить на 3.x

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

                                      Если вам охота возиться с умирающим языком, скудным коммунити, тормозными и устаревшими модулями — дело ваше. Лично мне удовольствия это не доставляет.

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

                                      Хотите сказать, что я не прав? Тогда покажите на хороший и быстрый орм и на кросплатформенный модуль для создания архивов, в которые можно было бы «положить» файлы из разных папок, с поддержкой русского, который бы без проблем открывал тот-же winrar?

                                      Я кагбы без претензий, просто интересно на такие посмотреть.
                                      • 0
                                        если правильно готовить DBIx::Class или Rose::DB + кэш, то в итоге всё упирается в производительность БД, а не орм
                                        архивирование: system qw(7z a), 'test.7z', @files
                                        • –1
                                          Это, пожалуй, единственные рабочие ОРМы, похожие на ОРМы из больших языков =) Только весьма тормознутые, местами со странностями. DBIx::Class заброшен, последний авторизованный релиз был в 2009-м, Rose клепают по релизу в год, но все идет к тому, что и его забросят.

                                          На хорошие и быстрые оба не тянут.

                                          Про архивирование — спасибо, я к использованию 7z через вызовы system и сам пришел, т.к. в огромном CPAN так и не нашлось пакета-оболочки для вменяемой работы с архивами. Так и приходится обвешивать старый проект костыликами.

                                          По поводу описанных выше веб-фреймворков вроде Mojo, достаточно сравнить активность листов рассылки по сравнению с даже не самым известным java фреймворком Play (а активность у перловых проектов в разы ниже), что бы сделать выводы.

                                          Собственно я не вижу, что в Perl может заинтересовать молодого любопытного разработчика и продолжаю считать этот язык огромным умирающим миром. В который все еще требуются доктора различной квалификации.
                                          • +2
                                            thanks for FUD, но будьте специфичны — укажите где тормознутость и странности, в чём измеряется «хорошесть» и где сравнение скорости? btw, Rose-DB-0.769 — 25 May 2012, DBIx-Class-0.08201 — 05 Oct 2012

                                            use Archive::Tar;
                                            ( my $tar = Archive::Tar->new )->add_files(@files);
                                            $tar->write('test.tgz', COMPRESS_GZIP);
                                            

                                            высокая активность в рассылке может также говорить о туче не решаемых чтением доков проблем и вопросов )
                                            • –1
                                              cl.ly/image/3O430z2L111E

                                              Иногда лучше сразу читать, что от вас просит собеседник. Что бы не попадать впросак после ответа.
                                              • +1
                                                если делаете архив под *nix для windows-юзеров, то юзайте либо пример с 7z выше (не понимаю в чём костыльность системного вызова)
                                                или
                                                use Archive::Tar;
                                                use Encode qw(encode decode);
                                                map { 
                                                    $_->rename( encode( cp866 => decode( utf8 => $_->name ) ) ) 
                                                } ( my $tar = Archive::Tar->new )->add_files(@ARGV);
                                                $tar->write('test.tgz', COMPRESS_GZIP);
                                                
                                                • –5
                                                  И в этом весь перл с его сипаном, дружище:

                                                  cl.ly/image/3X2M1l3O211h
                                                  cl.ly/image/1N2y0b113x28

                                                  Теперь эпик фейл не только в винде, но и в юниксе =)

                                                  Смирись, за семнадцать лет существования CPAN так и не родился модуль для нормальной кросплатформенной работы с архивами. Чем привлекать молодых?
                                                  • –1
                                                    Значит никому не был нужен — потому и не родился. Молодым работа с архивами — это то что нужно, да. :)
                                                    • –2
                                                      Задача вроде «собрать несколько файлов и выдать в виде архива» не так уж и редка даже в вебдеве. В Cpan полно модулей для архивов, только ни один не понимает русский язык или юникод. Хотя поддержка юникода в том-же zip официально существует лет пять.

                                                      Как я уже писал, под Archive::Zip даже патч есть. Только за несколько лет его никто не удосужился включить в дистрибутив.

                                                      Без обид, но это никак не свидетельствует об особых перспективах развития языка.
                                                      • +4
                                                        примените патч, создайте и залейте на CPAN модуль Alt::Archive::Zip — problem solved!

                                                        p.s. windows не поддерживает юникод в zip файлах в своих Compressed Folders судя по статье в wikipedia
                                                        • –4
                                                          Да, но прийдется отвечать за этот пакет. Чего делать особо не хочется.
                                                          • +2
                                                            Вот давно уже смотрю как вы эту проблему с кроссплатформенными архивами обсасываете (уже который пост) и до сих пор не могу понять вашу логику
                                                            — есть проблема
                                                            — проблема связана с локалями, поэтому понятно что касается не всех
                                                            — есть патч (его уже даже кто то написал!)
                                                            Можно применить патч и юзать решение для себя
                                                            Можно применить патч и залить исправленный вариант на CPAN.
                                                            Нет, вы выбираете третий вариант — нет, я сменю язык разработки, так как Perl — г… но…
                                                            Мда, логично, чо…

                                                        • +1
                                                          Без обид, но к перспективам языка это относится как к существованию бозона Хиггса приблизительно…
                                                      • 0
                                                        замените cp866 на cp1251, тогда winrar покажет нормально, но не покажет например 7zip под win (c cp866 на нём протестил, думал winrar не будет отличаться, но нет..)
                                                        то что в юниксе при перекодировании имена файлов меняются на не читаемые — само собой разумеется.
                                                        если системный вызов «7z a ...» работает кросс-платформенно и решает задачу — так и юзайте его — в чём проблема
                                                        • –1
                                                          Мне нужен был кросплатформенный вариант, для двух распространенных ос (мак/вин). В итоге я потратил два дня на изыскания, перебрал несколько модулей с CPAN, потом перебрал несколько архивных программ.

                                                          С системным вызовом свои сложности, сразу надо добавлять в программу настройку, проверять существование бинарника, выводить предупреждения если его нет… (делается для ендюзеров) когда можно было бы обойтись без всего этого обвеса. Плюс работа с консольным 7z тоже таила в себе грабли, сейчас уже точно не помню, надо в код смотреть.

                                                          Впрочем, этого ожидаемо, учитывая пляски с бубном вокруг кодировок в перле под виндой. И да, мне особо не по душе такие трудности этого умирающего языка, поэтому предпочитаю что-то более развитое, без старческих болезней и с более развитым набором библиотек.
                                                          • +2
                                                            Странно сливать проблемы кроссплатформенной разработки на язык, но чтож — посоветуйте тот волшебный язык, на котором есть архив-либа работающая с кирилическими именами файлов в юникс системах с unicode локалью и windows, где с локалью всё несколько сложнее?

                                                            p.s. к чему этот FUD про умирание в конце каждого вашего поста? хейтер чтоли? )
                                                            • –1
                                                              Шла бы речь о C, я бы про кросплатформенность ничего бы не говорил. От языка типа Perl ожидаешь большего =)

                                                              Нет, не хейтер. Защитник детей (с)
                                                    • –1
                                                      А «неудобные» вопросы про скорость, странности и хорошесть ORM вы конечно пропустили, в итоге, извините, «съехав» на личное мнение. Не говоря уже про то что перепутили DBIx::Class еще с чем то…
                                                      Как говорят в Интернетах, «конец немного предсказуем»…
                                                      • –1
                                                        Я не готов в камментах обсуждать вопрос вроде DBIx::Class vs Hibernate, скажу лишь, что скорость первого не впечатляла, как и работа с ним. Так что считайте это моим личным мнением.
                                                    • –3
                                                      Про RoseDB — посмотрите на количество релизов за разные годы, на список рассылки, проект практически не развивается, интерес к нему чуть больше нуля. По одному-двум сообщениям в месяц.

                                                      DBIx::Class умер еще раньше, релиз в 2007-м, в 2009-м и некий ** UNAUTHORIZED RELEASE ** в этом году.

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

                                                      Резюмирую. Добро пожаловать на кладбище мертвых животных. Что в этом должно интересовать молодого разработчика? Только проекты типа «наш перловик умер от старости и кому-то надо тянуть кучу кода дальше»
                                                      • +2
                                                        > DBIx::Class умер еще раньше, релиз в 2007-м, в 2009-м и некий ** UNAUTHORIZED RELEASE ** в этом году.

                                                        Простите, а это тогда что:
                                                        image

                                                        там в списке много еще релизов после 2009.

                                                        > Только проекты типа «наш перловик умер от старости и кому-то надо тянуть кучу кода дальше»

                                                        а это петросянство вообще не в тему…
                                                        • –3
                                                          Оу, прошу извинить, с DBIx::Class ошибся. Не к тому разработчику зашел. В целом же свое мнение менять не буду, перл умер.
                                                    • +2
                                                      Привет, я некогда начинающий разработчик с полутора годами опыта уже. Я выбрал Перл не за такие относительные вещи, как наличие можных приложений и модулей, а за философию языка и предоставляемую свободу. Но это все неважно.
                                                      Больше всего меня удивляют люди (с достаточно большим опытом и крутыми навыками программирования на языке), который только говорят, что на Перле нет ничего годного, что есть в питонах и прочих джавах. Дак какого хера — напиши. Даже в некоторых случаях, где в других языках есть то, что нет в перле, можно не генерировать идеи, а написать реализацию на Перле. Если оно такое нужное и полезное, то подхватят и помогут. ЧТо за потребительство? Зарабатывать бабло на опенсорсном языке, модулях и приложениях и чмырить язык, что не предоставили халяву получше. При этом ни черта не делая для сообщества и развития своего языка. Не место красит человека, а человек место. То же и про языки, и прочее. Дураки следуют моде, умные живут сами по себе, крутые перцы моду создают. Хотя к чему нужна эта мода?
                                                      • 0
                                                        Ну и как ощущения? Работаете по профилю? Саморазвитие? Что нового написали на перле за последний год?

                                                        И что плохого в потребительстве? Ведь язык программирования без потребителей быстро оказывается на страницах википедии в разделе мертвых языков =)
                                                        • +2
                                                          Работаю перлистом в неплохой команде. В принципе, все так, как хотел: удаленка, высокий потолок развития наперед, зарплата. Много задач, которые раньше сделать бы не смог, попадаются и интересные для меня лично. Не жалею, что не пошел учить джаву или питон, как всякие выпускники вузов штапмованные. Считаю, что человек должен сам определеть свое развитие и выбирать тот же язык. Потребительство в опенсорсе не совсем работает. Суть в том, что надо что-то давать, чтобы это развивалось. И языки попадают в мертвые уже после того, как пользы достаточной никто не приносит. А потреблясты всегда там, где тепло и удобно. Это лишь следствие.
                                                  • +3
                                                    А покажите мне на python нормальную реализацию клиентской библиотеки SOAP + клиентский ssh который может коннектиться к cisco оборудованию по ssh? ;)
                                                    Вот честно. perl тут хоть что-то дает, а python — грабельки. Я конечно могу и сам написать ручками все, но это ж долго и неблагодарно.

                                                    По мне рано perl хоронить, в своей нише он очень хорош.
                                                    • –1
                                                      github.com/knipknap/exscript

                                                      Exscript is a Python module and a template processor for automating network
                                                      connections over protocols such as Telnet or SSH.

                                                      Exscript is also an excellent and much more powerful Net::Telnet replacement,
                                                      so we welcome all you Perl developers!

                                                      Exscript may be used to automate sessions with routers from Cisco, Juniper,
                                                      OneAccess, Huawei, or any others.
                                                      • +2
                                                        Да, я знаю эту библиотеку, сам патчил и разбирался.
                                                        У нее несколько проблем:
                                                        1. Makefile и прочие сопутствующие файлы сделаны коряво и не кросс-платформенно ни разу. Чтобы собрать ее под FreeBSD приходилось доставать рашпиль.
                                                        2. Поддерживается только оборудование cisco на cisco ios. Cisco ASA и прочие cucm и cue идут лесом, надо брать самому и патчить.
                                                        3. Автор не хочет прилагать усилия ни по пакетированию этой библиотеки, ни по доделке и продвижению.

                                                        И это все на ультрасовременном и поддерживаемом python-е!
                                                        А для soap я вообще библиотеки клиентской чтобы как-то работала — не нашел.

                                                        Ну и выводы у меня такие — perl старый язык — но нем мне получается работать — python новый но библиотек в нем мало или совсем нет, стоит чуть сделать шаг влево, шаг вправо от mainstream. И да, я буду использовать perl (и даже tcl) потому что на них у меня получается делать быстрее чем на модном python-е.
                                                        • –2
                                                          Я на питоне за всю жизнь написал пару программок для работы с опенофисом. Честно, не знаю какие подводные камни есть в этом языке. Сейчас пишу под Java и использую перл как вполне сносный язык для вспомогательного скриптования. Но с таким же успехом мог бы использовать пхп или питон.

                                                          И честно скажу, что-то серьезное писать на перле нет желания. Не сомневаюсь, что язык проживет еще много-много лет, как жив до сих пор фортран. Будут и программисты, кто-то же учит клингонский. Но это будет такая узкая ниша, что молодым скорей всего будет не интересно в нее серьезно входить. Просто нечем заманивать, нет никаких приятных плюшек.
                                                • –2
                                                  Качество модулей в CPAN лучше не становится

                                                  Абсолютная правда. Все перловики любят похвастаться, что на сипане есть 20к дистрибутивов. А вот что многие из них являются устаревшим и нерабочим говном, это они тактично умалчивают.
                                                  Есть относительно небольшая кучка кучка авторов и их модулей, которые делают реально полезные вещи, и делают их правильно. На самом деле, именно вот эта небольшая часть и составляет основную мощь сипана.
                                                  • +2
                                                    вы так говорите будто бы в gems или eggs все модули абсолютны полезны и иннвационны, и там нет велосипедов, ндацти реализцаий каждого апи неведомого сервиса и пр. крапа
                                                    • –2
                                                      Нет, я так не говорю. Где я вообще что–то сравнил с другими языками?
                                                      Я говорю, что аргумент, который всегда приводится в спорах, презентациях и т.п., на самом деле… скажем так, производит впечатление ровно до того момента, пока не начнется плотная работа с сипаном.
                                                      • +1
                                                        общеизвестно что 80% чего-либо — дерьмо, но это проценты, а стоит считать в абсолютных числах, т.е. у одного языка 100 модулей в архиве, значит 20 нормальных, а у другого 1000 в архиве, значит 200 нормальных
                                                • 0
                                                  Актуальность Mojo и неактуальность Catalyst — это субьективное мнение автора?
                                                  Не в плане священных войн, просто уточнить.
                                                • +2
                                                  Разместил на hh резюме разработчика perl с опытом, з/п от 90 т.р., полный день — позвали в один день сразу в два места, не считая ещё одной вакансии, которая там уже была с такими параметрами.
                                                  А стоит ли сейчас начинать — не знаю, не модно это, конечно. Всякие руби с питонами сейчас.
                                                  Не начинайте, нам дышать легче будет :)
                                                  • –5
                                                    Объективно — сейчас начинать с Perl не стоит. Сейчас время не отдельных программ, а сервисов, а они на перле не пишутся — нет ни SOAP вменяемой реализации, ни даже ясности с простейшим JSON-RPC. JavaScript фреймворки perl в качестве серверной части не поддерживают. Простота загрузки модулей на CPAN привела к жуткому замусориванию, документация поддерживается в древнем POD формате… минусов столько, что всерьёз изучать перл и на нём писать большое чем системные скрипты смысла нет. Конечно можно занять узкую нишу перлового кодера, но разве это интересно?
                                                    • 0
                                                      А на каком языке сейчас есть вменяемая реализация SOAP?
                                                      Я в свое время поискал, C# для меня не вариант, а к python-у ничего нормального не нашел.
                                                      Поэтому так и осталюсь на perl на SOAP::Lite со всеми его косяками.
                                                      • 0
                                                        C# и Java. SOAP::Lite — это клиентская урезанная реализация, я имел ввиду серверную, то есть написание SOAP сервисов на Perl. Есть пара модулей, но они вещь в себе.
                                                        • 0
                                                          SOAP::Lite это и сервер тоже
                                                          • +1
                                                            В Soap::Lite не сервер, а «сервер». Серверная часть реализуется с SOAP-WSDL, но не так хорошо, чтобы можно было на неё полагаться в серьёзных проектах.
                                                            • 0
                                                              ок. На чем сейчас модно, кроме C# и Java делать Server-Side SOAP проекты?
                                                              • 0
                                                                мне нужно было мало, поэтому хватило «сервера» SOAP::Lite
                                                      • 0
                                                        Если цель писать сервисы — начинать с Perl конечно не стОит. Хотя говорить что сервисы=SOAP конечно же нельзя — есть и REST, и Thrift, и прочие Aero…
                                                        • –1
                                                          Объективно — сейчас начинать с Perl не стоит.


                                                          Это так. Плюсануть не могу — поддержу комментарием.

                                                          1.
                                                          Перл, с его концепцией There Is More Than One Way to Do IT — оказался подходящим полем для экспериментов, отработаные в нем концепции перешли в другие языки. Ирония в том, что этот же принцип оказался недостатком для масштабных enterprise-проектов, где, в контексте удобства поддержки кода, многообразие выразительных форм означает увеличение вероятности ошибки и затруднение инспекци кода. И именно из-за трудности поддержки большого количества кода в долгосрочной перспективе — в настоящее время перлу предпочитают сишарп и яву.

                                                          2.
                                                          Текущие предложения для перловиков — это, как правило подддержка и доработка уже существующих систем. По опыту знаю, что наследие в таких случаях практически не дает возможности внести изменение в дизайн и архитектуру, вместо этого приходится добавлять все новые и новые костыли и обходные пути для поддержки работоспособности системы. А добавление костылей — плохой контекст для обучения новичков.

                                                          3.
                                                          Спрос на перл кодеров на порядки меньше спроса на те же сишарпы, явы и дотнеты — и это самый очевидный аргумент в пользу того, что начинать с перла не стоит. Это конечно не аргумент для тех, кому не хочется быть штампованным выпускников вуза и заниматься потребительством, где тепло и удобно. Но если вы хотите не только обладать эзотеричесими знаниями о редко используемых языках программирования, но и быть востребованными на рынке — перл вам имеет смысл осваивать совсем не в первую очередь.
                                                          • 0
                                                            Лично по мне perl и C# с Джавой не сравнимы. Разные слишком языки.
                                                            • 0
                                                              есть ряд задач, которые можно писать и на том, и на другом

                                                              когда заказчик после успешного выполнения пилотного проекта прямым текстом говорит, что для следущего проекта он предпочтет перлу сишарп потому, что перл код некому поддерживать на их стороне — сразу задумываешься о многом
                                                              • +1
                                                                А это то тут причем?

                                                                Я сказал что perl (с его быстротой разработки и переносимостью) никак не сравним с C# и Java. То что заказчик хочет — это ортогонально (по моему мнению) к предмету спора.

                                                                Я бы понял когда переход был бы perl -> python или там perl -> ruby. Но perl-> C#,Java? Как то в голове не укладывается
                                                                • 0
                                                                  предмет спора — стОит ли с перла начинать
                                                                  когда видишь, что заказчики предпочитают перлу другие платформы даже при успешно выполненном проетке — это довод в пользу других платформ
                                                                • +1
                                                                  > перл код некому поддерживать на их стороне

                                                                  так любая контора не хочет поддерживать код на языках отличных от тех что она юзает, мы вот сишарп не возьмём — некому на нашей стороне поддерживать
                                                                  • 0
                                                                    всё верно
                                                                    И учитывая то, что спрос на перл меньше спроса на яву и дотнет,
                                                                    количество контор, которые не хотят поддерживать перл — больше на порядок, чем таких контор, как Ваша.
                                                                    • 0
                                                                      Бесспорно, однако меньше не значит мало, перловики весьма востребованы
                                                                      • –2
                                                                        > меньше не значит мало, перловики весьма востребованы

                                                                        Я использую для сравнения данные вот этого сайта www.itjobswatch.co.uk/ они достаточно репрезентативны. Вариации с поправкой на локальный рынок возможны, но порядок величин сохраняется.

                                                                        Matching Job Ads (% of Permanent IT Job Ads Sampled) Last 3 Months

                                                                        C# 20104 (17.44 %)
                                                                        Java 17245 (14.96 %)

                                                                        C++ 6940 (6.02 %)
                                                                        C 4008 (3.48 %)
                                                                        Perl 3450 (2.99 %)
                                                                        Python 3333 (2.89 %)
                                                                        Ruby 1984 (1.72 %)

                                                                        COBOL 142 (0.12 %)
                                                                        Fortran 71 (0.06 %)

                                                                        ну так вот, меньше 3% от общего числа вакансий — это не «весьма», это «всего лишь»

                                                                        Кроме того, стоит учесть тенденцию. Сколько вы проработаете на текущем проекте?
                                                                        Один-два года? три-пять лет? Рискну предположить, за это время спрос на перловиков станет еще меньше. Не исключено, что к тому времени, как Вы станете перл-гуру, Вы будете востребованы примерно в той же мере, как сейчас програмисты на коболе и фортране (или шесть сотых процента — тоже не значит мало?)
                                                              • +1
                                                                > Ирония в том, что этот же принцип оказался недостатком для масштабных enterprise-проектов

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

                                                                > По опыту знаю, что наследие в таких случаях практически не дает возможности внести изменение в дизайн и архитектуру

                                                                как раз у нас сейчас и идут внесения изменений в архитектуру, причём достаточно активно меняется старая, и делается прототип новой
                                                                • 0
                                                                  > как раз у нас сейчас и идут внесения изменений в архитектуру
                                                                  бывает. повезло значит

                                                                  > не зная ооп и в джаве можно монстров наворотить
                                                                  не зная ооп — его лучше осваивать на примере явы, чем перла
                                                                  • +1
                                                                    Почему джава? Может питон?
                                                                    Не особо важно на каком примере, главно понимать концепцию — она везде одинаковая
                                                                    • 0
                                                                      концепция конструктора в перле не одинаковая по сравнению с плюсами, явой
                                                                      и соглашусь — для начала даже питон подойдет лучше чем перл
                                                                      • 0
                                                                        > концепция конструктора в перле не одинаковая по сравнению с плюсами, явой

                                                                        и в чём же концептуальная разница?
                                                                        • 0
                                                                          1. в том, что нужно делать bless
                                                                          2. в том, что название конструктора не совпадает с названием класса
                                                                          • +1
                                                                            А концепция конструктора в том что он называется как класс или в том что он порождает объект?
                                                                            • 0
                                                                              изучение языка — это не только принятие к сведению абстрактных концепций, но и применение конкретных форм выражения этих концепций. У перла форма выражения концепций ООП отличается от других языков и это не способствует их освоению после перла.
                                                                              • 0
                                                                                Возможно, но для этого нужно перл изучать до паскаля, си и т.п., что думаю в реальности бывает не так часто
                                                                          • 0
                                                                            Я бы пошел дальше и сказал бы, что в перле конструктор как концепция отсутствует. Вместо конструктора есть устное соглашение, мол давайте будем делать везде метод new (кстати говоря, далеко не все этому соглашению следуют).
                                                                            bless может вызываться из любого метода, но самое главное, что он может и не вызываться вовсе. Можно создать класс без конструктора. Однако, все равно можно будет создать объект такого класса.

                                                                            Да что я вам рассказываю? worldmind, вы же пишете на перле. Неужели вам такие вещи неочевидны?

                                                                            ЗЫ: я, если что, Perl люблю и зарабатываю им на жизнь. Просто еще я знаю, что в перле много чего «не как у людей». Это надо принять и начать получать от этого удовольствие.
                                                                            • 0
                                                                              Я немного о другом, внешний вид (форма) ООП в перле иной, однако все концепции ООП (инкапсуляция, наследование, полиморфизм — содержание) вполне реализуются (причём как всегда различными методами), конечно для того чтобы правильно их реализовать нужно понимать эти концепции, но понимание этих концепций требуется в любом языке, не зная ООП можно и в джаве что угодно натворить.
                                                                              Форма иная, содержание то же, понимание нужно в независимости от формы, так в чём проблема?
                                                              • +3
                                                                unobtrusive&fast oop — Moo
                                                                event loops & parallel programming — AE (AnyEvent), Coro + EV, fork, threads
                                                                number crunching — PDL
                                                                c/c++ extenstion — Inline::C, Inline::CPP
                                                                gui — Prima, Wx, Gtk2
                                                                video&graphics: OpenGL, GStreamer, SDL
                                                                images — Imager, ImageMagick
                                                                • 0
                                                                  Как много интересного, спасибо. За всем не угнаться. Про Prima я только сегодня узнал, к примеру.
                                                                  • 0
                                                                    добавил ссылку на коммент
                                                                  • 0
                                                                    есть еще HTML::Mason, mod_perl
                                                                    • 0
                                                                      спасибо за статью

                                                                      я бы в список внес еще PSGI + Plack, полезные штуки, особенно если цель собрать свой кастомный веб-фреймоврк, ну и сюда же пачку различных веб-серверов и коннекторов к ним (и не только к ним), которые можно использовать под различные задачи
                                                                      • 0
                                                                        Test::More на русском языке
                                                                        • +1
                                                                          прочитал и утёр скупую слезу — насколько близкий путь… жаль, плюсануть не хватает кармы пока.

                                                                          вот еще зря не упомянули два важных момента:

                                                                          1. быстрая компиляция сборка в исполняемый файл при помощи Perl packager. здесь есть краткая, но весьма доступная для понимания статья на эту тему. зачем нужно — часто случается, что готовый скрипт запускается на системе, где Perl отсутствует, либо не той версии/сборки. PP создает ZIP архив с загрузчиком и всем необходимым окружением.
                                                                          2. эффективная защита кода. опять же из соображений передачи в третьи, и не всегда чистые, руки. не обфускация, вроде Acme::Bleach, а именно защита. Filter::Crypto — мой выбор. я знаю, что распаковать реально, но про автоматические средства лично мне неизвестно, а декриптовка Filter::Crypto вручную — удел узкого круга специалистов (желающие могут потренироваться хотя бы на демке FOP2)
                                                                          • 0
                                                                            В юниксоподобных ОС (как минимум, в линуксе и FreeBSD) вместо perldoc perlSOME_TOPIC можно писать более короткое man perlSOME_TOPIC

                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.