Думаю, все уже знают, что современные браузеры умеют рисовать некоторые части страницы на GPU. Особенно это заметно на анимациях. Например, анимация, сделанная с помощью CSS-свойства transform выглядит гораздо приятнее и плавнее, чем анимация, сделанная через top/left. Однако на вопрос «как правильно делать анимации на GPU?» обычно отвечают что-то вроде «используй transform: translateZ(0) или will-change: transform». Эти свойства уже стали чем-то вроде zoom: 1 для IE6 (если вы понимаете, о чём я ;) для подготовки слоя для анимации на GPU или композиции (compositing), как это предпочитают называть разработчики браузеров.

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

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

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

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

• Четкая миссия – заявленная причина существования группы.
• Свободное участие – насколько легко люди могут присоединиться к группе.
• Прозрачность – насколько открыто и публично принимаются решения.
• Бесплатные участники – как много можно платить людям за участие.
• Свобода работы с материалами (ремиксабельность) – насколько свободно участники могут использовать работу друг друга.
• Четкость протокола – насколько хорошо прописаны правила.
• Компетентность власти – насколько хорошо следят за соблюдением правил.
• Нон-трайбализм – насколько далеко распространяются права группы над своими участниками.
• Самоорганизация – насколько свободно могут участники определять свои задачи.
• Толерантность – как группа разбирается с конфликтами.
• Измеримый успех – как хорошо группа может отслеживать свой прогресс.
• Высокое награждение – как группа вознаграждает своих участников.
• Децентрализация – насколько широко распределены участники группы.
• Свободная рабочая среда – насколько легко создавать новые проекты.
• Стандартная структура – насколько общая структура стабильна и предсказуема.
• Плавность обучения – насколько легко начать и продолжить учиться.
• Позитивность – насколько группа движима позитивными целями.
• Чувство юмора – насколько серьезно группа себя воспринимает.
• Минимализм – сколько лишней работы делает группа.
• Разумное финансирование – как группа борется за выживание в экономическом плане.

Спасибо Сергею Даньшину за помощь с переводом.

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

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

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

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

Оглавление

Часть 2: ядро движка

• Интегрирование
• Метки времени
• Модульная архитектура
  • Тела
  • Формы
  • Силы
  • Материалы
• Широкая фаза
  • Отсечение дубликатов контактных пар
  • Система слоёв
• Проверка пересечения полупространств

Часть 3: трение, сцена и таблица переходов

• Трение
• Сцена
• Таблица переходов коллизий

Часть 4: ориентированные твёрдые тела

• Математика вращения
• Ориентированные формы
• Распознавание коллизий
• Разрешение коллизий

Недавно я писала о том, как готовить графику для Android, какие сложности возникают во время нарезки и как сделать так, чтобы приложение на выходе полностью соответствовало дизайну. Теперь я делюсь опытом и по iOS. В e-Legion мы работаем с пакетом Adobe и для нарезки графики используем Illurstator.

Создавая визуализации или интерактивные страницы, мы часто используем комбинацию из jQuery и D3. Причём в основном используется D3, а из jQuery берут небольшой набор функций для манипуляций с DOM.

И хотя в D3 есть мощные возможности – селекторы и обёртка для ajax, часто нам не хватает каких-то функций из jQuery. Мы покажем, как можно заменить jQuery, используя D3 повсеместно. В результате ваш код упростится, объём проекта уменьшится, и вы не будете смешивать разные подходы, а будете использовать функции так, как принято в D3.

Для начала рассмотрим, в чём эти две библиотеки сходятся. Это удобно для тех, кто уже знает jQuery, и хочет изучить D3.

Схожести

Селекторы

Обе библиотеки основаны на простых в использовании, но богатых на возможности селекторах.

jQuery

$('.foo').addClass('foobar');
$('.foo').removeClass('foobar');

D3

d3.selectAll('.foo').classed('foobar', true);  
d3.selectAll('.foo').classed('foobar', false); 

Управление стилями и атрибутами

jQuery

$('.foo').attr('data-type', 'foobar');
$('.foo').css('background', '#F00');

D3

d3.selectAll('.foo').attr('data-type', 'foobar');  
d3.selectAll('.foo').style('background', '#F00');  

Недавно мы в «Я люблю ИП» закончили курсы по дизайну от trydesignlab.com. И это одна из самых важных статей, которую нам посоветовал ментор в процессе обучения. Именно поэтому мы решили её перевести. Посмотреть все наши работы с курсов можно в ВКонтакте по тэгу #design101@iloveip.

Вступление

Сначала о главном. Это руководство не для всех. Это руководство прежде всего для:

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

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

А пока давайте я расскажу, что вы найдёте в этой статье.

Недавно мы в «Я люблю ИП» закончили курсы по дизайну от trydesignlab.com. И это одна из самых важных статей, которую нам посоветовал ментор в процессе обучения. Сегодня мы публикуем вторую часть перевода. Посмотреть все наши работы с курсов можно в ВКонтакте по тэгу #design101@iloveip.

Мы говорили о правилах создания чистых и красивых интерфейсов.

Вот эти правила:

1. Свет падает сверху (Часть 1)
2. Сначала черное и белое (Часть 1)
3. Увеличьте белое пространство (Часть 1)
4. Научитесь накладывать текст на изображения
5. Научитесь выделять и утапливать текст
6. Используйте только хорошие шрифты
7. Крадите как художник

