Попробуйте найти друзей, у которых обратная проблема (перевод долларов из Москвы в США/Европу) и договоритесь о взаиморасчете. Сейчас многим это актуально (оплата обучения, ипотеки и т.п.)
Хм, если верить Сыма Цяню, то при Сунь-цзы княжество У все-таки выиграло несколько войн. Впрочем, текст трактата скорее всего более поздний, но там слишком много разных вариантов.
Ага. Просто в результате ты комментируешь не действительно один из основопологающих текстов по стратегии (сравнивать можно разве что с Лиддел-Гартом, да с Триандафилловым), а плохой перевод с плохого перевода с перевода, сильно упрощенный относительно оригинала, еще и без комментариев. Потому и рекомендую прочитать Конрада и уже потом вернуться к комментированию. А лучше кроме Конрада еще и комментарии Малянова почитать и другие комментарии к Сунь-цзы, благо их очень много. Ну и про применение Сунь-цзы к современной реальности (от военной стратегии до бизнеса) написано дофига книг (правда, про переводы не слышал). Все-таки хорошо упакованная стихийная диалектика легко применима к текущим проблемам, да и многие другие принципы вполне универсальны.
А по какому переводу цитаты приведены? Это и не Малявинский и не Конрада, больше похож на перевод с английского (весьма неудачная). Вообще, советую почитать именно Конрадовский перевод с его же комментариями, там очень и очень много всякого интересного - от тонкостей перевода и до понимания отдельных фраз в разные эпохи и разными комментаторами.
Как я понимаю, "работало в командах" - относится к одному и только одному случаю? Тогда почему именно указанные вещи достаточны для того, что бы работало? Или они необходимы, а не достаточны? И, кстати, а что значит "работало"?
Увы, я не проходил курсов у Левенчука, так что не мог кратко описать содержимое подхода ШСМ, хотя с удовольствием их порекомендую. Но это уже "следующий уровень", на мой взгляд. С рациональностью чуть сложнее, описанный подход ближе к "формально научному", но и с его применением для улучшения процессов все непростом, тем более все сложно с применением менее очевидных практик из LessWrong-овской тусовки (и вообще я к ним отношусь с любовью, но осторожностью).
А какие доказательства ожидаются? В тексте патента вряд ли будет ссылка на ТРИЗ (с чего бы?). При этом даже я общался с кучей знакомых физиков, которые в начале 200х в Питере делали сложные изобретения на запад и ТРИЗ там был одним из основных инструментов. Да и статья в Forbes про использование TRIZ в Samsung выглядит вполне убедительной. Собственно, набор инструментария в ТРИЗ достаточно простой, освоить его не сложно, после чего многие решения можно считать тризовскими - что инженерные, что разработческие, что управленческие.
Ну, это уже давно не так, сейчас больше двух собседований не бывает. Но процессы найма вообще меняются сложнее всего, увы. А по рабочим местам - нормальная современная компания, ноутбуки, рабочие станции, офис или удаленка и так далее. Много меньше проблем, чем, например, в Яндексе лет 10 назад (про сегодняшний просто не знаю). Некоторые вещи сделаны очень хорошо, некоторые еще нет.
Если я правильно понял amarao, то его смущает использование bad там, где оно не очень к месту. В оригинале действительно просто code smel, без прилагательных - и это правильно. Мне тоже стоило бы не добавлять характеристик, попахивает - и ладно. В конце концов у smell без прилагательных уже достаточно отрицательных коннотаций.
Вот да, это уровень дизайна для джуниора. При этом вообще не понятно, зачем у джуна спрашивать системный дизайн. Но судя и по другим отрывкам из книги, использовать советы оттуда для реального проектирования категорически не рекомендуется. Полезны ли эти советы для интервью - не знаю, у меня бы разработчик с такими ответами интервью не прошел бы.
Я бы искренне посоветовал подумать над общим решением, это же не только для онбординга нужно, а для тех же платежей, да и вообще для множества разных операций (почти для всех, на самом-то деле).
Я скорее про число шагов, которое нужно выполнить в секунду, про скорость восстановления после падения воркера, про число одновременных процессов и т.п. Это те НФТ, которые больше всего влияют на подобные решения.
Когда из одного сценария (саги) нужно вызвать другую, а потом продолжить работу. Частый сценарий, который через простую последовательность шагов уже не реализуется.
Я не понял, как и когда другие воркеры поймут, что конкретные саги "зависли". Только по таймеру?
Насколько я понимаю, нет, ваше решение еще очень далеко от temporal. У вас поддерживается только линейная фиксированная последовательность шагов, а не любые сценарии; нет никакой поддержки версионирования сценариев; нет user-actions; весь ресайленс нужно реализовывать практически вручную; да и вообще, фактически, все нужно делать вручную, нет какого-то удобного фреймворка.
Возможно, я не прав, но решение смотрится не как "мы сделали оркестратор бизнес-транзакций на гошечке", а как "мы реализовали не совсем сагу для парочки конкретных кейсов". Ну или из статьи не видно, какая функциональность у вашего решения есть (зато хорошо заметно, какие проблемы у этого решения будут).
Потому и говорю, что вы еще в начале большого пути )
Конечные автоматы все-таки сложно программировать, особенно когда там сложные циклы внутри, я потому и перешел сначала на акторы, а потом на workflow. Ну а в Озоне, подозреваю, еще в самом начале пути )
Ну, даже если не тащить temporal, то можно было бы сделать свое решение в духе temporal.io, там идеология (не реализация) гораздо удобнее классических саг. Ну или вообще сделать оркестратор как библиотеку, в стиле Haydn4k. Впрочем, не факт, что на go вообще можно написать удобный оркестратор.
Кстати, а какие требования у вас по производительности оркестраций? И по взаимодействию разных сценариев? И не совсем понятно, что происходит при падении воркера, как можно понять, что нужно повторить какие-то операции?
Попробуйте найти друзей, у которых обратная проблема (перевод долларов из Москвы в США/Европу) и договоритесь о взаиморасчете. Сейчас многим это актуально (оплата обучения, ипотеки и т.п.)
Хм, если верить Сыма Цяню, то при Сунь-цзы княжество У все-таки выиграло несколько войн. Впрочем, текст трактата скорее всего более поздний, но там слишком много разных вариантов.
Ага. Просто в результате ты комментируешь не действительно один из основопологающих текстов по стратегии (сравнивать можно разве что с Лиддел-Гартом, да с Триандафилловым), а плохой перевод с плохого перевода с перевода, сильно упрощенный относительно оригинала, еще и без комментариев. Потому и рекомендую прочитать Конрада и уже потом вернуться к комментированию. А лучше кроме Конрада еще и комментарии Малянова почитать и другие комментарии к Сунь-цзы, благо их очень много.
Ну и про применение Сунь-цзы к современной реальности (от военной стратегии до бизнеса) написано дофига книг (правда, про переводы не слышал). Все-таки хорошо упакованная стихийная диалектика легко применима к текущим проблемам, да и многие другие принципы вполне универсальны.
А по какому переводу цитаты приведены? Это и не Малявинский и не Конрада, больше похож на перевод с английского (весьма неудачная).
Вообще, советую почитать именно Конрадовский перевод с его же комментариями, там очень и очень много всякого интересного - от тонкостей перевода и до понимания отдельных фраз в разные эпохи и разными комментаторами.
Как я понимаю, "работало в командах" - относится к одному и только одному случаю? Тогда почему именно указанные вещи достаточны для того, что бы работало? Или они необходимы, а не достаточны?
И, кстати, а что значит "работало"?
Увы, я не проходил курсов у Левенчука, так что не мог кратко описать содержимое подхода ШСМ, хотя с удовольствием их порекомендую. Но это уже "следующий уровень", на мой взгляд.
С рациональностью чуть сложнее, описанный подход ближе к "формально научному", но и с его применением для улучшения процессов все непростом, тем более все сложно с применением менее очевидных практик из LessWrong-овской тусовки (и вообще я к ним отношусь с любовью, но осторожностью).
Они и прошлую модель где-то на полгода протормозили, так что может и выйдет.
Но пока да, платить стремно...
А какие доказательства ожидаются? В тексте патента вряд ли будет ссылка на ТРИЗ (с чего бы?). При этом даже я общался с кучей знакомых физиков, которые в начале 200х в Питере делали сложные изобретения на запад и ТРИЗ там был одним из основных инструментов. Да и статья в Forbes про использование TRIZ в Samsung выглядит вполне убедительной.
Собственно, набор инструментария в ТРИЗ достаточно простой, освоить его не сложно, после чего многие решения можно считать тризовскими - что инженерные, что разработческие, что управленческие.
Но если погуглить пару минут, то можно найти какие-то материалы за пределами РФ:
https://www.researchgate.net/publication/269758536_Case_study_of_SAMSUNG_TFT-LCD_Technology_Innovation_using_TRIZ_method
https://ieeexplore.ieee.org/document/1308166
https://www.osaka-gu.ac.jp/php/nakagawa/TRIZ/eTRIZ/epapers/e2009Papers/eCheongTRIZSymp2008/09eP-Cheong-TRIZSymp2008-090709.pdf
Оценка их адекватности - отдельная и нетривиальная задача.
Ну, это уже давно не так, сейчас больше двух собседований не бывает. Но процессы найма вообще меняются сложнее всего, увы.
А по рабочим местам - нормальная современная компания, ноутбуки, рабочие станции, офис или удаленка и так далее. Много меньше проблем, чем, например, в Яндексе лет 10 назад (про сегодняшний просто не знаю). Некоторые вещи сделаны очень хорошо, некоторые еще нет.
Если я правильно понял amarao, то его смущает использование bad там, где оно не очень к месту. В оригинале действительно просто code smel, без прилагательных - и это правильно. Мне тоже стоило бы не добавлять характеристик, попахивает - и ладно. В конце концов у smell без прилагательных уже достаточно отрицательных коннотаций.
Хм, да, может быть заменить на process smell было бы правильнее. Я подумаю еще и, может быть, заменю.
Вот да, это уровень дизайна для джуниора. При этом вообще не понятно, зачем у джуна спрашивать системный дизайн.
Но судя и по другим отрывкам из книги, использовать советы оттуда для реального проектирования категорически не рекомендуется. Полезны ли эти советы для интервью - не знаю, у меня бы разработчик с такими ответами интервью не прошел бы.
Я бы искренне посоветовал подумать над общим решением, это же не только для онбординга нужно, а для тех же платежей, да и вообще для множества разных операций (почти для всех, на самом-то деле).
Кстати, а в Озоне разве нет общего стандартного решения для оркестрации? Вроде бы микросервисы у вас давно уже?
Я скорее про число шагов, которое нужно выполнить в секунду, про скорость восстановления после падения воркера, про число одновременных процессов и т.п. Это те НФТ, которые больше всего влияют на подобные решения.
Когда из одного сценария (саги) нужно вызвать другую, а потом продолжить работу. Частый сценарий, который через простую последовательность шагов уже не реализуется.
Я не понял, как и когда другие воркеры поймут, что конкретные саги "зависли". Только по таймеру?
Насколько я понимаю, нет, ваше решение еще очень далеко от temporal. У вас поддерживается только линейная фиксированная последовательность шагов, а не любые сценарии; нет никакой поддержки версионирования сценариев; нет user-actions; весь ресайленс нужно реализовывать практически вручную; да и вообще, фактически, все нужно делать вручную, нет какого-то удобного фреймворка.
Возможно, я не прав, но решение смотрится не как "мы сделали оркестратор бизнес-транзакций на гошечке", а как "мы реализовали не совсем сагу для парочки конкретных кейсов". Ну или из статьи не видно, какая функциональность у вашего решения есть (зато хорошо заметно, какие проблемы у этого решения будут).
Потому и говорю, что вы еще в начале большого пути )
Еще немножко материалов по теме:
1) Про реализацию акторов поверх PG : https://pgconf.ru/2017/93989
2) Про workflow: https://habr.com/ru/company/oleg-bunin/blog/588488/
Конечные автоматы все-таки сложно программировать, особенно когда там сложные циклы внутри, я потому и перешел сначала на акторы, а потом на workflow.
Ну а в Озоне, подозреваю, еще в самом начале пути )
Ну, даже если не тащить temporal, то можно было бы сделать свое решение в духе temporal.io, там идеология (не реализация) гораздо удобнее классических саг.
Ну или вообще сделать оркестратор как библиотеку, в стиле Haydn4k. Впрочем, не факт, что на go вообще можно написать удобный оркестратор.
Кстати, а какие требования у вас по производительности оркестраций? И по взаимодействию разных сценариев? И не совсем понятно, что происходит при падении воркера, как можно понять, что нужно повторить какие-то операции?
А, это конечно, тут сложно спорить.
Спасибо. Я вечно теряю эти ссылки.