Блог:Виталий Филиппов

Вот есть обычный crowdfunding. Но там для финансирования с идеей должен появиться (будущий) автор проекта.

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

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

Тьфу ты, никак не настрою я этот хоббикинговский клон 250го T-Rex’а. FBL сделал, контроллер поставил и он вроде даже пашет, но теперь хвост, сцука, вообще не держит. Беда в том, что в хвосте люфт просто конский, а такой настройки, как задержка, у контроллера (CopterX CX-3X2000) нет. То есть, чтобы он полетел, нужно хвост менять либо на новый Align’овский, либо на что-то в духе Microheli MH-TX2142TST Precision CNC Aluminum Tail Set Pro (TITANIUM) — T-REX 250/SE. Для ремня и то, и то стоит баксов по 60. Для вала Align даже дороже.

То есть, получается, нужно было сразу взять за 300$ нормальный BNF Align TREX 250 Plus DFC, плюс OrangeRX DSM модуль, и не выпендриваться. Ибо 300$ в свой я уже явно влупил… Только разница в том, что Align бы за эти деньги летал, а этот кусок говна — не хочет. У Align и хвост правильный (конструкция хорошая, привод вальный), и голова DFC’шная, и 3GX (что удобно хотя бы потому, что вороха проводов нет), и движок нормальный, и электроника тоже…

Было бы даже лучше, если бы я просто сам собирал HK-250GT с хоббикинга, потому что весь комплект железа стоит 30$, а электроникой закупиться на хоббикинге нормальной легко (движок 10$ + регулятор где-то те же 10$ + сервы цифровые по 4-5$ + фбл голова 20$ + фбл контроллер 55$ + приёмник по вкусу 20$). Хвост, правда, всё равно бы пришлось менять на align (+60$), и всё равно под вопросом была бы беспроблемность этого фбл — эти китайцы всё равно нет-нет, где-нибудь, да налажают. Итого всё равно 225$ — если повезёт и оно таки полетит.

Но я-то вообще дурак — зачем-то взял CopterX 250 за 150$, плюс потом всё равно поменял приёмник (20$), сервы поменял сначала на аналоговые (4*2.5$), потом на цифровые (4*5$), голову всё равно поменял на фбл (20$), соответственно фбл контроллер тоже поставил (50$), это вот его мне почта про*бала и пришлось повторно заказывать (и хз ещё когда за прошлую попытку деньги вернут). Плюс зачем-то взял program box для контроллера и не стал брать usb кабель — мало того что кабель 5$ стоит, а коробочка 32$, так ещё через кабель прошивку обновить можно, а через коробочку, очевидно, нет! Движок я не менял, но работает он со страшным звуком (смазка? не, не слышали). А, ещё что характерно — штатный гироскоп CopterX хороший — из всех, что я пробовал, с этим люфтящим хвостом справлялся только он. Но в смысле ФБЛ толку от этого нет, всё равно сам контроллер за хвост отвечает.

Итого уже 302$ потрачено, а вертолёт всё ещё не летает. :) короче, как ни крути, а за 300$ align — это хорошее предложение.

Сервис бесплатных голосовых звонков Viber выпустил официальный клиент для Linux. На фотке к новости указана некто "Алина":

И комменты...

Скоро будет скайпкапец. Появляются альтернативы.

Хрен редьки не слаще. Если б с открытым кодом, да с возможностью установки на свой сервер, да с выбором метода шифромания, тлгда да.

Плата-клон TDM400P — от 2.5к р., модуль FXO — от 1.3к р.
Asterisk и туева хуча софтфонов — бесплатно.
Strongswan — столько же (если шифрования SIP недостаточно).
Опыт настройки — бесценно.

Миша: Маш, как тебе позвонить?
Маша: Плата-клон TDM400P, модуль FXO, Asterisk, Strongswan…

Миша: хорошо, что есть Алина…

Что-то этим летом опенсорсники болеют. Один за другим проекты, бывшие бесплатными, делают либо платными, либо добавляют платные сборки по неслабой цене:

