Facebook и Bocoup выпустили набор тестов для мобильных браузеров Ringmark (исходный код обещают открыть и пожертвовать W3C в течение ближайших недель).



Ringmark проводит быстрый тест браузера на поддержку различных спецификаций и выдаёт подробный отчёт. Наборы спецификаций объединены в кольца (rings), где каждое следующее кольцо означает более сложный уровень. Следующий уровень тестов не начинается, если предыдущее кольцо не заполнено на 100%. В первом кольце 83 теста, во втором — более 300.

Со временем разработчики планируют сделать больше колец, вдобавок к нынешним трём.

Продолжаем цикл статей посвящённый алгебре исчисления процессов. Данный текст является переводом и сокращённым пересказом начальных глав книги Чарльза Э. Хоара. Теория применяется для формального описания работы параллельных систем. Примерам её практических применений являются такие языки программирования как Erlang, Go и Limbo.

• Часть 1
• Часть 2

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

Пару лет назад я сильно заинтересовался UX и всем, что с ним связано. Постепенно пришло понимание, насколько важна визуализация информации, особенно сейчас. Прочитав Тафти, Кливеленда и Бертена, просто невозможно не думать в этом направлении. Постоянно приходят в голову идеи, как сделать вещи (в частности, в нашем продукте) более визуальными, более понятными.

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

И, как обычно, прощу прощения за объем статьи. Но, надеюсь, вам будет интересно дочитать до конца.

Предыдущие статьи про иконки породили множество вопросов о технике рисования таких, по сути, мини иллюстраций. Постараюсь раскрыть эту немудреную тайну:)
Подробного описания, что и куда нажать не привожу, это бы потребовало написания целой серии уроков, а хочу поделиться общим принципом.

В качестве примера взял иконку из текущего проекта.
Сервис Rizzoma — это система коллаборации, альтернатива Google-wave.
В ходе работы над сайтом родилась идея сделать красивые иконки для каждого блока с преимуществами сервиса. Улитка символизирует контекстные сообщения и по сути своей является продвинутым символом @

Довольно качественная эмуляция игры на HTML + CSS + JavaScript, для рисования используются именно html блоки, а не canvas.

Представьте, что на дворе сейчас 1982 год и вы играете в аркаду. Это было любимое времяпрепровождение у подростков того времени. Ваша задача — уничтожить все, что можно :) Для управления используйте стрелки, для стрельбы — shift или ctrl, для мин — пробел. Цель игры — уничтожить базу, при этом не попасться противникам и не убиться об стенки.

Игра Survivor изначально была написана для Atari 2600 в 1982 году и была портирована на Commodore 64 годом позднее. Данную браузерную версию написал Скотт Шиллер в дань уважения к Commodore 64 и для очередной демонстрации как HTML + CSS + JavaScript могут быть использованы для эмуляции игр и компьютеров, на которых работали более 30 лет назад.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

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

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Три года назад на Хабре была опубликована статья «Form Spam Bot Blocker: Защищаем Web-формы без CAPTCHA!», рассказывающая о принципиально отличном от CAPTCHA решении для PHP по защите форм от спам-ботов. Это решение основано на идеях, изложенных в своих статьях Филом Хааком (Phil Haack) — Honeypot Captcha и Недом Батчелдером (Ned Batchelder) — Stopping spambots with hashes and honeypots. К сожалению, предложенный в статье класс, написан для PHP4 и не развивается с 2007-го года. Хочу предложить вашему вниманию его аналог на PHP5.

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

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

Начнем с XML файла. Структура не сложная. Каждый элемент состоит из идентификатора, идентификатора родительского элемента, ссылки и названия.

У многих людей, как-либо связанных с безопасностью, периодически возникает желание заняться pentest'ом, то есть тестом на проникновение. И чаще всего начинают все с pentest'а веб-приложений. Порог вхождения довольно мал (простейшая sqli определяется добавлением кавычки в параметр и эксплуатируется не особо сложнее), но при этом встречаются и довольно сложные задания, которые заставляют потратить пару-тройку дней на ковыряние.
Но возникает вопрос — где применять теоретические знания, без страха внезапного появления маски-шоу? Под катом проведу небольшой обзор полигонов для экспериментов по pentest'у.

По умолчанию в Google Analytics отслеживать взаимодействие посетителей с контентом сайта довольно просто. Используя стандартный код отслеживания, вы сможете получать различную информацию такую как: время проведённое посетителем на странице (time on site), показатель отказов (bounce rate) и количество просмотров (pageviews).

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

