In fact there is already evidence in recent studies of second language learners
that a combined approach is superior to incidental vocabulary learning alone.
Zimmerman (1994), for example, found that 3 hours a week of explicit vocabulary
instruction plus some self-selected reading were more effective than reading
alone. Paribakht and Wesche (1997) also found that reading plus explicit
instruction led to superior gains over a period of three months.
Huckin and Coady (1999, pp.189-190) warned us that “guessing from context has
serious limitations. It is still seen as an important part of
vocabulary-building, especially among advanced learners, but it requires a
great deal of prior training in basic vocabulary, word recognition,
metacognition, and subject matter”. Lastly, the most recent tendency to see
incidental learning as involving different levels of task involvement (Laufer &
Hulstijn, 2001) also suggests a need to combine incidental and intentional
learning as a vocabulary learning strategy. Similar views are shared by Nation
(2001) and Schmitt (2000), two new books on vocabulary acquisition.
Not surprisingly, a considerable amount of earlier work on foreign language
vocabulary learning followed the psychological paradigm in memory research. And
almost all studies focusing on the pacing of repetition and recall of word
lists arrived at the same conclusion: that forgetting mostly occurs immediately
after initial encounter, and that the rate of forgetting slows down afterwards.
Anderson and Jordan (1928) examined the number of words that could be recalled
immediately after initial learning, 1 week, 3 weeks, and 8 weeks thereafter and
discovered a learning rate of 66%, 48%, 39%, and 37% respectively. Similar
results can be found in Seibert (1927, 1930). It was therefore suggested that
students should start repeating newly learned words immediately after the first
encounter. Spaced recall and repetition should follow afterwards at longer
intervals.
> Из всех известных мне идиотских советов эти два самые вредные.
> Друзья, слова в отрыве от контекста не стоят ни копейки. И никаких исключений.
> Учить слова нужно только с контекстом, и ассоциировать тоже — только с контекстом.
> Для достижения прогресса делайте то, что вам нравится: читайте, смотрите, слушайте, говорите, говорите сами с собой, думайте. На изучаемом языке.
Если у изучающего словарного запаса не хватает для понимания хотя бы базового смысла, то ему ничто не будет нравится — будет сплошная фрустрация. Фрустрация же и обучение есть вещи взаимоисключающие.
> Но не в ущерб настроению. Если смысл кажется понятным и без одного непонятного слова, его можно пропустить и продолжить поглощать поток информации не прерываясь. В ближайшее время оно всё равно всплывет не раз, и имея в памяти уже несколько вариантов использования можно либо догадаться о значении самому (что полезнее всего), либо открыть словарь, подсмотреть, переосмыслить, и запомнить.
Угадывание смысла слов из контекста называется 'incidental vocabulary learning' и является естественным способом усвоения родного языка. Для изучения слов иностранного языка этот способ менее эффективен чем целенаправленное разучивание слов.
Во-первых, нужно уже иметь базовый словарный запас чтобы понимать основной смысл. Во-вторых, чтобы слова действительно запоминались нужно их повторять каждый день, сооветственно контакт с языком должен быть ежедневным. В-третьих, поскольку запоминание зависит о частоты повторения слов, то запоминаться будут те слова, которые чаще употребляются, а редкие слова, особенно всякие прилагательные которые общего смысла не меняют так и будут пропускаться и нести весьма размытый смысл. В-четвертых, если заниматься только тем, что интересно, то словарный запас получается однобоким и возникает типичная проблема — люди читают тех. лит. свободно но пасуют на простейших бытовых темах.
В свете вышеизложенного не стоит ограничиваться только чтением. Чтобы пополнение словарного запаса было наиболее эффективным надо им заниматься целенаправленно и каждое незнакомое слово выписывать и регулярно повторять, лучше всего с помощью именно flashcards используя spaced repetition method (список соответствующего софта можно найти в wikipedia). Если словарный запас совсем минимальный, то стоит начать с какого-нибудь учебника, например Cambridge University «English Vocabulary in Use». Если словарный запас уже есть на уровне, то тогда рекомендую в flashcard записывать анлийское толкование вместо русского перевода, например из Cambridge Learner's Dictionary (доступен online).
> Пользуясь этой простой методикой я поднялся с уровня «не понимаю ни слова» до уровня С1 (согласно CEFR выше только C2 — Mastery or proficiency) и подтвердил этот уровень сдачей кембриджского экзамена.
За полтора года.
Я не знаю какому уровню словарного запаса C1 соответствует, но с помощью соответствующего софта для flashcard выучить пару тысяч слов тратя где-то 10-15 минут в день можно примерно за полгода.
Что-то мне думается что результаты с testyourvocab.com не соответствуют пороговыем значениям словарного запаса перечисляемым в начале статьи. Чтобы их сравнивать результаты надо делить где-то втрое-четверо. Т.е. результат по тесту в 5000-6000 слов как раз должен соответствовать традиционном понимаемому базовому английскому словарю который дается в школе/институте и составляет 1500-2000 слов.
Не надо считать строчки кода — вы идете по граблям, которые остальное человечество прошло лет 30 назад. Основные недостатки использования этой метрики в качестве основы для планирования разбирал еще Ф.Брукс в своей классической книге The Mythical Man-Month вышедшей в 1975-м году. Эти недостатки также перечислены и на упомянутой странице из википедии.
Самый главный недостаток — это неточность данной метрики. Например, запись оценки в виде «7500 строк для задачи b» предполагает, что точность составляет ±100 строк, тогда как в реальности точность этой оценки примерно ±3500, т.е. итоговый результат может отличаться в два-три раза минимум, а в крайних случаях — на порядок. Производительность разных программистов (или одного программиста на разных задачах) в строках кода также отличается в среднем в 2-3 раза и до 10 раз в крайних случаях и зависит в том числе и от объема кода и от количества других программистов участвующих в проекте.
Не думаю что нужно перечислять остальные недостатки — этого уже достаточно чтобы понять, что данную метрику имеет смысл использовать только для оценки порядка объема некоего проекта, например — «проект в 15000 строк является средним по объему и средним программистом будет выполнен в срок от 3 до 9 месяцев».
>По большому же счету я затрудняюсь называть чисто косметический rename function — рефакторингом.
Об чем и речь. Остается лишь find/replace.
Я не очень улавливаю о чем собственно у вас речь. У меня складывается впечатление что ваш мессадж в том, что рефакторинг с применением некошерного find/replace — это и не рефакторинг вовсе?
>Кучу геморроя вы поймаете в любом языке как только попробуете поменять какой-нибудь низкоуровневый API приложения и сделать следующий шаг после применения 'Add Argument' к методу
В IDEA я по крайней мере быстро выявлю все проблемные места.
Быстро — не выявите, если проблемными являются, в зависимости от контекста, только 10 из 100 мест, где используется данный method.
В популярных IDE для Perl (коих две) вроде бы нет даже примитивного «find usage»?
grep/ack прекрасно работает в качестве «find usage».
Именно, других вариантов ведь нет? Либо завязывать приложение на mod_perl, либо завидовать наличию mod_php
Ничто не мешает использовать минимальные возможности mod_perl и не завязываться только на него одного. Если самостоятельно реализовать не получается — можно использовать веб-фреймворки, в CGI::Application и Catalyst поддержка CGI, mod_perl и FastCGI идет из коробки. Если не хочется фреймворк — то можно использовать Plack — это middleware, дающий единый API для web приложения и взаимодействующий с mod_perl, mod_psgi, plain CGI, FastCGI и т.д.
В перле надо везде следить за юникодом, где есть ввод-вывод. А данные могут из БД попасть в перл, пройти через пару модулей, через регекспы и выйти в виде кракоябр через JSON::Any. Ищи потом свищи, где проблема.
В драйвере БД (mysql, Pg) достаточно включить всего один флаг при коннекте, чтобы все данные шли с utf8 флагом, я уже писал выше.
> Урежте осетра.
Простите, что сделать?
Это идиоматическое выражение, которое означает, что вы преувеличиваете количество сущностей за которыми надо следить для поддержки Unicode, как тот рыбак преувеличивает размер пойманого им осетра.
> Или как у вас regexp оказался отдельным слоем?
Вот например linuxforum.ru/index.php?s=7ddd94c1171d58bf01c0f7363571055d&showtopic=51252&st=0&p=504768&#entry504768 или вот web.opennet.ru/openforum/vsluhforumID9/8150.html
Проблема решается, но начинающего может ввести в легкий ступор.
В обоих случаях проблема была в отсутствии decode на входящих данных. На regexp она у них просто проявилась, как проявилась бы и на обычном 'eq'.
Или как было сказано в камментах на опеннете — «А вообще работа с юникодом в перле(да и в большинстве других языков) это шаманство, особенно когда много _различных_ потоков ввода/вывода» (с)
Шаманством это выглядит потому что говорящий, судя по его советам, сам слабо понимает как работать с Unicode в Perl. Я еще раз повторю — для нормальной поддержки Unicode необходимо и достаточно делать decode() на входе и encode() на выходе — и это все (см. perlunitut). Все остальное (см. perlunifaq) — по большому счету syntax sugar. В приведенной проблеме на opennet все начало правильно читаться и обрабатываться после добавления «use utf8;» и «use open ':encoding(utf8)';». Первое нужно потому, что строковые константы в исходнике — это тоже ввод и Perl'у нужно сообщить о том, что они в UTF-8. Второе включило автоматическое decode/encode в utf-8 для файлов открытых через open(). В данном случае правильнее (поскольку локаль в UTF-8) было бы заменить «use open ':encoding(utf8)';» на «use open ':locale';» и тогда бы у них заработали и STDOUT/STDIN/STDERR. Но товарищи пошли по пути использования непосредственного decode/encode, что было бы OK, если бы они использовали функции из модуля Encode. В данном случае они используют функций utf8::encode/utf8::decode, которые во-первых меняют строки in place, что чревато граблями, во-вторых, в случае смены локали данный код нужно будет менять на использование функций из Encode.
И хотите совет? Не читайте opennet, ни до обеда, ни после. Большинство советчиков там именно что шаманы, которые исповедуют Cargo Cult.
Сочуствую, но этот мир не идеален и никому неизвестно все заранее. Поэтому лучше воспринимать такие сложные эпизоды в карьере как источник опыта и знаний и думать что энтропия в этом мире все-таки несколько уменьшилась в итоге личной профессиональной деятельности :)
>Вы выборку из этих данных какую делали? Открывали каждую вакансию типа 'Software Developer' или 'Software Engineer' без указания языка? Или просто сделали предположение что это не Perl и дальше пятой страницы не смотрели?
посмотрел 5 страницу, 6, 10 и парочку после 10.
Т.е. сами вакансии не открывали?
>Объясните, на основании каких данных вы решили отбросить >3000 вакансий (95% процентов)?
даже если и есть ещё пара сотен, как вы предлагаете их выискивать?
Если вы отбрасываете больше половины значимых данных — то ваши итоговые результаты недостоверны.
>я вот нашел случайным тыком такую даже на 25-ой странице
исключение, подтверждающее правило?
посмотрел еще на 10-ой,11-ой,53-ей страницах — нашел соответственно 1, 2 и 1 релевантные вакансии.
Как бы сам dice.com сортирует вакансии по релевантности…
Релевантность, судя по всему, там однобитная — «упоминается в title»/«упоминается в body», поэтому после 5-ой страницы релевантные вакансии размазаны равномерно по оставшейся сотне страниц.
>Это можно объяснить например тем, что примерно половина вакансий для Perl не имеет названия языка в job title. См. jobs.perl.org — из 20 вакансий в title Perl упоминается у 12 (~60%)
половина VS 10% — приличная разница, не находите ли?
Извините, но EPIC, судя по его докуам умеет только «extract_subroutine», rename он уже не умеет. Это сложно назвать поддержкой рефакторинга кода.
Я могу предположить что в Java 'rename function' более востребована, поскольку там очень любят растаскивать код на однострочные методы (видимо сказывается легкая доступность 'Extract Method' ;) ), соответственно методов становится много, по названиям они путаются и приходится часто их переименовывать. В Perl такие однострочные функции я наблюдаю обычно в финансовых расчетах, где нужны и промежуточные результаты и итог одновременно и тут действительно часто возникают функции под названием вроде calc_percent, calc_percent_more, которые нужно переименовывать в более приличный вид, но такого, чтобы это потребовало серьезной автоматизации — не встречал. По большому же счету я затрудняюсь называть чисто косметический rename function — рефакторингом.
Как и возня с search-replace средствами по всему дереву проекта.
Если вызовы размазаны по всему дереву проекта — то это уже code smell или какой-то низкоуровневый API. В большинстве случаев некий метод вызывается единицы раз.
Чем мне нравится Java, так это тем, что очень легко искать в проекте места испорченные корявым рефакторингом. И ещё проще код рефакторить. В Perl это далеко не так, в нем можно играючи поиметь кучу геморроя на пустом месте.
Кучу геморроя вы поймаете в любом языке как только попробуете поменять какой-нибудь низкоуровневый API приложения и сделать следующий шаг после применения 'Add Argument' к методу — изменению фактических аргументов, которые передаются методу. Все закончится тем же ручным search-replace по всему дереву, который особо не автоматизируется из-за того что каждый случай использования метода надо анализировать чтобы понять какие параметры использовать и откуда их брать в данном контексте. При этом надо понимать что на практике этот search/replace является всего-лишь разовым механическим действием, которому предшествует намного более долговременная разработка и тестирование этого нового API (если по Fowler'у, то 'Substitute Algorithm' ).
>mod_perl дает намного больше возможностей нежели mod_php.
А так ли нужны возможности в угоду сложности?
Для типичного современного приложения типа «моя самописная CMS на shared hosting» скорее всего ничего не нужно, кроме быстрой запускалки.
Для чего-то более серьезного в mod_perl уже есть некоторые вкусности, которых нет ни в каких mod_[php|python|wsgi|passenger]. Фактически, mod_perl это набор хуков которые можно вызвать практически на любом этапе обработки HTTP-запроса Apacheм. Можно легко организовать роутинг запросов, доступ к пост-фильтрам Apache, обработку ошибок, отсылку файлов через sendfile и т.д.
не секрет, что благодаря ему php скрипты под apache работают шустрее чем скрипты на perl.
Можно ли увидеть ссылку на тесты? Или вы сравниваете mod_php с plain CGI?
>В качестве тупой запускалки по типу mod_php сейчас есть mod_perlite и он уже может исполнять Movable Type.
Ему уже года три-четыре им по очереди занимается то один то другой энтузиаст и этот проект все-ещё в стадии вау-проекта. Типа, вау! Он вроде-бы смог запустить Movable Type!
Судя по commit-логам на github этим проектом занимается в основном один человек — Aaron Stone с ноября 2007-го года, когда им была создана в svn версия 0.01. Впрочем, проект действительно сырой, у меня оно падает в корку уже при старте Apache.
Как альтернативу можно еще посмотреть на Plack и mod_psgi (аналог mod_wsgi)
Как пример — куча модулей, включая TemplateToolkit не знают, что есть на свете юникод, особенно это затрагивает чтение-запись в файлы. Поэтому приходилось либо искать по мейллистам плагины (tt2) либо переписывать модули.
Простите, но судя по Changes от Tempalate Toolkit он уже 5 лет начиная с версии 2.14 поддерживает Unicode и умеет делать как минимум вот так:
Потом начинаются заморочки. Перл с юникодом странно работает, он может получать юникод, но не подозревать об этом если у строки не проставлен флаг, что это юникод.
Если вы прошляпили и не сделали где надо decode — то да, огребете.
Т.е. в реальности надо постоянно заботится во всех слоях между которыми идет обмен данными — web, db, perl, regexp, file i/o, stdin, stdout… Это не смертельно, но иногда злит.
Урежте осетра. Следить надо только за тем, что входит и выходит из одного слоя — perl, поскольку только на этой границе имеет значение utf8 флаг. При этом очень интересно, как вы собрались обмениваться данными, например, между web и db, минуя perl? Или как у вас regexp оказался отдельным слоем? А stdin, stdout и file i/o — разными сущностями (да и web в случае plain CGI тоже наполовину обычный file i/o).
В реальности, в Unicode приложении вам нужно сделать decode при разборе CGI параметров, сказать sql driver'у чтобы он выставлял utf8 входящим данным (если в базе у вас UTF8), проставить нужный encoding на каждый open файла и сделать encode при выдаче HTTP body и это все.
В пятых я никому не пожелаю переносить крупный Perl проект с Linux на Windows, особенно если в нем куча модулей из CPAN. Хорошо, если это ваш проект, типа сайт, который всегда будет работать на одном сервере и у него один хозяин. А если у вас тиражируемый продукт?
Я три года был ведущим разработчиком тиражируемого коммерческого проекта на Perl. В качестве рабочего окружения продукта поддерживается и ActivePerl 5.6+ и shared hosting. Продукт использует несколько десятков pure Perl модулей со CPAN (всего около 10 Мб). Из внешних обязательных зависимостей только DBD::mysql. Опционально продукт может использовать внешние HTML::Parser, MIME::Tools, Net::DNS, perl-LDAP и GD — эти модули и их зависимости обнаруживаются автоматически и соответствующие опции становятся доступными в настройках.
>Я лично не испытываю особых затруднений при разработке приложений, которые используют только pure-Perl модули
Я наверное не ошибусь, если замечу, что даже внутри самого банального perl-date-time модуля есть замечательные файлы DateTime.bs и DateTime.so? На pure perl они не очень тянут. Пример не самый лучший, потому-что модуль известный и в готовом виде есть везде.
Обратите внимание на файл DateTimePP.pm в том же пакете — буквы PP означают pure-Perl. XS версия опциональна.
Но если например в проект взять довольно шустрый движок темплейтов ClearSilver (http://www.clearsilver.net/), который написан на C++ и имеет обертку к Perl, то может так вдруг оказаться, что в вашей новой версии ОС нет готового модуля для этого движка. В прошлой был, в новой — нет. Увы, случай из реальной жизни, я уже молчу про Windows.
Мне так кажется, что если у проекта среди требований стоит на первом месте переносимость, то и модули надо выбирать в первую очередь по этому критерию, а потом уже по шустрости или удобству. У меня, например, используется HTML::Template, я сильно матерился первое время после Template Toolkit. Сейчас привык, и даже извлек из его использование пользу — примитивность HTML::Template сразу отучает городить какой-либо код в шаблонах.
Как собственно и вопрос удобства их использования. Ведь если в CPAN начать устанавливать один модуль, вдруг окажется, что у него в зависимостях ещё пять, и у этих пяти есть свои зависимости — во славу компилятора make. Хотя несомненно, что большая часть этих модулей есть в пакетах. В общем, ещё то удовольствие.
У меня на данный момент в системе установлен 571 перловый модуль. Из них только 9 собраны из локально созданных мной портов, остальные из системных. Напрямую со CPAN поставлено ни одного модуля.
Я повторюсь, вопрос затрагивает исключительно кросплатформенность Perl. В Linux таких проблем вы наверняка не встретите.
Я рассматриваю shared hosting на каком-нибудь протухшем RHEL 3 как более сложную в поддержке платформу нежели чем ActivePerl 5.8+ на self-managed сервере, поскольку подмножество pure Perl модулей значительно меньше, нежели доступные в виде ppm модули (с учетом дополнительных репозитариев)
>perl — 3247
при этом «чистый» перл там уже странице на пятой почти заканчивается, т.е. перл либо идёт в нагрузку, либо (что реже) альтернативным языком к php/python, итого получается чуть ли не на порядок меньше, т.е. всего 300 вакансий
Вы выборку из этих данных какую делали? Открывали каждую вакансию типа 'Software Developer' или 'Software Engineer' без указания языка? Или просто сделали предположение что это не Perl и дальше пятой страницы не смотрели? Объясните, на основании каких данных вы решили отбросить >3000 вакансий (95% процентов)? Вы уверены что среди отброшенных вами вакансий не найдется еще пары сотен вполне релевантных Perl вакансий (я вот нашел случайным тыком такую даже на 25-ой странице)?
Если не верите — сделайте поиск как «Search job title only»:
java — 3083
c++ — 823
c# — 900
perl — 167(!)
php — 292
Это можно объяснить например тем, что примерно половина вакансий для Perl не имеет названия языка в job title. См. jobs.perl.org — из 20 вакансий в title Perl упоминается у 12 (~60%). Для сравнения, phpjobs.com — из 12 релевантных вакансий в title PHP упоминается у всех (100%).
Для ООП есть модуль Mouse — легкая версия Moose. Не имеет зависимостей и может быть собран без XS части, т.е. pure-Perl.
mod_perl дает намного больше возможностей нежели mod_php. В качестве тупой запускалки по типу mod_php сейчас есть mod_perlite и он уже может исполнять Movable Type.
С Unicode никаких особых заморочек в Perl 5.6+ не встречал, достаточно внимательно прочитать man perluniintro и остальное, а потом аккуратно делать decode на входе текста и encode на выходе.
Есть модуль Devel::Refactor который умеет rename_subroutine. Этот модуль может использоваться из EPIC плугина для eclipse. Можно наверное и из vim'а, но у меня лично особой необходимости в таких средствах не возникало, хватало search/replace в vim и grep/sed в особо тяжелых случаях.
Во-первых, насчет всех нужных вы существенно преувеличиваете. Я лично не испытываю особых затруднений при разработке приложений, которые используют только pure-Perl модули. Из зависимых от C модулей часто нужен только DBD::mysql или DBD::Pg.
Во-вторых, ничто не мешает вам ставить perl-модули с помощью пакетных менеджеров, а не через cpan. Для FreeBSD к примеру есть pm2port, который создает FreeBSD port из Perl-модуля.
В-третьих, а что вам мешает использовать тот же Maven с Perl-приложением? Я лично так вообще Rake использую для сборки, запуска тестов, deploy и т.п.
В-четвертых, если вы не пользуетесь PAR, то это не значит что никто им не пользуется.
Согласен дискуссию завершить, но прежде должен заметить, что я нигде не предлагал вам измерять популярность языка по количеству пакетов, это вы выдумали самостоятельно.
Если вы учтете тот факт, что ohloh отслеживает всего около 1000 проектов имеющих отношение к Perl при том, что только на CPAN зарегистрировано 77 708 модулей, то может быть поймете, что и в open source у Perl все не так плохо как вам показалось. Для сравнения, на сегодня python имеет 8639 пакетов, ruby — 9253 gem'ов, PHP PEAR — совсем смешные 547 пакетов.
Тренд на понижение я на этом графике вижу только у cobol. Так что ваши утверждения «о снижении популярности Perl-а» с реальностью несколько расходятся. Остальные же ваши рассуждения очень похожы на усиленное притягивание фактов за уши к уже сформированному у вас мнению с помощью пространных домыслов.
Vocabulary Learning in a Second Language: Person, Task, Context and Strategies
www.tesl-ej.org/wordpress/issues/volume7/ej26/ej26a4/
In fact there is already evidence in recent studies of second language learners
that a combined approach is superior to incidental vocabulary learning alone.
Zimmerman (1994), for example, found that 3 hours a week of explicit vocabulary
instruction plus some self-selected reading were more effective than reading
alone. Paribakht and Wesche (1997) also found that reading plus explicit
instruction led to superior gains over a period of three months.
Huckin and Coady (1999, pp.189-190) warned us that “guessing from context has
serious limitations. It is still seen as an important part of
vocabulary-building, especially among advanced learners, but it requires a
great deal of prior training in basic vocabulary, word recognition,
metacognition, and subject matter”. Lastly, the most recent tendency to see
incidental learning as involving different levels of task involvement (Laufer &
Hulstijn, 2001) also suggests a need to combine incidental and intentional
learning as a vocabulary learning strategy. Similar views are shared by Nation
(2001) and Schmitt (2000), two new books on vocabulary acquisition.
Not surprisingly, a considerable amount of earlier work on foreign language
vocabulary learning followed the psychological paradigm in memory research. And
almost all studies focusing on the pacing of repetition and recall of word
lists arrived at the same conclusion: that forgetting mostly occurs immediately
after initial encounter, and that the rate of forgetting slows down afterwards.
Anderson and Jordan (1928) examined the number of words that could be recalled
immediately after initial learning, 1 week, 3 weeks, and 8 weeks thereafter and
discovered a learning rate of 66%, 48%, 39%, and 37% respectively. Similar
results can be found in Seibert (1927, 1930). It was therefore suggested that
students should start repeating newly learned words immediately after the first
encounter. Spaced recall and repetition should follow afterwards at longer
intervals.
> Друзья, слова в отрыве от контекста не стоят ни копейки. И никаких исключений.
> Учить слова нужно только с контекстом, и ассоциировать тоже — только с контекстом.
citation needed ©
> Для достижения прогресса делайте то, что вам нравится: читайте, смотрите, слушайте, говорите, говорите сами с собой, думайте. На изучаемом языке.
Если у изучающего словарного запаса не хватает для понимания хотя бы базового смысла, то ему ничто не будет нравится — будет сплошная фрустрация. Фрустрация же и обучение есть вещи взаимоисключающие.
> Но не в ущерб настроению. Если смысл кажется понятным и без одного непонятного слова, его можно пропустить и продолжить поглощать поток информации не прерываясь. В ближайшее время оно всё равно всплывет не раз, и имея в памяти уже несколько вариантов использования можно либо догадаться о значении самому (что полезнее всего), либо открыть словарь, подсмотреть, переосмыслить, и запомнить.
Угадывание смысла слов из контекста называется 'incidental vocabulary learning' и является естественным способом усвоения родного языка. Для изучения слов иностранного языка этот способ менее эффективен чем целенаправленное разучивание слов.
Во-первых, нужно уже иметь базовый словарный запас чтобы понимать основной смысл. Во-вторых, чтобы слова действительно запоминались нужно их повторять каждый день, сооветственно контакт с языком должен быть ежедневным. В-третьих, поскольку запоминание зависит о частоты повторения слов, то запоминаться будут те слова, которые чаще употребляются, а редкие слова, особенно всякие прилагательные которые общего смысла не меняют так и будут пропускаться и нести весьма размытый смысл. В-четвертых, если заниматься только тем, что интересно, то словарный запас получается однобоким и возникает типичная проблема — люди читают тех. лит. свободно но пасуют на простейших бытовых темах.
В свете вышеизложенного не стоит ограничиваться только чтением. Чтобы пополнение словарного запаса было наиболее эффективным надо им заниматься целенаправленно и каждое незнакомое слово выписывать и регулярно повторять, лучше всего с помощью именно flashcards используя spaced repetition method (список соответствующего софта можно найти в wikipedia). Если словарный запас совсем минимальный, то стоит начать с какого-нибудь учебника, например Cambridge University «English Vocabulary in Use». Если словарный запас уже есть на уровне, то тогда рекомендую в flashcard записывать анлийское толкование вместо русского перевода, например из Cambridge Learner's Dictionary (доступен online).
> Пользуясь этой простой методикой я поднялся с уровня «не понимаю ни слова» до уровня С1 (согласно CEFR выше только C2 — Mastery or proficiency) и подтвердил этот уровень сдачей кембриджского экзамена.
За полтора года.
Я не знаю какому уровню словарного запаса C1 соответствует, но с помощью соответствующего софта для flashcard выучить пару тысяч слов тратя где-то 10-15 минут в день можно примерно за полгода.
Самый главный недостаток — это неточность данной метрики. Например, запись оценки в виде «7500 строк для задачи b» предполагает, что точность составляет ±100 строк, тогда как в реальности точность этой оценки примерно ±3500, т.е. итоговый результат может отличаться в два-три раза минимум, а в крайних случаях — на порядок. Производительность разных программистов (или одного программиста на разных задачах) в строках кода также отличается в среднем в 2-3 раза и до 10 раз в крайних случаях и зависит в том числе и от объема кода и от количества других программистов участвующих в проекте.
Не думаю что нужно перечислять остальные недостатки — этого уже достаточно чтобы понять, что данную метрику имеет смысл использовать только для оценки порядка объема некоего проекта, например — «проект в 15000 строк является средним по объему и средним программистом будет выполнен в срок от 3 до 9 месяцев».
Я не очень улавливаю о чем собственно у вас речь. У меня складывается впечатление что ваш мессадж в том, что рефакторинг с применением некошерного find/replace — это и не рефакторинг вовсе?
Быстро — не выявите, если проблемными являются, в зависимости от контекста, только 10 из 100 мест, где используется данный method.
grep/ack прекрасно работает в качестве «find usage».
Ничто не мешает использовать минимальные возможности mod_perl и не завязываться только на него одного. Если самостоятельно реализовать не получается — можно использовать веб-фреймворки, в CGI::Application и Catalyst поддержка CGI, mod_perl и FastCGI идет из коробки. Если не хочется фреймворк — то можно использовать Plack — это middleware, дающий единый API для web приложения и взаимодействующий с mod_perl, mod_psgi, plain CGI, FastCGI и т.д.
В драйвере БД (mysql, Pg) достаточно включить всего один флаг при коннекте, чтобы все данные шли с utf8 флагом, я уже писал выше.
Это идиоматическое выражение, которое означает, что вы преувеличиваете количество сущностей за которыми надо следить для поддержки Unicode, как тот рыбак преувеличивает размер пойманого им осетра.
В обоих случаях проблема была в отсутствии decode на входящих данных. На regexp она у них просто проявилась, как проявилась бы и на обычном 'eq'.
Шаманством это выглядит потому что говорящий, судя по его советам, сам слабо понимает как работать с Unicode в Perl. Я еще раз повторю — для нормальной поддержки Unicode необходимо и достаточно делать decode() на входе и encode() на выходе — и это все (см. perlunitut). Все остальное (см. perlunifaq) — по большому счету syntax sugar. В приведенной проблеме на opennet все начало правильно читаться и обрабатываться после добавления «use utf8;» и «use open ':encoding(utf8)';». Первое нужно потому, что строковые константы в исходнике — это тоже ввод и Perl'у нужно сообщить о том, что они в UTF-8. Второе включило автоматическое decode/encode в utf-8 для файлов открытых через open(). В данном случае правильнее (поскольку локаль в UTF-8) было бы заменить «use open ':encoding(utf8)';» на «use open ':locale';» и тогда бы у них заработали и STDOUT/STDIN/STDERR. Но товарищи пошли по пути использования непосредственного decode/encode, что было бы OK, если бы они использовали функции из модуля Encode. В данном случае они используют функций utf8::encode/utf8::decode, которые во-первых меняют строки in place, что чревато граблями, во-вторых, в случае смены локали данный код нужно будет менять на использование функций из Encode.
И хотите совет? Не читайте opennet, ни до обеда, ни после. Большинство советчиков там именно что шаманы, которые исповедуют Cargo Cult.
Т.е. сами вакансии не открывали?
Если вы отбрасываете больше половины значимых данных — то ваши итоговые результаты недостоверны.
посмотрел еще на 10-ой,11-ой,53-ей страницах — нашел соответственно 1, 2 и 1 релевантные вакансии.
Релевантность, судя по всему, там однобитная — «упоминается в title»/«упоминается в body», поэтому после 5-ой страницы релевантные вакансии размазаны равномерно по оставшейся сотне страниц.
Вы о чем, поясните?
Я могу предположить что в Java 'rename function' более востребована, поскольку там очень любят растаскивать код на однострочные методы (видимо сказывается легкая доступность 'Extract Method' ;) ), соответственно методов становится много, по названиям они путаются и приходится часто их переименовывать. В Perl такие однострочные функции я наблюдаю обычно в финансовых расчетах, где нужны и промежуточные результаты и итог одновременно и тут действительно часто возникают функции под названием вроде calc_percent, calc_percent_more, которые нужно переименовывать в более приличный вид, но такого, чтобы это потребовало серьезной автоматизации — не встречал. По большому же счету я затрудняюсь называть чисто косметический rename function — рефакторингом.
Если вызовы размазаны по всему дереву проекта — то это уже code smell или какой-то низкоуровневый API. В большинстве случаев некий метод вызывается единицы раз.
Кучу геморроя вы поймаете в любом языке как только попробуете поменять какой-нибудь низкоуровневый API приложения и сделать следующий шаг после применения 'Add Argument' к методу — изменению фактических аргументов, которые передаются методу. Все закончится тем же ручным search-replace по всему дереву, который особо не автоматизируется из-за того что каждый случай использования метода надо анализировать чтобы понять какие параметры использовать и откуда их брать в данном контексте. При этом надо понимать что на практике этот search/replace является всего-лишь разовым механическим действием, которому предшествует намного более долговременная разработка и тестирование этого нового API (если по Fowler'у, то 'Substitute Algorithm' ).
Для типичного современного приложения типа «моя самописная CMS на shared hosting» скорее всего ничего не нужно, кроме быстрой запускалки.
Для чего-то более серьезного в mod_perl уже есть некоторые вкусности, которых нет ни в каких mod_[php|python|wsgi|passenger]. Фактически, mod_perl это набор хуков которые можно вызвать практически на любом этапе обработки HTTP-запроса Apacheм. Можно легко организовать роутинг запросов, доступ к пост-фильтрам Apache, обработку ошибок, отсылку файлов через sendfile и т.д.
Можно ли увидеть ссылку на тесты? Или вы сравниваете mod_php с plain CGI?
Судя по commit-логам на github этим проектом занимается в основном один человек — Aaron Stone с ноября 2007-го года, когда им была создана в svn версия 0.01. Впрочем, проект действительно сырой, у меня оно падает в корку уже при старте Apache.
Как альтернативу можно еще посмотреть на Plack и mod_psgi (аналог mod_wsgi)
Простите, но судя по Changes от Tempalate Toolkit он уже 5 лет начиная с версии 2.14 поддерживает Unicode и умеет делать как минимум вот так:
$tt->process($in, $vars, $out, binmode => ':utf8');
Если вы прошляпили и не сделали где надо decode — то да, огребете.
Урежте осетра. Следить надо только за тем, что входит и выходит из одного слоя — perl, поскольку только на этой границе имеет значение utf8 флаг. При этом очень интересно, как вы собрались обмениваться данными, например, между web и db, минуя perl? Или как у вас regexp оказался отдельным слоем? А stdin, stdout и file i/o — разными сущностями (да и web в случае plain CGI тоже наполовину обычный file i/o).
В реальности, в Unicode приложении вам нужно сделать decode при разборе CGI параметров, сказать sql driver'у чтобы он выставлял utf8 входящим данным (если в базе у вас UTF8), проставить нужный encoding на каждый open файла и сделать encode при выдаче HTTP body и это все.
Я три года был ведущим разработчиком тиражируемого коммерческого проекта на Perl. В качестве рабочего окружения продукта поддерживается и ActivePerl 5.6+ и shared hosting. Продукт использует несколько десятков pure Perl модулей со CPAN (всего около 10 Мб). Из внешних обязательных зависимостей только DBD::mysql. Опционально продукт может использовать внешние HTML::Parser, MIME::Tools, Net::DNS, perl-LDAP и GD — эти модули и их зависимости обнаруживаются автоматически и соответствующие опции становятся доступными в настройках.
Обратите внимание на файл DateTimePP.pm в том же пакете — буквы PP означают pure-Perl. XS версия опциональна.
Мне так кажется, что если у проекта среди требований стоит на первом месте переносимость, то и модули надо выбирать в первую очередь по этому критерию, а потом уже по шустрости или удобству. У меня, например, используется HTML::Template, я сильно матерился первое время после Template Toolkit. Сейчас привык, и даже извлек из его использование пользу — примитивность HTML::Template сразу отучает городить какой-либо код в шаблонах.
У меня на данный момент в системе установлен 571 перловый модуль. Из них только 9 собраны из локально созданных мной портов, остальные из системных. Напрямую со CPAN поставлено ни одного модуля.
Я рассматриваю shared hosting на каком-нибудь протухшем RHEL 3 как более сложную в поддержке платформу нежели чем ActivePerl 5.8+ на self-managed сервере, поскольку подмножество pure Perl модулей значительно меньше, нежели доступные в виде ppm модули (с учетом дополнительных репозитариев)
Вы выборку из этих данных какую делали? Открывали каждую вакансию типа 'Software Developer' или 'Software Engineer' без указания языка? Или просто сделали предположение что это не Perl и дальше пятой страницы не смотрели? Объясните, на основании каких данных вы решили отбросить >3000 вакансий (95% процентов)? Вы уверены что среди отброшенных вами вакансий не найдется еще пары сотен вполне релевантных Perl вакансий (я вот нашел случайным тыком такую даже на 25-ой странице)?
Это можно объяснить например тем, что примерно половина вакансий для Perl не имеет названия языка в job title. См. jobs.perl.org — из 20 вакансий в title Perl упоминается у 12 (~60%). Для сравнения, phpjobs.com — из 12 релевантных вакансий в title PHP упоминается у всех (100%).
mod_perl дает намного больше возможностей нежели mod_php. В качестве тупой запускалки по типу mod_php сейчас есть mod_perlite и он уже может исполнять Movable Type.
С Unicode никаких особых заморочек в Perl 5.6+ не встречал, достаточно внимательно прочитать man perluniintro и остальное, а потом аккуратно делать decode на входе текста и encode на выходе.
Во-вторых, ничто не мешает вам ставить perl-модули с помощью пакетных менеджеров, а не через cpan. Для FreeBSD к примеру есть pm2port, который создает FreeBSD port из Perl-модуля.
В-третьих, а что вам мешает использовать тот же Maven с Perl-приложением? Я лично так вообще Rake использую для сборки, запуска тестов, deploy и т.п.
В-четвертых, если вы не пользуетесь PAR, то это не значит что никто им не пользуется.
Тренд на понижение я на этом графике вижу только у cobol. Так что ваши утверждения «о снижении популярности Perl-а» с реальностью несколько расходятся. Остальные же ваши рассуждения очень похожы на усиленное притягивание фактов за уши к уже сформированному у вас мнению с помощью пространных домыслов.
java — 9698
c# — 4582
c++ — 4164
perl — 3247
php — 1639
python — 1308
ruby — 688
cobol — 530
Benchmark: timing 10 iterations of JOIN, LOOP…
JOIN: 1 wallclock secs ( 1.02 usr + 0.02 sys = 1.03 CPU) @ 9.70/s (n=10)
LOOP: 2 wallclock secs ( 2.22 usr + 0.02 sys = 2.23 CPU) @ 4.48/s (n=10)