Джеймс Лонг — создатель Prettier — два года назад написал хорошую статью про то, что помогло ему в карьере программиста "How I Became a Better Programmer".

- Ищите людей, которые вас вдохновляют, но не идеализируйте их
- Цените то, что вы создаёте
- Не стоит работать круглыми сутками
- Игнорируйте "мишуру" и фокусируйтесь на фундаментальных концепциях и знаниях
- Прежде чем реализовывать свою идею проведите исследование
- Беритесь за большие проекты и выходите из зоны комфорта. В этом разделе ещё перечисляется то, что можно сделать: изучите C, напишите компилятор, изучите макросы, прочитайте SICP, разберитесь в continuations, пробуйте новые языки программирования.

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

#musings #career #programming

https://jlongster.com/How-I-Became-Better-Programmer

Сегодня прочитал статью 2012 года Люка Вагнера "Optimizing JavaScript variable access". В статье Люк написал про то, каким образом он оптимизировал доступ к переменным в SpiderMonkey (js-движок в Firefox).

Начинается статья с описания оптимизации наихудшего случая, когда скоуп расширяется в рантайме с помощью eval. Поиск значения переменной в этом случае осуществляется с помощью итеративного алгоритма, к которому применяется те же техники оптимизации, которые используются при получении свойства объекта. Затем разбирается быстрый доступ к локальным переменным. В этом случае доступ оптимизируется очень хорошо, так как запись или получение значения из стека сводится к одной команде CPU. Последним пунктом разбирается быстрый доступ к нелокальным переменным. В этом случае не нужно поддерживать динамический хэш как в первом примере, так как вся информация о переменных уже доступна во время запуска js-кода и код может быть скомплирован JIT-компилятором.

Честно говоря не знаю, насколько это описание актуально для новых версий SpiderMonkey. Но как бы то ни было, всегда интересно поразбираться во внутреннем устройстве движков, так как эта информация может пригодиться в самый неожиданный момент.

#spidermonkey #optimization #js

https://blog.mozilla.org/luke/2012/10/02/optimizing-javanoscript-variable-access/

Сегодня нашёл в твиттере хороший доклад Андерса Хайлсберга (основной автор TypeScript) "TypeScript: Static types for JavaScript".

В 2010 году, перед тем как принять решение о создании нового языка, разработчики хотели открыть исходный код инструмента ScriptSharp, который переводил исходный код из C# в JS и который уже использовался командой Outlook.com. Но в итоге решили пойти другим путём и создать новый язык, который бы устранял ошибки в JavaScript и добавлял новые фичи, которых не хватало в JS (типы, классы, декораторы и т.п.). Так появился TypeScript.

В докладе Андерс рассказывает про разные возможности TypeScript. Объясняет, почему они ограничили вывод типов локально. Это было сделали из-за неявности, которую могут нести системы типов с нелокальным выводом типов. Больше про вывод типов Андерс не рассказывал, но мне хотелось бы услышать про эту фичу побольше. В самом конце рассказывает про то, как в обычном JS можно улучшить себе жизнь, используя тулинг TypeScript. Например, VSCode подтягивает файлы определений типов для библиотек и таким образом для них начинает работать автодополнение. Ещё в любой JS-файл можно добавить комментарий // @ts-check и TypeScript будет подсвечивать ошибки при неправильном использовании функций или если в коде есть опечатки.

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

#typenoscript #talk

https://www.youtube.com/watch?v=ET4kT88JRXs

На прошлой неделе разработчики Edge написали пост про грядущие изменения в браузере после перехода на кодовую базу Chromium – "What to expect in the new Microsoft Edge Insider Channels".

В статье рассказывается, над чем в первую очередь будет идти работа. Команда Edge хочет уделить много внимания доступности Chromium: запланирована поддержка новых API, будут работать над high-contrast CSS Media query, реализуют возможность удобной работы с браузером с помощью клавиатуры. Начиная с версии Chromium 73 вместе с Google работают над поддержкой архитектуры ARM64. Ещё планируют улучшить прокрутку и юзабилити при работе на тач-устройствах. Продолжают работать над стандартами. Запланировали реализовать предложение HTML Modules. UA-string нового браузера будет включает токен "Edg":

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.48 Safari/537.36 Edg/74.1.96.24