• Parted Magic — автор, не меняя лицензию, сделал 5$ за скачивание любой сборки. В принципе, без смены лицензии и отсутствии запрета на распространение сборок — это такой себе «принудительный донейт» автору. В общем-то автор, конечно, джедай — хотел всего 1200$ в месяц… на себя и ЖЕНУ. Ему несколько месяцев недодали, и он решил принудительно пособирать.
• Proxmox VE — лицензия не менялась (AGPLv3), но стали сильно предлагать всем использовать ынтырпрайз-репозиторий обновлений за 50/200/400/800$ в год за каждый CPU (примерно 4/17/33/66$ в месяц, всё что дороже 4$ — с поддержкой разных уровней паршивости).
• nginx — лицензия BSD, сделали платную версию, 1350$ в год за каждую установку, с некоторыми дополнительными плюшками.
• RhodeCode — был GPL, стал частично-GPL/частично-проприетарный (что могли, то сделали не-GPL), цена 50$ в месяц (600$ в год) за 50 юзеров, или 300$ в месяц (3600$ в год) за сколько хочешь юзеров. Плюс у них появился хостинг, но как он будет с github и bitbucket конкурировать — понятия не имею.
• GitLab — был просто MIT, а теперь появится закрытая сборка за 20$ в год за каждого пользователя с шагом 20 пользователей. То есть, например, 400$ в год (33$ в месяц) за 20 юзеров, 1200$ в год (100$ в месяц) за 100 юзеров. Фичи, бывшие открытыми, обещают оставить открытыми навсегда, а что будет в ынтырпрайз-сборке — даже пока не решили.

Самое «интересное» — это когда оказывается, что за изначально платный софт нужно платить один раз при покупке, а за «типа опенсорс», «типа сельфхостед», «типа не-сервис» — нужно платить каждый год, да ещё и в зависимости от количества юзеров / процессоров / ещё какого-нибудь фуфла. По сравнению с этим автор Parted Magic ещё нормально деньги берёт.

Как-то это обидно, когда вдруг оказывается, что опенсорсники-то — не опенсорсники, а какие-то коммерсанты паршивые. Балмер покусал?

UPDATE: О, кстати — а это получается что, RhodeCode, обслуживающий 51 пользователя, авторы оценили почти в 3 РАЗА дороже, чем NGINX PLUS?!!!! У них там совсем крыша поехала?

См. https://bugs.php.net/bug.php?id=65340

При использовании __set() объект почему-то занимает в 2 раза больше памяти O_o

Тестовый скрипт:

<?php
 
// Memory leak somewhere around __set?
 
class A
{
    var $data = array();
    function __get($k)
    {
        return $this->data[$k];
    }
    function __set($k, $v)
    {
        return $this->data[$k] = $v;
    }
}
 
$b = new A();
 
for ($i = 0; $i < 500000; $i++)
    $b->{"a$i"} = 'abc';
var_dump(memory_get_usage()); // int(78318488) - why so big?
$c = clone $b;
unset($b);
var_dump(memory_get_usage()); // int(42220972) - OK
 
unset($c);
$b = new A();
for ($i = 0; $i < 500000; $i++)
    $b->__set("a$i", 'abc');
var_dump(memory_get_usage()); // int(42221492) - OK

Почему-то первое значение потребления памяти почти в 2 раза больше, чем два других.

3G в мегафоне нормальное — в Москве. Приём хороший. Вот только нужно оно НЕ в Москве. А в МО, например, приём много где не очень. И скорость вроде бы и нормальная — в рамках одного соединения. Но как только соединений становится много, тормоза гарантированы. Как у других опсосов — не знаю, но подозреваю, что вряд ли лучше.

Отсюда — тривиальный хинт: поднимаем туннель домой (ну либо на работу / сервер / ещё куда-нибудь) и лезем через него. Простейший вариант — поднять дома squid и прокидывать к нему соединения путём ssh -L (port forwarding). Либо можно сделать VPN через PPP-SSH и заворачивать в него всё iptables’ом. Либо даже просто OpenVPN поднять.

