Существует стереотип, что reverse engineering — это занятие для злых хакеров в темных очках и блестящих кожаных пальто. Под покровом ночи, в перерывах между беготней по стенам и рукопашными схватками с толпами спецназовцев, эти компьютерные нелюди творят страшные взломы программ, пентагонов и прочих баз данных. Сами взломы как правило не требуют никакой предварительной подготовки и занимают считанные секунды. Ну и конечно в процессе практически любого взлома по чОрным экранам адских хакерских ноутбуков с непонятной ОС ползут зелёные кракозяблы и/или крутится какая-то 3D-фиговина…



Сегодня я хочу отойти от затасканных голливудских штампов про злых компьютерных взломщиков и поведать вам, дорогие читатели, о том как мирный reverse engineering помог чуть-чуть улучшить приложение Яндекс.Деньги. Надеюсь эта история пошатнет устойчивый стереотип, что reverse engineering — это обязательно плохо и нужно только нехорошим людям.

Наверное, многие C++-программисты слышали про мультиметоды и знают о том, что по сей день нет для этого языка приемлемой реализации: ни языковой поддержки, ни внешних библиотек. Есть кодогенераторы, выкрутасы через виртуальные методы, частный случай двойной диспетчеризации aka паттерн Посетитель (Visitor). Но ведь хочется просто реализовать несколько функций и указать: этот набор функций — есть мультиметод и точка.

О мультиметодах и некоторых подходах к их библиотечной реализации давно писали Мейерс и Александреску. Почти 20 лет эти идеи обсуждаются в различной литературе по C++, но до сих пор так и не были развиты до законченного решения, которое можно было бы удобно использовать в реальных проектах…

Я решил попытать счастья, дерзнуть, предложить свое видение этой проблемы и способ ее решения. Получилась шаблонная библиотека на одних только заголовочниках.
Это реализация под стандарт C++03, на чистом C++: без каких-либо кодогенераторов и дополнений. Цель — библиотека с простым и понятным интерфейсом для реализации возможности перегружать функций по типу (и даже по значению) во время выполнения (это была программа минимум, в конечном итоге получилось еще много вкусностей).

Введение

Итак, у меня есть собака.
Краткое резюме:
Кличка: Белка
Окрас: Белый с рыжим
Порода: Западносибирская лайка с кем-то еще
Происхождение: Дворянское
Стоимость: 0р 0к

Собака была приобретена в собственном подъезде за еду и кров. Была выброшена какими-то негодяями без еды и воды в картонной коробке без фирменных логотипов породы и адреса завода-изготовителя. Ну да не важно, мы и с менее качественным товаром имели дело, а тут такая рыжая морда, и совсем бесплатно. Берем!
Пришлось принимать товар как есть, NO-NAME. Скорее всего, сделано в Китае. Гарантийные претензии тоже непонятно, кому предъявлять, а они были — в собаке водились глисты длиннее ее самой. К счастью, все это в прошлом. Зверюга подросла. Доказала свою преданность и послушность, за что получила возможность гулять без веревки на шее. Поскольку это не просто собака, а настоящая собака-гуляка, которая привыкла к полноценной четырёхразовой прогулке без поводка (она у меня совсем не агрессивная, но очень любознательная и послушная), ей потребовался своеобразный маячок, чтобы наблюдать ее похождения даже в темноте, и не нервничать, куда ж она подевалась. А подеваться ей есть куда — ее любимое занятие — приносить палки хозяину, и требовать, чтобы он ее кинул. Ну а найти-уж ее дело. Но это ж не простая собака, а собака, у которой папка — программист и немножко электронщик. Впрочем, даже простой ошейник с DealExtreme приковывает взгляды окружающих, особенно радуются дети. Разве это не стоит того? Но начнем с начала. Под катом много текста!