На данный момент для Windows 10 доступна Canary-версия и Developer-версия. Developer-версия более стабильна. В будущем новый Edge будет доступен на Windows 7, Windows 8.1 и macOS.

#chromium #edge

https://blogs.windows.com/msedgedev/2019/04/08/microsoft-edge-preview-channel-details/

В прошлый вторник Владимир Клепов из Яндекс.Почты написал хороший пост про то как они адаптируют письма к тёмной теме – "Как создать тёмную тему и не навредить. Опыт команды Яндекс.Почты".

В статье рассматриваются три подхода:
1. Переопределение стилей. Самый простой и понятный подход, но с большим недостатком – все красивости в письме пропадают.
2. CSS-фильтр с инвертированием цветов. Находчивое решение, но у него очень большие проблемы с производительностью.
3. Преобразование стилей. Этот метод и используется в почте. Он гораздо сложнее в реализации, но результат самый лучший. Его суть заключается в том, что в динамике проверяются все значения цветов в формате HSL. Если яркость (L) выше (для текста) или ниже (для фона) порога, то ничего не меняется, так как письмо и так уже в нужной цветовой палитре. Если это условие неверно, то проводится адаптация цвета (h, s, l) => (h, s, 1 - l).

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

#css #colors #hsl #yandex

https://habr.com/ru/company/yandex/blog/446780/

Google в рамках проекта Fugu, который нацелен на устранением разрыва между нативными и web-приложениями, работает над добавлением имплементации чернового стандарта WebHID API для работы с HID-устройствами в Chromium. Робат Вильямс в статье "Upcoming WebHID API - access Bluetooth/USB HID devices in web applications" рассказывает о пользе этого API.

HID-протокол позволяет организовать работу с целыми классами устройств, избавляя от необходимости писать код для взаимодействия с разными устройствами. Например, код, использующий WebHID API для включения индикатора связи на гарнитуре, будет работать со всеми гарнитурами разных производителей, которые работают с этим протоколом.

В статье также разбирается работа с новым API, которое доступно с помощью navigator.hid. Есть пара примеров использования API. В них ничего необычного нет: подготовка устройства, считывание данных и отправка данных. В общем, web-платформа стремительно развивается. Скоро мы сможем делать с её помощью ещё более продвинутые приложения.

https://blog.scottlogic.com/2019/04/03/upcoming-webhid-api.html

#chromium #webplatform #future

Smashing Magazine опубликовал хорошую статью Павла Померанцева про управление z-index'ами "Managing Z-Index In A Component-Based Web Application".

Павел рассказывает, что такое контекст наложения (stacking context) и почему именно он является основной проблемой некорректного наложения элементов страницы друг на друга. Затем делится своей стратегией использования z-index, которая может помочь при управлении наложением в приложениях с большим количеством компонентов:
1. Все компоненты должны создавать свой собственный контекст наложения. Если внутри компонента нет элементов с z-index, то этот шаг необязателен.
2. Внутри CSS-файлов компонентов поддерживайте z-index'ы так как вам удобно. Предпочтительно использовать z-index только для тех элементов, которые не являются потомками других элементов.
3. Если возникает проблема с неправильным наложением, надо найти первый общий предок-компонент проблемных элементов и внутри этого компонента поменять z-index'ы корректным образом.

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

#css #layout

https://www.smashingmagazine.com/2019/04/z-index-component-based-web-application/

Вчера Матиас Байненс из команды v8 написал статью про то, как написать полифилл для globalThis, который будет работать во всех окружениях.

Несколько лет назад в TC39 появилось предложение унифицировать название глобального объекта, который бы был доступен в браузере, на сервере (node.js) и других окружениях. Так появился globalThis, который уже поддерживается нативно в Chrome 71, Firefox 65, Safari 12.1 и iOS Safari 12.2.

Написание полифилла для globalThis нетривиальная задача, так как скрипт может быть запущен в браузере, в web-воркере браузера, в расширениях, node.js, должен работать в strict-режиме и в sloppy-режиме и т.п. Матиас в статье поэтапно рассказывает как написать такой полифилл. В итоге приходит к решению, которое модифицирует прототип объекта, для получения доступа к глобальному объекту.

