Всегда удивляла стоимость простых шлюзов для MODBUS.
Как-то раз возникла необходимость удалённо мониторить некоторые контроллеры. Цена на простейшие преобразователи RTU (RS-485) -> TCP/IP для передачи данных на сервер просто сумасшедшая. 280$ за простейшую коробочку по ссылке из статьи. Отечественные производители не отстают.
В итоге купил Orange Pi, шнурок rs485-USB и опциональный USB-модем. На github'е нашёл утилиту для преобразования RTU -> TCP. Для сбора данных, дашборда (с мобильным приложением даже) и графиками поднял сервер с OpenHAB. От силы потратил 50$ + 10$ в месяц за простейший сервер с OpenHAB и VPN.
Нет, конечно, можно порассуждать о надёжности, безопасности и прочем. Но для простейшего кейса домашней автоматизации или мониторинга на этапе пуска-наладки какого-нибудь магазина/музея/школы этого решения хватает с горой. И колоссальная экономия.
Не, стрелочка в определении лямбд у меня нареканий не вызывает — это уже устоявшийся вариант.
Я про другое. Если взглянуть на этот код, то можно увидеть следующие «интересности»:
1) в классе (который назвали entity) есть const поля, а есть field. Казалось бы и то, и другое — поля класса, но к первым в коде обращаются через явное указание типа и двоеточия (Board::playerX), а ко второму через точку и this (this.cells). Нужно ли было делать такую разницу для данных в одной области видения?
2) стрелочка используется и для вызова методов класса, и для пайпинга. Нет, конечно, можно подвести эти вещи под один знаменатель, если представить что каждый метод неявно принимает параметр this (вроде того, как это сделано в Питоне). Но нужно ли?
3) потом мы видим, что через двоеточия мы по сути можем обращаемся к статическим const полям (game = game->makeAutoMove(Board::playerX, 0);). При этом само поле не помечено как static, хотя спецификатор этот есть (factory static createInitialBoard()). Кстати к этому статичному фабричному методу мы обращаемся уже через указание класса и собаку (field board: Board = Board@createInitialBoard();). Зачем надо было делать такое различие — не ясно.
Да, может всему этому есть объяснение и сложно судить по куску кода о языке. Но серьёзно, как отметили выше, ощущение такое, что ребята просто на ходу сочиняют разрозненные куски, а потом под это подведут кривую спецификацию. В то время как лучше было бы начать с другого конца.
Слабая и неуместная аналогия. Мне удобен код с синтаксисом, который вызывает минимальную когнитивную нагрузку — моя голова и так будет загружена при чтении/написании кода. Здесь синтаксис, похоже, впитал всё самое жуткое из мира c/c++, так ещё и сверху присыпал от себя.
Делаем простой и понятный язык для человека, поэтому добавляем побольше разномастных скобочек, стрелочек, знаков, двоеточий, точку с запятой в конце! *картинка с изображенеим genius*
В случае с объявлениями полиморфных типов, а уж тем более когда на типы налагаются ограничения классов типов, типа того, как здесь:
showVsPretty :: (Show a, PrettyPrint a) => a -> (String, String)
причина как раз вполне понятна. Название этого параметра не несёт никакой смысловой нагрузки и лишь выступает в качестве местозаполнителя. И вряд ли особая польза была бы, если это записывали как:
А вот почему внутри реализаций функций такая тяга к коротким переменным — загадка. Вероятно как и в случае с C причина кроется в возрасте и наследственности языка. Во времена становления Haskell и уж тем более во времена становления ML о читаемости кода ещё так не пеклись, и люди просто привыкли.
Но ведь если начинать рассуждать о зловредных приложениях, то почему мы не рассматриваем вариант с нехорошим браузером, в котором открываем наш consent screen? Это может быть и не chrome, и что-то косящее под chrome, но точно так же способное сфишить логин и пароль.
Вообще, если говорить про легитимность приложений, то инструмент, дающий возможность на сервере отделить своих от чужих был бы очень кстати. В частности, мы могли бы просто не открывать в WebView страницу ввода учётных данных вообще, если знаем, что инициатором запроса было не наше приложение (если, конечно, провайдером OAuth2 являемся мы сами). И, как я понимаю, это уже возможно через использование Attestation API (https://developer.android.com/training/safetynet/attestation).
Пара вопросов:
1) Зачем нам добиваться редиректа в приложение? Почему не подходит вариант открывать вебвью для прохождения веб-части авторизации в рамках самого своего приложения и просто доставать полученный authorization_code из него через интерфейс взаимодействия с вебвью? В этом случае браузер и приложение существуют рядом друг с другом и связываться с кастомными схемами просто не требуется.
2) Если обращение в Token Endpoint из вашего приложения проксировать через свой сервер, то хранение client_secret можно перенести на него. Равно как и избавиться от передачи authorization_code в приложение — можно сразу за счёт указания redirect_url передавать его на свой бэкенд и в ответ возвращать в браузер готовый access_token. Стоят ли все эти ухищрения в вашей статье того, чтобы сэкономить не так много времени на реализацию простого бэкенда для авторизации? Совсем server-less приложения это всё же редкость…
Смутные впечатления от этой истории… Боюсь, ваш опыт стартапа, который за несколько лет (поправьте, если не прав) остался на уровне 12-15 человек, не смог наладить процессы, CTO на уровне тимлида и уходит из-за того, что не смог наладить работу в своей зоне ответственности, — всё это далеко не показательно.
Скорее это история про человека, который понял, что руководство и управленческие решения в рамках компании — не для него. И ушёл тимлидом JS в корпоративного монстра.
Я сваггер только мельком смотрел. Может какие-то расширения к нему позволяют разбивать на части спеку.
В Blueprint API для этого есть что-то вроде «наследования» и «переопределения полей» и возможность инклудить одни документы в другие (но эта фича не из коробки). Если добавить соглашений наименования и разбиения на файлы, то в целом становится удобоваримо.
Поделюсь опытом использование таких тулз, а точнее Blueprint API.
Исходное состояние:
— продукты средней сложности
— API прежде всего для поддержки работы SPA и мобильных приложений, но также есть и межсервисное взаимодействие
— подход к разработке во многом выработался в духе «API-first» — API целенаправленно пишется постановщиками чуть ли не в первую очередь, согласовывается потребителями и нужен чуть ли не всем участникам: менеджерам, аналитикам, разработчикам, тестировщикам и иногда даже заказчикам или сторонним подрядчикам.
Долгое время всё это велось в confluence с не строгим шаблоном. Это вызывало следующее проблемы:
1. Отсутствие регламента и прозрачности в изменениях. Хотя круг тех, кто имел право внесения правок был ограничен, но всё же их было сложно контроллировать. Из-за этого возникали проблемы в духе «зачем вы это поменяли?», «а я не знал?», «в рамках чего было это изменение?» и прочее.
2. Отсутствие формализации описания там, где она была бы полезна. Достаточные ограничения на типы полей, примеры, единообразность, наглядность — всего этого часто не хватало. Легко можно было обнаружить, например, поле даты где-то в виде UNIX timestamp, а где-то в виде ISO8601 в одном и том же контексте.
3. Сложность использования для валидации или тестирования. Во многом вытекает из первых двух пунктов и обычных людских ошибок. Даже если каждый метод снабжался JSON-схемой и примерами запросов и ответов, то это не гарантировало того, что они актуальные и вообще правильные.
В качестве эксперимента разработчики начали использовать Blueprint API для описания сначала межсерверного взаимодействия. Зачастую там не было медиаторов в лице аналитиков, поэтому чтобы договариваться между собой они писали спеку в этом формате и шарили между собой. Позднее под доработку инструментария были выделены ресурсы и был эксперимент по попытке полноценного использования Blueprint API с самого начала нового проекта.
Как это выглядело.
По сути был почти полностью перенят процесс работы разработчиков и применён к работе аналитика над API. Основные моменты:
— Любое изменение только по задаче в Jira. К этому не надо относиться как к лишней бюрократии — это просто момент инициации работы. Даже какое-то подробное объяснение не требуется.
— Всё API — в git. Любое изменение проводится близко к git flow — именование веток, пулреквесты, мерджи в нужные ветки.
— В пулреквест в качестве ревьюверов доабвляются все заинтересованные лица со стороны разработки. После обсуждения, правок и апрувов ветка может быть смержена, а изменение в апи опубликовано.
— Весь тулчейн настроен в CI и работа аналитика сведена только к текстовому редактору и git'у.
Какие плюсы поимели:
— Процесс работы над API стал формализованным и прозрачным для всех.
— Blueprint предоставил достаточные средства для формализации описания. Да, он не идеальный и многих вещей в нём не хватает, а что-то было сделано криво. Но уже через несколько итераций выстроилась достаточно удобная схема ведения спецификации, организации файлов, соглашений по именованию сущностей внутри Blueprint API. Какие-то фичи были добавлены нами, какие-то баги поправлены.
— Минимизация ошибок из-за человеческого фактора. За счёт переиспользования сущностей внутри спецификации и автоматической генерации примеров, JSON-схемы и табличного описания полей, аналитик получал по сути конструктор методов, на выходе которого получалось удобное для всех заинтересованных лиц представление.
— Автоматизация и валидация. Тут очевидные применения всего этого добра — автогенерация интерфейсов к API (прежде всего у мобильщиков), валидация ответов при тестировании и прочее.
Какие проблемы возникли:
— Git flow это не только благо. Всё же документация это не код. В документации много изменяемых, но не формализуемых частей — текстовые описания методов, тексты ошибок, таблицы прав и прочее.
— Сложности синхронизации с командой и процессами разработки. Зачастую документация писалась сильно вперёд. Аналитик мог описывать функциональность на 1 и 2 релиза вперёд, а значит накидывать в git ветки, которые могли не скоро понадобится. А если в это вмешивались изъяны процесса разработки, то даже порядок будущего мерджа ветвей нельзя было предсказать. Вкупе с первым пунктом это вытекало либо в трудности при мердже (конфликты, cherry-picking, вот это всё), либо в сложности с определением какая часть документации актуальна, а какая уже ускакала вперёд.
— Повышенный overhead на работу аналитика. Раньше он просто редактировал страничку в confluence, а теперь он ломает голову над декомпозицией структур в Blueprint API, над ветками, пулреквестами и прочим. Можно сказать, что это повышает нижнюю планку для аналитика в проекте.
— Организационные моменты. Просмотр PR'ов по документации было правом, но не обязанностью заинтересованных лиц. Они тратили на это время, но это время не было их должностной обязанностью. В итоге со временем многие начали забивать на ревью.
— Ограничения Blueprint API. Да, многого не хватает. Да, редко, но были ситуации, когда API подстраивалось под возможности документирования хотелки. Да, это куча разрозненных файлов (в лучшем случае — насколько я знаю, в Swagger'е это просто диких размеров yaml), скреплённых придуманными вами соглашениями и правилами.
По итогам почти года использования этой штуки (ах да, я как раз в роли аналитика выступал) на проекте «с нуля» и до «n+1-ого релиза», могу сказать, что это был положительный опыт. Да, многое было сделано неудобно, но процесс создания и ведения API встал на некие рельсы, стал более выделенным. И все потребители оказались удовлетворены — менеджеры получили человечное и красивое опсиание, тестировщики получили почти исчерпывающие данные об ограничениях API, разработчики получили предсказуемость, полноту и возможность накручивания новых тулз поверх формального описания Blueprint API.
Но ведь можно пофилософствовать) Есть пространство возможных функций (которые можно включить в продукт), из которых путём выбора каких-то из них и определения их взаимодействия образуется функционал (итогового продукта). То есть вполне натягивается сова на глобус.
Я прекрасно понимаю роль разработчиков и сложности в их работе, поскольку я поработал и в этой роли, а также в роли менеджера, и в роли где-то между ними. И про поток, и про факапы, и про «вечнозанятых» бездельников, и про кошмарных недоменеджеров, и про планирование я тоже не по наслышке знаю.
Подход «вы же сэкономили на мне денег, но не поделились и продолжаете платить по рынку» не верен. Вам платят за ваши навыки исходя из стоимости, сформированной рынком. Если оплата вашего времени и навыков принимается за справедливую обеими сторонами, то уже никто никому ничего не должен. Всё остальное — плюшки. О каких бабках, которые вы не видели может идти речь? Может ещё все софтверные гиганты должны доплачивать каждому индусу на аутсорсе за то, что они на нём экономят? Тогда где экономия, простите?
Вы этим постом лишь подчёркиваете ту проблему, из-за которой многие компании не хотят работать с удалёнщиками. Даже если компания смогла осознать тот факт, что «8 часов + обед» не имеют никаких реальных оснований в IT, что большинство IT-специалистов способно работать откуда угодно лишь бы был интернет и ПК, что коммуникации возможно наладить на достаточном уровне и без личного присутствия (это пожалуй, второе по сложности), что людям можно доверять и оценивать по результатам (это первое по сложности), то вот проблему контролирования рисков вы
для них не решаете, а лишь ярко подчёркиваете. Они ваши слова увидят в виде «да, я могу пропасть среди дня, потому что я же дома работаю, а не в вашем офисе, значит у меня полная свобода, может я предупрежу, но не факт, тем более что у меня поток, так что могу и не ответить, даже если я тут». Удалённая работа это только работа «где хочу», а не «когда и как хочу».
Что до возвышения работы программиста над остальными в ИТ (и не только в ИТ), то нет, я и тут вас не поддержу. Да, это умственный труд, да, порой весьма напряженный. Но не надо думать, что мир сходится на программистах и они самые недооценённые и непонятые люди в сфере. И хороший менеджер, хороший дизайнер, хороший тестировщик, хороший девопс/админ, хороший аналитик тратят не меньше усилий, и точно так же учатся.
Да, именно так. Кроме того это очень простая штука и работает без нареканий.
Что до смарт тв, то если вас он полностью устраивает по качеству исполнения и функциям, то, вероятно, хромкаст вам не нужен. У меня вот, например, в какой-то момент гугл убрал поддержку приложения ютуба для смарт тв, и я остался без него.
Я бы, наверное, плюсанул, но всё же позиция немного эгоистична и в рамках проекта может быть вредна. Ситуации, когда возникает какой-то важный вопрос, который требует привлечения внимания разработчика и который гораздо важнее его «потоков», случаются. Факап, упавший сервер, критический баг… вариантов много и наверняка каждый сталкивался. И если в этот момент оказывается, что разработчик отъехал в магазин на пару часов и не известно, когда вернётся, то это плохо. Заводить на этот счёт баг в трекере, назначать совещание на завтра и сидеть на попе смирно — это верх бюрократии и неэффективности.
Нет, часы онлайн-присутствия и доступности должны быть обязательно оговорены. А о всяких «отъездах», «дневных снах», «купаниях в море тая» нужно предупреждать команду. Мир не сошёлся на программистах и в работу вовлечены многие люди. И работать так, чтобы не тормозить работу других — важный скилл.
Как-то раз возникла необходимость удалённо мониторить некоторые контроллеры. Цена на простейшие преобразователи RTU (RS-485) -> TCP/IP для передачи данных на сервер просто сумасшедшая. 280$ за простейшую коробочку по ссылке из статьи. Отечественные производители не отстают.
В итоге купил Orange Pi, шнурок rs485-USB и опциональный USB-модем. На github'е нашёл утилиту для преобразования RTU -> TCP. Для сбора данных, дашборда (с мобильным приложением даже) и графиками поднял сервер с OpenHAB. От силы потратил 50$ + 10$ в месяц за простейший сервер с OpenHAB и VPN.
Нет, конечно, можно порассуждать о надёжности, безопасности и прочем. Но для простейшего кейса домашней автоматизации или мониторинга на этапе пуска-наладки какого-нибудь магазина/музея/школы этого решения хватает с горой. И колоссальная экономия.
Я про другое. Если взглянуть на этот код, то можно увидеть следующие «интересности»:
1) в классе (который назвали entity) есть const поля, а есть field. Казалось бы и то, и другое — поля класса, но к первым в коде обращаются через явное указание типа и двоеточия (
Board::playerX), а ко второму через точку и this (this.cells). Нужно ли было делать такую разницу для данных в одной области видения?2) стрелочка используется и для вызова методов класса, и для пайпинга. Нет, конечно, можно подвести эти вещи под один знаменатель, если представить что каждый метод неявно принимает параметр this (вроде того, как это сделано в Питоне). Но нужно ли?
3) потом мы видим, что через двоеточия мы по сути можем обращаемся к статическим const полям (
game = game->makeAutoMove(Board::playerX, 0);). При этом само поле не помечено как static, хотя спецификатор этот есть (factory static createInitialBoard()). Кстати к этому статичному фабричному методу мы обращаемся уже через указание класса и собаку (field board: Board = Board@createInitialBoard();). Зачем надо было делать такое различие — не ясно.Да, может всему этому есть объяснение и сложно судить по куску кода о языке. Но серьёзно, как отметили выше, ощущение такое, что ребята просто на ходу сочиняют разрозненные куски, а потом под это подведут кривую спецификацию. В то время как лучше было бы начать с другого конца.
причина как раз вполне понятна. Название этого параметра не несёт никакой смысловой нагрузки и лишь выступает в качестве местозаполнителя. И вряд ли особая польза была бы, если это записывали как:
А вот почему внутри реализаций функций такая тяга к коротким переменным — загадка. Вероятно как и в случае с C причина кроется в возрасте и наследственности языка. Во времена становления Haskell и уж тем более во времена становления ML о читаемости кода ещё так не пеклись, и люди просто привыкли.
Вообще, если говорить про легитимность приложений, то инструмент, дающий возможность на сервере отделить своих от чужих был бы очень кстати. В частности, мы могли бы просто не открывать в WebView страницу ввода учётных данных вообще, если знаем, что инициатором запроса было не наше приложение (если, конечно, провайдером OAuth2 являемся мы сами). И, как я понимаю, это уже возможно через использование Attestation API (https://developer.android.com/training/safetynet/attestation).
1) Зачем нам добиваться редиректа в приложение? Почему не подходит вариант открывать вебвью для прохождения веб-части авторизации в рамках самого своего приложения и просто доставать полученный authorization_code из него через интерфейс взаимодействия с вебвью? В этом случае браузер и приложение существуют рядом друг с другом и связываться с кастомными схемами просто не требуется.
2) Если обращение в Token Endpoint из вашего приложения проксировать через свой сервер, то хранение client_secret можно перенести на него. Равно как и избавиться от передачи authorization_code в приложение — можно сразу за счёт указания redirect_url передавать его на свой бэкенд и в ответ возвращать в браузер готовый access_token. Стоят ли все эти ухищрения в вашей статье того, чтобы сэкономить не так много времени на реализацию простого бэкенда для авторизации? Совсем server-less приложения это всё же редкость…
Скорее это история про человека, который понял, что руководство и управленческие решения в рамках компании — не для него. И ушёл тимлидом JS в корпоративного монстра.
В Blueprint API для этого есть что-то вроде «наследования» и «переопределения полей» и возможность инклудить одни документы в другие (но эта фича не из коробки). Если добавить соглашений наименования и разбиения на файлы, то в целом становится удобоваримо.
Исходное состояние:
— продукты средней сложности
— API прежде всего для поддержки работы SPA и мобильных приложений, но также есть и межсервисное взаимодействие
— подход к разработке во многом выработался в духе «API-first» — API целенаправленно пишется постановщиками чуть ли не в первую очередь, согласовывается потребителями и нужен чуть ли не всем участникам: менеджерам, аналитикам, разработчикам, тестировщикам и иногда даже заказчикам или сторонним подрядчикам.
Долгое время всё это велось в confluence с не строгим шаблоном. Это вызывало следующее проблемы:
1. Отсутствие регламента и прозрачности в изменениях. Хотя круг тех, кто имел право внесения правок был ограничен, но всё же их было сложно контроллировать. Из-за этого возникали проблемы в духе «зачем вы это поменяли?», «а я не знал?», «в рамках чего было это изменение?» и прочее.
2. Отсутствие формализации описания там, где она была бы полезна. Достаточные ограничения на типы полей, примеры, единообразность, наглядность — всего этого часто не хватало. Легко можно было обнаружить, например, поле даты где-то в виде UNIX timestamp, а где-то в виде ISO8601 в одном и том же контексте.
3. Сложность использования для валидации или тестирования. Во многом вытекает из первых двух пунктов и обычных людских ошибок. Даже если каждый метод снабжался JSON-схемой и примерами запросов и ответов, то это не гарантировало того, что они актуальные и вообще правильные.
В качестве эксперимента разработчики начали использовать Blueprint API для описания сначала межсерверного взаимодействия. Зачастую там не было медиаторов в лице аналитиков, поэтому чтобы договариваться между собой они писали спеку в этом формате и шарили между собой. Позднее под доработку инструментария были выделены ресурсы и был эксперимент по попытке полноценного использования Blueprint API с самого начала нового проекта.
Как это выглядело.
По сути был почти полностью перенят процесс работы разработчиков и применён к работе аналитика над API. Основные моменты:
— Любое изменение только по задаче в Jira. К этому не надо относиться как к лишней бюрократии — это просто момент инициации работы. Даже какое-то подробное объяснение не требуется.
— Всё API — в git. Любое изменение проводится близко к git flow — именование веток, пулреквесты, мерджи в нужные ветки.
— В пулреквест в качестве ревьюверов доабвляются все заинтересованные лица со стороны разработки. После обсуждения, правок и апрувов ветка может быть смержена, а изменение в апи опубликовано.
— Весь тулчейн настроен в CI и работа аналитика сведена только к текстовому редактору и git'у.
Какие плюсы поимели:
— Процесс работы над API стал формализованным и прозрачным для всех.
— Blueprint предоставил достаточные средства для формализации описания. Да, он не идеальный и многих вещей в нём не хватает, а что-то было сделано криво. Но уже через несколько итераций выстроилась достаточно удобная схема ведения спецификации, организации файлов, соглашений по именованию сущностей внутри Blueprint API. Какие-то фичи были добавлены нами, какие-то баги поправлены.
— Минимизация ошибок из-за человеческого фактора. За счёт переиспользования сущностей внутри спецификации и автоматической генерации примеров, JSON-схемы и табличного описания полей, аналитик получал по сути конструктор методов, на выходе которого получалось удобное для всех заинтересованных лиц представление.
— Автоматизация и валидация. Тут очевидные применения всего этого добра — автогенерация интерфейсов к API (прежде всего у мобильщиков), валидация ответов при тестировании и прочее.
Какие проблемы возникли:
— Git flow это не только благо. Всё же документация это не код. В документации много изменяемых, но не формализуемых частей — текстовые описания методов, тексты ошибок, таблицы прав и прочее.
— Сложности синхронизации с командой и процессами разработки. Зачастую документация писалась сильно вперёд. Аналитик мог описывать функциональность на 1 и 2 релиза вперёд, а значит накидывать в git ветки, которые могли не скоро понадобится. А если в это вмешивались изъяны процесса разработки, то даже порядок будущего мерджа ветвей нельзя было предсказать. Вкупе с первым пунктом это вытекало либо в трудности при мердже (конфликты, cherry-picking, вот это всё), либо в сложности с определением какая часть документации актуальна, а какая уже ускакала вперёд.
— Повышенный overhead на работу аналитика. Раньше он просто редактировал страничку в confluence, а теперь он ломает голову над декомпозицией структур в Blueprint API, над ветками, пулреквестами и прочим. Можно сказать, что это повышает нижнюю планку для аналитика в проекте.
— Организационные моменты. Просмотр PR'ов по документации было правом, но не обязанностью заинтересованных лиц. Они тратили на это время, но это время не было их должностной обязанностью. В итоге со временем многие начали забивать на ревью.
— Ограничения Blueprint API. Да, многого не хватает. Да, редко, но были ситуации, когда API подстраивалось под возможности документирования хотелки. Да, это куча разрозненных файлов (в лучшем случае — насколько я знаю, в Swagger'е это просто диких размеров yaml), скреплённых придуманными вами соглашениями и правилами.
По итогам почти года использования этой штуки (ах да, я как раз в роли аналитика выступал) на проекте «с нуля» и до «n+1-ого релиза», могу сказать, что это был положительный опыт. Да, многое было сделано неудобно, но процесс создания и ведения API встал на некие рельсы, стал более выделенным. И все потребители оказались удовлетворены — менеджеры получили человечное и красивое опсиание, тестировщики получили почти исчерпывающие данные об ограничениях API, разработчики получили предсказуемость, полноту и возможность накручивания новых тулз поверх формального описания Blueprint API.
Подход «вы же сэкономили на мне денег, но не поделились и продолжаете платить по рынку» не верен. Вам платят за ваши навыки исходя из стоимости, сформированной рынком. Если оплата вашего времени и навыков принимается за справедливую обеими сторонами, то уже никто никому ничего не должен. Всё остальное — плюшки. О каких бабках, которые вы не видели может идти речь? Может ещё все софтверные гиганты должны доплачивать каждому индусу на аутсорсе за то, что они на нём экономят? Тогда где экономия, простите?
Вы этим постом лишь подчёркиваете ту проблему, из-за которой многие компании не хотят работать с удалёнщиками. Даже если компания смогла осознать тот факт, что «8 часов + обед» не имеют никаких реальных оснований в IT, что большинство IT-специалистов способно работать откуда угодно лишь бы был интернет и ПК, что коммуникации возможно наладить на достаточном уровне и без личного присутствия (это пожалуй, второе по сложности), что людям можно доверять и оценивать по результатам (это первое по сложности), то вот проблему контролирования рисков вы
для них не решаете, а лишь ярко подчёркиваете. Они ваши слова увидят в виде «да, я могу пропасть среди дня, потому что я же дома работаю, а не в вашем офисе, значит у меня полная свобода, может я предупрежу, но не факт, тем более что у меня поток, так что могу и не ответить, даже если я тут». Удалённая работа это только работа «где хочу», а не «когда и как хочу».
Что до возвышения работы программиста над остальными в ИТ (и не только в ИТ), то нет, я и тут вас не поддержу. Да, это умственный труд, да, порой весьма напряженный. Но не надо думать, что мир сходится на программистах и они самые недооценённые и непонятые люди в сфере. И хороший менеджер, хороший дизайнер, хороший тестировщик, хороший девопс/админ, хороший аналитик тратят не меньше усилий, и точно так же учатся.
Что до смарт тв, то если вас он полностью устраивает по качеству исполнения и функциям, то, вероятно, хромкаст вам не нужен. У меня вот, например, в какой-то момент гугл убрал поддержку приложения ютуба для смарт тв, и я остался без него.
Нет, часы онлайн-присутствия и доступности должны быть обязательно оговорены. А о всяких «отъездах», «дневных снах», «купаниях в море тая» нужно предупреждать команду. Мир не сошёлся на программистах и в работу вовлечены многие люди. И работать так, чтобы не тормозить работу других — важный скилл.