Здравствуйте, Ночной Смотрящий, Вы писали:

...

НС>Продолжаешь меряться? Ну так у меня все равно длиннее. Моим софтом, бесплатным, пользуются десятки, если не сотни тысяч человек. А у тебя как с успехами на этом фронте?

наконец-то что-то интересное написал. ссылку на софт давай

Здравствуйте, arth, Вы писали:

НС>>И это, на самом деле, уже фейл, на что тебе пальцем и указали. Не надо писать неочевидный код. А если уж написал, так хотя бы напиши поясняющий комментарий. Вроде 13 лет опыта заявляешь, а с какими то элементарнейшими вещами проблема.
A>если ты не в состоянии понять 2 строки кода, то хорошо что мы не вместе работаем.
Ты реализовал определённый подход с снятием денег с одного акка (услово, может не сработать) и внесение на другой акк (всегда должно работать, иначе беда). Но по коду ты это запихал в один и тот же метод, различие лишь в знаке аргумента. Т.е. эта конкретно логика не прослеживается чётко и закодирована какими-то if-ами, и типичный антипаттерн exceptions as control flow.
Да и ты сам запутался поместив это дело в try-catch с каким-то бессмысленным "//unlikely we will have overflow here". Понятное дело, не покрыл такое даже тестом — ибо похоже сам видимо не понял как такое может случиться и что собственно делать. А ведь если add может проваливаться по какой-либо причине (ведь ты берёшь интерфейс Storage, который может кидать Exception хрен знает почему) — то у тебя вся целостность слетает.
"Design and implement a RESTful API" — ты должен продумать поведение клиентов и сервера, чтобы они могли делать операции конкурентно и иметь [eventually] согласованное представление о состоянии системы. В твоём решении если запрос клиента провалился — то он никак не узнает — прошел ли Transfer успешно или нет, т.е. клиент "сломается". Поэтому в REST такие вещи делать двумя запросами, можно что-то в духе оптимистических блокировок.
Да и с точки зрения REST должно быть две бизнес-сущности — Account и Transfer, ровно то что упомянуто в задании. Кто такой Wallet — вообще не понятно: Keep it simple and to the point.

Здравствуйте, StatujaLeha, Вы писали:

SL>Просто мимо проходил и заинтересовало: а для "счета кассы" какой счет парный? Как туда деньги зачисляют?
Для счета кассы парный счет это счет клиента. Не зря ведь они названы парными в данном случае
Суть в том, что когда вы вносите деньги на свой счет в банке одновременно происходит две вещи — у банка становится больше наличности (активов), а у вас больше остаток на счете (пассив банка).
Когда вы снимаете деньги со своего счета, то все происходит с точностью до наоборот — уменьшаются активы банка (счет кассы) и его обязательства перед вами — остаток на вашем счете (пассивы).
Поэтому корреспондирующие счета одни и те же, что для внесения, что для снятия денег. Меняется только "знак" операции.
В российском бухучете это делается с использованием понятий Дебет и Кредит счета.
Если ничего не забыл, то примерно так, с точностью до балансового счета второго порядка.
Внесение. Дт 20202 — Кт 40817
Снятие Кт 20201 — Дт 40817

Но это все бухгалтерия и понятно, что от кандидата не требуется знать всех деталей. Именно поэтому в задании четко сказано, что именно необходимо сделать — операцию перевода между двумя счетами.
А человек придумывает, абсолютно ненужную, операцию — add и выносит ее в API.

Здравствуйте, ·, Вы писали:

·>Здравствуйте, arth, Вы писали:

НС>>>И это, на самом деле, уже фейл, на что тебе пальцем и указали. Не надо писать неочевидный код. А если уж написал, так хотя бы напиши поясняющий комментарий. Вроде 13 лет опыта заявляешь, а с какими то элементарнейшими вещами проблема.
A>>если ты не в состоянии понять 2 строки кода, то хорошо что мы не вместе работаем.
·>Ты реализовал определённый подход с снятием денег с одного акка (услово, может не сработать) и внесение на другой акк (всегда должно работать, иначе беда). Но по коду ты это запихал в один и тот же метод, различие лишь в знаке аргумента. Т.е. эта конкретно логика не прослеживается чётко и закодирована какими-то if-ами, и типичный антипаттерн exceptions as control flow.


