Музеи бывают разные…

Вот пришла мне сегодня такая мысль: программирование — это тоже искусство, код бывает написан так, что грамотный программист может долго восхищаться тем, как он написан и потом черпать от туда идеи для вдохновления. Например, если говорить о perl — мне очень нравится, как пишет код Tatsuhiko Miyagawa, и что самое интересное — он много очень написал. Например, много полезных приёмов можно подчерпнуть даже в таком хорошем и полезном инструменте для парсинга html & xml, как Web::Scraper — простой то туда пример для программеров перла 😉

Дак вот, я о том, что раз программирование — это искусство, то почему бы, подумал я, не открыть где нибудь музей, где вместо картин были бы исходные коды. Потом моя мысль пошла дальше — мол код интереснее смотреть на экране компа, тем более в цифровом виде — чтобы легче было копипасты делать, проверить если что и т.п.. Значит, музей должен быть в интернете! И вот, подумал я, наверное, я один до этого додумался 😉 Погуглил — как бы не так… Опередили меня ровно на год! По крайней мере в русском сегменте сети.

Итак, встречайте музей программного кода! 🙂

Топология корпораций глазами ученых (заговор?)

Теорию графов применили для изучения структуры мирового рынка

Специалисты по системному анализу из Цюриха доказали, что значительная часть экономики (около 40 процентов) контролируется совсем небольшой долей компаний, куда входят преимущественно финансовые институты. Несмотря на то, что такой вывод подозрительно напоминает классическую теорию заговора, полученный результат является первой попыткой анализа структуры финансовых потоков в экономической системе в целом. Также это отличный повод напомнить читателям «Ленты.ру» о существовании теории графов.

Подробнее — читаем статью на Lenta.RU. Довольно интересно! 🙂

Также, еще здесь:

Первая пятерка самых влиятельных компаний выглядит следующим образом.

  1.  Barclays plc
  2.  Capital Group Companies Inc.
  3.  FMR Corporation
  4.  AXA
  5.  State Street Corporation

От себя: вот эта пятёрка — самое интересное. Ниодна компания мне не известна, но они правят миром

Git и ‘.’ (точка) как remote

Знаете ли вы, что в git символ точка (dot — ‘.’) как имя для remote обозначает текущий репозитарий, в котором вы работаете? Когда-то я мельком нашел ссылку в документации на это, запомнил, и вот сегодня сделал вот это:

git push . my_temp_branch:master
# А так ещё проще и лучше:
git push . HEAD:master

И это сработало! Очень кстати полезно бывает привести ветку (например, master), от которой вы начали продолжать свою временную ветвь,  в соответствие с ней. Первое, что хочется сделать: Читать далее Git и ‘.’ (точка) как remote

Несколько полезных jQuery модулей от Odyniec

Сегодня посмотрел страничку одного разработчика по ник — имени Odyniec. Очень понравились его разработки. Спешу поделиться с вами 🙂

  • imgAreaSelect — jQuery плугин для кропинга (cropping images) картинок (точнее, выделение области — кропинг делайте сами ;-)) — (пример)
  • imgZoom — Красивое листание картинок с анимацией, ротацией и приближением из далека (пример)
  • selectListмультивыборочный select лист, показывающий выбранные опции отдельно с возможностью легкого их удаления (пример)

Также, автор написал несколько полезных статей по CSS (как создать «деревья», «табы»)

Также, автор написал несколько модулей на perl для Dancer (его сайт также работает под Dancer): Dancer::Plugin::DebugToolbar, Dancer::Plugin::DirectoryView

Термин «Lexical scope» в Perl

Довольно часто в документации к Perl встречается такой термин, как Lexical Scope. Однако лично я пока не нашел точного определения этому термину в man-ах perl-а. Порывшись в интернете, нашел все таки точное определение этому термину.

В терминах Perl, lexical scope определяется либо границами файла-исходника (если было за пределами первого блока в файле), либо блоком, в котором определен ({…}), либо внутри «eval». Поскольку блоки могут быть вложенными, то и lexical scope может быть вложенным. Это очень важно понимать, так как некоторые директивы имеют именно этот lexical scope (my, our, package)

Git — начинаем работать :)

Итак, продолжаю группу статей, посвязенных Git — одному из замечательных инструментов по управлению версиями текстовых файлов, а еще более точно — исходных программных текстов.

