IM
спасибо🦆
Size: a a a
2020 February 19
AD
а научите валидировать технические идеи? хочу что-то в духе customer development или lean startup, но только для тех идей. что-то так и не понял как это делать красиво
AD
всякие “спросите маму” и makebook.io знаю и читал
IN
всякие “спросите маму” и makebook.io знаю и читал
Надо чонть померить сначала и показать почему щас все плохо и почему потом станет хорошо
IN
Лучше всего мерить в бабках
A
A
технические идеи рождаются потребностями, если потребности нет, а техническую идею хочется, то есть риск потратить время впустую
AD
Надо чонть померить сначала и показать почему щас все плохо и почему потом станет хорошо
с метриками не все так просто
O
Я дальше ковырялся с DI и пока пришёл к тому, что статические зависимости удобно пробрасывать через драй инжект, а динамические через драй эффект резолв, лол.
Я пока не знаю на какие камни я наткнусь, но вышлядит прикольно.
Ещё я боюсь, что мне захочется все атрибуты пробрасывать через эффект. Типа такого:
Я пока не до конца понимаю, где та грань, которая отделяет удобство эффектов от излишнего использования.
Я пока не знаю на какие камни я наткнусь, но вышлядит прикольно.
Ещё я боюсь, что мне захочется все атрибуты пробрасывать через эффект. Типа такого:
require 'dry/effects'
include Dry::Effects::Handler.Resolve
class BillOrder
include Dry::Effects.Resolve(:order, :tariff)
def call
order[:cost].to_i * tariff
end
end
provide(order: { cost: 1 }, tariff: 100_500) do
puts BillOrder.new.call
end
Я пока не до конца понимаю, где та грань, которая отделяет удобство эффектов от излишнего использования.
AD
Надо чонть померить сначала и показать почему щас все плохо и почему потом станет хорошо
вот банальный пример, у меня есть теория, что миру нужен еще один трейлблейзер (условный пример). вот какие метрики в конкретном случае ты предлагаешь брать и как провалидировать идею до реализации?
MS
Я дальше ковырялся с DI и пока пришёл к тому, что статические зависимости удобно пробрасывать через драй инжект, а динамические через драй эффект резолв, лол.
Я пока не знаю на какие камни я наткнусь, но вышлядит прикольно.
Ещё я боюсь, что мне захочется все атрибуты пробрасывать через эффект. Типа такого:
Я пока не до конца понимаю, где та грань, которая отделяет удобство эффектов от излишнего использования.
Я пока не знаю на какие камни я наткнусь, но вышлядит прикольно.
Ещё я боюсь, что мне захочется все атрибуты пробрасывать через эффект. Типа такого:
require 'dry/effects'
include Dry::Effects::Handler.Resolve
class BillOrder
include Dry::Effects.Resolve(:order, :tariff)
def call
order[:cost].to_i * tariff
end
end
provide(order: { cost: 1 }, tariff: 100_500) do
puts BillOrder.new.call
end
Я пока не до конца понимаю, где та грань, которая отделяет удобство эффектов от излишнего использования.
То есть ты вместо того чтобы передать их параметром в new ты используешь эффекты?
MS
Это похоже на забивание гвоздей микроскопом
IN
вот банальный пример, у меня есть теория, что миру нужен еще один трейлблейзер (условный пример). вот какие метрики в конкретном случае ты предлагаешь брать и как провалидировать идею до реализации?
Ты не поверишь, у меня такая же идея и у меня есть гипотеза как это померить))
IN
Но тут в двух словах не опишешь
AD
То есть ты вместо того чтобы передать их параметром в new ты используешь эффекты?
есть один специфический кейс, когда это оправдано и котоый я бы взял себе. можно добавить мониторинг для резолва зависимостей (и для регистрации) и на этом навернуть кучу всего
A
вот банальный пример, у меня есть теория, что миру нужен еще один трейлблейзер (условный пример). вот какие метрики в конкретном случае ты предлагаешь брать и как провалидировать идею до реализации?
если у тебя/в компании/у друзей нет проекта, котороый остро нуждается в решении, которое можно сформулировать, как еще один трейлблейзер, то миру, скорее всего, не нужен еще один трейлблейзер
AD
Ты не поверишь, у меня такая же идея и у меня есть гипотеза как это померить))
ну, у меня нет идеи связанной с сервис объектами или трейлблейзером. мне интересно понять на практике все это
MS
если у тебя/в компании/у друзей нет проекта, котороый остро нуждается в решении, которое можно сформулировать, как еще один трейлблейзер, то миру, скорее всего, не нужен еще один трейлблейзер
Потому что и первый то не очень миру нужен был