Сегодня объекты используются очень активно, хотя это трудно было предположить после выхода PHP 5 в 2005 году. Тогда я ещё мало что знал о возможностях этого языка. Пятую версию PHP сравнивали с предыдущей, четвёртой, и главным преимуществом нового релиза стала новая, очень мощная объектная модель. И сегодня, десять лет спустя, около 90% всего PHP-кода содержит объекты, не изменившиеся со времени PHP 5.0. Это убедительно говорит о том, какую роль сыграло внедрение объектной модели, неоднократно улучшавшейся на протяжении последующих лет. В этом посте я хотел бы рассказать о том, как всё устроено «под капотом». Чтобы люди понимали суть процессов — почему сделано так, а не иначе — и лучше, полнее использовали возможности языка. Также я затрону тему использования памяти объектами, в том числе в сравнении с эквивалентными массивами (когда это возможно).

Я буду рассказывать на примере версии PHP 5.4, и описываемые мной вещи справедливы для 5.5 и 5.6, потому что устройство объектной модели там почти не претерпело изменений. Обратите внимание, что в версии 5.3 всё не так хорошо с точки зрения возможностей и общей производительности.

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

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

Очень маловероятно, что на production-серверах PHP-код изменится между выполнением нескольких запросов. Так что можно считать, что при компилированиях всегда считывается один и тот же исходный код, а значит и опкод будет точно таким же. И если извлекать его для каждого скрипта, то получается бесполезная трата времени и ресурсов.

Меня зовут Оксана Харчук, я работаю QA-инженером в DataArt чуть больше года. Расскажу, как в нашем проекте организован процесс работы, и как быть, если релиз каждый день.

Сначала, когда я только пришла в DataArt, слово «релиз» ассоциировалось у меня с чем-то страшным. Но, как оказалось, если процесс работы построен правильно, релизы даже каждый день — совсем не страшно, а очень даже удобно.Чтобы этого достичь, процесс разработки в нашем проекте построен на принципах непрерывной поставки (continuous delivery) и непрерывной интеграции (continuous integration).

Что такое Continuous delivery и Сontinuous integration?

Continuous delivery или непрерывная поставка ПО — набор практик и принципов, нацеленных на сборку, тестирование и поставку ПО быстрее и чаще. Непрерывная поставка качественного кода опирается, в свою очередь, на непрерывную интеграцию.

Сontinuous integration, или непрерывная интеграция — это практика разработки ПО, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Ведь ясно: если над разными частями кода работают несколько программистов, при интеграции этих частей возникает много трудностей. Непрерывная интеграция помогает справиться с ними.

Этим летом в Москве проходила конференция профессиональных веб-разработчиков DevConf 2014. Мы в Badoo поддерживали конференцию, выступали с докладами и сделали видео докладов, которые были интересны нашим разработчикам. Так как спикеры были «за», то мы делимся видео с нашими подписчиками.

1. «StatsCollector, или «Мама! Он и меня посчитал!»».
Старынин Валерий, PHP разработчик отдела BI, Badoo.
Доклад о том, как мы собираем статистику для каждого пользователя, обсчитываем каждое открытие страницы (и не только!), обрабатываем 120000 событий в секунду и планируем расширяться.

Хочу рассказать о своем эксперименте по проверке «Теории шести рукопожатий». На написание этого материала меня вдохновила статья «Анализ дружеских связей VK с помощью Python» (чтобы избежать повторений, в дальнейшем я буду ссылаться на нее). Так как в целом задача мной была поставлена по-другому, да и использованные методы тоже отличаются, то я решил что это может быть интересно.

Как определить чиновников, наиболее подозрительных с точки зрения коррупции? Проще всего — сравнив их доходы и уровень жизни.

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

Почему открытая информация о доходах чиновников важна? Потому что это позволяет их контролировать.


Фото из инстаграмма дочери бывшего руководителя ГАИ Украины Александра Ершова. На фото дочь Ершова в Каннах рядом с Пэрис Хилтон. В результате скандала из-за несоответствия задекларированных доходов и образа жизни семьи Ершов подал в отставку.

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

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

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



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

Сегодня мы представляем вашему вниманию адаптированную подборку инструментов (в том числе облачных) для разработчиков, которые позволяют создавать по-настоящему качественные проекты. Здесь представлены исключительно SaaS, PaaS и IaaS сервисы, предоставляющие бесплатные пакеты для разработчиков инфраструктурного ПО.

В 1940-е вам нужна была специальная бабка, которая считает людей на входе в магазин. В 1950-е верхом прогресса была камера, плёнку с которой потом можно было анализировать. В конце 80-х в США и Европе (в т.ч. Германии) начали распространяться инфракрасные датчики или просто счётчики открывания-закрывания дверей на герконах. Сейчас технологии медленно дрейфуют к тому, чтобы засекать ваши широковещательные пакеты Wi-Fi и Bluetooth (рассылку поиска сетей), чтобы отслеживать перемещения телефона с точностью до 3 сантиметров. Плюс растёт значение распознавания потоков людей с видеосистем.

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


^{Самая простая реализация после геркона — пересечение ИК-луча}

