Здравствуйте, уважаемые хабравчане!
В процессе разработки приложения под Android, которое предполагает взаимодействие пользователя с графическими примитивами (точками, линиями, эллипсами, прямоугольниками и т.д.), возникла довольно неприятная ситуация: пользователь может задать произвольный многоугольник и сделать его неактивным, однако чтобы в будущем была возможность активировать данный многоугольник и продолжить с ним работь (например, переместить в другое место или добавить/удалить вершины) необходимо для неактивного объекта определить, коснулся ли пользователь данного объекта, т.е. потребовалось решить вопрос о принадлежности точки многоугольнику.

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

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

Предыдущая часть тут

Анимация скрытых объектов

Похоже, одной из серьезных проблем для модуля CSS3 Animations станут объекты, которые имеют display: none и visibility: hidden.

Рабочая группа CSS3 постоянно ведет дискуссии по поводу того, что же будет в новом стандарте. Никаких скандалов, интриг и расследований. Голые мысли, непрекрытые идеи, обнаженные факты.

Предыдущая часть тут

Немного магии в линейных градиентах

Предложен новый способ рисования линейных градиентов. Как известно, такие заливки рисуются по линии градиента (gradient-line), отправной точкой которого является центр контейнера. Однако, если захочется нарисовать градиент похитрее, без дополнительных костылей в виде JS не обойтись. Например, есть градиент с тремя цветами: А, Б, В. Захотелось заполнить контейнер так, чтобы цвет А был «привязан» к левому верхнему углу, цвет Б — к правому верхнему, а цвет В — к правому нижнему. И при изменении размеров контейнера результат всегда был одинаковым.

Какая-то здравая мысль в этом есть, но «лепить» сверху на текущее поведение линейных градиентов как-то немного неправильно.

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

Советы довольно очевидные (хотя, как показывает практика, бывают и те, кто не знает этих очевидных вещей) и субъективные.

Если вы читаете эти строки, то будет вполне естественно предположить, что вы проводите за компьютером по крайней мере несколько часов в день, а то и больше. Такой режим работы привносит с собой достаточно сильную нагрузку на наши руки, которая может вызвать боли в кистях, запястьях и пальцах. Такие боли вызваны так называемым «туннельным синдромом» (синдромом карпального канала, кистевым туннельный синдром, carpal tunnel syndrome) — хроническим заболеванием.

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

Как развивается туннельный синдром и что мы при этом чувствуем

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

Тестирование скорости выполнения JS или отображения страниц — занятие неблагодарное. Любое тестирование отражает действительность только тогда, когда оно выполнено в как можно более одинаковых условиях и тестируются идентичные по функциональности вещи. Ведь на вопрос, что быстрее, грузовик или спорткар, каждый тут же ответит, что спорткар. А если по полю да с прицепом навоза? Победитель в каждом случае будет тот, кто лучше всего приспособлен для выполнения специфических задач.

В этой статье будет немного гипотез и немного фактов. Не будет фанатских речей и призывов сменить браузерную ориентацию.

Итак, наши подопытные кролики:

• FF 4b7
• Opera 10.63
• Chrome 7

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

The Little Redis Book — это бесплатная книга про Redis.

Книга была написана Karl Seguin, при поддержке Perry Neal. Karl Seguin является также автором книги The Little MongoDB Book, которую часто рекомендуют для быстрого старта с MongoDB. Первая версия повилась около недели назад.

Сегодня я сделал первую версию перевода этой книги. Исходные тексты доступны в репозитории на GitHub. Там же можно найти и готовый PDF.

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

Я благодарен следующим людям за помощь в переводе оригинального текста и вычитке результата:

• Dmitry Scriptin
• Денис Веселов
• polinom

Я прошу все неточности и опечатки отправлять для коррекции перевода.

Сама по себе инструкция о том, где что подкрутить на сервере, чтобы Drupal стал работать быстрее, встречаются на просторах интернета в разной степени детализации. Однако все встречавшиеся мне статьи обладали небольшим изъяном: я не встречал каких-либо реальных замеров, сопутствовавших настройке. Как численно меняется скорость генерации страницы? Как меняется использование памяти? Что происходит при увеличении количества параллельных запросов? Давайте проведём эксперимент. Некоторые рекомендации, изложенные в статье, носят общий характер и могут быть полезны для других CMS.

В настоящее время jQuery является де-факто библиотекой для работы с DOM. Она может использоваться вместе с популярными MV* фрэймворками (такими как Backbone), имеет множество плагинов и очень большое сообщество. С другой стороны JavaScript становится все популярнее и многие разработчики начинают интересоваться как работают стандартные API и когда можно просто их использовать, не добавляя дополнительную библиотеку.

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

