как понимаю, оскорбительно тут то, что с другими расами ошибки нет. Если бы приложение уверенно детектировало европеодов как "белых обезьян", а азиатов как "жёлтых обезьян", то проблемы бы не возникло. Забавно, что простым костылём проблема не решается. Если на фотке будет горилла, а Гугл подпишет "чернокожий", то тоже оскорбление получается.
Думаю, что ещё имеет место "ошибка выжившего". Я не встречал статей в духе "мы уволили нашего ключевого разработчика, и бизнес умер", или хотя бы "мы уволили нашего ключевого разработчика, и темп роста компании упал в 2 раза". На ум приходит лишь одна история, когда компания осознала проблему и была вынуждена вернуть ключевого сотрудника. Это Apple.
выгонять - не стремятся. Но многие компании не стремятся и удерживать такого сотрудника. Парадокс, но менеджменту психологически проще расстаться с текущим сотрудником, который просит прибавку ( мысль менеджера "я сейчас плачу X, а теперь должен платить X+Y за ту же работу?" ) и нанять нового сотрудника за Z денег, где Z > X+Y , потому что "нам нужен сотрудник, а рынок труда предлагает только за Z или больше". На Хабре было несколько статей на эту тему.
Моё предложение - выкинуть скрам, процессы подстраивать под потребности.
Так выкидывайте. Только не говорите потом, что "Скрам не работает". Скрам декларирует, что при соблюдении всех правил участники получат определённые плюшки. Не соблюдаете какие-то правила - теряете плюшки, в целом или частично. Иногда довольно неочевидным образом.
Это значит, что все Разработчики в Scrum Team имеют одинаковый авторитет и права. Если этот принцип нарушается, то команда теряет ценности Скрама, со всеми последствиями.
Scrum Teams являются кросс-функциональными.
Это не означает, что это команда из фулл-стэков. Это означает, что если (утрируя) на каждый спринт Вы то добавляете в команду участников с нужными компетенциями и убираете из команды участников с невостребованными компетенциями, то у Вас нет команды.
Также они самоуправляемы, то есть сами решают, кто, что, когда и как делает.
СМ контролирует соответствие Скраму, но не решения участников. СМ не распределяет задачи между Разработчиками - они делают это самостоятельно через консенсус. Тем более, никакой вышестоящий начальник не влияет на решения команды. (Зато, например, он может распустить саму команду).
впечатление, что копит обиды в себе ... так явный экстраверт его охарактеризовал
Я правильно показал в цитате, что все эти слова - единая характеристика одного человека ( некоего интроверта ) другим человеком ( неким экстравертом)? Если да, то этот экстраверт довольно любопытная личность: намеренно наносит людям обиды, прощупывая, насколько сильно их можно "топтать". Интроверт "не прощупывается", и экстраверта это беспокоит; он понимает, что если будет вспышка агрессии, то при последующем "разборе полётов" виноват будет именно он ( так как зашёл слишком далеко). Откуда я делаю вывод о намеренном нанесении обид: раз экстраверт говорит "впечатление, что копит обиды" - значит, он знает: есть, что копить.
В целом статья разочаровала. Много воды, мало по теме. Частные претензии:
Однако, если покопаться в настройках MySQL, то вы получите те же значения, что и на физическом сервере
Это, в лучше случае, самообман. Возьмите физический сервер с SSD‑ или NVMe‑дисками, а затем возьмите облачный, и сравните показатели вставки/изменения/удаления записей.
Сейчас, за счет кэширования базы данных
Кэширование не решает проблем скорости. Кэширование решает проблемы масштабирования. Если у Вас промахи кэша - это 99 случаев из 100, то кэш бесполезен.
использовать микросервисную архитектуру
В случае Битрикса это нерелеватно - функционал "из коробки" не имеет микросервисной архитектуры.
Когда поэт, описывая даму, Начнет: «Я шла по улице. В бока впился корсет»,‑ Здесь «я» не понимай, конечно, прямо — Что, мол, под дамою скрывается поэт. Я истину тебе по‑дружески открою: Поэт — мужчина. Даже с бородою.
Можете рассказать, на каких мощностях это работает? Каков размер БД? Что вы делаете с историческими данными ( например, задачи или сделки, закрытые год назад)?
Проблема стара как мир: ножом можно порезаться.
как понимаю, оскорбительно тут то, что с другими расами ошибки нет. Если бы приложение уверенно детектировало европеодов как "белых обезьян", а азиатов как "жёлтых обезьян", то проблемы бы не возникло.
Забавно, что простым костылём проблема не решается. Если на фотке будет горилла, а Гугл подпишет "чернокожий", то тоже оскорбление получается.
Думаю, что ещё имеет место "ошибка выжившего". Я не встречал статей в духе "мы уволили нашего ключевого разработчика, и бизнес умер", или хотя бы "мы уволили нашего ключевого разработчика, и темп роста компании упал в 2 раза".
На ум приходит лишь одна история, когда компания осознала проблему и была вынуждена вернуть ключевого сотрудника. Это Apple.
выгонять - не стремятся. Но многие компании не стремятся и удерживать такого сотрудника. Парадокс, но менеджменту психологически проще расстаться с текущим сотрудником, который просит прибавку ( мысль менеджера "я сейчас плачу X, а теперь должен платить X+Y за ту же работу?" ) и нанять нового сотрудника за Z денег, где Z > X+Y , потому что "нам нужен сотрудник, а рынок труда предлагает только за Z или больше". На Хабре было несколько статей на эту тему.
Тем не менее, в формуле написано "не меньше,чем". Это разные вещи, вообще-то
Как замечательно перекликается с соседней статьёй про фотографа!
проблема кодирования - явно в символе "$". Нельзя ли как-то заэскейпить строчку?
Так выкидывайте. Только не говорите потом, что "Скрам не работает". Скрам декларирует, что при соблюдении всех правил участники получат определённые плюшки. Не соблюдаете какие-то правила - теряете плюшки, в целом или частично. Иногда довольно неочевидным образом.
Я трактую эти фрагменты иначе, взгляните:
Это значит, что все Разработчики в Scrum Team имеют одинаковый авторитет и права. Если этот принцип нарушается, то команда теряет ценности Скрама, со всеми последствиями.
Это не означает, что это команда из фулл-стэков. Это означает, что если (утрируя) на каждый спринт Вы то добавляете в команду участников с нужными компетенциями и убираете из команды участников с невостребованными компетенциями, то у Вас нет команды.
СМ контролирует соответствие Скраму, но не решения участников. СМ не распределяет задачи между Разработчиками - они делают это самостоятельно через консенсус.
Тем более, никакой вышестоящий начальник не влияет на решения команды. (Зато, например, он может распустить саму команду).
Этакое "дерганье за косички", но стороны взрослой (физически) женщины?
Я правильно показал в цитате, что все эти слова - единая характеристика одного человека ( некоего интроверта ) другим человеком ( неким экстравертом)?
Если да, то этот экстраверт довольно любопытная личность: намеренно наносит людям обиды, прощупывая, насколько сильно их можно "топтать". Интроверт "не прощупывается", и экстраверта это беспокоит; он понимает, что если будет вспышка агрессии, то при последующем "разборе полётов" виноват будет именно он ( так как зашёл слишком далеко).
Откуда я делаю вывод о намеренном нанесении обид: раз экстраверт говорит "впечатление, что копит обиды" - значит, он знает: есть, что копить.
В целом статья разочаровала. Много воды, мало по теме. Частные претензии:
Это, в лучше случае, самообман. Возьмите физический сервер с SSD‑ или NVMe‑дисками, а затем возьмите облачный, и сравните показатели вставки/изменения/удаления записей.
Кэширование не решает проблем скорости. Кэширование решает проблемы масштабирования. Если у Вас промахи кэша - это 99 случаев из 100, то кэш бесполезен.
В случае Битрикса это нерелеватно - функционал "из коробки" не имеет микросервисной архитектуры.
Отдельный сервер Redis
Отдельный сервер MySQL
Отдельный сервер PHP
- всё это - не микросервисы.
Так контролирующая компания - не китайская, а американская. Так что ничего удивительного.
Непонятно, как у вас сочетается "много чего за кэшами" и "1650 запросов на один заказ".
Думаю, если бы вы расписали статистику как:
сценарий с оформлением заказа - K запросов,
сценарии без оформления заказа ("просмотры") - N1-N2 запросов, в среднем M запросов,
заказов в минуту столько-то,
просмотров в минуту столько-то,
то было бы нагляднее.
С 1909 года ничего не изменилось!
Рекомендую автору для изучения функцию preg_quote
зависит от тематики. На интернет-магазинах ( не маркетплейсах) рекламы обычно нет.
Можете рассказать, на каких мощностях это работает? Каков размер БД? Что вы делаете с историческими данными ( например, задачи или сделки, закрытые год назад)?
Не первый раз встречаю, как пишут детальное регулярное выражение, и не понимаю, зачем?
например:
failregex = ^\s*[[a-z]+] \d+#\d+: *\d+ limiting requests, excess: [\d.]+ by zone "(?:%(ngx_limit_req_zones)s)", client: <HOST>,
Почему бы не записать проще:
failregex = .+ limiting requests, excess: .+ client: <HOST>,
?