• Поговорим о словарном запасе иностранного языка
    0
    Как все оказывается запущено.

    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.
  • Поговорим о словарном запасе иностранного языка
    0
    > Из всех известных мне идиотских советов эти два самые вредные.

    > Друзья, слова в отрыве от контекста не стоят ни копейки. И никаких исключений.
    > Учить слова нужно только с контекстом, и ассоциировать тоже — только с контекстом.

    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 минут в день можно примерно за полгода.
  • Поговорим о словарном запасе иностранного языка
    +1
    Что-то мне думается что результаты с testyourvocab.com не соответствуют пороговыем значениям словарного запаса перечисляемым в начале статьи. Чтобы их сравнивать результаты надо делить где-то втрое-четверо. Т.е. результат по тесту в 5000-6000 слов как раз должен соответствовать традиционном понимаемому базовому английскому словарю который дается в школе/институте и составляет 1500-2000 слов.
  • Почем ныне разработка ПО на заказ?
    +1
    Не надо считать строчки кода — вы идете по граблям, которые остальное человечество прошло лет 30 назад. Основные недостатки использования этой метрики в качестве основы для планирования разбирал еще Ф.Брукс в своей классической книге The Mythical Man-Month вышедшей в 1975-м году. Эти недостатки также перечислены и на упомянутой странице из википедии.

    Самый главный недостаток — это неточность данной метрики. Например, запись оценки в виде «7500 строк для задачи b» предполагает, что точность составляет ±100 строк, тогда как в реальности точность этой оценки примерно ±3500, т.е. итоговый результат может отличаться в два-три раза минимум, а в крайних случаях — на порядок. Производительность разных программистов (или одного программиста на разных задачах) в строках кода также отличается в среднем в 2-3 раза и до 10 раз в крайних случаях и зависит в том числе и от объема кода и от количества других программистов участвующих в проекте.

    Не думаю что нужно перечислять остальные недостатки — этого уже достаточно чтобы понять, что данную метрику имеет смысл использовать только для оценки порядка объема некоего проекта, например — «проект в 15000 строк является средним по объему и средним программистом будет выполнен в срок от 3 до 9 месяцев».
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    >По большому же счету я затрудняюсь называть чисто косметический rename function — рефакторингом.

    Об чем и речь. Остается лишь find/replace.

    Я не очень улавливаю о чем собственно у вас речь. У меня складывается впечатление что ваш мессадж в том, что рефакторинг с применением некошерного find/replace — это и не рефакторинг вовсе?
    >Кучу геморроя вы поймаете в любом языке как только попробуете поменять какой-нибудь низкоуровневый API приложения и сделать следующий шаг после применения 'Add Argument' к методу

    В IDEA я по крайней мере быстро выявлю все проблемные места.

    Быстро — не выявите, если проблемными являются, в зависимости от контекста, только 10 из 100 мест, где используется данный method.
    В популярных IDE для Perl (коих две) вроде бы нет даже примитивного «find usage»?

    grep/ack прекрасно работает в качестве «find usage».
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    Именно, других вариантов ведь нет? Либо завязывать приложение на 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.
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    Сочуствую, но этот мир не идеален и никому неизвестно все заранее. Поэтому лучше воспринимать такие сложные эпизоды в карьере как источник опыта и знаний и думать что энтропия в этом мире все-таки несколько уменьшилась в итоге личной профессиональной деятельности :)
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    >Вы выборку из этих данных какую делали? Открывали каждую вакансию типа '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% — приличная разница, не находите ли?

    Вы о чем, поясните?
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    –1
    Извините, но 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' ).
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    >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 и умеет делать как минимум вот так:

    $tt->process($in, $vars, $out, binmode => ':utf8');
    Потом начинаются заморочки. Перл с юникодом странно работает, он может получать юникод, но не подозревать об этом если у строки не проставлен флаг, что это юникод.

    Если вы прошляпили и не сделали где надо 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 и это все.
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    В пятых я никому не пожелаю переносить крупный 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 модули (с учетом дополнительных репозитариев)
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    >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%).
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    Для ООП есть модуль Mouse — легкая версия Moose. Не имеет зависимостей и может быть собран без XS части, т.е. pure-Perl.

    mod_perl дает намного больше возможностей нежели mod_php. В качестве тупой запускалки по типу mod_php сейчас есть mod_perlite и он уже может исполнять Movable Type.

    С Unicode никаких особых заморочек в Perl 5.6+ не встречал, достаточно внимательно прочитать man perluniintro и остальное, а потом аккуратно делать decode на входе текста и encode на выходе.
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    Есть модуль Devel::Refactor который умеет rename_subroutine. Этот модуль может использоваться из EPIC плугина для eclipse. Можно наверное и из vim'а, но у меня лично особой необходимости в таких средствах не возникало, хватало search/replace в vim и grep/sed в особо тяжелых случаях.
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    +1
    Во-первых, насчет всех нужных вы существенно преувеличиваете. Я лично не испытываю особых затруднений при разработке приложений, которые используют только pure-Perl модули. Из зависимых от C модулей часто нужен только DBD::mysql или DBD::Pg.

    Во-вторых, ничто не мешает вам ставить perl-модули с помощью пакетных менеджеров, а не через cpan. Для FreeBSD к примеру есть pm2port, который создает FreeBSD port из Perl-модуля.

    В-третьих, а что вам мешает использовать тот же Maven с Perl-приложением? Я лично так вообще Rake использую для сборки, запуска тестов, deploy и т.п.

    В-четвертых, если вы не пользуетесь PAR, то это не значит что никто им не пользуется.
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    Согласен дискуссию завершить, но прежде должен заметить, что я нигде не предлагал вам измерять популярность языка по количеству пакетов, это вы выдумали самостоятельно.
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    Если вы учтете тот факт, что ohloh отслеживает всего около 1000 проектов имеющих отношение к Perl при том, что только на CPAN зарегистрировано 77 708 модулей, то может быть поймете, что и в open source у Perl все не так плохо как вам показалось. Для сравнения, на сегодня python имеет 8639 пакетов, ruby — 9253 gem'ов, PHP PEAR — совсем смешные 547 пакетов.
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    +2
    Хотите динамику, смотрите.


    Тренд на понижение я на этом графике вижу только у cobol. Так что ваши утверждения «о снижении популярности Perl-а» с реальностью несколько расходятся. Остальные же ваши рассуждения очень похожы на усиленное притягивание фактов за уши к уже сформированному у вас мнению с помощью пространных домыслов.

  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    Это у вас выборка специфическая. Зайдите на dice.com и посмотрите.

    java — 9698
    c# — 4582
    c++ — 4164
    perl — 3247
    php — 1639
    python — 1308
    ruby — 688
    cobol — 530

  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    На FreeBSD join быстрее всего в два раза

    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)
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    +2
    Ну тогда еще для коллекции — Amazon, Yahoo, BBC, Slashdot. В России — Рамблер.
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    +1
    s/забывали/забыли/
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    Есть Test::Perl::Critic. В pre-commit хуки надо вешать проверку успешного прохождения тестов.
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    Вы забывали к своим утверждениям добавить «под Windows».
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    У меня данный код выполняется за ~0.2 sec. Аналогичный PHP код — за 0.35 sec. Система FreeBSD.
  • Mini-FAQ по Perl (Частые вопросы, ЧаВо)
    0
    Во-первых, здесь видимо умничает парсер хабра и подставляет HTML entity ellipsis (…) оно же троеточие, вместо двух подряд идущих точек. Во-вторых в данном случае в Perl две точки обозначают range operator, функциональность flip-flop — это только в скалярном контексте. В-третьих, три точки, как подставил хабр — тоже можно и в данном случае это не меняет поведение кода.
  • Новогодний подарок хостерам: Как разместить на сервере 10000 клиентов или даже больше
    0
    Роговскому, как всякому нормальному социопату, любые увещевания — до лампочки. Товарищ не способен учиться по определению, поскольку заметить собственные ошибки он не в состоянии, а любая критика извне — это происки конкурентов и завистников. Все что он извлек из головомойки на тему DNS — это знание о существовании услуги 'Slave DNS'. Теперь с применением этого знания он строит геокластеры с балансировкой через DNS :)
  • Как сделать бюджетный геокластерный хостинг
    +2
    Топикстартер известный шарлатан. Его статьи — это малограмотные «фантазии на тему», никаким реальным опытом не подкрепленные. Разбирали уже не раз — тут он узнает о существовании услуги 'Slave DNS', тут он тестирует Squid vs Varnish, не имея понятия что у него в системе происходит, но выводы делает, тут он оптимизирует шаред-хостинг не имея понятия как работает *nix VM.
  • Photoshop vs. Fireworks: сжатие
    +2
    К примеру, на yahoo 40-60% пользователей заходит с пустым кешем. yuiblog.com/blog/2007/01/04/performance-research-part-2/
  • Повышение качества javascript кода. JSLint
  • monit — наблюдатель за системными процессами
    0
    Еще man openssl говорит что gendh obsoleted by openssl dhparam, поэтому лучше вместо openssl gendh 512 написать openssl dhparam -2 -outform PEM
  • monit — наблюдатель за системными процессами
    0
    Во FreeBSD лежит в PORTS/sys-utils/monit.


    На самом деле — в $PORTSDIR/sysutils/monit/

    # FreeBSD/OpenBSD/NetBSD
     /usr/local/etc/monit/monitrc
    


    Во FreeBSD конфиг лежит по умолчанию в /usr/local/etc/monitrc

    # Для того, чтобы иметь возможность проводить такие проверки, нужно собрать monit с поддержкой SSL.
    # Любители FreeBSD — будьте внимательны при сборке!


    Во FreeBSD monit собирается с поддержкой SSL по умолчанию.
  • От чего зависят технические достижения человечества…
    +2
    Если уж на то пошло
  • От чего зависят технические достижения человечества…
    0
    Да, их тоже перевозят по реке, но ссылки под рукой нет, память может меня и подводить.
  • От чего зависят технические достижения человечества…
    0
    Кстати, на второй фотке в статье имеено этот бак, а не ускорители или какие-то другие двигатели.
  • От чего зависят технические достижения человечества…
    +4
    Вот так
  • От чего зависят технические достижения человечества…
    +8
    Как вам такой красавец? Aero Spacelines Super Guppy Специально разработан для перевозки крупногабаритных аэрокосмических грузов.

  • От чего зависят технические достижения человечества…
    +3
    Станция Алмаз взлетела как минимум трижды под названием Салют-2, Салют-3 и Салют-5. И размер ее (диаметр 4.15 метра) несколько шире чем вагон-рефрижератор (3.1 метра ширина).
  • Стандарт быстрой подзарядки для электромобилей
    0
    Там «Ontario Public Service fleet» с толку сбивает, сразу думается про казенные машины или таксистов каких-нибудь. Вот по ссылке в CBC News уже более понятно — обещаны rebate от $4K до $10K для купивших после 1 июля 2010.
  • Стандарт быстрой подзарядки для электромобилей
    0
    Кстати, в wiki пишут что провинция Онтарио дает какую-то субсидию в $10K на Chevy Volt, только сходу не ясно кому.