Object.defineProperty(Object.prototype, '__magic__', {
  get: function() {
    return this;
  },
  configurable: true
});
var globalThis = __magic__;
delete Object.prototype.__magic__;

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

#js #polyfill #proposal

https://mathiasbynens.be/notes/globalthis

Прочитал небольшую статью Тори Волкера "The Pitfalls of Async/Await in Array Loops" про использование async/await в циклах.

По ходу статьи Тори рассказывает как добиться того, чтобы три промиса были выполнены по порядку с использованием циклов. В начале он показывает неправильно работающий пример с использованием forEach и объясняет, почему он не работает так как нужно (в комментариях есть больше подробностей). Потом показывает уже работающее решение с использованием map. В этом примере почти всё работает как ожидается, но промисы не ждут друг друга. В последнем примере используется for...of, с которым всё ок – каждый промис ждёт выполнения предыдущего.

Статья небольшая, но вполне адекватная. Если у вас в проекте используется async/await, то статья может быть вам полезна.

#js #async

https://medium.com/dailyjs/the-pitfalls-of-async-await-in-array-loops-cf9cf713bfeb

Сергей Ufocoder опубликовал на ДевШахте очень прикольную статью "Анонимные функции в JavaScript".

Анонимная функция может легко ввести в заблуждение. Это доказывает опрос, который проводил Сергей у себя в твиттере. Анонимная ли эта функция?

const myFunc = function (a) {
return a + 42;
}

Анонимная. Если после function есть идентификатор, то это именованная функция, во всех остальных случаях анонимная. Но при этом у примера выше myFunc.name === 'myFunc'. Почему это именно так, а не иначе, в статье разбирается на уровне спецификации языка. В общем, статья интересная, советую почитать.

#js #specification #function

https://medium.com/devschacht/anonymous-functions-in-javanoscript-ff6b9ba85de0

Майкл Дроэтбум неделю назад в статье "Pyodide: Bringing the scientific Python stack to the browser" рассказал про новую разработку Mozilla. Pyodite — это экспериментальный проект для запуска полноценного python data science стека в браузере. Цель проекта — развитие data science экосистемы JavaScript.

Pyodite использует WebAssembly для запуска python-кода в браузере. Из кода на python доступна вся web-платформа: результат работы python-библиотек можно обрабатывать в JavaScript, отображать в canvas и т.п. В статье есть подробное объяснение того, как разработчики достигли интероперабельности между Python и JavaScript, какие были альтернативы и почему они не подошли. Так как проект экспериментальный, ещё остаётся простор для развития, например, многопоточность, которой в Pyodite пока нет.

Сейчас в Pyodite доступны библиотеки NumPy, Scipy, Matoplib, Pandas, но в будущем разработчики планируют интегрировать PyPI (основной репозиторий python-библиотек и программ), таким образом будут доступны ещё более 50000 пакетов.

#webassembly #datascience #python

https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser/

Сатья Гунасекеран из команды разработчиков v8 сегодня твитнул про, то что в новом релизе Chrome 75 была добавлена реализация предложения TC39 Numeric Separators (stage 3).

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

const million = 1_000_000;
const billion = 1_000_000_000;

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

#v8 #proposal #js

https://twitter.com/_gsathya/status/1120389255619055616?s=21

Самая большая новость прошедшего дня — выпуск Node.js 12. Команда разработчиков Node сделала обзор нововведений в статье "Introducing Node.js 12".

V8 был обновлён до версии 8.7.4. Теперь в Node есть поддержка асинхронных стек-трейсов, быстрый await, был ускорен парсинг JS. Была добавлена поддержка TLS 1.3, но из-за проблем с совместимостью по-умолчанию Node работает по TLS 1.2. Доступная для Node память теперь по умолчанию ограничена объёмом доступной памяти в системе, ранее доступная память по-умолчанию была ограничена 700Mb или 1400Mb для 32- и 64-разрядных систем соответственно (наследие браузеров). Дефолтный http-парсер теперь llhttp. Продолжается работа над упрощением работы с нативными модулями, написанными на языках C, C++, Rust и т.п. Node.js теперь запускается быстрее на 30% благодаря тому, что code-cache для встроенных модулей добавляется прямо в бинарный файл на этапе сборки. Продолжается работа над ESM-модулями (доступны за флагом `--experimental-modules`) и Worker Threads. Добавлен Diagnostic Reports, про который я писал несколько недель назад. Сборка теперь требует GCC6, Xcode 8 или Visual Studio 2017. Минимально поддерживаемая версия macOS 10.10 “Yosemite”, Windows 7, 2008 R2 или 2012 R2. Платформы, использующие glibc, для поддержки Node.js 12 должны включать минимальную версию glibc не ниже 2.17.

