Pull to refresh
85
0
Кирилл Орлов @DiverOfDark

Разработчик / DevOps

Send message
Это довольно просто, но я этого не смогу сделать, т.к. не пользуюсь ими.
я хочу прикрутить к BT ещё раздел с личным инвестиционным планом, это что-то похожее, но не могу сказать когда это произойдёт.
Я пытался, у меня их интеграция с банками работала через раз :(
Скорее вкусовщина и интерес.
Спасибо, посмотрю, выглядит как нечто очень близкое, только, возможно, чуть более mature.
Интеграция с банками (и не только) — это то, что больше всего болело у меня, когда я делал свое решение.
На самом деле там миллион нюансов :(…
А чтобы появился сбер, втб, тиньков, younameit-банк — надо чтобы кто-то написал для них провайдера — я ими не пользуюсь :(.
Но там по сути довольно просто всё, Selenium-ом дергаются онлайн банки, вот пример как это выглядит для райффайзена:
github.com/DiverOfDark/BudgetTracker/blob/master/BudgetTracker/Scrapers/RaiffeisenScraper.cs
Т.е. дописать не сложно, было бы желание, да доступ к онлайн-банку)
Спасибо что напоминаешь! Обещаю что напишу статью чуть позже.

Тем не менее, для нетерпеливых есть довольно подробный README на GitHub.
Если это Active-Active, как вы конфликты разрешать будете?

Это то, о чем я и писал в «планах на будущее» — либо распределенные транзакции, либо «кто последний, тот и прав». Оба варианта так себе, но для pet project-ов подойдёт.

Понимаете, за HA Redis отвечаете не вы. Вам не надо думать, как он устроен, как разрешены конфликты, что там и как.

Не согласен с подходом. То что вы можете найти hosted ha redis, или перенести ответственность на другую команду / SRE — не означает что не стоит думать о том, что делать когда(не если, а когда) оно приляжет / потеряются данные за последние N минут.

Но в ряде случаев вы правы, если это уже не pet-project — то с т.з. рисков — проще писать всё в отдельную базу данных, которую не ты администрируешь. А лучше сразу в облако — оно-то точно не упадет.
Если ломается запись в хранилище — это вроде как раз решается retry-политиками?

Допустим мы делаем Active-Active решение из N инстансов, каждый со своим хранилищем и условно-мгновенной репликацией друг с другом.

Да, вы правы что тут есть некоторые сложности, но не вижу значительно больших сложностей, чем иметь high-available redis (который также может упасть, к слову).
Спасибо за идеи!

1) Да, но это решается на уровне хранилища / IStorage, если цель оптимизировать потребление дискового пространства. Если цель оптимизировать потребление памяти — то такое, конечно, можно сделать, но смысла в этом я вижу мало, если честно.

Если только какой-то конкретный уникальный проект, в котором сотни тысяч текстов по >10 кбайт (а это всего лишь 1 гб!) — тогда это можно решать в рамках какого-то конкретного проекта.

2) Аналогично п.1, хотя есть другой частый кейс, который возможно имеет смысл поддерживать прямо в ObjectRepository — это хранение бинарных файлов (например, картинки?). Очевидно, что писать их прямо в underlying storage не лучшая идея, вероятно их стоит хранить рядом на диске (или в облачном object storage: S3, Azure Blob Storage).

3) TableDictionary уже реализует IEnumerable, поэтому тут уже работает обычный LINQ:
var count = repository.Set<ParentModel>().Where(v=> v.Property == "123").Count();

Я почему-то предполагал это очевидным, поэтому не упомянул в статье, каюсь.

4) Хорошая мысль! В своих проектах я делал на базе Roslyn прямо в админке консоль для ObjectRepository, можно это вынести и в отдельную тулзу.
По большому счёту это ничем не отличается от любого внешнего nosql-хранилища. Тут основной плюс в том, что это в том же самом процессе работает.
Да, это правда. С другой стороны — условно-мгновенная репликация на соседний сервис и поддержание постоянно активным хотя бы одного инстанса должно решить эту проблему, нет?
EF Core InMemoryProvider не предполагает сохранения данных куда-либо, он нужен для локальных тестов.
Также я не в курсе насколько хорошо один и тот же инстанс datacontext из ef переживает обращения из разных потоков.
Вы говорите про базу данных, а статья про слой доступа к данным в вашем приложении.

MS SQL 2014 in-memory — это возможность хранить таблицы целиком в памяти в сервере базы данных, но у вас всё равно остается слой ORM(или сырых SQL-запросов) в вашем коде, так же остается сетевой запрос за данным, т.е. нету всех тех плюсов что были описаны выше.

Корректнее было бы сравнить мой подход с кэшированием внутри Entity Framework / других ORM, и тут в моём варианте значимым отличием было бы только то, что я гарантирую отсутствие сетевых запросов / ленивых запросов при получении данных после старта.
У нас вообще адская схема — этот nginx проксирует всё на другой хост(хорошо хотя бы в том же регионе.), где крутится IIS+ASP.NET приложение, а это еще и сетевой лаг.

Но в целом с точки зрения открытия сайта — на мой взгляд стало лучше. Всё-таки ngx_pagespeed делает всякие полезные вещи типа минификации/конвертации картинок под конкретные браузеры и прочее, это точно не то, о чем хотелось бы постоянно думать :).

Меня тоже долго останавливало перенос js в днище сайта, но оказалась проблема больше психологическая чем технологическая — большая часть завелась практически без проблем.
Завелось, работает, используем:)
пример можно посмотреть на https://escapeteams.ru — позаходить под разными браузерами и посмотреть что он подставляет вместо картинок и стилей.
в целом довольно прикольно, единственное — есть некоторые сложности с кэшем, иногда проблемы с его инвалидацией при деплое новой версии. Но впринципе решается rm -rf /tmp/ngx_pagespeed && /etc/init.d/nginx restart :).
Для Ubuntu по хорошему стоило бы делать что-то такое:

apt-get source nginx
dpkg build-package -b
dpkg -i our-built-package.deb
apt-mark hold our-built-package


Сам развлекался тем что собирал nginx + ngx_pagespeed + ngx_brotli :)
lozga, вау, а про тот ресурс что вам подсказали в твиттере — я уже писал на гиктаймс:) Безумно приятно наткнуться на упоминание :)

Так что у вас есть все возможности оказать влияние на развитие проекта :)
Ну и QuestFinder — ребята весьма молодцы, отличный портал, но я все таки не считаю правильным делать такой проект владельцам квестов. :)
Сегментировать целевую аудиторию сложно. + на самом деле у некоторых квестов есть возрастные ограничения, надо с этим тоже как-то увязать.
Спасибо за идею, но пока не уверен как это лучше сделать, возможно на базе тех же тегов.
Спасибо за развернутый ответ!

1) Да, уже не в первый раз слышу что нужны теги, но пока не уверен как их качественно сделать. Сделаем.
2) Такое правда бывает? Я с таким не сталкивался.
3) Понимаете, так можно порекомендовать и неудачный квест. Я например был очень на многих квестах и далеко не все из них я бы стал рекомендовать другим. То что человек где-то был — еще не факт что это стоит рекомендовать. Делать это в сочетании с отзывом — можно подумать как, но задача как минимум нетривиальна.
4) Опять же — нету явного ранжирования. Но дорабатывать фильтрацию/сортировку — уже запланировано, добавлю и фильтры по сложности.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity