Trying Clean Architecture on Typescript

В моей библиотеке книги Роберта Мартина занимают почетное место - на рабочем столе, рядом с публикациями Мартина Фаулера, Стива Макконнелла и еще нескольких менее известных авторов. Отзывы о его последней книге, Clean Architecture, неоднозначны: кому-то не хватает деталей, а кто-то просто пытается реализовать свое понимание усвоенного материала на своей любимой платформе. Недавно мне попалась на глаза одна такая попытка на Go, потом еще одна, потом еще одна на Python, и я решил попробовать написать что-то подобное на TypeScript.

Sending binary with Node.js via gRPC

Protocol Buffers - протокол сериализации структурированных данных. Нельзя просто взять и скомпилировать: rpc Send (stream bytes) returns (void);, нужно обязательно использовать структуры: rpc Send (stream File) returns (Empty);. В Node.js самый простой способ отправить файл, или любой другой Readable Stream - спайпить его с Writable Stream. Для того чтобы отправить файл через gRPC можно пребразовать поток бинарных данных в поток структурированных данных и наоборот с помощью Transform Stream, как-то так: на клиенте Readable Stream -> Transform Stream -> ClientReadableStream, на сервере ServerReadableStream -> Transform Stream -> Writable Stream.

Node.js gRPC defaults

Вчера обновил grpc-node и после запуска приложения получил предупреждение: 'DeprecationWarning: grpc.load: Use the @grpc/proto-loader module with grpc.loadPackageDefinition instead'. В процессе выяснения причины оказалось что grpc-protobufjs среди прочих решает вопрос с дефолтными значениями: по умолчанию отсутствие значения интерпретируется как отсутствие значения, т.е. полю не присваивается дефолтное значение. Конец моим страданиям и разочарованиям, теперь можно избавляться от костылей. Кроме того исследование изменений в gRPC позволило мне ответить еще на один на вопрос: как передать метаданные с сервера на клиента без использования ошибки.

WTF with errors in gRPC?

Недавно мне задали вопрос: для чего нужен package-lock.json, я ответил: для того же для чего и npm-shrinkwrap.json - чтобы не было мучительно больно. Вчера обнаружил удивительный диссонанс между версиями 1.8.0 и 1.8.4 модуля gRPC, а именно изменения в процессе создания ошибки, вот от кого никак не ожидал. К примеру, если в версии 1.8.0 ошибка с сообщением 'Invalid name' на сервере предсказуемо превращалась в ошибку в таким же сообщением на клиенте, то в версии 1.8.4 на клиенте то же сообщение об ошибке превращается в '2 UNKNOWN: Invalid name'. WTF?

JavaScript interview question

"Посетителю должно быть неудобно. Посетитель должен быть смешон. Иначе, какое от него удовольствие?", - братья Стругацкие, "Обитаемый остров". Сегодня познакомился с задачей, которую можно использовать на собеседовании по JavaScript если вдруг появилось желание "сделать посетителю неудобно". Или собеседник знает в чем подвох, что маловероятно (вряд ли кто-либо использует подобные приемы на практике), или есть шанс получить процесс решения, который может кое-что рассказать о собеседнике. Не пытайтесь повторить это дома.

Going to gRPC. Bidirectional streaming

В процессе проектирования одного приложения в какой-то момент я решил, что один сервис должен иметь возможность итерировать по коллекции, за которую отвечает другой. Не просто получать данные в виде списка или потока, а иметь возможность перечислять элементы коллекции по одному, а также прерывать процесс итерации. Не смотря на то, что в итоге ответственность за прерывание процесса досталась итератору, что позволило решению остаться в пределах парадигмы request-response, мне захотелось посмотреть как могло бы выглядеть решение на bidirectional streaming RPC.

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).

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? Или какого коллайдера вместо цикла использовать функцию высшего порядка? Для "красоты"? Супер полезная абстракция, согласен, зачастую очень даже уместная, но это не тот случай.

JavaScript Execution Optimization

Небольшой этюд на тему оптимизации в V8, или сказ о том как мономорфизм влечет за собой оптимизацию, а полиморфизм (не путаем с subtype или parametric polymorphism), в свою очередь, деоптимизацию JavaScript функций, с картинками. По мотивам публикаций Benedikt Meurer и Вячеслава Егорова. Для того, чтобы по-взрослому разобраться в том, как оптимизировать JavaScript код, рекомендую почитать публикации уважаемых разработчиков, упомянутых выше, а также документацию V8. Дисклеймер: "Premature optimization is the root of all evil", - Donald Knuth.

Node.js Event Loop

А знаете ли вы, что process.nextTick и Promise используют отдельный Event Loop внутри Event Loop, а fs, crypto.randomBytes и crypto.pbkdf2, dns.lookup, http.get и http.request (вызванные с именем хоста, а не ip-адресом, и поэтому вызывающие dns.lookup), а также C/C++ аддоны, которые используют libuv thread pool, создают свои собственные потоки (по умолчанию до 4, максимум до 128), и таким образом Node.js Event Loop не совсем Single Threaded, а скорее Mostly Single Threaded?

JavaScript Persons

В мире JavaScript немало "весовых" персон которые так или иначе оказывают влияние на "рядовых" JavaScript разработчиков. На меня больше всего повлияли трое: Douglas Crockford, Reginald Braithwaite и Eric Elliott. Знакомьтесь: 1) Douglas Crockford: сайт, профиль в Google+, плейлисты на Youtube, 2) Reginald Braithwaite: сайт, профиль в Twitter, книги, 3) Eric Elliott: профиль в Medium, профиль в Twitter, коллекция ссылок по теме JavaScript.

Что еще почитать по JavaScript

С момента предыдущей публикации по теме мне удалось прочитать следующую литературу по JavaScript: Functional Programming in JavaScript by Luis Atencio, Functional Programming in JavaScript by Dan Mantyla и Professor Frisby's Mostly Adequate Guide to Functional Programming. Кроме того: High Performance Browser Networking - "must read" мануал для веб-разработчика, Out of the Tar Pit - вкуснейшая статья на холиварную тему "imperative vs. declarative" и Designing Data-Intensive Applications - я прочитал так называемый "Early Release" т.к. книга пока еще не издана, когда выйдет в тираж обязательно познакомлюсь с материалом не вошедшим в "раннее издание".

VS Code Node.js Debugging

В VS Code есть встроенный дебаггер, но не смотря на то, что я использую этот инструмент уже давно, Node.js код я дебажу с помощью node-inspector. Сначала запускаю дебаггер: node-inspector --web-port 8088 --save-live-edit true --preload false, затем приложение: node --debug app или node --debug-brk app (по ситуации), после чего открываю в браузере интерфейс дебаггера по адресу http://127.0.0.1:8088/?ws=127.0.0.1:8088&port=5858. Расскажу как я пытался перейти на встроенный дебаггер VS Code.