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

Памятка начинающему экзорцисту.

Прежде, чем начать: я знаю, что такое phpDaemon и System_Daemon. Я читал статьи по этой тематике, и на хабре тоже.

Итак, предположим, что вы уже определились, что вам нужен именно демон. Что он должен уметь?

• Запускаться из консоли и отвязываться от неё
• Всю информацию писать в логи, ничего не выводить в консоль
• Уметь плодить дочерние процессы и контролировать их
• Выполнять поставленную задачу
• Корректно завершать работу

Отвязываемся от консоли

// Создаем дочерний процесс
// весь код после pcntl_fork() будет выполняться двумя процессами: родительским и дочерним
$child_pid = pcntl_fork();
if ($child_pid) {
    // Выходим из родительского, привязанного к консоли, процесса
    exit();
}
// Делаем основным процессом дочерний.
posix_setsid();

// Дальнейший код выполнится только дочерним процессом, который уже отвязан от консоли

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

Все встреченные варианты по тем или иным причинам меня не устроили и пришлось написать свое решение.
Набор требований у меня был следующий:

• Использование форков;
• Синхронный режим с сохранением интерфейса при отсутствии необходимых расширений;
• Многократное использование дочерних процессов;
• Полноценный обмен данными между процессами. Т.е. запуск с аргументами и получение результата по завершении;
• Возможность обмена событиями между дочерним процессом-«потоком» и основным процессом во время работы;
• Работа с пулом потоков с сохранением многократного использования, передачи аргументов и получения результатов;
• Обработка ошибок выполнения;
• Таймауты на выполнение работы, ожидание работы потоком, инициализацию;
• Максимум производительности;

В результате получилась библиотека AzaThread (старое название — CThread).

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

Например, встречались такие варианты:

if ($error['type'] == E_ERROR || $error['type'] == E_PARSE || $error['type'] == E_COMPILE_ERROR){…}

или

if(in_array($error['type'], array(E_ERROR, E_PARSE,  E_COMPILE_ERROR)) {…}

В связи с этим решил написать небольшую статью о битовых операциях с примерами их использования.

Все началось в середине сентября. На тот момент, наш стартап работал уже пол-месяца и все, что мы собирались делать в публичном плане – это участвовать в предстоящем в Кишиневе Startup Weekend’e, который намечался на 11-13 ноября. Просматривая организаторов данного мероприятия, у меня в голове была только одна мысль – найти кого-нибудь, кто помог бы нам попасть в Кремниевую Долину. Тогда эта была всего лишь мысль и о том, каким образом и как скоро она реализуется я даже и представить не мог.

Добрый день, Хабр.

Я хочу написать цикл статей о создании расширений для Google Chrome. К этому меня побуждает, во-первых, практическая польза самого процесса разработки и последующего использования: вы сами определяете, какие ещё задачи хотите решить не выходя из браузера и, во-вторых, отсутствие каких-либо внятных гайдов, туториалов и справочников на русском языке, за исключением, пожалуй, этой и вот этой статей на Хабре. Основная цель цикла — систематизировать разрозненную информацию и облегчить поиск потенциальным разработчикам, благо индексируется Хабр хорошо :)

В первой (этой, то бишь) статье, на примере простейшего расширения, будут рассмотрены все основные моменты, связанные с разработкой, отладкой и использованием расширения, конфигурационный файл manifest.json и начала chrome.* API. Первая же статья, думаю, будет не очень полезна опытным разработчикам (это дисклеймер).

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

Безусловно в этом списке вы обязательно найдёте уже знакомые расширения, однако огромный пласт полезных расширений всегда остаётся в стороне. Так что приготовьтесь установить ещё парочку расширений! :)

Встроенные инструменты разработки в Firefox

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

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



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

Однажды в студеную зимнюю пору я столкнулся с упоминанием того, что кто-то в Facebook пытается подтвердить теорию шести рукопожатий. Для тех кто не в курсе, эта теория заключается в том, что все жители земли в среднем знакомы друг с другом через цепочку из пяти друзей (т.е. шести рукопожатий). Подробнее об истории этой теории можно прочитать в википедии, там же можно узнать о том, что Майкрософт несколько лет назад пыталась подтвердить эту теорию на основе данных о контакт-листах мессенджера MSN — в результате у них получилось 6,6 рукопожатий, что вполне вписывается в теорию.

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

1. На каких данных это все расчитывать.
2. Где эти данные взять.
3. Как эти данные сохранять.
4. Каким алгоритмом воспользоваться для расчетов.

Добрый день, Хабрасообщество!

Спустя 3 месяца после призыва о помощи, команда переводчиков документации PHP спешит рассказать как много мы достигли вместе с вами, читатели Хабра.
Самое главное: русская документация PHP снова в строю!