В последнее время я стал все больше и больше интересоваться функциональным программированием, и при выборе языка предо мною пал выбор среди двух очень понравившихся мне языков — Haskell и F#.
В F# меня соблазнило то, что его можно компилировать в MSIL сборки, что обеспечивает возможность использования библиотек классов F# в других языках Microsoft .Net, а также то, что он и сам может их использовать. Ко всему прочему, я ещё и начинающий разработчик Unity3D, и мне в голову пришла мысль: если компилируется в MSIL, то может можно использовать F# скрипты в Unity? Гугление дало ответ: по-человечески нельзя. Можно создать библиотеку классов, поставить в проекте ссылки на библиотеку UnityEngine.dll, компилировать и импортировать как ассет, после чего добавлять компоненты Mono-behaviour напрямую из библиотеки, но это не слишком удобно, согласитесь. Однако, пройдя гугл, Reflection и справку по Unity, мне все таки удалось приблизить(но не повторить в точности) работу с F# скриптами внутри редактора к тому виду, в котором производится работа со скриптами на встроенных языках. Подробности — под хабракатом.

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

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

Бэкмаскинг

Потенциал подобной техники увидел ещё изобретатель фонографа Томас Эдисон, а впервые ею воспользовались пионеры электронной музыки в 50-ых годах прошлого века, хотя, конечно, популяризации приемов бэкмаскинга мы обязаны группе Beatles. В частности, под воздействием марихуаны Леннон прокручивал пленки задом наперед, и полученный звук его очень заинтересовал. Первой песней со скрытым сообщением была Rain.

Добрый день, сегодня я хочу продолжить рассказывать о своей библиотеке, в надежде найти сторонников идеи.
Этот пост является продолжением Transcend Library 4: Введение, точнее логичным развитием дискуссии в комментариях.

Давным давно… ну как давно? вчера! (С), то есть пару лет назад, портировал я одну скромную библиотечку с Java на .NET. И не просто на .NET, а на версию 1.1.

Подход известен — берем в зубы Sharpen (или конвертер из вижуалстудии 2003 года, кому что нравится), и далее — лобзиком.

Про очевидности с итераторами, структурами ("System.Drawing.Size это не объект") и потоками рассказывать не буду — банальщина. А вот про некоторые сюрпризы — добро пожаловать.

Фильтр размытия по гауссу (широко известный “gaussian blur” в фотошопе) достаточно часто применяется сам по себе или как часть других алгоритмов обработки изображений. Далее будет описан метод, позволяющий получать размытие со скоростью, не зависящей от радиуса размытия, используя фильтры с бесконечной импульсной характеристикой.

Если в одном из моих прошлых постов речь шла о довольно современном подходе к построению сбалансированных деревьев поиска, то этот пост посвящен реализации АВЛ-деревьев — наверное, самого первого вида сбалансированных двоичных деревьев поиска, придуманных еще в 1962 году нашими (тогда советскими) учеными Адельсон-Вельским и Ландисом. В сети можно найти много реализаций АВЛ-деревьев (например, тут), но все, что лично я видел, не внушает особенного оптимизма, особенно, если пытаешься разобраться во всем с нуля. Везде утверждается, что АВЛ-деревья проще красно-черных деревьев, но глядя на прилагаемый к этому код, начинаешь сомневаться в данном утверждении. Собственно, желание объяснить на пальцах, как устроены АВЛ-деревья, и послужило мотивацией к написанию данного поста. Изложение иллюстрируется кодом на С++.

Приветствую.

Уж не знаю, как так вышло, но игрался я на досуге с лямбда-выражениями в С++11 (о которых, к слову, я уже писал статью, снискавшую пару лет назад на удивление достаточно неплохую популярность), и под наркотическим воздействием впечатлением от языка Haskell начал разбираться с такими понятиями, как частичное применение и каррирование в контексте языка С++. И для начала, пожалуй, неплохо бы нам определиться с этими терминами.

