Перевёл недавно команду на VS2013. Сегодня поставил на неё VsVim. И ведь работает. Все плюшки студии с решарпером + оболочка от Vim. Продолжаю погружение в красноглазие.

Вот есть замечательный плагин на wordpress — lj-xp, который использует не менее замечательную библиотеку для xml-rpc. Так эта херня не проверяет — валидный у него там xml получился или нет (наверняка через конкатенацию строк нахерачили xml и думаю, что всё ок). Поэтому я неделю потратил, чтобы разобраться — почему предыдущий пост не доехал до ЖЖ. Поэтому у нас никогда не будет клевых штук.

PS: жж, видимо, перестал через xml-rpc отдавать ID записи, так что редактирование записей через этот плагин тоже сломалось. Вообще нормально.
PPS: отдаёт, но как-то странно. Будем думать, что опять виноваты пхп-кодеры из вордпресса.

А давайте поиграем в задачки.

Дано: посты с комментариями. У постов есть теги, у комментариев есть авторы. Ну, комментарии и их авторы нас пока не интересуют. Лежит это всё дело в СУБД.

Задача: находить все посты, помечены одним или более тегами (теги на вход подаёт юзер). Чтобы распределение данных было близко к реальности, надо чтобы постов было более 100 тысяч, а количество тегов не превышало 2-3 тысячи, в идеале — +/- 1 тысяча. На пост от 0 до 10-15 тегов (техническое ограничение должно отсутствовать, возможность не указывать теги должна присутствовать).

Ответ СУБД должна выдавать за минимально возможное время. Например, на системе без нагрузки после компиляций планов/поднятия кеша с винта — не более 50 мс на один поиск на стандартном десктопе (примерно i7 860 @ 2.8 GHz, 8 Gb DDR3).

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

Для решения задачи можно использовать любую СУБД, обладающую следующими свойствами:
1. СУБД обязана иметь ACID-транзакции.
2. СУБД обязана уметь гарантировать ссылочную целостность данных. Например, через foreign keys.

ЗЫ: я задачку решил и оно используется у нас в продакшене :)

ЗЫ2: важное забыл. Распределение тегов по постам крайне неравномерно. Может быть так, что одним тегом покрыто 10% постов, а другим — 2 (два, не два процента) поста. И находить должно с одинаковой скоростью по каждому из таких тегов в отдельности и по обоим вместе.

ЗЫ3: решение задачи — это минимум два запроса: тот, который создаст структуру базы и тот, которым вы выберите посты (id, text минимум) по заданному вводу.

http://www.codeproject.com/KB/web-security/StuxnetMalware.aspx

Ну, да, баян. Тем не менее, считаю статью интересной. В ней описывается сложнейший червь, известный даже на данный момент, который является ответственным за поломки центрифуг в иранской ядерной программе в 2009-2010 годах.

Одно из свидетельств того, что делали это серьёзные люди с серьёзными целями — вирусная часть червя была подписана сертификатом, выданным корпорацией Verisign корпорации Realtek. Говорят, что сертификат был украден напрямую из офиса последней.

Must have for anyone.

Ну, по крайней мере, для любого, кто называет себя «разработчиком на t-sql».

В проект papirus.net ищу разработчика. Полный рабочий день, офис на м. Сокол, Москва.

Что делать:

• Писать хороший и удобный для обычных юзеров (не айтишников) UI на JS + CSS + HTML. UI под мобильники и нет. Под разные браузеры под разными ОС :)
• Писать не тормозящий бэкенд на C#.
• Иногда писать запросы к БД (но редко) на t-SQL.
• Искать и внедрять новые технологии, которые улучшат проект.

Что дадим:

• Денег (базовая вилка 70-90 т.р., но всё обсуждается в конце с директором фирмы индивидуально).
• Хорошее рабочее место (кампутер, почти безлимитный инет, 24″ монитор).
• Немного еды за счёт фирмы (бутерброды, каши быстрого приготовления, йогурты, твороги, сыры, колбасы, фрукты, чай, кофе).
• Относительно свободный график (после испытательного срока).
• Замечательный коллектив (всего около 20 человек, но над этим проектом работают трое).
• Отлаженный рабочий процесс (недельные релизы, скрум-митинги по четвергам, автобилд, перфорц и прочие радости).

