Несколько PHP-ссылок:

• Очередные спичечные экономисты;
• functions_exist() — так и не понял, в чём прикол. Сначала подумал, что это my_function_exists(), но всё оказалось гораздо прозаичнее.

Встретил у Болка запись о том, как формируются номера российских ИНН. Стало интересно, как с этим обстоит дело у нас.

Итак, украинский ИНН (индивидуальный налоговый номер) состоит из 10 цифр. В нём зашифрованы:

• дата рождения (первые пять цифр образуют число, равное количеству дней от 01.01.1900 до даты рождения владельца ИНН);
• пол (чётность девятой цифры: четная цифра – женский, нечетная – мужской);
• checksum, т.е. контрольное число (последняя цифра)

Как считается контрольная цифра я пока что не знаю. Здесь можно проверить, как работает большой брат, исходники большого брата — под катом.

Забавные факты про украинский ИНН:

• физическим лицам, которые из-за своих религиозных или других убеждений отказываются от принятия идентификационного номера, официально сообщили об этом соответствующим органам государственной власти и имеют соответствующую отметку в паспорте, предоставляется идентификационный номер в виде номера и серии паспорта таких лиц (src);
• иностранцы не могут отказаться от кодов, даже если они имеют соответствующие религиозные убеждения. Причина: украинские власти не могут внести соответствующую отметку в их паспорт (см. предыдущий пункт) и присвоить ИНН по номеру паспорта. Зачем нужен украинский ИНН иностранцу? Чтобы иметь возможность стать учредителем юрлица или заниматься предпринимательской деятельностью на территории Украины (src);
• я не смог найти в сети информацию о том, какие ИНН присваиваются гражданам, родившимся в 19 веке (т.е. до 01.01.1900 года).

Отдельно хочется процитировать каких-то религиозных маразматиков (орфография и пунктуация сохранены):

Как здесь не заметить, что определенные проблемы будут ощущать, например, лица, которые изменили свой пол.

Понятно, что не сложно написать программу, которая к 1 января 1900 года прибавит число и получит дату рождения. Так что, милые дамы, со старинным правилом этикета, согласно которого о Вашем возрасте спрашивать было не принято, придется расстаться. У технотронного века свой жесткий и далекий от условностей приличия “этикет”.

Мой вам совет, милые дамы: если кто-то выспрашивает у вас ваш ИНН, отнеситесь к нему с подозрением!

(more…)

Вот тут написано, что изучение любого языка должно начинаться с чтения спецификации языка.

Это неправда, причём неправда вредная.

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

1. не должен быть тривиальным: программа “hello, world!” демонстрирует не то, что вы ориентируетесь в языке, а то, что вы разбираетесь в среде на уровне “куда писать код, как компилировать”;
2. не должен быть слишком большим — вы либо бросите его от многочисленных неудач, либо сваяете совершенно несъедобное гавно;
3. должен быть кому-то нужен: вам необходим “заказчик”. Наличие заказчика не означает, что вы получите деньги за этот проект — какой идиот станет платить за вашу первую программу? Заказчик даст вам боевую задачу и будет выдавать свой feedback в ответ на ваши релизы. Очень важно, чтобы в роли заказчика выступал кто-нибудь другой, а не вы, иначе в случае неудач в освоении языка вы рискуете начать пересматривать функциональность программы, а не рыть землю носом.

   Поспрашивайте друзей, наверняка кому-нибудь из них нужна какая-то программка, подходящая для вашего первого проекта. Доведите этот проект до конца, и вы убьёте двух зайцев сразу: освоите язык и окажете услугу “заказчику”. Кстати, если вы сделаете его счастливым, то он может заплатить вам символические деньги: всё равно на что-то серьёзное с вашим опытом претендовать рано.

А спецификации языка читать конечно надо. Это можно сделать после того, как у вас заработает программа “hello, world!“, исходники которой вы скачаете из интернета.

JavaScript переживает сейчас вторую молодость, среди причин которой AJAX-бум и рост высокоскоростного доступа к интернету.

Банально, на JavaScriptе стали писать больше, чем писали раньше. И выяснили, что на чистом JavaScript много не напишешь: тяжёлое наследие Web 1.0, громоздкая Document Object Model, да и требования кросс-браузерности никто не отменял.

А кодить надо много и быстро, ведь на дворе уже Web 2.0 с его user-generated content, который эти юзеры хотят генерировать не с помощью стандартных кастрированных элементов управления родом из прошлого века, а с помощью нормальных графических интерфейсов, не хуже десктопных.

В результате для убыстрения разработки появились javascript библиотеки, количество которых наверняка перевалило за сотню. Называются они по-вебдванольски модно — “frameworkами”. Их главная цель — снять с кодера всю работу по обеспечению кросс-браузерности, обеспечив удобный доступ к DOM/AJAX и другие приятности, которых не хватает в чистом javascript. Выглядят эти фреймворки именно как библиотеками, подключаемые в документ с помощью тега <script>

Чем универсальнее фреймворк, тем он тяжелее. С одной стороны, это не проблема: есть GZIP, да и средняя скорость доступа к интернету растёт с каждым днём. С другой стороны, зачем грузить больше?