Этот пост предназначен для тех, кто приступает только работать на Git. Все нижесказанное будет предназначено для Unix окружения и оболочки Bash.

  1. Заходим в Unix, где есть bash & git Читать далее Git — начинаем работать 🙂

perl, utf8 и encode & decode термины

Полезно будет знать Perl программерам. Дело в том, что часто в документациях к perl (perldoc utf8) и модулям (например JSON) употреблаются такие термины, которые лично меня часто путали своим смыслом, а именно: encode to UTF-8, decode to UTF-8. Что подумает нормальный программер, услышав слово encode to? То, что что-то кодируется во что-то, а именно «encode to UTF-8» -> «кодирование в UTF-8». Я знаю, что perl хранит внутри себя строки UTF-8 со специальным флагом — если он установлен — строка UTF-8, если нет — бинарная. Поэтому, когда в доке я читал encode to UTF-8, я все время путался — думал, что говорят про установку этого флага. Оказалось, все в точности наоборот.

Правильно так: когда пишут encode to UTF-8, это значит, что внутри перла строка с UTF-8 данными остается как есть, но флаг UTF-8 убирается, и perl начинает вести себя со строкой так, как будто там бинарные (octet) байтовые данные (то есть посути, строка внутри перла перестает быть UTF8, хотя слово «encode» несет в себе другой смысл). И наоборот — decode to UTF-8 -> UTF8 флаг ставится (то есть для perl-а строка становится UTF8).

P.S. В Perl есть такая функция — encode (модуль Encode). Смысл ее в том, чтобы перевести строку из внутреннего содержания на perl (которое всегда UTF-8 внутри, т.е. Unicode символы) в байтовую последовательность, которая бы отражала ту кодировку, которую ей указали (то есть раз байтовая — значит всегда utf8 флаг в результате отсутсвует). Если мы делаем $result = encode(‘utf-8’, $string), то результат как раз будет в том, что флаг utf8 будет просто снят для $result и в реальности никакого переводирования не будет (то есть побайтово внутри perl-а $string & $result будут содержать одни и те же байты, только $string еще будет иметь взведенный utf8 флаг). И это как раз вписывается в те понятия, которые я описал ранее. Для decode и байтового UTF8 всё обратно — флаг utf8 просто ставится в $result.

Вот такая абракодабра… Будьте внимательны!

Немного о супер направлениях в Web на Perl

Немогу не поделиться своими выводами об изучении нескольких новых технологий в Perl и в Web программировании. Немного предистории.

Я сам программирую динамические веб сайты (CGI) только на Perl. Никогда не использовал PHP. Это не только потому, что я фанат Perl, но и дань эффективности — под Perl много модулей, много возможностей, и при грамотном подходе сайты на Perl будут работать быстрее PHP — ведь Perl код после компиляции хранится в памяти в виде байт кода (типа «Пи кода» кода в Pascal). А если знаешь Perl, то и разработка может идти гораздо быстрее. Читать далее Немного о супер направлениях в Web на Perl

Массивы JavaScript, Internet Explorer и запятые

Заметил такую особенность — если описывать массив как

var array = [
elem1,
elem2,
elem3,
];

То в Firefox и Google Chrome — он будет иметь 3 элемента, а в Internet Explorer (тестировалось в 8-ой версии) — 4 элемента, причем 4-ый будет null.

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

Оказывается, такой стиль имеет скрытую угрозу — ошибки, когда «прогулка»  по массиву дает null элемент, тогда как такой программист предполагал, что будет три элемента и все — не null. Вообщем, программеры JavaScript — остерегайтесь 😉

Читать далее Массивы JavaScript, Internet Explorer и запятые

Опять Cookies, только теперь Google Chrome

Не успел написать программу, как опять наткнулся на неприятность, точнее, на баг. Смысл его в том, что Google Chrome некорректно ставит в JavaScript свойство document.cookie, если кука пришла от сайта с quoted path, то есть, если пришла такая:

Set-Cookie: session=session_ID; path="/"

Дело в том, что путь, заключенный в кавычки — правило, определенное самим RFC 2109 (пункт 4.1). Firefox это обрабатывает корректно, а Google Chrome — глючит. То есть, чтобы в JavaScript от Chrome считывать куки, нужно их выставлять через path без кавычек. Но в любом случае, это некорректно, поэтому отписал об этом на их форум. Посмотрим, как они исправят это 😉