Category: литература

Последние дни Курсива

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

Спустя четыре года Анатолий Левенчук переподнял эту же тему в блогпосте Мелкая моторика и интеллект, в котором тоже не было достоверно выяснено, а есть ли причинно-следственная связь на самом деле, или всё бабкины сказки.

А сегодня вот ещё что всплыло по теме. Курсив и другие образовательные мифы. Это довольно подпёртая первоисточниками статья, разбирающая эти ваши доказательства про полезность разных аспектов овладения курсивом.

Курсив, кстати, придумали итальянцы, дабы постоянное поднимание и опускание гусиного пера не рвало пергамент. Пергамент, Карл! Гуси, Карл!

Так вот, оказывается, курсивом писать ещё и медленнее, чем своим стилем. Исследование 2013 года. Это самый смешной камень в гроб курсива.

Что неделя грядущая нам готовит #ulsk

Про Ульяновские эвенты.

Originally posted by jay_is_here at Что неделя грядущая нам готовит

Давно что-то я ничего не писал сюда. Все больше по мелочи, да в facebook. Вот, решил немного поделиться планами на грядущую неделю, а она обещает быть насыщенной!

1. В среду, 12 сентября, будет день программиста. Планируется нечто конференцеподобное в «Тарелке» УлГТУ, где, среди прочих докладов, будут кратенькие 5-минутные блиц-презентации более-менее регулярных около-айтишных мероприятий. Среди прочих, будет и презентация «ИТ-посиделок», которые я периодически устраиваю. Собственно, я и буду презентовать. Из «тарелки» народ двинется в клуб «Техас», куда я тоже заскочу на час-полтора, чтобы успеть оттуда свалить до того, как все напьются.

2. В субботу, 15 сентября, пройдет «День свободы ПО». Хотя изначально я довольно скептически относился к этому мероприятию, но Михаил Дронов сделал невозможное и умудрился раскрутить его до вполне себе приличного уровня. У нас уже около десятка потенциальных докладчиков и несколько мастер-классов. Проходить вся эта движуха будет в областной научной библиотеке имени В.И.Ленина. Вроде бы как планируется видео-трансляция, запись докладов и «телемост» с другими группами, отмечающими SFD в России.

Я планирую рассказать о том, почему участие в конференциях и открытых проектах - это полезно и интересно, о грантах в открытых проектах и о том, почему сейчас уже практически нельзя себе позволить не уметь работать с Linux. Рекомендую попасть на этот доклад студентам профильных специальностей, потому что там будет много полезных вещей, которые в ВУЗах вам вряд ли расскажут.

Еще один очень важный доклад для будущих и настоящих программистов сделает Михаил. Он расскажет о свободных лицензиях, об их особенностях и о совместимости лицензий. Это нужно знать, чтобы не попадать в неприятные ситуации, когда заимствованный код или библиотека вдруг оказываются несовместимыми по лицензиям со схемой распространения программного продукта, принуждая либо открыть код всей вашей разработки, либо удалить «несовместимый» код. К сожалению, этого вы в университетах тоже пока не услышите, хотя наметки есть.

Есть еще пара готовящихся сюрпризов, связанных с SFD, но они пока под вопросом, поэтому про них я напишу потом, по мере готовности :)

Если кто-то хочет что-то услышать или увидеть, а еще лучше - что-то рассказать или показать - обращайтесь любым способом ко мне или организаторам SFD. Ну или хотя бы прямо тут, в комментариях :)

Мир компьютеров (1988)

Из последней поездки в Россию вернулась реликвия. Одна из первых книг по компьютерам, которую я прочитал. Читалась запоем, но небыстро — слишком много концепций было впихнуто в эту книгу. 1988 год. Перевод с японского, очевидно.



Семиуровневая модель иерархии протоколов ISO OSI.



Тогда это выглядело местами как научная фантастика. Сейчас только-только элементы из этой книги начинают свой путь в повседневной жизни. Например, электронные доски, которые сейчас валом закупаются в школы (и школы потом не знают, что с ними делать):



Телеконференция. Только в 2006 году я впервые увидел такое вживую. Обратите на сходство книги и реальности двадцать лет спустя.



Ну и DES, конечно, куда же без DES в восьмидесятых.



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

Хотите узнать главное отличие Маков от Винды?

Сергей Булаев (Интернетные штучки, etc) наткнулся на известный эффект различия в идеологии многооконной работы между маком и виндой.

Не знаю почему, но стоит виндоузятнику сесть за мой ноут, скажем проверить почту, первым делом производится попытка увеличить окно браузера до максимума. И это при разрешении монитора 1920x1200. Я давно уже отвык от этих странностей.

Это абсолютно стандартная практика, проверенная уже на десятках друзей. Единственное что я могу предположить - походу в винде, в отличии от маков, не особо удобно работать с несколькими окнами на десктопе.
http://bulaev.org/10150221

