Структурная vs номинальная типизация это больше проблема проверки логической корректности программ, нежели вопрос времени исполнения. Опкодам в рантайме вообще без разницы по каким причинам их собрали вместе. К ООП это тоже имеет отношение поскольку-поскольку.
CA описывает архитектуру системы, а не отдельного компонента. Один из тезисов говорит про независимость от UI.
Бизнес логика по классике живёт на сервере, а ваше приложение под Android это тонкий клиент. Интересно, не является-ли такой клиент, в терминах данной архитектуры фактически тем самым UI, независимость от которого они хотят добиться?
Если ответ да, то изначальное желание затащить еще какую-то CA внутрь клиента, выглядит немного сюрриалистично.
Энтерпрайз, если дословно, это предприятие. В том самом, несколько архаичном для русского языка смысле, как некая активность, сопряженная с преодолением каких-то трудностей. Размер здесь не главное - с равным успехом это термин может использоваться как для небольших стартапов, так и корпораций-гигантов.
Enterprise Architecture это история про архитектуру бизнесов. Информационные системы и приложения лежат уровнем ниже. А в самом низу находятся различные технологии.
С тем же успехом можно сказать: смени пол и занимайся чем угодно. Смени планету и занимайся чем угодно. Смени... По факту людей, которые вложили годы своей жизни и труда в этот проект выставили за дверь. Причем это сделали их же коллеги. По большому счету, в решении ни кого не волнует ни отношение к происходящему, ни цели проводимых экспериментов.
Барбара кстати сама говорила, что немного в шоке от того, к чему пришла индустрия с подачи Дяди Боба - она в своей, в общем-то проходной, работе ни на какие такие откровения не претендовала, а сам принцип это просто цитата из более ранней работы её коллеги. Она использовала его скорее как гипотезу, нежели аксиому. В следующей публикации несколькими годами позже, с подачи своего науч.рука, принцип был оспорен. Но Мартина это ни сколько не смутило. Что их всех объединяло? - общая тусовка.
К сожалению это не так. Если команда не обладает нужной квалификацией, то тимлид будет вынужден сдасться если не при первом же продолбанном делайне, то при втором. А дальше их ожидает технический долг и все остальное по классике.
У меня был опыт работы в стартапе, где на первых этапах работали довольно дорогие ребята. Сделали с десяток разных вариаций продукта, естественно с соответствующим уровнем техлолга
Когда владельцы наконец-то поняли чего хотят, то наняли дешёвую команду, которая переписала по подготовленному нами ТЗ все практически с нуля. После чего первую команду разогнали. С точки зрения бизнеса это оптимальный вариант.
Дядя Боб является так же автором SOLID. Поэтому обосновать одно из его творений через другое это тавтология.
Там было время, когда бороться со сложностью пробовали путем усложнения структуры. Причем это предлагали ребята, у которых за плечами уже был кое-какой опыт разработки. Проблема в том, что до использования таких структур команда должна сначала дорасти. Если нет, то их внедрение делает только хуже. Все равно, что младенца сажать на двухколесный велосипед.
Архитектура конкретного проекта определяется не какими-то абстактными принципами, а вполне конкретными требованиями. В первую очередь - нефункциональными. Поэтому они в общем-то все всегда разные.
Кстати, часто эту байку рассказывают разработчики, не умеющие ни в одну из best practices. Стартапа через 3 месяца правда у них тоже не выходит, ровно по тем же причинам.
480Mbps это предельная скорость на сигнальном уровне. Реальная скорость передачи ваших данных - за минусом накладных расходов протокола и ошибок - заметно ниже. К тому же USB2 это half-duplex. Шина здесь общая для всех устройств, использование которой разбивается на фреймы в 1 милисекунду - т.е. частота 1kHz. Если на стороне приёмника нет буфера, то потери пакетов будут вполне заметны даже слух.
Архитектурные диаграммы это не программирование (как географическая карта это не сама местность). Они лишь демонстрируют некий взгляд, с определённой точки зрения, на определённые вещи, которые для кого-то кажутся существенными.
На flowchart диаграмме показывают интересующий нас сценарий, один из возможных. Но это не алгоритм. В том смысле, что он не обязан быть исчерпывающим. Наоборот, он но должен показывать только важное, отбросив все лишнее.
Графическое представление двухмерно, в то время как текст в общем-то одномерен. Выбор зависит от того, что вы хотите показать. Ваш вариант DSL имеет право на жизнь. Для BPMN есть, например, ещё такой https://www.bpmn-sketch-miner.ai/index.html, где баланс сдвинут в сторону естественности языка, нежели краткости записи.
Идея с реактивным интерпретатором состояния вполне рабочая для каких-то частных случаев. Например, некоторые системы биллига услуг или мониторинги работают именно по такому принципу. Но в пределе, поддержка систем правил здесь превращается в игру 80 уровня.
На самом деле приложений и оборудования для совместной работы тьма. Вот про незнание и неумение пользоваться - правда. Здесь же - жадность. Вообще, тема эффективной совместной работы на удаленке достойна отдельного изучения сама по себе.
Структурная vs номинальная типизация это больше проблема проверки логической корректности программ, нежели вопрос времени исполнения. Опкодам в рантайме вообще без разницы по каким причинам их собрали вместе. К ООП это тоже имеет отношение поскольку-поскольку.
Разница как между частной собственностью и общественной.
Примером языков с поздним связыванием являются скриптовые. Для решения проблем с производительностью в них достаточно успешно используется JIT.
Не появятся-ли тогда одноразовые редакторы с поодной статьёй, и учёки лишь для того, чтобы отписаться?
Все ещё называете вещи своими именами? А вы отважные, однако.
Нужна-ли здесь CA или может быть какая-то другая архитектура?
CA описывает архитектуру системы, а не отдельного компонента. Один из тезисов говорит про независимость от UI.
Бизнес логика по классике живёт на сервере, а ваше приложение под Android это тонкий клиент. Интересно, не является-ли такой клиент, в терминах данной архитектуры фактически тем самым UI, независимость от которого они хотят добиться?
Если ответ да, то изначальное желание затащить еще какую-то CA внутрь клиента, выглядит немного сюрриалистично.
Энтерпрайз, если дословно, это предприятие. В том самом, несколько архаичном для русского языка смысле, как некая активность, сопряженная с преодолением каких-то трудностей. Размер здесь не главное - с равным успехом это термин может использоваться как для небольших стартапов, так и корпораций-гигантов.
Enterprise Architecture это история про архитектуру бизнесов. Информационные системы и приложения лежат уровнем ниже. А в самом низу находятся различные технологии.
С тем же успехом можно сказать: смени пол и занимайся чем угодно. Смени планету и занимайся чем угодно. Смени... По факту людей, которые вложили годы своей жизни и труда в этот проект выставили за дверь. Причем это сделали их же коллеги. По большому счету, в решении ни кого не волнует ни отношение к происходящему, ни цели проводимых экспериментов.
Барбара кстати сама говорила, что немного в шоке от того, к чему пришла индустрия с подачи Дяди Боба - она в своей, в общем-то проходной, работе ни на какие такие откровения не претендовала, а сам принцип это просто цитата из более ранней работы её коллеги. Она использовала его скорее как гипотезу, нежели аксиому. В следующей публикации несколькими годами позже, с подачи своего науч.рука, принцип был оспорен. Но Мартина это ни сколько не смутило. Что их всех объединяло? - общая тусовка.
К сожалению это не так. Если команда не обладает нужной квалификацией, то тимлид будет вынужден сдасться если не при первом же продолбанном делайне, то при втором. А дальше их ожидает технический долг и все остальное по классике.
У меня был опыт работы в стартапе, где на первых этапах работали довольно дорогие ребята. Сделали с десяток разных вариаций продукта, естественно с соответствующим уровнем техлолга
Когда владельцы наконец-то поняли чего хотят, то наняли дешёвую команду, которая переписала по подготовленному нами ТЗ все практически с нуля. После чего первую команду разогнали. С точки зрения бизнеса это оптимальный вариант.
Дядя Боб является так же автором SOLID. Поэтому обосновать одно из его творений через другое это тавтология.
Там было время, когда бороться со сложностью пробовали путем усложнения структуры. Причем это предлагали ребята, у которых за плечами уже был кое-какой опыт разработки. Проблема в том, что до использования таких структур команда должна сначала дорасти. Если нет, то их внедрение делает только хуже. Все равно, что младенца сажать на двухколесный велосипед.
Архитектура конкретного проекта определяется не какими-то абстактными принципами, а вполне конкретными требованиями. В первую очередь - нефункциональными. Поэтому они в общем-то все всегда разные.
Кстати, часто эту байку рассказывают разработчики, не умеющие ни в одну из best practices. Стартапа через 3 месяца правда у них тоже не выходит, ровно по тем же причинам.
ну то есть вопрос софта и умения им пользоваться.
ну то есть вопрос оборудования.
480Mbps это предельная скорость на сигнальном уровне. Реальная скорость передачи ваших данных - за минусом накладных расходов протокола и ошибок - заметно ниже. К тому же USB2 это half-duplex. Шина здесь общая для всех устройств, использование которой разбивается на фреймы в 1 милисекунду - т.е. частота 1kHz. Если на стороне приёмника нет буфера, то потери пакетов будут вполне заметны даже слух.
Я в машине сменил несколько usb шнурков, соединяющих телефон с ГУ, пока Android Auto не перестал периодически отваливаться.
Архитектурные диаграммы это не программирование (как географическая карта это не сама местность). Они лишь демонстрируют некий взгляд, с определённой точки зрения, на определённые вещи, которые для кого-то кажутся существенными.
На flowchart диаграмме показывают интересующий нас сценарий, один из возможных. Но это не алгоритм. В том смысле, что он не обязан быть исчерпывающим. Наоборот, он но должен показывать только важное, отбросив все лишнее.
Графическое представление двухмерно, в то время как текст в общем-то одномерен. Выбор зависит от того, что вы хотите показать. Ваш вариант DSL имеет право на жизнь. Для BPMN есть, например, ещё такой https://www.bpmn-sketch-miner.ai/index.html, где баланс сдвинут в сторону естественности языка, нежели краткости записи.
Идея с реактивным интерпретатором состояния вполне рабочая для каких-то частных случаев. Например, некоторые системы биллига услуг или мониторинги работают именно по такому принципу. Но в пределе, поддержка систем правил здесь превращается в игру 80 уровня.
На самом деле приложений и оборудования для совместной работы тьма. Вот про незнание и неумение пользоваться - правда. Здесь же - жадность. Вообще, тема эффективной совместной работы на удаленке достойна отдельного изучения сама по себе.