Облегчает жизнь и увеличивает скорость серфинга весьма глобально.

Серьёзная часть

На официальном roi.ru есть по идее полезная петиция — за отмену последней дебильной фантазии госдуры на тему интернета:

https://www.roi.ru/poll/petition/biznes/otmenit-zakon-o-proizvolnyh-blokirovkah-internet-resursov-ot-02072013-187-fz-zakon-protiv-interneta/

Кто зареган на госуслугах — голосуйте («за», разумеется). Насколько это полезно — хз, но явно не вредно.

А теперь бугагашечка

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

«Закон о тишине, проживания в жилых домах»

«Основные цель:
В целях обеспечения комфортного проживания, ограничить строительные и ремонтные работы в многоквартирных домах в выходные дни и не рабочее время с 18.00 до 10.00.
Основные причины, что ремонт затрагивает затяжной характер, который не обеспечивает защиту граждан от отдыха после работы, детей до 14 лет и т. п.
Проблемой первораторго шума в домах до 23.00 остро стоит во всех регионах и это время необходимо снижать.»

ААААААААААААА!!!!! У меня PARSE ERROR!!!!!!!!

Или вот такое:

«Поощрение владельцев велосипедов»

«Из-за увеличения граждан владеющих автомобилем, в дальнейшем возможен транспортный коллапс. Переход на велосипеды позволит снизить текущую ситуацию и ситуацию в дальнейшем.»

Снизить. Ситуацию. Ну да, а то граждане увеличиваются, всё правильно.

Или просто вот такое:

• «Цена литра бензина в России не выше 10 рублей»
• «Вынести Ленина из Мавзолея и похоронить»
• «Возродить СССР»
• «Легализация короткоствольного огнестрельного оружия»
• «Обязательный опрос дембелей об обороноспособности страны»
• «Внесение изменение в работу Почты России»
• «Легализация проституции»
• «Минимальная заработная плата 25 000 руб.»

Без вот этого почёсывания TRACE не пашет!

sysctl net.netfilter.nf_log.2=ipt_LOG

Хм! А в AMOLED-то на Galaxy S4 чёрный всё-таки не совсем идеальный!

То есть если в тёмной комнате пустить на включённый экран чёрный цвет, будет явно заметно, что он светится, причём красноватым светом.

И самое главное — светится сильнее, чем экран первого Galaxy S!

На первом S чёрный действительно практически идеальный. То есть, тоже капельку светится, но настолько слабо, что заметить это свечение тяжело даже в тёмной комнате. А на S4 достаточно заметно.

Это что ж получается — типа, виден ток утечки транзисторов?

Или это ШИМ никогда до нуля не закрывается, даже на чёрном цвете? Регулировка яркости там вроде ШИМом с частотой 240 герц сделана. О, кстати! А ведь на первом Galaxy и ШИМа тоже не было. ШИМ хорошо видно, если на средней яркости помахать перед экраном карандашом — будет заметен «повторяющийся след» от карандаша. Прикольно.

Ну ладно. Экран всё равно хороший, и контрастность всё равно почти идеальная, пусть и похуже первого Galaxy. Ну и ШИМ — хрен с ним, с ШИМом. 240 герц — это не страшно, по идее. Зато, типа, цвета более правильными быть должны, засчёт возможности их точной регулировки…

Эксперимент с UBIFS на флешке, кстати, не удался.

При первом же нештатном отключении питания ФС мгновенно развалилась. Вероятно, из-за наличия промежуточного уровня в виде block2mtd, которое привело к неатомарности каких-нибудь операций. Это при всей хвалёной крашеустойчивости UBIFS’а. Ну а fsck для него, собственно говоря, вообще отсутствует, так что исправить побившуюся ФС можно только путём полной перезаливки.

