Из того что ещё можно сделать "малой кровью" - например ReadOnly реплика БД, на которую "заварачивать" часть запросов - то же получение меню, может даже большинство GET запросов.
Идея интересная, но в текущем виде защита только от script kiddies
Основная проблема - разница в производительности недорогого смартфона 3-4 летней давности и современных ASIC майнеров "числодробилок", тут либо на смартфоне будет задержка в несколько минут и несколько процентов батареи, либо защита очень слабая.
А как всё это согласуется с SOLID? особенно с S и O?
class Order из примера:
отвечает и за совместимость продуктов и за расчёт налогов, не очень то single
содержит IsValid — который будет регулярно меняться, конфликтует с closed
Про «Удаленщиков режут в первую очередь» — категорически не согласен.
Сейчас есть серьёзная доля компаний c Remote First идеологией, у них может не быть офиса вообще, или офис может быть чисто символическим, который при всём желании не вместит всех работающих.
Возможно, такое отношение есть в компаниях, когда большая часть работает в офисе, а некоторым «разрешают» работать удалённо — тогда действительно, этот человек может считаться не таким важным, раз уж разрешили ему работать не в офисе.
Учитывая желание разговаривать по английски, не искали варианты работы на заграницу?
Последние несколько лет работаю удалённо на заказчиков не из России и более чем доволен.
Отказаться от онлайн тестирования но предложить выполнение тестового задания?
Онлайн тестирование в большинстве случаев короче и проще, а так же позволяет «размять мозг». Проходил несколько онлайн тестов за последний год, и часто было обидно что они достаточно простые.
Программисту мешает непривычная среда разработки. Как правило это веб страница, которую кандидат видит впервые и к ее интерфейсу надо привыкать в процессе теста.
Почти все современные codility/hackerrank предлагаю потренироваться на кошечках чтобы не терять время в момент тестирования.
Интересная статья, спасибо.
Пару вопросов, нет ли случаев, и как с ними бороться:
1. Есть хэш / цифровая подпись, и при изменении любого атрибута (имени, даты) — всё портится. А если подпись приватным ключом клиента?
2. С датами, сдвиг без изменения возраста не возможен в принципе. Возможен только без изменения «количества лет» на определённую дату. Поменяли дату на 25 дней раньше, а оказалось что кто-то получил документ ещё не родившись, или сделал что-то раньше чем ему разрешено это по закону. (например снял деньги со вклада до наступления 18 лет).
3. Есть ли обработка геоданных (GPS Координаты)?
Я думаю вы путаете цену с деньгами. Цена содержит в себе одно или несколько полей денег, при этом:
Само наличие сущности цена, с некоторыми свойствами определяет возможность продажи.
Может быть есть более удачное название для сущности, но я пока не придумал.
Итак «набросок» цены, как один из вариантов сущности:
class Price : Entity
{
public Money Value {get;set;}
public Item Item {get;set;}
public Location Location {get;set;}
public PriceType PriceType {get;set;}
...
}
В данном примере можно задать цену для Товара, с учётом валюты, в разных Локациях (точки продаж, может быть в разных странах) а также типом цены, например для Доставки, Оптовой цены, Особого Клиента или что-то ещё.
При продаже по определённой Цене, в «таблицу проводок» или что-то подобное записывается текущее значение цены.
В таблице проводок используется понятие Денег (ValueObject)
Точно так же как и в Цене, может использоваться в расчётах Прибыли, Расходов, Доходов и т.д.
Здесь действительно всё зависит от того что именно понимается под Price и под Money.
в моём понимании для торговли, вполне можно использовать следующий подход:
Money — классический ValueObject, состоящий, в простейшем случае, из количества денег (например Decimal) и валюты.
Price — Цена, цена относится к какому то товару или услуге, она может содержать в себе то, что платит покупатель (деньги — VO), ставку/сумму налогов. Выходит, что нельзя делать её в виде ValueObject при таком подходе — по той причине, что её нужно сравнивать по ссылке, а не по содержанию.
10 рублей как деньги (VO) — они везде 10 рублей и их можно «заменить одни другими»
10 рублей как цена — может содержать разные налоги, и заменять их уже нельзя.
А money, деньги, те что обычно число и валюта? Есть такой? Да и price я видел(давно правда, около 3х лет назад), и состоял он в очень странных отношениях с money. И price уже как раз entity, обычно, т.к. привязан к продукту.
зачем отключать? можно же просто обновить прошивку контроллера заряда, и подать повышенное напряжение на аккумулятор во время зарядки.
Из того что ещё можно сделать "малой кровью" - например ReadOnly реплика БД, на которую "заварачивать" часть запросов - то же получение меню, может даже большинство GET запросов.
Как вариант, для фильтрации FE-грида можно посмотреть в сторону OData. Там уже есть готовые инструменты для этого.
Самый главный вопрос: а что с налогами? (особенно интересно в случае удалённой работы на другую страну)
Помню были времена, когда в додо идеологически отказывались от ORM.
Кстати, а Price от Money всё ещё наследуется?
Идея интересная, но в текущем виде защита только от script kiddies
Основная проблема - разница в производительности недорогого смартфона 3-4 летней давности и современных ASIC
майнеров"числодробилок", тут либо на смартфоне будет задержка в несколько минут и несколько процентов батареи, либо защита очень слабая.Поисковики же явно парсят ФИО, в том числе.
и зачем там использовать
PS: Как прогресс с микросервисами? Есть ли ETA полного отказа от монолита?
class Order из примера:
отвечает и за совместимость продуктов и за расчёт налогов, не очень то single
содержит IsValid — который будет регулярно меняться, конфликтует с closed
Сейчас есть серьёзная доля компаний c Remote First идеологией, у них может не быть офиса вообще, или офис может быть чисто символическим, который при всём желании не вместит всех работающих.
Возможно, такое отношение есть в компаниях, когда большая часть работает в офисе, а некоторым «разрешают» работать удалённо — тогда действительно, этот человек может считаться не таким важным, раз уж разрешили ему работать не в офисе.
Последние несколько лет работаю удалённо на заказчиков не из России и более чем доволен.
Сам автор сказал, иначе было бы не 800 а 1100100000 баксов.
На порядок — это в 10 раз. Неужели правда в Минске что-то может стоить в 10(!) раз меньше?
</зануда-mode>
Онлайн тестирование в большинстве случаев короче и проще, а так же позволяет «размять мозг». Проходил несколько онлайн тестов за последний год, и часто было обидно что они достаточно простые.
Почти все современные codility/hackerrank предлагаю потренироваться на кошечках чтобы не терять время в момент тестирования.
Пару вопросов, нет ли случаев, и как с ними бороться:
1. Есть хэш / цифровая подпись, и при изменении любого атрибута (имени, даты) — всё портится. А если подпись приватным ключом клиента?
2. С датами, сдвиг без изменения возраста не возможен в принципе. Возможен только без изменения «количества лет» на определённую дату. Поменяли дату на 25 дней раньше, а оказалось что кто-то получил документ ещё не родившись, или сделал что-то раньше чем ему разрешено это по закону. (например снял деньги со вклада до наступления 18 лет).
3. Есть ли обработка геоданных (GPS Координаты)?
Само наличие сущности цена, с некоторыми свойствами определяет возможность продажи.
Может быть есть более удачное название для сущности, но я пока не придумал.
Итак «набросок» цены, как один из вариантов сущности:
В данном примере можно задать цену для Товара, с учётом валюты, в разных Локациях (точки продаж, может быть в разных странах) а также типом цены, например для Доставки, Оптовой цены, Особого Клиента или что-то ещё.
При продаже по определённой Цене, в «таблицу проводок» или что-то подобное записывается текущее значение цены.
В таблице проводок используется понятие Денег (ValueObject)
Точно так же как и в Цене, может использоваться в расчётах Прибыли, Расходов, Доходов и т.д.
в моём понимании для торговли, вполне можно использовать следующий подход:
Money — классический ValueObject, состоящий, в простейшем случае, из количества денег (например Decimal) и валюты.
Price — Цена, цена относится к какому то товару или услуге, она может содержать в себе то, что платит покупатель (деньги — VO), ставку/сумму налогов. Выходит, что нельзя делать её в виде ValueObject при таком подходе — по той причине, что её нужно сравнивать по ссылке, а не по содержанию.
10 рублей как деньги (VO) — они везде 10 рублей и их можно «заменить одни другими»
10 рублей как цена — может содержать разные налоги, и заменять их уже нельзя.
А money, деньги, те что обычно число и валюта? Есть такой? Да и price я видел(давно правда, около 3х лет назад), и состоял он в очень странных отношениях с money. И price уже как раз entity, обычно, т.к. привязан к продукту.