LINUX.ORG.RU
ФорумJob

Вакансия: Разработчик perl в Москве

 ,


0

1

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

Требования:
1.Высшее образование (обязательно).
2.Perl (fast CGI), Postgresql, HTML, XML, Nginx. Разработка с использованием систем контроля версий (Subvertion/Mercurial)
3.Приветствуются: знание сетевых технологий и навыки их интеграции, навыки администрирования GNU/Linuх, FreeBSD.
4.Приветствуется знание PHP 5 (ООП), JavaScript, JQuery, Ajax, Yii, SMPP, WML, WAP, NoSQL(Redis, Memcached)
5.Приветствуется умение проектировать высоконагруженные системы.

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

Условия:
1.Интересная работа в молодом, стремительно развивающемся коллективе,
2.З.п. белая от 70000 руб. (на испытательный срок), повышение по итогам достижения kpi
3.Оплата сотовой связи
4.Спорт и другие развлечения

Резюме можно слать на email: apodolin на vasmedia точка ru

2.Perl (fast CGI)

1.Интересная работа в молодом, стремительно развивающемся коллективе,

по-моему эти вещи несовместимы. Нужно быть ярым фанатиком, чтобы продолжать писать на Perl.

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

Знаете, надоели уже такие обобщения. Если вы знаете только PHP или Ruby, не надо пишущих на Perl объявлять стариками или фанатиками. Это выглядит, как минимум, глупо.

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

реч о том что perl легаси и поэтому знать perl очень полезно для своего бюджета.

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

Я писал на Perl лет 6 назад. В 2005 году кроме этого набора регэкспов и php особо выбора не было, а сейчас я даже не представляю как можно при таком разнообразии всяких Pyramid, RoR, Node.js использовать Perl. Это явно фанатизм или неумение учиться. Ну или то и другое вместе.

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

Я молод душой и телом. Я пишу на Perl.

Галоперидолу пациенту. Следующий.

xpahos ★★★★★ ()

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

P.S. сам пишу на перле полтора года, правда не для веб

marvin_yorke ★★★ ()

Требование высшего образования обоснуйте, пожалуйста.

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

Высшее образование - стандартное требование при приеме в относительно крупную компанию.

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

CPAN? mod_perl? PL/perl? Таких причин много.

1987 - н.в. Язык зрелый.

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

CPAN? mod_perl? PL/perl? Таких причин много.

не совсем понял при чем тут CPAN, mod_perl и PL/Perl. Единственный момент с которым согласен - perl_module для nginx. Делал кое что на нем, но это только из-за того, что Игорь выбрал Perl, можно так же реализовать python итд. PL/Perl свободно можно заменить на PL/Python, PgSQL его поддерживает.

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

CPAN это огромная экономия человеко-часов. Ни у одного другого скриптового языка нет библиотеки сопоставимой по объемам. Централизованное, хорошо проиндексированное хранилище программных решений позволяет perl разрабочику разрабатывать только новый код, код который еще никто не писал. Ибо если что-то было качественно сделано, то она обязательно есть в CPAN.

mod_perl, PL/Perl и пр. это намек, что perl скрипты стандартно поддерживается практически везде. В крупных проектах под них специально делается оптимизация.

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

Поэтому к черту новые языки, пусть они достигнут совершенолетия (18 лет) прежде, чем я пущу их в свой мозг.

Для меня: Perl, PostgreSQL, C++, Javascript — это инструменты в которых я целенаправленно прокачиваю свои знания (в указанном порядке). Основную массу задач я решаю с их помощью. Это не значит, что я другими не пользуюсь, но все сложное и большое я решать именно этими, если только нет ОЧЕНЬ веских причин использовать что-то другое.

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

CPAN это огромная экономия человеко-часов. Ни у одного другого скриптового языка нет библиотеки сопоставимой по объемам. Централизованное, хорошо проиндексированное хранилище программных решений позволяет perl разрабочику разрабатывать только новый код, код который еще никто не писал. Ибо если что-то было качественно сделано, то она обязательно есть в CPAN.

я пока не находил пакетов, которых не было бы для python, а вот наоборот уверен что есть такие вещи.

mod_perl, PL/Perl и пр. это намек, что perl скрипты стандартно поддерживается практически везде. В крупных проектах под них специально делается оптимизация.

mod_python, PL/Python и пр. это намек, что python скрипты стандартно поддерживается практически везде. В крупных проектах под них специально делается оптимизация.

Если вы знаете хорошо python, то вы сможете работать с активными базами данных, с web-серверами, писать сложные анализаторы текста, работать с оборудованием на уровне портов и кадров и многое другое. И вам не надо вникать в тонкости 10 других языков. А если эти языки еще и молодые, то ввиду того, что фаза активной разработки не пройдена, то спецификации будут меняться, и вы должны будете за этим следить и обеспечивать обратную совместимость разработок.