Зато пришла в голову идея — а нафига собственно вообще нужны лог-структурированные ФС? По-моему, успех SSD’шек доказывает, что более грамотный подход — совершенно обычная ФС поверх дополнительного уровня трансляции, обеспечивающего лог-структурированность. А такой уровень ведь по идее вполне элементарно реализуется (по крайней мере, для USB флешек). Я вот думаю, может даже попробовать его написать?

«Nepomuk требуется Akonadi — кто все эти люди?!!11»

Пилять, я вот всё равно считаю, что Akonadi и тем более Nepomuk, Strigi и прочая семантическая муита в KDE 4 — полное дерьмо.

С Akonadi в почтовике KMail вместо ОДНОГО процесса, жрущего 100 % CPU, мы имеем ЧЕТЫРЕ (kmail + akonadiserver + akonadi_maildispatcher_agent + mysqld). Не, я вижу, что оно улучшается со временем: в 4.8 KMail, кроме CPU, сжирал ещё и всю доступную память. В 4.10 он улучшился и теперь жрёт только CPU.

Нахера было этот маразм плодить? Мало тормозов, давайте ещё межпроцессные коммуникации замутим? Например, akonadiserver, насколько я увидел, вообще только дирижирует всем этим оркестром, но при этом жрёт 60 % одного ядра. Кстати, нормально работать с базой данных они тоже не умеют — если включить лог запросов mysql, там будет сплошной «lambda-walk», то есть чтение записей по первичному ключу ПО ОДНОЙ в цикле. Что за идиоты это писали?

А сколько процентов линукс-юзеров использует этот сраный непомук? В гугле первый же вопрос — «КАК ИХ ОТКЛЮЧИТЬ?»

В итоге кроме, блин, ОПЕРЫ (!!!) я пока не могу найти Linux-почтовик, который бы банально справился с моей рабочей почтой (а там всего-то 65к писем на IMAP’е). Thunderbird загрузить её осиливает, но дико жрёт при этом память и намертво зависает при попытке выделить и удалить 10к сообщений, упавших от мониторинга (и по-моему вообще в итоге по OOM сваливался, насколько я помню). KMail, как я уже сказал, жрёт CPU вообще всё время, а с учётом ЧЕТЫРЁХ активных процессов при проверке почты нагружает систему ТАК, что аж курсор мыши подтормаживает.

Причём оно же ещё имеет свойство самозапускаться при некоторых условиях несмотря на StartServer=false в ~/.config/akonadi/akonadiserverrc. Я в итоге его отключил так:

Options="UNIX_SOCKET=/var/run/mysqld/mysqld.sock_XYU_BAM"

Отстой какой-то))

И оптимальна для флешек всё-таки UBIFS. Так как

• Наиболее шустрая
• Поддерживает сжатие — я вот реплику поднял, у меня 2.4гб базы в 800мб реальных пожались
• Со свежими ядрами и CONFIG_MTD_UBI_FASTMAP=y быстро монтируется (не требуется сканирование всего девайса при монтировании)

Я до вчерашнего дня думал, что USB флешки и карточки памяти — это практически голая флеш-память. А оказывается, нет — любая флешка/SDшка/CFка имеет внутри себя тупой, но всё-таки контроллер с тупым, но всё-таки FTL’ем (Flash Translation Layer’ом), который даже умеет какой-то wear leveling.

Тупой контроллер потому, что мелкий и ресурсов у него мало. В частности — мало памяти. Именно из-за этой тупости случайная запись на флешки/SD/CFки так дико тормозит. Из-за малого объёма RAM контроллеру флешки, в отличие от контроллера SSD, негде хранить полную таблицу сопоставления виртуальных и реальных секторов. Поэтому мапятся не сектора, а крупные блоки по где-то мегабайту (бывает и больше), а при записи есть лимит на количество «открытых» блоков.

Как это происходит:

• Допустим, вы пишете в сектор X.
• Контроллер отображает блок, которому принадлежит этот сектор, на реальный блок, и «открывает» его — выделяет пустой блок, запоминает, что он «дочерний» для открытого и записывает туда один изменённый вами сектор.
• Таким макаром можно открыть максимум N разных блоков; N обычно очень маленькое — в районе 3-6. Вот у меня на столе лежит флешка, у которой 6.
• Дальше если вы пишете следующий сектор из уже открытого блока — он просто записывается в его дочерний блок (что быстро).
• Если же следующий записываемый сектор принадлежит другому блоку — какой-то из открытых блоков придётся закрывать и сливать содержимое дочернего блока с оригинальным.

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

И поэтому авторы всяких UBIFS и JFFS2 не совсем правы, когда говорят, что эти ФС не предназначены для блочных устройств, а только для MTD (MTD — это как раз голая флеш-память). Ибо даже если смонтировать флешку в UBIFS через block2mtd, то скорость записи мелких файлов кардинально возрастает и становится вполне похожа на скорость нормальной последовательной записи. Это, может, и не совсем оптимально — UBIFS сама занимается стиранием блоков, а в случае USB флешки этого можно было бы не делать. Но всё равно она сильно быстрее, чем использование обычной НЕ лог-структурированной ФС.

У меня вот идея маленькую реплику MySQL повесить дома на флешку с UBIFS. Дело в том, что когда я прошлый раз пробовал повесить домой реплику с сервера, она меня достала постоянным шуршанием харда :)

Кстати, выяснить размер стираемого блока и лимит числа открытых блоков своей флешки можно утилитой flashbench и делением отрезка пополам:

Размер блока

запускаем flashbench -a /dev/sdc, смотрим на вывод. Начиная с какого-то размера блока число в последней колонки становится сильно меньше — значит размер блока равен оному из предыдущей строки. Этот размер и надо использовать в драйвере block2mtd.

Лимит блоков

запускаем, варьируя Y путём деления отрезка пополам flashbench -e 4M --open-au --open-au-nr=Y /dev/sdc. 4M здесь — размер блока, полученный в предыдущем пункте (необязателен, но с ним удобнее). Пока Y <= лимиту блоков, скорость в зависимости от размера записываемого блока падать не будет. Как только Y превысит лимит блоков, скорость сразу начнёт падать в зависимости от размера записываемого блока почти линейно.

Ё-маё!

Оказывается, эти УРОДСКИЕ гугловые редиректы (google.com?url=…) не только отслеживают все ваши клики, а ещё и портят заголовок Referer! Раньше было очень удобно — поисковые запросы, по которым пришли на твой сайт, можно было собрать прямо из логов апача.

А сейчас — Х*Й! Потому что при переходе там адрес именно google.com?url=…, а в нём параметра ?q=… НЕТ! И это я уж не говорю о том, что тупо по клику правой кнопкой мыши «Копировать ссылку» невозможно — получаешь мусор вместо нужной ссылки.

Козлы. Ну и яндекс — тоже козлы, они так же делают.

Короче, срочно всем ставить мой юзерскрипт, который это дурацкое поведение отключает:

• «Google Tracking Be Gone» — http://userscripts.org/scripts/show/120330

Работает в FF+Greasemonkey, Chrome, Opera.

Вот такой клёвый чувак-лифтомотор водится у нас на работе, на инструкциях пользования пассажирскими лифтами ТЕХНОЛИФТ:

Это я его векторизовал с исходника:

Хе-хе. Переписал свой шаблонизатор 4-ый раз с 2006-го года — теперь на LALR(1). Поводом послужило упирание в глубину стека при рекурсивном спуске :-D смешно, да. До этого шаблонизатор был сначала стырен с phpBB (он там вообще примитивный был), потом переписан на регэкспы, потом на поиск подстроки, а потом всё-таки добавились операторы, появилась грамматика и я его переписал ещё раз — на рекурсивный спуск. Теперь вот до LALR(1) с помощью PHP-генератора парсеров LIME (типа, по мотивам lemon’а сделанного) добрался.

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

