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

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

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

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

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

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

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

В моем случае, в качестве frontend сервера, стоит nginx и формат access-лога имеет вид:

log_format main '$remote_addr — $remote_user [$time_local] "$host" "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" -> $upstream_response_time';

Что на выходе дает что-то вроде такой строки:

188.142.8.61 — - [14/Sep/2014:22:51:03 +0400] «www.mysite.ru» «GET / HTTP/1.1» 200 519 «6wwro6rq35muk.ru» «Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.191602; .NET CLR 3.5.191602; .NET CLR 3.0.191602» "-" -> 0.003

1. tail -f /var/log/nginx/nginx.access.log | cut -d ' ' -f 1 | logtop

Позволяет получить общую картину: распределение уникальных IP, с которых идут запросы, кол-во запросов с одного IP и т.д.
Самое ценное — что все это работает в режиме реального времени и можно мониторить ситуацию, внося какие-либо изменения в конфигурацию (например просто забанить ТОП 20 самых активных IP через iptables или временно ограничить географию запросов в nginx через GeoIP http://nginx.org/ru/docs/http/ngx_http_geoip_module.html).

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

Листая страницы хаба «Алгоритмы», наткнулся на топик, посвященный решению задачи локализации точки в многоугольнике: задан многоугольник (замкнутая ломаная линия без самопересечений), требуется определить — находится ли заданная точка A внутри этого многоугольника или нет. В одном из последних комментариев к топику было высказано недоумение, какое отношение такая чисто математическая задача имеет к теории алгоритмов. Имеет-имеет, причем самое непосредственное. Задача локализации является классической задачей вычислительной геометрии (не путать с компьютерной графикой). В качестве разминки предлагается взглянуть на картинку справа, на которой изображен многоугольник типа кривой Пеано (источник [1]), и попытаться ответить на вопрос — красная точка ты видишь суслика? и я не вижу, а он есть! находится внутри или снаружи многоугольника? А ниже мы (исключительно в образовательных целях) рассмотрим простую вариацию данной задачи, когда заданный многоугольник является выпуклым.

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

Раньше создавать такие карты было удобно в Adobe ImageReady, но начиная с версии CS3 эта программа больше не поставляется с Фотошопом. На сегодняшний день подобный функционал есть в Adobe Fireworks, но устанавливать эту программу только из-за редактора карт (для работы мне нужен только Фотошоп) — не очень хорошая идея. Существуют и онлайн-редакторы, которые написаны, в основном, с использованием canvas. В них отсутствует возможность редактировать созданные области на карте. Если ошиблись — придется все переделывать. Да и создавать эти области не слишком удобно. Еще одно неудобство заключается в том, что картинку приходится загружать на сервер. В общем, надо писать что-то свое.

Итак, задача:
— написать на javascript редактор, который позволит создавать карты изображений — загружаем картинку, рисуем области, получаем html-код. Если ошиблись — должна быть возможность отредактировать карту. Редактор должен работать в оффлайн-режиме. Обеспечить поддержку только современных браузеров, в том числе Internet Explorer 9.

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

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

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

Конечно, я попытаюсь рассказать обо всём по-порядку, начиная с основ. Поэтому, эта статья будет крайне полезна тем, кто только начинает или хочет разобраться с git. Более опытные читатели, возможно, найдут для себя что-то новое, укажут на ошибки или поделятся советом.

В очередной раз ковыряясь в чужом коде, понимаю насколько больная тема — стандарты кодирования в PHP…

Небольшая предыстория.

У меня есть хобби-проект трекер.ру
Алгоритм такой: пользователь вводит поисковый запрос, этот запрос «на лету» ищет торренты на сторонних трекерах (рутор, рутрекер, tfile и тд).
Для параллельного поиска идет одновременно несколько аякс запросов, которые должны обработаться асинхронно.
Однако, запросы выполнялись синхронно. Если какой-то трекер долго не отдавал ответ, то остальные запросы подвисали и ждали ответа от подвисшего трекера. Общее время выполнение запросов равнялось сумме всех запросов. Хотя, по моим планам общее время должно было равняться самому долгому запросу.
Долго ломал голову, почему так. Грешил на HTTP pipelining. Но, причина оказалась намного банальней. Все дело в сессиях. Дело в том, что сессии в php консистентны и php не даст обратиться другому процессу к уже занятой сессии.

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

В конце декабря Mail.Ru вновь (впервые с 1997 года ;) выпустила революционный продукт — облачное хранилище, первым активным пользователям которого бесплатно выдают один терабайт. 1 Тб — по меркам начала 2014-го года это совершенно эпический объем, по крайней мере в масштабе национальной отрасли ИТ. Ради справедливости можно отметить, что некоторые китайские компании дают и больше, однако практическая применимость таких предложений для большинства читателей Хабрахабра выглядит сомнительной.

Небольшим изъяном актуальной версии Облака по мнению многих моих друзей и коллег выглядит то, что Облако (по крайней мере официально) не поддерживает WebDAV. Это не позволяет «из коробки» использовать шифрование с помощью простых и популярных в народе средств вроде Boxcryptor. Поскольку сам по себе Boxcryptor — это всего лишь удобная графическая надстройка над encfs+fuse, я решил для себя и для друзей составить короткую и простую инструкцию, как эффективно шифровать данные бэкапов в Облаке.Mail.Ru

Постановка задачи

Я продвинутый фотолюбитель. Мой фотоархив насчитывает примерно 600Гб данных, причем примерно половина из них — это выполненные в высоком разрешении сканы родительских слайдов, начиная с 1957 года. Почти все хранится в NEF+CR2 (это raw-форматы Canon и Nikon), каждая фотокарточка занимает от 15 до 60 мб. Иными словами, бесплатный терабайт от Flickr меня совсем не устраивал в частности из-за невозможности хранить необработанные исходники фото. Начиная с 2008-го года, резервирование архива выглядит так: раз в году я покупаю современный жесткий диск стоимостью 100 евро и копирую на него все содержимое предыдущего диска, а старый HDD отправляется «на пенсию» в медиа-сервер, который включается 3-4 раза в год. У этого подхода много достоинств (несмотря на смертность жестких дисков, данные еще ни разу не пропадали), но есть огромный недостаток — физическое расположение хранилища.

Я много путешествую по миру, и за последние 10 лет суммарно провел в России (где находится медиа-сервер и стопка «отставных» HDD) не более 4-х лет. Иногда случаются казусы, связанные с потерей внешних винчестеров — так я потерял значительную часть архива фотографий 2012-го года, которые банально не довез до своего дома на родине. На словах решение простое — «go cloud», а вот на деле тарифы всех мало-мальски удобных сервисов, позволявших заархивировать 1Тб оригиналов фотоизображений, были долгое время прямо-таки заоблачными.

И вот 20 декабря 2013 года нам было объявлено о том, что все желающие обладатели ящика на mail.ru могут получить в подарок 1 терабайт. Бесплатно. Для любых файлов. Но только у многих возникают вопросы, как хранить свои данные в облаке в зашифрованном виде.

В 2011 году была переведена хорошая статья „Лучшие шрифты для программирования“. Теперь представляется список самых удачных шрифтов для кода на момент июня 2014 года.
Хотя я и уверен, что многих устраивает Courier New, используемый по умолчанию в Windows во многих редакторах. Но, как человек любящий типографику, настаиваю обратить внимание на одну из гарнитур из этой статьи. Хороший шрифт — это прекрасно!

Когда делаешь простые сайты на WordPress, то с вебсервером все просто, поставил себе Xampp и спокойно работаешь.

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

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

Что именно хочется:

• Поддержку нормальных url типа sitename.ru
• Не редактировать /etc/hosts
• Не редактировать конфиги nginx
• Работать в локальной папке
• Удобное администрирование конфигурации сервера
• Изолированое окружение
• Поставить и забыть

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

Поэтому я поднял дебиан на виртуальной машине (virtualbox) и настроил nginx+phpfpm за пару часов, но это не очередное хау ту по связке nginx+phpfpm, мы делаем готовое решение по типу xampp.

Как-то поиграв в оффисе в hexbug, зародилась идея написать игрушку по схожим мотивам.
По текущему роду деятельности я веб разработчик и поэтому захотелось чтобы в игре использовался только HTML, JavaScript и CSS — средства знакомые каждому вебразработчику. Никакого вам flash или даже canvas. Звучит хардкорно, но на самом деле сейчас HTML + CSS3 это очень мощные и гибкие средства визуализации, а писать игровой код на JavaScript — одно удовольствие. Вдобавок захотелось чтобы игра была с сетевым мультиплеером, притом интерактивной — никаких там шашек, карточных игр, пошаговых стратегий, все должно быть в действии и движении.

Вот что получилось в итоге:



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

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

В последние несколько лет моя работа связана с использованием CMS Drupal, но на досуге я изучал и just for fun запускал проекты на питоновских фреймворках Django, Flask и Twisted. Сейчас я решил освоить основы двух-трех популярных PHP-фреймфорков и первыми я решил изучить Zend Framework 2 и Yii.

В процессе ознакомления с Zend Framework 2 я изучил туториал с официального сайта (http://framework.zend.com/manual/2.2/en/user-guide/overview.html), просмотрел документацию фреймворка (http://framework.zend.com/manual/2.2/en/index.html), прочитал книгу Michael Romer “Web development with Zend Framework 2” и собрал собственное тестовое приложение.

Переварив всю эту информацию, я пришел к мысли, что официальный туториал к фреймворку суховат:

• в нем не рассказывается о работе с пользователями, сессиями и правами доступа,
• лишь вскользь рассматривается такая основополагающая часть фреймворка как ServiceManager,
• в качестве интерфейса с базой данных безальтернативно используется паттерн Table Gateway (и соответствующая его реализация в фреймворке),
• используется встроенный в фреймворк шаблонизатор, который после питоновского Jinja 2 кажется совершенно неудобным и примитивным,
• и т.д.

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

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

• в качестве шаблонизатора будет использоваться Twig,
• для работы с БД — Doctrine ORM,
• для авторизации/аутентификации и распределения прав доступа я буду использовать существующие модули ZfcUser и BjyAuthorize,
• также я рассмотрю вопросы разработки собственных валидаторов форм, View плагинов и другие.

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

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

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

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


Иллюстрация Стивена Резига

Мы познакомились с Владиславом Архиповым во время питерской конференции WNCONF, где он выступал с докладом. В его выступлении особое внимание уделялось важной для нас теме трактовки gambling для social casino. В ходе разговора, в котором участвовали и другие коллеги, выяснилось, что юридическим моментам в своей работе инди-девелоперы уделяют очень мало внимания, создавая необходимые документы по остаточному принципу. Мы решили восполнить этот пробел и провести вместе с практикующим юристом небольшой “ликбез”.

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

SELECT * FROM test_table ORDER BY id LIMIT 100000, 30

могут выполнятся очень долго. Например, в моем случае, на одном из сайтов кол-во комментариев перевалило за 200к и постраничная навигация по комментариям начала ощутимо тормозить, а в mysql-slow.log все чаще стали попадать запросы с временем выполнения 3-5сек.

Инструменты, которые мы будем использовать

Docker

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

Собрав контейнер один раз, его можно многократно использовать.

Простой пример — это БД Redis. Если нам необходимо несколько серверов Redis на одном компьютере, при обычном подходе нам придется изменять конфигурационные файлы в /etc/redis и менять файлы в /etc/init.d. Можно написать bash скрипт, но это не делает процесс легче.