Как часто вы пишете велосипеды? Можно я тоже тут рядом пристроюсь? Но дело в том, что мой велосипед, он особенный. Казалось бы, простенький, трехколесненький, склепанный всего за один день. Но есть одна хитрость — он работает на движке от болида. Что он умеет?

А смотрите:

<?php
$class = MySingleton::getInstance();
var_dump($class instanceof MySingleton); // => (bool)true
var_dump($class instanceof DOMDocument); // => (bool)false

// а теперь немного магии
test::double('MySingleton', ['getInstance' => new DOMDocument]);

var_dump($class instanceof MySingleton); // => (bool)false
var_dump($class instanceof DOMDocument); // => (bool)true
?>

О нет, мы изменили синглтон! Мы переопределили статический метод. Как же теперь жить?
Но вопрос теперь в другом: как мы жили до этого?

Встречайте AspectMock. Самый простой, но самый мощный фреймворк для моков и стабов на PHP.
Ваш новый суперпростой помощник в тестировании. Основан на Go AOP от NightTiger.

Рано или поздно многие крупные проекты сталкиваются с проблемами производительности при постраничной навигации по записям. Некоторые из них решают эту проблему ограничением количества доступных для просмотра записей (скажем, не больше 1000). Вполне приемлемое решение. Но в этом случаем могут возникнуть проблемы с индексированием сайта сторонними поисковиками, которые и представляют наибольшую угрозу. В этой статье я хотел бы отказаться от привычной для всех панели навигации вида «1..2..3..4..» в пользу простой «вперед… назад» (будет проще объяснить), но это не проблема реализовать подобное и с первым вариантом.
Более точно определить тему, назвав, какое количество записей считать достаточно большим для появления тормозов, не получится, так как эта цифра для всех разная и сильно зависит от того, насколько быстрые у Вас жесткие диски, сколько памяти, и какая часть Ваших данных уже закеширована в ней и тд. Но если Вы и Ваши сервера ощущают, что n-ная страница при выводе даётся тяжелее первой, и при этом не знаете, что с этим делать – статья для Вас. Но для начала, я хотел бы на пальцах объяснить, почему ОНО работает медленно.

Кстати, тест происходит на виртуальной машинке, работаю я с СУБД под рутом, версия MySQL – 5.0.32.

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

Я отметил две проблемы подавляющего числа конфигов nginx'а, попадавших мне на глаза:

• «Всё в одном файле»
• Дублирование настроек

С помощью моего подхода, надеюсь, эти и многие другие проблемы будут устранены.

Хотелось бы остановиться и посмотреть на развитие языков программирования с точки зрения развития пользовательских типов данных (ПТД).
Сразу хочу оговориться, под пользователями понимаются программисты, как люди, пишущие код на этих языках. Ну, и те, кто этот код сопровождает или просто читает.

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

Пользователи желают иметь примерно такие типы данных

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

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

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

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

Просматривая одно из обучающих видео "Школы разработки интерфейсов" Яндекса, наткнулся на ссылку на офигенный труд израильской веб-программистки Тали Гарсиэль (Tali Garsiel) "How browsers work" (Как работают браузеры).

Она в течение нескольких лет отслеживала всю издаваемую информацию о внутреннем устройстве браузеров, изучала исходный код WebKit и Gecko и, в конце концов, собрала все воедино. Вот что пишет сама Тали:

Когда на 90% компьютеров был установлен IE, приходилось мириться с тем, что это загадочный «черный ящик», однако теперь, когда более половины пользователей выбирает браузеры с открытым исходным кодом, пришло время разобраться, что скрывается у них внутри, в миллионах строк программного кода на C++...

Пролистав, я был поражен — отличная работа. Внутреннее устройство браузеров, алгоритмы разбора — все хорошо иллюстрировано, доступно и понятно. И без излишних подробностей, страниц на 30-40. Как раз то, что нужно. Решил — это надо обязательно перевести. Покопался еще немного — оказалось перевод уже как 1,5 года есть!

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

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

За время своей работы верстальщиком, мне довелось иметь дело с кучей разных макетов как от новичков дизайна (или порой просто левых людей), так и до профессионалов. И за это время я успел набрать приличную выборку наиболее типичных багов в макетах, которых не в состоянии избежать даже маститые специалисты. Сразу оговорюсь — в некоторых организациях есть внутренние «требования к дизайн-макетам», и по идее, при несоответствии дизайна этим требованиям, он должен без вопросов отправляться на доработку, но реалии таковы, что зачастую проще самому внести нужные правки, чем гонять документ туда-сюда по трекеру. Но даже в этих «требованиях» упомянуты далеко не все очевидно возможные «косяки». Постараюсь привести наиболее популярные и универсальные (без личностной привязки). Да, кстати, все баги привожу под использование фотошопных psd — ну уж де-факто это стандарт в веб-макетах. Да и не попадались мне ещё макеты в векторе (и надо сказать, слава богу).

На ранних стадиях развития интернета, разработчикам приходилось использовать бедные, убогие языки программирования. Приходилось использовать только функции и операторы. Никаких объектов, никаких интерфейсов, никакого dependency injection!

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

Но теперь-то у нас есть PHP 5.3 с отличной имплементацией ООП! Представляем библиотеку SimplePHPEasyPlus! SimplePHPEasyPlus позволит вам складывать два числа современным способом, с использованием ООП. Он быстрый, простой, гибкий и оттестированный. Чтобы добавить 1 к 1, нужно всего лишь выполнить следующее:

Распространенной задачей для программиста является рисование графиков. Входными данными является массив точек (x_i;y_i). Как правило, мы знаем только некоторые значения — в определенных точках графика. Чтобы построить непрерывный график кривой необходимо прибегнуть к интерполяции или аппроксимации.