То есть — лексический анализатор понимает, когда находится внутри директивы, а когда вне, и возвращает соответственно просто куски шаблона литералами, либо прочие лексемы внутри директив, а также пропускает текущую директиву при возникающих ошибках разбора, отлавливая их. Для чего, кстати, пришлось допилить сам LIME — см. https://github.com/vitalif/lime — и окончательно прочувствовать алгоритм работы LALR(1). :) он вроде был курсе на 2-ом, но я его тогда как-то не особо прочувствовал. Или не было?.. Не помню точно.

А ещё я как-то не осознавал, что первым теорию формальных языков Хомский, который лингвист, придумал (ну или структурировал, по крайней мере).

Дока, кстати, тут — Шаблонизатор VMX::Template.

Посранивал тут я гриды. А именно, jqGrid и, в очередной раз — dhtmlxGrid и ещё ExtJS’овский грид. И хочу сказать — блин, какое-то фуфло))

1. С ExtJS всё понятно — он в своём обычном репертуаре: умеет почти всё, но ТОРМОЗИТ, требует МЕГАБАЙТ JS’а и долгое и мучительное конфигурирование — даже чтобы сделать в гриде тупой селектбокс, нужны дополнительные извращения. И баги там тоже есть — например, я не смог добиться, чтобы TreeGrid при изначальной загрузке полностью разворачивался — если указать expanded=true для всего, то при загрузке часть записей оказывается не на своём месте в иерархии (лечится сворачиванием и разворачиванием). Если же попытаться сделать expandAll по событию load, то все записи дублируются, и это уже не лечится никак. Кроме того, сегодня на работе долго ловили баг — в Store запись есть, а в гриде её нет. Кстати, я что-то даже не дождался окончания ловли. Но код аккуратный, это да. И документация хорошая.
2. jqGrid умеет довольно много, но всё равно меньше, чем ExtJS’овский. Например, не умеет drag’n’drop-ом перемещать элементы в иерархии. Но главный минус — он ещё и весь какой-то КОСОЙ! Даже единого стиля названий методов/аргументов не выдержано, и документация хромает (не очень качественно сделана на dokuwiki). Опции для селектов зачем-то задаются в одной строке типа "id:name;id:name;id:name" и т. п. Да и конфигурируется тоже не особо легко.
3. А вот dhtmlxGrid — хороший пример, он реально быстро работает и очень прост в конфигурации, и всё бы хорошо, если бы не одно «НО»: его полная версия, сцука, ПЛАТНАЯ :-(! Ну и собственно даже платная версия имеет странную лицензию — например, там есть пункт «The Licensee is not permitted to distribute the component(s) or its part(s) in any fashion which would promote, encourage, or allow reuse or redistribution of the JavaScript component(s)». Бугага. Это по их мнению вообще выполнимо в случае JS? А также вызывает вопрос — хотя бы продавать-то софтину, в составе который эта хрень тусуется, можно?
   Но в целом, несмотря на отсутствие TreeGrid’а и полезных фишек типа фиксированных колонок мне GPL’ный вариант dhtmlxGrid’а всё равно нравится, ибо он БЫСТРЫЙ. Хотя внутри красота кода, по-моему, явно хромает.
   Также теоретически, если никто не увидит :), то можно наверное стырить JS-ники со страничек с примерами про-версии.

Чудесный коммит, устраняющий опечатку.
Из-за опечатки при удалении bumblebee удалялся весь /usr.
Баг был быстро пойман и исправлен, что не помешало багтрекеру проекта на github стать на несколько дней филиалом форчана, с макросами, пони и прочим. (c) Lurkmore

А вот тот самый коммит:
https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac

Мелкософт решил в очередной раз сократить издержки и перейти на WebKit поменять модуль проверки орфографии с хорошего (ОРФО) на плохой (свой на основе стыренно-купленных у ОРФО словарей). Результаты этого видны невооруженным глазом — теперь можно писать: нармально, промышленость, спакойненько, децком, сапогов, теоритически, словестный. А верные слова, наоборот, часто подчеркиваются красной чертой — «ежесезонный», «всеевропейский» и многие другие будут считаться ошибкой.