“Стандартом” отрасли ни один фреймворк не стал — все выбирают то решение, которое кажется удобней, и грузят пользователю именно его.

Рассмотрим гипотетическую ситуацию — существование стандартного javascript фреймворка. Стандартность означает поддержку браузерами.

В случае javascript-библиотеки эта поддержка является всего лишь гарантией того, что браузер где-то у себя локально хранит исходный код этой библиотеки. Разработчик может подключить фреймворк точно так же тем же тегом <script>, только грузить код не со своего сайта, а из локальной зоны браузера.

Если бы такой стандарт появился, и стал бы обязательным для поддержки всеми вебдванольными браузерами, то это никак бы не затронуло разработчиков, использующих другие фреймворки: продолжайте подгружать пользователям библиотеки со своего сайта, как вы подгружаете сейчас. Разработчики, перешедшие на этот гипотетический стандартный фреймворк, получают бонус в виде уменьшения времени загрузки кода библиотеки. Соотвестственно, этот стандартный фреймворк мог бы стать действительно мощной библиотекой — грузить-то ничего не надо.

Можно, конечно, пойти другим путём, и вместо такого фреймворка расширять сам язык, чтобы ему не требовались эти костыли. Или вместо одного фреймворка обеспечить поддержку нескольких (вроде FireFoxных аддонов).

Заставить браузеры договориться о такой поддержке будет, наверное, непросто. Но её наличие может стать ещё одним аргументом в их войне. Например, если Firefox начнёт поддерживать несколько фреймворков, а другие браузеры не начнут, то в коде можно будет делать простую проверку на поддержку библиотеки и в случае её отсутствия подгружать библиотеку с сайта, а в случае поддержки грузить локально. Тогда сайты, использующие поддерживаемые фреймворки, начнут натурально работать быстрее в Firefoxе, и медленнее во всём остальном.

Я уже высказывал идею хранения ресурсов, доступных “сайтам из интернета”, в локальной зоне браузера: прошлый раз я предлагал с её помощью реализовать браузерный клипарт. Вообще, идея богатая: в браузер можно напихать много стандартных вещей, и не грузить ими канал, который не резиновый.

Правда, браузеры относятся скорее к консервативному классу ПО (тяжёлое наследие HTML, ага), так что рассчитывать на внедрение такой революционной идеи больше чем одним браузером не приходится. Ведь даже нормальный индикатор аплоада никто до сих пор так и не сделал.

(ага, щаз — может ещё и исходники выслать?)

На самом деле, таких программ может быть две штуки:
1) программа заполнения заданной сетки из большого словаря;
2) программа составления сетки, заполненной словами из короткого списка.

Первая программа достаточно тривиальна — я написал её ещё в школе на паскале, и пользуюсь до сих пор. На том сайте все нетематические кроссворды составлены полуавтоматически: сетка заполняется автоматом (при этом предварительно в сетку можно вписать слова, которые должны войти в кроссворд обязательно), а определения придумываются вручную. Можно было бы, конечно, и определения брать из словаря, но не нужно: нет ничего скучнее кроссворда со словарными определениями.

Вторая программа нужна для составления тематических кроссвордов — составить такой кроссворд с помощью первого метода можно, но для этого нужны очень большие тематические словари. Я ещё не начал писать такую программулину — если честно, даже не знаю, с какой стороны к ней подойти. Требования достаточно формализованы: использовать не менее X слов из заданного словаря, полученная сетка должна иметь плотность не ниже заданного Y, частота пересечений должна быть не меньше Z. Есть идеи, с чего можно начать составление?

И второй вопрос: где можно взять списки русских слов (т.е. словари без определений)? Нужны имена существительные, в именительном падеже — как собственные, так и нарицательные. Если знаете, где взять с определениями, тоже хорошо: я определения выкину нафик, если не подойдут — а определяемые слова оставлю — вот и получится список русских слов.

Update: о боже, wordpress заменяет смайлики на иконки. Я блондинко.

30-го сентября вечером начнётся наша прямая трансляция (с сайта ЦВК) распределения мест в украинском парламенте, как в 2006 году.

Синдикация трансляции: rss; трансляция синдикации трансляции в ЖЖ — 2006_rss

На сайте sports.ru очередное изменение скриптов, на которых работают их блоги.

Как и предыдущее, это изменение связано с новой URL scheme — новой схемой адресации блогопостингов. Прошлый раз спортсрумельцы вместо урла вида blog/?author=utkin&postid=123456 внедрили УРЛы вида blog/utkin/?postid=123456

Подождали пару месяцев — и решили полностью избавиться от Dynamic URLs: вместо blog/utkin/?postid=123456 у них теперь blog/utkin/123456.html

Всё верно; непонятно только, отчего спортсрумельцы так долго шли к этой очевидной схеме. Молодцы, что таки дошли. Только совершенно не молодцы из-за того, что после перехода на новую схему старые адреса перестают работать. Понятное дело, что не хотят нарушать ссылочную целостность — у каждого материала должен быть только один адрес, иначе бардак и плохие позиции в поисковиках. Это похвально. Только, блин, почему не повесить редиректы на старые адреса? Это же три строчки кода с комментариями.

