Огромное спасибо за комментарий! Я изучу вопрос, поскольку отсутствия шедулера - было единственным блокером, почему окончательно нельзя было переехать на vercel.
Одно но: он не работает в превью деплойментах :) Нужно обязательно сделать продакшн и тогда все работает. Вот документация по этому поводу: https://vercel.com/docs/cron-jobs
Про продакшен и превью у меня была отдельная история, но я уже в них разобрался =)
Так же с удовольствием расскажу, если хотите, как у меня уже третий год живёт 2 бота на firebase совершенно бесплатно и стабильно.
Я даже не пробовал firebase, но меня всем устроит vercel, когда разберусь с cron.
Если дело про TW, то там дело не в боте же, а впринципе, что сервис Apps не готов к работе. Вы с таким же успехом и на php можете там что-то задеплоить и вордпресс условно упаковать, но зависнуть при деплое по тем же причинам. Т.е. дело не в боте. Рискну предположить, что просто напросто, не хватает ресурсов на сервере, где у них разворачиваются apps. Это по проблеме cpu 100%.
Не вижу смысла с точки зрения архитектуры, интегрировать в сервис еще одну синхронную интеграцию, которая должна на лету переводить на нужный язык.
Вижу риски, что поскольку это синхронная интеграция, то критично время ответа. А если сервис долго отвечает или не отвечает, то тогда нужно делать альтернативное решение на своей стороне и заводить свой шаблон с переводом.
А если я завожу, для перестраховки, свой шаблон с переводом, зачем мне интеграция с сервисом, повышающая риски?
Как вариант, я бы мог выслать весь словарь один раз и получить его же на разных языках. Прихранить себе и бесплатно использовать.
Похоже, основные клиенты такого сервиса, это аудио/видео сервисы с аннотацией-переводом. Если перевода не будет в видео или аудио конференции - это не блокер. А если текста не будет на кнопке оплатить (например), потому что сервис не ответил или отвечал долго - это блокер.
Как уже тут обсуждалось, DDD - это сказочное существо, которое мало кто видел вживую. Но абсолютно точно, что применение хотя бы каких то принципов из DDD, не обязательно всех, это уже отличный шаг, эволюция, как заметил автор.
DDD - это таинственный зверь...но при этом никто этого зверя в глаза не видел
Это не совсем так. DDD — не "волшебная таблетка", а набор практик для сложных доменов, где бизнес-логика запутана и меняется. Его редко применяют "по учебнику", потому что:
Каждый домен уникален, и решения адаптируются под контекст.
Реальные примеры часто закрыты NDA (банки, и тд).
Пример открытых проектов:
Домены в системах типа Apache Isis (хотя это уже "тяжелая артиллерия").
Но да, многие статьи действительно поверхностны, т.к. авторы пересказывают термины, не погружаясь в суть. Это проблема не DDD, а качества контента или той аудитории, для которой пишется контент.
-У тебя есть карта реальный пример проекта?
-Лучше! У меня рисунок карты гексагональной архитектуры.
Схемы - это лишь инструмент для визуализации. Суть в том, чтобы:
Изолировать доменную логику от инфраструктуры (базы, фреймворки)
Упростить тестирование
Пример: если вы отделяете логику оплаты заказа от способа оплаты (Робокасса, эквайринг), это уже элемент гексагонального подхода. Многие так делают, даже не зная терминов.
Согласен, что вокруг DDD много шума. Но его ценность - не в модных терминах, а в фокусе на смысле, а не на технологиях. Если у вас есть примеры, где DDD не сработал — давайте обсудим! Мне самому интересно, где границы его применимости. Именно поэтому я и писал эту стать. Именно поэтому я и рисовал красивые графики. И именно поэтому я отвечаю подробно ваш комментарий.
Я бы добавил это в пользу варианта "Я работаю в интерпрайзе и не понимаю проблем автора."
Судя по рейтингу, моя история не смогла найти отклика у большинства читателей. У меня есть небольшие гипотезы, хочу либо их подтвердить, либо исключить.
Вот, например, на вашем примере хочется декомпозировать этот вариант - "Я — участник инновационной команды в большом интерпрайзе, но процессы нам не мешают"
Если не затруднит, Ваш ответ и ответ других читателей был бы интересен:
Вы участник создание процессов (Может вы методолг или менеджер/руководитель)? Или может вы участник каких-то коровых (глубокий бек) команд? Или может Вы имели ввиду, что процессы живут сами по себе, а вы сами по себе?=)
Я в начале пути — думал что пассивный доход с биржи — реален
Спустя пару лет и слитые депы, заявляю ответственно: Нет такой стратегии, которая стабильно приносит пассив.
Чего я только не перепробовал — и простые MA пересечения, всякие индикаторы. И сложный подсчет 5ти волн Эллиотта — все это не больше, чем помощник для трейдера, который торгует сам. Но это точно не пассивный доход.
Поэтому ваш заголовок, как минимум, вводит в заблуждение.
P.S. Если бы такая стратегия была и Вы решились бы из доброты ее опубликовать, она бы перестала быть доходной.
Я скорее больше прогер, чем трейдер.
Питон не умею, но разобрался в pine editor в Tradingview — это дает возможность наложить свой алгоритм на любой инструмент. Ну и посмотреть отчет.
Я открыл для себя уйму нового, вот несколько самых важных пунктов:
Чем больше сделок (маленький ТФ) — тем меньше профит, из-за комиссии
Почти ЛЮБАЯ стратегия приносит профит, если она выше 4х часового таймфрема
И самое важное: системность выполнения условий, выполнять одни и те же алгоритмы.
Тут не увидел, чтобы кто-то говорил про скорость интернета. Неужели у меня одного проблемы с высокоскоростным стабильным подключением ?)
Примерно год назад пробовал через PlayKey, поиграть в ГТА по сети. Были лаги, условно до 1сек. Я нажимаю движение и только через 0,5-1 сек герой двигается. По сети с таким лагом играть мучительно.
Но тогда же я решил, что с такой проблемой встречаются большинство игроков, играющих из России. Все-таки интернет у нас не так хорош, чтобы поддерживать стабильную высокую скорость.
Даже описание проекта крайне сложное, конечно, может быть это впечатление возникает от избалованности к простым решениям на рынке, в которых стараются все уместить в несколько предложений. Но что бы я предложил автору, так это сделать декомпозицию проекта и попробовать продвигать мелкие узконаправленные сервисы, которые легко объяснить и как следствие — легко продавать.
Я бы предложил автору
Не юрист, но думаю , что скрины не имеют никакой юридической силы.
Тем более что в браузере самому можно и 1 рубль сделать, через правку элемента, но если бы бы это можно было заверить нотариусом..
А ещё лучше, если бы было письмо, подтверждающее бронь на покупку в 2млн. Тоесть я говорю, о каком то факте, подтверждающем эту цену.
Я бы использовал яндекс, но там нет возможности разместиться не в рф. А у меня интеграция с openai.
А про Lambda от AWS спасибо, попробую.
Сегодня, после мелкого фикса в репе, запушил код, и...снова время приключений. Это заставило меня изучить комментарий @Sleitor, еще раз спасибо!
Но у vercel есть ограничения на cron для hobby проектов: https://vercel.com/docs/cron-jobs/usage-and-pricing
Однако, это натолкнуло меня на идею сделать ручку для того, чтобы ее кто-то дергал раз в N минут. Аналог cron. И тут меня спас бесплатный cron-job.org
В итоге, я окончательно перевез apps из TW на Vercel.
Огромное спасибо за комментарий! Я изучу вопрос, поскольку отсутствия шедулера - было единственным блокером, почему окончательно нельзя было переехать на vercel.
Про продакшен и превью у меня была отдельная история, но я уже в них разобрался =)
Я даже не пробовал firebase, но меня всем устроит vercel, когда разберусь с cron.
Если дело про TW, то там дело не в боте же, а впринципе, что сервис Apps не готов к работе. Вы с таким же успехом и на php можете там что-то задеплоить и вордпресс условно упаковать, но зависнуть при деплое по тем же причинам. Т.е. дело не в боте. Рискну предположить, что просто напросто, не хватает ресурсов на сервере, где у них разворачиваются apps. Это по проблеме cpu 100%.
В коде я лечил архитектуру, которая не работала на честном serverless - Vercel.
А в TW такая архитектура кушалась. Но даже после фикса, TW себя ведет так же криво, как и до фикса. Потому что там дело не в ней, а в инфре таймвеба.
Нет, я не покупал vps/vds.
Можете попробовать по урлу перейти: https://timeweb.cloud/my/apps
Это именно в timeweb cloud, там есть apps меню.
Вот еще нагуглил: https://timeweb.cloud/docs/apps и https://timeweb.cloud/services/apps
Не вижу смысла с точки зрения архитектуры, интегрировать в сервис еще одну синхронную интеграцию, которая должна на лету переводить на нужный язык.
Вижу риски, что поскольку это синхронная интеграция, то критично время ответа.
А если сервис долго отвечает или не отвечает, то тогда нужно делать альтернативное решение на своей стороне и заводить свой шаблон с переводом.
А если я завожу, для перестраховки, свой шаблон с переводом, зачем мне интеграция с сервисом, повышающая риски?
Как вариант, я бы мог выслать весь словарь один раз и получить его же на разных языках. Прихранить себе и бесплатно использовать.
Похоже, основные клиенты такого сервиса, это аудио/видео сервисы с аннотацией-переводом.
Если перевода не будет в видео или аудио конференции - это не блокер.
А если текста не будет на кнопке оплатить (например), потому что сервис не ответил или отвечал долго - это блокер.
Как уже тут обсуждалось, DDD - это сказочное существо, которое мало кто видел вживую. Но абсолютно точно, что применение хотя бы каких то принципов из DDD, не обязательно всех, это уже отличный шаг, эволюция, как заметил автор.
Абсолютно согласен, даже без полного погружения, можно брать на вооружения отдельные практики:
Единый язык (Ubiquitous Language) снижает риски недопонимания между разработчиками и бизнесом
И отдельно добавлю про Bounded Contexts, который поможет дробить монолиты на микросервисы
Это не совсем так. DDD — не "волшебная таблетка", а набор практик для сложных доменов, где бизнес-логика запутана и меняется. Его редко применяют "по учебнику", потому что:
Каждый домен уникален, и решения адаптируются под контекст.
Реальные примеры часто закрыты NDA (банки, и тд).
Пример открытых проектов:
Домены в системах типа Apache Isis (хотя это уже "тяжелая артиллерия").
Но да, многие статьи действительно поверхностны, т.к. авторы пересказывают термины, не погружаясь в суть. Это проблема не DDD, а качества контента или той аудитории, для которой пишется контент.
Схемы - это лишь инструмент для визуализации. Суть в том, чтобы:
Изолировать доменную логику от инфраструктуры (базы, фреймворки)
Упростить тестирование
Пример: если вы отделяете логику оплаты заказа от способа оплаты (Робокасса, эквайринг), это уже элемент гексагонального подхода. Многие так делают, даже не зная терминов.
Согласен, что вокруг DDD много шума. Но его ценность - не в модных терминах, а в фокусе на смысле, а не на технологиях. Если у вас есть примеры, где DDD не сработал — давайте обсудим! Мне самому интересно, где границы его применимости. Именно поэтому я и писал эту стать. Именно поэтому я и рисовал красивые графики. И именно поэтому я отвечаю подробно ваш комментарий.
Я бы добавил это в пользу варианта "Я работаю в интерпрайзе и не понимаю проблем автора."
Судя по рейтингу, моя история не смогла найти отклика у большинства читателей.
У меня есть небольшие гипотезы, хочу либо их подтвердить, либо исключить.
Вот, например, на вашем примере хочется декомпозировать этот вариант - "Я — участник инновационной команды в большом интерпрайзе, но процессы нам не мешают"
Если не затруднит, Ваш ответ и ответ других читателей был бы интересен:
Вы участник создание процессов (Может вы методолг или менеджер/руководитель)?
Или может вы участник каких-то коровых (глубокий бек) команд?
Или может Вы имели ввиду, что процессы живут сами по себе, а вы сами по себе?=)
А в заголовке написано "… трейд..."
Спустя пару лет и слитые депы, заявляю ответственно: Нет такой стратегии, которая стабильно приносит пассив.
Чего я только не перепробовал — и простые MA пересечения, всякие индикаторы. И сложный подсчет 5ти волн Эллиотта — все это не больше, чем помощник для трейдера, который торгует сам. Но это точно не пассивный доход.
Поэтому ваш заголовок, как минимум, вводит в заблуждение.
P.S. Если бы такая стратегия была и Вы решились бы из доброты ее опубликовать, она бы перестала быть доходной.
Имеет прямую зависимость с
Первое без второго не бывает.
А второе без первого может быть.
Питон не умею, но разобрался в pine editor в Tradingview — это дает возможность наложить свой алгоритм на любой инструмент. Ну и посмотреть отчет.
Я открыл для себя уйму нового, вот несколько самых важных пунктов:
И самое важное: системность выполнения условий, выполнять одни и те же алгоритмы.
Интересны итоги этой идеи!
Примерно год назад пробовал через PlayKey, поиграть в ГТА по сети. Были лаги, условно до 1сек. Я нажимаю движение и только через 0,5-1 сек герой двигается. По сети с таким лагом играть мучительно.
Но тогда же я решил, что с такой проблемой встречаются большинство игроков, играющих из России. Все-таки интернет у нас не так хорош, чтобы поддерживать стабильную высокую скорость.
Или это был мой опыт и у остальных все было ок?)
Я бы предложил автору