Просто про веб технологии

Сегодня Facebook анонсировал релиз HipHop.

Коротко, что такое HipHop для PHP:

• HipHop – это компилятор кода PHP в C++. Т.е. он преобразует PHP код в C++ код для дальнейшей компиляции. Это не другой язык. И это не компилятор времени исполнения (JIT).
• HipHop будет выпущен Facebook под opensource лицензией, под такой же как и основной код PHP. Facebook возлагает надежды, что разработчики улучшать HipHop и расширят его функциональность, таким образом HipHop сможет заменить больший набор функций PHP.
• HipHop был одним из проектов в Facebook по улучшению его производительности. Все таки Facebook, второй сайт по объему траффика в интерент и в основном построенный на PHP. HipHop запущен на большинстве LAMP PHP серверах Facebook и в среднем улучшил производительность этих серверов в два раза.
• HipHop достигает этого, путем исследования вашего PHP приложения и на его основе строить C++ проект. C++ проект потом компилируется и запускается на собственном веб серврере. Это дает возможность исключить PHP Zend engine и Apache из цепочки.
• Учитывая что, некоторые возможности PHP не поддерживаются. Также, дополнения к PHP написанные на C, должны быть переписаны в HipHop C++ дополнения.
• Преимущества в скороости HipHop достигаются благодаря статическому анализу, который парсит ваш PHP код ищя пути преобразования динамических частей в статические.
  Учитывая это, ваше улучшение производительности, может сильно варьроваться – более структурированный код получить наибольший прирост в производительности.

Что значит HipHop для вас:

• Если ваш проект использует sharing хостинг – то ничего.
• Если ваш проект использует 2 или менее серверов – то ничего.
• Если у вас нет выделенного development и deployment окружения и у вас нет разработчика знающего C++ – то ничего.
• Если вы разработчик open source приложения – то немного.
• Если вы shared хостинг компания – то немного.
• Если PHP не bottleneck вашего приложения – то пока еще ничего.
• Если ваше приложения использует много серверов, и в основном на них работает PHP, а также у вас есть все исходники PHP кода, у вас есть немного знаний C/C++, тогджа ответ возможно.
• Если вы разрабатываете php framework, то ответ иногда.
• Если у вас есть сильно-связанные части архитектуры, которые удовлетворяют требованиям выше и эти части слабо связаны (через API) с остальной системой, то ответ много что.
• Если вы обдумываете какой язык выбрать для реализации вашей системы, то ответ очень много.
• Если вы обдумываете аргумент, переписать весь сайт на другой язык, то вы потеряли свой аргумент.

Есть очень много языковы возможностей, хороших или плохих, которые PHP должен поддерживать, а HipHop нет. Потому как HipHop уникальное решение, он никгода не заменит Zend Engine.

Статья является частичным переводом статьи Terry Chay Faster PHP fo shizzle—HipHop for PHP

Michelangelo van Dam написал краткое введение в Unit тестрование на Zend Framework 1.8+.
Так как версия Zend Framwork 1.8 была сильно переработана, то по сути это первое руководство описывающее как писать Unit тесты в ZF 1.8+.
Начиная с этого момента, можно сказать, что теперь разработчикам не на что жаловаться – руководство есть, начинаем писать тесты. :)

Одни оптимизации полезны, другие просто пустая трата времени.
Вот пример наиболее частых заблуждений:

а. echo быстрее чем print
Echo может быть быстрее, так как оно не возвращает значение. Но, в моем бенчмарке преимущество было очень мало. А, в некоторых ситуациях print будет быстрее echo, например когда ob_start включен.

б. меньше комментариев ускоряет код
Если вы используете кеширование opcodes, то комментарии уже игнорируются. Этот миф идет от PHP3, когда каждая строка PHP интерпретировалась во время исполнения.

в. 'var='.$var быстрее чем, "var=$var"
Так было до версии 4.2 и было исправлено в версии 4.3.

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

И тот же самый код без ссылки.

