Hacking & Security

Шарик, отвечающий на вопросы

sepos — Tue, 14 Dec 2010 09:00:57 GMT

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

Сегодня я решал один ~~важный~~ вопрос и переклинило меня, что непременно нужно воспользоваться шариком, отвечающим на вопросы (как в фильме «трасса 60»).

Гугл нормальных online-шариков не нашел: либо предлагают купить материальный шарик, либо online, но этот шарик страшно выглядит и/или с хитрой логикой (например, нужно ввести текст вопроса, который проходит валидацию).

Собственно, примерно за час написал свой шарик. Нужно просто кликнуть по нему и получишь ответ.

Возможно, кому-то такой шарик покажется чуть приятнее остальных.

http://www.ecm7.ru/8ball/

UPD:
Шарик переехал на собственный домен: www.8-ball.ru.
Старая ссылка тоже работает и перенаправляет на новое место.

Mail.ru изнутри: фотоэкскурсия по офису интернет-холдинга

sepos — Sat, 20 Nov 2010 20:28:53 GMT

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

В эти дни на горизонте компании — очередной волнительный и этапный момент в жизни. Уже этой осенью Mail.ru Group планирует разместить до 25 % своих акций на Лондонской фондовой бирже.

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

В 11 утра этого понедельника мы прибыли на Ленинградский проспект к бизнес-центру «Авион», где располагается московский офис Mail.ru

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

Мы поднялись на пятый этаж, где отрекомендовались на ресепшн:

Вскоре к нам пришла руководитель пресс-службы компании Валерия Коммисарова:

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

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

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

Здесь же проголодавшиеся сотрудники могут перехватить что-нибудь съестное. Комплексные обеды «Мэйл» не практикует, но чем перекусить найдется всегда: бесплатный чай, кофе, молоко, йогурты, бутерброды, салаты, булочки есть почти всегда.

Кстати, в той комнате, что мы были, кроме прочего, есть мини-библиотека:

Как объяснила Валерия, сотрудники Mail.ru могут заказать любую профессиональную литературу, и она будет куплена за счет компании.

Закончив обсуждение, мы двинулись на осмотр офиса.

***

Узнаваемой особенностью всех помещений компании являются вот такие «перфорированные» стенки опен-спейсов:

из которых порой вырастают длинные коридоры:

Еще одна особенность — фотопринты ладоней сотрудников, которые развешаны почти везде:

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

***

Был план зайти в кабинет генерального директора Mail.ru Дмитрия Гришина. Но хозяин оказался в отъезде, а связаться с ним, чтобы получить разрешение на фотографирование кабинета, не удалось. Пришлось довольствоваться фотографией натюрморта: «ресепшн перед кабинетом Гришина с задумчивой девушкой и яблоками»:

После этого мы направились гулять по этажам и офисам. Сами офисы не были чем-то уникальными. Это более или менее обычные «опен-спейсы». Какие-то небольшие — на 5−15 человек:

Какие-то — на пару-тройку сотен сотрудников:

Кстати, всего в офисе на Ленинградском постоянно работает больше тысячи человек. Самое многочисленное подразделение — бывшая компания «Аструм Онлайн», ныне ставшая частью «Мэйла». Именно у них, как мне показалось, самые большие рабочие пространства...

...и самая изобретательная фантазия:

Пройдя офисы хорошо известных в онлайне «Работа@mail.ru», «Мой мир@mail.ru», «Игры@mail.ru» и других подразделений, мы дошли до игровой комнаты. Там были пуфики, бильярд, настольный футбол:

и теннисный стол:

Неподалеку находилась душевая. Удобно для тех, что приезжает в офис на велосипеде.

***

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

Возвращаясь за вещами, которые оставили в кабинете пресс-службы, мы заглянули в вотчину «Видео@mail.ru». Там, как и в других помещениях, кипела работа:

***

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

Атака MBR-червя или все новое — хорошо забытое старое

sepos — Thu, 26 Aug 2010 08:28:39 GMT

В последнее время в Интернете получил массовое распространение ранее неизвестный червь — Win32/Zimuse, нацеленный на повреждение главной загрузочной записи MBR (Master Boot Record) на жестком диске.
Примечательно то, что данная угроза изначально была в шутку создана для заражения одного небольшого сообщества словацких байкеров. Возможно, это были происки конкурирующего с ними мотоклуба. Однако сегодня червь уже вышел из-под контроля его авторов и активно распространяется по всему миру. При этом 90% всех инфицированных пользователей сначала находились на территории Словакии. Но теперь по количеству заражений лидируют также США, Таиланд и Испания, с небольшим отставанием Италия, Чехия и другие европейские страны.

Win32/Zimuse повреждает главную загрузочную запись MBR на всех обнаруженных им жестких дисках. Это делает недоступными для пользователя все данные, находящиеся на жестком диске.

Червь распространяется двумя способами: в виде приложения на вполне легальных веб-ресурсах, которое имитирует поведение самораспаковывающегося zip-архива или в виде программы IQ-теста, а также на сменных USB-носителях. Именно второй способ повлиял на быстрый рост его распространения.

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

На сегодняшний день червь известен в двух вариантах — Win32/Zimuse.A и Win32/Zimuse.B. Они отличаются методом распространения и временем активации. Варианту «А» необходимо 10 дней до начала распространения через USB-устройства, второму — лишь 7 дней с момента заражения.
Подобного рода инцидент уже был ранее известен с вирусом OneHalf, который наделал много шума в середине девяностых. В то время многие антивирусные программы были бессильны перед данной угрозой. OneHalf заражал MBR и шифровал пользовательские данные. Многие варианты лечения этого вируса приводили к повреждению загрузочного сектора и потере данных. В процессе расследования и поиска авторов OneHalf большинство фактов указывало на то, что его распространение началось именно в Словакии и, вероятнее всего, автор был тоже оттуда.

Пользователи антивирусных продуктов ESET NOD32 Antivirus и ESET NOD32 Smart Security защищены от угрозы Win32/Zimuse, а для всех остальных компания ESET разработала специальную утилиту, которая позволяет избавиться от червя Zimuse Removal Tool.

Пишем StarCraft-бота на F#

sepos — Wed, 25 Aug 2010 05:31:22 GMT

В день когда было объявлено о соревновании я яростно взялся за создание бота для StarCraft на языке F#. F# отлично работает в таких областях как AI, асинхронное программирование и всякие замечательные штуки. Однако, я не стал писать об этом проекте раньше по этическим причинам. Дело в том что API, используемое для взаимодействия с Broodwar напрямую нарушает лицензионное соглашение StarCraft. Подумайте об этом — предоставлять API для программного доступа к продукту может быть опасно. Разработка ботов идёт рука об руку со взломом, эксплоитами и испорченным играм для нормальных игроков. Хотя мои мотивы в модификации StarCraft ограничиваются написанием ботов для собственного использования, я абсолютно уважаю желание Blizzard предотвратить реверс-инжиниринг их программ.