Если сайт перестаёт обрабатывать старые адреса после перехода на новую схему адресации, это очень плохо. Во-первых, перестают работать закладки и ссылки. Во-вторых, сайт проседает в поисковиках. В конце-концов, это очень неудобно и неправильно. Неудобно из-за того, что в RSS-фиде тоже оказываются новые адреса, и в читалке выскакивают 25 непрочитанных записей.

Мне тут в голову пришла неожиданная идея оптимизации кода: убрать на компьютера разработчика функцию copy-paste.
Вопрос: повысится ли качество кода?

Источник: bash.org.ru, удалённая цитата

Ответом на вопрос из эпиграфа будет, по-моему, скорее “да”, чем “нет”. Та или иная ограниченность ресурса (машинного времени), приводит к более эффективному его использованию.

Когда мой учитель информатики работал программистом на большом советском заводе с большими компьютерами, программы для которых писались на перфокартах, скармливаемых компьютерам специально-обученными девочками, у него не было возможности дебаггить программу в реальном времени. Он готовил перфокарты с программой, дожидался своей очереди, отдавал перфокарты с исходниками девочкам и через время получал от них другие перфокарты с результатом работы его программы. Результатами были или искомые данные, или ошибки в том или ином виде. В случае неудачи (представьте, что вы первый раз компилируете программу после того, как она полностью написана — и прикиньте вероятность удачной компиляции) он готовил новые перфокарты и снова ждал своей очереди, чтобы отдать перфокарты девочкам. Чем больше раундов он затрачивал на решение задачи, тем сильнее был нагоняй от начальства. Эти ограничения выработали некоторые навыки компилирования и исполнения программ без компьютера (”в уме” и “на бумажке”).

Когда я учился в школе, у меня не было личного компьютера, машинное время было ограничено уроками информатики в лицее и ИГЗ там же. Компьютерного времени очень не хватало, а программировать хотелось много. Из-за этого очень многие программки писались заранее “на бумажке” (целиком или полностью), а компьютер использовался лишь для ввода, отладки и доводки программы. Иначе (если программировать только тогда, когда оказывался у компьютера) успевалось очень немного — из-за того, что неэффективно расходовалось время. Нехватка машинного времени научила писать программы без компьютера.

Вынужденное программирование без компьютера заставляло больше думать, изменяя стиль программирования: тщательное продумывание алгоритма вместо методичного перебора возможных вариантов решения. При решении алгоритмической задачи всё время есть несколько конкурирующих путей решения задачи. Если у тебя есть компьютер под рукой, то самый простой способ выбрать лучшее решение — это перебровать все способы, которые пришли в голову, и выбрать тот, который лучше всего работает. Это самое простое решение, но оно требует довольно больших затрат компьютерного времени - на ввод и отладку каждого решения с его последующей проверкой. Когда доступа к компьютеру нет, и будет его всего ничего, ты не можешь позволить себе перебирать варианты. Приходится анализировать их в голове (на бумажке) и искать решение “теоретически”.

Самый простой пример: задача — сделать в программе хитрую операцию с большим массивом за наименьшее время. Есть 3-4 способа запрограммировать эту операцию, на первый взгляд все одинаково эффективные. Как будет решать эту задачу глупый программист? Сядет и закодит все решения, посмотрит на скорость работы и выберет правильный. Умный программист прежде чем кодить, оценит каждое из решений в уме, т.е. без компьютера.

Очевидно, что для того, чтобы быть умным программистом, не обязательно быть ограниченным в компьютерном времени. Достаточно выработать в себе привычку не бросаться кодить без предварительного рисования фигнюшек на бумажке. Принудительное ограничение машинного времени вынуждает тебя решать задачу без компьютера, при этом приходится думать. Это ограничение помогает осознать, что в программировании код — вторичен; первично решение задачи (алгоритм, структура данных, правильные подпрограммы и прочее). Свободный доступ к компьютеру развращает программиста — искушение выбрать правильное решение перебровав все варианты велико и часто берёт верх.

Безусловно, некоторые программистские задачи требуют некоторого перебора. Написанное выше относится скорее к алгоритмическим задачам, и решать такие задачи нужно тщательнее.

Возвращаясь к эпиграфу: если запретить разработчику делать copy-paste, то это вынудит его писать правильные (в меру универсальные) подпрограммы, а не плодить код а-ля индус.

Реанимировал свою старую онлайн-забаву: кроссворды, которые можно разгадывать прямо в браузере.

Программинг (PHP/JavaScript) пришлось переделать полностью, зато теперь кроссворды работают в IE, FF и Opera. Пока что на сайте выложено всего два кроссворда (1, 2), но уже можно подписаться на обновления (или добавить во френды).

Если найдёте ошибку — смело пишите в комментарии. Спасибо!

P.S. Ещё придумал уникальный и оригинальный домен для проекта, ага.

Статья о разных аспектах растеризации текста.

Букф многа, картинок тоже немало, ещё и на английском. Но читать интересно.