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

Быстрое изменение состояния посреди анимации

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

@keyframes toggleOpacity {
  50% { opacity: 1; } /* Turn off */
  50.001% { opacity: 0.4; }

  /* Keep off state for a short period */

  52.999% { opacity: 0.4; } /* Turn back on */
  53% { opacity: 1; }
}

Вот как я использовал этот приём для имитации мигающей неоновой вывески с помощью прозрачности и свойства text-shadow:

Здравствуйте, хабражители!

Не так давно на просторах интернета появилась javascript библиотека для построения пользовательских интерфейсов от facebook — Reactjs. Данная библиотека идеально подходит для создания простых и сложных javascript приложений. Позволяет организовывать ваш клиент-сайд в виде независимых компонентов. Берет на себя всю заботу по модификации DOM структуры дерева. И делает это весьма эффективно и разумно.

В общем, в результате небольшого знакомства с reactjs появилось такое приложение — demo. Цель данного поста поделиться впечатлениями от работы с reactjs + gruntjs + browserify.

Ниже будет изложено:

• Основные моменты создания приложения и личные впечатления (симбиоз reactjs + browserify + gruntjs + coffeescript).
• Серверный пререндериг reactjs компонентов для статических страниц.
• Подход к сборке reactjs приложения с помощью gruntjs и деплой на gh-pages одной командой.

Тех кого заинтересовал прошу под кат…

Для тех, кому одного курса на праздники мало и кто хочет больше, продолжаем нашу серию курсов от Школы анализа данных Яндекса. Сегодня подошла очередь курса «Дискретный анализ и теория вероятностей» – даже более фундаментального, чем предыдущий. Но без него нельзя представить ещё большую часть современной обработки данных.

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



Читает курс Андрей Райгородский. Доктор физико-математических наук. Профессор кафедры математической статистики и случайных процессов механико-математического факультета МГУ им. М. В. Ломоносова. Заведующий кафедрой Дискретной математики ФИВТ МФТИ. Профессор и научный руководитель бакалавриата кафедры «Анализ данных» факультета инноваций и высоких технологий МФТИ. Руководитель отдела теоретических и прикладных исследований компании «Яндекс». (Ещё больше можно узнать в статье о нём на Википедии).

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

Сегодня — о самом важном. Современный анализ данных без него представить невозможно. В рамках курса рассматриваются основные задачи обучения по прецедентам: классификация, кластеризация, регрессия, понижение размерности. Изучаются методы их решения, как классические, так и новые, созданные за последние 10–15 лет. Упор делается на глубокое понимание математических основ, взаимосвязей, достоинств и ограничений рассматриваемых методов. Отдельные теоремы приводятся с доказательствами.



Читает курс лекций Константин Вячеславович Воронцов, старший научный сотрудник Вычислительного центра РАН. Заместитель директора по науке ЗАО «Форексис». Заместитель заведующего кафедрой «Интеллектуальные системы» ФУПМ МФТИ. Доцент кафедры «Математические методы прогнозирования» ВМиК МГУ. Эксперт компании «Яндекс». Доктор физико-математических наук.

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

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

Первый раз я пытался стать его пользователем году так в 2009, когда он вдруг стал «модным» и многие мои друзья перебрались туда из ВК. Но многие там не прижились. Меня, например, пугало абсолютно все: от сине-сиреневого цвета шапки до непонимания того, что произойдет при нажатии вон-на-ту-кнопку. В течение следующих нескольких лет мы молча наблюдали за усложнением интерфейса, когда весь мир стремился к простоте.

Но моя статья не о том. Я хочу представить вашему вниманию свой труд, на который меня изначально натолкнул пользователь Klimentij, написавший статью «Юзабилити Facebook». Долгое время хотел им заняться и вот, наконец, появилось свободное время.

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

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

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

Это пост для тех, кто начинает работу с Git. Все, что здесь написано по частям можно найти в многочисленных простынях о Git на Хабре. Но я подумал, что неплохо было бы иметь отдельный предельно понятный топик, который бы гуглился по запросу «git изменение коммитов».

Менеджмент, на мой взгляд, сильно похож на шахматы. Ты изучаешь методологии, ходишь на тренинги (то есть, изучаешь дебюты, принципы миттельшпиля и эндшпиля), готовишься, рисуешь план и… начинаешь игру!

Разворачиваешь свои войска: пешки двинулись вперед, кони подтягиваются, слоны занимают диагонали. И тут к тебе подходит ферзь (тим лид) и говорит “Знаешь, старик, я, наверное, буду увольняться… Чего-то совсем меня все достало.” И через две недели сходит с доски.

Нападает небольшая растерянность: а че делать? В дебютах не писали про внезапное увольнение ферзей…

Идем к начальству. Там нас ждет знакомая песня: “Сейчас бюджета нет, ты давай там как-то коней помотивируй…“ А ты понимаешь, что мотивированный конь — это не совсем ферзь. Он продолжает действовать как конь, только у него глаза начинают гореть.

Или: “Мы тебе можем нанять три пешки, ты их там поментори и через шесть ходов они вполне могут стать ферзями.” А ты понимаешь, что через 6 ходов тебя уже закопают вместе с проектом.

