Разрешите представить вам перевод статьи Нолана Лоусона «У нас проблемы с промисами», одной из лучших по теме из тех, что мне доводилось читать.

У нас проблемы с промисами

Дорогие JavaScript разработчики, настал момент признать это — у нас проблемы с промисами.

Нет, не с самими промисами. Их реализация по спецификации A+ превосходна. Основная проблема, которая сама предстала передо мной за годы наблюдений за тем, как многие программисты борются с богатыми на промисы API, заключается в следующем:

— Многие из нас используют промисы без действительного их понимания.

Если вы мне не верите, решите такую задачку:

Вопрос: В чем разница между этими четырьмя вариантами использования промисов?

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);

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

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

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

Привет, Хабр!

Мы в Хекслете любим свой стек технологий :) Когда рассказываем другим — многие завидуют: Rails, Docker, AWS, React JS. Реакт мы используем в первую очередь для создания веб-среды для разработки Hexlet-IDE, которая позволяет нашим пользователям выполнять упражнение по разработке приложений и взаимодействию с виртуальной машиной прямо в браузере.

Сегодня мы публикуем перевод статьи «An Unconventional Review of React» Джеймса Шора, ведущего проекта Let’s Code: Test-Driven JavaScript.



Он мне понравился. Я не ожидал такого.

Для специальных выпусков Let’s Code JavaScript в августе и сентябре я изучал Реакт.

На случай если вам не знаком Реакт: это библиотека для фронт-энд веб-разработки. С помощью него создаются компоненты: короткие, не-совсем-ХТМЛ теги, которые можно комбинировать для создания интерфейса.

Реакт знаменит своими нетрадиционными решениями: реализацией виртуального DOM’а, созданием элементов интерфейса в JavaScript вместо шаблонов, создание суперсета языка JavaScript — JSX, который позволяет вставлять не-совсем-ХТМЛ прямо в код JS.

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

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

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

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

Идея написать подобный пост у меня появилась давно; в некоторых кописрачах я прямым текстом писал, что копирайт убивает классическое искусство и обещал раскрыть этот тезис позже. Долгое время меня останавливало то, что на Хабре такой топик вряд ли будет сильно интересен. Но, после некоторых раздумий, я пришёл к выводу, что проблема «копирайт — искусство» шире собственно классической музыки и литературы и затрагивает многие куда более приземлённые вещи. Например, игровую индустрию.

Если мы посмотрим внимательно на жанровое разнообразие в игровой индустрии (сразу оговорюсь, я имею в виду сюжетные single-player игры, не касаясь mmorpg и казуальщины), то мы обнаружим, что оно существенно деградировало по сравнению с 90-ми годами. Жанр квеста исчез совсем, TBS находится на грани вымирания. Существенно сократилось поголовье классических RPG типа Baldur Gate, Planescape Torment (т.е. таких RPG, где надо думать головой при билде персонажа). Стало значительно меньше игр с оригинальной игровой механикой (типа Settlers I-II). Собственно, за меня здесь уже всё сказали, см. картинку слева.

Большая часть современных игр — это какая-то помесь RPG от первого лица, шутера и аркады. При этом, что характерно, на разработку этих игр тратится очень много денег, так что проблема явно не в желании издателя сэкономить. Ровно то же самое произошло и с музыкой: всё многообразие жанров (опера, симфония, соната, фуга, etc.) в классическом искусстве деградировало ровно до одного — песни. И, если я не ошибаюсь в своих предположениях, то очень скоро с геймдевом произойдёт то же самое.

Собственно, если некоторые студии перестанут регулярно выкапывать труп стюардессы (см. Might & Magic Heroes VI, Civilization V, Diablo 3, etc), то это может произойти прямо завтра. Почему же? Что общего у геймдева 90-х и классической музыки?

Файловых менеджеров много, но есть один, о котором, думаю, будет многим интересно узнать. Ведь он двухпанельный, работает в браузере, оснащён редактором (с подсветкой синтаксиса) и консолью, состоит из клиента и сервера, а написан на JavaScript/Node.js.

То ли с подачи Бизнес Молодости, то ли по иным причинам, сейчас только ленивый не предлагает разработку Landing Page. И на то есть причины. Согласно глобальной идее, лендинг – эта такая особая страница, которая технично должна превращать посетителей в лиды со значительно большей вероятностью, чем это умеет делать сайт в привычном понимании.


Сатира на большинство «лендинг пейджей»

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости

Angular — зрелый и мощный JavaScript-фреймворк. Он довольно большой и основан на множестве новых концепций, которые необходимо освоить, чтобы работать с ним эффективно. Большинство разработчиков, знакомясь с Angular, сталкиваются с одними и теми же трудностями. Что конкретно делает функция digest? Какие существуют способы создания директив? Чем отличается сервис от провайдера?

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

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

Еще одна? Зачем? Есть же CommonJS и AMD? Страждующие могут пройти под кат.

19 августа 2009 года, в 12:30 Том Леман написал первую строчку кода задуманного им проекта Rap Genius, посвященного трактованию рэп-текстов. А уже в 18:22 того же дня была готова первая версия веб-сайта. Менее шести часов потребовалось на то, чтобы создать сервис, куда сегодня каждый месяц заходят 40 миллионов новых пользователей, который привлек уже 17 миллионов долларов венчурных инвестиций, и вокруг которого недавно разгорелся интернет-скандал, разрешившийся в пользу проекта и сделавший его ещё более популярным.