Мы хотим получать более детальную информацию по каждому сообщению или статье. Читают ли люди комментарии или только сообщение, статью? Открывают ли они во вкладках несколько сообщений?
Каким способом лучше получать детальную информацию о том как посетители сайта взаимодействуют с каждой страницей?

Эта статья о том, как измерить степень взаимодействия с контентом при помощи кастомизированного кода отслеживания Google Analytics (далее GA).

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…

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

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

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

Пусть нам задан массив A[i], на который поступают запросы вида:

• посчитать сумму на отрезке [L; R] (позже, мы поймем, что аналогично можно вычислять функции min, max, gcd и др.
• добавить к элементу A[i], delta

Наивная реализация

Мы можем предрасчитать массив частичных сумм, а именно:

 for(int j = 0; j < i; j++) B[j] += A[i];

и тогда на запрос суммы [L; R], мы будем возвращать B[R]-B[L-1] за . Однако на запрос изменения, потребует пересчета частичных сумм (содержащих этот элемент) и в худшем случае составит асимптотику порядка , что не есть хорошо.

Набравшись храбрости для своего первого поста на Хабре я хочу представить бету дизайнерского стартапа — сайт DesignTree.ru. По концепции это дизайнерские микроблоги, в которых контентом выступают авторские дизайнерские работы, ограниченные размером в 300х400px — всего 120 000px или 120k. Большинство материалов сайта это логотипы, фирменный стиль и шрифтовые решения, размещаемые самими авторами.

Предисловие переводчика

Данная статья является вольным переводом-пересказом поста The End of Autoloading
. Оригинальная статья не первой свежести, поэтому код приведенный в примерах может быть не актуален. В теме, которую затрагивает статья, самое главное — общий взгляд, а не конкретные примеры.

Предисловие

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

11-12 мая этого года в Москве пройдет третья конференция профессиональных программистов Application Developer Days (ADD).

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

В соответствии с календарем релизов осталось всего несколько недель до заморозки списка фич следующего релиза git (1.7.10), в который войдет улучшение работы git merge, нарушающее обратную совместимость и ставящее «под удар» тех, кто использует merge в своих скриптах.
Мы решили последовать совету Джейка Эджа (Jake Edge): «Большинство свободных проектов обсуждают планируемые изменения до их реализации и дают пользователям возможности протестировать новые фичи задолго до релиза. Лучшая помощь проекту на этом этапе — четко обоснованные, конкретные описания существующих проблем, отсутствующей функциональности и т.д., а не бесконечный поток сообщений „Project XYZ ОТСТОЙ!!!11“ в списках рассылки или комментариях»

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

Существует замечательное и буквально завораживающее семейство фрактальных кривых — кривые дракона. Кто не знаком с ними принцип их построения проще всего объяснить при помощи полоски бумаги. Итак, возьмём полоску бумаги и сложим её несколько раз пополам, а затем развернем так чтобы между углами сгиба образовались прямые углы. В итоге мы получим кривую дракона. Поскольку толщина сложенной полоски каждый раз удваивается, а длина отдельного звена уменьшается в два раза, то мы не можем получить таким наивным способом длинных кривых.
К счастью длинные кривые легко рисуются другим способом, а точнее множеством способов. В частности, в Сети можно встретить рекурсивную программу порождающую кривую дракона достраивая катеты к отрезкам исходной кривой, как гипотенузам. Но я решил поручить это дело черепашке. Поскольку кривая дракона состоит из серии поворотов «налево» и «направо», то черепашка должна уметь только делать шаг в перёд и поворачивать. Главное, что я хотел увидеть — это сплетение кривых дракона. Да! Эти кривые сочетаются между собой в разных и интересных позициях, что кажется невероятным для таких сложных и запутанных кривых.

В 2006 году между Департаментом Национальной безопасности США и частной компанией Coverity, производящей решение для автоматизированного тестирования качества кода, был заключён договор об крупнейшем аудите исходного кода открытого и проприетарного программного обеспечения. Несколько дней назад отчёт компании был опубликован и его выводы кратко приведены ниже:

• Было проверено 37 млн строк программного кода сорока пяти наиболее активных Open Source-проектов, причём средний размер тестируемых проектов составлял 832 000 строк. Был рассчитан показатель "Средняя плотность дефектов" как число ошибок на тысячу строк кода, который составил в среднем 0.45.
• Было проверено 300 миллионов строк проприетарного кода, произведённого сорока одной анонимной компанией. Средний размер проекта — 7.5 млн строк кода, средняя плотность дефектов составила 0.64.