Статья даст вам краткий обзор того, как строятся интерфейсы с помощью React JS.
Вы можете параллельно писать код с помощью starter kit, или просто продолжать читать.

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

1 Один столбец вместо нескольких

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

Ранее мы уже знакомили вас с переводами статей Chris Bailey, которые он писал по мере развития своего проекта a Year of Productivity — они доступны в нашем блоге в разделе «личная продуктивность».

Сегодня мы хотели бы познакомить вас с выводами Криса о взаимосвязи между продуктивностью и счастьем.

Итак, даем слово Крису!

Как-то копаясь в выдачах гугла, я наткнулся на не столь интересную статью сайта BBC. Но меня зацепило кое-что другое.

На протяжении довольно долгого времени я и мои коллеги, участники Русскоязычной поддержки Wolfram Mathematica, занимались разработкой и коллекционированием полностью бесплатных и качественных ресурсов на русском языке, которые позволили бы любому желающему научиться программировать на языке Wolfram Language (Mathematica) самостоятельно.

Думаю, что пришла пора рассказать об этом на Хабрахабре, создав статью о разрабатываемой коллекции ресурсов, которая будет постоянно расширяться и пополняться, и будет служить, по сути, русскоязычным аналогом страницы "Where can I find examples of good Mathematica programming practice?" на сайте Mathematica at StackExchange.com.

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

Итак, в крупном производственном холдинге есть много компаний, объединённых в одну группу. В 2011 и 2012 году они показывали высокую прибыль, при которой можно забыть об оптимизации и просто фигачить как можно быстрее дальше, пока получается. «Что тут думать, трясти надо» — оптимальная бизнес-стратегия на таких нормах прибыли. В 2013-м году из-за общей экономической ситуации стало понятно, что прибыль будет снижаться. Соответственно, первое, что начало делать большое руководство — это разбираться, куда и как конкретно тратятся деньги, чтобы найти то, что можно безболезненно оптимизировать или просто убрать.

Когда начинающие оптимизаторы приступают к работе, они, как правило, увлекаются заманчивыми перспективами, предложенными A/B тестированием, и начинают экспериментировать, меняя цвета кнопок и задумываясь о том, как лучше составить тексты. Но все это по отдельности может принести улучшение результатов не более чем на 30-50% Если вы не такой гигант торговли, как «Амазон», вам придется сделать гораздо больше, чем просто поменять цвета кнопок. Что именно? Об этом — далее в переводе статьи от Smriti Chawla!

На прошлой неделе Inspector Buddy, проект робота на основе смартфона на Windows Phone созданный инди-разработчиком Робертом Ошлером, получил Гран-при конкурса разработчиков Accela Construct App Challenge 2014.



Inspector Buddy — это доступный (если не сказать дешевый) робот, который призван помочь инспекторам по недвижимости в процессе обследования жилых и нежилых помещений, обезопасив их от несчастных случаев и производственных травм. В этом посте мы поделимся некоторыми подробности о проекте, сердцем которого стала Nokia Lumia 521 (операторская версия смартфона Lumia 520).

Вводная часть

Так сложилось, что я переехал жить и работать из Москвы в Минск. Часто видел подобные материалы про аналогичные переезды в какие-то экзотические для меня или совсем далеки страны, я же хочу поделиться опытом эмиграция «к соседям».

Важно, что я буду писать именно о Минске, а не о всей Белоруссии. Написанное ниже — это лишь мое видение ситуации, возможно, где-то я не все увидел.

Если возникнут какие-то вопросы, напишите в личку или в комментарии к посту.

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

Статья затронет весь цикл разработки приложения. Вместе мы напишем простенькую игру “Крестики-Нолики” с одним экраном (в ОС Android это называется Activity).

Отсутствие опыта разработки на языке Java не должно стать препятствием в освоении Android. Так, в примерах не будут использоваться специфичные для Java конструкции (или они будет минимизированы на столько, на сколько это возможно). Если Вы пишете, например, на PHP и знакомы с основополагающими принципами в разработке ПО, эта статья будет вам наиболее полезна. В свою очередь так как, я не являюсь экспертом по разработке на Java, можно предположить, что исходный код не претендует на лейбл “лучшие практики разработки на Java”.

Настоящий поклонник операционной системы Android знает, чем действительно знаменателен июнь этого года. Да-да, сегодня, 25 июня, стартовала конференция для разработчиков I/O, устраиваемая компанией Google каждый год.



Google I/O, напомню, проводится начиная с 2008 года. По традиции, она проходит в течение двух–трех дней в выставочном комплексе «Москоун Центр» в Сан-Франциско. На ней обсуждаются технические особенности создания приложений под Android, новые функции браузера и ОС Chrome, Google API, WebToolkit, App Engine, открытые веб-технологии и многое другое. Как и Worldwide Developers Conference (WWDC), которую в июне проводит Apple, I/O служит площадкой для анонса новых продуктов и приложений о которых мы сейчас с вами и узнаем.

Привет, Хабра!
При разработке игр на JavaScript часто возникает необходимость создавать множество объектов. О том, как правильно это сделать и не утонуть в коде, я рассказывал, примерно — месяц назад на Frontend Dev Conf в Минске. Возможно, доклад будет интересен тем, кто не был на конференции и сталкивался с проблемой создания множества объектов, либо является разработчиком HTML5 игр.



Под катом текст с картинками.