Поэтому к черту новые языки, пусть они достигнут совершенолетия (18 лет) прежде, чем я пущу их в свой мозг.

умрут, сгниют и потом можно будет писать. Новую мажорную ветку не могут реализовать 10 лет. Работа с объектами, декораторами, иксепшонами как была через костыли, так и осталась. Я как-то не готов ждать 18 лет, когда в языке реализуют нормальные иксепшоны на уровне языка.

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

Работа с объектами, декораторами, иксепшонами как была через костыли, так и осталась.

«костыльность» заключается в том, что это сделано не как в петоне?

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

чем они сейчас не нормальные и почему на уровне языка лучше?

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

«костыльность» заключается в том, что это сделано не как в петоне?

т.е. тебя устраивает как реализованы классы в Perl?

чем они сейчас не нормальные и почему на уровне языка лучше?

тем, что эти костыли не дают возможности получить полную информацию о том что произошло. Сделай open несуществующего файла в Perl и Python и попробуй эксепшонами отследить что произошло.

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

т.е. тебя устраивает как реализованы классы в Perl?

В какой из реализаций? Мне и на bless'ах нравится. ПРавда, есть своя реализация.

Сделай open несуществующего файла в Perl и Python и попробуй эксепшонами отследить что произошло.

eval { open F, $fileName or die };
say «Can't open $fileName ($@)» if $@;

Или Try::Tiny, по вкусу. Ещё что-то?

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

eval { open F, $fileName or die };
say «Can't open $fileName ($@)» if $@;

хороший регэкспс, но это не экспешен. Как открыть файл и в зависимости от причины, по которой его невозможно открыть производить дальнейшие действия?

что-то вроде try: blahblah except OSError as e: blahblah или IOError.

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

Таки где вы увидели регулярку?

что-то вроде try: blahblah except OSError as e: blahblah или IOError.

use TryCatch;

try
{
    open F, $fileName or die IOError->new(code => 200);
    # do smth
}
catch (IOError $e where { $_->code > 100 } )
{
    # do smth
}
helios ★★★★★ ()
Ответ на: комментарий от xpahos

т.е. тебя устраивает как реализованы классы в Perl?

Так что с ними не так? Классы как классы.

тем, что эти костыли не дают возможности получить полную информацию о том что произошло.

Да ну? А мужики то не знали.

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

> open F, $fileName or die IOError->new(code => 200);

ты так будешь писать везде? :)

        try:
            url = urllib2.urlopen(url)
            code = url.getcode()
        except (urllib2.URLError, httplib.InvalidURL, httplib.BadStatusLine, ValueError):
            return False

как с чем-то подобным быть?

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

как-то так

eval {
  wtf code
};

if ($@ && ref($@) eq 'WTF::Exception1' || ref($@) eq 'WTF::Exception2'
    ref($@) eq 'WTF::Exception2' || ref($@) eq 'WTF::ValueError')
{
   return failes;
}

Если exception'ы наследуются друг от друга и важно это учесть, то поможет UNIVERSAL::isa

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

я ж говорю, отличный набор регэкспов, но как сделать исключения? Тут нельзя перехватить эксепшон, который не был прописан тобой.

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

я ж говорю, отличный набор регэкспов, но как сделать исключения?

Где ты тут увидел регекспы?

Тут нельзя перехватить эксепшон, который не был прописан тобой.

А мужики то не знали.

if ($@ && ref($@) eq 'WTF::Exception1' || ref($@) eq 'WTF::Exception2'
    ref($@) eq 'WTF::Exception2' || ref($@) eq 'WTF::ValueError')
{
   return false;
}
elsif ($@) {
  // unknown exception here
  return false;
}

В общем, по делу претензии будут или так и будешь продолжать позориться своей неграмотностью?

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

В общем, по делу претензии будут или так и будешь продолжать позориться своей неграмотностью?

ну если это ты считаешь нормальной реализацией обработки исключений, то претензий нет. Я лучше продолжу пользоваться нормальным языком, в котором не нужно вызывать eval для того, чтобы поймать исключение и городить кучу костылей из if'ов :)

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

ну если это ты считаешь нормальной реализацией обработки исключений, то претензий нет.

Ты не смог объяснить в чем ненормальность.

Я лучше продолжу пользоваться нормальным языком, в котором не нужно вызывать eval для того, чтобы поймать исключение и городить кучу костылей из if'ов :)

Что в этом плохого и почему куча if'ов это костыли, а куча except'ов это не костыли?

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

Reset ★★★★★ ()

О, перл ещё кто-то использует для новых проектов, надо же. Некроманты прям, колдуны вуду.

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

