Пишу про разработку вообще и в частности про: JavaScript, HTML5, CSS3, AngularJS, ReactJS, Agile.

Хром меняет полиси относительно автозапуска видео на странице

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

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

i-will-found-you-and-will-mute-you

Если честно, то я доволен. Чем строже с автозапуском видео тем лучше.

Autoplay Policy Changes

Поделиться:

Пример улучшения дизайна для корзины

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

cart-design-makeover

Cart design upgrade

Поделиться:

Webpack-server проксируем запросы

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

или

но это не самое лучшее решение. Так как нужно настраивать это отдельно и каждый фронтенд разработчик должен быть в курсе. А хочется запустить все командой

И больше не возвращаться к этому вопросу. Для этого можно настроить проксирование через webpack-dev-server, обращаться во время разработки к нему, а он уже будет стучаться к удаленному серверу.

webpack-proxy-flow-diagram

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

Все настройки добавляются во все тот же webpack.config.js

Ссылки по теме:

Поделиться:

UI – сборник микро-советов

Немножечко советов о том, как сделать UI приятнее и нагляднее. По ссылке внизу можно получить все одним махом 😉

Все советы одним моментом:

Поделиться:

Биткоин – жутко медленная и энергоемкая система транзакций

Биткон-сеть, для своей работы потребляет энергию – энергия требуется на “майнинг”, расшифровку и обработку блоков с информацией о транзакциях. В год на это потребляется 35 тераватт электричества, столько же сколько и Дания. Только в случае с Данией это целая страна, а в случае с биткоином это очень медленная сеть по обеспечению транзакций.

bitcoin-transactions-data

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

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

Ссылки по теме:

Поделиться:

Тестируем NodeJS

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

Причем под NodeJS вроде несовсем понятно как это и делать, а проблема в том как мы пишем код:

Этот код ни разу не протестировать, потому что мы не можем просто создать файл с тестами, импортировать туда productsController.js и поверять что возвращает метод fetchProducts. А все потому что он тесно связан с базой данных myDB, эту связь для тестов нужно разорвать, заменив базу данных на временный объект.

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

Можно пойти другим путем – заменять контекст. Стандартный пакет vm имеет метод runInNewContext(), который как раз этим и занимается. В итоге нам потребуется вот такая вспомогательная функция для загрузки контроллера, который нужно протестировать:

И все что остается – это использовать ее в самом тесте:

Ссылки по теме:

Поделиться:

Зарплата в зависимости от того на чем пишешь JS

Да, звучит немного странно – на чем можно писать еще JS кроме самого JS. Все нормально, ребят, не спешите, у меня есть мысль, хочу поделиться. Интерактив на фронте можно писать не только на JS, но и на другом языке, который будет компилироваться в JS. Вы же слышали про TypeScript или CoffeeScript, ну так это два варианта таких языков. И вот вариантов этих достаточно много, если быстренько, то вот несколько примеров:

  • TypeScript
  • CoffeeScript
  • Elm
  • Reason
  • Dart
  • Purescript
  • ClojureScript
  • Scala.js
  • Haxe
  • Nim

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

  • Попытка отгородиться от “пороков” JS, и начать-таки писать безопасный код, что бы ошибки ловились на стадии компиляции
  • Писать код один раз, а потом компилировать его под разные системы
  • Программистам не нужно изучать все тонкости JS, могут просто писать на том, что уже знают

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

js-flavors-salary

Звучит, конечно, интересно и хочется уже начать учить то, что оплачивается так хорошо. Однако, у меня есть несколько вопросов к этим результатам (правда пока без ответов) – Самая высокая зарплата у тех, кто пишет на Reason. Я вообще о нем до этого ни разу не слышал. Зайдя на репозиторий этого языка видно, что разрабатывается он в фейсбуке и что-то мне подсказывает, что именно там-то и работают большинство программистов, которые им пользуются. То есть так ли зарплата связана с языком или все-таки с местом работы, где этот язык и разработали?

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

Ссылки по теме:

Поделиться:

Таблица умножения в функциональном стиле

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

multiplication-table

Самое смешное, что в JS нет явного функцонального способа создать цикл. Если речь заходить о циклах, то перед глазами сразу встает for или while, но они же ни разу не фенкциональные =)

На языке Scala можно решить это достаточно просто:

А все потому, что циклы тут умеют сами возвращать значение. Но это в скале, а вот в JS все иначе.

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

Кстати, я об этом уже писал – Создаем массивы в JS

Это, кстати, и будет самым “сложным” этапом, после этого весь остальной код достаточно тривиален:

Поделиться:

Консоль хрома теперь не интерпретирует код сразу как нажали на enter

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

console-brackets-boundaries

Да, скорее всего это обновление еще с прошлой версии. Каюсь ребята, забыл протестировать, а ждал уже давно 🙂

Поделиться:

Подключение стилей через webpack

Подключать стили через webpack не очень сложно, есть два основных варианта:

  • Собирать все стили в один внешний файл css
  • Хранить стили в файлах js и встраивать их уже во время парсинга

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

webpack.config.js

Встраивать стили в js файлы проще. Для этого дополнительный плагинов не требуется, достаточно только указать каким “лоадером” парсить стили:

webpack.config.js

Я предпочитаю использовать второй способ – встраивать стили в js файлы. Тому есть несколько причин:

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