Этот эффект неоднократно описан в литературе по UI дизайну, и замечается достаточно быстро с переходом на мак.

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



В чём прикол? В маках зелёная кнопка со значком плюсик не предназначена для распахивания окна на полный экран. В наш век экранов с двухтысячепиксельными разрешениями мало какое приложение может рационально отобразить информацию на таком пространстве. Открой тот же браузер на полный экран — и все эти «тянущиеся» дизайны, не говоря уж про plain text, превратятся в набор длинных строк. Длинные строки — это зло, пока переносишь взгляд от правого края экрана до левого, ты забываешь на какой строчке этот взгляд должен в итоге остановиться. Ширина строчек в книгах — 60-70 букв по горизонтали, не больше. Журнальная и газетная вёрстка — и того у́же, и не без причины. Распахивание на полный экран — неработоспособная парадигма для современных разрешений.

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

Нажатие на зелёную кнопку убирает скроллбары.

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

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

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

Естественно, контекста может быть слишком много: никому не нравится, когда из его экрана торчит множество одновременно движущихся червяков и выедают мозг. Защита от распыления внимания на маке состоит из следующих моментов:
  • Реальный, (почти) удобный механизм рабочих столов. Да, как на юниксах. В отличие от винды, в которой приложения упорно не желают мириться с разными десктопообразующими тулзами, и постоянно брыкаются. В итоге разные активности просто размещаются в разных рабочих пространствах, группируясь по любым критериям, типа "работа1", "работа2", "развлечения", и поэтому один визуальный контекст с несколькими одновременно видимыми приложениями не мешает другому.

  • В маке нет этих вечных всплывающих балунов. Сеть воткнули, выткнули, потеряли устройство, вставили устройство, нужен апдейт, апдейт устанавливается, апдейт установлен, антивирус протух, антивирус просканировал и не нашёл, антивирус просканировал, нашёл и полечил, etc. Эти вещи назойливо вмешиваются в рабочий процесс даже если распахиваешь какое-то окно на полный экран. Винда просто задолбает асинхронными нотификациями. Мак обычно таких вещей себе не позволяет.


Так всё же, как более удобно, с распахиванием окон на полный экран, или без этого? Думаю, что лучше всего иметь гостевой комп с виндой, если уж гости такие гики, что предпочитают клавиатуру водке.

OCaml LRU

The quality of programmers is a decreasing function of the density of GOTO statements in the programs they produce."
— Edsger W. Dijkstra
Никто уже давно не пишет нигде GOTO. В нашем репозитарии их всего четыре штуки, и те — во втащенном стороннем Perl'овском коде. Но зато велосипеды похожего порядка величины изобретаются сплошь и рядом.

Внезапно стал необходим LRU кэш на OCaml'е. LRU (Least Recently Used) кэш — это такая конструкция, которая обеспечивает хранение наиболее часто использующихся данных. Если данные не используются, добавление новых записей в LRU приводит к вымыванию наименее использовавшихся данных из конца гипотетического списка, отсортированного по уменьшению частоты использования.

(Предупреждаю вопрос "почему не memcached?": потому что значение по ключу у кэша для этой задачи измеряется в мегабайтах, да это и не простой бинарник а очень развесистая структура.)

Стандартно крохотные LRU кеши можно делать на односвязных списках [{key, value}] (O(1) вставка, O(N) поиск элемента),
на двусвязных списках (O(1) вставка, O(N) поиск, чуть-чуть более GC-friendly),
на двусвязных списках + какой-то быстрой структуре для поиска (O(1) вставка, O(D) поиск, где O(D) можно традиционно для хешей считать O(1)).

Последний раз LRU я писал на C (2002-2003?), сейчас нужно было на OCaml. Задача сама по себе элементарная. Если бы не одно "но": связные списки. Писать ещё один двусвязный список в эпоху ракет, летящих к марсу, было бы совсем неоптимальным расходом времени. Если это ещё имеет какой-то смысл в качестве задачи для студентов, то писать связный список опять, тем более, на функциональном языке, вызывает неприятный рефлекс.

Когда я ещё пилил в Netli, наш VP of Engineering однажды подошёл, увидел что я ковыряю <sys/queue.h> (в приличных операционках — man 9 queue), и посетовал: "везде, куда ни придёшь, все пишут свои, глючные linked lists".

Вообще, связные списки (двусвязные в большей степени, но даже односвязные) — это удивительная структура данных. Она относится к числу может быть самых стрёмных структур данных по отношению "баги в имплементации / на сложность концепции". Накосячить в doubly linked list — проще простого. Проще чем в имплементации Google Protocol Buffers, по отношению к объёму соответствующей теории. Проще, чем написать интерпретатор лиспа на хаскеле. Этот факт заслуживает отдельной медицинско-биологической работы на тему зависимости концентрации внимания от простоты задачи.

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