Интерполяция — построение кривой, проходящей через заданные точки.
Аппроксимация — приближение кривой к исходной, но не обязательно проходящей через заданные точки.

В этом топике я хочу продемонстрировать свою библиотеку для PHP, которая производит интерполяцию с помощью многочлена Лагранжа, C-сплайна и сплайна Акимы, а также аппроксимацию кривой Безье. Дополнительно в ней реализована отрисовка отрезка со сглаживанием (антиалиасингом).

Кратко рассмотрим методы интерполяция и аппроксимации.

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

Итак, представим себе, что есть два программиста. Один из них умный, прочёл кучу статей на Хабре, знает каталог GoF наизусть, а Фаулера — в лицо. Другой же делает всё просто. Первого будут звать, например, Борис Н., а второго — Маркус П. Само собой, имена вымышленные, и все совпадения с реальными людьми и программистами случайны.

Итак, к ним обоим приходит проектный менеджер (если в вашей вселенной PM не ходит сам к программистам, назовите его как-то иначе, например BA или lead, сути это не изменит) и говорит:
— Ребята, нам нужно, чтобы делался хлеб.

Именно так, «делался», без уточнения способа производства.

Как же поступят наши программисты?

Думаю, что не только я, но и другие пользователи Chrome под Windows, на многих сайтах замечали проблемы c отображением нестандартных шрифтов. Читать текст на таких сайтах можно, но глазам больно. Я бы так все это и продолжал терпеть, но на одном из недавних собственных проектов этот вопрос встал буквально ребром. Решил разобраться во всем досконально.

Разница в этих двух фрагментах очевидна. Первый сделан со случайно выбранного сайта adaptive-images, а второй с его локальной копии, в css которой была изменена буквально одна строчка.

(Читавшие первую версию статьи могут сразу перейти к UPD, где приведено работающее альтернативное решение проблемы для Chrome)

    Не так давно, просматривая глубокой ночью достаточно интересную заметку о игре на основе JS/Canvas (со своими ошибками и заблуждениями, которые были и у меня, что уж греха таить, понастальгировал всласть), я наткнулся на очередную порцию откровенно холиварных комментариев, после прочтения которых мир за окном стал серым и безрадостным, еда потеряла вкус, а любимый чай оказался несладким. И в тот момент то ли звезды сошлись, то ли срочных и важных багов и фич на вчера стало немного меньше, но я решил ввязаться в спор с достаточно резкими тезисами и вступиться за любимую технологию, которую так откровенно поливали непонятно чем. Так бы и осталось все это на уровне беспредметного перебрасывания пакетов с доводами через забор, если бы в ту же ветку не решил написать RussianSpy, и не об абстрактных попугаях, которых легче переписать в 3D, а о вполне конкретной задаче. И промелькнувшая фраза «Могу прислать ТЗ...» плавно намекнула на то, что вечер обещает быть интересным.

Для перемещения элемента по экрану есть два основных способа:

• CSS 2D-преобразования и translate();
• position:absolute и изменение top/left.

Крис Койер недавно писал, почему лучше и логичнее использовать translate (это быстрее, и свойство position имеет большее отношение к вёрстке, а не к визуальным эффектам и анимации, в отличие от translate).

Я хочу расширить его ответ и привести несколько хороших примеров. Я записал скринкаст, в котором помощью Chrome DevTools timline рассматриваю различия между этими подходами с точки зрения производительности, особенностей рендеринга и композитинга на GPU.



Если вам нужна сокращённая текстовая версия — продолжайте читать.

Одним из незамеченных героев вселенной HTML5 является XMLHttpRequest 2. Строго говоря XHR2 не является частью HTML5 и не является самостоятельным объектом. XHR2 это тот же XMLHttpRequest, но с некоторыми изменениями. XHR2 является неотъемлемой частью сложных веб-приложений, поэтому ему стоит уделить большее внимание.

Наш старый друг XMLHttpRequest сильно изменился, но не многие знают о его изменениях. XMLHttpRequest Level 2 включает в себя новые возможности, которые положат конец нашим безумным хакам и пляскам с бубном вокруг XMLHttpRequest: кросс-доменные запросы, процесс загрузки файлов, загрузка и отправка двоичных данных. Эти возможности позволяют AJAX уверенно работать без каких-либо хаков с новейшими технологиями HTML5: File System API, Web Audio API, и WebGL.

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

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

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

Что имеем?

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

Таблица(test) имеет следующую структуру:

• — pk_id ( первичный ключ )
• — id ( поле заполненное разными числами )
• — value ( поле заполненной с помощью rand() )

Первичный ключ не имеет дыр и начинается с 1.

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



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

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

«Цели-задачи» — это что-то вроде веб-девелоперского карго-культа: большинство студий ставит макет аэропорта из соломы («Сайт должен предоставлять посетителю всю необходимую информацию и формировать солидный имидж компании») и ждёт, когда с неба свалится ящик с консервами.

Давайте попробуем разобраться, как правильно подходить к постановке задач для сайта, в этой статье из четырёх частей:

1. Поведение потребителя в «цифровую эпоху» — чем отличается сегодняшний потребитель от вчерашнего, и как это влияет на бизнес.
2. Сайт как инструмент влияния — чем отличается сегодняшний сайт от вчерашнего, и о чём нужно помнить, решив создать новый сайт.
3. Как ставить задачи для сайта? — конкретные рекомендации для заказчиков и студий. За рецептами — пролистывайте до сюда.
4. Пример блока «Назначение сайта» — демонстрация того, что должно получиться в итоге.