Пока еще не очень стабильно (вчера несколько часов потратил, чтоб закрыть несколько багов с поддержкой UTF-8), но комментарии и посты экспортируются без проблем.
Контуры, думаю, проще распознавать, чем фотографии. Во всяком случае при распознавании капч трейсинг контура — отдельная не самая тривиальная порой операция.
Да-да, без огромной базы картинок и достаточно большой базы вариантов идея не жизнеспособна — но тогда возникает проблема синонимов и общих/частных понятий, например, что изображено на картинке — документ или бумага, Эйнштейн или учёный и т.п.
Идея не оригинальна, у убнутариев в их мозговом штурме уже есть такой вопрос. Называется это все kittenauth.
На самом деле ваша капча по крайней мере в такой реализации ни разу не безопасна, т.к. число картинок будет скорее всего сравнительно не большим и статическим, следовательно, распознать картинки будет не сложно (банальный словарь соответствуий картинка-слово). Распознать «A2», если оно не деформируется, тоже достаточно просто, а если начать деформировать столы и слонов, то действительно начинается царство LSD :-)
Более того, такой код встретился и именно изменение поведения между версиями и обратило на себя внимание. Я не спорю с тем, что код — дрянь, но я считаю, что такое поведение для кода $string[$another_string] не логично и далеко не очевидно, что строка-индекс будет прикастована к целому.
Про хаскель я всерьез задумался тогда, когда мне в JS-коде захотелось использовать нечто, что, как я впоследствие узнал, называлось «Y-комбинатор» :-)
Питон — под python-docs.tar.bz2 (официальные доки), ничего лучшего тоже не видал… Да и не привыкать документацию читать, начиная изучать программирование с ассемблера :)
Гугл сказал Python — значит Python.
Достаточно часто слышал про проблемы с производительностью при сравнении ruby vs. python, нет, я знаю, что современные вычислительные мощности бла-бла-бла, и время программиста бля-бла-бла.
Но, как мне кажется без вдумчивого изучения ruby, он с python примерно эквивалентен по фишками.
А для экзотики хотелось бы поковырять haskell и erlang, да времени не хватает :-)
Я стал значительно терпимее после того, как баги с безопасностью были найдены в микрокоде процессоров Intel (на wasm.ru чудесный топик был на эту тему).
И к глюкам разного рода я уже привык — редкий день без отосланного багрепорта обходится. :)
Я тоже могу сказать «PHP — говно», мне противен язык с кучей лапши, но это всего лишь инструмент — некоторые задачи (Personal Home Page) он решает отлично и это сложно не признать. Насколько на нём удобно и хорошо писать сложные и большие системы — не знаю, у меня нет опыта написания чего-то огромного на PHP, так, пару чуть менее чем тривиальных сайтиков несколько лет назад.
Но это не отменяет моей скромной ненависти к PHP, сдержанного отношения к Perl и тихого обожания Python.
:)
Ну да, отличная логика, такая, слегка недетерминированная :)
Что warning это хорошо — значит, всё-таки баг был отрепорчен не зря.
А у вас какая версия? У меня 5.2.6-pl7-gentoo с E_ALL не ругается…
При том я нашел четвертый вариант результата выполнения кода — строка не меняется вообще:
$ php -r '$foo = «asdf»; $foo[«foobar»] = $foo; var_dump($foo);'
string(4) «asdf»
А присвоение ключу строки либо превратило строку в ассоциативный массив (вполне ожидаемое поведение для текстового ключа), либо (о боги!) этот текстовый ключ был неявно преобразован в число, после чего в зависимости от представления строки в разных версиях был взят либо первый её символ, либо '\0'…
Нет, я все понимаю, что compatibility надо иногда ломать, но всё же…
Например, в том же питоне была выпущена версия 2.6 где при исполнении кода, который поломается в 3.0, выдавались предупреждения.
А все варианты результата этого кода, коих три: "\0oobar", «foobar», и array('foobar' => 'foobar') — вот все эти три варианта проявляются в различных версиях 5.2.x (может быть я все-таки ошибаюсь про все три, но абсолютно точно — два из них в 5.2.х и все три в 5.х).
Отсюда вывод: либо они слишком часто любят ломать совместимость, либо данный интерпретируемый язык не выдает warning-ов при таком очевидном и довольно тривиальном «undefined behaviour» — это его никак не красит.
Стоит также заметить, что в данном случае речь не про стандартную библиотеку, не про криворуких кодеров — речь про дизайн языка.
Так что увеличение стоимости спама в десятки раз — это хорошо.
На самом деле ваша капча по крайней мере в такой реализации ни разу не безопасна, т.к. число картинок будет скорее всего сравнительно не большим и статическим, следовательно, распознать картинки будет не сложно (банальный словарь соответствуий картинка-слово). Распознать «A2», если оно не деформируется, тоже достаточно просто, а если начать деформировать столы и слонов, то действительно начинается царство LSD :-)
Поставить, да, можно, конечно, но речь шла про искаропку.
Или, хотите сказать, у убунты коробки нет? :)
Питон — под python-docs.tar.bz2 (официальные доки), ничего лучшего тоже не видал… Да и не привыкать документацию читать, начиная изучать программирование с ассемблера :)
Я не спорю, что пример — ацкий ацтой, но это тот случай, когда warning выдавать лучше, чем тупо кастовать строчку к числу.
Если хотите подробностей, вот этот баг: bugs.php.net/bug.php?id=45400
Достаточно часто слышал про проблемы с производительностью при сравнении ruby vs. python, нет, я знаю, что современные вычислительные мощности бла-бла-бла, и время программиста бля-бла-бла.
Но, как мне кажется без вдумчивого изучения ruby, он с python примерно эквивалентен по фишками.
А для экзотики хотелось бы поковырять haskell и erlang, да времени не хватает :-)
И к глюкам разного рода я уже привык — редкий день без отосланного багрепорта обходится. :)
Я тоже могу сказать «PHP — говно», мне противен язык с кучей лапши, но это всего лишь инструмент — некоторые задачи (Personal Home Page) он решает отлично и это сложно не признать. Насколько на нём удобно и хорошо писать сложные и большие системы — не знаю, у меня нет опыта написания чего-то огромного на PHP, так, пару чуть менее чем тривиальных сайтиков несколько лет назад.
Но это не отменяет моей скромной ненависти к PHP, сдержанного отношения к Perl и тихого обожания Python.
:)
Что warning это хорошо — значит, всё-таки баг был отрепорчен не зря.
А у вас какая версия? У меня 5.2.6-pl7-gentoo с E_ALL не ругается…
При том я нашел четвертый вариант результата выполнения кода — строка не меняется вообще:
$ php -r '$foo = «asdf»; $foo[«foobar»] = $foo; var_dump($foo);'
string(4) «asdf»
Например, в том же питоне была выпущена версия 2.6 где при исполнении кода, который поломается в 3.0, выдавались предупреждения.
А все варианты результата этого кода, коих три: "\0oobar", «foobar», и array('foobar' => 'foobar') — вот все эти три варианта проявляются в различных версиях 5.2.x (может быть я все-таки ошибаюсь про все три, но абсолютно точно — два из них в 5.2.х и все три в 5.х).
Отсюда вывод: либо они слишком часто любят ломать совместимость, либо данный интерпретируемый язык не выдает warning-ов при таком очевидном и довольно тривиальном «undefined behaviour» — это его никак не красит.
Стоит также заметить, что в данном случае речь не про стандартную библиотеку, не про криворуких кодеров — речь про дизайн языка.