Как с помощью консоли разработчика превратить Google Chrome в подобие текстового редактора? Какой смысл в ней приобретает знакомый многим по jQuery значок $? Как вывести в консоль набор значений, оформленный в виде вполне приличной таблицы? Если сходу ответы на эти вопросы в голову не приходят, значит вкладка Console из инструментов разработчика Chrome ещё не раскрылась перед вами во всей красе.

На первый взгляд, перед нами – вполне обычная JavaScript-консоль, которая годится только на то, чтобы выводить в неё логи ответов серверов или значения переменных. Я, кстати, так ей и пользовался, когда только начал программировать. Однако, со временем набрался опыта, подучился, и неожиданно для себя обнаружил, что консоль Chrome умеет много такого, о чём я и не догадывался. Хочу об этом сегодня рассказать. Да, если вы читаете сейчас не на мобильнике, можете тут же всё это и попробовать.

Введение

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

На компьютере был открыт текстовой файл со списком статей и библиотек про веб-разработку. Он постоянно пополнялся новыми данными.

Свернув его, я пошел на улицу в поисках кинотеатра с Deadpool'ом запустил браузер и стал блуждать по окрестностям интернета. Во время прогулки я наткнулся на интересную js-библиотеку по созданию css-анимации, которую добавил в открытый до этого текстовой документ… Как оказалось, по этой теме у меня уже набралось больше 40 ссылок на материалы и библиотеки.

Рисунок используемый для parallax эффекта. Автор Patryk Zabielski

Привет друзья, я покажу вам как создать простою многослойную иллюстрацию с глубиной, которая переходит к контенту. Мы будем использовать метод, в котором необходим только css и чистый JS(coffeescript) (Никаких jQuery!).

Этот урок для начинающих, с начальным знанием JS и CSS, так что я буду объяснять большинство вещей и ссылаться на внешние источники.

→ Финальное демо

Примечание переводчика: визит под кат этого поста означает большие объёмы потреблённого трафика. И это иронично, если учесть поднятую тему. Но всё сразу встаёт на свои места, если помнить, что в оригинале это было выступление в прошлом ноябре в Сиднее длиной почти в час. Чтение поста занимает куда меньше времени. В форме видеозаписи (1280×720) речь занимает два гигабайта. Пост же занимает всего лишь 12 МиБ. Рекомендуется просмотр на широких мониторах.



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

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

Что не так с тестированием вёрстки

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

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

Друзья мои! Время от времени каждый из нас сталкивается с ситуацией, когда, попав на новый для себя сайт, приходится хорошенько поразмыслить минуту-другую, чтобы понять, как там все устроено. Примерно в таком же положении можно оказаться, обнаружив радикальные (или не очень) перемены во внешнем облике любимых сайтов, будь то last.fm или Кинопоиск. Существуют разные способы примирить пользователей с новым дизайном: от постепенного знакомства с привнесенными новшествами («Попробуйте бета-версию обновленного сайта прямо сейчас!») до создания пошагового гайда по новым возможностям. О последнем варианте мы сегодня и поговорим.

Моя стратегия разобраться в какой-либо теме — пару часов почитать Хабр. Я решил сэкономить немного времени таких же, как и я, и сделал небольшую подборку полезных и интересных материалов на тему UX. Сразу предупрежу, что получить профессиональный level up с помощью них не получится (для этого есть оффлайновые курсы), но вот вникнуть в тему и получить инсайты — запросто. И да, если есть, поделитесь ссылками на материалы, которые были для вас максимально полезными в свое время.

Как-то мне надо было добавить в админку просмотр списка паролей. База хранилась на сервере в формате KeePass (kdbx v2), сервер был на ноде — недолго думая, я взял первый попавшийся пакет и сделал. А потом понадобилось то же самое, но прямо у пользователя в браузере, без сервера. Ничего не нашлось. Первым желанием было форкнуть либу и заменить использование node api, но от первого просмотра кода желание пропало, решил сделать сам.



Под катом расскажу о проблемах, с которыми я столкнулся, и способах их решения

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

Давид Монтаг (David Montaque), выпускник Стэнфордского университета и сотрудник компании Palantir Technologies, написал статью, в которой описал создание алгоритмических стратегий для торговли фьючерсами на основе исторических данных. Для предсказания будущей цены и волатильности Монтаг использовал техники машинного обучения. Мы представляем вашему вниманию описание эксперимента и выводы, к которым пришел исследователь.

Недавно столкнулся с интересной задачей: в шапку сайта установить видео в качестве фона. Шапка всегда занимает первый экран и установлена по принципу background-position: 50% 0. Суть в том, что на планшете мы видим видео полностью, а на телефоне оно обрезается по краям и снизу остается только центральная часть.

Предлагаю вашему вниманию перевод статьи «Responsive Upscaling: Large-Screen E-Commerce Design» автора Christian Holst.

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

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

