Честно говоря, я довольно с большим трудом представляю себе военных, заказывающих у Яндекса… а что собственно — не Яндекс.Почту же? Теоретически могу представить себе, что армии нужны дата-центры, но как-то именно Яндекс — не самая близкая к государству корпорация, способная на такое.
Что-то может государству и продадут, но неужели прям такой проектище с кучей партнёров чисто ради этого будут организовывать?
А вот контролировать производство своих серверов с учётом всё дорожающей китайской рабочей силы и заодно получить немного рынка тех, кому нужно импортнозамещение железа — почему нет.
Всё возможно, бухгалтерские книги Яндекса я не видел, и конечно любая вменяемая корпорация хотела бы зарабатывать на всём. Однако, ИМХО, подход тут скорее такой:
— китайцы становятся дороговаты и заказы тонн оборудования наверняка регулярно натыкаются на трудности
— так может уже можно и у себя производить машины
— а заодно что-то продадим импортозамещающим и под это дело подтянем финансы ВТБ
— ну, что-то может и государство за имеотрозамещение подкинет
Внимательно прочитал «сценарии использования», но всё равно не получается представить себе ситуацию, когда доступа только к IDE было бы достаточно :/
Разрабатываем хоть десктопное приложение, хоть веб-приложение, хоть консольное — его ж надо хоть иногда запускать и смотреть результаты, а как это делать, если удалённо доступна лишь IDE? Получается, что более-менее просто можно только запускать автотесты и command line apps (если они настроены именно в IDE через Run Configurations)?
Скорее всего я упускаю что-то очевидное. olegchir, с помощью Projector можно же как-то потыкать в web приложение запущенное на машине с IDE или внутри корпоративного облака?
Желание реактивности понятно, если клиенты приходят многими тысячами, но ведь не одним же WebFlux живы. Лично я не работал ни с RxJava, ни с Akka, ни с Vert.x, но ТС наверняка ведь выбрал WebFlux не просто подкидыванием монетки, вот и интересно пришёл ли бы он снова к WebFlux, если бы пришлось выбирать заново.
Да и реактивность ради возможности тысяч и десятков тысяч соединений ценой сложности отладки несинхронного кода выглядит весьма интересным вопросом, которым скорее всего задавался ТС.
> придётся либо городить сложную инфраструктуру
Подозреваю, что ТС тоже о таком задумывался и было бы очень интересно узнать результаты размышлений (или даже экспериментов)?
Скажем, если реактивность в случае ТС даёт выигрыш не в двадцать раз по количеству быстро обслуживаемых соединений, а в два-три раза, то не дешевле было бы просто поднять две-три копии сервиса (возможно на той же физической коробочке) а нагрузку выравнивать лоад балансером и парой сервисов очередей?
Инфраструктура была бы сложнее, но ничего запредельно сложного + возможность жить при части упавших инстансов как приятный побочный эффект, а отлаживать синхронный код было бы заметно проще. Конечно же это всё — спекуляции без погружения в подробности проекта — вот и интересно было бы узнать мысли pprriisstt об этом.
— трудности с незакрытыми соединениями, приведшими аж к анализу трафика через WireShark и в результате оказалось, что Reactor Netty по умолчанию не умеет в таймауты
— своя подпорка для обхода работы с пулами соединений по умолчанию
— удобное программирование реактивности через fluent цепочек настолько дорого, что приходится заталкивать всё в один обработчик
— .groupBy и .flatMap в WebFlux написаны так, что течёт память и останавливается обработка сообщений
— ...
И при этом в качестве итогов вы пишете, что «Reactor Netty – удобен, гибок и быстр. », а в Spring WebFlux можно обрабатывать события с «витиеватой логикой с нелинейной обработкой и ветвлениями».
В статье перечислено довольно много проблем возникших в процессе реализации и не самых лёгких для решения проблем. Честно говоря, увидев обещание трудностей с fluent цепочками и «оригинальными» решениями WebFlux столь базовых вещей как groupBy, я бы три раза задумался перед тем, как брать его в работу — совсем не интересно терять удобство и строить патчи вокруг WebFlux, если только это не компенсируется ну очень большими плюсами.
pprriisstt, после всех этих приключений, вы всё ещё считаете Netty + WebFlux хорошим выбором или сожалеете, что не было времени/желания изучить возможные альтернативы подробнее? Или есть какие-то гигансткие плюсы у этого решения? Например, может быть производительность рвёт конкурентов настолько сильно, что вы готовы мириться с трудностями?
> «Первый внос»
Спасибо! Исправлю к следующей версии!
> Поточнее учесть страховые взносы — а надо ли?
Именно так. Не только страховые взносы, но и их тоже. У меня не очень получалось оценить их эффект «на глазок», вот и визуализировал. То же самое касается ремонта и оплаты услуг риэлтера.
> А где досрочные погашения? Это куда важнее всей мишуры с не ипотечными расходами?
Для принятия решения о покупке мне это кажется не очень важным (ибо неплохо моделируется например как бы сокращением длительности кредита), но вообще возможность важная. Спасибо за идею, попробую добавить.
> Где оценка инфляции? Ведь это тоже важно?
Финальная цель какой-нибудь будущей версии — сравнить эффективность покупки квартиры с ОФЗ, например, а тогда не очень важно считать в ценах стартового года или с учётом инфляции. Но конечно, можно и учесть — подумаю.
> А вообще — если уж делать продвинутый ипотечный калькулятор — то нужно делать интеллектуальный калькулятор — которые не просто по паре (пусть и хитрых) формул посчитает графики, а рассчитает наиболее оптимальные сценарии вложения средств…
«Шаг за шагом достигнем поставленной цели».
Именно это, действительно, очень интересно. Понимание расходов — лишь первый шаг, но уже полезный в отдельности и как калькулятор, и как источник комментариев для понимания упущенных факторов.
Конкретно этот калькулятор — исключительно для расходов, чтобы определить «сколько же на самом деле мы отдадим денег за эту квартиру». Вычет, по большому счёту — тот же расход, только со знаком минус.
Добавьте колонку для вычета в " Одноразовые или почти одноразовые" и в «Накопленные суммы расходов», внесите «расход» с отрицательным знаком в тот месяц, когда налоговая скорее всего вернёт его там. И наверное, надо будет поправить источники данных в графике (скорее всего там тоже на одну колонку что-то поедет)…
Хмм… попробую так ли гибко работает добавление расходов и опубликую апдейт. В первом приближении можно добавить «отрицательные расходы» в колонку «ремонт», например.
Модифицировать для досрочных платежей, конечно можно. Спасибо за идею — подумаю. В принципе, можно провести досрочный платёж как вручную увеличенную «выплату тела» за конкретный месяц. Тогда только надо будет пересчитать формулы тела-процентов, чтобы опирались не на исходную сумму, а на остающуюся к текущему моменту. Должно быть не очень сложно — попробую сделать.
Затем же, зачем и любые другие велосипеды — потому, что не удалось найти достаточно гибкий. Не удалось найти ни одного, где можно было бы учесть ремонт и оплату коммуналки в некоторые месяцы, например.
Что-то может государству и продадут, но неужели прям такой проектище с кучей партнёров чисто ради этого будут организовывать?
А вот контролировать производство своих серверов с учётом всё дорожающей китайской рабочей силы и заодно получить немного рынка тех, кому нужно импортнозамещение железа — почему нет.
Всё возможно, бухгалтерские книги Яндекса я не видел, и конечно любая вменяемая корпорация хотела бы зарабатывать на всём. Однако, ИМХО, подход тут скорее такой:
— китайцы становятся дороговаты и заказы тонн оборудования наверняка регулярно натыкаются на трудности
— так может уже можно и у себя производить машины
— а заодно что-то продадим импортозамещающим и под это дело подтянем финансы ВТБ
— ну, что-то может и государство за имеотрозамещение подкинет
Разрабатываем хоть десктопное приложение, хоть веб-приложение, хоть консольное — его ж надо хоть иногда запускать и смотреть результаты, а как это делать, если удалённо доступна лишь IDE? Получается, что более-менее просто можно только запускать автотесты и command line apps (если они настроены именно в IDE через Run Configurations)?
Скорее всего я упускаю что-то очевидное. olegchir, с помощью Projector можно же как-то потыкать в web приложение запущенное на машине с IDE или внутри корпоративного облака?
Да и реактивность ради возможности тысяч и десятков тысяч соединений ценой сложности отладки несинхронного кода выглядит весьма интересным вопросом, которым скорее всего задавался ТС.
> придётся либо городить сложную инфраструктуру
Подозреваю, что ТС тоже о таком задумывался и было бы очень интересно узнать результаты размышлений (или даже экспериментов)?
Скажем, если реактивность в случае ТС даёт выигрыш не в двадцать раз по количеству быстро обслуживаемых соединений, а в два-три раза, то не дешевле было бы просто поднять две-три копии сервиса (возможно на той же физической коробочке) а нагрузку выравнивать лоад балансером и парой сервисов очередей?
Инфраструктура была бы сложнее, но ничего запредельно сложного + возможность жить при части упавших инстансов как приятный побочный эффект, а отлаживать синхронный код было бы заметно проще. Конечно же это всё — спекуляции без погружения в подробности проекта — вот и интересно было бы узнать мысли pprriisstt об этом.
И при этом в качестве итогов вы пишете, что «Reactor Netty – удобен, гибок и быстр. », а в Spring WebFlux можно обрабатывать события с «витиеватой логикой с нелинейной обработкой и ветвлениями».
В статье перечислено довольно много проблем возникших в процессе реализации и не самых лёгких для решения проблем. Честно говоря, увидев обещание трудностей с fluent цепочками и «оригинальными» решениями WebFlux столь базовых вещей как groupBy, я бы три раза задумался перед тем, как брать его в работу — совсем не интересно терять удобство и строить патчи вокруг WebFlux, если только это не компенсируется ну очень большими плюсами.
pprriisstt, после всех этих приключений, вы всё ещё считаете Netty + WebFlux хорошим выбором или сожалеете, что не было времени/желания изучить возможные альтернативы подробнее? Или есть какие-то гигансткие плюсы у этого решения? Например, может быть производительность рвёт конкурентов настолько сильно, что вы готовы мириться с трудностями?
Спасибо! Исправлю к следующей версии!
> Поточнее учесть страховые взносы — а надо ли?
Именно так. Не только страховые взносы, но и их тоже. У меня не очень получалось оценить их эффект «на глазок», вот и визуализировал. То же самое касается ремонта и оплаты услуг риэлтера.
> А где досрочные погашения? Это куда важнее всей мишуры с не ипотечными расходами?
Для принятия решения о покупке мне это кажется не очень важным (ибо неплохо моделируется например как бы сокращением длительности кредита), но вообще возможность важная. Спасибо за идею, попробую добавить.
> Где оценка инфляции? Ведь это тоже важно?
Финальная цель какой-нибудь будущей версии — сравнить эффективность покупки квартиры с ОФЗ, например, а тогда не очень важно считать в ценах стартового года или с учётом инфляции. Но конечно, можно и учесть — подумаю.
> А вообще — если уж делать продвинутый ипотечный калькулятор — то нужно делать интеллектуальный калькулятор — которые не просто по паре (пусть и хитрых) формул посчитает графики, а рассчитает наиболее оптимальные сценарии вложения средств…
«Шаг за шагом достигнем поставленной цели».
Именно это, действительно, очень интересно. Понимание расходов — лишь первый шаг, но уже полезный в отдельности и как калькулятор, и как источник комментариев для понимания упущенных факторов.
Добавьте колонку для вычета в " Одноразовые или почти одноразовые" и в «Накопленные суммы расходов», внесите «расход» с отрицательным знаком в тот месяц, когда налоговая скорее всего вернёт его там. И наверное, надо будет поправить источники данных в графике (скорее всего там тоже на одну колонку что-то поедет)…
Хмм… попробую так ли гибко работает добавление расходов и опубликую апдейт. В первом приближении можно добавить «отрицательные расходы» в колонку «ремонт», например.