#nodejs #release #announcement

https://medium.com/@nodejs/introducing-node-js-12-76c41a1b3f3f

Разработчики Wasmer — рантайма для WebAssembly — представили пакетный менеджер WAPM.

WAPM расшифровывается как "WebAssembly Package Manager". Он состоит из двух частей: приложения командной строки wapm и реестра пакетов wapm.io. Цель нового пакетного менеджера — упрощение работы с модулями WebAssembly (запуск, распространение), поддержка разных видов ABI (WASI, Emnoscripten), простая интеграция с разными экосистемами языков (Python, PHP, Ruby, JavaScript). В разделе про NPM разработчики пишут про то, что WebAssembly на сервере — это совершенно новый сценарий использования технологии, поэтому при создании WAPM они решили отказаться от экосистемы JavaScript.

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

https://medium.com/wasmer/announcing-wapm-the-webassembly-package-manager-18d52fae0eea

#webassembly #package #announcement

Пару дней назад вышел релиз Chrome 74. Пит Лепаж сделал обзор новых возможностей, которые будут интересны разработчикам.

Были добавлены приватные поля классов:

class IncreasingCounter {
  // Private class field
  #privateValue = 0;
  get value() {
    return this.#privateValue;
  }
  increment() {
    this.#privateValue++;
  }
}

Появилась поддержка нового медиа-выражения, которое позволяет определить, отключены ли анимации во всей системе @media (prefers-reduced-motion: reduce). Это очень полезное выражение, так как некоторые пользователи могут испытывать симптомы укачивания на страницах с параллакс-эффектом, зумом и другими эффектами движения.

Добавлены события CSS-transitions (transitionrun, transitionstart, transitionend, transitioncancel) и обновлено API Feautre Policy, например, можно получить список всех доступных фич, с помощью document.featurePolicy.allowedFeatures().

В статье ещё есть много ссылок с подробным объяснением всех новых фич.

P.S. Если среди подписчиков канала кто-нибудь завтра идёт на Я.Субботник в Москве, где я буду рассказывать про кодмоды, подходите сказать привет, буду рад услышать ваш фидбек про канал.

#announcement #chrome #release

https://developers.google.com/web/updates/2019/04/nic74

Прочитал статью Эрика Эллиота 2017-го года "Getting to 10x (Results): What Any Developer Can Learn from the Best". В ней рассказывается про то, какими качествами обладают эффективные программисты.

Эрик опросил более 1000 программистов. Он попросил поделиться мнением о том, какими качествами обладали самые экстроординарные программисты, с которыми им приходилось работать (так называемые "десятикратники" - 10x). В топ-5 попали: эффективный поиск решения проблем, много умеет (skilled), учитель/ментор, отличный ученик, любит то, чем занимается. Затем в статье разбирается каждое качество и как их можно улучшить. Затронул тему менторства, приведя такой пример. Если два 1x становятся 5x, под менторством одного 10x, то они могут сделать работу десяти программистов уровня 1x, даже если 10x будет заниматься только менторством.

Ещё в опросе он попросил поделиться качествами самых худших программистов. В топ-5 попали: некомпетентность, высокомерие, неспособность к эффективной работе с другими, немотивированность и упрямство. Для каждого качества даются советы, что можно с ними сделать, чтобы эффективнее двигаться в сторону 10x.

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

#programming #psychology #productivity

https://medium.com/javanoscript-scene/getting-to-10x-results-what-any-developer-can-learn-from-the-best-54b6c296a5ef

Кент Си Доддс опубликовал у себя в блоге статью про то, как управлять состоянием приложения, не используя сторонние библиотеки, "Application State Management with React".