1. Только 18% из 50 ведущих американских интернет-магазинов, которые мы тестировали ранее, в этом году адаптировали свой дизайн под большие экраны (в то время как у 94% этих сайтов дизайн адаптирован под мобильные устройства).
2. Почти три четверти электронных продаж все ещё совершаются на ПК, а не на мобильных устройствах (смотрите здесь, здесь и здесь).
3. Около трети этих пользователей приходят с экранов шире 1350 пикселей (смотрите здесь, здесь и здесь). (Примечание: Разумеется, есть разница между шириной экрана и шириной браузерного окна — реальное число пользователей с браузером указанной ширины будет ниже. Мы рекомендуем вам отслеживать размеры браузерного окна в вашей веб-статистике для более полной картины того, насколько значителен этот сегмент для вашего сайта.

В нашем блоге мы уже неоднократно рассказывали о создании интерактивных email-рассылок с помощью CSS и HTML. Сегодня мы представляем вашему вниманию адаптированный перевод заметки Джастина Ку о том, как сверстать интерактивные вкладки, которые будут работать в почтовых программах iOS, Android и популярных веб-приложениях.

Осталось совсем немного до окончания набора в третью Школу разработчиков интерфейсов, которая в этот раз пройдёт в Москве. Упор в ней будет сделан на практику в формате виде мини-хакатонов. Его мы уже опробовали в прошлом году в Минске и Екатеринбурге. Студенты будут делиться на команды, и уже командно реализовывать проект. Кроме написания самого кода, нужно будет уметь принимать решения, разбираться с возникшими спорными вопросами, разбивать весь процесс разработки на логические итерации. Помогать в этом будут ребята из Яндекса, которые будут работать индивидуально с каждой командой. Занятия начнутся 7 сентября.

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

Вступительное испытание в Школу тоже очень практическое. Мы закончим принимать заявки 16 августа в 23:59. Пока есть еще время справиться с заданиями, мы попросили наших преподавателей немного помочь будущим студентам и на примере прошлогодней анкеты объяснить, какой логикой стоит руководствоваться, решая предложенные задачи, и рассказать, чему они уделяют внимание при их проверке.



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

Капча всем известна. Также всем известно, что она представляет собой большую проблему и для программистов и для пользователей. Она ни тем ни другим не нравится! Ее приходится использовать по необходимости!

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

Последний предлагаемый метод спорный, но судите сами!

Примечание переводчика: Тема наследования в JavaScript является одной из самых тяжелых для новичков. С добавлением нового синтаксиса с ключевым словом class, понимание наследования явно не стало проще, хотя кардинально нового ничего не появилось. В данной статье не затрагиваются нюансы реализации прототипного наследования в JavaScript, поэтому если у читателя возникли вопросы, то рекомендую прочитать следующие статьи: Основы и заблуждения насчет JavaScript и Понимание ООП в JavaScript [Часть 1]

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

JavaScript является очень мощным языком. Настолько мощным, что в нем сосуществует множество различных способов проектирования и создания объектов. У каждого способа есть свои плюсы и минусы и я бы хотел помочь новичкам разобраться в этом. Это продолжение моего предыдущего поста, Хватит «классифицировать» JavaScript. Я получил много вопросов и комментариев с просьбами привести примеры, и для именно этой цели я решил написать эту статью.

Привет!

За то время, пока мы писали, что есть для веб-разработчика в нашем облаке Microsoft Azure, а потом писали, что изменилось, произошло достаточно изменений для того, чтобы написать ещё одну статью. :) (вкратце за час можно посмотреть чего нового в докладе XaocCPS с DevCon 2015). Под катом — краткий обзор со ссылками, 10 минут прочтения которого дадут представление о том, что есть на Azure для веб-разработчика.

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

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

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

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

Предлагаю читателям «Хабрахабра» перевод статьи «12 Little-Known CSS Facts (The Sequel)». Она совсем недавно была упомянута в дайджесте интересных материалов из мира веб-разработки и IT.

Update: немного «шлифанул» перевод напильником. Выражаю благодарность всем неравнодушным читателям.
Внимание! Под катом почти 1.5 Мб картинок и много интересных ссылок.

Итак, начнём-с…

1. В свойстве border-radius можно использовать slash-синтаксис.

Об этом уже писалось 4 года назад, но многие новички и даже некоторые опытные разработчики не знают о существовании этой «фишки».

Верите или нет, но следующий код валиден:

.box {
  border-radius: 35px 25px 30px 20px / 35px 25px 15px 30px;
}

Больше года назад я опубликовал 12 малоизвестных фактов о CSS (перевод на хабре), и по сей день это была одна из самых популярных статей на SitePoint. С тех пор я собирал больше интересностей и маленьких советов по CSS для новой публикации. Мы же все знаем, что каждый успешный фильм должен способствовать выходу новомодного сиквела, верно?

^{Автор иллюстрации SitePoint/Natalia Balska.}

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