Несколько недель назад американский телеканал CNBC продемонстрировал фильм из своего документального цикла «Титаны», посвященный главе компании Apple Стиву Джобсу. Эти фильмы рассказывают о жизни выдающихся людей, изменивших мир. И конечно же, этот список был бы неполным, если бы в нем не было создателя Mac, iPod, iPhone, iPad и множества других полезных вещей. Русская озвучка подготовлена сайтом — AppleInsider.ru



Еще 2 части под катом.

За те 9 лет, что я занимаюсь программированием, в мою асю пришло несколько сотен просьб о помощи, от менее опытных, начинающих программистов. И вот, когда сегодня, в очередной раз, незнакомый человек попросил помочь ему написать плагин для вордпресс (код которого, честно говоря, я в глаза ни разу не видел), я решил написать небольшой гайд, который бы помог начинающим программистам правильно обращаться за советом к более опытным.

Введение

Недавно наткнулся на статью, размещенную на Хабрахабре, посвященную сравнению изображений «Выглядит похоже». Как работает перцептивный хэш. Так как я сам достаточно долго занимался этой тематикой (являюсь автором программы AntiDupl), то мне захотелось поделиться здесь своим опытом по данному вопросу. В статье я приведу два варианта алгоритма сравнения похожих изображений — базовый и улучшенный. Все они были проверены автором на практике в рамках указанного выше проекта. Изложение мое будет вестись без строгих доказательств, сложных формул и специальной математической терминологии. Надеюсь, что читатели простят меня за это.

Базовый Алгоритм

Мера схожести изображений

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

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

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

Данный обзор инструментов идет в продолжение первых двух статей (см часть 1 и часть 2)

Сейчас мы разберем такие важные вопросы как:

• Присвоение региона сайту
• Формирование особых сниппетов
• Обзор самых важных слов сайта
• Анализ мета-описаний страниц сайта
• Проблемы индексации

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

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

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

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

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

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

Если посмотреть новости, поступающие с конференции MWC, может сложиться ложное впечатление, что кроме LG, Samsung, HTC, Motorola и Sony Ericsson других производителей устройств на Android нет.

Громкие анонсы это, конечно, хорошо, но мы решили исправить эту несправедливость и отправились на поиски необычных девайсов, спрятанных среди многочисленных планшетов на Honeycomb и смартфонов на Gingerbread. И нашли:



Знакомьтесь, японский монополист сотовой связи Docomo. Как и многие другие операторы компания выпускает смарфтоны под своим брендом, но какие! В продолжении видео с еще одним необычным гаджетом, на этот раз планшетом. Хотя это определение весьма условно.

На мой взгляд, в этой версии следующие изменения являются основными:
1) Перенос строк. То что долго многие ждали.
2) Поддержка Git 1.7.x
3) Поддержка HTML5
4) Улучшено определение изменений файлов другими программами.
5) PHP рефакторинг.

Полный список новшевств.
Все фичи 7 версии
Скачать NetBeans IDE 7.0 Beta 2

С чего все началось

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

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

REST (Representational state transfer) — это архитектурный стиль или свод соглашений для web-приложений и сервисов, основанный на манипулировании ресурсами и спецификацией HTTP. Впервые об этом заговорил Рой Филдинг (Roy Fielding) — один из отцов основателей HTTP (Hypertext Transfer Protocol).

Web-приложения зачастую игнорируют спецификацию HTTP и двигаются вперёд используя полюбившиеся возможности: GET и POST, 200 OK и 404 NOT FOUND. Так как используются программируемые web-приложения, со своими собственными API, то решение игнорировать спецификацию HTTP, может создать проблемы в дальнейшем. Как следствие — имеем множество приложений с интерфейсами GET и POST. Например интерфейс удаления пользователя: GET /user/1/delete против POST /user/delete {id=1}; в случае REST можно указать /user/1 это ресурс, а удаление HTTP метод DELETE.

Добрый день, %username%!
За последний год столкнулся с несколькими задачами по написанию SOAP/REST API к различным сервисам и вывел для себя боле-менее удобную модель. Я не претендую на фундаментальное исследование, просто хочу поделиться опытом наступания на грабли.

Для начала общие требования к default API:

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

