Это сильно сложнее и может принести регресс. Кроме этого количество партиций может увеличиваться настройкой кафки. Если использовать devops, то просто подрастёт количество контейнеров с приложением.
Кроме этого может оказаться, что узкое место процессор например или память и тогда добавление потоков на одной машине задачу в какой-то момент перестанет решать. А контейнеры могут подниматься на разных машинах и не имеют такого ограничения.
В этом случае без всяких доработок в коде попросят у devops поднять ещё один контейнер с этим приложением и добавить партиций на топик и обработка пойдёт пропорционально быстрее.
А разве нельзя в таком случае создать статичные суррогатное поле, которое будет при создании объекта заполняться некоторым предопределенным значением, хоть GUID - например, и его использовать как базу для расчёта hashcode? Вроде генерация GUID не очень затратна по времени и почти исключает дубликаты.
Выглядит как ошибка в Delphi, это бы описать и отправить разработчикам. А так выходить изотерика какая-то: есть странное поведение причины которого не ясны.
Прямо в точку, насчёт редактирования! При большом числе компонентов, часто проще отредактировать форму открыв dfm в notepade и найдя нужное место обычным поиском.
Если брать вариант с такси, то можно было как вариант взять брокер сообщений типа Кафки и раскидать сообщения (о бронировании машины и отмене бронирования и т. д.) по партициям топика, где ключом будет идентификатор машины.
Фронт многопоточно, через слой API пишет в брокер сообщений сообщения, которые группируются в партии по ключу и хранятся согласно порядку ввода, а бэк может выгребать и обрабатывать эти сообщения тоже многопоточно. При этом скорость работы ограничена в основном числом партиций. И если инстанс, который обрабатывает текущее сообщение упал, то сообщение в брокере останется не прочитанных и следующий инстанс его штатно подберёт и обработает, главное чтобы весь процесс обработки в конкретном инстансе был реализован так, чтобы при падении не оставалось мусора в БД.
А тут вероятно все будет асимптотически сходиться к какому-то предельному значению скорости исполнения программы и каждая последующая итерация будет давать все меньший и меньший прирост скорости.
Ну например, нажал кнопку, сработало событие. И оценивать время от его начала до окончания. Если время превышает лимит, отключать этот скрипт как невалидный. Ну или если потребление памяти страницей превышает лимит гасить страницу, сейчас иногда бывает пару дней страница повисит в фоне и вместо 50МБ начинает занимать 1-2ГБ, а после перезагрузки страницы снова норма.
А вот интересно, если бы во все браузера встроить код, который бы рубил страницу, если она не загрузилась (со всеми скриптами) полностью условно за 1 сек, это бы стимулировало писать более легковесные и качественные Web приложения? Ну т. е.
как то оценивать качество страниц при загрузке и если они тратят слишком много ресурсов (память, процессор, диск, много что-то в фоне подолгу считают), то рубить загрузку. Хотя наверное это разработчикам браузеров не нужно.
Согласен. Но в описании про это особо не описано и нет критериев, когда нужно выделять код в процедуру, а когда не нужно, т.е. по факту такое решение должен принимать не рядовой разработчик, а midl или кто повыше, с пониманием бизнеса и того как оно в коде реализовано (а у него время не резиновое, его внимания куча вопрос требует). Т.е. человек со стороны, не знакомый с кодом или с не большим опытом, такое не потянет (я про аутсорсеров или джунов например).
Для рядовых разработчиков обычно создают простые правила (например стандарт кодирования принятый в конкретной команде или good practice), как себя вести в какой-то ситуации и DRY мне кажется тут более понятная парадигма (бери то что уже сделано не изобретай велосипед)
Из минусов дублирования кода я вижу такой: прилетит требование поменять бизнес логику, а она вместо одной процедуру размазана по коду. И будут несколько команд делать одно и то же в разных местах и наверняка по разному. И добавят вместо условной одной ошибки в процедуре, N ошибок в разных местах и не факт, что вообще найдут все места, где поменять нужно. Поддерживать такое очень сложно потом.
Это сильно сложнее и может принести регресс. Кроме этого количество партиций может увеличиваться настройкой кафки. Если использовать devops, то просто подрастёт количество контейнеров с приложением.
Кроме этого может оказаться, что узкое место процессор например или память и тогда добавление потоков на одной машине задачу в какой-то момент перестанет решать. А контейнеры могут подниматься на разных машинах и не имеют такого ограничения.
В этом случае без всяких доработок в коде попросят у devops поднять ещё один контейнер с этим приложением и добавить партиций на топик и обработка пойдёт пропорционально быстрее.
А разве нельзя в таком случае создать статичные суррогатное поле, которое будет при создании объекта заполняться некоторым предопределенным значением, хоть GUID - например, и его использовать как базу для расчёта hashcode? Вроде генерация GUID не очень затратна по времени и почти исключает дубликаты.
Выглядит как ошибка в Delphi, это бы описать и отправить разработчикам. А так выходить изотерика какая-то: есть странное поведение причины которого не ясны.
А в чем хакерствр? Dfm такой же plain text как html, xml или json.
Прямо в точку, насчёт редактирования! При большом числе компонентов, часто проще отредактировать форму открыв dfm в notepade и найдя нужное место обычным поиском.
В условиях импортозамешения выбор становиться не таким богатым :(
Если брать вариант с такси, то можно было как вариант взять брокер сообщений типа Кафки и раскидать сообщения (о бронировании машины и отмене бронирования и т. д.) по партициям топика, где ключом будет идентификатор машины.
Фронт многопоточно, через слой API пишет в брокер сообщений сообщения, которые группируются в партии по ключу и хранятся согласно порядку ввода, а бэк может выгребать и обрабатывать эти сообщения тоже многопоточно. При этом скорость работы ограничена в основном числом партиций. И если инстанс, который обрабатывает текущее сообщение упал, то сообщение в брокере останется не прочитанных и следующий инстанс его штатно подберёт и обработает, главное чтобы весь процесс обработки в конкретном инстансе был реализован так, чтобы при падении не оставалось мусора в БД.
Могут под видом санкций порезать сервис для некоторых регионов и ничего с этим не сделаешь. Работало и перестало.
Ну например, нажал кнопку, сработало событие. И оценивать время от его начала до окончания. Если время превышает лимит, отключать этот скрипт как невалидный. Ну или если потребление памяти страницей превышает лимит гасить страницу, сейчас иногда бывает пару дней страница повисит в фоне и вместо 50МБ начинает занимать 1-2ГБ, а после перезагрузки страницы снова норма.
А вот интересно, если бы во все браузера встроить код, который бы рубил страницу, если она не загрузилась (со всеми скриптами) полностью условно за 1 сек, это бы стимулировало писать более легковесные и качественные Web приложения? Ну т. е.
как то оценивать качество страниц при загрузке и если они тратят слишком много ресурсов (память, процессор, диск, много что-то в фоне подолгу считают), то рубить загрузку. Хотя наверное это разработчикам браузеров не нужно.
Habra Home — про жизнь айтишников, кто, где, как устроился.
Требуются ли права sa для работы утилиты, ну или иначе: какие нужны права для работы этой утилиты?
Для рядовых разработчиков обычно создают простые правила (например стандарт кодирования принятый в конкретной команде или good practice), как себя вести в какой-то ситуации и DRY мне кажется тут более понятная парадигма (бери то что уже сделано не изобретай велосипед)
Из минусов дублирования кода я вижу такой: прилетит требование поменять бизнес логику, а она вместо одной процедуру размазана по коду. И будут несколько команд делать одно и то же в разных местах и наверняка по разному. И добавят вместо условной одной ошибки в процедуре, N ошибок в разных местах и не факт, что вообще найдут все места, где поменять нужно. Поддерживать такое очень сложно потом.
Язык английский, а текст русский
<html lang="en"
<title Скорочтец
Там ведь энергия передается через электромагнитное поле, как в трансформаторе.