Прогресс сообщества PHPDoc-RU

С 1 августа и по 12 ноября объем переведенной документации вырос в 4 раза и составил более чем четвертую часть общего количества файлов и больше трети от их объема.



Подробности под катом (Графика: ~ 65Кб).

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

1. Почему стоит начать работать «в белую»
2. Почему на начальном этапе ИП лучше ООО
3. Что делать, если партнёров несколько

Если вы – начинающий или уже опытный фрилансер и подумываете о работе «в белую», но ещё точно не определились с вопросами «Стоит ли оно того?» и «ИП или ООО?», вэлком

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

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

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

Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле .htaccess. Отличия при работе в контексте <VirtualHost> изложены в конце статьи.

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

Почему так происходит?

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

Когда появился php5 с исключениями, а затем ZendFramework, который всегда кидает исключения — я не мог понять: чем же exception лучше моего любимого trigger_error()? Долго думал, обсуждал с коллегами и разобрался в этом вопросе. Теперь я чётко знаю, где использовать trigger_error(), а где throw new Exception().

В чём же принципиальная разница между ними?

Добрый день. Хочу поделиться историей, которая произошла со мной буквально вчера, но обо всем по порядку.

Доброго времени суток всем желающим приобщиться к миру пользовательских скриптов (они же userscript, userJS, юзерскрипты).

В этой статье я хочу поведать о том, что такое юзерскрипты, c чем их едят и, главное, как их готовят!

Внимание: предполагается минимальное знание javascript.
На практике доказано: юзерскрипты может писать человек, не знакомый с программированием, но обладающий усидчивостью и желанием изучить javascript!
О том, что такое javascript и как с ним обращаться, можно узнать на javascript.ru.

При использовании свойств box-shadow или border-radius непосредственно на изображении, браузеры могут некорректно отображать заданные нами CSS стили, из-за чего внешний вид блока будет существенно отличаться от задуманного. Однако если использовать изображение в качестве фона, то этой проблемы можно запросто избежать. Из статьи вы узнаете, как с помощью jQuery сделать идеально закругленные углы у изображений, а так же какие еще способы оформления возможны с помощью таких свойств как box-shadow, border-radius и transition.

Приветствую всех. Являясь большим поклонником продукции одной известной фруктовой компании, решил попробовать свои силы в разработке под iOS. И вот хочу поделиться своим опытом и трудностями, с которыми я столкнулся, во время написания и публикации своего, фактически первого, приложения в App Store. Может быть, мой опыт окажется кому то полезным. А трудностей было предостаточно. В процессе публикации в App Store приложение было 2 раза отклонено и третий раз висело 6 дней в статусе «In Review». В итоге моя настойчивость победила, приложение опубликовали и оно попало в пятерку русского App Store в категорию Top Free iPhone Navigation Apps. И так все по порядку.

18 сентября состоялся финальный раунд всероссийского кубка по программированию Russian Code Cup. В этом году в финал олимпиады вышли 50 программистов — 27 из России, 11 из Украины, 7 из Беларуси, двое из США и по одному из Армении, Грузии и Швейцарии.



Победителем стал Петр Митричев из Москвы. Он получил приз в 10 тыс. долл. США. Второе место занял Евгений Капун из Санкт-Петербурга, он получил 5 тыс. долл. США. На третьем месте — Михаил Дворкин из Санкт-Петербурга с призом в 3 тыс. долл. США. Поздравляем ребят и желаем им дальнейших успехов!

В этой статье мы проведем разбор задач из финального раунда.

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

Что делает холодным воскресным утром нормальный человек? Любой вам ответит: холодным воскресным утром человек спит. Потому что всю неделю он работал и хочет отдохнуть.
Что делает холодным воскресным утром программист? Холодным воскресным утром программист пьёт горячий чай и пишет код. Чай он пьёт, потому что утро холодное, да и проснулся ещё не до конца, а код пишет, потому что хочется. Программисту всегда хочется писать код, только в будни он пишет код за деньги и от этого очень устаёт, а в выходные для себя, поэтому отдыхает.

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

Как вы возможно помните, когда-то мы писали интерпретатор языка Йоба. С тех пор интерпретатор был незначительно улучшен, выделен в отдельный класс, стал принимать строку на вход, отдавать строку на выход (вместо работы с консолью). Теперь нашей задачей станет внедрение Йобы в качестве основного языка компании Google превращение интерпретатора Йобы в веб-приложение, да не простое — а клиентское. Хоть я и добавил в класс счётчик операций, чтобы нельзя было слишком обнаглеть, но всё равно — пусть пользователь на своём компьютере вычислительные мощности тратит, а не на сервере.