> меньше не значит мало, перловики весьма востребованы
Я использую для сравнения данные вот этого сайта 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.
Перл, с его концепцией There Is More Than One Way to Do IT — оказался подходящим полем для экспериментов, отработаные в нем концепции перешли в другие языки. Ирония в том, что этот же принцип оказался недостатком для масштабных enterprise-проектов, где, в контексте удобства поддержки кода, многообразие выразительных форм означает увеличение вероятности ошибки и затруднение инспекци кода. И именно из-за трудности поддержки большого количества кода в долгосрочной перспективе — в настоящее время перлу предпочитают сишарп и яву.
2.
Текущие предложения для перловиков — это, как правило подддержка и доработка уже существующих систем. По опыту знаю, что наследие в таких случаях практически не дает возможности внести изменение в дизайн и архитектуру, вместо этого приходится добавлять все новые и новые костыли и обходные пути для поддержки работоспособности системы. А добавление костылей — плохой контекст для обучения новичков.
3.
Спрос на перл кодеров на порядки меньше спроса на те же сишарпы, явы и дотнеты — и это самый очевидный аргумент в пользу того, что начинать с перла не стоит. Это конечно не аргумент для тех, кому не хочется быть штампованным выпускников вуза и заниматься потребительством, где тепло и удобно. Но если вы хотите не только обладать эзотеричесими знаниями о редко используемых языках программирования, но и быть востребованными на рынке — перл вам имеет смысл осваивать совсем не в первую очередь.
в перловых проектах, где файлов больше сотни и используется OOP — IDE необходим
навигация по коду удобнее всего была в sourceinsight, дебагер — приятнее было использовать в eclipse
notepad++ — предоставлял только необходимый минимум для написания скриптов (считаю, что посветка синтаксиса не роскошь, а необходимость)
vim — имел смысл, только если ничего иного использовать нельзя (небольшие коррекции кода на удаленном сервере, где вообще ничего нет и доступ только через ssh)
> А есть ли действительная польза от code review?
> это сталкивание двух… взглядов на код, чаще всего только тормозящий разработку.
примерно то же можно сказать о тестировании
к слову о толсто-зеленом образе
известен очень эффективный способ обойтись без код-ревью, тестирования, как отдельной активности,
и без qa/тестировщиков как таковых: просто начать штрафовать дэвов за баги, отданые заказчику в релизах
после внедрения такой практики обычно отношение и к код-ревью, и к тестированию может поменяться
Слово «тестер» могут исправлять вовсе не потому, что обижаются,
а если например в компании (обычно характерно для больших >1000 человек бодишопов)
принята внутренняя градация квалификации тестеров и где QA-engineer квалифицируется и соответственно оплачивается выше тестера
Тот факт, что персонаж, занимающий позицию QA-engineer, может не знать что такое вообще qa и по факту заниматься тестированием — никого не волнует
Но если вы скажите такому перцу, что он тестер — он вас поправит
потому, что в терминах компании, где он работает, он просто называется по-другому
В таком контексте объяснять человеку, что у него позиция называется неправильно — т.к занимается он вовсе не внедрением процессов обеспечения качества, а контролем качества — причем в ухком контексте — уже как-то и глупо
Товарищ мой стебал меня, говоря:
— как ты сказал, кем ты там работаешь?.. амперметром?.. а ну да — тастером
звучит солидней — есть такое
хотя тут рекрутеры тоже постарались — вакансии с заголовком qa engineer через одну по факту требуют скилов мануальных мышкотыкателей и\или админов
в текущей практике QA engineer и software tester стали почему-то синонимами
хотя смешивать тестирование с QA — обеспечением качества — не совсем правильно
в задачи QA включаются например такие далекие от тестирования процессы для обеспечения качества:
— внедрение систем continuous integration
— внедрение систем для code review
— проведение статического анализа кода
— внедрение систем проверки лицензионной чистоты кода
— build and release активности
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.
Перл, с его концепцией There Is More Than One Way to Do IT — оказался подходящим полем для экспериментов, отработаные в нем концепции перешли в другие языки. Ирония в том, что этот же принцип оказался недостатком для масштабных enterprise-проектов, где, в контексте удобства поддержки кода, многообразие выразительных форм означает увеличение вероятности ошибки и затруднение инспекци кода. И именно из-за трудности поддержки большого количества кода в долгосрочной перспективе — в настоящее время перлу предпочитают сишарп и яву.
2.
Текущие предложения для перловиков — это, как правило подддержка и доработка уже существующих систем. По опыту знаю, что наследие в таких случаях практически не дает возможности внести изменение в дизайн и архитектуру, вместо этого приходится добавлять все новые и новые костыли и обходные пути для поддержки работоспособности системы. А добавление костылей — плохой контекст для обучения новичков.
3.
Спрос на перл кодеров на порядки меньше спроса на те же сишарпы, явы и дотнеты — и это самый очевидный аргумент в пользу того, что начинать с перла не стоит. Это конечно не аргумент для тех, кому не хочется быть штампованным выпускников вуза и заниматься потребительством, где тепло и удобно. Но если вы хотите не только обладать эзотеричесими знаниями о редко используемых языках программирования, но и быть востребованными на рынке — перл вам имеет смысл осваивать совсем не в первую очередь.
Но погодите, вот сейчас подтянутся убежденные сторонники парсинга логов, и объяснят, почему отладка с брейкпоинтами — это не труЪ.
в перловых проектах, где файлов больше сотни и используется OOP — IDE необходим
навигация по коду удобнее всего была в sourceinsight, дебагер — приятнее было использовать в eclipse
notepad++ — предоставлял только необходимый минимум для написания скриптов (считаю, что посветка синтаксиса не роскошь, а необходимость)
vim — имел смысл, только если ничего иного использовать нельзя (небольшие коррекции кода на удаленном сервере, где вообще ничего нет и доступ только через ssh)
сомнительный совет, учитывая задекларированные цели
с тем же успехом можно посоветовать использовать монохромные АЦПУ дисплеи 25x80 вместо fullHD мониторов
ее скорее можно считать справочником, чем учебником.
годная книга по перлу: Damian Conway — Perl Best Practices
поправьте, если ошибусь: селениум как раз НЕ умеет работать с диалогом загрузки файлов
легко находится ищется по ключевым «advanced bash scripting guide»
> это сталкивание двух… взглядов на код, чаще всего только тормозящий разработку.
примерно то же можно сказать о тестировании
к слову о толсто-зеленом образе
известен очень эффективный способ обойтись без код-ревью, тестирования, как отдельной активности,
и без qa/тестировщиков как таковых: просто начать штрафовать дэвов за баги, отданые заказчику в релизах
после внедрения такой практики обычно отношение и к код-ревью, и к тестированию может поменяться
Слово «тестер» могут исправлять вовсе не потому, что обижаются,
а если например в компании (обычно характерно для больших >1000 человек бодишопов)
принята внутренняя градация квалификации тестеров и где QA-engineer квалифицируется и соответственно оплачивается выше тестера
Тот факт, что персонаж, занимающий позицию QA-engineer, может не знать что такое вообще qa и по факту заниматься тестированием — никого не волнует
Но если вы скажите такому перцу, что он тестер — он вас поправит
потому, что в терминах компании, где он работает, он просто называется по-другому
В таком контексте объяснять человеку, что у него позиция называется неправильно — т.к занимается он вовсе не внедрением процессов обеспечения качества, а контролем качества — причем в ухком контексте — уже как-то и глупо
Товарищ мой стебал меня, говоря:
— как ты сказал, кем ты там работаешь?.. амперметром?.. а ну да — тастером
хотя тут рекрутеры тоже постарались — вакансии с заголовком qa engineer через одну по факту требуют скилов мануальных мышкотыкателей и\или админов
хотя смешивать тестирование с QA — обеспечением качества — не совсем правильно
в задачи QA включаются например такие далекие от тестирования
процессы для обеспечения качества:
— внедрение систем continuous integration
— внедрение систем для code review
— проведение статического анализа кода
— внедрение систем проверки лицензионной чистоты кода
— build and release активности
хочется подробностей про L2 over ssh и рецепт wake-up-on-lan через ssh
если бы не знал, о чем речь — я бы точно не понял
чем, тот который ходит отличается от того, которым ходят — и кто из них где