Так вот, так как чего-то похожего на <sys/queue.h> в OCaml'е нет, то забив на NIH-синдром, я полез искать сразу код LRU. Думал, найду LRU — сэкономлю какой-то квант своего времени на имплементации.

Гугление на "lru ocaml" первым же своим ответом вынесло на соответствующую библиотеку Дастина Саллингса Lru.html, которую, к тому же, несколько раз рекомендовали в окамловских списках рассылки. Так как Дастин тоже живёт в Санта Кларе, стало очевидно что я должен использовать именно эту библиотеку.

Первый же тест функциональности модуля Lru с треском провалился.
[vlm@nala:~]> cat test.ml
let _ =
        let lru = Lru.create 42 in
        Lru.add lru "key" "value";
        Lru.remove lru "key";;
[vlm@nala:~]> ocamlopt -o test linkedlist.ml lru.ml test.ml && ./test
Fatal error: exception Out_of_memory
[vlm@nala:~]> 

Понятно, что проблема в lru.ml, ведь не может же быть так, чтобы косяк был в linkedlist.ml, на котором построен lru.ml? Ведь linked list, это элементарная структура данных даже на императивных языках, а уж на функциональных — и того проще! Не может же быть чтобы развесистая библиотека, развивавшаяся в течение нескольких лет и стабилизировавшаяся в районе 2004 года, имела проблему в двусвязных списках?

Или может?

Разобравшись, я отослал патч автору и позвонил ему, с целью поздравить с граблями.

linkedlist.ml.orig linkedlist.ml
@@ -126,7 +126,7 @@
        match l.l with
        None -> ()
        | Some el ->
-               if el = it then l.l <- Some el.next;
+               if el == it then l.l <- Some el.next;
                l.cnt <- l.cnt - 1;
                ()

Это как раз та ошибка, из-за которой программа валилась от Out of memory.

Вот мой квотинг и ответ Дастина:

> It turns out, the bug is not in the LRU library, but in the Linkedlist module. It used structural comparison (el = it) instead of physical comparison (el == it) and probably hit some GC-related timing issue in a newer OCaml version (I don't believe it did not ever work for you, so I presume it worked on some earlier OCaml version).

Hey, that's great. I was just getting that error in something I hadn't touched in a while and assumed for some reason that it was a bug in ocaml (since that was the only thing that changed).


То есть, компайлер сменился, и код двусвязного списка вдруг перестал работать.

В итоге, я потратил на то чтобы разобраться с проблемой и накатать этот пост больше времени, чем заняло бы создание собственной имплементации LRU. Всенепременнейше, со своими собственными багами.

[1] Evolutionary Trends of Programming Languages, 2003
[2] http://rosettacode.org/w/index.php?title=Doubly-Linked_List_(element)

Ласточко с веслою

Воскресенье. Утро. Солнце! Птички поют!

Марк проснулся, пробирается к нам в комнату и начинает бесноваться.

Едва проснувшаяся Олька из-под одеяла читает ему стихи, чтобы чуть-чуть отвлечь от деструктивных намерений:

— Утро наступило
Солнышко взошло
— эээ, как там дальше ... (Марк отковыривает от стены доску и с ней наперевес с восторженным воплем несётся в нашу кровать)
Ласточко с Веслою
В сени к нам влетло!
— %-O

В чём сила, брат?..

как спекулянты продают книжки на Амазоне... пару дней назад смотрел — ещё баксов стописят стоила, а теперь — четверть жигулей %-O



Ну и естественно, что в этой книге circa 1996 есть то, чего нет в Июльской (2007) новейшей книжке за девятнадцать баксов :(

(no subject)

Вычитал вот...

В кругу облаков высоко
Чернокрылый воробей
Трепеща и одиноко
Парит быстро над землей.
Он летит ночной порой,
Лунным светом освещенный,
И, ничем не удрученный,
Все он видит под собой.
Гордый, хищный, разъяренный
И летая, словно тень,
Глаза светятся как день.

("Стих № 2", П. И. Карпов. Творчество душевнобольных и его влияние на развитие науки, искусства и техники.)

Что-то это мне напомнило... А, вот что:

Вот воробей летит
и шевелит ногами.
А я его поймал
И отпустил руками.

Методическое указание: попытайтесь визуализировать
процесс полёта воробья.


Это уже необезяевщина, © 1997 Лайдер.

Книги, которые мы читаем

Возвращаясь в штаты 11-часовым перелетом, от нечего делать разглядел названия книжкек, которые читали соседи.

Одна пассажирка читала труд И.П.Неумывакина, "Перекись водорода. Мифы и реальность."


Вторая пассажирка читала Dean Koontz, "Velocity".


Я же в это время пытался продраться сквозь реферат "Химический состав молока" с 5ballov.ru :) Узнал про закон Вигнера: "Содержание различных составных частей сухого вещества молока колеблется тем меньше, чем в более тонком распределении они присутствуют в молоке".