В первый же день, разложив по полочкам песню Killa Cam в исполнении рэпера Cam’ron, Леман внедрил те функции, которые до сих являются самыми востребованными. Конечно же, мы были просто обязаны позвать его выступить на последней конференции Design+Startup, проходящей под патронажем фонда First Round. На этой встрече Леман поделился теми четырьмя словами, благодаря которым Rap Genius смог состояться.

«Первая версия Rap Genius была просто отвратительна. Но благодаря этой отвратительности я узнал секрет, как нужно делать вещи в интернете. Секрет простой: чем хуже, тем лучше».

Что же это значит на практике? Том Леман с удовольствием рассказывает нам об этом.

Введение

Я работаю веб-дизайнером. Какое-то время назад я подрабатывала фрилансером, сейчас работаю в небольшой студии. У нас нет менеджера проектов, поэтому, зачастую, я сама выступаю этим самым менеджером, по совместительству. Опыт общения с самыми разными заказчиками у меня достаточно большой. Статья «Краткая инструкция по работе с web-дизайнером (для менеджера проекта)» вызвала у меня шквал эмоций и бурю негодования, потому что именно таких заказчиков я всегда старалась избегать. В этой статье я попробую описать, как в идеале должна проходить работа заказчика и дизайнера.

С удовольствием приму критику и выслушаю мнения «другой стороны».

Применяя 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:

За последние шесть лет я добился успеха с тремя моими компаниями («Cube6 Media», «Gravatar» и «GitHub»), и потерпел неудачу с парой других проектов. Я много думал над тем, как все получилось, и определил 3 основных роли, которые необходимы для создания успешных веб-приложений: дизайнер, архитектор и разработчик.

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

Читая публикации о верстке для вэба, вы не раз натыкались на рекомендацию не использовать пикселы в media queries. Например, вот цитата из совсем недавней статьи на Хабре:

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

Что, если я скажу вам, что использование пикселов в media queries не только не причиняет никакого вреда верстке, но и имеет преимущества над использованием em'ов?

Сегодня на глаза попался старый вопрос "Почему работодатель предпочитает нанимать веб-разработчика в офис?": habrahabr.ru/qa/22292. Вопрос был задан еще в 2012 году, но, на мой взгляд, ситуация с тех пор не сильно изменилась.

Коллеги, тут есть серьезное недопонимание, которое давно пора устранить.

Многие, как мне кажется, представляют себе фрилансера примерно так:

• Приходит на какую-то отдельную небольшую задачу, выполняет ее и уходит.
• Работает над несколькими мелкими проектами одновременно. Либо имеет постоянную работу, а фрилансером просто подрабатывает в оставшееся время.
• Его не беспокоит проект в целом. Только то, за что он отвечает.
• Огораживает себя техническими заданиями. И из-за каждой новой плюшки может возникнуть конфликт.
• Работает когда хочет. С ним сложно связаться.

Вступление

В статье я собрал советы по использованию media query. Расскажу, как можно более эффективно использовать media query. В конце статьи есть список использованных источников.

• Внешнее подключение media query
  
• Больше чем просто размер viewport
  
• Не только смартфоны
  
• Инструмент для работы с media query
  
• Выделяйте специфичное
  
• Breakpoints когда и сколько?
  
• Второстепенные breakpoints
  
• Относительные единицы измерения
  
• Условная загрузка
  
• Список использованных ресурсов
  

Это открытое письмо CoffeeScript-сообществу.
Вы можете присоединиться к дискуссии на Hacker News.

Эта тирада, возможно, также справедлива для TypeScript и ему подобных. Чёрт, да даже для asm.js. Я знаю, что asm.js впечатляет в теории, но вы сами пытались пройтись по написанному на нём коду? Это мусор, и вам явно не придётся писать такое в ваших обычных каждодневных исходниках.

Одним из незамеченных героев вселенной HTML5 является XMLHttpRequest 2. Строго говоря XHR2 не является частью HTML5 и не является самостоятельным объектом. XHR2 это тот же XMLHttpRequest, но с некоторыми изменениями. XHR2 является неотъемлемой частью сложных веб-приложений, поэтому ему стоит уделить большее внимание.

Наш старый друг XMLHttpRequest сильно изменился, но не многие знают о его изменениях. XMLHttpRequest Level 2 включает в себя новые возможности, которые положат конец нашим безумным хакам и пляскам с бубном вокруг XMLHttpRequest: кросс-доменные запросы, процесс загрузки файлов, загрузка и отправка двоичных данных. Эти возможности позволяют AJAX уверенно работать без каких-либо хаков с новейшими технологиями HTML5: File System API, Web Audio API, и WebGL.

В этой статье будут освещены новые возможности XMLHttpRequest, особенно те, которые можно использовать при работе с файлами.

Примечание переводчика: После публикации статьи с автором связался коммерческий директор из King.com, создателя Candy Crush Saga, и прояснил несколько моментов, после чего автор добавил пару замечаний. Добавленные абзацы отмечены курсивом.

Принудительная монетизация

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

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

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