Это перевод статьи, написанной Jon Hobbs-Smith. Я счел ее довольно интересной и решил выложить в своем блоге, а также поделиться им с хабрапользователями, также как и я заинтересованными в библиотеке jQuery. Перед тем как начать хочу отметить, что написана она (как и переведена) далеко не экспертом в jQuery, поэтому если вы найдете в ней ошибку, пожалуйста, сообщите. Итак, начнем.

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



Заинтересованная аудитория: авторы HTML-контента, разработчики скриптов серверных приложений (PHP, JSP и т.д.), менеджеры веб-проектов и любые другие люди, так или иначе связанные с дизайном форм ввода данных, дизайна баз данных и онтологий, которые затрагивают личные имена людей.

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

Помню, как в 2000 году была мода недоуменно спрашивать, почему у нас до сих пор нет городов на луне, летающих автомобилей и армии человекоподобных роботов. Прошло десять лет и вопрос зашел глубже – куда исчезла наука? Почему в ней больше не появляется громких имен? Где новые Эйнштеин, Резерфорд, Нильс Бор и Макс Планк? Если их нет, то откуда берутся все новинки техники?

Мы в Runa Capital финансируем технологические стартапы и не понаслышке знаем, в чем тут дело. Чем дальше мы продвигаемся в исследовании технологий, тем больше усилий необходимо. Это все равно, что тащить тележку в гору с постоянно нарастающим углом подъема – внизу справится и один человек, но ближе к вершине придется работать нескольким командам специалистов, да еще и посменно – одни будут тащить тележку, вторые прокладывать рельсы, третьи конструировать тормозную систему, четвертые разрабатывать лучший маршрут и т.д.


Альберт Эйнштеин в США. Калифорния, Санта-Барбара, 18 февраля 1933.

Однажды поиски движка для интернет магазина завели меня на рессурс www.practicalecommerce.com
Где я прочел такую фразу: — Есть больше чем 350 движков онлайн-шоппинга. И каждую неделю мы обсуждаем один, беря интервью и у разработчика движка и у клиента…

Неужели так много? Подумал я. Да, на некоторых российских рессурсах зарегистрировано более 540 CMS. Но не все из них магазины, а большинство это самописные движки студий. А если брать только коробочные, то наберется всего около 30. Так где же сотни? И, что самое важное, не пропустил ли я самый лучший движок? Который где-то лежит, и ждет именно меня. И я решил найти эти самые сотни.
Достиг ли я своей цели, читайте дальше…

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

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

Ну и собственно почему-бы им не поделиться со всеми?

Web Symbols

В последнее время мне везет натыкаться на интересные статьи для перевода. На этот раз – статья на HTML5Rocks о производительности HTML5 canvas. Автор пишет о некоей стене, в которую упираются разработчики при создании приложений. Какое-то время назад в нее уперся и я при портировании старой-доброй игры на canvas.

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

1. Вступление
2. Тестирование производительности
3. Предварительно отрисовывайте в виртуальный canvas
4. Группируйте вызовы
5. Избегайте ненужных изменений состояния
6. Отрисовывайте только разницу, а не весь холст
7. Используйте многослойных canvas для сложных сцен
8. Избегайте shadowBlur
9. Различные способы очистить экран
10. Избегайте нецелых координат
11. Оптимизируйте анимации с помощью 'requestAnimationFrame'
12. Большинство мобильных реализаций canvas – медленные
13. Заключение
14. Ссылки

Вступление

HTML5 canvas, который начинался, как эксперимент компании Apple, – наиболее широко распространенный стандарт для 2D режима непосредственной графики в интернет. Многие разработчики использую его в широком круге мультимедиа проектов, визуализаций и игр. Как бы то ни было, с ростом сложности приложений, разработчики нечаянно натыкаются на стену производительности.

Некоторое время назад мне довелось организовывать новую группу разработки, которая должна была заняться развитием OLAP и BI продуктов в дружеской софтверной компании. А так как группа была собрана из свежих выпускников ВУЗов, то мне пришлось написать «краткий курс молодого бойца» для того чтобы максимально доступно дать начальные понятия об OLAP людям, которые ни разу с ним не сталкивались, но уже имели опыт программирования и работы с БД.

Выкладываю теперь это Введение в Общественное Достояние.

В статье несколько смешиваются понятия OLAP, Business Intelligence, и Data Warehouse, но и в жизни часто сложно понять, где проходит граница. А уж в реальных проектах, так и подавно, все они ходят рядом. Поэтому прошу не судить строго.