Если вы .NET программист, то вы наверняка объявляли и использовали события в своем коде. Несмотря на это, не все знают, как события работают внутри и какие особенности связаны с их применением. В этой статье я попытался описать работу событий как можно более подробно, включая некоторые частные случаи, с которыми редко приходится иметь дело, но про которые важно и\или интересно знать.

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

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

"Мама мыла раму":

(предложение
    (именная гр. (сущ мама))
    (глаг. гр. (глаг мыла)
        (именная гр. (сущ раму)))
    (. .)))

Это называется синтаксическим деревом предложения. В графическом виде его можно представить следующим образом (в упрощенном виде):

Доброго времени суток.
Не так давно заинтересовался этим движком. Благо, русских материалов на эту тему достаточно много, в том числе и на хабре.
Однако, я нигде не видел описание (на русском языке) порядка возникновения различных событий в создаваемых играх, а это один из факторов оптимального размещения скриптов в тех или иных функциях.
Поэтому решил перевести раздел Execution Order of Event Functions из англоязычной справки Unity3D.
Надеюсь, из этого выйдет что-нибудь путнее. Кто заинтересовался — добро пожаловать под кат =)

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

А пока, обо всем по порядку…


Катя Клубникина изображает счастливого туриста с первым макетом устройства на шее.

Часть первая. Предыстория.

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

Надо сказать, что до этого я практически 13 лет занимался тем, что принято называть собирательным термином «визуальная коммуникация», а именно, рисовал графический дизайн, снимал рекламу и делал дизайн в движении, а позднее, имея изрядный школьно-студенческий программерский багаж, стал интересоваться разработкой интерактивного ПО, в т.ч. применительно к набиравшей обороты web-индустрии.

После выхода iPhone 4S с Siri «на борту», владельцы остальных гаджетов Apple, чувствовали себя немного обделенными. Даже в свой новый iPad Apple не включила Siri. Разработчиками по всему миру были предприняты попытки портировать Siri на другие устройства или написать похожие аналоги. И только русскоязычный App Store хранил молчание. Наверно все разработчики очень заняты, подумал я, и решил исправить это досадное недоразумение…

Друзья, я хочу вам рассказать историю развития проекта president2012.ru. Сайт является лидером по тематике выборов президента России, за 3 месяца его посетило около 2 млн. человек, в пике имел до 20 тыс. посетителей онлайн и более 1 млн. хитов в сутки, задействовано было 3 сервера облака.

Интересных моментов в процессе работы над проектом набралось столько, что держать в себе эти знания я не могу, и хочу поделится с вами. Я понимаю, что многое, о чем я сейчас собираюсь рассказать, уже описано качественнее в специализированных разделах, и ничего нового я не открою. Моя задача скорее в том, чтобы через отдельные нюансы передать ту атмосферу, в которой проходила работа над проектом. А так же в миллионный раз с помощью success story показать таким же как я людям, что всё возможно и всё в их руках.

Кому это может быть интересно? Всем, кто так или иначе занимается созданием тематичных веб-сайтов и рассчитывает работать с высоконагруженными проектами.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

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

Всем доброго времени суток!

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

Дерево ван Эмде Боаса (van Emde Boas tree) — ассоциативный массив, который позволяет хранить целые числа в диапазоне [0; U), где U = 2^k, проще говоря, числа, состоящие не более чем из k бит. Казалось бы, зачем нужно еще какое-то дерево, да еще позволяющее хранить только целые числа, когда существует множество различных сбалансриованных двоичных деревьев поиска, позволяющих выполнять операции вставки, удаления и прочие за O(log n), где n — количество элементов в дереве?

Главная особенность этой структуры — выполнение всех операций за время O(log(log(U))) независимо от количества хранящихся в ней элементов.

Цель этой статьи — заставить всех, особенно программистов на Си, сказать «я не знаю Си».
Хочется показать, что тёмные углы в Си значительно ближе, чем кажется и даже тривиальные строки кода несут в себе undefined behavior.