Технический долг – одна из самых больных тем, которые возникают при продуктовой разработке. На него вечно не хватает времени, и бизнес часто не видит необходимости в его устранении. Статья "How great Product Managers deal with technical debt" приводит в пример некоторые инсайты, которые помогут в снижении долга.

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

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

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

#pm #product

https://productcoalition.com/how-great-product-managers-deal-with-technical-debt-453edec3d473

"XML and JSON Are Like Cardboard" - статья, рассказывающая про то, что представляют собой для современного мира слабоструктурированные (Semi-structured) текстовые форматы обмена данными.

Автор сравнивает XML и JSON с картоном. Практически любая промышленность использует картон для упаковки товара. Если вы закажите маленький чип в интернет-магазине, его вам доставят упакованным в большое количество картона, вес которого будет в несколько раз больше. Тем не менее использование избыточного количества картона в упаковке, превышает потенциальные потери, которые могут быть вызваны при транспортировке без него.

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

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

#musings #xml #json

https://queue.acm.org/detail.cfm?id=3143320

Давайте поговорим про js-фреймворки, а именно про будущий Vue 3.0. Кажется, что прошло совсем немного времени с момента релиза второй версии, но разработчики уже готовы выпустить следующий мажорный релиз. Статья "What Does Vue 3.0 Mean for Web Development?" рассказывает о том, чего нам ждать в будущем.

Основной упор был сделан на оптимизации производительности. Движок отслеживания изменений был переписан на ES2015 Proxy. Это позволило ускорить начальную инициализацию компонентов в 2 раза и снизить потребление памяти. Также разработчики разбили фреймворк на ещё большее количество модулей, что позволило уменьшить ядро до 10Кб (в gzip). Во второй версии были эксперименты с использованием Vue на нативных платформах аля React Native. В третей версии поддержка нативных платформ заявлена как основная фича. Под шумок разработчики переписывают код с Flow на TypeScript, мотивируя это тем, что пользователей TS гораздо больше. Очень много внимания уделили Developer Experience.

Ну что сказать, звучит это всё более чем любопытно. Очень интересно наблюдать за тем, как Vue стремительно развивается, не имея за спиной поддержки в лице больших корпораций. И кто знает, какую долю займёт Vue через несколько лет.

#vue #js #jsframeworks

https://medium.com/@mattmaribojoc/what-does-vue-3-0-mean-for-web-development-851052fc0138

Внезапно меня занесло в баг-трекер v8, где я увидел очень интересный пропозал от разработчика из Microsoft.

Как оказалось в v8 оператор in не оптимизирован. Все его вызовы приводят к дорогостоящим рантайм проверкам. В пропозале идёт речь про переход к использованию инлайн кешей и jit-оптимизаций при использовании in. Но есть известные проблемы, когда перебираются все ключи объекта, в этом случае оптимизаций нет.

Были произведены замеры с тестовой реализацией v8 на методе Array.prototype.indexOf, который вызывался 10 раз у массива с 10 миллионами элементов. Результаты хорошие - заметно ускорение в 4-10 раз на разных типах массивов.

#js #v8 #performance

https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig/edit

Для меня было небольшим открытием, что на сайте npm есть semver-калькулятор.

Вводите в поле "pick a package" интересующий пакет, в поле "enter a range" диапазон версий и вуаля - зелёным цветом будут показаны все нужные версии.

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

#npm #tool

https://semver.npmjs.com

Может быть конвертация строки в число сама по себе простая операция, но только не в JavaScript, где существует множество возможностей выстрелить себе в ногу. Валерий Карпов в статье "Convert a String to a Number in JavaScript" описывает суть проблемы с конвертированием и приводит возможные решения с хорошим объяснением нюансов.

Автор предлагает использовать Number(), если вы готовы мириться с граничными случаями при конвертации, например, Number(''); // 0, и parseFloat(), если вам нужна большая строгость parseFloat(''); // NaN. Для проверки, является ли число NaN, советует использовать метод Number.isNaN(), который был добавлен в ES2015. Призывает отказаться от использования глобального isNaN(), так как isNaN('string') === true, а Number.isNaN('string') === false, то есть в последнем варианте аргумент не приводится к числу и таким образом этот метод "честнее" для разработчика.

Странно, что в статье про parseInt() ничего нет. Видимо, подразумевается, что мы работаем в основном с десятичной системой счисления.

#js #quirks

http://thecodebarbarian.com/convert-a-string-to-a-number-in-javanoscript.html

