это видео пропитано Риком Кацманом и ЕПАМом чуть более, чем полностью, еще пять копеек (может, что прослушал): количество пользователей и надежность таки часто на бизнес сильно влияют и интересуют его (MAU, текущее и планируемое = $, надежность доступность безотказность могут быть конкурентным преимуществом) нефункциональные требования/атрибуты могут идти напрямую от бизнес целей или вообще из ниоткуда (как и неявные ограничения) перед началом нарезки на сервисы и прикидки типов баз иногда полезно прикинуть общий арх стиль системы или комбинацию оных, нарезка по-умолчанию на сервисы по функциям не всегда оптимальное решение (на самом деле, выбор стиля это принятое арх решение, с плюсами и минусами, которое хорошо бы записать в список принятых решений с пусть простым, но обоснованием) если пытаться систематизировать весь процесс дизайна для общего случая, можно начинать с одного большого квадрата монолита (все функц блоки живут в нем) и уже в процессе смотреть, какие функции и как вырезать в отдельные куски и почему + как они общаются и в каких сценариях работы (причин как вырезать, так и не вырезать много, в каждом случае может сыграть своё)
Мне это архитекчер ремайнднул один видосик с вумен в магазине одежды, которая то на русском, то английском рассказывала про ассортимент товара у нее. Такой колзоз пздц!!
Обычно колхоз возмущается когда "не панашаму". А весь мир давно уже понимает что есть 100500 разных людей с разной культурой и языком. Если собеседник объяснился понятно - это хорошо. АйТи мир завязан на ежедневную коммуникацию на английском языке и это абсолютно нормальное явление, когда термины рабочие переходят в ежедневный обиход. Ненормально упарываться чистотой русского языка и поучать всех остальных. По вашему я должен представляться всем что работаю не БекЕнд девелопером, а "программистом заднего конца" ?
@@KohanGalanych ну, тут уж как вам угодно)) конца или начала) я не упарываюсь чистотой русского языка, но английские слова пихать везде где только можно через слово ну камон) пример, зачем говорит эксэптнуть, если можно сказать приняли задачу. Мы тут не не репчик читаем друг другу, где это уместно.
@@sergeys4732 а вы "камон" зачем вплели только что? )) Профессионал в речи использует удобные терминыб мне слух не режет и сразу понятно что человек уже не только хеллоу ворлд написал. ;)
Д4 это уровень выше сеньера но ниже архитектора по иерархии в компании, где работает Сергей. Как правило, специалисты данного уровня мыслят более технически, и редко оглядываются на бизнес- потребности. А они как раз и диктуют решение, ведь не всегда нужно самое лучшее и быстрое. Иногда надо подешевле, иногда побыстрее и тд.
не совсем понятен переход: почему deployment в несколько availability zones и куча реплик должны гарантировать именно X nines of availability, без evaluation на каких то тестовых данных. на мой взгляд просто диаграммы не достаточно
@@MJCtalks Да, на уровне железа это понятно что можно посчитать; я скорее про то, что ведь система может крашиться и на уровне софта, а в таком случае ни знания SLA, ни количество реплик, ни остальное никаких гарантий по поводу доступности не дают, без реального тестирования. (как я это понимаю)
@@carl.bergmann краш на уровне софта это функциональный баг и он должен быть пофикшен до релиза. Так же если у вас высокий sla то он спасет и от софта частично. Ещё прописывается процедура disaster recovery, что делать и как быстро система восстановится.
@@MJCtalks Я все же считаю, что сказать всякий баг на уровне софта это функциональный баг будет серьезным допущением, но даже если это опустить, то еще более серьезным допущением будет сказать, что все баги должны быть пофикшены до релиза. Безусловно вы правы, если мы говорим о так называемых bohr bugs (ну или о persistent errors), в случае же всяких transient errors (heisenbugs) то такого рода баги сложно даже воспроизвести, и следовательно, пофиксить. И да, естественно определенный уровень redundancy может увеличить уровень доступности, однако опять же без реального тестирования довольно сложно сказать сколько nines можно гарантировать. Возможно этот пример не относится к видео, поскольку там все же была разобрана довольно простая система, но в общем случае количество availability zones или реплик не гарантируют железно X nines в системе
@@carl.bergmann , на этапе проектирования у нас есть только sla сервисов, требования и допущения. Исходя из этого надо спроектировать и продать решение. Тестирование реальной системв уже да, покажет насколько верны были наши допущения.👍
Забавно как бомбит у работников абстрактного РосГазНефтьПромТех и не понимают что иногда для аутсорсинга сложно переключишься вот так вот сходу когда ты сначала мануалы от Амазона читал, потом днями объясняешь тоже потенциальному кастомеру, а потом теми же терминами внутри команды обсуждаешь. Это тупо проще и быстрее. Уверен в Яндекс.Облако и 1С совсем по другому, литературно и изящно.
Представляю кака каша подучилась заменив все на русские термины. Хотябы user story, delivery manager, solution architect, scope. Ну или перевести generic на русский объяснив почему это не common.
Те, кто возмущался, что сбор требований - задача БА, а не архитектора, как раз и показали, что они далеки до архитектуров, а пока еще остаются обычными девелоперами, которым надо нарезать таски в джире и они их будут делать.
Суржик специалиста нереально режет ухо. В большинстве случаев это не оправданная терминология, а речь, напоминающая малограмотных деревенских жителей, смешивающих русские и, например, украинские слова. Очень странное впечатление производит
Суржик, трасянка - естественная адаптация языков. На западе давно уже не парятся этим. А в нашем исконно православном мире начинает бомбить некоторых. Ещё и деревенщиной обзывают. Может это у вас нехватка образования, раз не можете смысл понять? Такие идеи чем то коричневым отдают, не находите?
@@KohanGalanych отнюдь, во первых специалист с видео часто повторяет то английские, то русские термины, как будто понтуется знанием(?). Это режет слух. Во вторых, если не может избавиться от привычки так говорить - лучше уж на чистом английском и с русскими субтитрами.
Степень раздражения при просмотре видео просто зашкаливает. Только скудностью интеллекта и мышления можно объяснить невозможность человека выражаться на одном языке. Постоянное использование слов (не терминов, а именно слов) на другом языке - как сказал бы спикер: "Буллшит".
Спикер просто работает на английском. Вся терминология у него тоже на английском. Вот ему и не так просто пользоваться русскими словами... Я почти уверен что если бы сделали этот толк на английском - то спикеру было бы проще. Другой вопрос что контент сделан на том языке, который ближе разработчикам из СНГ. Тут уже ничего не поделаешь.. Мир большой.
@@borisnikulitsa695 В таких случаях лучше делать все-таки интервью на английском, с русскими полными субтитрами, потому что фарш русских и английских слов раздражает невероятно. Как будто зашел в комнату где работают над стартапом 18 летние хипстеры. Ну и учитывая, что архитектура, это все-таки не уровень начинающих разработчиков/менеджеров, процент владеющих английским велик среди зрителей
Согласен, зачем вообще это видео на русском? Все кто делает архитектуру, т.е. достиг уже уровня выше сениора, знают английский. Надо было на английском делать
![Architecture Kata - discover what it's like to be an architect [#ityoutubersru]](http://i.ytimg.com/vi/JYj7pqd-Bso/mqdefault.jpg)
![How to write aspects with Spring AOP [Spring AOP journey - Part 1]](/img/n.gif)
Спасибо! Нужно больше таких видосов)
это видео пропитано Риком Кацманом и ЕПАМом чуть более, чем полностью, еще пять копеек (может, что прослушал):
количество пользователей и надежность таки часто на бизнес сильно влияют и интересуют его (MAU, текущее и планируемое = $, надежность доступность безотказность могут быть конкурентным преимуществом)
нефункциональные требования/атрибуты могут идти напрямую от бизнес целей или вообще из ниоткуда (как и неявные ограничения)
перед началом нарезки на сервисы и прикидки типов баз иногда полезно прикинуть общий арх стиль системы или комбинацию оных, нарезка по-умолчанию на сервисы по функциям не всегда оптимальное решение (на самом деле, выбор стиля это принятое арх решение, с плюсами и минусами, которое хорошо бы записать в список принятых решений с пусть простым, но обоснованием)
если пытаться систематизировать весь процесс дизайна для общего случая, можно начинать с одного большого квадрата монолита (все функц блоки живут в нем) и уже в процессе смотреть, какие функции и как вырезать в отдельные куски и почему + как они общаются и в каких сценариях работы (причин как вырезать, так и не вырезать много, в каждом случае может сыграть своё)
Мне это архитекчер ремайнднул один видосик с вумен в магазине одежды, которая то на русском, то английском рассказывала про ассортимент товара у нее. Такой колзоз пздц!!
Обычно колхоз возмущается когда "не панашаму". А весь мир давно уже понимает что есть 100500 разных людей с разной культурой и языком. Если собеседник объяснился понятно - это хорошо. АйТи мир завязан на ежедневную коммуникацию на английском языке и это абсолютно нормальное явление, когда термины рабочие переходят в ежедневный обиход. Ненормально упарываться чистотой русского языка и поучать всех остальных. По вашему я должен представляться всем что работаю не БекЕнд девелопером, а "программистом заднего конца" ?
@@KohanGalanych ну, тут уж как вам угодно)) конца или начала) я не упарываюсь чистотой русского языка, но английские слова пихать везде где только можно через слово ну камон) пример, зачем говорит эксэптнуть, если можно сказать приняли задачу. Мы тут не не репчик читаем друг другу, где это уместно.
@@sergeys4732 а вы "камон" зачем вплели только что? )) Профессионал в речи использует удобные терминыб мне слух не режет и сразу понятно что человек уже не только хеллоу ворлд написал. ;)
мне понравились эротичные выдохи в микрофон от бородача
Ну просто красавчики!
привет, зачем вы использовали ВМ ? почему не взять webapp?
Не совсем понял, о чем вы говорите?
Спасибо, подскажите : Д4 мышление на 9 минуте, о чем речь? Поделитесь источником
Д4 это уровень выше сеньера но ниже архитектора по иерархии в компании, где работает Сергей. Как правило, специалисты данного уровня мыслят более технически, и редко оглядываются на бизнес- потребности. А они как раз и диктуют решение, ведь не всегда нужно самое лучшее и быстрое. Иногда надо подешевле, иногда побыстрее и тд.
@@MJCtalks Спасибо
не совсем понятен переход: почему deployment в несколько availability zones и куча реплик должны гарантировать именно X nines of availability, без evaluation на каких то тестовых данных. на мой взгляд просто диаграммы не достаточно
Cloud предоставляет sla по сервисам. Далее можно посчитать сколько зон и нод нужно чтобы достичь необходимого availability
@@MJCtalks Да, на уровне железа это понятно что можно посчитать; я скорее про то, что ведь система может крашиться и на уровне софта, а в таком случае ни знания SLA, ни количество реплик, ни остальное никаких гарантий по поводу доступности не дают, без реального тестирования. (как я это понимаю)
@@carl.bergmann краш на уровне софта это функциональный баг и он должен быть пофикшен до релиза. Так же если у вас высокий sla то он спасет и от софта частично. Ещё прописывается процедура disaster recovery, что делать и как быстро система восстановится.
@@MJCtalks Я все же считаю, что сказать всякий баг на уровне софта это функциональный баг будет серьезным допущением, но даже если это опустить, то еще более серьезным допущением будет сказать, что все баги должны быть пофикшены до релиза. Безусловно вы правы, если мы говорим о так называемых bohr bugs (ну или о persistent errors), в случае же всяких transient errors (heisenbugs) то такого рода баги сложно даже воспроизвести, и следовательно, пофиксить. И да, естественно определенный уровень redundancy может увеличить уровень доступности, однако опять же без реального тестирования довольно сложно сказать сколько nines можно гарантировать. Возможно этот пример не относится к видео, поскольку там все же была разобрана довольно простая система, но в общем случае количество availability zones или реплик не гарантируют железно X nines в системе
@@carl.bergmann , на этапе проектирования у нас есть только sla сервисов, требования и допущения. Исходя из этого надо спроектировать и продать решение. Тестирование реальной системв уже да, покажет насколько верны были наши допущения.👍
Забавно как бомбит у работников абстрактного РосГазНефтьПромТех и не понимают что иногда для аутсорсинга сложно переключишься вот так вот сходу когда ты сначала мануалы от Амазона читал, потом днями объясняешь тоже потенциальному кастомеру, а потом теми же терминами внутри команды обсуждаешь. Это тупо проще и быстрее. Уверен в Яндекс.Облако и 1С совсем по другому, литературно и изящно.
Представляю кака каша подучилась заменив все на русские термины. Хотябы user story, delivery manager, solution architect, scope. Ну или перевести generic на русский объяснив почему это не common.
Я бы лучше претензию к уровню звука высказал, это реально косяк. Особенно когда в микрофон Андрея слышно Сергея, а потом он отворачивается)
Второго чела не слышно, жесткий диссонанс между звуком ведущего и гостя. В след раз дайте гостю тоже микрофон
Те, кто возмущался, что сбор требований - задача БА, а не архитектора, как раз и показали, что они далеки до архитектуров, а пока еще остаются обычными девелоперами, которым надо нарезать таски в джире и они их будут делать.
А зачем тогда нужен БА?
sound (
Суржик специалиста нереально режет ухо. В большинстве случаев это не оправданная терминология, а речь, напоминающая малограмотных деревенских жителей, смешивающих русские и, например, украинские слова. Очень странное впечатление производит
Рунглиш, по странным причинам, очень распространен среди программистов. Сколько ни общаюсь, изо всех лезет
Вы не шарите, суржик это диалект 👌
Суржик, трасянка - естественная адаптация языков. На западе давно уже не парятся этим. А в нашем исконно православном мире начинает бомбить некоторых. Ещё и деревенщиной обзывают. Может это у вас нехватка образования, раз не можете смысл понять? Такие идеи чем то коричневым отдают, не находите?
@@KohanGalanych отнюдь, во первых специалист с видео часто повторяет то английские, то русские термины, как будто понтуется знанием(?). Это режет слух. Во вторых, если не может избавиться от привычки так говорить - лучше уж на чистом английском и с русскими субтитрами.
@@KohanGalanych Чего у тебя так бомбит?) Люди высказывают своё мнение. А ты видно сам коричневый в бчб ленте.
Степень раздражения при просмотре видео просто зашкаливает. Только скудностью интеллекта и мышления можно объяснить невозможность человека выражаться на одном языке. Постоянное использование слов (не терминов, а именно слов) на другом языке - как сказал бы спикер: "Буллшит".
Спикер просто работает на английском. Вся терминология у него тоже на английском. Вот ему и не так просто пользоваться русскими словами...
Я почти уверен что если бы сделали этот толк на английском - то спикеру было бы проще. Другой вопрос что контент сделан на том языке, который ближе разработчикам из СНГ.
Тут уже ничего не поделаешь.. Мир большой.
@@borisnikulitsa695 В таких случаях лучше делать все-таки интервью на английском, с русскими полными субтитрами, потому что фарш русских и английских слов раздражает невероятно. Как будто зашел в комнату где работают над стартапом 18 летние хипстеры.
Ну и учитывая, что архитектура, это все-таки не уровень начинающих разработчиков/менеджеров, процент владеющих английским велик среди зрителей
@@mauzer17 Плюс ребята из Индии, Мексики и других стран тоже могли бы посмотреть.
Согласен, зачем вообще это видео на русском? Все кто делает архитектуру, т.е. достиг уже уровня выше сениора, знают английский. Надо было на английском делать