PHP не создает дубликат переменной "отправленной по значению", вместо этого он использует внутренних высокоскоростной подсчет ссылок. Поэтому в TestRef(), $b и $c будут дольше устанавливаться, так как надо вести "трэкинг" ссылок, в то время как в TestNoRef(), $b и $c сразу будут ссылаться на исходное значение $a, а значение счетчика ссылок будет инкрементировано.
В сравнении, функции которые принимают массивы и объекты, работают быстрее тех, которых принимают ссылки. Потому что, массивы и объекты не используют подсчет ссылок, а используется оригинальное значение переданное в параметре.
Например:

медленнее чем:

Примечание: в PHP5 все объекты передаются по ссылке, и нет необходимости устанавливать знак '&' в списке параметров. Производительность работы с объектами в PHP5 значительно выше, чем в php4.

Интересная статья описывающая важность умения читать код и документации.

Когда я заступил на работу в компанию CQG в конце 1999 года, у меня уже был, как мне казалось, достаточно большой опыт в разработке ПО – три года создания корпоративных приложений БД под заказ. Мне уже казалось, что я очень много знаю и умею, и я был крайне самоуверен. Однако, возникла некоторая загвоздка – CQG не являлось приложением баз данных, основанном на комбинации готовых сторонних технологий, таких как MS SQL сервер, Visual Basic, Delphi, JavaScript, и 1C – к которым я привык. Меня потряс объем приложения – почти 50 мегабайт основных исходников, не считая свистулек, прибамбасов, разного рода служебных и системных штук, по размеру почему-то превосходящих размер основных исходников.

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

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

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

Каких-либо иллюзий на свой счет, меж тем, к тому моменту у меня уже не осталось – я понял, что цена всем моим знаниям, университетскому образованию, и опыту – ломаный грош. Меня поражал простой факт – я был объективно образован в Computer Science гораздо лучше Тола, и _знал_ больше. При этом, и, после некоторого опыта работы, я был в этом абсолютно уверен – я бы не смог спроектировать и реализовать такую систему за год, как это десять лет назад с одним помощником сделал Тол. Сложность системы явно превосходила мои возможности - я бы по ходу работы закопался в деталях. И уж тем более, у меня не получилось сделать систему так гибко, чтобы она прожила 10 лет, и была до сих пор адекватна ситуации.

То есть, до меня начало доходить, что есть нечто очень важное, что совершенно перпендикулярно университетскому образованию, чего нас просто не учили даже замечать. Оно перпендикулярно «дизайн-паттернам» и книгам по ОО проектированию. И оно, это нечто, у Тола есть, а у меня – нет. Если мои знания не могут мне помочь сделать такую систему – то много ли они стоят? Понимание и знание требуется для действия, ни для чего другого – это не китайская декоративная ваза.

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