Кстати в перле в отличие от сраного питона есть не только убогий строковый eval, но и полноценный eval на вход которому подается корректное перловое выражение

На чёрта он сдался этот eval? ЕМНИП основной юзкейс для него в перле - отлов исключений (perl-way, да).

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

Питон лучше перла только тем, что он в моде и _сейчас_ проще найти программистов под новый проект именно на питоне, а не на перле. Никаких _технических_ преимуществ у питона нет.

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

Ты не смог объяснить в чем ненормальность.

Что в этом плохого и почему куча if'ов это костыли, а куча except'ов это не костыли?

Я могу забыть обработать исключение, но я никогда не забуду его создать. Мне не нужно будет выяснять из-за чего не работает кусок кода, т.к. всегда есть исключения и я могу ими нормально управлять, могу создавать свои и уже в самом исключении закладывать часть логики. Весь мой код - 4 строчки и они все понятны. Любой человек, который знает синтаксис python открывает код и понимает что делает код, ему не нужно разбираться где ты там создал исключение, как ты его создал и какие параметры были переданы. Что будет с твоим кодом после 3х лет? Ты точно сможешь открыть его и понять что ты обрабатывал?

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

Само по себе использование eval - моветон. Как минимум это не безопасно. В функциональных языках может быть это и оправдано, но практических задач на LISP я никогда не решал и поэтому не знаю. Будем мериться у кого однострочник будет более запутанный?

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

Я могу забыть обработать исключение, но я никогда не забуду его создать. Мне не нужно будет выяснять из-за чего не работает кусок кода, т.к. всегда есть исключения и я могу ими нормально управлять, могу создавать свои и уже в самом исключении закладывать часть логики.

Ты не поверишь, но в перле всё точно также.

Любой человек, который знает синтаксис python открывает код и понимает что делает код, ему не нужно разбираться где ты там создал исключение, как ты его создал и какие параметры были переданы. Что будет с твоим кодом после 3х лет? Ты точно сможешь открыть его и понять что ты обрабатывал?

Ты не поверишь, но любой человек, который знает синтаксис perl откроет код через 3 года и тоже поймет что это всё значит. Да в перле некоторые вещи сделаны не так как в «традиционных» языках, но ничего плохого в этом нет и к этим нюансам привыкаешь через день работы с кодом.

Само по себе использование eval - моветон. Как минимум это не безопасно.

Подробнее можно?

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

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

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

Ты не поверишь, но в перле всё точно также.

что-то я не заметил. Я вижу, что у тебя вызывается eval и только в нем можно поймать исключение. В python я могу это делать в любом месте.

Ты не поверишь, но любой человек, который знает синтаксис perl откроет код через 3 года и тоже поймет что это всё значит. Да в перле некоторые вещи сделаны не так как в «традиционных» языках, но ничего плохого в этом нет и к этим нюансам привыкаешь через день работы с кодом.

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

Подробнее можно?

Изначально это не безопасно. Вот тебе прям ссылка на вики http://en.wikipedia.org/wiki/Eval#Security_risks

Eval ухудшает читаемость кода. Тут я думаю разъяснения не нужны.

Eval затрудняет дебаггинг. Ну вот я не представляю как ты будешь вызывать что-то подобное pdb в своем eval и какие результаты это принесет.

Может еще расскажешь мне про классы в Perl? Как они создаются, про передачу параметров и проверку их же. Про self в классах. Может быть про тонну кода, который нужно написать для наследования одного только класса. Может быть поговорим о том, что в Perl можно накосячить даже в Assert, просто забыв добавить пару ковычек. Ну и как дела у Perl обстоят с list, dict, итераторами? Как разворачивать списки. Даже просто аналог args,kwargs для Perl в классах/методах есть?

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

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

Если тебе не нужно, это не значит что всем не нужно. В python есть байткод, но PyPy работает быстрее и мы его используем. Его используют как минимум те, с кем я переодически общаюсь в рассылке для обработки данных.

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

Ты не поверишь, но в перле всё точно также.

Да плохо всё в перле с исключениями. Есть несколько костыльных реализаций в CPAN + самопальные велосипеды + много модулей, где вообще исключения не используют. Такой зоопарк создаёт гемор на ровном месте. То же самое с объектными системами - каждый изголяется по-своему. Уж лучше бы совсем не было этих объектов разномастных. Хотя мне одно время нравилось на тикле свою объектную систему велосипедить. Вот уж где раздолье. А на перле уныло как то. Что там нынче в моде: Moose, InsideOut? Лучше бы было простенькое ОО из коробки с удобным синтаксисом, глядишь перл не слил бы так позорно web-нишу пых-пыху.

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

что-то я не заметил. Я вижу, что у тебя вызывается eval и только в нем можно поймать исключение. В python я могу это делать в любом месте.

