Re[9]: Что не так с тестовым заданием?
От: arth  
Дата: 11.03.19 16:59
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

...

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


наконец-то что-то интересное написал. ссылку на софт давай
Re[8]: И вот feedback от них и мои им ответы
От: · Великобритания  
Дата: 11.03.19 18:56
Оценка: 5 (1)
Здравствуйте, 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.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[7]: Что не так с тестовым заданием?
От: lintik  
Дата: 11.03.19 19:27
Оценка: +1
Здравствуйте, StatujaLeha, Вы писали:

SL>Просто мимо проходил и заинтересовало: а для "счета кассы" какой счет парный? Как туда деньги зачисляют?

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

Но это все бухгалтерия и понятно, что от кандидата не требуется знать всех деталей. Именно поэтому в задании четко сказано, что именно необходимо сделать — операцию перевода между двумя счетами.
А человек придумывает, абсолютно ненужную, операцию — add и выносит ее в API.
Re[9]: И вот feedback от них и мои им ответы
От: arth  
Дата: 11.03.19 19:32
Оценка:
Здравствуйте, ·, Вы писали:

·>Здравствуйте, 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)

но я подумал это все чересчур. спросили бы на интервью, начал бы думать плотнее
Re[10]: И вот feedback от них и мои им ответы
От: Ночной Смотрящий Россия  
Дата: 11.03.19 19:46
Оценка:
Здравствуйте, arth, Вы писали:

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

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

Тут уж чего нибудь одно, или идемпотентность, или транзакция наружу.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[10]: Что не так с тестовым заданием?
От: Ночной Смотрящий Россия  
Дата: 11.03.19 19:46
Оценка: +1 -1 :)
Здравствуйте, arth, Вы писали:

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

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

Сам ты не поленился отдельный гитхаб-аккаунт завести, а с меня ссылки требуешь?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[11]: Что не так с тестовым заданием?
От: arth  
Дата: 11.03.19 19:48
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

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


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

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

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


не требую, спрашиваю, и не на гитхаб
Re[12]: Что не так с тестовым заданием?
От: Ночной Смотрящий Россия  
Дата: 11.03.19 19:50
Оценка: -1 :))
Здравствуйте, arth, Вы писали:

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


Предпочту сохранить анонимность.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[10]: И вот feedback от них и мои им ответы
От: · Великобритания  
Дата: 11.03.19 19:51
Оценка: +1
Здравствуйте, 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 в твоём виде использовать никак нельзя. Да, сервер вроде как не падает, но клиенты работать надёжно не могут в принципе. По моему это показывает, что ты не умеешь проектировать распределённые системы.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[11]: И вот feedback от них и мои им ответы
От: arth  
Дата: 11.03.19 20:20
Оценка:
Здравствуйте, ·, Вы писали:

·>Здравствуйте, 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 в твоём виде использовать никак нельзя. Да, сервер вроде как не падает, но клиенты работать надёжно не могут в принципе. По моему это показывает, что ты не умеешь проектировать распределённые системы.

я и не пытался показать, что умею. это синтетика. ладно, я совсем иначе понимаю суть этого тестового задания, о чем написал еще в первом сообщении.
Re[3]: Что не так с тестовым заданием?
От: Grizzli  
Дата: 12.03.19 08:17
Оценка:
Здравствуйте, neFormal, Вы писали:

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


работодателей на рынке достаточное количество, вполне можно выбирать
Re[3]: Что не так с тестовым заданием?
От: Grizzli  
Дата: 12.03.19 08:19
Оценка:
Здравствуйте, binnom, Вы писали:

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


Конечно никто не жалуется. я например даже не знаю что это такое, и без хороших гарантированных денежных перспектив даже не стал бы ничего делать на 2 часа.
Re[4]: Что не так с тестовым заданием?
От: kaa.python Сингапур http://sysdev.me/
Дата: 12.03.19 08:46
Оценка: +1
Здравствуйте, Grizzli, Вы писали:

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


Зависит от страны. В РФ, да, не принято таким загружать кандидата и на это есть разумные причины. В то же время в странах куда много народу стремиться, с тобой часто и говорить не станут до того, как тестовое задание решишь. И на это тоже есть разумные причины
Re[4]: Что не так с тестовым заданием?
От: neFormal Россия  
Дата: 12.03.19 08:48
Оценка:
Здравствуйте, Grizzli, Вы писали:

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

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

а не покажешь ли это "достаточное количество", которые готовы платить по 5 килобаксов джунам?
нет? то-то же!
...coding for chaos...
Re[5]: Что не так с тестовым заданием?
От: Grizzli  
Дата: 12.03.19 09:01
Оценка:
Здравствуйте, neFormal, Вы писали:

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


кроме 5 килобаксов существует масса других обстоятельств. если я будут за 2 килобакса работать 2 часа в день, в остальное время лабая халтуру или собственный проект, то плевать на твоих работодателей с их 5 килобаксами, даже если они 10 килобаксов будут платить
Re[2]: Выводы
От: Skorodum Россия  
Дата: 12.03.19 09:14
Оценка:
Здравствуйте, arth, Вы писали:

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

A>Обосрать и научить жизни, минимально задействовав мозг. Странная культура.
A>Остальным спасибо за ваше время.
You are welcome!
Re[2]: Выводы
От: zverjuga Беларусь  
Дата: 12.03.19 09:30
Оценка: +1
Здравствуйте, arth, Вы писали:

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


а как по мне, так лучше сделать тестовое задание дома в комфортных условиях, чем на собеседованиях отвечать на вопросы, ради которых нужно прочитать кучу тупых книжек и потратить кучу времени на подготовку.
решаю проблемы
Re[6]: Что не так с тестовым заданием?
От: neFormal Россия  
Дата: 12.03.19 09:34
Оценка:
Здравствуйте, Grizzli, Вы писали:

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

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

конечно, кому и фалафель — стейк, но кому нужен джун на 2 часа в день.
это, максимум, зарплата студента-стажёра.
...coding for chaos...
No concurrency safe
От: igor-booch Россия  
Дата: 12.03.19 09:43
Оценка:
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.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Отредактировано 12.03.2019 9:45 igor-booch . Предыдущая версия .
Re[7]: Что не так с тестовым заданием?
От: Grizzli  
Дата: 12.03.19 10:02
Оценка:
Здравствуйте, neFormal, Вы писали:


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

F>это, максимум, зарплата студента-стажёра.

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