Телеграмм чат группы itarchitect страница 2553

parrot.ru

Рейтинг популярных групп и каналов

В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Архитектура ИТ-решений

1922 membersпожаловаться на группу

2020 January 22

NK

Nikita Kiselev in Архитектура ИТ-решений

В систему поступают новые данные постоянно. Тестировщику нужно проверить в том числе и работу с новыми данными.

Хм. Сейчас написал, и понял, что новые данные могут поступать по новой механике, и это тоже тестировщику нужно проверить.

Тогда получается, что нужно просто на стейджинг завести тот же поток данных, что и на прод.

если есть такая возможность - то самое правильно ерешение

источник

11:29пожаловаться #1

DS

Daniyar S in Архитектура ИТ-решений

Там же их можно и анонимизировать как раз.

источник

11:29пожаловаться #2

RT

Roman Tsirulnikov in Архитектура ИТ-решений

Сегодня интересный материал по новостям прошел

When to Refactor

Here's a rule of thumb: If your reason for rewriting the code is that you don't understand it, you should not rewrite it. Instead, you should spend the time trying to understand the code. Once you understand it, refactor the code to make it easier for the next person to understand.

https://www.justindfuller.com/2020/01/why-do-we-fall-into-the-rewrite-trap/

Why do we fall into the rewrite trap?

One of my favorite reads is Joel Spolsky's Things You Should Never Do. He wrote this post almost twenty years ago, outlining the downfall of Netscape and others because they spent years rewriting working code. His solution is, unsurprisingly, to refactor. About a year before Joel wrote Things You Should Never Do, Martin Fowler published his popular book, Refactoring: Improving the Design of Existing Code.
So, my question is, if we as a community figured out — twenty years ago — that we should stop rewriting programs, why is it still commonly done today?

источник

13:03пожаловаться #3

ВК

Владислав Козуля in Архитектура ИТ-решений

Осётр, Да

источник

14:38пожаловаться #4

AS

Andrei Soloschak in Архитектура ИТ-решений

Roman Tsirulnikov

Сегодня интересный материал по новостям прошел

When to Refactor

Here's a rule of thumb: If your reason for rewriting the code is that you don't understand it, you should not rewrite it. Instead, you should spend the time trying to understand the code. Once you understand it, refactor the code to make it easier for the next person to understand.

https://www.justindfuller.com/2020/01/why-do-we-fall-into-the-rewrite-trap/

Why do we fall into the rewrite trap?

One of my favorite reads is Joel Spolsky's Things You Should Never Do. He wrote this post almost twenty years ago, outlining the downfall of Netscape and others because they spent years rewriting working code. His solution is, unsurprisingly, to refactor. About a year before Joel wrote Things You Should Never Do, Martin Fowler published his popular book, Refactoring: Improving the Design of Existing Code.
So, my question is, if we as a community figured out — twenty years ago — that we should stop rewriting programs, why is it still commonly done today?

Да, неплохая статья. Вот например подход, который подходит для улучшения архитектуры микросервиса(ов).
This is one reason that, as Sam Newnan writes in Building Microservices, some people suggest to keep microservices small enough to rewrite in 2 weeks or less. There's no huge loss if a total overhaul is needed. You could rewrite it during a slow season.

источник

15:34пожаловаться #5

VU

Vitaly U in Архитектура ИТ-решений

В каком смысле справится? Мы говорим о хранение ~ 473 040 000 000 сообщений, если я правильно понял (1.5 года по 10000 сообщений в секунду)

Господа, а никто не знает продолжения истории? Была ли в итоге реализация хранения 10000 сообщений в секунду в течении 1.5 года на кафке или теорией и закончилось?

источник

19:12пожаловаться #6

Ms

Mutko says in Архитектура ИТ-решений

У кафки ретеншен меньше:)

источник

19:14пожаловаться #7

AP

Alexey Pryanishnikov in Архитектура ИТ-решений

Не вижу проблемы ссыпать на диск, лишь бы диска хватило.
Или вам не только хранить, а ещё и доступ к этим сообщениям нужен? ;)))

источник

19:16пожаловаться #8

Ms

Mutko says in Архитектура ИТ-решений

В случае с cqrs вам агрегировать ещё надо по дате

источник

19:17пожаловаться #9

VU

Vitaly U in Архитектура ИТ-решений

Так это не мне надо было, я просто тему вспомнил, подумал, что может за это время уже реализовали

источник

19:21пожаловаться #10

VU

Vitaly U in Архитектура ИТ-решений

https://t.me/itarchitect/10172

Старый Хрыч in Архитектура ИТ-решений

rabbitmq vs kafka vs aq - что лучше для хренения сообщений в течении 1,5 года +

источник

19:22пожаловаться #11

VU

Vitaly U in Архитектура ИТ-решений

Было бы интересно посмотреть

источник

19:23пожаловаться #12

GK

Gennadiy Kruglov in Архитектура ИТ-решений

https://t.me/itarchitect/10172

Старый Хрыч in Архитектура ИТ-решений

rabbitmq vs kafka vs aq - что лучше для хренения сообщений в течении 1,5 года +

Для хренения сообщений (сохранил синтаксис автора) нужно использовать предназначенные для этого хранилища, например, Hadoop.

Брокеры сообщений для хранения сообщений не предназначены. Только в рамках политик хранения, обычно до тех пор, пока сообщения не будут обработаны потребителями.

источник

19:26пожаловаться #13

NK

Nikita Kiselev in Архитектура ИТ-решений

странная идея = хранить мессаджи в брокере )

источник

19:27пожаловаться #14

GK

Gennadiy Kruglov in Архитектура ИТ-решений

Главный вопрос - с какой целью хранить сообщения.

источник

19:27пожаловаться #15

GK

Gennadiy Kruglov in Архитектура ИТ-решений

странная идея = хранить мессаджи в брокере )

Мягко говоря

источник

19:27пожаловаться #16

p

pragus in Архитектура ИТ-решений

Старый Хрыч

rabbitmq vs kafka vs aq - что лучше для хренения сообщений в течении 1,5 года +

😳

источник

19:29пожаловаться #17

p

pragus in Архитектура ИТ-решений

Gennadiy Kruglov

Главный вопрос - с какой целью хранить сообщения.

может человек опечатался и речь шла о "хоронить".

источник

19:30пожаловаться #18

VU

Vitaly U in Архитектура ИТ-решений

Gennadiy Kruglov

Для хренения сообщений (сохранил синтаксис автора) нужно использовать предназначенные для этого хранилища, например, Hadoop.

Брокеры сообщений для хранения сообщений не предназначены. Только в рамках политик хранения, обычно до тех пор, пока сообщения не будут обработаны потребителями.

Это мы ещё тогда проговорили, но вот типа требование жесткое было прям в транспорте хранить, я поэтому и спрашиваю)

источник

19:31пожаловаться #19

VU

Vitaly U in Архитектура ИТ-решений

И вроде даже сторонники идеи были
https://t.me/itarchitect/10218

Leonid Vygovskiy in Архитектура ИТ-решений

Kafka можно рассматривать как хранилище сообщений. Если выделить ей места на hdd достаточно для сохранения всех данных в течении нужного периода времени, она справится https://www.confluent.io/blog/okay-store-data-apache-kafka/

источник

19:32пожаловаться #20