очень категорично. в 98% случаев соглашусь. но иногда это имеет право на существование

·>Да и ты сам запутался поместив это дело в try-catch с каким-то бессмысленным "//unlikely we will have overflow here". Понятное дело, не покрыл такое даже тестом — ибо похоже сам видимо не понял как такое может случиться и что собственно делать. А ведь если add может проваливаться по какой-либо причине (ведь ты берёшь интерфейс Storage, который может кидать Exception хрен знает почему) — то у тебя вся целостность слетает.

строго говоря, кейсы с переполнением нужно рассматривать отдельно и вне контекста тестового задания.
ну, вопрос что такое целостность. целостность, это когда никакая информация никуда не потерялась. например, если в логе будет сообщение о переполнении с деталями, то целостность не нарушается, потому есть вся доступная информация для корректирования баланса


·>"Design and implement a RESTful API" — ты должен продумать поведение клиентов и сервера, чтобы они могли делать операции конкурентно и иметь [eventually] согласованное представление о состоянии системы. В твоём решении если запрос клиента провалился — то он никак не узнает — прошел ли Transfer успешно или нет, т.е. клиент "сломается". Поэтому в REST такие вещи делать двумя запросами, можно что-то в духе оптимистических блокировок.
·>Да и с точки зрения REST должно быть две бизнес-сущности — Account и Transfer, ровно то что упомянуто в задании. Кто такой Wallet — вообще не понятно: Keep it simple and to the point.

вопрос идемпотентности вообще отдельная тема. я автоматом вынес его за скобки тестового задания.

можно было сделать навскидку:
txid begin_transaction(...)
end_transaction(txid)
status transaction_status(txid)

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

Здравствуйте, arth, Вы писали:

A>вопрос идемпотентности вообще отдельная тема. я автоматом вынес его за скобки тестового задания.
A>можно было сделать навскидку:
A>txid begin_transaction(...)
A>end_transaction(txid)
A>status transaction_status(txid)

Тут уж чего нибудь одно, или идемпотентность, или транзакция наружу.

Здравствуйте, arth, Вы писали:

НС>>Продолжаешь меряться? Ну так у меня все равно длиннее. Моим софтом, бесплатным, пользуются десятки, если не сотни тысяч человек. А у тебя как с успехами на этом фронте?
A>наконец-то что-то интересное написал. ссылку на софт давай

Сам ты не поленился отдельный гитхаб-аккаунт завести, а с меня ссылки требуешь?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, arth, Вы писали:

НС>>>Продолжаешь меряться? Ну так у меня все равно длиннее. Моим софтом, бесплатным, пользуются десятки, если не сотни тысяч человек. А у тебя как с успехами на этом фронте?
A>>наконец-то что-то интересное написал. ссылку на софт давай

НС>Сам ты не поленился отдельный гитхаб-аккаунт завести, а с меня ссылки требуешь?

не требую, спрашиваю, и не на гитхаб

Здравствуйте, arth, Вы писали:

A>не требую, спрашиваю, и не на гитхаб

Предпочту сохранить анонимность.

Здравствуйте, arth, Вы писали:

A>очень категорично. в 98% случаев соглашусь. но иногда это имеет право на существование
В данном случае получился плохой, запутанный код.

A>·>Да и ты сам запутался поместив это дело в try-catch с каким-то бессмысленным "//unlikely we will have overflow here". Понятное дело, не покрыл такое даже тестом — ибо похоже сам видимо не понял как такое может случиться и что собственно делать. А ведь если add может проваливаться по какой-либо причине (ведь ты берёшь интерфейс Storage, который может кидать Exception хрен знает почему) — то у тебя вся целостность слетает.