Нелинейные шахматы. Причем со всей этой бандой ты как менеджер должен выдавать какие-то ожидаемые результаты…

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

Можем ли мы как менеджеры повлиять на нелинейность человека, про которую так много писал Алистер Коберн в своей программной статье [1]? На что-то можем, на что-то нет. Но мы абсолютно точно можем отслеживать состояние человека, используя ряд инструментов. Об одном из них сегодня и поговорим.

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

После успешного релиза смартфона Nexus 4 компании LG и Google вновь объединили усилия и анонсировали первый смартфон на основе самой свежей версии ОС Android — Android™ 4.4, KitKat®. Получивший новые характеристики смартфон Nexus 5 является самой тонкой и быстрой моделью в линейке устройств Google Nexus на сегодняшний день.

Для жителей Соединенных Штатов Nexus 5 продается в 4 модификациях:

• Nexus 5 (16 ГБ, черный) — 349$
• Nexus 5 (32 ГБ, черный) — 399$
• Nexus 5 (16 ГБ, белый) — 349$
• Nexus 5 (32 ГБ, белый) — 399$

На данный момент аппарат можно заказать в США. Но, к сожалению, для жителей СНГ раздел Устройства недоступен в Play Маркет'е. Поэтому просто положить товар в корзину, ввести адрес и оплатить — не получится. Но не будем отчаиваться и попытаемся обойти этот запрет. В статье я постараюсь максимально подробно рассказать о процедуре покупки и различных тонкостях. Начнём!

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

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

Недавно я увидел изящный JS сниппет в этом твите.

var bind = Function.prototype.call.bind(Function.prototype.bind); // #fp

Взглянув на него, я смог догадаться, что он делает. Он превращает x.y(z) в y(x, z). Радуясь как ребенок, я показал его своим коллегам. Они спросили меня, что же тут происходит. Я открыл рот, чтобы объяснить и… не смог сказать ни слова. Я развернулся и ушел.

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

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

Agile движение имеет свой взгляд на спецификации. Наиболее экстремальное крыло выражает свои взгляды так:

В жопу спецификации!

На днях в iTunes появилось новое шоу от создателей Метрики – UXtra. UXtra – англоязычный подкаст о пользовательских впечатлениях и интерфейсах, сервис-дизайне и бизнесе, созданный при участии компании UIDG и альянса юзабилити компаний UXalliance (мировой лидер в области изучения пользовательских впечатлений и интерфейсов). Специально для аудитории Хабра создатели подкаста подготовили его транскрипт на русском языке.

Эта статья рассказывает о времени выполнения и о расходе памяти большинства алгоритмов используемых в информатике. В прошлом, когда я готовился к прохождению собеседования я потратил много времени исследуя интернет для поиска информации о лучшем, среднем и худшем случае работы алгоритмов поиска и сортировки, чтобы заданный вопрос на собеседовании не поставил меня в тупик. За последние несколько лет я проходил интервью в нескольких стартапах из Силиконовой долины, а также в некоторых крупных компаниях таких как Yahoo, eBay, LinkedIn и Google и каждый раз, когда я готовился к интервью, я подумал: «Почему никто не создал хорошую шпаргалку по асимптотической сложности алгоритмов? ». Чтобы сохранить ваше время я создал такую шпаргалку. Наслаждайтесь!

Добрый день уважаемые, хабрачеловеки.
В данной статье я хочу поделиться с вами своим опытом работы с такими фреймворками как AngularJS и Knockout.
Cтатья будет интересна тем, кто хорошо знаком с JavaScript-ом и имеет представление хотя бы об одном из упомянутых фреймворков и естественно желает расширить свой кругозор.

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

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

Привлечение клиентов

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

Так уж получилось, что даже на Хабре многие имеют очень смутное представление о семействе OS Linux.

Цель данной статьи – максимально популярным языком рассказать про особенности и отличия Linux от Windows для тех, кто вообще не имел с ним дела.

Я уже не один год свободно пользуюсь Archlinux, загружая винду лишь «на поиграться». Данная статья рассказывает о вещах, которые я выяснил эмпирическим путем, тыкаясь словно слепой котенок. Если бы в свое время мне попалась бы именно такая информация именно в такой форме — это сэкономило бы мне как минимум 2 года, в течение которых я переходил с Windows на Linux.

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


Элементарно. Так что теперь усложним задание — пусть наше значение имеет контекст. Пока что вы можете думать о контексте просто как о ящике, куда можно положить значение:


Теперь, когда вы примените функцию к этому значению, результаты вы будете получать разные — в зависимости от контекста. Это основная идея, на которой базируются функторы, аппликативные функторы, монады, стрелки и т.п. Тип данных Maybe определяет два связанных контекста:

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

В Ангуляре, дочерняя область видимости обычно прототипически наследуется от родительской. Единственным исключением является директива, в которой используется scope: { ... }, создающая «изолированную» область видимости, не наследуемую прототипически. Такая конструкция часто используется при создании директив для компонентов «многоразового использования»

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