По большей части это напоминало дзен, когда вам дают задание, разрывающее мозг, вроде хлопка одной ладонью, и через некоторое время вы неожиданно ловите просветление. Удивительный опыт. Вот один небольшой пример, на что это было похоже.
- Тол, скажи, а как работает вот эта штука.
- Влад, вот этого я на самом деле не знаю. А ты почитай код, и разберись!
- Тол, ты издеваешься надо мной?! Здесь пятьдесят мегабайт этого гребанного недокументированного кода! Ты знаешь все Тол, и это ни для кого не секрет.
- Хорошо, смотри, – не стал спорить Тол, - Я тебе говорю – я не знаю, и поэтому я должен сам почитать код, чтобы ответить на твой вопрос. Поэтому, я открываю код.
Тол открывает правильный файл в одну попытку, продираясь через файловую систему, не пользуясь класс-браузером, мотает файл в правильную середину.
- Так. Ты сказал, вот эта фигня? Вот, открыл. Так… Тебе нужен вот этот метод. Читаем. Вот, смотри, он вызывает вот этого парня (так Тол называл классы и объекты – look – now this guy tell that guy to do this thing). Видишь? Вот, происходит тут то-то и то-то. Все просто.
- Спасибо, Тол! Теперь все ясно. А говорил – не знаешь!
- Я тебе говорю – код читай, блин! Все то же самое ты можешь сделать сам!
- Тол, ну в нем же нихрена не понятно без документации, - сказал я, будучи совершенно уверен, что я не смогу сделать того же сам. Происходящее напоминало ловкий фокус.
- Тебе, чтобы читать код, нужна документация? Прости – какая?
- Ну, там, диаграммы классов, например.
- У нас была одна, вроде, составленная лет пять назад. Она сейчас, мягко говоря, не соответствует действительности. Сам понимаешь, у нас 50 инженеров, и разработка идет очень активная. Но если ты уверен, что она тебе поможет, я могу поискать, – участливо смотрит на меня Тол, - ну так что, искать?
- Не, устаревшая, мне, пожалуй, не поможет, - подумав, ответил я, - это ж я все равно должен весь код изучить, чтобы понять, где ей можно доверять, а где нет.
- На самом деле, я не уверен, что тебе сильно поможет даже новая, и поэтому я тебе и говорю: код – лучшая документация! – терпеливо разъясняет Тол, - Она _всегда_ актуальна, и _никогда_ не устаревает, помимо того, что более информативна чем диаграмма классов, конечно.
- Хорошо, я понял, а может, ты мне еще объяснишь, вот в этом месте как работает…
- Нет. Это ты мне объяснишь, после того, как прочтешь. Мне как раз надо скоро будет туда правки вносить. Давай, парень, я не тебя рассчитываю. Иди - читай код.
- Хорошо, Тол, – обреченно сказал я, и пошел читать код.

Да, надо сказать, я тогда немного обиделся на Тола, я думал, что он нифига не понимает. И долгое время считал, что он был не прав. Как-то года через три ко мне подошел коллега, с вопросом. Я был утомлен от работы, голова соображала вяло. К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?

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

Я читаю код, без труда восстанавливая логику поведения и структуру программы в уме, и одновременно простыми словами объясняю это коллеге. Тут у меня в голове что-то перещелкивает, и я с изумлением вспоминаю наш разговор с Толом трехлетней давности, сознание у меня как бы раздваивается, и я наблюдаю за собой со стороны.

- Вот, видишь, как все просто, - заканчиваю я. И к своему чудовищному удивлению добавляю, то, что надо сказать, потому что это правда:
- А вообще - читай код. Код – лучшая документация. Ты вот думаешь, я разбираюсь в этой подсистеме? Нет, я этот код вижу в первый раз, так же как и ты.
- Но этот код совершенно не документирован! Диаграммы хоть какие-нибудь бы!
- Смотри, - говорю я улыбаясь, окончательно осознавая, что Тол в очередной раз, как и всегда, оказался прав, - вот я запускаю Rational Rose, где у меня всосана вся наша система в режиме reverse engineering, и бросаю на чистый лист эти пять классов. Видишь? Вот тебе свежая, актуальная диаграмма. Какой смысл тратить усилия на документирование того, что устаревает за год, и может быть в любой момент восстановлено за пару минут? Если она тебе сильно поможет, я сейчас ее тебе распечатаю. Распечатать?
- Да нет, пожалуй, - задумчиво отвечает коллега, рассматривая диаграмму. Ясности она не добавляла.
- Вот. Диаграммы не стоят ничего, ценны мыслительные процессы, происходящие у тебя в голове в процессе их составления. Поэтому я и говорю: код – лучшая документация. Читай код.

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

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

Толу на самом деле было все равно, есть документация или нет. В совершенстве владея reverse engineering, он в уме потрясающе легко умел переходить от кода к архитектуре, и наоборот. В результате, проектируя, он всегда детально представлял, в какой код превратятся его мысли, и поэтому был способен быстро прокручивать в голове огромное количество вариантов, отбрасывая "плохие". В его понимании, архитектор, не умеющий читать чужой код с "листа", и не пишущий своего - подобен инвалиду, пытающемуся бегать на костылях. Он довольно быстро закончит очень плохим архитектором - вопрос нескольких лет.

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

Оригинал статьи здесь: http://gaperton.livejournal.com/32772.html