Давайте создадим интерактивную карту. Чего-нибудь. Что значит интерактивную? Ну, она должна взаимодействовать с пользователем и с данными на веб-странице, на которой она расположена. Думаю, этого достаточно, чтобы считать её интерактивной.

Что же, и возьмём мы SVG. Почему? Да потому что с ним легко работать человеку, знакомому с HTML. SVG — это векторный формат, основанный на XML. То есть у SVG-рисунка есть своя DOM, к различным элементам можно применять CSS-правила и управлять старым добрым JavaScript'ом.

Что же, начнём?

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

Ставим задачу

Кого ищем? Ищем эффективных бойцов. Известно, что эффективность программистов со схожим опытом может отличаться в 10 раз (Ф. Брукс) или даже в 27 раз (Р. Гласс). Сразу, оговорюсь, эффективность это не только количество трупов врагов реализованных требований к ПО на единицу трудозатрат, но и умение результативно взаимодействовать с окружающими. Это важно, потому что по моим наблюдениям 50% проектных человеко-часов тратится на коммуникации. У нас это называется «синхронизация ментальных моделей».

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


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

Animate.css

На днях наткнулся на эту замечательную вещь и решил поделиться с Хабрахабром.
Animate.css — сборка отличных кроссбраузерных CSS3 анимаций в одном файле.

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

Основы

Мы начнём с несложного обзора модульного подхода, хорошо известного с тех пор, как Эрик Миралья (Eric Miraglia) из YUI впервые об этом написал. Если вам уже знаком модульный подход, переходите сразу к «Продвинутым техникам».

Анонимные замыкания

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

Сразу стоит предупредить, что Drupal это не готовое решение. После установки вы не получите настроенную и работающую социальную сеть, интернет магазин и т.д. В Drupal действует принцип «предоставление возможностей по мере необходимости». Именно поэтому на Drupal не делают сателиты и ГС в промышленном масштабе и, возможно, именно поэтому количество рабочих сайтов на Drupal уступает таким CMS как Joomla и Wordpress, любимым CMS строителей сателитов и ГС.

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

Думаю, не мне одному чрезвычайно надоели ресурсы, требующие регистрации по каждому поводу и без. С обязательной капчей, которая правильно введется только с пятого раза, с подтверждением по е-мейлу, которое обязательно свалится в спам и то — только через сутки. Придумывать каждый раз новую пару логин-пароль — забудется, вводить одно и то же на всех сайтах — небезопасно. Местами прокатывают пары вида «qwerty:qwerty» или «login:password», но, увы, далеко не везде. Надоело. Не счесть, сколько раз я, увидев надпись «только зарегистрированный пользователь может ****», просто кривился и закрывал вкладку, чтобы больше ни разу на этот сайт не заходить. Неужели администраторы ресурсов сами этого не понимают?

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

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

Часто можно услышать от многих веб-дизайнеров слова «Я уже не могу дождаться, когда же можно будет использовать CSS3...». А между тем, использовать его можно уже сегодня. Да, использование CSS3 для критичных моментов сайта сейчас невозможно. Но использовать его для добавления мелких, некритичных для проекта деталей вполне реально, можно и нужно.

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

Я рад приветствовать вас, дорогие читатели.

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

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

Однажды вечером, сразу после того, как я закончил разбираться с наследованием в JS, мне пришла в голову идея, что пора бы заняться чем-нибудь посложнее — например паттернами. На столе внезапно оказалась книжка Gof, а на экране ноутбука появился труд с названием «JavaScript patterns».

В общем, спустя пару вечеров, у меня появились описания и реализации на JavaScriptе самых основных паттернов — Decorator, Observer, Factory, Mediator, Memoization (не совсем паттерн, а скорее техника, но мне кажется что она прекрасно в этот ряд вписывается) и Singleton.

В оригинале название звучит как «How Not To Sort By Average Rating». Я подумал, что дословный перевод «Как не сортировать по усреднённому рейтингу» будет малопонятен и хуже отражает содержание статьи.

Постановка проблемы

Вы занимаетесь веб программированием. У вас есть пользователи, которые оценивают контент на вашем сайте. Вы хотите разместить высоко оцененный контент наверху, а низко оцененный — внизу. Для этого на основе пользовательских оценок вам нужно вычислить некий «рейтинг».

Неправильное решение №1

Рейтинг= (Число положительных оценок) - (Число отрицательных оценок)