Может показаться, что кроме подсчёта посетителей в магазине, такие штуки ни для чего не нужны. Однако, если утыкать ими весь торговый центр, даже простая линейная аналитика даёт кучу полезного. Например, грамотный торговый центр по отслеживанию потоков знает, что магазин перестал нравиться его аудитории — и точно численно понимает, на место кого сажать нового арендатора.

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

Предположим, у вас есть prod и test базы данных. В какой-то момент разработчик внес изменения в тестовую базу, но забыл внести эти изменения в боевую базу. Если это часто используемая таблица, то ситуация очень быстро становится очевидной, так как в логах появятся ошибки в SQL-запросах и вам начинает звонить начальник с упреками «какого @#$%».

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

Еще вариант — вы провели обновление ПО и у вас все перестало работать. Куча непонятных ошибок на пустом месте, приложение лежит, пользователи не довольны.

В таких случаях бывает очень полезно посмотреть чем же отличаются базы и сделать соответствующие выводы.

Я рад бы написать что “эта статья предназначена для новичков”, но это не так. Большинство php-разработчиков, имея опыт 3, 5 и даже 7 лет, абсолютно не понимают как правильно использовать эксепшены. Нет, они прекрасно знают о их существовании, о том что их можно создавать, обрабатывать, и т.п., но они не осознают их удобность, логичность, и не воспринимают их как абсолютно нормальный элемент разработки.

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

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

Представление данных

До этого мы обращали много внимания на поведение и общую структуру кода, но забиывали про на данные, с которыми имеем дело. Сейчас у нас все является строками, включая возвращаемое значение CatApi::getRandomImage(). То есть вызывая этот метод, мы «знаем», что получим строку. Говорю «знаем», так как PHP может вернуть все — объект, ресурс, массив и т.д. Тем не менее, хоть в случае с RealCatApi::getRandomImage() мы и можем быть уверенны, что нам придет строка, так как мы явно приводим значение к ней, мы не можем точно сказать, что эта строка будет «полезна» (валидна) для того, кто вызвал этот метод: это может быть и пустая строка, строка, которая не содержит URL (типа «I am not a URL») и так далее.

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

Хочу табличку! Хочу табличку с сортировкой, опциональной разбивкой по страницам и близкой к стилю bootstrap, но так, чтобы в нее можно было добавить много много колонок.

Что нужно подготовить заранее?

1. Yii Framework ( http://www.yiiframework.com/ )
Нужно скачать, установить, запустить, разобраться с логикой построения проектов.

2. jQuery EasyUI ( http://www.jeasyui.com/ )
Нужно скачать, распаковать и скопировать в папку с ресурсами проекта в Yii Framework и подключить следующие файлы:

/easyui/themes/default/easyui.css
/easyui/themes/icon.css
/easyui/jquery-1.8.0.min.js
/easyui/jquery.easyui.min.js

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


*квадраты до сотни

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

Собирался написать комментарий, но незаметно вырос целый пост.

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

В данной заметке хотел бы поделиться личным опытом непосредственного сравнения Microsoft Office под Windows и Mac; постараюсь обобщить большинство вопросов и нюансов, возникающих при обдумывании как индивидуального перехода, так и перевода организаций и групп.

Свой индивидуальный опыт я считаю достаточно репрезентативным в связи с тем, что являюсь профессиональным пользователем Microsoft Office с 1996 года. Я профессионально как автор, рецензент и редактор с 1996 года ежедневно (может быть, разве что за исключением дня свадьбы) вынужден находиться в Microsoft Office буквально круглосуточно. За день через меня проходят примерно 25-30 файлов Word и 15-20 файлов Powerpoint, содержащих любые возможные функции, т.е. достаточно больших и сложных (Word, как правило, не менее 200 страниц; Powerpoint, как правило, не менее 70 слайдов). За прошедшие 14 лет я попробовал все имевшиеся версии Microsoft Office на всех имевших место версиях Windows. Надеюсь, что обратившие на себя мое внимание особенности будут репрезентативны для более «мягких» сценариев. Хотелось внести некоторую ясность, т.к. с одной стороны сама Microsoft и большинство деловых пользователей в США утверждают о полной совместимости, в то время как в рунете в большинстве случаев можно услышать противоположное.

Сегодня я хочу рассказать о том как я мучался с PHPUnit, Selenium RC и Facebook'ом :)

В новых смартфонах Samsung есть весьма интересная фича — Multi Windows.
Она позволяет запускать одновременно два приложения в одном окне.
К сожалению, кроме Samsung эту фичу пока что мало кто поддерживает.
Но на самом деле её не так уж и сложно добавить к уже существующему приложению.

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

Все нижеописанное характерно для моей компании, но сам HR достаточно стандартен по калифорнийским стандартам (что сейчас уже практически стало международными стандартами). Никакого пиара, так что просто в двух словах: моя компания — это маленькая транснациональная компания со штатом где-то в 4000 человек, HQ — в Palo Alto, R&D (где я работаю) — Vancouver, BC. Я интервьюирую на позицию в моей команде, которая занимается разработкой web-frontend для встраиваемых устройств (используется Python, C и стандартный HTML-набор).