Кент в статье критикует Redux и пишет про то, что с использованием хука useState и Context можно организовать полноценное управление состоянием приложения в удобном виде и показывает это на примерах. Описанный подход можно реализовать с использованием обычных компонентов, но результат будет не так красив как с хуками. Разработчики React в последних версиях библиотеки благословили использование Context в обычных приложениях (а не только в библиотеках для управления состоянием), поэтому его можно использовать не опасаясь, что с обновлением React в вашем приложении что-то может сломаться.

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

#react #statemanagement #musings

https://kentcdodds.com/blog/application-state-management-with-react

Бюрк Холланд из Microsoft написал статью с объяснением причин, почему приложения, написанные на Node.js, обычно не запускают напрямую в продакшене "You should never ever run directly against Node.js in production. Maybe."

Если в приложении возникнет исключение, которое не будет обработано, Node.js упадёт (в статье следовало бы упомянуть про глобальную обработку uncaughtException, либо автор просто потроллил). Также не исключены ситуации, когда Node.js может упасть из-за других причин, например, если будет утечка памяти (про это почему-то автор статьи не рассказал). Если ничего не предпринимать, пользователи не смогут воспользоваться приложением. Поэтому необходимы средства, которые будут мониторить процесс ноды и в случае проблем заново запускать приложение. Для этого можно использовать pm2, systemd, kubernetes и т.п. В статье основной упор был сделан на pm2, но и про другие механизмы есть немного информации.

В общем, это неплохой обзор того, как работают с Node.js в продакшене. Статья написана с юмором — автор не стесняется шутить над собой.

#nodejs #pm2 #systemd

https://medium.freecodecamp.org/you-should-never-ever-run-directly-against-node-js-in-production-maybe-7fdfaed51ec6

Сегодня прочитал большую статью Пауло Ренато Де Атайдеса "Comparing JVM alternatives to JavaScript". Интересное чтиво, если вам хочется узнать, какие инструменты могут использовать Java-программисты, когда перед ними стоит задача создания SPA-приложения.

Пауло мотивирует свой подход использования Java-инструментов тем, что современный фронтенд очень сложный. Зачем тянуть тянуть в свой Java-проект ещё одну систему сборки, когда можно воспользоваться существующим тулчейном Java.

В статье рассматривается 6 проектов, которые позволяют написать фронтенд-приложение с использованием Java или JVM-based языков:

- GWT - Java-source-to-JS, серверный и клиентский фреймворк
- TeaVM - Java-bytecode-to-JS компилятор
- JSweet - Java-source-to-JS (и TypeScript) компилятор со своей экосистемой
- CheerpJ - Полная имплементация JVM для браузера (+ Swing)
- Vaadin Flow - Java-source-to-JS-source, серверный и клиентский фреймворк
- Bck2Brwsr - Java-bytecode-to-JS компилятор

В конце статьи есть сравнение реализации одного и того же простого приложения с использованием 5 проектов (Bck2Brwsr у автора не завёлся) и традиционного приложения на React. В замере производительности победил JSweet, в общем размере скачиваемых ресурсов победа опять за JSweet, число строк кода для простого компонента — Vaadin. Если вы не пишете код на Java (например, как я), то статью интересно прочитать только ради общего развития.

#js #java #jvm

https://renato.athaydes.com/posts/comparing-jvm-alternatives-to-js.html

Пару дней назад увидел в твиттере ссылку на статью 2011 года "Теоретический минимум для программиста".

Статья описывает то, что следует знать всем программистам. Пунктов больше 30: С++, компиляторы, ассемблер, мультитредность, аппаратное обеспечение, процессоры, дискретная математика, вычислимость, языки программирования, алгоритмы и комбинаторная оптимизация, численные методы, машинное обучение, теория информации и многое другое. У тех пунктов, где это имело смысл, есть список рекомендуемых авторов и тем для изучения. При этом есть уклон в C++ и Windows.

После прочтения статьи у меня был только один вопрос: "Что это было?". Сначала я думал, что это шутка, но потом прочитал комментарии и апдейты к статье и немного переварил информацию, и да, это не троллинг. Предполагается, что на изучение всех этих тем может потребоваться около 5 лет (или больше). Если вам повезло учиться в таком ВУЗе, где это всё было в программе, я могу вам только позавидовать. В общем, рекомендую эту статью к прочтению, чтобы составить себе план для развития на годы вперёд.

#programming #musings

https://sharpc.livejournal.com/67583.html