В этом топике расскажу о том, как я из старенького цифровика и линзы из CD-ROM'а сделал инструмент для микрофотографии.

audio.js — это javascript библиотека, позволяющая использовать HTML5 тэг повсюду. Что скрывается за словом «повсюду». Если есть возможность использовать тэг , то будет использоваться он, иначе будет подключен плеер на flash. В библиотеку так же входит и UI отображение для этого плеера, которое может быть видоизменено с помощью css.

В настоящее время я работаю над одним веб-приложением, и вот захотелось мне обновить нынешний, довольно-таки топорный интерфейс на что-то более современное, более красивое. Начать решил с кнопок как с наиболее технически нагруженной части: в них требуется не только заменить внешний вид, но и добавить индикацию нажатия и обработку событий. Сразу же возникла проблема: как обеспечить масштабирование? Обычной растровой картинкой не обойтись, так как у пользователей могут использоваться разные шрифты (как вид, так и размер), и картинка-подложка не будет под них адаптирована. Логично было бы попробовать использовать для этих целей SVG, чем я и занялся.

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

Все мы тут собрались умные, образованные, красивые и опытные. И на сегодняшний день, мне кажется, почти все используют тот, или иной вид RPC между JavaScript и PHP, который работает на API из того, или иного фреймворка. Кое кто даже разрабатывает какие-то свои костыли и подпорки. Я не исключение, конечно же. Правда пошел я по пути наименьшего сопротивления и, собственно, речь в этой статье пойдет как раз об этом — об очередной реализации XML\JSON RPC для JavaScript и PHP.

Предыстория такова, что мне необходимо было разработать некую систему управления данными. Естественно, что данные хранятся в СУБД, а управлять ими надо через веб. Привязываться к фреймворкам готовым очень не хотелось, потому выбор был не велик — PHP-быдлокодинг, или MVC с рендерингом на основе готовых разработок вроде smarty. Однако, примерно в то же время, я обратил внимание на такие проекты как extJS (он же Sencha теперь) и qooxdoo, которые позволяют создавать полноценные веб-приложения минуя утомительную HTML-верстку, генерацию HTML/XML, XSLT преобразования и многие другие «страшные» вещи, характерные для MVC и PHP-быдлокода. Потому созрел следующий план действий.:

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

Fat-Free чем-то похож на известный Ruby-фреймворк Sinatra. Автор Fat-Free помешан на минимализме и чистоте кода, что положительно отразилось на этом простом каркасе для разработки самых разнообразных приложений.

Fat-Free состоит из одного файла и весит всего 55KB. При этом фреймворк обладает таким функционалом: специфический и довольно удобный шаблонизатор, гибкое кеширование, автоматическая защита от спама, интегрированные средства для юнит тестов, профайлер кода.

Он настолько маленький и быстрый, что даже может использоваться для контроля траффика Web-сервера.

Это, также, единственный фреймворк, который защищает Ваше приложение от хотлинкинга и DoS атак.

Предисловие

В этом руководстве Вы узнаете, как построить простую систему по архитектуре MVC (Model-View-Controller, Модель-Отображение-Контроллер) на PHP 5.1 с использованием возможностей библиотеки SPL (Standard PHP Library, Стандартная Библиотека PHP).

Вы любите смотреть фильмы? Я — да: «Теория большого взрыва», «The IT Crowd», разное аниме… Все это очень затягивает.
Для просмотра всего этого добра я пользуюсь консольной версией самого всеядного медиаплеера mplayer. (Давайте воздержимся от холивара по поводу красноглазия и GUI vs консоль) Но вот незадача, для каждой новой серии приходится заново набирать длинную команду вроде такой:

$ mplayer -ass -subcp cp1251 имя_сериала_01_еще_какая_то_чушь.mkv

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

Вместо введения

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

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

Хочу Вам рассказать о штуке, которую я изобрел сегодня, чтобы ускорить процесс загрузки сайтов. Все вы знаете, что <script src="..."></script> задерживает отрисовку страницы, пока не загрузится этот скрипт. Если их десятки — это может сереьезно замедлить работу сайта — в результате пользователь 20 секунд пялится на пустую (или недорисованную) страницу из-за какого-нибудь тупящего социального виджета (умножить на десяток этих виджетов).

Не правда ли было бы круто, если бы можно было сказать <script extsrc="..."></script> ("extsrc" = "грузи потом"), чтобы скрипты загружались после того как страница отрисована?

Все бы хорошо, но есть document.write… Сегодня я наконец решил его проблему — представляю extsrc.js — скрипт, который запустит все скрипты после отрисовки страницы (даже если они содержат document.write — и правильно отрисуется все).

Результат? Супер-быстрая загрузка страниц, даже если там море всяких внешних скриптов.

Использование:

Заменяем <script src="..."> на <script extsrc="...">.