A>строго говоря, кейсы с переполнением нужно рассматривать отдельно и вне контекста тестового задания.
A>ну, вопрос что такое целостность. целостность, это когда никакая информация никуда не потерялась. например, если в логе будет сообщение о переполнении с деталями, то целостность не нарушается, потому есть вся доступная информация для корректирования баланса
Переполнением чего? BigDecimal переполнить у тебя не выйдет. Если только OOM долбанёт. Но в этом случае твой код тоже слажает. В если вдруг где Error кинется, так деньги потеряются.
Т.е. в одном месте ты ловишь исключение, т.е. типа ожидаешь его там, а потом делаешь то же самое в catch блоке, рискуя потерять исключение. Бардак.

A>·>"Design and implement a RESTful API" — ты должен продумать поведение клиентов и сервера, чтобы они могли делать операции конкурентно и иметь [eventually] согласованное представление о состоянии системы. В твоём решении если запрос клиента провалился — то он никак не узнает — прошел ли Transfer успешно или нет, т.е. клиент "сломается". Поэтому в REST такие вещи делать двумя запросами, можно что-то в духе оптимистических блокировок.
A>·>Да и с точки зрения REST должно быть две бизнес-сущности — Account и Transfer, ровно то что упомянуто в задании. Кто такой Wallet — вообще не понятно: Keep it simple and to the point.

A>вопрос идемпотентности вообще отдельная тема. я автоматом вынес его за скобки тестового задания.
Дело не в идемоптентноси конкретно. Задание было придумать API, но API в твоём виде использовать никак нельзя. Да, сервер вроде как не падает, но клиенты работать надёжно не могут в принципе. По моему это показывает, что ты не умеешь проектировать распределённые системы.

Здравствуйте, ·, Вы писали:

·>Здравствуйте, arth, Вы писали:

A>>очень категорично. в 98% случаев соглашусь. но иногда это имеет право на существование
·>В данном случае получился плохой, запутанный код.

как скажешь

A>>·>Да и ты сам запутался поместив это дело в try-catch с каким-то бессмысленным "//unlikely we will have overflow here". Понятное дело, не покрыл такое даже тестом — ибо похоже сам видимо не понял как такое может случиться и что собственно делать. А ведь если add может проваливаться по какой-либо причине (ведь ты берёшь интерфейс Storage, который может кидать Exception хрен знает почему) — то у тебя вся целостность слетает.

A>>строго говоря, кейсы с переполнением нужно рассматривать отдельно и вне контекста тестового задания.
A>>ну, вопрос что такое целостность. целостность, это когда никакая информация никуда не потерялась. например, если в логе будет сообщение о переполнении с деталями, то целостность не нарушается, потому есть вся доступная информация для корректирования баланса
·>Переполнением чего? BigDecimal переполнить у тебя не выйдет. Если только OOM долбанёт. Но в этом случае твой код тоже слажает. В если вдруг где Error кинется, так деньги потеряются.
·>Т.е. в одном месте ты ловишь исключение, т.е. типа ожидаешь его там, а потом делаешь то же самое в catch блоке, рискуя потерять исключение. Бардак.

https://stackoverflow.com/questions/6791970/how-to-get-biggest-bigdecimal-value

про Error хороший поинт

A>>·>"Design and implement a RESTful API" — ты должен продумать поведение клиентов и сервера, чтобы они могли делать операции конкурентно и иметь [eventually] согласованное представление о состоянии системы. В твоём решении если запрос клиента провалился — то он никак не узнает — прошел ли Transfer успешно или нет, т.е. клиент "сломается". Поэтому в REST такие вещи делать двумя запросами, можно что-то в духе оптимистических блокировок.
A>>·>Да и с точки зрения REST должно быть две бизнес-сущности — Account и Transfer, ровно то что упомянуто в задании. Кто такой Wallet — вообще не понятно: Keep it simple and to the point.

A>>вопрос идемпотентности вообще отдельная тема. я автоматом вынес его за скобки тестового задания.
·>Дело не в идемоптентноси конкретно. Задание было придумать API, но API в твоём виде использовать никак нельзя. Да, сервер вроде как не падает, но клиенты работать надёжно не могут в принципе. По моему это показывает, что ты не умеешь проектировать распределённые системы.

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

Здравствуйте, neFormal, Вы писали:

