я люблю openid, поэтому на своём блоге ещё при установке отключил джанговскую систему регистрации и прикрутил openid. С тех пор она стабильно хорошо работала для меня, но так же стабильно порождала жалобы от других людей, что они не могут залогиниться.
сегодня я капитулировал
я отключил родную систему комментариев и приделал к блогу intenseDebate. Всё-таки лучше получать хоть какие-то комментарии в чужую систему, чем не получать никаких в сломанную свою.
ext3 — журналируемая файловая система. Это хорошо, потому что вероятность потерять данные заметно меньше, чем на FAT. Но вот реализация её в линуксе плоха, потому что требует регулярно записывать байты на диск. Частота записи в журнал регулируется параметром commit в fstab и по умолчанию составляет пять секунд. Там это можно поменять, но придётся исправлять и ещё один файл, не помню, какой :)
чем же плоха запись на диск раз в минуту, например? Тем, что оставляя компьютер включённым на ночь или просто на долгое время, нельзя добиться остановки жёстких дисков. Вернее, можно поставить commit=600 секунд, и настроить диск останавливаться уже через минуту бездействия, но так к диску скоро придёт 3.5-дюймовая смерть.
а раз диск крутится, то он шумит, греется и расходует энергию. Парниковый эффект, CO₂, всё такое.
и, насколько я понял, миграция на ext4 тут тоже не поможет
за последнее время мне довелось дважды столкнуться с node.js. Оба раза у меня остались не очень приятные впечатления, поэтому хочу предупредить любопытствующих, чего не стоит ожидать.
во-первых, скажу о самом движке V8, который используется в node.js для выполнения яваскрипта. Сборщик мусора у него какой-то тупой. При обработке больших массивов данных он не включается, даже если скрипт сожрал всю доступную память и жестоко свопится. Его можно вызывать вручную, если запускать node с параметром типа --expose-gc, но работает он не сильно шустро. Профилирование тоже делается довольно неудобно. Сначала оно работает нетрадиционным образом: не буду считать время, потраченное на функцию, а буду раз в миллисекунду проверять, в какой функции я оказался, и собирать статистику по этому. Кроме того, вначале нужно запустить код и собрать статистику в файл, а потом отдельной утилитой смотреть её и пытаться понять вывод утилиты. Отдельно пришлось повозиться с её компиляцией: почему-то используемый для неё scons не догадывался сам, что сборка идёт на 64-битной системе.
во-вторых скажу о самом node.js, который предоставляет для V8 хост-объекты и стандартную библиотеку. Это нечто очень сырое, хотя и активно развивающееся. Да, посвятив изучению и экспериментам много времени, потихоньку осваиваешься. Но вот обычный для всех других малознакомых языков подход «писать код, сверяясь с документацией» здесь не работает совершенно. Документация, во-первых, плохая сама по себе, а во-вторых устаревшая и потому ошибочная. Гугл тем более бесполезен, давая результаты годовой давности. Да что там документация — я был на двухдневном семинаре по node.js, и там автор книги про это давал нам примеры и задания с уже несуществующими вызовами API.
в-третьих, менеджер пакетов npm стоит отдельного проклятия. Ещё можно понять, почему для каждого пакета он качает строго указанные в описании версии зависимостей — в настолько быстро меняющемся проекта это необходимо. Но зачем же складывать это рекурсивно в подкаталоги? И зачем дважды менять расположение папки с пакетами? Вычищать его потом пришлось из трёх разных мест.
в-четвёртых, для работы с графикой там есть идеологически очень красивый подход: раз браузер рисует графику, используя Canvas, мы сделаем для node.js свой Canvas, и можно будет гонять один и тот же код на сервере и на клиенте. Да, это здорово. Только очень медленно, и API ужасно бедный по сравнению с любой графической библиотекой.
и вот к чему это всё привело. Несмотря на свою давнюю и глубокую любовь к яваскрипту, я переписал код на питон, и он стал работать в десять раз быстрее, выдавая в несколько раз лучший результат. А с node.js я подожду экспериментировать ещё пару лет, пока он не перестанет бурлить.
недавно я решил настроить подсветку кода в своей IDE под себя и обнаружил удивительную вещь. По умолчанию в коде полужирным выделялись «ключевые слова», а имена переменных, методов и всего остального отображались обычным шрифтом. Стоило только обратить на это внимание, как вся нелепость такого подхода стала буквально бросаться в глаза.
самое важное в коде — это имена объектов, с которыми ты работаешь. Всякие if, function, фигурные скобки и так далее служат необходимой синтаксической обёрткой и только. Конечно, без них никуда, но по важности им далеко до имён объектов. Если удалить их из кода, он всё равно останется более-менее осмысленным, а вот если удалить имена объектов, смысл в оставшемся тексте будет очень сложно найти. Вот парочка примеров.
недавно мне пришлось по очереди настраивать два ноутбука, и чтобы не прыгать от клавиатуры к клавиатуре и от мыши к тачпаду, я снова воспользовался маленькой, но очень удобной программкой Synergy. Она просто подключает мышь и клавиатуру одного компьютера к другому по сети. Достаточно перевести мышь за правую (на выбор) границу одного экрана — и она оказывается на другом. Работает в винде, линуксе и маке, андроиде и ифоне настроек почти не требует. Рекомендую.