С развитием прогрессивных web-приложений (PWA) необходимость в нативных платформах становится не такой острой как раньше, особенно когда web-приложения взаимодействует только с серверами. Но, к сожалению, они проигрывают, когда необходимо организовать общение с устройствами, например, роутером, дроном, умной лампой и т.п. Чтобы избавиться от этого недостатка, в современных браузерах реализуют новый стандарт WebBluetooth API. Статья "An Introduction To WebBluetooth" от Ниелса Линхера служит хорошей отправной точкой для начала его изучения.

Работа с устройствами очень проста при использовании WebBluetooth. Достаточно подключиться к устройству по bluetooth через браузер (интересно, что в терминах WebBluetooth API устройство является сервером) и выбрать нужный сервис на устройстве. После выбора нужного сервиса можно начинать записывать в определённые характеристики сервиса значения, чтобы изменить поведение устройства, например, изменить цвет у умной лампы, или узнать текущие характеристики, например, уровень белого цвета у той же лампы.

Я считаю, что перспективы у этого стандарта очень хорошие. С учётом того, что на рынке появляются всё больше и больше устройств с поддержкой bluetooth, ещё большее распространение API (сейчас оно доступно только в Chromium-based браузерах и Samsung Internet) может послужить импульсом для появления очень креативных web-приложений.

#webapi #bluetooth #WebBluetooth

https://www.smashingmagazine.com/2019/02/introduction-to-webbluetooth/

Прочитал очень интересную статью Эрика Эллиота "The Forgotten History of OOP". В ней очень детально разбирается история появления ООП и то как оно трансформировалось с течением времени.

Всё началось с биолога и математика Алана Кея, который был вдохновлён идеей создать вычислительные части одной системы "клетками". Его идея воплотилась в одном из первых ООП языке - Smalltalk'е. На него большое влияние оказали Lisp и Simula. Наследование в него было добавлено позже уже другим человеком. Алан считает, что наследование послужило той причиной по которой его основные идеи, которые он вложил в понятие ООП, не получили большего внимания. Основными ингредиентами ООП по его мнению являются передача сообщений, инкапсуляция и динамическое связывание. То есть по большей части совсем не то, что подразумевают большинство современных программистов, когда слышат это понятие (инкапслуяция, наследование, полиморфизм).

Эрик предлагает вернуться к изначальным идеям Алана Кея и начать разрабатывать системы в парадигме MOP (термин предложен Эриком как сокращение от Message Oriented Programming). При проектировании таких систем компоненты не должны знать о внутреннем состоянии других компонентов, всё взаимодействие между ними должно быть построено на передаче сообщений, при этом они могут работать распределённо.

После прочтения статьи меня не оставляет ощущение, что эти идеи очень сильно перекликаются с микросервисной архитектурой.

#oop #history #musings

https://medium.com/javanoscript-scene/the-forgotten-history-of-oop-88d71b9b2d9f

Давно смотрю в сторону elm, но пока с ним ничего серьёзного не делал. Тут попалась статья "Elm changed my mind about unpopular languages", после прочтения которой снова захотелось что-нибудь написать на этом языке.

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

У elm много плюсов: элегантный командный интерфейс, поставляющаяся с платформой утилита для автоматического форматирования кода, обязательное следование semver у пакетов, дебаггер с поддержкой time-travel, отличная производительность, хорошо проработанный интерфейс взаимодействия с JS. Также есть минусы: высокий порог входа для программистов, привыкших работать с императивными языками, нельзя использовать на сервере, недостаёт высокоуровневых возможностей других функциональных языков, например, Haskell.

#elm #fp

https://blog.realkinetic.com/elm-changed-my-mind-about-unpopular-languages-190a23f4a834

Мне очень нравятся статьи Ире Адеринокун - просто и по делу. Недавно она опубликовала статью "Tips for making interactive elements accessible on mobile devices", с советами как облегчить жизнь пользователям мобильных сайтов.

В статье много советов, и они должны быть достойны вашего внимания. Размещайте интерактивные элементы в доступных местах на странице. Старайтесь делать интерактивные элементы так, чтобы пользователь понимал, что с ними можно взаимодействовать. Предоставляйте инструкции для нестандартных жестов, например, как в Twitter при обновлении ленты твитов. Увеличивайте расстояние между элементами и область тапа, чтобы интерактивные элементы можно было удобно нажимать пальцем. Группируйте объекты, выполняющие одинаковые действия. Используйте возможности HTML5, для настройки раскладки клавиатуры при работе с <input>. Предоставляйте альтернативу ввода с помощью клавиатуры.

На написание статьи Ире сподвигнули рекомендации W3C - Web Content Accessibility Guidelines 2.1, которые были обновлены в июне 2018 года.

#ui #a11y #mobile

https://bitsofco.de/tips-for-making-interactive-elements-accessible-on-mobile-devices/