Самое эпичное — если Word 2013 не находит в своем словаре некоторое слово, часто он пробует разделить его на два так, чтобы каждое было ему известно. В результате получаются следующие курьезные подсказки:

• Профкомовец → подсказка Word 2013 — «профком овец»
• Беспрограммный → «бес программный»
• Обломовцы → «облом овцы»
• Дизайнерша → «дизайн ерша»
• Задобреет → «зад обреет»

И прочее.

А вот тут небольшая история про то, как оно произошло — http://roem.ru/2013/02/19/addednews64105/ — от Ашманова, который в итоге купил Информатик. Вот так вот оно, проприетарщину проприетарщикам продавать — стырят и ухом не моргнут :-)

Плюс комменты с лора из темы про ОРФО:

Ответы на коммент: 5 лет назад, когда я пробовал OpenOffice Writer, мне этой штуки больше всего не хватало.
А в Calc — русских формул.

1. Боюсь спросить о любимом языке программирования.
2. Я всегда тащился от функции «ЧИСТРАБДНИ» — всегда очень хотелось ЧИСТРАБДНуть что-нибудь в ответ — знать бы, в чем состоит это действие :(

Про JavaScript[править]

JavaScript — это, конечно, хорошо, но всё-таки лучше, когда его на странице настолько мало, насколько это возможно.

Ибо иначе… вот прямо пример: сделали Википеды WikiEditor. Всё хорошо, удобная новая панель редактирования (увидеть можно, нажав править на любой странице википедии), с ajax-предпросмотром, тоже удобным, все дела.

Но вот вопрос — ЗОЧЕМ было его делать на JS ЦЕЛИКОМ? Можно же было эту панельку вывести пыхом, а потом понацеплять к ней обработчики путём JS.

А на чистом JS (+ jQuery) получается так, что всё в колбэках, и в итоге:

☹ Панель появляется не сразу, а через некоторое время (0.5-1 сек) ПОСЛЕ загрузки страницы.

☹ Расширяемость WikiEditor «не очень», и опять на тех же колбэках. И, разумеется, опять же никак не кэшируется.

☹ Попутно появляется довольно неприятный баг — если перейти куда-то дальше, а потом кликнуть НАЗАД, то состояние страницы, а следовательно, и содержимое окна редактирования НЕ ВОССТАНАВЛИВАЕТСЯ! Причём подобное я уже наблюдал с YAHOO UI в багзилле, и оно как-то мистически связано с использованием события onDOMReady (то есть DOMContentLoaded). То есть именно при каких-то действиях браузер перестаёт уметь полностью восстанавливать состояние страницы при переходах по истории. Причём проявляется это везде, в том числе и в IE, и в Опере (которая R.I.P). Но тут надо ещё подходик совершить, повкуривать, может, найду причину.

Про jQuery[править]

Опять-таки, jQuery — вроде, тоже неплохо. Кое-что полезное он содержит, API у него вроде как поудобнее и поуниверсальнее, чем у голого JS.

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

Но есть и (2)ой, возможно, даже более важный минус — повсеместное применение операций над множествами. В чём же минус, спросите вы — это же гораздо удобнее? А вот в чём: если написать что-то не то без jQuery — твой скрипт скорее всего свалится с ошибкой в консоль. А в случае jQuery и операций над множествами что-то просто тихо отвалится — вместо null будет просто пустое множество! То есть jQuery — это дополнительный шаг в сторону типичного скриптового рас!"(дяйства (хотя казалось бы, куда уж дальше-то).

В общем, насчёт важности (2) — хз, конечно. Меня лично больше бесит всё-таки то, что многие уже не в силах писать без jQuery, и 90кб тащат ради скрипта на 30 строчек. Это у меня природное какое-то влечение к упрощению, да.

Так что я испытываю глубокое моральное удовлетворение от выпиливания откуда-нибудь jQuery :-)

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

→ продолжить чтение…