Всем привет, как-то давно мне иметь дело с большим количеством разных текстовых редакторов и IDE, на различных операционных системах. Тогда мне очень сильно начал раздражать такой момент, что на каждой их них стоит своя тема оформления кода, плюс ещё несколько других на выбор. Там были и хорошие и плохие, но они все были разные, что для меня на тот момент являлось проблемой и постоянно приходилось привыкать к новому оформлению.
Привет! Представляю вашему вниманию перевод статьи «What to do when “this” loses context» автора Cristi Salcescu.
Лучший способ избежать потери контекста this – не использовать this. Однако, это не всегда возможно. Например, мы работаем с чужим кодом или библиотекой, которые используют this.
Литерал объекта, функция-конструктор, конструктор объектов класса в системе прототипов. Псевдопараметр this используется в системе прототипирования для того, чтобы дать доступ к свойствам объекта.Читать полностью »
Дэвид Хэррон, автор материала, перевод которого мы публикуем сегодня, задался следующим вопросом: «Должен ли человек, работавший более 10 лет в Sun Microsystems, в команде Java SE, до последнего вздоха думать лишь о байт-коде Java и создавать экземпляры абстрактных интерфейсов?». Он задавал этот вопрос применительно к себе, и для него платформа Node.js, после Java, оказалась подобна глотку свежего воздуха. Дэвид говорит, что когда он был уволен из Sun в январе 2009 года (прямо перед поглощением этой компании Oracle), он узнал о Node.js. Эта технология его зацепила. Что значит «зацепила»? С 2010-го года он много писал о программировании для Node.js. А именно, написал несколько книг, в том числе — «Node.js Web Development», четвёртое издание которой вышло в этом году. Он подготовил множество небольших материалов о Node.js, опубликованных в интернете. Фактически, он уделил очень много времени и сил, рассказывая о платформе Node.js и о возможностях JavaScript. Почему того, кто раньше занимался исключительно Java, так увлекли Node.js и JavaScript?
Данная статья является логическим продолжением введения в программирование шейдеров для верстальщиков. В ней мы сделали шаблон для создания различных двумерных эффектов с фотографиями с помощью шейдеров и посмотрели пару примеров. В данной статье мы добавим еще пару текстур, применим на практике разбиение Вороного для создания мозаики из них, поговорим о создании различных масок в шейдерах, о пикселизации, а также затронем некоторые проблемы древнего синтаксиса GLSL, который до сих пор существует в наших браузерах.
Так же, как и в прошлый раз, будет минимум теории и максимум практики и рассуждений на приземленном бытовом языке. Начинающие найдут здесь последовательность действий с советами и полезными замечаниями, а опытные фронтендеры возможно найдут себе пару идей для вдохновения.
В этой статье я покажу насколько опасны могут быть расширения в хроме, и чем
расширения в фаерфоксе безопаснее.
Речь пойдёт о расширении FastProxy.
Ни в коем случае не ставьте его в чистом виде в хроме.
Что нужно, чтобы построить экосистему небанковских сервисов, да и вообще любую подобную экосистему? Мастер-система хранения и обработки данных, а также API. В этом посте мы разберем две версии созданного нами API — первую и удачную — и подробно остановимся на том, в чем их важные отличия друг от друга.
В последнее время микросервисные архитектуры пользуются определённой популярностью. От того, как взаимодействуют микросервисы, может зависеть производительность и масштабируемость решений, основанных на них. Это взаимодействие может быть синхронным или асинхронным. В материале, перевод которого мы представляем вашему вниманию сегодня, рассматриваются синхронные методы взаимодействия микросервисов. А именно, речь пойдёт об исследовании двух технологий: HTTP/1.1 и gRPC. Первая технология представлена стандартными HTTP-вызовами. Вторая основана на использовании высокопроизводительного RPC-фреймворка от Google. Автор материала предлагает взглянуть на код, необходимый для реализации взаимодействия микросервисов с использованием HTTP/1.1 и gRPC, провести замеры производительности, и выбрать технологию, которая позволяет организовать обмен данными между микросервисами наилучшим образом.
Привет, друзья!
Итак, разработчики Реакта решили сделать нашу работу с их либой более линейной, направить, так сказать, нас нерадивых на путь наименьшего шанса ошибиться и написать плохой код, что, на мой взгляд, является нашим неотъемлемым правом и способом совершенствоваться и изобретать. Речь идет о всеми любимых методах componentWillReceiveProps и других из той же серии, их больше не будет, но нам дадут альтернативу в виде статического метода getDerivedStateFromProps. Лично мне он напоминает темную комнату, где лежат вещи, и их нужно найти, но ничего не видно.
Разработчики в своих ответах на гневные комментарии пользователей Реакта пишут мол: Ну не дадим мы вам prevProps, это невозможно, придумайте что-нибудь, prevProps нет, ну вы держитесь там, просто кешируйте их в состоянии, в общем предлагают нам сделать небольшой костылек в нашем новом хорошем коде. Это все конечно несложно, можно понять и простить, но вот меня раздосадовал тот факт, что теперь у меня нет контекста this, комнату мою замуровали, из нее ничего не видно, даже соседей не слышно, вот и решил я написать для себя штуку, которая скроет в себе все костыли и мой код будет с виду хоть и странным, но бескостыльным (а бескостыльным ли?).
В общем, мне нужно внедрить prevProps в состояние компонента, еще хочется чтобы все выглядело как обычно, а также невозможно прожить без волшебного this в статическом getDerivedStateFromProps (вот дурак!). Два дня мучений и самосовершенствования и все готово, я родил мышь.
Задача сравнения фреймворков очень неблагодарное занятие, предпочтения у разработчиков разные, технологии меняются очень быстро. Слишком быстро. Эта статья, устареет еще до того момента как я нажму кнопочку “опубликовать“.
Читать полностью »
Сегодня я раскажу про модуль Hardware в Voximplant Web SDK. Этот модуль пришел на смену старой системе управления аудио- и видеоустройствами. Но сначала – немного об управлении устройствами в WebRTC-стеке и зачем все это нужно.
Редко, но у конечных пользователей бывает несколько микрофонов. Или бывает несколько динамиков: например обычные динамики и bluetooth-наушники; или динамик телефона и громкая связь для смартфона.
А вот две камеры в современном мире бывают очень часто. На планшетах и телефонах: обычная и фронтальная. На ноутбуках: встроенная и получше внешняя. И так далее и тому подобное. Пользователь может сильно растроиться, если по дефолту будет выбран не тот набор устройств и он никак не сможет их изменить. Это первое применение управлению медиа в WebRTC.
Второе применение — это тонкие настройки аудио и видео. Всякие эхоподавления, шумоподавления, установка разрешения видео, фреймрейта, баланс белого и прочего, что конкретно ваш браузер поддерживает.
Читать полностью »
