Накопление знаний
Гуманитарно-политические заметки

Я тайландский программист

Полностью фраза звучит так

"Я тайландский программист, решаю проблему тайландского бизнесмена совместно с командой тайландских программистов... Почему я должен писать код на английском ? Какого рожна ?"

То есть оказывается не одни 1С специалисты такие, как я и писал в своё время на Хабре, скорость разработки под бизнес-требования сформулированных на русском, будет быстрей на русском языке. Английский язык тут только помеха и дополнительные затраты.

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

Но погодите - из теории компиляторов мы знаем, что исходный код, это не магический текст, а просто AST (абстрактное синтаксическое дерево). То есть вполне себе объектная модель доступная для алгоритмов.

Сервисы типа crowdin, transifex и zatana приучили нас к тому, что вообще-то i18n и l10n тоже возможны к автоматизации.

А наличие в SonarQube автоматической проверки правописания на любом языке позволяет проверять имена процедур и переменных.

Про машинный перевод средствами Yandex, Google тоже не стоит забывать. То есть платформа oscript.io или её аналоги вполне можно (вместе с библиотеками) попробовать оттраслировать в любой язык. Инженерные практики для этого есть

сервис gramarly может помочь в части коммуникаций, но вот исходный код должен быть транслируемый в обе стороны... Ну а движок пусть будет на английском, хотя лично я бы предпочёл Эсперанто.

Кстати об интеграции


Учесть всю логику интеграции невозможно… Точнее её невозможно задокументировать и стабилизировать. Интеграционные инструменты и программные интерфейсы постоянно изменяются, а если не изменяются, то рано или поздно продукты к неизменяемым API выпиливают.
Способствует этому в том числе и Agile с инженерными практиками. Релизы каждый в погоне за рынками сбыта и с целью отдачи технических долгов приводят к тому, что пока ты интегрировал API v2 продукта 1 c API v3 продукта 2, оба эти продукта уже поменяли API и старые методы которые ты надеялся использовать признали “устаревшими”. Хуже в банках - они еще только согласуют “контракты данных”, а контракты “уже протухли”.
Собственно, на мой взгляд, как ответ на вышеуказанную проблему автор который в начале 2000-ных активно “топил за ESB’ы”, в начале 10-тых начал активно “топить за микросервисы”. А IBM даже приобрёл strongloop https://strongloop.com/. Дескать мы не будем навязывать контракты - пусть эти микросервисы/микрокоманды делают свои нетленные microapi и сами там как-то договариваются, а мы им ничего навязывать не будем.
Однако концепция микросервисов из микропродуктов никак не отвечала на вопрос трансформации данных, и что самое главное никак не позволяло быть “слабосвязанными” этим самым микросервисам.
То есть логику трансформации данных кто-то должен реализовывать, правила маршрутизации в условиях слабой связанности систем должен кто-то кодировать. Из концепции концепции микросервисов плавно вытекало, что необходимы
  • микротрансформаторы
  • микрослабосвязыватели
То есть продукты которые будут хорошо делать трансформацию и хранение данных между вызовами, пока системы будут по какой то причине недоступны.
Опять же, на мой взгляд, так родились zappier и ему подобные сервисы (с очень демократичными ценами).

Дополнительные проблемы

Микросервисы, микросервисами, но в организациях вообще-то принято интеграционные потоки данных хранить у себя “в периметре”, а не в облаках. Помимо всего прочего любой грамотный “инфраструктурщик” напомнит вам про горизонтальное-вертикальное масштабирование и вообще отказоустойчивость, а также высокую доступность (про мониторинг и анализ аварий даже заикаться не будем).
А также - напомним, что визуальное проектирование информационные потоков которое мы знаем еще из UML (http://plantuml.com/sequence-diagram 4) имеет один плюс: оно позволяет выявить коллизии еще на этапе проектирования.
Чтобы сильно вас не погружать в проблематику, давайте зафиксируем, что по состоянию на 2017 год, с учетом наших знаний о проблемах поколений идеальное решение для интеграции должно позволять
  • кодировать логику интеграции
  • иметь визуальное представление
  • поддерживать микросервисность в части
  • создания/кодирования
  • тестирования
  • развертывания
  • обеспечивать высокую скорость проверки гипотез

Собственно отсюда и родились AWS Lambda и тот самый Balerina Lang - https://medium.com/ballerina-techblog

Исходный посыл подсмотрен вот тут https://medium.com/ballerinalang/ballerina-thinking-about-names-why-restrict-to-english-c1f9803e827