Итак, как представитель Microsoft и человек уважающий лицензионные соглашения, я не особенно распропространялся о своём проекте. Так было пока юридический отдел Blizzard официально не разрешил проведение упомянутого соревнования. Разрешите представить Вам моего StarCraft-бота на F# (который, на самом деле, просто порт Java Proxy Bot).

Настройка необходимых программ

1. Купите и установите StarCraft

Первое, что следует сделать — купить и установить StarCraft и расширение BroodWar. Их можно раздобыть за $15 в онлайн-магазине Blizzard.

Обязательно установите StarCraft в легко доступную папку вроде «E:\StarCraft». Иначе копирование файлов бота в Program Files (доступную только администратору) будет очень непростым делом.

2. Скачайте и установите Chaos Launcher

Chaos Launcher — инструмент, управляющий загрузкой и запуском StarCraft. Т.к. оригинальная игра вышла в 1998, мы не станем винить её за то что она не может нормально работать в оконном режиме. Но для разработки бота это очень важный вопрос.

Для начала, распакуйте файл в папку, например "E:\StarCraft\Chaos Launcher\”. Потом, чтобы проверить всё просто запустите ChaosLauncher.exe. Отметьте «W-Mode plugin» и нажмите Start. Теперь Вы можете играть в StarCraft в оконном режиме!

3. Установите BWAPI

BWAPI это открытое API для взаимодействия со StarCraft: BroodWar, и именно это API мы будем использовать в нашем боте.Скачайте BWAPI_Beta_2.6.1.zip и распакуйте его в папку, например "E:\StarCraft\BWLAPI_Beta_2.6.1\”. Заметьте, что Вам ещё необходимо пройти регистрацию. В файле Readme перечислены следующие шаги:

Скопируйте содержимое папки ChaosLauncher в директорию, куда Вы установили Chaos Launcher ("E:\StarCraft\Chaos Launcher"\”)
Скопируйте содержимое папки StarCraft в Вашу папку StarCraft ("E:\StarCraft\”)
Скопируйте содержимое папки Windows в ваш системный каталог ("C:\Windows\”)

Представляю StarCraftBot 9K

Теперь все необходимые инструменты на месте, но написание бота для программы, расширений к которой вообще не планировалось, будет непростым делом. StarCraft Bot 9K имеет следующую архитектуру (которая, в свою очередь, повторяет архитектуру Java ProxyBot, доступного на сайте AIIDE).

Вы используете Chaos Launcher для запуска StarCraft
Когда начинается игра, код BWAPI исполняется каждый игровой ход
В каждый ход StarCraftConnector (С++) передаёт всю публично доступную информацию из игры.
Клиент StarCraftBot9K (C#) слушает эти события
И наконец сам StarCraftBot9K (F#) отвечает за принятие решений в игре.

4. Скачайте StarCraftBot9K

В самом конце этого поста указан zip-файл со всеми исходными кодами. Скачайте его и распакуйте в папку, например "E:\StarCraftBot9K\”.

5. Установите StarCraftConnector

При сборке StarCraftBot9K одним из получившихся файлов будет StarCraftConnector.dll — библиотека на C++, построенная поверх BWAPI, которая отсылает сообщения о состоянии игры в сокет. После этого приложение на C# слушает этот сокет и по мере надобности отправляет сообщения игре StarCraft.

Чтобы «установить» StarCraftConnector скопиркйте его в "E:\StarCraft\bwapi-data\AI\”. Эту папку Вы должны были скопировать когда устанавливали BWAPI.

После этого откройте "E:\StarCraft\bwapi-data\bwapi.ini” и установите поле ai_dll в значение "bwapi-data\AI\StarCraftConnector.dll”.

6. Запустите StarCraftBot9K

Наконец, Вы готовы к запуску StarCraftBot9K! Просто запустите приложение. Оно начнёт слушать сокет пока StarCraftConnector не начнёт отправку данных.

7. Запустите StarCraft

Теперь снова запустите Chaos Launcher, в этот раз включив модуль "BWAPI Injector”. Заметьте, запускать его нужно от имени администратора.

Когда запустится StarCraft всё будет выглядеть как обычно, BWAPI и StarCraftConnector включаются только при начале Custom Game.

8. Передайте управление StarCraftBot 9K

Когда начнётся игра Вы должны увидеть что то наподобие этого. Это отображение внутреннего состояния игры StarCraft в простом WinForms-приложении. Сюда ещё придётся добавить много дополнительных компонент — например объектную модель для отправки правильных команд StarCraft'у.

Когда вы отметите галочку "Economy AI Module”, асинхронный поток F# запустится и подключится к StarCraft, начав строительство Вашей базовой экономики (строительство SCV, Дронов или Зондов и отправка их к руднику.)

/// Модуль AI для управления экономикой. Постройка дронов, веспен-гейзеры и прочее
let private getEconomyAI (mediator : GameMediator) =
 async {

 while true do

 let currentState = mediator.CurrentGameState

 // Строить рабочих на все имеющиеся ресурсы
 if currentState.SupplyUsed < currentState.SupplyTotal &&
 currentState.Minerals >= 50 &&
 currentState.CanProduce.[ int (getWorkerType(g_GameMetadata.PlayerRace)) ] then

 // БАГ: рабочий строится в первом попавшемся командном центре, это может быть не лучшим решением
 // В идеале у нас должна быть абстракция более высокого уровня "база" со статусом "активная" или "мало ресурсов"
 let cmdCenter =
 currentState.Units
 |> Seq.filter (fun unit -> unit.Player = g_GameMetadata.PlayerID)
 |> Seq.tryFind (fun unit -> isCommandCenter (enum
 if Option.isSome cmdCenter then
 let cmdCenterID = cmdCenter |> Option.get |> (fun unit -> unit.ID)
 let cmd = TrainUnit(cmdCenterID, int (getWorkerType(g_GameMetadata.PlayerRace)))
 mediator.SendCommand(cmd)

 // Посылаем незанятых рабочих к ближайшему минеральному полю
 for scunit in currentState.Units do
 // Если юнит наш, это рабочий и он ничего не делает,
 // отправить его к ближайшему полю минералов
 if scunit.Player = mediator.GameMetadata.PlayerID &&
 isWorker scunit &&
 scunit.OrderID = int (UnitOrder.PlayerGuard) then

 let orderID = scunit.OrderID

 let scunitLoc = { X = scunit.XPos; Y = scunit.YPos }

 let mineralPatches =
 currentState.Units
 |> Seq.filter(fun unit -> unit.TypeID = int UnitID.MineralField)
 |> Seq.map(fun minPatch -> let patchLoc = { X = minPatch.XPos; Y = minPatch.YPos }
 scunitLoc.FlyingDistanceTo(patchLoc), minPatch)
 |> Seq.sortBy(fun (dist, minPatch) -> dist)

 if mineralPatches <> Seq.empty then
 let targetMinPatch = mineralPatches |> Seq.head |> snd
 let cmd = RightClickUnit(scunit.ID, targetMinPatch.ID)
 mediator.SendCommand(cmd)

 // Спим и проверяем позже. Если этот агент будет отменён, здесь мы жто увидим
 do! Async.Sleep(100)
 }

Пока что AI не представляет из себя ничего особенного. Но асинхронная модель F#, reactive framework и события первого порядка позволяют создать очень мощную и элегантную модель на основе асинхронных событий, происходящих в игре.

К примеру, мы приказываем юниту вроде Голиафа атаковать противника. При этом может случиться множество вещей! Голиаф может убить другого юнита, тот юнит может убежать, Голиаф может погибнуть и так далее. И результат Вашего действия Вы узнаете только спустя несколько секунд. Асинхронные процессы в F# позволяют очень эффективно оборачивать такие асинхронные действия.

let! result = tryEngage enemyUnit

match result with
| MarineWasKilled -> printfn "Sad."
| UnitWasKilled -> printfn "Horray! Now go find a medic to heal"
| UnitRanAway -> printfn "Should you chase? Maybe..."

Функция tryEngage может быть просто объединением нескольких событий (marine.OnKilled, unit.OnKilled и новое событие когда юнит отбегает слишком далеко). Может быть пока эту концепцию сложновато понять. Я постараюсь написать новый пост об этом позже.
Я прикрепил исходный код. Хотя возможно ему и требуется дополнительная полировка, всё должно быть довольно понятно. Заметьте, что эта статья идёт не с одним, а сразу с двумя предупреждениями!

Все образцы кода предоставляются «КАК ЕСТЬ» без каких либо гарантий, явных либо подразумеваемых. Никаких гарантий что код подойдёт для того, для чего Вы его планируете использовать. Другими словами, если использование BWAPI приведёт к Вашему бану на Battle.net или повредит Вашей системе, не ожидайте от меня сострадания.

Как видите, здесь очень много взаимодействующих частей. Я рад предоставить некоторую техническую поддержку, но если Вы отклолнитесь от указанной процедуры не ожидайте что я буду знать почему <случайная штука> не работает или как устроен StarCraft изнутри.

Дополнительные материалы:

Исходный код бота

Программируем для PSP: Часть I, настройка компилятора

sepos — Tue, 24 Aug 2010 08:34:22 GMT

Давайте условимся сразу: я следую паттерну "изучение обучением", т.е. учу, одновременно изучая, обгоняя читателей на 2-3 "шага" вперед. Однако это не значит, что я ничего не знаю и все, что говорю - обычные копипасты: я стараюсь разобраться в теме, прежде чем писать о ней. Поэтому смело задавайте вопросы, этим вы принесете пользу и себе, и мне: на вопросы, ответ на которые я не знаю, я буду его искать, осозновать и рассказывать вам.

Итак, в этом топике будет небольшой рассказ о том, как скомпилировать и запустить первую программу на своей приставке. Сразу предупреждение: статья мегатехнического плана, почти все содержание касается утомительной, но быстрой настройки компилятора, а в результате вы получите лишь банальный "Hello World". Однако без нее никак.

Будем предполагать как данность, что у вас есть приставка Sony PSP, перепрошитая до последней версии - 3.90 M33-3 (так называемая custom firmware, неофициальная прошивка). О том, как перепрошиваться, уже рассказывали многие, и останавливаться на этом я не буду. Так же будем считать, что в кирпич ваш вставлена флешка, на которой есть хотя бы 50кб свободного места, и вы имеете к ним доступ (например, через саму PSP).

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

Используемый язык программирования — Си, я буду использовать бесплатную IDE Code::Blocks под Windows XP. Пользователи других компиляторов или ОС могут попробовать настроить IDE сами, благо, настройки у всех похожи; я же использовал то, для чего нашел мануал ;)

Для начала, скачаем набор компиляторов, линкеров и библиотек для PSP под названием DevKitPSP. Распакуйте его куда-нибудь, я его распаковал в корень диска E: (теперь у меня есть папка E:\devkitpsp\).

Теперь откройте Code::Blocks. В меню выберите Settings→Compiler and Debugger, как Selected Compiler в открывшемся окошке выберите GNU GCC (он должен стоять по умолчанию), скопируйте его, назвав, например, DevKitPSP, и настройте его:

Вкладка Search Directories→Compiler (удалите все, что там есть, и нажимайте Add для добавления каждого из путей):

E:\devkitPSP\include
E:\devkitPSP\psp\include
E:\devkitPSP\psp\sdk\include

Linker:

E:\devkitPSP\lib
E:\devkitPSP\psp\lib
E:\devkitPSP\psp\sdk\lib

Вкладка Toolchain Executables:

Compiler's installation directory: E:\devkitPSP . Там есть примечание, что в этой папке должна быть подпапка bin, проверьте.
C-compiler: psp-gcc.exe
C++-compiler: psp-g++.exe
Linker for dynamic libs: psp-g++.exe
Linker for static libs: psp-ar.exe
Еще три поля я оставил пустыми.

Теперь можно жать OK, и переходить к созданию нового проекта (File→New→Project..., слева в окошке жмем Projects и выбираем Empty). Заполняем Project Title (не играет роли, пусть будет PSPHelloWorld), не забываем поставить папку для сохранения проекта (я вон в первый раз забыл, и получил кучу глюков и ошибок); компилятор, разумеется, ставим свежесозданный нами.

Наш проект девственно пуст, создаем фаил (File→New→File..., на название наплевать, я выбрал main.c) — не забудьте в мастере создания фаила выбрать как язык Си и поставить галочки "Add to current project", "Debug" и "Release" (почему они не стоят по умолчанию?).

В созданный фаил копируем код (ключ доступа - хабрахабр). Я бы сюда закинул, если бы не хабрапарсер. Код писал не я, кстати: опыта пока-что маловато, хотя я вполне понимаю, что там происходит и как - в любом случае, в этом топике я останавливаться на этом не буду.

Теперь последние штрихи к настройке. Мы уже настроили то, с помощью чего будем компилировать, но не настроили, как и что у нас должно выходить. Поэтому жмем правой кнопкой на название проекта справа, выбираем Properties, а там — Build targets. Снимаем галочку "Auto-generate filename extension", и правим в Output filename расширение "exe" на "elf". Выполняем тоже самое для конфигурации Release, жмем Ok.

Жмем правой кнопкой на название проекта опять, выбираем Build Options и, на вкладке Linker Options, вписываем в Other linker options:

-lpspdebug -lpspdisplay -lpspge -lpspctrl -lpspsdk -lpsplibc -lpspnet_inet -lpspnet_apctl -lpspnet_resolver -lpsputility -lpspuser -lpspkernel

. Повторяем для Release.

Вроде всё (надеюсь, это последняя статья скучного технического плана). Теперь собираем проект (Build→Build или знакомое всем Ctrl-F9) — если вдруг появились ошибки, то думаем, что же сделали не так, а потом спрашиваем в комментариях (может, я забыл чего).

Чтобы не настраивать потом заново, стоит сохранить проект как шаблон (File→Save Project as user-template...).

Итак, у нас есть elf-фаил нашей программы. Перед тем, как закидывать его на PSP, надо преобразовать его в EBOOT.PBP (название придумал не я, честно). Для этого у меня стоит такой bat-ник:

"E:\devkitPSP\bin\mksfo.exe" %1/bin/Debug/%1 %1/bin/Debug/%1.sfo
"E:\devkitPSP\bin\psp-fixup-imports.exe" %1/bin/Debug/%1.elf
"E:\devkitPSP\bin\psp-strip.exe" %1/bin/Debug/%1.elf -o %1/bin/Debug/stripped.elf
"E:\devkitPSP\bin\pack-pbp.exe" %1/bin/Debug/EBOOT.PBP %1/bin/Debug/%1.sfo NULL NULL NULL NULL NULL %1/bin/Debug/stripped.elf NULL

Он располагается у меня в директории pspprj, в которой я создаю по папке для каждого проекта. Используется он так: make_eboot.bat HelloWorld . Если у вас другая организация папок, или вы просто хотите его переписать или запускать каждую программу вручную — просто запускайте по строчке, не забывая заменять %1 на названия или пути к фаилам. В результате у вас получится фаил EBOOT.PBP, его надо будет закинуть в папку /PSP/GAME150/HelloWorld (или другое название)/, а все остальное можно спокойно удалить. Теперь проверяйте (выход — по кнопке Home).

Как "домашнее задание" — сделайте так, чтобы все "хелловорлды" были с новой строки. До встречи!

P.S. Вырезал весь "юмор", который сначала вписывал. Всегда самого раздражали тупые шутки в такого рода постах, а в том, что мои шутки не тупы, я быть уверен не могу :)

Проблема глобального переопределения new/delete в C++/CLI

sepos — Mon, 23 Aug 2010 13:27:19 GMT

Как известно, C++ позволяет глобально переопределять операторы new и delete. Обычно такое переопределение используется для диагностики, поиска утечек памяти и более эффективного распределения памяти.

Все это мы используем в нашем крупном проекте. Однако у нас есть часть, написанная на C#, которая с помощью C++/CLI взаимодействует с основной частью на C++. И вот тут появились проблемы. У нас получались утечки памяти там, где их быть ну никак не могло.

Все сводилось к тому, что вызывался наш new, но delete был crt’шный.
Чтобы разобраться с проблемой, я создал тестовый solution, где смоделировал ситуацию. Для простоты переопределенные функции выглядят так:

void* __cdecl operator new( size_t size ) { printf("New\n"); return malloc(size); } void __cdecl operator delete( void *p ) { printf("Delete\n"); free(p); }

Значит, мы должны получить одинаковое количество New и Delete в выводе, равное количеству пар new/delete.

Вот код, который вызывает new/delete:

//managed.h namespace Managed { public ref class ManagedClass { public: ManagedClass() { NativeClass* cl = new NativeClass(); delete cl; int* a = new int(); delete a; } }; } //native.cpp NativeClass::NativeClass() { int* a = new int(); delete a; }

Из C# мы создаем ManagedClass так:

static void Main( string[] args ) { ManagedClass cl = new ManagedClass(); }

Еще есть класс Foo, который лежит в отдельном файле basic.h, причем он никак не используется в этих классах. Просто его определение помещается в Precompiled Header.
Этот "плохой” класс не несет функциональности, однако одно наличие его приводит к очень странному результату. Если комментируешь конструктор копирования класса, то все работает отлично:

#pragma once class Foo { public: Foo() {} //Foo( const Foo& ) {} Foo& operator = ( const Foo& ) { return *this; } virtual ~Foo() {} };

Вывод:
   New
   New
   Delete
   Delete
   New
   Delete

3 new – 3 delete. Все хорошо.

Если же конструктор копирования не закомментирован, то не всем нашим new соответствует наш delete:

#pragma once class Foo { public: Foo() {} Foo( const Foo& ) {} Foo& operator = ( const Foo& ) { return *this; } virtual ~Foo() {} };

Вывод:
   New
   New
   Delete
   New

3 new – 1 delete. Все плохо.

Итог: мы имеем ошибку выбора функции удаления, которая зависит от "положения луны”. Самое время начать гуглить.

В ходе поисков был найден документ, предположительно описывающий нашу проблему:
http://support.microsoft.com/kb/122675.

К сожалению, после детального прочтения документа, выясняется, что наш случай отличается от рассмотренного. Более того, в pure-C++ проекте такого поведения не наблюдается. Проблема в C++/CLI.

Продолжим наши исследования. Если деструктор сделать не виртуальным, то опять все работает, как надо:

#pragma once class Foo { public: Foo() {} Foo( const Foo& ) {} Foo& operator = ( const Foo& ) { return *this; } ~Foo() {} };

Вывод:
   New
   New
   Delete
   Delete
   New
   Delete

Стоит заметить, что этот класс никак не используется в нашей программе. Просто само его наличие приводит к багу.
Т.к. баг проявляется только в C++/CLI, то попробуем пометить этот класс как unmanaged:

#pragma managed(push,off) #include "../System/basic.h" // h файл с "плохим” классом Foo #pragma managed(pop)

Вывод:
   New
   New
   Delete
   Delete
   New
   Delete

Получилось! Однако, это не решение проблемы. Будем копать дальше.

Может быть проблема в Precompiled Headers? Однако если basic.h из Stdafx.h, но вставить его в любой другой *.h файл, который попадает в проект, то проблема повторится.

Посмотрим более подробно, что делает linker. Для этого включим режим вывода дополнительной информации у linker’а:

Ого! Он нашел delete в MSVCRTD.lib, вот почему delete используется не наш:

В случае же, когда мы делаем деструктор не виртуальным или комментируем конструктор копирования, получаем такой выход linker’а:

Более того, если оставить конструктор копирования, сделать деструктор не виртуальным, но добавить виртуальную функцию, опять delete начинает глючить.

Хотя исследования были в Debug сборке, но и в Release наблюдается то же самое поведение.

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

В итоге имеем, что при наличии класса, у которого есть виртуальная таблица и конструктор копирования (причем этот класс компилируется в managed), linker линкует стандартный delete, хотя у нас и есть переопределенный delete в dll.

PS. Кому интересно самостоятельно поработать с простейшим тестовым solution с проблемой и, возможно, помочь советом, могут скачать его вот здесь: https://mysvn.ru/Lof/NewDeleteProblem

Преобразование FB2 в XHTML с сохранением вложенных рисунков

sepos — Mon, 23 Aug 2010 10:23:56 GMT

Возникла у меня небольшая необходимость преобразовать книги в формате FB в xhtml.
Ну ясное дело я полез на www.gribuser.ru/xml/fictionbook/2.0/xsl/export/ где и взял файл
FB2_2_xhtml.xsl (заодно захватил FB2_2_txt.xsl мало ли в текстовом виде понадобится книжку получить )
Попробовал сконвертировать книжку, и заметил маленькую проблемку, рисунки то пропали. :(
В принципе рисунки не главное в книжке, но все равно немного обидно. Поэтому полезем разбираться в чем проблема.

По стандарту FB2 внедренные рисунки описываются в тегах binary.А ссылаются на них с указанием якоря в ссылке, то есть

<img src='#cover.jpg'/>

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

$path='book'; //путь к папке куда будем складывать рисунки $doc=new DOMDocument(); $doc->load($xml_filename); $nodes=$doc->getElementsByTagName('binary'); foreach ($nodes as $node) { $value=base64_decode($node->nodeValue); $fname= $node->attributes->getNamedItem('id')->nodeValue; $fh=fopen($path.'/'.$fname,'w+'); fwrite($fh,$value); fclose($fh); }

Затем делаем xslt преобразование файлов взятым с офф сайта и радуемся жизнь, рисунки появились. Вот только объем, если делатаь небольшую библиотечку то надо хранить txt файлы, fb2 файлы, xhtml'ку, да и рисунки еще, накладно получается. В принципе можно хранить одну fb2'шку а по обращению получать файл, задержка небольшая, пару секунд и подождать можно (это на нетбуке, на десктопе преобразование выполняется только влет). И тут мне вспомнилось что существует такая вещь как Data Uri, так почему бы не использовать ее и не встроить рисунки прямо в итоговую xhtml'ку. Конечно размер вырастет, но ведь мы получаем xhtml'ку только посмотреть когда нужно, к тому же если такой xsl файл получить то можно будет fb2'ки нормально в браузере читать.
И вот я начал копаться в FB2_2_xhtml.xsl файле.
Сразу видно причину почему пропали рисунки

:template match="fb:image">      align="center">          border="1">             :choose>                 :when test="starts-with(@xlink:href,'#')">                     :attribute name="src">:value-of select="substring-after(@xlink:href,'#')"/>:attribute>                 :when>                 :otherwise>                     :attribute name="src">:value-of select="@xlink:href"/>:attribute>                 :otherwise>             :choose>         >     > :template>

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

:when test="starts-with(@xlink:href,'#')">     :attribute name="src">         :text>data::text>         :variable name="href" select="substring-after(@xlink:href,'#')" />          variable="href" expression="substring-after(@xlink:href,'#')"/>         :value-of select="//fb:binary[@id=$href]/@content-type" disable-output-escaping="yes" />         :text>;base64,:text>         :value-of select="//fb:binary[@id=$href]" disable-output-escaping="yes"/>     :attribute> :when>

Почему то простая конструкция

:variable name="href" select="substring-after(@xlink:href,'#')" />

у меня не захотела задавать переменную, она не виделась в xpath выражении, после дополнительного определения
variable="href" expression="substring-after(@xlink:href,'#')"/>
все заработало как нужно.

Также внес небольшие изменения касающие вывода названия книги сверху

align="center">     :value-of select="fb:description/fb:title-info/fb:book-title"/> >

А также вывода обложки

:for-each select="fb:description/fb:title-info/fb:coverpage/fb:image">     :call-template name="image"/> :for-each>

предварительно исправив на Возможно стоит перенести содержание в конец, но в принципе меня и так все устраивает. Получившийся файл можно взять здесь bit.ly/1JOIvz P.S. пока искал в нете подходящее решение наткнулся на rusec.livejournal.com/11740.html :) Ну и касательно fb2 читалки под линуксом не могу процитировать сообщение на которое наткнулся на лоре Нашел для себя отличный ридер для fictonbook: «zcat book.fb2.zip|xsltproc FB2_2_txt.xsl -|less -s» ;) juick.com/demyan/70753

Кроссбраузерные HTML инклуды sepos — Mon, 23 Aug 2010 05:25:52 GMT Пусть у нас есть простенький хтмльчик index1.htm DOCTYPE html> <html> <head> <title>Xbrowser HTML includestitle> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> head> <body> <h1>First fileh1> body> html> Как известно, хтмл поддерживает инклуды только через iframe/object, но с ними не очень удобно работать из яваскрипта. Можно, конечно, прописать в каждую подключаемую страницу скрипт типа такого new function(){ var frame= window.frameElement if( !frame ) return var parent= frame.parentNode var body= document.getElementsByTagName( 'body' )[0] var child; while( child= body.firstChild ) parent.insertBefore( child, frame ) parent.removeChild( frame ) } Он переносит своё содержимое в родительский документ и удаляет фрейм. Но в случае отключённоо яваскрипта мы получим окошко ифрейма не подстраивающееся под размер содержимого. В XHTML2 пояилась интересная возможность — аттрибут src можно задавать любому элементу и содержимое документа на который он указывает будет всталено вместо содержимого элемента. Напишем index2.htm DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml2.dtd"> <html> <head> <title>Xbrowser HTML includestitle> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> head> <body> <h1>Second fileh1> <div src="index1.xml" srctype="text/xml"> <a href="index1.xml">link 2 first filea> div> body> html> Проверили — не работает. Оживить её можно с помощью яваскрипта, который опять же может быть отключён, но это уже не так фатально — пользователю будет показана ссылка на подключаемый файл. Но мы поступим круче и обойдёмся без яваскрипта. А поможет нам в этом xsl преобразование, накладывающееся само на себя. Напишем index2.xml, который будет ни чем иным, как index.htm обёрнутым в специальную волшебную обёртку. DOCTYPE t:stylesheet [ ATTLIST t:stylesheet id ID #REQUIRED> ]> xml-stylesheet type="text/xsl" href="#t:stylesheet"?> <t:stylesheet id="t:stylesheet" version="1.0" xmlns:t="http://www.w3.org/1999/XSL/Transform"> <t:output method="html" doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" /> <t:template match=" @* | node() "> <t:copy> <t:apply-templates select=" @* | node() " /> t:copy> t:template> <t:template match=" / "> <t:apply-templates select=" document( '#t:stylesheet' )//html " /> t:template> <t:template name="content"> <html> <head> <title>Xbrowser HTML includestitle> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> head> <body> <h1>Second fileh1> <div src="index1.htm" srctype="text/xml"> <a href="index1.htm">link 2 first filea> div> body> html> t:template> t:stylesheet> Доктайп тут выполняет две функции: 1. он указывает xml-процессору, что аттрибут id в t:stylesheet является идентификатором, что позволяет использовать его при указании xsl-преобразования. 2. Если документ будет отдан как text/html, то браузет всё ж будет рендерить страницу в режиме соответствия стандартам. В t:output мы прописываем доктайп по той же причине, только для случая, когда документ был отдан как xml и xslt преобразовал себя в html. Первый шаблон матчится на все узлы и рекурсивно их копирует. Второй — матричится на корень и пропускает xslt тэги, сразу переходя к выводу html. Последнее правило просто содержит html с инклудами. Имя его не имеет никакого значения. Если проверить сейчас это в браузере, то никаких отличий быть не должо. Однако, если добавить ещё один шаблон, то инклуды внезапно заработают. <t:template match=" *[ @src and contains( @srctype, 'xml' ) ] "> <t:copy> <t:apply-templates select=" @* " /> <t:apply-templates select=' document( @src )//html/body/* ' /> t:copy> t:template> Примечательно, что инклудить таким образом можно как xml типа index2.xml, так и html типа index1.htm Напишем index3.xml, который инклудит index2.xml DOCTYPE t:stylesheet [ ATTLIST t:stylesheet id ID #REQUIRED> ]> xml-stylesheet type="text/xsl" href="#t:stylesheet"?> <t:stylesheet id="t:stylesheet" version="1.0" xmlns:t="http://www.w3.org/1999/XSL/Transform"> <t:output doctype-public="-//W3C//DTD XHTML 2.0//EN" doctype-system="http://www.w3.org/MarkUp/DTD/xhtml2.dtd" /> <t:template match=" @* | node() "> <t:copy> <t:apply-templates select=" @* | node() " /> t:copy> t:template> <t:template match=" *[ @src and contains( @srctype, 'xml' ) ] "> <t:copy> <t:apply-templates select=" @* " /> <t:apply-templates select=' document( @src )//html/body/* ' /> t:copy> t:template> <t:template match=" / "> <t:apply-templates select=" document( '#t:stylesheet' )//html " /> t:template> <t:template name="content"> <html> <head> <title>Xbrowser HTML includestitle> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> head> <body> <h1>Third fileh1> <div src="index2.xml" srctype="text/xml"> <a href="index2.xml">link 2 second filea> div> body> html> t:template> t:stylesheet> Для роботов и убогих мобильных браузеров страницы можно просто отдавать как text/html и тогда вместо вставляемого файла будет рисоваться ссылка на него. Совместимость: ie6+, ff3+, opera10+, webkit?+ Реабилитация XML/XSLT технологий sepos — Fri, 20 Aug 2010 12:57:04 GMT Здравствуй. Некоторое время назад мы внедрили у себя в CMS наряду с уже имевшимся к тому моменту собственным шаблонизатором, еще и XSLT. Поскольку есть в XSLT большие и реальные преимущества и для разработчиков, и для хозяев студий, и даже для владельцев сайтов. Но реакция наших партнеров разделилась на противоположные мнения: одни давно ожидали этого и были рады появлению такой возможности, другие поставили под сомнение востребованность XSLT, приводя в качестве аргумента низкую производительность, которую якобы влечет за собой использование XSLT. Понятно, что у всего нового всегда есть сторонники и противники, и рассудит их время. Поэтому не было особого смысла развязывать религиозную войну XSLT vs tpl или Smarty на тот момент. Но мы обнаружили, что оказывается, один из лидеров российского рынка CMS с завидным упорством все пишет и пишет о якобы несостоятельности XSLT как массовой технологии и готов рассматривать ее только в контексте специфичных задач. А это негативно влияет на умы некоторых непосвященных разработчиков об XSLT. С другой стороны, прошедшая недавно крупнейшая европейская IT-выставка CeBIT показала нам, что большинство серьезных западных CMS (и коробочных и внутренних платформ) используют XML/XSLT в качестве единого унифицированного стандарта. Все-таки, российский IT-рынок по скорости внедрения новых технологий слегка отстает от западного. На этом фоне говорить о том, что XSLT - отстой, пока весь мир его использует, не совсем полезно и правильно. Поэтому я, зарегистрировавшись на Хабре, начну с попытки реабилитации несправедливо обиженного XSLT. На мой взгляд, ответственность участников рынка CMS как раз в том, чтобы продвигать современные технологии и быть своеобразными технологическими флагманами. А не дискредитировать их, даже если не получилось реализовать у себя или не нравится. Можно не читать тем, кто и так знает про XSLT или даже использует. Эта статья для тех, кто еще не в теме или сомневается. Тех, кто не согласен - прошу не устраивать холивар. Все имеют право высказывать свое мнение. Шаблонизаторы XSLT, Smarty и внутренние tpl коробочных CMS. Все технологические преимущества XSLT основаны на основной концепции, заложенной в него, - полное разделение бизнес-логики и логики представления. Смешать модели представления и модели бизнес-логики – это смертный грех программиста. И только человек с очень низкой квалификацией с этим не согласится. При этом, например, достаточно популярный шаблонизатор Smarty, не только позволяет реализовывать бизнес-логику в шаблоне, на уровне представления, но и подталкивает разработчика к этому, искушает его быстрым решением сиюминутной задачи. К чему это приведет впоследствии – к неструктурированной цепочке связей между шаблонами и скриптами, которая нарастает как снежный ком и в итоге становится неуправляемой. В итоге изменение, например, одного метода, который используется в шаблоне, приведет к тому, что «упадет» весь шаблон. Любые задачи по расширению становятся сравнимы с «написанием всего с нуля» даже для того разработчика, который изначально вел проект. Не говоря о том, что становится невозможным передача этого проекта другому разработчику. Таким образом, преимущества использования отчуждаемой CMS могут отчасти нивелироваться использованием Smarty, так как в сложном и тем более нестандартном внедрении он делает созданный проект неотчуждаемым от своего разработчика. Смена разработчика в большинстве случаев будет означать то самое «переписывание с нуля», которое, как ни парадоксально, в этом случае окажется более выгодным, чем трудозатраты на изучение «чужого» кода. Очевидно, что это решение не оптимально, и повлечет за собой очередную порцию достаточно существенных финансовых вливаний. Поэтому говорить о невысокой стоимости владения серьезного проекта, созданного с использованием такого шаблонизатора не приходится. Разумеется, если проект небольшой, смены разработчиков не предвидится или вам нужно быстро сделать и забыть – Smarty подходит больше. Также нельзя не отметить незащищенность «от дурака», если в CMS используется Smarty – внедренец невысокого уровня «с помощью» Smarty может легко прямо в шаблоне прописать запрос к БД и обрушить всю систему целиком. Важная характеристика родных tpl-шаблонизаторов CMS – их индивидуальность, т.к. в большинстве случаев они написаны для каждой конкретной CMS. Каждый индивидуальный шаблонизатор требует от внедренца предварительного изучения, и это увеличивает стоимость разработки. В итоге, Smarty на практике показывает себя как простой, привычный, но не очень гибкий, нерасширяемый, слабо отчуждаемый от разработчика, к тому же еще потенциально небезопасный. Эти недостатки всегда сопутствуют смешению бизнес-логики и модели представления данных. И с этой точки зрения, Smarty и ему подобные выступают антиподом технологии XSLT, которая, собственно, и создавалась, для того чтобы все эти недостатки устранить. 10 аргументов в пользу XSLT Надежность технологии 1) XSLT - это давно появившийся индустриальный стандарт, поддерживаемый W3C. Он разрабатывается многочисленной командой профессиональных разработчиков. Технология постоянно улучшается и обновляется за счет качественной поддержки. Во всем мире XSLT уже давно воспринимается как стандарт верстки, в России он используется на таких крупных проектах как Яндекс, Мой Круг и других. Безопасность 2) Жесткое разделение бизнес-логики и модели представления данных ни при каких обстоятельствах не позволит верстальщику «убить» всю систему, если он имеет доступ только к шаблонам. Гибкость 3) XSLT позволяет повторно использовать результаты уже произведенной работы. Единожды сверстанный на XSLT шаблон не держит на себе функциональность бизнес-логики и ее отработки, поэтому он свободно масштабируется и переносится на другие проекты. 4) Для типовых операций достаточно создать шаблон только один раз и использовать его из проекта в проект. Пример из практики: студия-партнер получила заказ на разработку 3-х сайтов автосалона под различные марки автомобилей. На создание первого сайта у нее ушло около 2-х месяцев, второй сайт с учетом новых доработок был разработан за 1 месяц, третий сайт был поднят за 2 недели. Благодаря тому, что собственно технология уже сделана, сайты остается только «разукрасить» (т.е. сменить дизайн). Единожды решенная задача, в следующий раз требует в 2-3 раза меньше времени даже с внедрением новых функций. Доступность, понятность, невысокая стоимость разработки 5) По нашему опыту, верстальщику, знакомому только с HTML и CSS, время разработки проекта на XSLT с нуля составит в среднем около месяца-полутора. При этом если он занимается изучением XSLT в отрыве от других задач по проектам, то может освоить его за полторы недели. Для сравнения – освоить tpl-шаблонизатор конкретной CMS такой же верстальщик сможет в среднем за неделю, а освоение в процессе работы над проектом займет у него тот же месяц. Но XSLT верстальщику нужно освоить только один раз, а каждый отдельный tpl-шаблонизатор тянет за собой отдельное изучение. Поэтому уже после разработки первого проекта на XSLT можно говорить об экономии на этапе внедрения. Отчуждаемость 6) Переработать чужой XSLT-шаблон может любой XSLT-верстальщик. Технология является стандартной, переход от одного разработчика к другому не представляет проблемы, что обеспечивает отчуждаемость проекта и существенную экономию на стоимости владения проектом. Расширяемость 7) Правка XSLT шаблона не предполагает вмешательства в бизнес-логику и анализ структуры связей, которые могли бы использоваться в шаблоне будь он на Smarty. Поэтому, например, изменения в бизнес-логике не приведет к обрушению других шаблонов. В этом уже заложены возможности для последовательного расширения, так как все связи структурированы и поддаются модификации. Расширяемость при таком подходе становится гораздо менее трудозатратной, и снова снижается стоимость владения проектом. При нынешних требованиях заказчиков очень сложно представить проект, который не потребует доработки и расширения в будущем. XSLT –это сейчас наилучший стандарт, который позволяет предусмотреть развитие проекта и закладывать возможности на перспективу. 8) Некоторые задачи, решаемые в XML+XSLT просто и эффективно, представляются как минимум нетривиальными без XSLT. Например, с помощью XSLT можно строить децентрализованные сервисы (в частности, популярный в контексте Веб 2.0 mash-up), можно использовать для построения кластерных систем (конечно же, это не касается CMS). Обмен контентом с другими ресурсами на основе XML-формата позволяет использовать чужие сервисы на собственном сайте. При этом если этот сторонний сервис «ляжет», то с сайтом ничего не произойдет – данные могут браться из КЭШа какое-то время, а потом может перестать отображаться именно этот сервис при остальной работоспособности сайта в целом. Описанный выше подход Smarty благодаря развитым и неструктурированным связям с великой долей вероятности поспособствует тому, чтобы вместе с тем самым сторонним сервисом «лег» и весь сайт целиком. Нативная поддержка XML 9) Изобилие данных в формате XML, которые часто нужно использовать в проекте, - это наша реальность. XSLT- шаблонизатор является «родным» парсером для XML, а все остальные решения – «велосипед». Производительность и скорость работы 10) Один из «недостатков», которые ставятся некоторыми разработчиками в «вину» XSLT - то, что он не может решить задачи бизнес-логики. Сложно представить себе более абсурдное утверждение. В этом смысле накладывать базу данных на XSLT и требовать высокой скорости работы – такой же абсурд, как воспроизводить диск с поддержкой 5.1 через динамик обычного телевизора и требовать при этом Dolby Surround. XSLT по определению не должен этим заниматься, он создан только для того, чтобы реализовывать представление. А вот бизнес-логика должна подготовить те данные, которые ему нужны, чтобы отобразить страницу. И если она их подготовит, то о скорости работы XSLT вопросов возникнуть не может, потому что передавать нужно только то, что будет отображаться на странице (в большинстве случаев 10-50 товаров). Если делать полное преобразование базы на 10 тыс. товаров в XML, а потом на это накладывать XSLT-трансформацию, то результаты производительности будут весьма печальны. При этом будет полностью изнасилована концепция разделения бизнес-логики и представления, на которой основан XSLT. Неудивительно, что при подходе, описанном у Сергея Рыжикова, он не покажет чудес производительности и скорости. О недостатках XSLT. К сожалению, идеальных людей/продуктов/технологий не бывает. XSLT не исключение. Отладка шаблона на XSLT, если в нем допущена ошибка, может потребовать от разработчика существенных усилий по ее нахождению и устранению. При этом даже любой незакрытый тег ведет к неработоспособности всего шаблона. Поэтому XSLT требует от разработчика особой тщательности, аккуратности и внимательности к деталям. Другим ограничением по массовому использованию XSLT в России многие называют существенно более высокий уровень заработной платы XSLT-верстальщика по сравнению с HTML-верстальщиком. Отчасти это так, но во многом ситуация нагнетена искусственно. В свое время, верстка на дивах была такой же экзотикой, как сейчас многим представляется XSLT. Но это не помешало ей получить широкое распространение благодаря реальным преимуществам перед табличной версткой. И дефицит специалистов по дивной верстке достаточно быстро восполнился на рынке. Поэтому появление XSLT-верстальщиков – вопрос при времени при очевидном превосходстве XSLT над другими существующими шаблонизаторами. Выводы. Для начинающего разработчика разобраться с tpl-шаблонами часто проще. Но на определенном этапе развития проекта использование XSLT становится оправданным как с технологической, так и с экономической точки зрения. Поэтому необходимо давать разработчикам выбор между tpl и XSLT. Но самим разработчикам необходимо понимать, что прогресс неизбежен и массовое распространение XSLT – это вопрос времени. Весь мир пошел этим путем и игнорировать его не стоит. Поэтому чем раньше разработчики начнут осваивать XSLT, тем больше денег заработают в будущем. Smarty против XSLT sepos — Fri, 20 Aug 2010 12:45:38 GMT Очень распространено заблуждение о том, что xslt — это сплошные тормоза, а smarty — наше всё. Отставим в сторону лаконичность синтаксиса смарти и удобство поддержки xslt, а устремим наш пристальный взор именно на скорость их работы. Рисовать мы будем нечто чуть более сложное чем «привет мир» — дерево. Это не даст нам использовать копипасту и заставит повторно использовать код для вывода узлов. Количество их пусть будет небольшим — 100 штук. Создадим простенькую объектную модель данных. class Thing { public $color, $shape, $childs= array(); function getArrayData(){ $childs= array(); foreach( $this->childs as $child ) $childs[]= $child->getArrayData(); $data= array( 'color' => $this->color, 'shape' => $this->shape, 'childs' => $childs, ); return $data; } function getXMLData( $doc ){ $node= $doc->createElement( 'thing' ); $node->setAttribute( 'color', $this->color ); $node->setAttribute( 'shape', $this->shape ); foreach( $this->childs as $child ) $node->appendChild( $child->getXMLData( $doc ) ); return $node; } } srand( 0 ); $things= array(); $colors= array( 'red', 'green', 'blue', 'yellow', 'magenta', 'cyan' ); $shapes= array( 'circle', 'ellipse', 'oval', 'rectangle', 'triangle', 'star', 'rhombus', 'trapeze', 'exploit ); for($i=0;$i<100;++$i){ $thing= new Thing; $thing->color= $colors[ array_rand( $colors ) ]; $thing->shape= $shapes[ array_rand( $shapes ) ]; if( $i ){ $things[ array_rand( array_slice( $things, 0, 10 ) ) ]->childs[]= $thing; }; $things[]= $thing; } У каждого узла есть два метода: getArrayData возвращает поддерево в виде структуры из родных массивов, а getXMLData возвращает DOM. Не сложно измерить, что составление DOM требует примерно в 3 раза больше времени. Однако, это всего-лишь предварительная обработка данных. XSLT преобразование $t1= getTime(); $doc= new DOMDocument; $data= $things[0]->getXMLData( $doc ); $t2= getTime(); $doc->appendChild( $data ); $xsl= new DOMDocument( ); $xsl->load( 'tpl.xsl' ); $proc= new XSLTProcessor( ); $proc->importStyleSheet( $xsl ); echo $proc->transformToXML( $doc ); $t3= getTime(); xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> method="html" /> match=" thing "> style="color:{@color}"> select=" @color " /> > > select=" @shape " /> > > select=" thing " /> > > > Результат: 3 + 5 = 8 Smarty шаблонизация $t1= getTime(); $data= $things[0]->getArrayData(); $t2= getTime(); $smarty= new Smarty; $smarty->template_dir = '.'; $smarty->compile_dir = '.'; $smarty->assign( 'thing', $data ); $smarty->display( 'tpl.smarty' ); $t3= getTime(); {function name="proc"} {$thing.color|escape} {$thing.shape|escape} {foreach from=$thing.childs item=child} {proc thing=$child} {/foreach} {/function} {proc thing=$thing} Результат: 1 + 20 = 21 ______________________ PHP быдлокод $t1= getTime(); $data= $things[0]->getArrayData(); $t2= getTime(); include( 'tpl.php' ); $t3= getTime(); function akeurwbkurlycqvaelkuyrc( $data ){ ?> htmlspecialchars($data['color'])?>"> htmlspecialchars($data['color'])?> htmlspecialchars($data['shape'])?> foreach( $data['childs'] as $child ) akeurwbkurlycqvaelkuyrc( $child ) ?> } akeurwbkurlycqvaelkuyrc( $data ); Результат: 1 + 2 = 3 Прочий код function getTime(){ return 1000 * microtime( true ); } preprocessing: $t2 - $t1 ?> templating: $t3 - $t2 ?> total: $t3 - $t1 ?> Тестовый стенд php 5.3.1, libxml 2.7.3, libxsl 1.1.23, smarty 3 rc2 Выводы Компиляция шаблонов в PHP вовсе не гарантирует производительности, в то время как работа с DOM не сильно и медленней нативной лапши.