Для затравки загадка: почему Windows Vista и Windows 7 занимают по 20 и более гигабайт? Ответ в конце поста.

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

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

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

У нас есть стандарт языка Си. Этот стандарт нужен не только для линукса на х86 и х86-64, но также и для линукса на всех остальных архитектурах, а также для Винды, юникса и прочих поделок. Это удобно. Ты пересаживаешься на новую ОС/другую архитектуру и ты знаешь, какого поведения ожидать от той или иной функции рантайма. Именно для этого стандарт и был создан. Поэтому, если находим баг в реализации стандарта, его надо исправлять. Обязательно. Или документировать различие, в случае если исправление нецелесообразно.

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

Эту проблему можно решать двумя способами.

1. Мы вносим в документацию изменение: «идите нахер со своими стандартами, у нас будет вот так». Этот вариант хорош тем, что не надо ничего делать. Плох тем, что наша реализация отличается от стандарта, новый человек будет неприятно удивлён, когда об этом узнает => кривая обучения становится круче. Надо знать не только стандарт, но и кучу маленьких хачков, прикрученных ради неумех.
2. Придумать способ сосуществования разных версий одного и того же модуля, даже если атрибут «версия» у них одинаковый. Это стоит а) денег (в виде работы проектировщиков, разработчиков и т.д.); б) места на жёстком диске юзера. Именно поэтому последние версии виндов так дохера занимают место.

Способ 2, реализованный в Майкрософте относительно прост и туп. При линковке в EXE записывается не только версия dll, но и хеш той конкретной длл, с которой мы линкуемся. А винда хранит кучу версий этот длл и умеет найти нужную дллку по хешу. В результате, у нас есть более новые версии библиотек с исправленными багами и старые версии библиотек для софта, который использует недокументированные фичи. Все довольны и счастливы. Почему так нельзя сделать в линупсе мне непонятно.

Способ 2, реализованный у Apple, проще и тупее. Там просто каждая программа таскает за собой все необходимые ей библиотеки с собой. И никаких проблем нет.

Вернёмся к нашим баранам. Предложенное Линусом решение — сделать memcpy алиасом memmove — абсолютно неприемлимо. Потому что, кроме 1% от всех десктопов, у Линукса есть ещё минимум 18% «встраиваемых устройств» (роутеры, свитчи, мобилы, пылесосы, станки, военные чипы всякие и пр.), которые ещё не вылезли в рай двухгигагерцовых процов и гигабайтов памяти. И, скорее всего, не вылезут. И им разница между memcpy и memmove важна и критична до сих пор. И эти 18% в абсолютном исчислении в разы больше, чем 1% от десктопов. Наиболее правильное решение в условиях линуксоидов (малый бюджет, етс) было предложено на рсдн тогда же, полгода назад:

1. На уровне молока матери билд-системы разделение на DEBUG и RELEASE билды, вместо самописных велосипедов в половине make-файлов.
2. За год до изменения модифицируем debug-версию memcpy(), чтобы там вылетал ASSERT() в случае пересекаюшихся буферов.
3. Даем девелоперам год на фикс. Пишем об этом явно и везде.
4. Спустя год, меняем release-реализацию.

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

Теперь не менее важное, кто виноват в данном конкретном случае (в порядке убывания):

1. Те, кто посадил в 1993м году багу и 17 лет не правил.
2. Те, кто использовал этот баг.
3. Те, кто изменил поведение де-факто без оповещений заранее.

Вы знаете, тут везде плач Ярославны по поводу смерти Symbian’a. Я скажу как разработчик. За такое надо убивать. И нажмёшь ты кнопочку сразу, или через пять минут — это не важно и ни на минуту не приблизит тебя к моменту старта эмулятора. Эмуляторы iPhone, Blackberry и Windows Mobile так не делают.

Надо кому? А то я вчера поставил всё. Всё удовольствие — 11 гигабайт.