Данная статья давно назревала в моей голове, но совсем в ином формате.
Прочитав последние несколько неуклюжих статей на тему WEB-сервисов (например: http://habrahabr.ru/blogs/development/108973/) и применения в них REST технологии, решил что настало время все-таки откинуть лень, выделить время и написать «переформатированную» в своей голове статью.
Итак, кратко, что Вы найдете в статье и кому она будет полезна:

— новичкам, которые интересуются или планируют написать WEB-сервис для проекта
— профи вряд ли найдут что-то новое для себя
— общая идеология REST
— применение CRUD в WEB-сервисах
— принципы KISS при построении раутеров
— лучшие практики
— немного пиара ;)
— ссылки, литература

Недавно на Хабре была опубликована статья под провокационным заголовком и призывом к прекращению изобретений велосипедов в API-строении. Поскольку тема мне интересна, то я просто не мог пройти мимо.
Увы, реальность за хабракатом меня сильно разочаровала — я увидел очередной велосипед, да еще и с квадратными колесами. (Коллеги, ничего личного, только техническое обсуждение.) Правда, авторы честно сказали, что увидели на нескольких сайтах модное слово REST и решили сделать по нему. Только вот поняли они этот «РЭСТ» по-своему, примерно как Дед Щукарь читал и понимал толковый словарь.
В этом топике я призываю по-настоящему покончить с велосипедами в API сайтов. Ведь получается какой анекдот: АПИ разрабатывается для упрощения доступа к сайту и легкости подключения внешних систем, а получается такой, что с ним еще сложнее, чем без него :)

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

В повествовании будут рассмотрены следующие вопросы:

1. Базовые технологии: XML-RPC, REST, SOAP и краткое сравнение
2. Дао вебсервиса
3. Просветленные API
4. Как отличить сайтовое API от говна
5. Выводы

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

• отправлять методом POST любые параметры вместе с файлом;
• отправлять куки;
• предоставлять возможность выбора сразу нескольких файлов (или нескольких тысяч – тут как пользователь захочет);
• отправлять файлы группами;
• файлы собираются в группы до определенного количества мегабайт, или до определенного количества файлов в группе; (это связано с тем, что на сервере есть ограничение на размер POST запроса и на количество файлов в одном пакете)

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

Итак, что из этого получилось

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

Так получилось, что до недавнего времени все мои web-проекты реализовывались на своих собственных серверах. И по этой причине мне ни разу не приходилось иметь дела с хостингом. Но всему приходит конец и в конце 2008 года я вдруг решил, что просто обязан купить себе хостинг и пару доменов.

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

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

UPD: доступна вторая часть статьи

Однажды мне надоели жалобы клиентов, вроде «на моём сайте вирус, сделайте что-нибудь!». Объяснять людям об опасности сохранения паролей от ФТП на небезопасной машине так же надоело. Гениальное оказалось рядом — обычно поражаются файлы index.* и default.* — так почему бы не отслеживать изменение этих файлов. Сказано — сделано.
UPD: код переписан — теперь никакого SQL и PHP, тупо парсим xferlog bash'ем

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

Недавно возникла задача получения чистого текста из различных форматов документооборота — будь-то документы Microsoft Word или PDF. Задача была выполнена даже с чуть более широким списком возможных входных данных. Итак, этой статьёй я открываю список публикаций о чтении текста из следующих типов файлов: DOC, DOCX, RTF, ODT и PDF — с помощью PHP без использования сторонних утилит.

Бэкапы — это вечная проблема: то объемы данных сумасшедшие, то вообще забываешь про них. В своем предыдущем проекте dvice.ru (он пока закрыт, так что без ссылки) я допустил досадную ошибку в самом начале его запуска. Я написал небольшой крон, который в 12 часов ночи удалял всех неактивированных пользователей, зарегистрировавшихся больше 24 часов назад. Но я ошибся в запросе и потерял данные пользователей, которые зарегистрировались до первого запуска этого запроса. Слава Богу, у меня были все данные в сессиях, поэтому я восстановил всех тех, кто логинился и ставил галку на чекбоксе — запомнить меня. Обидно и глупо, но на ошибках учатся. Поэтому перед запуском своего крайнего проекта — inwhite.ru, я сделал систему бэкапов.

Бэкапы делались и копились, старые удалялись, и все было отлично. Пока внезапно я не понял, что страдаю полной фигней. Бэкапы-то я делаю, а вот забирать — не забираю. Объемы данных, лежащих на моем VPS, не такие большие, но по почте тоже особо не наотправляешься. Покупать еще один VPS и складывать туда все по FTP/SVN/CVS/SSH не особо хочется, хотя тоже вариант интересный.

До вчерашнего дня я был озадачен мыслью: а как все же забирать эти данные? И вот вечером меня осенило.