Техника Clickjacking заключается в создании специального iFrame с помощью CSS и Javascript, который создает кнопку-подделку. По нажатию на эту кнопку в невидимый iframe загрузится специальная страница с вредоносным кодом. Спрятанная страница может быть подделкой текущей и заставить юзера делать, то что он не желал, например заново пройти аутентификацию, для считывания его регистрационных данных. Бороться против этого на данном этапе уже поздно.

На данный момент FireFox не имеет методов борьбы с ClickJacking, но вы можете установить расширение No-Script который имеет новую возможность ClearClick и защищает пользователя от данного типа атаки.

InternetExplorer также не имеет никакой техникик защиты, только в IE8 появилась частичная защита от ClickJacking.

Будте бдительны нажимая на интригующие кнопки обманки и ставте себе No-Script.

Clickjacking on Wiki

Twitter пострадал от ClickJacking

Как бороться с ClickJacking

Новый движок XtraDB был выпущен Percona как замена стандартного InnoDB.

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

Percona XtraDB включает всю InnoDB ACID-совместимую архитектуру и расширенную MVCC архитектуру, добавлены новые возможности, более тюнингована, более информативна, более масштабируема на мульти-процессорных системах, и с улучшенной системой использования оперативной памяти.

Что нового в этом движке? Вот список улучшений:

• INFORMATION_SCHEMA.XTRADB_ENHANCEMENTS. Эта таблица содержит информацию про различия XtraDb и той же версии InnoDb.
• Улучшения в SHOW INNODB STATUS.
• Улучшения в InnoDB IO.
• InnoDB RW-lock fixes. Улучшена масштабируемость для систем с 8+ ядер.
• Buffer pool fixes
• innodb_buffer_pool_pages

В общем это сейчас тунингованый InnoDB, только OpenSource. Для комьюнити публичный OpenSource считаю большим плюсом.

Percona сделала и продолжает делать отличную работу по развитию и поддержке MySQL.

Думаю Percona это новая MySQL и уже в скором будущем мы не раз в этом убедимся. :)

Оффициальный анонс XtraDB

Тесты производительность ввода вывода XtraDB

Тесты производительности и нагрузки CPU XtraDb

Документация по XtraDB http://www.percona.com/docs/wiki/percona-xtradb:start

Исходные коды на XtraDB https://launchpad.net/percona-xtradb

Обсуждения XtraDB и остальных разработок Perocona http://groups.google.com/group/percona-dev

Хочу сказать спасибо всем, кто дал отзыв в первой части статьи «Рефакторинг для начинающих». Особенно спасибо Yury Veretelnikov, за его (в большинстве случаев) справедливую критику, которая открыла мне глаза на проблемы в оформлении и написании статьи.

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

Кратко содержание:

• Цель рефакторинга
• Простые и сложные методы рефакторинга
• Когда начинать рефакторинг?
• Как начать рефакторинг?
• Как не поломать рабочий код?
• Когда рефакторинг не нужен?
• Каталог методов рефакторинга и примеры рефакторинга

А теперь кратко по каждому пункту.

Цель рефакторинга

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

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

Простые и сложные методы рефакторинга

Простые методы рефакторинга — это базовые, фундаментальные методы применяемые в рефакторинге. Например это: выделение метода, перемещение поля класса, выделение класса, переименование метода, класса или поля и т.д.

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

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

Когда начинать рефакторинг?

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

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

Применяйте рефакторинг при разборе кода. Разбор кода это хорошая практика, когда в команде разработчиков, разработчики проверяют код друг друга.

Как начать рефакторинг?

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

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

Как не поломать рабочий код?

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

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

Когда рефакторинг не нужен?

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

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

Другой случай, когда следует воздержаться от рефакторинга, это близость даты завершения. Однако приближение срока окончания работ — единственный случай, когда можно отложить рефакторинг, ссылаясь на недостаток времени.

Каталог методов рефакторинга и примеры рефакторинга

Большой каталог методов рефакторинга можно найти на refactoring.com вместо примеров кода, тут применяются примеры на языке UML.

Также, хороший каталог методов рефакторинга можно найти на wikipeadia, каждый метод снабжен примером на C#.

В заключении

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