Handling errors in gRPC

Вчера прочитал один пост на тему обработки ошибок в gRPC. На мой взгляд передавать вместе с ошибкой стэк - это уже перебор: сообщение, статус, может быть какой-нибудь код, прочие дополнительные поля (например Retry-After), но не стэк. По-моему стэк должен быть залогирован там где произошла ошибка, после чего его миссия завершена. Кроме того я не согласен с автором на предмет того, каким образом передавать все эти дополнительные поля: идея передавать ошибку вместе с данными (или вместо данных) мне не нравится, думаю метаданные здесь подойдут лучше.

Going to gRPC

Недавно начал инвестигировать gRPC + Protocol Buffers. В Node.js профит сомнительный, по крайней мере до тех пор пока не появится стабильный http/2 (без флага --expose-http2), тем не менее никто не мешает уже сейчас использовать другую платформу, я бы предпочел Go. Первое знакомство с Node.js прошло без проблем, а вот с Go пришлось повозиться: скачать C++ реализацию protobuf, сбилдить protoc.exe с помощью CMake, после чего сбилдить protoc-gen-go (и не забыть добавить в переменную окружения PATH путь к protoc.exe).

Goodbye, Postman!

Позавчера я познакомился с расширением для Visual Studio Code по имени REST Client и понял что у него есть все шансы заменить в моем арсенале Postman - изначально приложение Google Chrome, а теперь и нативное приложение, которое я использую в процессе разработки в качестве REST-клиента на протяжении последних нескольких лет. Профит: 1) выполняем запросы не покидая Visual Studio Code 2) сохраняем запросы в текстовых файлах (.http или .rest) 3) на один Electron меньшe

TypeScript Declaration Files

На HolyJS 2017 Piter я спросил у Дугласа Крокфорда что он думает по поводу TypeScript, и заодно сообщил ему что я обратил внимание на TypeScript с его подачи, на что он мне ответил, что если ты хочешь писать на C# - пиши на C#. Но я пишу серверный код на ES6, и почему не использовать вместе с линтером (ESLint, или если угодно JSHint от самого Дугласа Крокфорда) еще один инструмент, который дает нам IntelliSense, проверку типов, и в результате позволяет всей команде двигаться быстрее? К сожалению этот вопрос остался без ответа потому что Дуглас Крокфорд ...

HolyJS 2017 Piter

И я там был, мед пиво пил... нет, меда не было, был горячий шоколад, интересные доклады, не менее интересные обсуждения в дискуссионных зонах, и в качестве суперзвезды один из самых известных персонажей в мире JavaScript ... Douglas Crockford !!! Понравились доклады про типизацию: Илья Климов снова пел про Flow + Reason, следом к нему присоединился Patrick Stapfer, ребята из Wrike попытались сравнить Dart с TypeScript и ES2017. После второй дозы фейсбуковского хайпа я подошел к уважаемому Douglas Crockford и задал ему вопрос:

Google Chrome Bookmarks

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

TypeScript checkJs

На прошлой неделе была анонсирована версия TypeScript 2.3, в которой появилась возможность выполнять проверку типов "vanilla JS" файлов. Я потрясен! Теперь можно не только линтить, но и тайп-чекить, что в перспективе может позволить создавать еще более надежный код. И для этого совсем не обязательно писать на TypeScript. Достаточно при запуске компилятора использовать следующие опции: --noEmit, --allowJs и --checkJs, или как вариант можно добавить поля { noEmit: true, allowJs: true } в tsconfig.json + комментарий // @ts-check в самое начало JavaScript файла.

TypeScript Curry

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

VS Code JavaScript Intellisense

Не смотря на то, что с TypeScript я познакомился еще до появления на свет Visual Studio Code, мне еще ни разу не довелось использовать его в повседневной работе. Пишу на ES6 (Node.js), стараюсь документировать код с помощью jsdoc, но зачастую одних только комментов не хватает для того, чтобы intellisense подсказал мне с чем я имею дело в текущий момент времени, а иногда очень хотелось бы (и не мне одному), поэтому я решил попробовать миксовать declaration files с "vanilla JS".

Safely Accessing Deeply Nested Values In JavaScript

Весь этот функциональный хайп начинает действовать на нервы, честное слово. На днях прочитал пару постов о вариантах реализации доступа к свойствам объекта в JavaScript, и у меня возникли вопросы к авторам по коду. К примеру зачем в случае отсутствия свойства объекта возвращать null, тогда как "канонически" это undefined? Для того чтобы притянуть это за уши к Maybe? Или какого коллайдера вместо цикла использовать функцию высшего порядка? Для "красоты"? Супер полезная абстракция, согласен, зачастую очень даже уместная, но это не тот случай.