А в чем разница рынка и ниши? Как формально отличить рынок профессиональных фотоаппаратов от рынка фотоаппаратов от рынка камер и фотоаппаратов от рынка устройств с камерой и даже от рынка техологичных игрушек? Это все рынки, пересекающиеся, вложенные друг в друга - но рынки.
Ниша - это про часть рынка с низкой конкуренцией. Про указанные рынки нельзя сказать, что там низкая конкуренция. Впрочем, разница между рынком, сегментом и нишей - весьма сомнительная и зависит от целей рассмотрения.
Хм, глубоко не нырял. Но в некоторых камерах шумодав работает даже на RAW, увы, особенно на высоких ISO. Хотя формально - да, просто значения, снятые с матрицы. Производительность встроенного в камеру процессора - один из признаков, отличающих старшие камеры в линейке - и там довольно много работы. Хотя, конечно, в основном это про генерацию jpeg, но не только.
Хм, смотря каких рынков. Есть рынок компактных среднеформатников, там Fuji и Хассель. Есть рынок пафосных дальномерок, там Leica и Fuji Есть рынок компактных камер, там Олимпус и Панасоник Есть рынок профессиональных полнокадровых камер и там Никон с Кэноном и Сони. Ну и так далее. Нет единого рынка фототехники, есть много разных рынков, с разными лидерами, разными стратегиями и так далее. И Никон с Кэноном далеко не на всех конкурируют и даже не на всех представлены.
Увы, но есть люди, которые не воспринимают критику, донесенную без использования эмоционально окрашенных слов. Часто они же не очень компетентны. И в этом случае иногда описать то, что они сделали в точных и эмоционально окрашенных терминах ("этот код - полное дерьмо") является единственным способом смотивировать на его переделку. Разумеется, добавив конструктивных причин подобной формулировки и рекомендаций по устранению. Уволить их можно, но это же надо ждать где-то год, а работу делать надо.
Так нанимают все больше в компанию, а не в команду. И уж кого наняли - того наняли (и да, это, конечно, проблема компании, но такой подход, увы, массовый).
Хм, проблемы представительности как раз не представляют особой проблемы. Достаточно просто собирать данные не в режиме "пришлите кто-нибудь", а через обращения в компании согласно статистическим данным (хотя бы по размеру и по отраслям), впрочем есть и куча других подходов. Верификацию-то уж точно стоило бы сделать. Как и глубинные интервью хотя бы с некоторыми компаниями (лучше с каким-то представительным количеством). Но ничего из этого не делалось, так как, кажется, цели сделать что-то обоснованное - не ставилось. Проверку каузации вполне можно сделать - например посмотреть, как меняется доходность в компаниях с резким изменением метрик (причем тоже с разным размерами и из разных отраслей). Скорее всего финансовые показатели при этом не изменятся. (Кстати, так как больше всего делилось данными люди из крупных компаний, где реально скорость доставки имеет смысл и легче обеспечиваются - то корреляция выглядит очевидной. Но понятно, что доставку 10 релизов в день в компании в 10 человек нет смысла делать. Впрочем, кажется, там и успех компаний считали абсолютные, а не в привязке на сотрудника, что уже совсем бессмысленно). И да, конечно индексы счастья или коррупции - бесполезны и не дают никакой полезной информации и не обладают никакой прогностической силы.
Про DORA. Там проблемы в сборе самих метрик (их присылали произвольные люди по собственной инициативе, без какой-то верификации данных, без определения представительности присланных данных, даже без соотношения данных с конкретными департаментами компаний), проблемы в отслеживании корреляций (не было анализа кластеризации по секторам, не оценивалась вообще важность для бизнеса метрик, некоторые метрики вообще не могут быть оценены для многих компаний). Ну и "корреляция не значит каузация". Так что говорить о какой-то большей обоснованности метрик DORA, нежели, например, натальной карты сервера - не приходится.
По поводу очевидности - тут как раз используемые решения были очевидно первыми, в том числе и для улучшения метрик. Но при этом же метрики никак с изменением подхода к бранчам не связаны, для улучшения метрик могли и еще десяток тестовых кластеров поставить, например.
Но вы правильно пишите, что метрики нужны для убеждения - да, в этом они помогают.
Хм, но DORA метрики, на самом деле, ни с чем не коррелируют (там исследование не может ничего доказать, так как сделано некорректно). Реально я вижу переход к относительно современной модели бранчевания, но этот подход очевиден уже при первом взгляде на старую модель. Зачем тут DORA?
P.S. Но да, DORA может использоваться для убеждение не слишком компетентного менеджмента для проведения достаточно очевидных изменений в пайплайне. Другой ценности в метриках нет.
Хм, TOGAF и прочее - это скорее про Enterprise Arch, а не про SolArch или SysArch. Да, эта роль возникает только в очень крупных компаниях. Но наличие корпоративного архитектора не значит, что на уровне отдельного продукта внутри департамента не используется DDD. Большие компании - большие, там много что внутри происходит )
Хм, вроде бы стратегические паттерны DDD - это как раз работа архитектора (как роли и, иногда, как позиции). Да и выявление UL/BC полезно в проекте любого размера.
Ну да, архитектор - это про правила взаимодействия разных команд в первую очередь. И никакой agile не убрал необходимости в архитекторе (как и не было необходимости в позиции архитектора в микропроектах на одну небольшую команду). Но в статье вообще путают активности, роли и позиции. Активности архитектора есть в любом проекте, роль - почти всегда, а позиция нужна уже только при нескольких командах.
Хм, он по производительности совсем в другой лиге, там и 50k сообщений в секунду - уже проблема, да и с надежностью и кластеризацией не очень хочется. Его можно разве что с Mosquito сравнивать, но будет примерно то же - сплошные "нет" и "умеренно".
На большинстве конференций предлагают свои шаблоны для презентаций, где большая часть этих пожеланий учтена (впрочем, я еще не видел ни одного действительно хорошего шаблона презентации от конференции, всюду какие-то огрехи, так как их придумывают дизайнеры). Если же конференция не присылает своего шаблона, то стоит использовать стандартный шаблон компании, а уж дизайнер обычно базовые вещи сможет сделать. Если нет стандартного шаблона в компании - то его полезно разработать, но не только дизайнеру.
Но, вообще, мне сложно представить презентацию, которой подошел бы дизайн из статьи. Очень много мелкого текста (не видно с дальних рядом), нет истории (много пунктов на одном слайде), нет номеров страниц, заголовок мало отделен от текста (впрочем, нужны ли заголовки на слайдах - вообще дискуссионный вопрос, мне как спикеру проще с ними, но слушателям они скорее мешают), текстовые блоки размещены в разных частях страниц.
Ну, у SO очень грамотная монолитная архитектура. Решение на микросервисах потребовало бы на порядок больше железа и раза в два больше сотрудников, еще и более дорогих - зачем это надо? МСА нужно довольно в редких случаях, к которым не относится большая часть проектов. Кстати, раньше поиск Яндекса был нефига не микросервисным )
Ой, да, ошибся, спасибо!
Нет, с 01.03.2022 временный порядок вывоза наличности, не больше 10k$ на человека.
Управление фокусом глазом, кстати, у Никона тоже было. Но выкинули, как неудобное.
Кто в 90х сделал первым - уже не помню...
А в чем разница рынка и ниши? Как формально отличить рынок профессиональных фотоаппаратов от рынка фотоаппаратов от рынка камер и фотоаппаратов от рынка устройств с камерой и даже от рынка техологичных игрушек?
Это все рынки, пересекающиеся, вложенные друг в друга - но рынки.
Ниша - это про часть рынка с низкой конкуренцией. Про указанные рынки нельзя сказать, что там низкая конкуренция.
Впрочем, разница между рынком, сегментом и нишей - весьма сомнительная и зависит от целей рассмотрения.
Хм, глубоко не нырял. Но в некоторых камерах шумодав работает даже на RAW, увы, особенно на высоких ISO. Хотя формально - да, просто значения, снятые с матрицы.
Производительность встроенного в камеру процессора - один из признаков, отличающих старшие камеры в линейке - и там довольно много работы. Хотя, конечно, в основном это про генерацию jpeg, но не только.
Постобработки там дофига, она сильно влияет на результат.
И она сильно разная на разных тушках, с фирменными особенностями и так далее.
Хм, смотря каких рынков.
Есть рынок компактных среднеформатников, там Fuji и Хассель.
Есть рынок пафосных дальномерок, там Leica и Fuji
Есть рынок компактных камер, там Олимпус и Панасоник
Есть рынок профессиональных полнокадровых камер и там Никон с Кэноном и Сони.
Ну и так далее.
Нет единого рынка фототехники, есть много разных рынков, с разными лидерами, разными стратегиями и так далее. И Никон с Кэноном далеко не на всех конкурируют и даже не на всех представлены.
Увы, но есть люди, которые не воспринимают критику, донесенную без использования эмоционально окрашенных слов. Часто они же не очень компетентны. И в этом случае иногда описать то, что они сделали в точных и эмоционально окрашенных терминах ("этот код - полное дерьмо") является единственным способом смотивировать на его переделку. Разумеется, добавив конструктивных причин подобной формулировки и рекомендаций по устранению.
Уволить их можно, но это же надо ждать где-то год, а работу делать надо.
Так нанимают все больше в компанию, а не в команду. И уж кого наняли - того наняли (и да, это, конечно, проблема компании, но такой подход, увы, массовый).
Хм, проблемы представительности как раз не представляют особой проблемы. Достаточно просто собирать данные не в режиме "пришлите кто-нибудь", а через обращения в компании согласно статистическим данным (хотя бы по размеру и по отраслям), впрочем есть и куча других подходов. Верификацию-то уж точно стоило бы сделать. Как и глубинные интервью хотя бы с некоторыми компаниями (лучше с каким-то представительным количеством). Но ничего из этого не делалось, так как, кажется, цели сделать что-то обоснованное - не ставилось.
Проверку каузации вполне можно сделать - например посмотреть, как меняется доходность в компаниях с резким изменением метрик (причем тоже с разным размерами и из разных отраслей). Скорее всего финансовые показатели при этом не изменятся.
(Кстати, так как больше всего делилось данными люди из крупных компаний, где реально скорость доставки имеет смысл и легче обеспечиваются - то корреляция выглядит очевидной. Но понятно, что доставку 10 релизов в день в компании в 10 человек нет смысла делать. Впрочем, кажется, там и успех компаний считали абсолютные, а не в привязке на сотрудника, что уже совсем бессмысленно).
И да, конечно индексы счастья или коррупции - бесполезны и не дают никакой полезной информации и не обладают никакой прогностической силы.
Опираться на свой опыт - да, есть смысл!
Про DORA. Там проблемы в сборе самих метрик (их присылали произвольные люди по собственной инициативе, без какой-то верификации данных, без определения представительности присланных данных, даже без соотношения данных с конкретными департаментами компаний), проблемы в отслеживании корреляций (не было анализа кластеризации по секторам, не оценивалась вообще важность для бизнеса метрик, некоторые метрики вообще не могут быть оценены для многих компаний). Ну и "корреляция не значит каузация".
Так что говорить о какой-то большей обоснованности метрик DORA, нежели, например, натальной карты сервера - не приходится.
По поводу очевидности - тут как раз используемые решения были очевидно первыми, в том числе и для улучшения метрик. Но при этом же метрики никак с изменением подхода к бранчам не связаны, для улучшения метрик могли и еще десяток тестовых кластеров поставить, например.
Но вы правильно пишите, что метрики нужны для убеждения - да, в этом они помогают.
Хм, но DORA метрики, на самом деле, ни с чем не коррелируют (там исследование не может ничего доказать, так как сделано некорректно).
Реально я вижу переход к относительно современной модели бранчевания, но этот подход очевиден уже при первом взгляде на старую модель. Зачем тут DORA?
P.S. Но да, DORA может использоваться для убеждение не слишком компетентного менеджмента для проведения достаточно очевидных изменений в пайплайне. Другой ценности в метриках нет.
Хм, TOGAF и прочее - это скорее про Enterprise Arch, а не про SolArch или SysArch. Да, эта роль возникает только в очень крупных компаниях. Но наличие корпоративного архитектора не значит, что на уровне отдельного продукта внутри департамента не используется DDD. Большие компании - большие, там много что внутри происходит )
Хм, вроде бы стратегические паттерны DDD - это как раз работа архитектора (как роли и, иногда, как позиции). Да и выявление UL/BC полезно в проекте любого размера.
Ну да, архитектор - это про правила взаимодействия разных команд в первую очередь. И никакой agile не убрал необходимости в архитекторе (как и не было необходимости в позиции архитектора в микропроектах на одну небольшую команду).
Но в статье вообще путают активности, роли и позиции. Активности архитектора есть в любом проекте, роль - почти всегда, а позиция нужна уже только при нескольких командах.
Хм, он по производительности совсем в другой лиге, там и 50k сообщений в секунду - уже проблема, да и с надежностью и кластеризацией не очень хочется. Его можно разве что с Mosquito сравнивать, но будет примерно то же - сплошные "нет" и "умеренно".
На большинстве конференций предлагают свои шаблоны для презентаций, где большая часть этих пожеланий учтена (впрочем, я еще не видел ни одного действительно хорошего шаблона презентации от конференции, всюду какие-то огрехи, так как их придумывают дизайнеры). Если же конференция не присылает своего шаблона, то стоит использовать стандартный шаблон компании, а уж дизайнер обычно базовые вещи сможет сделать. Если нет стандартного шаблона в компании - то его полезно разработать, но не только дизайнеру.
Но, вообще, мне сложно представить презентацию, которой подошел бы дизайн из статьи. Очень много мелкого текста (не видно с дальних рядом), нет истории (много пунктов на одном слайде), нет номеров страниц, заголовок мало отделен от текста (впрочем, нужны ли заголовки на слайдах - вообще дискуссионный вопрос, мне как спикеру проще с ними, но слушателям они скорее мешают), текстовые блоки размещены в разных частях страниц.
Ну, у SO очень грамотная монолитная архитектура. Решение на микросервисах потребовало бы на порядок больше железа и раза в два больше сотрудников, еще и более дорогих - зачем это надо?
МСА нужно довольно в редких случаях, к которым не относится большая часть проектов. Кстати, раньше поиск Яндекса был нефига не микросервисным )
Это же ирония, да? А то в тексте не очень точно считывается )
А быстро - это сколько? У меня монолит стартовал за одну секунду в 2012 году, это достаточно быстро?
Java, но никакого спринга, конечно.