Ты не поверишь, но в перле eval точно также можно вызвать в любом месте как и try/except в питоне.

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

Ага, опыта месяц от силы.

Изначально это не безопасно. Вот тебе прям ссылка на вики http://en.wikipedia.org/wiki/Eval#Security_risks

Верно только для строкового eval'а, а мы сейчас говорим не о нем.

Eval ухудшает читаемость кода. Тут я думаю разъяснения не нужны.

Каким образом?

Ну вот я не представляю как ты будешь вызывать что-то подобное pdb в своем eval и какие результаты это принесет.

А в чем проблема?

Может быть про тонну кода, который нужно написать для наследования одного только класса.

Где тут тонна кода?

use base qw(Base)

Может еще расскажешь мне про классы в Perl? Как они создаются, про передачу параметров и проверку их же.

Создаются не так как в питоне, но плохого ничего в этом не вижу.

Ну и как дела у Perl обстоят с list, dict, итераторами?

Хорошо обстоят.

Как разворачивать списки.

Всмысле?

Даже просто аналог args,kwargs для Perl в классах/методах есть?

В перле принято передавать ссылки на хеши.

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

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

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

Как у этого pypy обстоят дела с подключением модулей, написанных на Си ?

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

Ага, опыта месяц от силы.

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

Где тут тонна кода?

package Boss;
use Employee;        # :-)
@ISA = qw(Employee);  

просто пример из документации.

import bla

class new_bla(bla.bla):
    pass

есть разница?

В перле принято передавать ссылки на хеши.

и к спискам. http://www.python.org/dev/peps/pep-3102/

По поводу eval и чтения кода. Просто посмотри на мои примеры и на свои. Что проще читать и дебажить? :)

А давай про декораторы теперь еще? :)

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

Как у этого pypy обстоят дела с подключением модулей, написанных на Си ?

Эммм, ты на wiki зайди и почитай для чего нужен pypy и что там с модулями на Си :)

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

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

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

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

есть разница?

Нет

По поводу eval и чтения кода. Просто посмотри на мои примеры и на свои. Что проще читать и дебажить? :)

Однохренственно.

А давай про декораторы теперь еще? :)

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

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

Я знаю что это jit для питона. Так как там с модулями на Си? Да или нет? swig мне сможет сгенерить модуль для pypy ? Да или нет? Мутные доки не хочу вкуривать, а особенно в субботу в 0:58.

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

просто пример из документации. есть разница?

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

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

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

опять костыли.

http://lemonnier.se/erwan/blog/item/45/ http://lemonnier.se/erwan/blog/item/47/

Of course, Python::Decorator is just a proof of concept. It shows that compile-time function composition (aka macros) can be done in Perl, at least in some restricted way. If such a feature makes it into the Perl core, it will have to have at least a more perlish syntax.

Still, Python::Decorator is fun for at least one more reason: it uses PPI, the Perl parsing module, to analyze and manipulate the source code of Perl programs. Now, that is cool and a lot like macros :)

это сильный аргумент, да :)

Я знаю что это jit для питона. Так как там с модулями на Си? Да или нет? swig мне сможет сгенерить модуль для pypy ? Да или нет? Мутные доки не хочу вкуривать, а особенно в субботу в 0:58.

Я тебя спросил про подобный JIT компилятор для Perl, ты мне про какие-то модули на Си. C API из CPython поддерживается, но рекомендовано для использования под нагрузкой. Про swig можешь спроси у разработчиков, если тебя это интересует.

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

опять костыли.

И опять потому что не встроено в язык, а реализовано библиотекой? Да, «сильный» аргумент, ничего не скажешь.

Я тебя спросил про подобный JIT компилятор для Perl, ты мне про какие-то модули на Си. C API из CPython поддерживается, но рекомендовано для использования под нагрузкой. Про swig можешь спроси у разработчиков, если тебя это интересует.

то есть под нагрузкой только python + модули на си, а pypy для «под нагрузкой» не годится? а на кой оно тогда?

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

И опять потому что не встроено в язык, а реализовано библиотекой? Да, «сильный» аргумент, ничего не скажешь.

там чувак сам написал _не_ _для_ _продакшена_ :)

то есть под нагрузкой только python + модули на си, а pypy для «под нагрузкой» не годится? а на кой оно тогда?

CPython модули работают медленнее из-за эмуляции. Мы не используем CPython модулей, поэтому проблем не возникает. Это тоже самое, что и с декораторами в Perl, но только это не влияет работу скриптов. Вообще почитай про ctypes.

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

С одной стороны очевидное непонимание основ реализации ООП в Perl, постоянное упоминанеие каких-то регекспов, а с другой - явные eval'ы, си. Создается ощущение, что ни один из вас на перле не работает.

level1 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.