Продолжаю делиться своими мыслями по поводу прочитанных статей. Сегодня попалась статья Акселя Раушмайера "Future JavaScript: what is still missing?". Аксель в ней размышляет о том, каких возможностей пока ещё не хватает в JS. Текста много, поэтому остановлюсь на самых интересных пунктах.

В JS нет простого способа сравнить два объекта по значению. Аксель предлагает для этого новый синтаксис #{x: 1} === #{x: 1} или новые виды классов на базе экспериментального синтаксиса декораторов. Также нет возможности использовать обычные инструкции как выражения. Для этого предлагается использовать do-выражения, которые уже существуют в качестве предложения добавления в стандарт. Для более удобной работы с композицией функций предлагается использовать pipeline operator |>. Интересно то, что на данный момент существуют два конкурирующих предложения "F# Pipelines" и "Smart Pipelines". Также Аксель высказывает мысль, что было бы неплохо иметь более легковесную конструкцию (относительно Worker API) для работы с конкурентностью. В статье ещё есть очень интересная мысль про использование стандартной библиотеки вместо объектов определённых в стандарте (Object, Reflect, Math, JSON).

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

#js #future #musings

http://2ality.com/2019/01/future-js.html

В статье, про которую я писал вчера, Аксель говорит о том, что он не фанат опционального чейнинга (`obj?.prop` - пропозал в будущий стандарт JS) и даёт ссылку на статью "Overly defensive programming" Карла Витулло, которая раскрывает идею того, почему чрезмерные проверки по всему коду это не очень хорошая практика.

Если мы пишем в коде слишком много защитных проверок (например, `const p = obj && obj.p;`) и подавляем возможные ошибки, то это может служить признаком того, что мы не знаем, какие гарантии предоставляют используемые сервисы и сторонние библиотеки. В итоге это может приводить к непонятным ошибкам. Лучше всего заблоговременно разобраться в данных и кинуть ошибку как можно ближе к тому месту, где она произошла, не забыв залогировать. В статье есть хороший пример. Какое сообщение вам будет понятнее: Warning: Failed prop type: The prop 'a' is marked as required in 'Thing', but its value is 'undefined'. или Uncaught TypeError: Cannot read property 'b' of undefined? Кажется, что ответ очевиден. Как альтернативу проверкам можно использовать статическую типизацию, которая просто не даст коду собраться, если какие-то контракты были нарушены.

Чрезмерные проверки - это как прикрывание дыр в стене с помощью картин. На первый взгляд может казаться, что всё в порядке, но на самом деле дыры остаются на своём месте точно также как и баги в программе.

#programming #softwaredesign #musings

https://medium.com/@vcarl/overly-defensive-programming-e7a1b3d234c2

Hackerrank выложил результаты опроса 70 тысяч программистов.

Cамый популярный язык 2018 года JavaScript; в прошлом году на первом месте была Java. Больше всего программисты в 2019 году хотят изучить Go, Kotlin и Python. В прошлом году на третьем месте была Scala, сейчас она переместилась на 6-ое место. Мне показался забавным график "Frameworks developers want to learn in 2019", где перемешали Angular, React, Spring, .NETCore, Ruby on Rails и другое. В общем, больше всего разработчики хотят изучить React. Наиболее перспективной новой технологией, разработчики считают Internet of Things (53%), Deep Learning уступил всего лишь три процента (50%). Во время работы большинство программистов предпочитает слушать электронную/танцевальную музыку, при этом у старшего поколения (54-72 года) наиболее популярны классика и рок.

#survey #results

http://info.hackerrank.com/rs/487-WAY-049/images/HackerRank_2019-Developer-Skills-Report.pdf

Вчера Бенджамин Де Кок (участник рабочей группы CSS) твитнул про то, что их группа утвердила добавление в стнадарт много новых математических функций: calc(), min(), max(), clamp(), sin(), cos(), tan(), acos(), asin(), atan(), atan2(), hypot(), sqrt(), pow().

Это означает, что после добавления в браузеры новых CSS-функций, у фронтендеров будет ещё меньше причин обращаться к CSS-препроцессорам. Добавление новых функций также поможет создавать в CSS новые виды анимаций и трансформаций, которые ранее были невозможны. С помощью функции clamp() можно будет легко устанавливать размер шрифта, который будет зависить от размера вьюпорта, но при этом шрифт будет ограничен верхними и нижними пороговыми значениями.

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

#css #future #cssfunctions #csswg

https://twitter.com/bdc/status/1100921258839953408

Недавно на youtube появился очень ламповый документальный фильм, посвящённый Ember.js. В нём создатели Ember.js рассказывают про историю появления фреймворка и рассказывают про то, какое место он занимает в современном мире фронтенд разработки.