F>может, человек кушать хочет, а ты ему говоришь, что работодатель сам придёт и икру в рот закидывать будет.

работодателей на рынке достаточное количество, вполне можно выбирать

Здравствуйте, binnom, Вы писали:

B>Тоже верно. Однако никто же не жалуется решать задачки на всяких кодилити по 2 часа безо всякого фидбэка вообще

Конечно никто не жалуется. я например даже не знаю что это такое, и без хороших гарантированных денежных перспектив даже не стал бы ничего делать на 2 часа.

Здравствуйте, Grizzli, Вы писали:

G>работодателей на рынке достаточное количество, вполне можно выбирать

Зависит от страны. В РФ, да, не принято таким загружать кандидата и на это есть разумные причины. В то же время в странах куда много народу стремиться, с тобой часто и говорить не станут до того, как тестовое задание решишь. И на это тоже есть разумные причины

Здравствуйте, Grizzli, Вы писали:

F>>может, человек кушать хочет, а ты ему говоришь, что работодатель сам придёт и икру в рот закидывать будет.
G>работодателей на рынке достаточное количество, вполне можно выбирать

а не покажешь ли это "достаточное количество", которые готовы платить по 5 килобаксов джунам?
нет? то-то же!

Здравствуйте, neFormal, Вы писали:

F>а не покажешь ли это "достаточное количество", которые готовы платить по 5 килобаксов джунам?

кроме 5 килобаксов существует масса других обстоятельств. если я будут за 2 килобакса работать 2 часа в день, в остальное время лабая халтуру или собственный проект, то плевать на твоих работодателей с их 5 килобаксами, даже если они 10 килобаксов будут платить

Здравствуйте, arth, Вы писали:

A>Зашел на РСДН и как говна наелся. за 15 лет ничего не изменилось — основная задача половины отвечающих — самоутвердиться, потратив минимум усилий на вникание в вопрос.
A>Обосрать и научить жизни, минимально задействовав мозг. Странная культура.
A>Остальным спасибо за ваше время.
You are welcome!

Здравствуйте, arth, Вы писали:

A>Главный вывод по теме — тестовые задания больше не пишу. По крайней мере в таком формате.

а как по мне, так лучше сделать тестовое задание дома в комфортных условиях, чем на собеседованиях отвечать на вопросы, ради которых нужно прочитать кучу тупых книжек и потратить кучу времени на подготовку.

Здравствуйте, Grizzli, Вы писали:

F>>а не покажешь ли это "достаточное количество", которые готовы платить по 5 килобаксов джунам?
G>кроме 5 килобаксов существует масса других обстоятельств. если я будут за 2 килобакса работать 2 часа в день, в остальное время лабая халтуру или собственный проект, то плевать на твоих работодателей с их 5 килобаксами, даже если они 10 килобаксов будут платить

конечно, кому и фалафель — стейк, но кому нужен джун на 2 часа в день.
это, максимум, зарплата студента-стажёра.

A>The solution is no concurrency safe — transaction is not atomic
A> me — there is no explicit requirement and actually basic
A>transaction (add) is atomic. There is no race conditions. Atomicity of
A>_transfer_ is required if we don't want to loose data — but here there
A>is no such problem since we don;t store anything between sessions.

А если:

    override fun transfer(from: String, to: String, amount: BigDecimal) {

        val amt = amount.abs()

        add(from, amt.negate())


// Здесь кто-то запросит list, и получит ответ ???!!!!

        try {
            add(to, amt)
        }
        catch (e: Exception) {
            add(from, amt) //unlikely we will have overflow here
            throw e
        }
}

получит противоречивые данные.
Так что не concurrency safe.

Здравствуйте, neFormal, Вы писали:


F>конечно, кому и фалафель — стейк, но кому нужен джун на 2 часа в день.
F>это, максимум, зарплата студента-стажёра.

в рф 2 кб — то средняя зп по отрасли для программиста. если ты за нее будешь работать не более двух часов в день, а остальное время будешь на работе своими делами заниматься — то это намного интересней, чем твои 5 кб и пахать с утра до вечера.