К сожалению это не так. Если команда не обладает нужной квалификацией, то тимлид будет вынужден сдасться если не при первом же продолбанном делайне, то при втором. А дальше их ожидает технический долг и все остальное по классике.
У меня был опыт работы в стартапе, где на первых этапах работали довольно дорогие ребята. Сделали с десяток разных вариаций продукта, естественно с соответствующим уровнем техлолга
Когда владельцы наконец-то поняли чего хотят, то наняли дешёвую команду, которая переписала по подготовленному нами ТЗ все практически с нуля. После чего первую команду разогнали. С точки зрения бизнеса это оптимальный вариант.
Дядя Боб является так же автором SOLID. Поэтому обосновать одно из его творений через другое это тавтология.
Там было время, когда бороться со сложностью пробовали путем усложнения структуры. Причем это предлагали ребята, у которых за плечами уже был кое-какой опыт разработки. Проблема в том, что до использования таких структур команда должна сначала дорасти. Если нет, то их внедрение делает только хуже. Все равно, что младенца сажать на двухколесный велосипед.
Архитектура конкретного проекта определяется не какими-то абстактными принципами, а вполне конкретными требованиями. В первую очередь - нефункциональными. Поэтому они в общем-то все всегда разные.
Кстати, часто эту байку рассказывают разработчики, не умеющие ни в одну из best practices. Стартапа через 3 месяца правда у них тоже не выходит, ровно по тем же причинам.
480Mbps это предельная скорость на сигнальном уровне. Реальная скорость передачи ваших данных - за минусом накладных расходов протокола и ошибок - заметно ниже. К тому же USB2 это half-duplex. Шина здесь общая для всех устройств, использование которой разбивается на фреймы в 1 милисекунду - т.е. частота 1kHz. Если на стороне приёмника нет буфера, то потери пакетов будут вполне заметны даже слух.
Архитектурные диаграммы это не программирование (как географическая карта это не сама местность). Они лишь демонстрируют некий взгляд, с определённой точки зрения, на определённые вещи, которые для кого-то кажутся существенными.
На flowchart диаграмме показывают интересующий нас сценарий, один из возможных. Но это не алгоритм. В том смысле, что он не обязан быть исчерпывающим. Наоборот, он но должен показывать только важное, отбросив все лишнее.
Графическое представление двухмерно, в то время как текст в общем-то одномерен. Выбор зависит от того, что вы хотите показать. Ваш вариант DSL имеет право на жизнь. Для BPMN есть, например, ещё такой https://www.bpmn-sketch-miner.ai/index.html, где баланс сдвинут в сторону естественности языка, нежели краткости записи.
Идея с реактивным интерпретатором состояния вполне рабочая для каких-то частных случаев. Например, некоторые системы биллига услуг или мониторинги работают именно по такому принципу. Но в пределе, поддержка систем правил здесь превращается в игру 80 уровня.
На самом деле приложений и оборудования для совместной работы тьма. Вот про незнание и неумение пользоваться - правда. Здесь же - жадность. Вообще, тема эффективной совместной работы на удаленке достойна отдельного изучения сама по себе.
Единственное, dd не стоит использовать когда диск примонтирован. Он работает ниже уровня файловой системы и если там что-то меняется за время копирования, то копия будет неконсистентной. Как вариант - клонировать снэпшот.
К агрегатам стоит относиться как к некому API, которое реализует композицию нескольких объектов - позволяя работать с ними как с одним целым. Это возможно когда все они находятся во владении одного Bounded Context. Например, кучу шестерёнкок можно воспринимать как часть агрегата, лишь когда они собраны внутри конкретной коробки передач. Если же они разбросаны по складам разных поставщиков, то это не агрегат. Возможной бизнес сущностью в такой ситуации может быть заказ-наряд - но только здесь понятие согласованости будет совсем иного рода, нежели передача вращения от одного вала другому. Хотя если все же попытаться сделать последнее, то мы в самом деле получим по истине эпическую сагу.
Тактические паттерны все же задуманы для использования в пределах только одного Bounded Contex - когда нужно согласовать между собой несколько принадлежащих ему агрегатов. В случае микросервисов, речь обычно идёт о согласовании данных в одной базе. Когда речь заходит о согласовании данных в разных базах - у которых разные владельцы - то про тактические паттерны говорить нет смысла.
Пытаться оркестрировать деньги на счетах, которым вы не владеете и создавать контексты, которые в теории не помещается в микросервис - все это выглядит как движение против шерсти.
Контрактное программирование помогает избежать части логических ошибок. Но это только один из классов. Например, у нас недавно была ситуация, когда приложение, будучи запущенным на процессорах Intel и на AMD, в математике с плавающей точкой выдавало разные результаты. Проблема оказалась в сторонней библиотеке, где авторы перемудрили с ассемблерными оптимизациями. В общем полезно и то и другое - нужно лишь найти правильный баланс.
задачки для стажёров, которые задаются в шуточно-игровом стиле (например, определить, где путешествовал коллега в отпуске), но для решения требуют выполнения операций в боевых системах и сервисах, например, поиск какой-либо информации в SIEM.
В приличном обществе за такие шутки можно отправиться в путешествие с мешком денег всем отделом. Или у вас регламенты доступа в SIEM тоже писали стажеры?
Фактически они получили возможность хранить все свои документы в одном месте, предоставляя и контролируя к ним доступ различным заинтересованным лицам и организациям. По сути такая же консолидация перс.данных как на тех же Госуслугах, только п(р)оданная населению под соусом либеральных ценностей.
Звучит как призыв вернуться обратно в детство. К сожалению или счастью Интернет теперь вырос и повзрослел. Сейчас он уже другой и с другими взрослыми проблемами: деньги, войны, преступность, политика - назад в подгузники дороги нет. 35 лет кризис среднего возраста?
Microsoft сейчас предлагают думаю лучшие решения для суверенных интернетов на глобальном рынке. Как в техническом, так и юридическом плане - чтобы вы случайно не нарушили чьи-то законы. Но составление контрактов это отдельное искусство.
Это правда, но это ещё не вся правда. Капитал боится отсутствия прибыли или слишком маленькой прибыли, как природа боится пустоты. Но раз имеется в наличии достаточная прибыль, капитал становится смелым. Обеспечьте 10 процентов, и капитал согласен на всякое применение, при 20 процентах он становится оживлённым, при 50 процентах положительно готов сломать себе голову, при 100 процентах он попирает все человеческие законы, при 300 процентах нет такого преступления, на которое он не рискнул бы, хотя бы под страхом виселицы. Если шум и брань приносят прибыль, капитал станет способствовать тому и другому.
В общем если у вас кого-то деньги не мотивируют, то речь наверняка идёт о каких-то грошах.
К сожалению это не так. Если команда не обладает нужной квалификацией, то тимлид будет вынужден сдасться если не при первом же продолбанном делайне, то при втором. А дальше их ожидает технический долг и все остальное по классике.
У меня был опыт работы в стартапе, где на первых этапах работали довольно дорогие ребята. Сделали с десяток разных вариаций продукта, естественно с соответствующим уровнем техлолга
Когда владельцы наконец-то поняли чего хотят, то наняли дешёвую команду, которая переписала по подготовленному нами ТЗ все практически с нуля. После чего первую команду разогнали. С точки зрения бизнеса это оптимальный вариант.
Дядя Боб является так же автором 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 уровня.
На самом деле приложений и оборудования для совместной работы тьма. Вот про незнание и неумение пользоваться - правда. Здесь же - жадность. Вообще, тема эффективной совместной работы на удаленке достойна отдельного изучения сама по себе.
Хорошо подготовиться, встретиться и за пару дней совершить научное открытие? Мне кажется здесь так не работает.
Единственное, dd не стоит использовать когда диск примонтирован. Он работает ниже уровня файловой системы и если там что-то меняется за время копирования, то копия будет неконсистентной. Как вариант - клонировать снэпшот.
Интересная статья, навела вот на какие мысли.
К агрегатам стоит относиться как к некому API, которое реализует композицию нескольких объектов - позволяя работать с ними как с одним целым. Это возможно когда все они находятся во владении одного Bounded Context. Например, кучу шестерёнкок можно воспринимать как часть агрегата, лишь когда они собраны внутри конкретной коробки передач. Если же они разбросаны по складам разных поставщиков, то это не агрегат. Возможной бизнес сущностью в такой ситуации может быть заказ-наряд - но только здесь понятие согласованости будет совсем иного рода, нежели передача вращения от одного вала другому. Хотя если все же попытаться сделать последнее, то мы в самом деле получим по истине эпическую сагу.
Тактические паттерны все же задуманы для использования в пределах только одного Bounded Contex - когда нужно согласовать между собой несколько принадлежащих ему агрегатов. В случае микросервисов, речь обычно идёт о согласовании данных в одной базе. Когда речь заходит о согласовании данных в разных базах - у которых разные владельцы - то про тактические паттерны говорить нет смысла.
Пытаться оркестрировать деньги на счетах, которым вы не владеете и создавать контексты, которые в теории не помещается в микросервис - все это выглядит как движение против шерсти.
Контрактное программирование помогает избежать части логических ошибок. Но это только один из классов. Например, у нас недавно была ситуация, когда приложение, будучи запущенным на процессорах Intel и на AMD, в математике с плавающей точкой выдавало разные результаты. Проблема оказалась в сторонней библиотеке, где авторы перемудрили с ассемблерными оптимизациями. В общем полезно и то и другое - нужно лишь найти правильный баланс.
В приличном обществе за такие шутки можно отправиться в путешествие с мешком денег всем отделом. Или у вас регламенты доступа в SIEM тоже писали стажеры?
Фактически они получили возможность хранить все свои документы в одном месте, предоставляя и контролируя к ним доступ различным заинтересованным лицам и организациям. По сути такая же консолидация перс.данных как на тех же Госуслугах, только п(р)оданная населению под соусом либеральных ценностей.
Звучит как призыв вернуться обратно в детство. К сожалению или счастью Интернет теперь вырос и повзрослел. Сейчас он уже другой и с другими взрослыми проблемами: деньги, войны, преступность, политика - назад в подгузники дороги нет. 35 лет кризис среднего возраста?
Наверное, будет лучше сказать: жители - Фландрия это часть Бельгии.
Microsoft сейчас предлагают думаю лучшие решения для суверенных интернетов на глобальном рынке. Как в техническом, так и юридическом плане - чтобы вы случайно не нарушили чьи-то законы. Но составление контрактов это отдельное искусство.
В общем если у вас кого-то деньги не мотивируют, то речь наверняка идёт о каких-то грошах.