Ember.js - эволюционное развитие SproutCore, фреймворка, котрый был разработан в Apple (используется на icloud.com). Чарльз Джоли, который был лидом SproutCore, вместе с Йехуда Катц основали стартап, в котором Йехуда и Том Дейл фуллтайм работали над новым фреймворком Amber.js, который затем переименовали в Ember.js. Сейчас вокруг Ember есть небольшое сильное коммьюнити. Фреймворк используют как в стартапах (Tilde), так и в больших корпорациях (linkedin.com). Ребята видят рост популярности React, Angular и Vue.js, но сдаваться не собираются.

Интересный факт - Йехуда и Том разрабатывали абсолютно всё с помощью парного программирования.

#jsframeworks #emberjs #documentary #history

https://www.youtube.com/watch?v=Cvz-9ccflKQ

Продолжаем чтение статей Акселя Раушмайера (что поделать, они очень хороши). В этот раз попалась статья про оптимизацию хвостовых вызовов (tail call optimization - TCO) в ES2015.

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

Наличие оптимизации хвостовых вызовов помогает реализовывать рекурсивные алгоритмы более органично. Жаль только, что TCO, похоже, не скоро будет добавлен в v8 (Chromium) и SpiderMonkey (Firefox) из-за проблем с его реализацией. Поддержка TCO пока только есть в Safari.

#js #tco #fp #es2015

http://2ality.com/2015/06/tail-call-optimization.html

В январе этого года на www.javanoscriptjanuary.com опубликовали статью гуглера Майка Самуэля "Defensive JavaScript" про то, каких подходов следует придерживаться, чтобы писать безопасный код.

Просто перечислю основные пункты из статьи. Не доверяйте кастомным проверкам, так как в процессе тестирования ложно-негативные случаи выявляются с меньшей вероятностью, лучше воспользоваться готовым и проверенным временем инструментом. Проверяйте предположения перед тем, как делать то, что нельзя отменить, например, предположение о том, что строка безопасна, при использовании myDOMNode.innerHTML = x; или response.write(x); на сервере. Не стоит пренебрегать дополнительными уровнями защиты, даже если они кажутся избыточными. Если вы используете статическую типизацию, это не повод отказываться от дополнительных проверок пользовательских данных.

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

#js #security

https://www.javanoscriptjanuary.com/blog/defensive-javanoscript

В рассылке сайта dev.to попалась статья про прфессинальное выгорание. Это очень серьёзная проблема, к которой, к сожалению, иногда относятся несерьёзно.

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

Пожалуйста, берегите себя и тех, кто вас окружает.

#productivity

https://dev.to/molly_struve/i-cant-do-it-all-my-burnout-story-1e54

Для того чтобы разобраться в нюансах настройки кэширования ресурсов на стороне клиента, советую прочитать очень хорошую статью Гарри Робертса "Cache-Control for Civilians", которую он опубликовал буквально пару дней назад.

В статье разбираются как распространённые методы управления кэшом, например, использование заголовка Cache-Control, так и новые механизмы, например, директива immutable и заголовок Clear-Site-Data. Рассказывается про кэш-бустинг. Из этой части я узнал, что cloudflare удаляет query string, если он используются для бустинга ассетов. То есть style.css?v=1.2.14 превращается просто в style.css. Ещё в статье есть пара практических советов настройки кэширования для определённых видов страниц.

Статья, как я уже говорил в начале, хорошая, но мне кажется, что она была бы ещё лучше, если бы в ней был более детальный разбор работы no-cache.

#http #cache

https://csswizardry.com/2019/03/cache-control-for-civilians/

Кайл Симпсон (автор "You Don't Know JS") у себя в твиттере поделился своими наблюдениями про то, как иногда используются функции, содержащие this.

Если вы замечаете, что вам становятся нужны стрелочные функции для сохранения контекста и что вы чрезмерно используете .bind() или старый-добрый var self = this;, то всё это симптомы того, что вы боритесь с this. Например, если такой класс используется в вашей программе автономно:

class Foo {
  constructor(x) {
    this.x = x;
    this. bar = () => this.baz(this.x + 1);
    this.baz = v => v * 2;
  }
}

var a = new Foo(20);
btn.addEventListener("click",a. bar);  // 42

То его можно заменить паттерном "Модуль":
fu

nction Foo(x) {
   return { bar, baz };
   function bar() { return baz(x + 1); }
   function baz(v) { return v * 2; }
}

var a = Foo(20);
btn.addEventListener("click",a. bar);  // 42

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

#js #context

https://twitter.com/getify/status/1101491957916938240?s=21