Wacom Javascript API позволяет приложению получить разные интересные параметры текущего состояния планшета. Например, силу нажатия или координаты ручки относительно планшета. А так же статические данные, такие как версия плагина или модель планшета.

В данном Хабратопике я покажу, как работает данный API, на примере HTML5 Canvas «рисовалки».

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

Квадрат

#square {
	width: 100px;
	height: 100px;
	background: red;
}

Для любого программного приложения, предназначенного для массового обслуживания пользователей, необходимо проводить нагрузочное тестирование на предмет его надежности и отказоустойчивости. А так как любой web-сайт — это по своей сути система массового обслуживания, то проверка его на отказоустойчивость всегда является неотъемлемой частью разработки. Существуют различные решения для проведения нагрузочного тестирования веб-приложений. Я не буду сейчас описывать их подробно, про некоторые из них есть упоминания здесь.

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

Для тех кто ни разу не использовал JMeter, рекомендую для начала почитать базовые обзоры, например, Простой нагрузочный тест с Apache JMeter. Когда я первый раз запустил данную программу, первая мысль была разобраться во всем методом «тыка», но как выяснилось это вообще нереально, и метод «тыка» неприменим к JMeter. Поэтому если хотите его использовать, то сразу открывайте мануал, поверьте, вам придется заглядывать туда очень часто, пока полностью не разберетесь, что и как. Я же здесь сейчас опишу самое очевидное и важное, а именно: как собственно создавать нагрузочные тесты. Если бы я в свое время сразу нашел подобную статью, то сэкономил бы без малого день на изучении этой софтины.

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

Есть задачи, которые в рамках реляционных СУБД не имеют универсальных решений и для того чтобы получить хоть какой-то приемлемый результат, приходится придумывать целый набор костылей, который ты потом гордо называешь “Архитектура”. Не так давно мне как раз встретилась именно такая.

Предположим, имеется некоторые сущности А и Б, связанные между собой по принципу One-to-Many. Количество экземпляров данных сущностей достаточно велико. При отображении сущностей для пользователя необходимо применить ряд независимых критериев, как для сущности А так и для сущности Б. Причем результатом применения критериев являются множества достаточно большой мощности — порядка нескольких миллионов записей. Критерии фильтрации и принцип сортировки задается пользователем. Как (я бы ещё спросил: Зачем им миллионы записей на одном экране? — но говорят надо) показать все это пользователю за время 0 секунд?
Решать такие задачи всегда интересно, но их решение сильно зависит от СУБД, под управлением которой крутится твоя база данных. Если у тебя в рукаве козырной туз в виде Oracle, то есть шанс, что эти костыли он подставит сам. Но спустимся на землю — у нас есть только MySQL, так что придется почитать теорию.

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Распределенные системы контроля версий (DVCS) постепенно замещают собой централизованные. Если вы еще не используете одну из них — самое время попробовать.

В статье я постараюсь показать, как можно быстро начать экспериментировать с git, используя сайт github.com.

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

А давайте сегодня взглянем на PHP немного с другой точки зрения, и напишем к нему расширение. Так как на эту тему уже были публикации на Хабре (здесь и здесь), то не будем углубляться в причины того, для чего это может оказаться полезным и для чего может быть использовано на практике. Эта статья расскажет, как собирать простые расширения под Windows с использованием Visual C++ и под Debian с использованием GCC. Также я постараюсь немного осветить работу с PHP-массивами внутри расширений и провести сравнение производительности алгоритма, написанного на native PHP и использующего код, написанный на C.

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

Помнится, кстати, что в комментариях к статьям о проектировании мне задавали такие вопросы вроде «А что делать, когда нет времени и денег на проектирование?». Ответ ниже.

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

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

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

По мотивам топика Chosen: сделай выпадающие списки более дружественными.

Довольно симпатичный виджет, иногда даже может быть полезен (допустим когда есть определенные требования к дизайну). Но в данный момент виджет не позволят добавлять позиции динамически, что возмутило товарища alexsrdk, да и меня тоже :) Сейчас попробуем это дело исправить.

Плагин Chosen создан для оформления красивых и удобных выпадающих списков с помощью jQuery и Prototype. Для установки плагина достаточно просто скачать файлы и прописать одну строчку:

$(".chzn-select").chosen()

(версия для jQuery)

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

Поскольку Chosen заменяет стандартный элемент HTML, то не нужно беспокоиться, как он работает с браузерами без поддержки JavaScript. Также не нужно ничего менять в бэкенде: формы сабмиттятся как обычно, изменения только в пользовательском интерфейсе.

Некоторые форки:
Chosen для MooTools
Модуль Chosen для Drupal 7

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