Итого получается:

<script src="http://whiteposts.com/extsrc_js/extsrc.js"></script>
<script extsrc="..."></script>

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

Во-первых, глаз лучше воспринимает строки текста состоящие из 8 до 12 слов. Во-вторых, можно гораздо лучше организовать колонки и уменьшить количество пустого пространства на странице. Долгое время это являлось исключительным преимуществом полиграфии. В вебе же приходилось всячески извращаться. Но теперь CSS3 позволяет создавать колоночную верстку без использования JavaScript.

За последний месяц, я написал уже два поста с обзорами плагинов jQuery (1 и 2). Надо сказать, что подобные статьи на английском языке появляются все чаще и чаще. Однако их содержание довольно быстро приедается. Галереи картинок, слайдеры, опять галереи картинок, многочисленные динамические меню и опять слайдеры. Мне не хочется описывать очередную порцию подобных плагинов. Поэтому сегодня я расскажу не о двадцати-тридцати как обычно, а только о семи важных на мой взгляд плагинах, о которых очень хотелось рассказать. Лучше меньше, да лучше.

Прошло несколько дней с публикации анонса о появлении на свет jQuickForm (если в двух словах, то jQuickForm это сборка jQuery + HTML_QuickForm2).
Была получено масса положительных отзывов, в т.ч. в личку, много посетителей сайта проекта сказали «LikeIt», а это говорит о том, работа нужная и своевременная.
Итак, сегодня я хочу сказать о том, что на данный момент практически все явные и потайные возможности jQuickForm описаны, а это ни много, ни мало:

Элементы

InputText, InputPassword, Date (выбор даты, состоящий из нескольких элементов типа select), DatePicker (jQueryUI), Slider (jQueryUI — «ползунок»), SliderRange (jQueryUI — диапазон значений), Select, Buttons, Textarea, Page (элемент для построения многостраничного мастера), Static (элемент формы для вставки произвольного HTML), jWysiwyg (простейший редактор), Autocomplete One Array (автокомплит с единственным значением и инициализацией при помощи передачи массива), Autocomplete One Remote (то же самое, но источник — аякс-скрипт), Autocomplete Multiple Array (автокомплит с множеством значений через запятую, используется, например, для формирования списка веб2.0 меток, источник — массив), Autocomplete Multiple Remote (тоже самое с удаленным источником), File Upload (обычный элемент загрузки файлов), и, по заявкам телезрителей — File MultiUpload

В наше время существует уже немалое количество таковых, не правда ли? Они даже неплохо справляются со своей работой, если надо, к примеру, сформировать HTML за сотые доли секунды – это довольно быстро, и пользователь не чувствует этой задержки. И почему же мы все не кидаемся вовсю использовать шаблонизацию на стороне клиента? Ну вот к примеру несколько пунктов:
– генерировать страницу (бОльшую её часть) становится таки уже накладно;
– если у вас используется смешанная шаблонизация (шаблоны и на javascript, и на вашем любимом скриптовом языке), то возникнет ситуация, когда они у вас дублируются;

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

1. Верстка, аутсорсинг и технические задания

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

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

Что я понимаю под правильной обработкой:

• Универсальное решение, которое можно вставить в любой существующий код;
• Легко расширяемое решение;
• В PHP аж три «механизма ошибок»: собственно ошибки (error), исключения (exception) и утверждения (assertion). Свести три механизма к одному — exception. В комментариях к предыдущей статье на эту тему выражалось мнение, что exception это плохой и/или сложный метод обработки ошибок. Я так не считаю и готов это обсудить в комментариях;
• Опциональное логирование;
• Общий обработчик exception, который будет поддерживать разные форматы вывода и debug/production режимы;
• В debug режиме должен выводится trace. Требования к trace: компактный, понятный и по возможности ссылки на открытие файлов в IDE.

Публикую по просьбе eugenioz.

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

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

В качестве средства распределения задач предлагаю вашему вниманию PHP-класс Tasks.

Код класса

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

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

ModularGrid — это небольшая программка на javascript (около 30 КБ), которая облегчает труд HTML-верстальщика.

Основные возможности ModularGrid

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

Вчера в топике «Модификация изображений для сайта, или какие бывают превьюшки» в комментариях diGreez предложил, как мне показалось, очень интересный способ организации превьюшек изображений. Реализовал на PHP функцию, которая занимается созданием таких превьюшек.
Функция документирована комментариями.

Сколько процентов пользователей вашего сайта являются также пользователями ВКонтакте? Как по вашему, сколько человек ничего не пишут / комментируют / добавляют (нужное подчеркнуть), лишь потому, что им лень регистрироваться на еще одном непонятном сайте в 100й раз? Предлагаю ответить для себя на эти 2 вопроса, прежде, чем ругать ВКонтакте и Open API.

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

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