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

A> где я налажал?

стал делать тестовое задание

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

A>код — https://github.com/arthells/mtest

Ну давайте по порядку. Это то, что я на автомате проверяю на ревью, без определенного порядка.

• Как уже правильно сказали, в readme не написано, как собирать. Одна-две строчки много времени не займут, а для читающего приятно и не надо вспоминать, какая там у вас культура.
  
• У вас там в бинарниках трояна нет? Это я к тому, что бинарники в репозитории — это нехорошо. Я знаю, что "все так делают". Но это ведь показывает, как вы подходите к выбору инструмента. Если у вас команда везде использует gradle, почему она не устанавливает глобально wrapper и не хранит только настройки в repo? Было бы логично, и можно было бы с причинами в readme описать, почему так сделано. Аналогичный инструмент есть для maven. Ну а sbt это из коробки уже давным давно сам поддерживает.
  
• Тесты. Вы их с падающими assert проверяли? У меня вот подозрение, что после первого падения все остальное упадет с AddressAlreadyInUse. Что как-то нехорошо. Например потому, что после этого нужно исправлять первый упавший тест а не любой понравившийся.
  
• Там же. Это вообще как fixture же можно написать. withServer(server => ...). И вот в withServer сделать правильный try/catch/finally.
  
• Не StorageTest а StorageImplTest. Вот представьте, у вас есть несколько реализаций Storage. Какую из них тестирует StorageTest?
  
• Assert.true(false) настораживает. Я сильно за java world не слежу, но когда там сломали Assert.fail? (Маленькая хитрость — туда можно даже написать, что именно сломалось!)
  
• А еще когда-то в Assert был assertEquals. И он старается показать, что же там было не equals в сообщении. Это достаточно часто полезно. Не нужно с отладчиком выяснять, какое же на самом деле значение вернулось. Очень часто по этому "неверному" значению можно сразу предположить, что сломалось и что нужно исправить.
  
• Ваш restful тянет только на Level 0 (используется HTTP). Банальный RPC over HTTP. SOAP, кстати, тоже попадает в REST Level 0. Хотелось бы видеть хотя бы Level 1 — Entities & Verbs (т.е. PUT /accounts/abc, GET /accounts, ...).
  
• Копипаста с ctx.queryParam хорошо выносится в отдельный метод. И меньше шансов, что имена параметров в query string и сообщении об ошибке не совпадут.
  
• Ожидание ввода в main — решение спорное. Как оно поведет себя в каком нибудь Kubernetes? Там некому будет вводить порт. Вообще право на жизнь оно имеет, но такие сюрпризы должны описываться в readme.
  
• Там же — можно было бы и написать количество фактических аргументов в сообщении об ошибке. Это несложно, а кому-то может однажды оказаться полезно.
  
• Интерфейсам Storage и Wallet документация (контракт) не помешали бы. Там как раз можно описать поведение при положительных/отрицательных значениях, возможные исключения и прочие интересные ситуации.
  
• *Impl. Это вот у вас ровно одна реализация предполагается? Почему бы не InMemoryStorage, например?
  
• Я бы вообще эти реализации спрятал за Factory Method. Потому что тогда их можно по желанию менять, разбивать/переразбивать на разные классы и т.п. В конце концов, все использования идут только через реализованные интерфейсы.
  
• В StorageImpl вложенность кода глубокая. Можно было бы спрямить через if/throw и if/return.
  
• Там же. current + change можно было бы в переменную сохранить. Было бы видно, что это одно и то же.
  
• В WalletImpl.transfer поведение на отрицательных amount немного неожиданное. Вы уверены, что другой разработчик, реализующий интерфейс Wallet, сделает подобное же поведение? Это к вопросу о контрактах (которые выглядят как документация).
  
• Там же. С JdbcStorateImpl ваш WalletImpl будет неатомарен. Вот его за factory method (создающего заодно и storage) спрятать — и будет лучше.
  
• Account интересен. Почему у вас конструктор по умолчанию создает счет с невалидным id?
  
• А зачем model и core разделили? Тем более, что core зависит от model а не наоборот. Кстати, а зачем в "реальном проекте" разделение делать иначе? Какие фундаментальные причины этого требуют?

Вот весь тот список — это "элементы стиля". Вещи, которые делаются вообще автоматически. Показывает, насколько разработчик механически следует шаблонам и насколько все же задумывается о причинах определенных технических решений.

Ссылаться на недостаток времени здесь смысла нет. За 6-12 часов все это делается (ни один из шагов много времени не добавляет) если вы раньше писали rest и задумывались обо всех мелочах. Если раньше не делали — да, хорошее упражнение. Но, вероятно, на другую позицию. В чем-то это похоже на найм в хороший ресторан. Вы приходите на кухню и вас просят приготовить обед за 45 минут. Вы сделали стейк с картошкой. Но картошку не почистили, мясо не посолили и никакого соуса не добавили. Потому что "что же вы хотели за 45 минут". А это вещи, которые как раз делаются автоматически.

Нет, у вас конечно не плохо. Откровенно плохого там ничего нет. Но и ничего выдающегося тоже нет. Видимо, у компании были более интересные кандидаты.

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

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

A>Попросили сделать тестовое задание часов за 6-12:

Одно вот это

A>2. There are no detailed requirements, use common sense.

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

Соответственно, никто (кроме задающего задание) не скажет тебе, что именно ты там не так придумал.

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

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

M>>Как уже правильно сказали, в readme не написано, как собирать. Одна-две строчки много времени не займут, а для читающего приятно и не надо вспоминать, какая там у вас культура.
A>камон. я не для домохозяек туториал пишу.
Не для домохозяек. Но вы предполагаете, что проверяющий хорошо знает все модные тренды во всех трех предложенных языках. А это может быть и не так. Может, они Java позволяют только для того, чтобы иметь больший круг кандидатов и потом переучивать их на используемый стек. Можно не иметь подробного описания сборки для проектов внутри команды, общее знание достигается через onboarding и тренировку. А вот для тестового задания две-три строчки о сборке будут полезны. Еще показывают, что вы все-таки задумываетесь о пользователях и умеете в какой-то мере бороться с проекцией "я знаю, значит и все остальные должны знать".

M>>У вас там в бинарниках трояна нет?
A>это тестовое задание. как и что это показывает — от "ничего" вплоть до "все"
Но вы же согласились его делать. Значит согласны, что что-то оно показывает? Свобода выбора технологий как раз полезна — показывает, о каких глубоких вопросах задумывался кандидат. И какие предпочтения имеет.

M>>Тесты. Вы их с падающими assert проверяли? У меня вот подозрение, что после первого падения все остальное упадет с AddressAlreadyInUse. Что как-то нехорошо. Например потому, что после этого нужно исправлять первый упавший тест а не любой понравившийся.
A>проверял
Ну и как? Удобно находить, где там ошибка? Я вот специально сейчас сломал один тест. Получил четыре AssertionError без каких-либо внятных сообщений об ошибках. Пришлось копаться в стеках, чтобы понять, откуда они происходят. Дополнительные сложности там, где их легко избежать.

M>>Не StorageTest а StorageImplTest. Вот представьте, у вас есть несколько реализаций Storage. Какую из них тестирует StorageTest?
A>вы серьезно?
Конечно. StorageTest по названию — это тест на соответствие спецификации (compliance). Т.е. любая реализация должна проходить эти тесты (которые с большой вероятностью property based). Здесь же можно поговорить про то, как сложно делать тесты, параметризованные объектами. При этом тесты конкретных реализаций либо расширяют StorageTest (и обходят ограничения фреймворков тестирования), или тестируют какие-то дополнительные свойства, характерные для этих реализаций.

M>>Ваш restful тянет только на Level 0 (используется HTTP). Банальный RPC over HTTP. SOAP, кстати, тоже попадает в REST Level 0. Хотелось бы видеть хотя бы Level 1 — Entities & Verbs (т.е. PUT /accounts/abc, GET /accounts, ...).
A>кому хотелось и зачем?
Ну в первую очередь вам. Потому что вы хотели продолжения интервью или найма. Хотелось бы мне. Как минимум потому, что приятно поговорить с кандидатом с широким кругозором. За реализацию Rest Level 1 вы бы получили плюсик. А на самом деле при создании API вы скорее всего вспомнили бы причины, по которым REST был спроектирован в его виде. И задумались бы про идемпотентность (idempotency) операций. Не обязательно ее реализовывать, можно было просто упомянуть в readme: "идемпотентность не реализована из-за ограничений на время, могу прислать план реализации по запросу". И получили бы сразу пять плюсиков.

Idempotency здесь очень важна. Вот представьте, я вызвал ваш RPC API и получил IOException. Вот что я с ним должен делать? Ничего (и рисковать, что запрос был потерян)? Или повторять запрос (и рисковать, что я проведу операцию дважды)? Вот из-за вашего API мне придется городить Artificiall Intelligence (искуственную разведку), которая будет выяснять состояние предыдущей операции прежде чем повторять. А с идемпотентным REST я бы ее просто повторил и сказал вам большое спасибо. Ситуация вполне реальная, и в том числе в финансовой сфере . Это — основная причина, по которой Rest Level 1 хотелось бы видеть лично мне.

M>>Ожидание ввода в main — решение спорное. Как оно поведет себя в каком нибудь Kubernetes? Там некому будет вводить порт. Вообще право на жизнь оно имеет, но такие сюрпризы должны описываться в readme.
A>надеюсь вы несерьезно, потому что тест не для запуска в Kubernetes
Серьезно. Потому что кандидат, написавший 5 приложений под Kubernetes, не будет вообще писать ввод. И опишет аргументы командной строки в README. Может это и не страшно, зависит от конкретной позиции, на которую вы претендуете.

M>>*Impl. Это вот у вас ровно одна реализация предполагается? Почему бы не InMemoryStorage, например?
A>а у вас? и почему если не одна, то не InMemoryCuncurrentHashSetStorageImpl? понятно куда клоню?
А у меня — несколько реализаций предполагается. И обычно их и есть несколько. Очень часто отдельная in-memory (или какая-то упрощенная) для тестов. Во многих случаях — декораторы. За что-то более осмысленное чем *Impl получили бы плюсик. Против вашего длинного варианта ничего не имею, он выше минимальных ожидаемых стандартов. За последовательное следование вашей конвенции (и сохранение нужных уровней абстракции и т.п.) получили бы сразу два плюсика. И я бы начал задумываться, а не стоит ли внедрить ваш стиль для всей команды.

M>>Я бы вообще эти реализации спрятал за Factory Method. Потому что тогда их можно по желанию менять, разбивать/переразбивать на разные классы и т.п. В конце концов, все использования идут только через реализованные интерфейсы.
A>нечего добавить. не вижу в 2019 году задачи явно показывать знание Factory Method
А вот и не угадали . Это задача на проектирование API, минимизирующего изменения в кодовой базе и расширяющего круг возможных рефакторингов. Один конкретный случай, конечно, не влияет. Но ведь проектирование таких API — это автоматизированный навык (подобных решений разработчики делают много). А вот на большой кодовой базе преимущества factory method уже будут заметны. Опять же, я на самом деле не требую именно фабричный метод (это один плюсик). Любое другое API, служащее той же цели (минимизация потенциальных изменений и расширение простора для рефакторинга) даст вам как минимум два плюсика.

M>>В StorageImpl вложенность кода глубокая. Можно было бы спрямить через if/throw и if/return.
A>а можно было и нет. дело вкуса
Это конечно да. Но толерантность к глубоким стрелкам настроаживает. Очень часто приводит к длинным и глубоким вложенностям, условиям и т.п. А потом мне приходится вспоминать, к чему же относится одинокий else с одной строчкой после большого блока кода, где его if не влез на его страницу. Чем меньше надо помнить — тем лучше.

M>>Account интересен. Почему у вас конструктор по умолчанию создает счет с невалидным id?
A>а с каким валидным id он может его создавать? это издержки json сериализации, нужен дефолтный конструктор, и вопросвалидности отдельный и серьезный
Вот! Именно таких вопросов (можно для начала и без ответов) я и жду от вас! Можно описать вопросы валидности в kotlindoc. Можно — в readme проекта. Можно взять сериализатор, не страдающий издержками (это тестовое задание, я хочу видеть, как вы видите идеальный код!). Пусть даже не распространенный, не важно. Я очень хочу иметь в команде разработчиков, видящих много факторов и находящих компромисс между ними. Пусть даже выбор будет не совпадать с моим, это не будет минусом.

M>>А зачем model и core разделили? Тем более, что core зависит от model а не наоборот. Кстати, а зачем в "реальном проекте" разделение делать иначе? Какие фундаментальные причины этого требуют?
A>чтобы model отдать клиенту, core ему не нужен (либо перенести ifaces из core в model, кто тоже стоит отдельного обсуждения)
Еще один хороший комментарий! Можно было бы про него в readme упоминуть. В том числе и потому, что решение по-умолчанию — странное. Для публичных API у вас клиенты будут не только на java. Им ваша модель вообще никак не поможет. И даже на Java — вы ведь не считаете всех остальных разработчиков полными идиотами? (Или все-же считаете?) Я думаю, они смогут сами написать модель, которая им нужна (с нужной им декомпозицией, используемыми полями и т.п.). Может, они даже возьмут десериализатор без издержек и им будут непонятны ваши компромиссы.

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

M>>Вот весь тот список — это "элементы стиля". Вещи, которые делаются вообще автоматически. Показывает, насколько разработчик механически следует шаблонам и насколько все же задумывается о причинах определенных технических решений.
A>большинсто про вкус, остальное minor по мне. нейминг — не технические решения, как и работа с Assert
Ну... Вкус, да. Вы ведь понимаете, что код больше читается, чем пишется? Поэтому мне очень интересен код, который легко читать. В котором не нужно задумываться, что же хотел нам сказать автор. В котором можно зайти в документацию и прояснить непонятные детали. Иначе через три месяца другой разработчик поймет ваш код немного не так, как он задумывался, и в системе возникнет плавающий баг. Стиль — это эвристики, учитывающие особенности работы человеческого мозга. Например, разворачивание глубокой вложенности в последовательный код — это workaround на ограниченность кратковременной памяти. Большинство обычных людей забудет к третьему вложенному if, что там было на верхнем уровне. А потом сделают ошибку или потратят дополнительное время на вспоминание.

Я несколько лет назад осознал, что "технические решения" — это только половина программирования. А вторая половина — гуманитарные науки, литература в первую очередь. Те самые нелюбимые технарями сочинения — это суть написания кода. Точное описание своих мыслей не только для машины, но и для программистов, читающих и сопровождающих за вами ваш код. Понимание того, что ваши мысли, ваше изложение и то, что понял читатель — это три разные вещи. Умение встать на сторону читателя и писать так, чтобы он увидел то, что вы хотели сказать.

Вот все эти Assert — это как раз сложности выражать свои мысли в прямом и явном виде. Не технические, ну и что? Мне не нужны ребусы в коде. Мне нужен программист, который не поленился прочитать API и выбрать наиболее выразительный метод (для тестирования они еще и сообщения об ошибках лучше создают). Это один из многих факторов, на которые я обращаю внимание. И всегда очень интересно, когда на ревью кода кто-то другой показывает мне более выразительный (простой и понятный) вариант, чем я использовал.

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

T>Ну, не знаю. Самое просто, а почему для money у вас BigDecimal?
Оно вообще то всю жизнь было рекомендованным решением по умолчанию для денег. Сейчас что, появились новые рекомендации и я что то пропустил?

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

A>Author don't know how to catch exceptions in junit

-- MGIMO ended?
-- Ask!

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

A>Думал, что от меня хотят чтобы я выбирал решения к месту, не занимался overdesign и overengineering etc., показал базовые вещи вроде разделения контракта и реализации, di, testability, стиль кода, который подходит к Kotlin ну и так далее.
Просмотрел сильно мельком и также мельком читал само задание. Но из того, что увидел — ничего особо криминального не заметил. Достаточно просто, при необходимости далее расширяется, рефакторится и далее можно добавлять навороты. Придраться конечно вполне нашел бы к чему, но ради тестового задания я бы не стал там сам сильно заморачиваться. Лично меня код бы вполне удовлетворил, для тестового задания все более чем нормально, и если не налажал на других вопросах далее бы все решалось исключительно твоими требованиями по зарплате. Подобный код сам периодически отправлял, вроде удовлетворялись вполне, правда оффера не было, так как я много просил, плюс сам говорил что я работу не ищу, а просто хожу чтоб навыки прохождения собеседований не терять. Раз в год обязательно собеседуюсь, но сейчас с тестовыми заданиями посылаю, если что — смотрите на гитхабе код предыдущих . Хотя, для прикола б на хаскеле я б может и сделал какое тестовое. На котлине бы уже не стал делать, уже игрался, причем с большими наворотами, чем я был бы готов делать для тестового задания .

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

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

A>выложил на github, поправил стартовое сообщение
Может им не понравилось, что нет истории разработки? (Все одним коммитом.)

Вообще если дали тз на несколько часов, а потом леняться дать вменяемый ответ что для них плохо, то с чистой совестью можете раскрывать название конторы.

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

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

A>Procedure of transferring money is not clear and difficult to support
A>no comment.
Здесь они тоже правы. Там логика то простейшая, но навернул ты сильно больше, чем можно было бы сделать. Лучше б простой императивщиной в лоб бы сделал да и все. Я про метод add, а не про transfer. Такое впечатление что начитался про паттерн матчинг и захотел непременно применить что то похожее. Да и transfer тоже — amount.abs() и доп логика.

То есть код можно было сделать одновременно и более простым, и более надежным. Плюс более компактным. Еще я б для тестового задания не стал бы выделять интерфейс. Принципиально не стал бы, если бы стали придираться — аргументировал бы тем, что мне не нужна дополнительная сложность и дополнительный код на ровном месте. При необходимости рефакторинг вида extract interface делается мгновенно, и если у интерфейса только одна реализация, то лучше не выпендриваться и не городить доп сложность на ровном месте.

Но, только бы за эти недочеты я бы браковать не стал.

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

A>The solution is no concurrency safe — transaction is not atomic
A> me — there is no explicit requirement

Это тот самый common sense, просто ты явно никогда не писал финансовый софт.

A>Insufficient testing coverage
A>nothing to say. It's 6hrs test. Not 40hrs

Не смешите мои тапочки. У тебя кода кот наплакал, тестова написать к нему 20 минут работы.

A>If we transfer negative amount money, author don’t throw exceptions, it takes abs value of this amount and transfer positive amount of money.

А это реально просто пипец, как по мне.

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

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

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

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

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

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

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

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

Пообщаться всяко полезнее.

И зачем готовиться? Говори что делаешь и знаешь, делов-то. Собеседование это процесс отсева ненужных: как кандидатов так и рабтотодателей. Если чего-то не знаешь, не хочешь, неинтересно, то зачем читать и готовиться?.

Я заметил, что чем меньше тестируют на собеседованиях, тем увлекательней и толковей работа. По нормальному, если подходишь, то минут через 5 собеседование превращается в увлекательную беседу. За которой, если не следить за временем, несколько часов проведешь.

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

A>код — https://github.com/arthells/mtest

Как то смущает рукопашный разбор параметров. Почему не https://dinject.io/javalin ?

Ну и для датастора я бы ожидал какую-нибудь ин мемори бд.

A>2/ в реальном мире она нигде не атомарна и не может быть таковой
ACID

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

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.

вообще то было в требованиях, конкурентное исполнение.

A>Insufficient testing coverage
A>nothing to say. It's 6hrs test. Not 40hrs

тоже было в требованиях.

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

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

A>>код — https://github.com/arthells/mtest

M>Ну давайте по порядку. Это то, что я на автомате проверяю на ревью, без определенного порядка.

M>

M>
• Как уже правильно сказали, в readme не написано, как собирать. Одна-две строчки много времени не займут, а для читающего приятно и не надо вспоминать, какая там у вас культура.
  
  камон. я не для домохозяек туториал пишу.
  
  M>
• У вас там в бинарниках трояна нет? Это я к тому, что бинарники в репозитории — это нехорошо. Я знаю, что "все так делают". Но это ведь показывает, как вы подходите к выбору инструмента. Если у вас команда везде использует gradle, почему она не устанавливает глобально wrapper и не хранит только настройки в repo? Было бы логично, и можно было бы с причинами в readme описать, почему так сделано. Аналогичный инструмент есть для maven. Ну а sbt это из коробки уже давным давно сам поддерживает.
  
  это тестовое задание. как и что это показывает — от "ничего" вплоть до "все"
  
  M>
• Тесты. Вы их с падающими assert проверяли? У меня вот подозрение, что после первого падения все остальное упадет с AddressAlreadyInUse. Что как-то нехорошо. Например потому, что после этого нужно исправлять первый упавший тест а не любой понравившийся.
  
  проверял
  
  M>
• Там же. Это вообще как fixture же можно написать. withServer(server => ...). И вот в withServer сделать правильный try/catch/finally.
  
  ну если мы проверяем как я в тестовом задании, те бесплатно, пишу тесты, то может вы и правы
  
  M>
• Не StorageTest а StorageImplTest. Вот представьте, у вас есть несколько реализаций Storage. Какую из них тестирует StorageTest?
  
  вы серьезно?
  
  M>
• Assert.true(false) настораживает. Я сильно за java world не слежу, но когда там сломали Assert.fail? (Маленькая хитрость — туда можно даже написать, что именно сломалось!)
  
  M>
• А еще когда-то в Assert был assertEquals. И он старается показать, что же там было не equals в сообщении. Это достаточно часто полезно. Не нужно с отладчиком выяснять, какое же на самом деле значение вернулось. Очень часто по этому "неверному" значению можно сразу предположить, что сломалось и что нужно исправить.
  M>
• Ваш restful тянет только на Level 0 (используется HTTP). Банальный RPC over HTTP. SOAP, кстати, тоже попадает в REST Level 0. Хотелось бы видеть хотя бы Level 1 — Entities & Verbs (т.е. PUT /accounts/abc, GET /accounts, ...).
  
  кому хотелось и зачем?
  
  M>
• Копипаста с ctx.queryParam хорошо выносится в отдельный метод. И меньше шансов, что имена параметров в query string и сообщении об ошибке не совпадут.
  
  придирка
  
  M>
• Ожидание ввода в main — решение спорное. Как оно поведет себя в каком нибудь Kubernetes? Там некому будет вводить порт. Вообще право на жизнь оно имеет, но такие сюрпризы должны описываться в readme.
  
  надеюсь вы несерьезно, потому что тест не для запуска в Kubernetes
  
  M>
• Там же — можно было бы и написать количество фактических аргументов в сообщении об ошибке. Это несложно, а кому-то может однажды оказаться полезно.
  
  за деньги — легко
  
  M>
• Интерфейсам Storage и Wallet документация (контракт) не помешали бы. Там как раз можно описать поведение при положительных/отрицательных значениях, возможные исключения и прочие интересные ситуации.
  
  согласен частично
  
  M>
• *Impl. Это вот у вас ровно одна реализация предполагается? Почему бы не InMemoryStorage, например?
  
  а у вас? и почему если не одна, то не InMemoryCuncurrentHashSetStorageImpl? понятно куда клоню?
  
  M>
• Я бы вообще эти реализации спрятал за Factory Method. Потому что тогда их можно по желанию менять, разбивать/переразбивать на разные классы и т.п. В конце концов, все использования идут только через реализованные интерфейсы.
  
  нечего добавить. не вижу в 2019 году задачи явно показывать знание Factory Method
  
  M>
• В StorageImpl вложенность кода глубокая. Можно было бы спрямить через if/throw и if/return.
  
  а можно было и нет. дело вкуса
  
  M>
• Там же. current + change можно было бы в переменную сохранить. Было бы видно, что это одно и то же.
  
  опять же про вкус
  
  M>
• В WalletImpl.transfer поведение на отрицательных amount немного неожиданное. Вы уверены, что другой разработчик, реализующий интерфейс Wallet, сделает подобное же поведение? Это к вопросу о контрактах (которые выглядят как документация).
  
  тут согласен
  
  M>
• Там же. С JdbcStorateImpl ваш WalletImpl будет неатомарен. Вот его за factory method (создающего заодно и storage) спрятать — и будет лучше.
  
  он и так неатомарен. атомарен Storage*
  
  M>
• Account интересен. Почему у вас конструктор по умолчанию создает счет с невалидным id?
  
  а с каким валидным id он может его создавать? это издержки json сериализации, нужен дефолтный конструктор, и вопросвалидности отдельный и серьезный
  
  M>
• А зачем model и core разделили? Тем более, что core зависит от model а не наоборот. Кстати, а зачем в "реальном проекте" разделение делать иначе? Какие фундаментальные причины этого требуют?
  M>

чтобы model отдать клиенту, core ему не нужен (либо перенести ifaces из core в model, кто тоже стоит отдельного обсуждения)

M>Вот весь тот список — это "элементы стиля". Вещи, которые делаются вообще автоматически. Показывает, насколько разработчик механически следует шаблонам и насколько все же задумывается о причинах определенных технических решений.

большинсто про вкус, остальное minor по мне. нейминг — не технические решения, как и работа с Assert

M>Ссылаться на недостаток времени здесь смысла нет. За 6-12 часов все это делается (ни один из шагов много времени не добавляет) если вы раньше писали rest и задумывались обо всех мелочах. Если раньше не делали — да, хорошее упражнение. Но, вероятно, на другую позицию. В чем-то это похоже на найм в хороший ресторан. Вы приходите на кухню и вас просят приготовить обед за 45 минут. Вы сделали стейк с картошкой. Но картошку не почистили, мясо не посолили и никакого соуса не добавили. Потому что "что же вы хотели за 45 минут". А это вещи, которые как раз делаются автоматически.

какие-то не очень уместные на мой взгляд аналогии

M>Нет, у вас конечно не плохо. Откровенно плохого там ничего нет. Но и ничего выдающегося тоже нет. Видимо, у компании были более интересные кандидаты.

спасибо за отзыв энивей

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

vsb>Если человек не знает, как собрать проект на Gradle, он к Java не имеет отношения.
Не, ну это уж перебор. До сих пор идут холивары maven vs gradle, и вполне возможно куча народа до сих пор сидит на мавене. Я вот на gradle так и не сделал ни одного проекта . Более того, у меня текущий проект вообще собирается с помощью ant . Я конечно соберу gradle проект, но мне придется гуглить . А по умолчанию для Java у меня по прежнему maven. Ибо для maven у меня настроен в конторе прокси и тому подобное, а для gradle мне снова придется гуглить как это сделать. Если кто думает, что я gradle не способен осилить — он сильно ошибается . Более того, я уже года 3 даже мавеном не собираю . Но какое то отношение к Java все таки имею .

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

A>я написал тест, они посмотрели и ответили что no go. я спросил почему. они прислали список претензий; я ответил
А зачем ответил? Думаешь что это что-то изменит?

B>>Печально потому, что ты утверждаешь, что у тебя 13 лет экспы. За 13 лет можно наверное было поднавтыкаться читать доки на минимальном уровне, да и раньше наверняка занимался чем-то схожим, там должны были быть похожие конструкции.
A>что за ерунду ты пишешь?
A>что за культура предсказателей?
У тебя повышенная возбудимость, ты в этом не виноват — гены поднасрали. Ты в очередной раз махнешь рукой на непрошенный совет, но все же — почитай про майндфулнэс и медитацию. Если не поможет, то можно сходить на курсы anger management.

B>>Это на самом деле говорит о низкой мотивации, и низком уровне самообразования. Когда у программиста нет любопытства — это так себе программистЪ, просто человек работающий за деньги Кого-то это устроит, кого-то нет. Я бы не рекомендовал брать, выше по трэду говорят что норм.
A>я для начала предлагаю тебе научиться врубаться в контекст, а потом рассуждать про мой уровень чего бы то ни было
Зачем мне врубаться во что-то? Есть определенные маркеры, которые говорят — go or no go. С моей точки зрения ты показал множественные no go, и уже третий день пытаешься нас всех агрессивно переубедить и доказать что ты хороший и все сделал правильно. Я собственно, поэтому бы и не стал брать. Мне лично на работе не нужны истерики и драматурги, с которыми надо тратить время на уговоры.

A>>>у меня прям в коде есть коммент "mock Storage?". Я просто не стал этого делать
B>>А почему не стал? Это же десяток строк полуавтоматического кода.
A>времени жалко
А три дня проведенные в этом срачике совсем не жалко?

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

...

меня просто раздражают тупые люди. последовательно тупые.

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

B>Ну, справедливости ради очень мало кто использует ортодоксальный подход с HTTP verbs для разделения сути операций, почти все юзают GET и POST.

Не знаю. Все кто заслуживает упоминания — более менее придерживаются. И уж по крайней мере идемпотентность при операциях с балансом счета — must have, ибо иначе адъ.

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

A>при том, что для прода и за деньги была бы проделана работа другого объема и качества

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

...

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

Остальным спасибо за ваше время.

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

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

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


IB> add(from, amt.negate())
IB>// Здесь кто-то запросит list, и получит ответ ???!!!!
Это в какой-то мере нормально, с одной стороны. По договорённости list может выдавать немного меньше доступных денег на счетах если есть незавершенные транзакции. Хотя обычно банки сообщают две циферки — доступное кол-во денег и зарезервированное, чтобы баланс всегда сходился.
С другой стороны, чтобы добавить такое в оригинальное решение — придётся много чего перелопатить.

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

A>ну zip для вас. для них был github, но там мое реальное имя, а я не палюсь ))
Сделай другой аккаунт. Мало кто захочет скачивать архив.

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

A>Попросили сделать тестовое задание часов за 6-12 (всего на задание давали примерно неделю):
A>Design and implement a RESTful API (including data model and the backing implementation)
A>for money transfers between accounts.

A>код — https://github.com/arthells/mtest
Как минимум самая важная операция по ТЗ — transfer, не является атомарной. Думаю, это сильно уменьшило баллов.

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

SVZ>>Т.к. это тестовое задание, то наверняка приветствуется некая пояснительная записка, где будут оговариваться принятые ограничения и которая содержит комментарии к решению.
SVZ>>2ТС: Была записка? В коде ничего подобного не нашел.

A>нет, в стартовом посте все что есть. было сказано что обычно на такое задание тратят 6-12 часов, что стало для меня референсом

A>там ясно сказано что no explicit requirements, use common sense

Ну т.е. ты предложил второй стороне разбираться самим, какие соглашения ты выбрал и угадывать, почему именно так?
Я бы такое не оценил.
"common sense" он у всех свой Вот они и оценили соответственно.

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

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

A>>код — https://github.com/arthells/mtest

GIV>Как то смущает рукопашный разбор параметров. Почему не https://dinject.io/javalin ?

почему рукопашный? тот же javalin вроде.

GIV>Ну и для датастора я бы ожидал какую-нибудь ин мемори бд.

зачем? чтобы просто показать, что я умею затащить в апп как депенденси и сделать таблицу из 2х полей?

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

GIV>>Как то смущает рукопашный разбор параметров. Почему не https://dinject.io/javalin ?
A>почему рукопашный? тот же javalin вроде.

Я про @Post вместо

 val to = ctx.queryParam("to") ?: throw IllegalArgumentException("@to is required.")

GIV>>Ну и для датастора я бы ожидал какую-нибудь ин мемори бд.
A>зачем? чтобы просто показать, что я умею затащить в апп как депенденси и сделать таблицу из 2х полей?

Так мне мой common sense говорит

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

A>Попросили сделать тестовое задание часов за 6-12 (всего на задание давали примерно неделю):
A>Design and implement a RESTful API (including data model and the backing implementation)
A>for money transfers between accounts.

A>Я написал и им не понравилось. Не оч понимаю, чего они хотели и где я налажал?

https://www.google.com/search?q=%22(including+data+model+and+the+backing+implementation)%22&oq=%22(including+data+model+and+the+backing+implementation)%22

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

M> Как уже правильно сказали, в readme не написано, как собирать. Одна-две строчки много времени не займут, а для читающего приятно и не надо вспоминать, какая там у вас культура.

Если человек не знает, как собрать проект на Gradle, он к Java не имеет отношения.

M> У вас там в бинарниках трояна нет? Это я к тому, что бинарники в репозитории — это нехорошо. Я знаю, что "все так делают". Но это ведь показывает, как вы подходите к выбору инструмента. Если у вас команда везде использует gradle, почему она не устанавливает глобально wrapper и не хранит только настройки в repo? Было бы логично, и можно было бы с причинами в readme описать, почему так сделано. Аналогичный инструмент есть для maven. Ну а sbt это из коробки уже давным давно сам поддерживает.

Официальная рекомендация от разработчиков Gradle — коммитить враппер в репозиторий: "To make the Wrapper files available to other developers and execution environments you’ll need to check them into version control." Всё остальное это уже ваши местечковые тараканы, которые нормальный человек угадывать не в состоянии и уж придираться к этому никак нельзя.

Нафиг такие тестовые задания!

Тестовое задание должно быть рассчитано максимум на один час.

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

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.
Они, конечно же, правы. Комон сенс здесь как бы орет, что метод должен быть трэдсейф.

A>Insufficient testing coverage
A>nothing to say. It's 6hrs test. Not 40hrs
Ты в курсе, что твои комменты очень грубые? Люди платят премиальные деньги не только за скилл, но и за приятную работу. Ты конечно не послушаешь, но я бы посоветовал тебе поработать над софт скиллами.

A>If we transfer negative amount money, author don’t throw exceptions, it takes abs value of this amount and transfer positive amount of money.
A>transferring negative amount is something which is odd. So it's a
A>convention. It either has to be documented or exception should be
A>thrown. So I partially agree.
ИМО это эпичный фэйл, а не partially agree.

A>Author don't know how to catch exceptions in junit
A>minor. Nothing to add.
Эм. Ты и правда не знаешь как ловить эксепшены или это что-то другое?

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

Честно говоря, по американским меркам, ты им посто нахамил. Думаю, что можно списать на разницу культур, учитывая общий уровень англ. — но вообще это просто жесть.

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

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.

Не поленился — посмотрел, но синхронизации я не нашел. Поясни, как она делается, и это самое атомисити достигается.
Транзакии/аккаунт — классические пример для синхронизации. И да, для сервиса — это и так понятное требование.

A>Insufficient testing coverage
A>nothing to say. It's 6hrs test. Not 40hrs
в принципе тут просто более внятно надо ответить было, и все
хотя я бы тесты вместе с интерфесами нахерачил, а потом имплементацию лепил

A>If we transfer negative amount money, author don’t throw exceptions, it takes abs value of this amount and transfer positive amount of money.
A>transferring negative amount is something which is odd. So it's a
A>convention. It either has to be documented or exception should be
A>thrown. So I partially agree.
ну это вообще саботаж какой-то, кмк

A>Author don't know how to catch exceptions in junit
A>minor. Nothing to add.
мдааа

A>Procedure of transferring money is not clear and difficult to support
A>no comment.
Сложность — понятие нескольно субъективное, но да. Пишешь не очень понятно местами. Кучка разбрсанных мелких классов,

A>Poor documentation — there is no specifications of endpoints, how to build a project
A>KL — there is a README. And there is a build.gradle. It's kind of
A>misunderstanding what we expect from 6hrs test.

Вот кстати, уже более внятное объяснение. К концы начало получаться немного.

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

A>>>я, строго говоря, им ничего не должен, как и они мне. вот если бы я на них работал, было бы другое дело.
B>>Ты к ним и не попадешь, если будешь и впредь продолжать жить в парадигме совковой настырности. Это не оскорбление, а констатация факта, я сам был таким же, и это стоило мне довольно дорого.
A>так я и не собираюсь к ним попадать.
А какой тогда смысл? Не могу уловить.

A>>>>>>>Author don't know how to catch exceptions in junit
A>>>если по теме, то я не совсем понял суть предложения "Author don't know how to catch exceptions in junit". как ловить эксепшены вне Junit я, кажется, знаю)
B>>Я не джавист, но полагаю что речь вот об этом:

B>>Это собственно, очень печально, поскольку такой функционал появился, судя по release notes, появился в 2006 году. Ты должен был объявить кастомный эксепшен для этой ситуации, и кидать его, а юнит-тест, полагаю, должен был быть таким:
A>почему печально? я просто этого не знал. может быть потому, что на джаве в прод писал я меньше года. и это как-бы публичная инфа для работодателя.
Печально потому, что ты утверждаешь, что у тебя 13 лет экспы. За 13 лет можно наверное было поднавтыкаться читать доки на минимальном уровне, да и раньше наверняка занимался чем-то схожим, там должны были быть похожие конструкции.

Это на самом деле говорит о низкой мотивации, и низком уровне самообразования. Когда у программиста нет любопытства — это так себе программистЪ, просто человек работающий за деньги Кого-то это устроит, кого-то нет. Я бы не рекомендовал брать, выше по трэду говорят что норм.

A>у меня прям в коде есть коммент "mock Storage?". Я просто не стал этого делать
А почему не стал? Это же десяток строк полуавтоматического кода.

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

SL>Пришел человек с кэшем: как в рамках этой модели кэш попадает на "счет кассы"?

Дебет счета "Деньги в кассе"
Кредит — "Счет клиента"

Проверка — сумма по дебету и по кредиту равна
Сумма на счете "деньги в кассе" равна тому сколько налички должно быть в кассе
Сумма в кредите "Счета клиентов" общей сумме денег клиентов.

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

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

A>зачем? чтобы просто показать, что я умею затащить в апп как депенденси и сделать таблицу из 2х полей?

Чтобы показать что ты знаешь что такое БД, умеешь правильно делать ее схему, знаешь что такое транзакция и уроыень ее изоляции. Ты же показал, что очень далек от финансовых приложений.
Второй момент — ты конкретно так накосячил с REST API. Т.е. ты вообще не знаешь что такое REST, у тебя самая примитивная ошибка — глаголы в урлах. Чего не должно быть в принципе.
Итого: не знаешь БД, не знаешь REST.

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

A>я не собеседуюсь на database guy.

Ну какой уж тут database guy? Тебя ж не спрашивают про планы запросов и т.п. Но если контора или отдел, в который ты обеседуешься, как то связана с БД, то они вправе ожидать хотя бы азов

A> как работают реальные банковские транзакции я не знаю и не обязан знать.

Речь не про банковские, а про танзакции СУБД.

НС>>Второй момент — ты конкретно так накосячил с REST API. Т.е. ты вообще не знаешь что такое REST, у тебя самая примитивная ошибка — глаголы в урлах. Чего не должно быть в принципе.
A>это очень сильное утверждение. многие рест от известных и уважаемых команд болт кладут на verbs и правильно делают

А, ну тогда продолжай в том же духе. Только не удивляйся очередному no hire.

НС>>Итого: не знаешь БД, не знаешь REST.
A>бред

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

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

Ну да, и с хамством у тебя тоже проблемы.

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

A>> где я налажал?
IM>стал делать тестовое задание

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

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

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

A>>зато у тебя все в порядке, ага

НС>А что ты ожидал услышать в ответ? Я ко всем тут отношусь уважительно, если они своим поведением не докажут необходимость обратного. Если уж хамишь людям, будь готов в ответ получить то же самое.

я здесь ни разу первым тебе не нахамил. первые твои сообщения — сплошной наезд и домыслы.

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

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

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

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

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

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

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

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

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

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

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

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

а мог бы за 5 работать час дома.
но нет, и доширака хватит.

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

F>а мог бы за 5 работать час дома.
F>но нет, и доширака хватит.

да мог бы вообще не работать, а получать 5. Куда еще уфантазируешься?

Попросили сделать тестовое задание часов за 6-12 (всего на задание давали примерно неделю):
Design and implement a RESTful API (including data model and the backing implementation)
for money transfers between accounts.
Explicit requirements:
1. You can use Java, Scala or Kotlin.
2. Keep it simple and to the point (e.g. no need to implement any authentication).
3. Assume the API is invoked by multiple systems and services on behalf of end users.
4. You can use frameworks/libraries if you like (except Spring), but don't forget about
requirement #2 – keep it simple and avoid heavy frameworks.
5. The datastore should run in-memory for the sake of this test.
6. The final result should be executable as a standalone program (should not require
a pre-installed container/server).
7. Demonstrate with tests that the API works as expected.
Implicit requirements:
1. The code produced by you is expected to be of high quality.
2. There are no detailed requirements, use common sense.

Ну я подумал что от меня за 6 часов не хотят увидеть prod-ready решения, всякие хинты вроде in-memory datastore и отсутствие реальных требований и common sense как-бы наводят на мысль, что нужно просто продемонстрировать что могу написать адекватный hello world.
Я написал и им не понравилось. Не оч понимаю, чего они хотели и где я налажал?

Понятно что в реальном мире многое было бы иначе. Отдельные проекты для model/core etc., другая модель, другой data pipeline etc.
Думал, что от меня хотят чтобы я выбирал решения к месту, не занимался overdesign и overengineering etc., показал базовые вещи вроде разделения контракта и реализации, di, testability, стиль кода, который подходит к Kotlin ну и так далее.

код — https://github.com/arthells/mtest

спасибо

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

A>код — https://yadi.sk/d/rZw2gQ2M74B9eA
zip?

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

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

A>>код — https://yadi.sk/d/rZw2gQ2M74B9eA
S>zip?

ну zip для вас. для них был github, но там мое реальное имя, а я не палюсь ))

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

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

A>>ну zip для вас. для них был github, но там мое реальное имя, а я не палюсь ))
S>Сделай другой аккаунт. Мало кто захочет скачивать архив.

выложил на github, поправил стартовое сообщение

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

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

можно было делать неделю, но по их словам в среднем они ожидают что чистого времени — 6-12 часов.

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

..

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

можно было делать неделю, но по их словам в среднем они ожидают что чистого времени — 6-12 часов.

S>Соответственно, никто (кроме задающего задание) не скажет тебе, что именно ты там не так придумал.

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

S>Одно вот это

A>>2. There are no detailed requirements, use common sense.

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

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

Т.к. это тестовое задание, то наверняка приветствуется некая пояснительная записка, где будут оговариваться принятые ограничения и которая содержит комментарии к решению.
2ТС: Была записка? В коде ничего подобного не нашел.

S>Соответственно, никто (кроме задающего задание) не скажет тебе, что именно ты там не так придумал.

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

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

A>Понятно что в реальном мире многое было бы иначе. Отдельные проекты для model/core etc., другая модель, другой data pipeline etc.
А ты у них спрашивал?

Здравствуйте, Stanislav V. Zudin, Вы писали:

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

S>>Одно вот это

A>>>2. There are no detailed requirements, use common sense.

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

SVZ>

SVZ>так как данный курсовой проект все равно никто читать не будет, делаем сердечник трансформатора из дерева

SVZ>Т.к. это тестовое задание, то наверняка приветствуется некая пояснительная записка, где будут оговариваться принятые ограничения и которая содержит комментарии к решению.
SVZ>2ТС: Была записка? В коде ничего подобного не нашел.

нет, в стартовом посте все что есть. было сказано что обычно на такое задание тратят 6-12 часов, что стало для меня референсом

S>>Соответственно, никто (кроме задающего задание) не скажет тебе, что именно ты там не так придумал.

SVZ>Оговаривать с задающим до начала выполнения тестового задания не только не запрещается, но даже поощряется.

там ясно сказано что no explicit requirements, use common sense

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

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

A>>Понятно что в реальном мире многое было бы иначе. Отдельные проекты для model/core etc., другая модель, другой data pipeline etc.
K>А ты у них спрашивал?

нет, дали понять что в описании все сказано

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

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

A>>Попросили сделать тестовое задание часов за 6-12 (всего на задание давали примерно неделю):
A>>Design and implement a RESTful API (including data model and the backing implementation)
A>>for money transfers between accounts.

A>>код — https://github.com/arthells/mtest
T>Как минимум самая важная операция по ТЗ — transfer, не является атомарной. Думаю, это сильно уменьшило баллов.

1/ в ТЗ не сказано, что она должна быть атомарной
2/ в реальном мире она нигде не атомарна и не может быть таковой

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

A>Попросили сделать тестовое задание часов за 6-12 (всего на задание давали примерно неделю):
A>Design and implement a RESTful API (including data model and the backing implementation)
A>for money transfers between accounts.

A>спасибо

Ну, не знаю. Самое просто, а почему для money у вас BigDecimal?

Здравствуйте, Stanislav V. Zudin, Вы писали:

..

SVZ>Ну т.е. ты предложил второй стороне разбираться самим, какие соглашения ты выбрал и угадывать, почему именно так?
SVZ>Я бы такое не оценил.
SVZ>"common sense" он у всех свой Вот они и оценили соответственно.

ну это не была q&a сессия и ее наличие как-бы не предполагалось
обычно она случается уже после, по результатам теста

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


A>>2/ в реальном мире она нигде не атомарна и не может быть таковой
S>ACID

ну в реальном мире с реальными требованиями все сложнее чем аббревиатуры. теоретически можно в контексте _этого_ задания сделать atomic move,
но я решил, что достаточно atomic exchange (add). конкретно здесь я не вижу необходимости и потенциальных race conditions тоже — основные операции атомарны, а
сам wallet введен лишь как иллюстрация возможного BL
ну то есть за бабки в пилот я бы написал совсем иначе, но для тестового задания я выбрал такой путь и не очень понимаю почему он неверен

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

Insufficient testing coverage
nothing to say. It's 6hrs test. Not 40hrs

If we transfer negative amount money, author don’t throw exceptions, it takes abs value of this amount and transfer positive amount of money.
transferring negative amount is something which is odd. So it's a
convention. It either has to be documented or exception should be
thrown. So I partially agree.

Author don't know how to catch exceptions in junit
minor. Nothing to add.

Procedure of transferring money is not clear and difficult to support
no comment.

Poor documentation — there is no specifications of endpoints, how to build a project
KL — there is a README. And there is a build.gradle. It's kind of
misunderstanding what we expect from 6hrs test.

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

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

A>>выложил на github, поправил стартовое сообщение
S>Может им не понравилось, что нет истории разработки? (Все одним коммитом.)

это другой репо. для них я открывал и там несколько коммитов с моим настоящим именем

S>Вообще если дали тз на несколько часов, а потом леняться дать вменяемый ответ что для них плохо, то с чистой совестью можете раскрывать название конторы.

ответ дали после того как я их попросил/он ниже в ветке

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

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

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.

AC>вообще то было в требованиях, конкурентное исполнение.

atomicity и конкурентное исполнение не одно и то же/и мой код concurrent safe

A>>Insufficient testing coverage
A>>nothing to say. It's 6hrs test. Not 40hrs

AC>тоже было в требованиях.

да, и у меня 20 или больше тестов

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

...
E>Здесь они в принципе правы. Для тестовых заданий я делаю базовую атомарность, тупо ставлю synchronized на все методы бизнес логики, чтоб не заморачиваться и оно работало. Оптимизировать влом и все эти оптимизации потом. Даже если там атомарность есть фактическая — совсем не очевидно что она есть, лучше явно по умолчанию поставить лок, да и все.

ну а на что им мозг? чтобы смотреть и разбираться/атомарность там есть в нужном объеме

A>>Procedure of transferring money is not clear and difficult to support
A>>no comment.
E>Здесь они тоже правы. Там логика то простейшая, но навернул ты сильно больше, чем можно было бы сделать. Лучше б простой императивщиной в лоб бы сделал да и все. Я про метод add, а не про transfer. Такое впечатление что начитался про паттерн матчинг и захотел непременно применить что то похожее. Да и transfer тоже — amount.abs() и доп логика.

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

E>То есть код можно было сделать одновременно и более простым, и более надежным. Плюс более компактным. Еще я б для тестового задания не стал бы выделять интерфейс. Принципиально не стал бы, если бы стали придираться — аргументировал бы тем, что мне не нужна дополнительная сложность и дополнительный код на ровном месте. При необходимости рефакторинг вида extract interface делается мгновенно, и если у интерфейса только одна реализация, то лучше не выпендриваться и не городить доп сложность на ровном месте.

ну, зачем на котлине писать в императивном стиле, подумал я/

E>Но, только бы за эти недочеты я бы браковать не стал.

спасибо за фидбек

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

A>Попросили сделать тестовое задание часов за 6-12 (всего на задание давали примерно неделю):
A>Design and implement a RESTful API (including data model and the backing implementation)
A>for money transfers between accounts.
Не смотря на то, что делать домашнее задание в 2019 году это полная дикость, все же глянул одним глазом.
Не понравилась модель предметной области.
Если с Account, который id + amount еще как-то можно смириться в тестовом задании, то кто такой Wallet?
Его интерфейс и реализация никак не следуют из названия.
Это что-то более похожее на Transaction чем на Wallet.
Зачем вообще нужен add, когда у вас в задании "money transfers between accounts"?
Почему пополнение счета не сделать как transfer(from='Cash/Wire', to=account)?

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

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

A>>Попросили сделать тестовое задание часов за 6-12 (всего на задание давали примерно неделю):
A>>Design and implement a RESTful API (including data model and the backing implementation)
A>>for money transfers between accounts.

A>>Я написал и им не понравилось. Не оч понимаю, чего они хотели и где я налажал?

mgu>https://www.google.com/search?q=%22(including+data+model+and+the+backing+implementation)%22&oq=%22(including+data+model+and+the+backing+implementation)%22

и что, такое им понравилось?

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

A>ну а на что им мозг? чтобы смотреть и разбираться/атомарность там есть в нужном объеме
Вообще то основное правило — при чтении кода мозг напрягаться не должен . Исключение — когда это высоко оптимизированный код, тут приходится. Соответственно решение по умолчанию — это минимальное количество кода, максимальная линейность кода, минимальный уровень вложенности. Применив merge ты возможно увеличил производительность по сравнению с решением в лоб, но понизил читаемость и поддерживаемость кода. Кстати, если уж начал выпендриваться с не совсем очевидной атомарностью — тест бы на параллельную попытку изменить счет бы не помешал. Накосячить на вот таких неблокирующих операциях на практике очень и очень легко, соответственно если решил так повыпендриваться, то тест нужно написать по любому. Если бы сделал через synchronized в лоб, причем synchronized был бы на все методы, то тут можно было бы и схалявить, ибо скорее всего ты бы не ошибся, но на более продвинутых решениях тестировать все таки надо.

У меня как то был случай, когда я увидел не неатомарность в чужом коде. Было запутанно, я предположил что автор проверил нормально, тем более он там был спец по алгоритмам, в олимпиадах участвовал и т.д. Так вот, он блин все таки ошибся и его творчество пришлось мне переписывать после того как он уволился. А шишки полетели на меня, исправлять ошибки в авральном режиме пришлось мне, не смотря на то, что код мне достался в наследство.

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

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

T>>Ну, не знаю. Самое просто, а почему для money у вас BigDecimal?
E>Оно вообще то всю жизнь было рекомендованным решением по умолчанию для денег. Сейчас что, появились новые рекомендации и я что то пропустил?

Интернет банкингом вы наверно пользуетесь? Как думаете, возможно ли там сделать операцию и перевести 0.005 рубля?

В Java есть Money API, правдо оно ни как не дойдет до включения в JDK. Можно посмотреть его как на пример дизайна.

А так, как минимум у любого счета есть тип валюты этого счета. Что тоже минус в вашей модели.

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

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

A>>Попросили сделать тестовое задание часов за 6-12 (всего на задание давали примерно неделю):
A>>Design and implement a RESTful API (including data model and the backing implementation)
A>>for money transfers between accounts.
L>Не смотря на то, что делать домашнее задание в 2019 году это полная дикость, все же глянул одним глазом.
L>Не понравилась модель предметной области.
L>Если с Account, который id + amount еще как-то можно смириться в тестовом задании, то кто такой Wallet?

по сути mock бля будущего BL. Wallet не в смысле "интерфейс для манипуляций с деньгами конкретного пользователя", а интерфейс всего сервиса. Сервис в тестовом задании
напоминает простой кошелек. Нейминг не на все 100 удачный, возможно.

L>Его интерфейс и реализация никак не следуют из названия.

следуют, если считать что это главный интерфейс сервиса

L>Это что-то более похожее на Transaction чем на Wallet.
L>Зачем вообще нужен add, когда у вас в задании "money transfers between accounts"?

потому что они как-то на аккаунтах должны появляться

L>Почему пополнение счета не сделать как transfer(from='Cash/Wire', to=account)?

зачем? для унификации интерфейса? я против, потому что для тестового задания — избыточно а в реальном мире еще может быть и вредно (думаю, из-за разных входных параметров при переводе из разных типов источников), но то отдельный вопрос, выходящий за пределы топика. все это должно обсуждаться уже после на реальных требованиях

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

A>>>Я написал и им не понравилось. Не оч понимаю, чего они хотели и где я налажал?

mgu>>https://www.google.com/search?q=%22(including+data+model+and+the+backing+implementation)%22&oq=%22(including+data+model+and+the+backing+implementation)%22

A>и что, такое им понравилось?

Да я к тому, что как рецензенты, неспособные сами придумать тестовое задание, могут комментировать результат? Замечания по делу? Умные слова? Так это другие бедолаги пишут, есть и такой вид работы на дом -- "оцените код".

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

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

vsb>Если человек не знает, как собрать проект на Gradle, он к Java не имеет отношения.

Не Gradle-ом единым жива Java.

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

A>код — https://github.com/arthells/mtest

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

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

Вам не кажется что с таким отношением можно примелькаться до лисчной неприязни и попадания в бан-листы? Т.е. потенциальным коллегам говорить заранее чтобы они потратили на Вас уйму времени чтобы Вы "потренировались"?

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

G>Вам не кажется что с таким отношением можно примелькаться до лисчной неприязни и попадания в бан-листы? Т.е. потенциальным коллегам говорить заранее чтобы они потратили на Вас уйму времени чтобы Вы "потренировались"?
Во первых, я таким делом редко занимаюсь. Раз в год где то. А во вторых, я говорю сразу, что работаю, в принципе доволен, работу если и ищу, то пассивно, мониторю рынок труда, вдруг какой фигней занимаюсь, соответственно куда то пойду только если будут сильно лучшие условия. Более того, периодически сам таких собеседовал. Было реально интересно собеседовать сотрудника JetBrains, например . И в третьих, контор очень много. Более одного раза я только в люксофт собеседовался, наверно раз 5 .

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

A>напоминает простой кошелек. Нейминг не на все 100 удачный, возможно.
В том-то и дело, что кошелек принадлежит конкретному владельцу, у вас же через него проходят транзакции кого угодно. В этом и главная проблема выбранного имени.

L>>Зачем вообще нужен add, когда у вас в задании "money transfers between accounts"?
A>потому что они как-то на аккаунтах должны появляться
Деньги не могут появиться на счете из воздуха, у них всегда есть источник — парный счет в транзакции.

Т.е. если бы я был сотрудником этой конторы, проводящем ревью тестового задания, то в заключении бы написал, что, скорее всего, очень много придется вложиться в обучение и погружение в предметную область и первые полгода-год кандидату нельзя будет поручать design & architecture.

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

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

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.
B>Они, конечно же, правы. Комон сенс здесь как бы орет, что метод должен быть трэдсейф.

он thread-safe во всех смыслах.

A>>Insufficient testing coverage
A>>nothing to say. It's 6hrs test. Not 40hrs
B>Ты в курсе, что твои комменты очень грубые? Люди платят премиальные деньги не только за скилл, но и за приятную работу. Ты конечно не послушаешь, но я бы посоветовал тебе поработать над софт скиллами.

кто платит премиальные деньги? откуда такая информация? и откуда ты знаешь насколько со мной приятно работать?

A>>If we transfer negative amount money, author don’t throw exceptions, it takes abs value of this amount and transfer positive amount of money.
A>>transferring negative amount is something which is odd. So it's a
A>>convention. It either has to be documented or exception should be
A>>thrown. So I partially agree.
B>ИМО это эпичный фэйл, а не partially agree.

эпичный фейл это отсутствие abs. а с abs это просто другая культура

A>>Author don't know how to catch exceptions in junit
A>>minor. Nothing to add.
B>Эм. Ты и правда не знаешь как ловить эксепшены или это что-то другое?

эмм, ты и правда доволен своими софт-скилами?

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

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

A>>напоминает простой кошелек. Нейминг не на все 100 удачный, возможно.
L>В том-то и дело, что кошелек принадлежит конкретному владельцу, у вас же через него проходят транзакции кого угодно. В этом и главная проблема выбранного имени.

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

L>>>Зачем вообще нужен add, когда у вас в задании "money transfers between accounts"?
A>>потому что они как-то на аккаунтах должны появляться
L>Деньги не могут появиться на счете из воздуха, у них всегда есть источник — парный счет в транзакции.

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

L>Т.е. если бы я был сотрудником этой конторы, проводящем ревью тестового задания, то в заключении бы написал, что, скорее всего, очень много придется вложиться в обучение и погружение в предметную область и первые полгода-год кандидату нельзя будет поручать design & architecture.

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

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

A>>>Insufficient testing coverage
A>>>nothing to say. It's 6hrs test. Not 40hrs
B>>Ты в курсе, что твои комменты очень грубые? Люди платят премиальные деньги не только за скилл, но и за приятную работу. Ты конечно не послушаешь, но я бы посоветовал тебе поработать над софт скиллами.
A>кто платит премиальные деньги? откуда такая информация?
Очевидно, что соглашаясь на тестовое задание в 6 часов, ты рассчитываешь на какие-то премиальные деньги. Ты же не станешь делать тестовое задание в контору, где платят в 2 раза меньше чем ты имеешь сейчас.

A>и откуда ты знаешь насколько со мной приятно работать?
Из фрагмента твоей деловой переписки. После такого матраса я бы на месте интервьюера порекомендовал бы no-go. Собственно, советую не очень удивляться, получая отлупы на казалось бы ровном месте. Одно дело желание агрессивно заэнфорсить свое мнение в срачике на РСДН, и совсем другое — работая в западной конторе. Впрочем, я думаю в Нетфликсе тебе бы очень понравилось.

A>>>If we transfer negative amount money, author don’t throw exceptions, it takes abs value of this amount and transfer positive amount of money.
A>>>transferring negative amount is something which is odd. So it's a
A>>>convention. It either has to be documented or exception should be
A>>>thrown. So I partially agree.
B>>ИМО это эпичный фэйл, а не partially agree.
A>эпичный фейл это отсутствие abs. а с abs это просто другая культура
Мде.

A>>>Author don't know how to catch exceptions in junit
A>>>minor. Nothing to add.
B>>Эм. Ты и правда не знаешь как ловить эксепшены или это что-то другое?
A>эмм, ты и правда доволен своими софт-скилами?
Нет, не очень, честно признаться.

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

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

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

реально не поленюсь

M>>>Как уже правильно сказали, в readme не написано, как собирать. Одна-две строчки много времени не займут, а для читающего приятно и не надо вспоминать, какая там у вас культура.
A>>камон. я не для домохозяек туториал пишу.
M>Не для домохозяек. Но вы предполагаете, что проверяющий хорошо знает все модные тренды во всех трех предложенных языках. А это может быть и не так. Может, они Java позволяют только для того, чтобы иметь больший круг кандидатов и потом переучивать их на используемый стек. Можно не иметь подробного описания сборки для проектов внутри команды, общее знание достигается через onboarding и тренировку. А вот для тестового задания две-три строчки о сборке будут полезны. Еще показывают, что вы все-таки задумываетесь о пользователях и умеете в какой-то мере бороться с проекцией "я знаю, значит и все остальные должны знать".

давайте без демагогии. gradle это не "еще одна билд система из миллиона билд систем". если ты видишь build.gradle в проекте и все еще не знаешь куда смотреть чтобы его собрать — ну тогда у нас с тобой разная культура и нам не по пути

M>>>У вас там в бинарниках трояна нет?
A>>это тестовое задание. как и что это показывает — от "ничего" вплоть до "все"
M>Но вы же согласились его делать. Значит согласны, что что-то оно показывает? Свобода выбора технологий как раз полезна — показывает, о каких глубоких вопросах задумывался кандидат. И какие предпочтения имеет.

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

M>>>Тесты. Вы их с падающими assert проверяли? У меня вот подозрение, что после первого падения все остальное упадет с AddressAlreadyInUse. Что как-то нехорошо. Например потому, что после этого нужно исправлять первый упавший тест а не любой понравившийся.
A>>проверял
M>Ну и как? Удобно находить, где там ошибка? Я вот специально сейчас сломал один тест. Получил четыре AssertionError без каких-либо внятных сообщений об ошибках. Пришлось копаться в стеках, чтобы понять, откуда они происходят. Дополнительные сложности там, где их легко избежать.

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

M>>>Не StorageTest а StorageImplTest. Вот представьте, у вас есть несколько реализаций Storage. Какую из них тестирует StorageTest?
A>>вы серьезно?
M>Конечно. StorageTest по названию — это тест на соответствие спецификации (compliance). Т.е. любая реализация должна проходить эти тесты (которые с большой вероятностью property based). Здесь же можно поговорить про то, как сложно делать тесты, параметризованные объектами. При этом тесты конкретных реализаций либо расширяют StorageTest (и обходят ограничения фреймворков тестирования), или тестируют какие-то дополнительные свойства, характерные для этих реализаций.

это все круто, но не к месту совсем.

M>>>Ваш restful тянет только на Level 0 (используется HTTP). Банальный RPC over HTTP. SOAP, кстати, тоже попадает в REST Level 0. Хотелось бы видеть хотя бы Level 1 — Entities & Verbs (т.е. PUT /accounts/abc, GET /accounts, ...).
A>>кому хотелось и зачем?
M>Ну в первую очередь вам. Потому что вы хотели продолжения интервью или найма. Хотелось бы мне. Как минимум потому, что приятно поговорить с кандидатом с широким кругозором. За реализацию Rest Level 1 вы бы получили плюсик. А на самом деле при создании API вы скорее всего вспомнили бы причины, по которым REST был спроектирован в его виде. И задумались бы про идемпотентность (idempotency) операций. Не обязательно ее реализовывать, можно было просто упомянуть в readme: "идемпотентность не реализована из-за ограничений на время, могу прислать план реализации по запросу". И получили бы сразу пять плюсиков.

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

M>Idempotency здесь очень важна. Вот представьте, я вызвал ваш RPC API и получил IOException. Вот что я с ним должен делать? Ничего (и рисковать, что запрос был потерян)? Или повторять запрос (и рисковать, что я проведу операцию дважды)? Вот из-за вашего API мне придется городить Artificiall Intelligence (искуственную разведку), которая будет выяснять состояние предыдущей операции прежде чем повторять. А с идемпотентным REST я бы ее просто повторил и сказал вам большое спасибо. Ситуация вполне реальная, и в том числе в финансовой сфере . Это — основная причина, по которой Rest Level 1 хотелось бы видеть лично мне.

вот про Idempotency в тему, наконец-то. это интересный топик поговорить, но не в рамках тестового задания. остальные замечания по поводу level'ов — странная любовь к классификациям. все, что идет после verbs вообще довольно мутная история.

M>>>Ожидание ввода в main — решение спорное. Как оно поведет себя в каком нибудь Kubernetes? Там некому будет вводить порт. Вообще право на жизнь оно имеет, но такие сюрпризы должны описываться в readme.
A>>надеюсь вы несерьезно, потому что тест не для запуска в Kubernetes
M>Серьезно. Потому что кандидат, написавший 5 приложений под Kubernetes, не будет вообще писать ввод. И опишет аргументы командной строки в README. Может это и не страшно, зависит от конкретной позиции, на которую вы претендуете.

ну да, не написал, то джуниор, написал — архитект. ладно, спишем на разную культуру

M>>>*Impl. Это вот у вас ровно одна реализация предполагается? Почему бы не InMemoryStorage, например?
A>>а у вас? и почему если не одна, то не InMemoryCuncurrentHashSetStorageImpl? понятно куда клоню?
M>А у меня — несколько реализаций предполагается. И обычно их и есть несколько. Очень часто отдельная in-memory (или какая-то упрощенная) для тестов. Во многих случаях — декораторы. За что-то более осмысленное чем *Impl получили бы плюсик. Против вашего длинного варианта ничего не имею, он выше минимальных ожидаемых стандартов. За последовательное следование вашей конвенции (и сохранение нужных уровней абстракции и т.п.) получили бы сразу два плюсика. И я бы начал задумываться, а не стоит ли внедрить ваш стиль для всей команды.

Impl — вполне осмысленно, если нет ничего иного, и, опять же, в контексте тестового задания

M>>>Я бы вообще эти реализации спрятал за Factory Method. Потому что тогда их можно по желанию менять, разбивать/переразбивать на разные классы и т.п. В конце концов, все использования идут только через реализованные интерфейсы.
A>>нечего добавить. не вижу в 2019 году задачи явно показывать знание Factory Method
M>А вот и не угадали . Это задача на проектирование API, минимизирующего изменения в кодовой базе и расширяющего круг возможных рефакторингов. Один конкретный случай, конечно, не влияет. Но ведь проектирование таких API — это автоматизированный навык (подобных решений разработчики делают много). А вот на большой кодовой базе преимущества factory method уже будут заметны. Опять же, я на самом деле не требую именно фабричный метод (это один плюсик). Любое другое API, служащее той же цели (минимизация потенциальных изменений и расширение простора для рефакторинга) даст вам как минимум два плюсика.

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

M>>>В StorageImpl вложенность кода глубокая. Можно было бы спрямить через if/throw и if/return.
A>>а можно было и нет. дело вкуса
M>Это конечно да. Но толерантность к глубоким стрелкам настроаживает. Очень часто приводит к длинным и глубоким вложенностям, условиям и т.п. А потом мне приходится вспоминать, к чему же относится одинокий else с одной строчкой после большого блока кода, где его if не влез на его страницу. Чем меньше надо помнить — тем лучше.

давайте не будем заниматься гаданием что к чему приводит. тут вложенность 3. 3, не 10. "сегодня он слугает джаз..." ага

M>>>Account интересен. Почему у вас конструктор по умолчанию создает счет с невалидным id?
A>>а с каким валидным id он может его создавать? это издержки json сериализации, нужен дефолтный конструктор, и вопросвалидности отдельный и серьезный
M>Вот! Именно таких вопросов (можно для начала и без ответов) я и жду от вас! Можно описать вопросы валидности в kotlindoc. Можно — в readme проекта. Можно взять сериализатор, не страдающий издержками (это тестовое задание, я хочу видеть, как вы видите идеальный код!). Пусть даже не распространенный, не важно. Я очень хочу иметь в команде разработчиков, видящих много факторов и находящих компромисс между ними. Пусть даже выбор будет не совпадать с моим, это не будет минусом.

ждете от меня? где? в readme? нет уж

M>>>А зачем model и core разделили? Тем более, что core зависит от model а не наоборот. Кстати, а зачем в "реальном проекте" разделение делать иначе? Какие фундаментальные причины этого требуют?
A>>чтобы model отдать клиенту, core ему не нужен (либо перенести ifaces из core в model, кто тоже стоит отдельного обсуждения)
M>Еще один хороший комментарий! Можно было бы про него в readme упоминуть. В том числе и потому, что решение по-умолчанию — странное. Для публичных API у вас клиенты будут не только на java. Им ваша модель вообще никак не поможет. И даже на Java — вы ведь не считаете всех остальных разработчиков полными идиотами? (Или все-же считаете?) Я думаю, они смогут сами написать модель, которая им нужна (с нужной им декомпозицией, используемыми полями и т.п.). Может, они даже возьмут десериализатор без издержек и им будут непонятны ваши компромиссы.

во-первых, я по-умолчанию буду думать, что клиенты на джава если явно не сформулировано иное — yagni
во-вторых, писать в readme то, что лучше обсудить — бред и трата времени
в-третьих — зачем писать что-то второй раз, если это уже написано? чтобы добавить багов? или чтобы притащить только ограниченный набор зависимостей? так вот эти все вопросы и нюансы использования обговариваются на собеседовании, но не пишется сочинение в readme

M>Да, стоит позаботиться о программистах с ограниченными возможностями навыками. Для них можно сделать отдельную библиотеку с моделями и даже API клиентом. Это будет внешняя по отношению к серверу библиотека. Или несколько библиотек на разных языках. Немного больше повторяющегося кода, но нет лишней связности меджу реализацией API и клиентом. Простое, понятное и скучное решение. А вот попытка сделать общую модель между сервером и клиентом — это как раз overarchitected.

боже, хватит всех считать за идиотов.

M>>>Вот весь тот список — это "элементы стиля". Вещи, которые делаются вообще автоматически. Показывает, насколько разработчик механически следует шаблонам и насколько все же задумывается о причинах определенных технических решений.
A>>большинсто про вкус, остальное minor по мне. нейминг — не технические решения, как и работа с Assert
M>Ну... Вкус, да. Вы ведь понимаете, что код больше читается, чем пишется? Поэтому мне очень интересен код, который легко читать. В котором не нужно задумываться, что же хотел нам сказать автор. В котором можно зайти в документацию и прояснить непонятные детали. Иначе через три месяца другой разработчик поймет ваш код немного не так, как он задумывался, и в системе возникнет плавающий баг. Стиль — это эвристики, учитывающие особенности работы человеческого мозга. Например, разворачивание глубокой вложенности в последовательный код — это workaround на ограниченность кратковременной памяти. Большинство обычных людей забудет к третьему вложенному if, что там было на верхнем уровне. А потом сделают ошибку или потратят дополнительное время на вспоминание.

а, ну знакомые слова — "все идиоты, пиши проще". прости чувак, но есть код который реально сложно и читать и писать. и поверь, мои 3 вложенных when не из их числа.
не в состоянии следить за простым контекстом? ну что могу сказать, се ля ви.

M>Я несколько лет назад осознал, что "технические решения" — это только половина программирования. А вторая половина — гуманитарные науки, литература в первую очередь. Те самые нелюбимые технарями сочинения — это суть написания кода. Точное описание своих мыслей не только для машины, но и для программистов, читающих и сопровождающих за вами ваш код. Понимание того, что ваши мысли, ваше изложение и то, что понял читатель — это три разные вещи. Умение встать на сторону читателя и писать так, чтобы он увидел то, что вы хотели сказать.

ты смотришь в верную сторону, только не литература — философия.
программирование — это про раскрытие сути вещей. про понятия и их связи, рациональность, полноту, именование и тп.
и тут как раз твои претензии по именованию имели бы большое значение, будь это код из prod.
имена важны, но есть еще контекст.
в моем контексте на передний план выходит вопрос достаточности и соразмерности. так вот *Impl по-моему соразмерен заданию и органичен тут, но не факт что
был бы нормален в настоящем большом проекте. если здесь я пишу *Impl, это не значит что я везде пишу Impl. Как об этом догадаться — спросить на интервью

M>Вот все эти Assert — это как раз сложности выражать свои мысли в прямом и явном виде. Не технические, ну и что? Мне не нужны ребусы в коде. Мне нужен программист, который не поленился прочитать API и выбрать наиболее выразительный метод (для тестирования они еще и сообщения об ошибках лучше создают). Это один из многих факторов, на которые я обращаю внимание. И всегда очень интересно, когда на ревью кода кто-то другой показывает мне более выразительный (простой и понятный) вариант, чем я использовал.

ты делаешь ложные выводы из ложных предположений. это не сложности, это сознательный выбор в контексте задачи.

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

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

A>>>>Insufficient testing coverage
A>>>>nothing to say. It's 6hrs test. Not 40hrs
B>>>Ты в курсе, что твои комменты очень грубые? Люди платят премиальные деньги не только за скилл, но и за приятную работу. Ты конечно не послушаешь, но я бы посоветовал тебе поработать над софт скиллами.
A>>кто платит премиальные деньги? откуда такая информация?
B>Очевидно, что соглашаясь на тестовое задание в 6 часов, ты рассчитываешь на какие-то премиальные деньги. Ты же не станешь делать тестовое задание в контору, где платят в 2 раза меньше чем ты имеешь сейчас.

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

A>>и откуда ты знаешь насколько со мной приятно работать?
B>Из фрагмента твоей деловой переписки. После такого матраса я бы на месте интервьюера порекомендовал бы no-go. Собственно, советую не очень удивляться, получая отлупы на казалось бы ровном месте. Одно дело желание агрессивно заэнфорсить свое мнение в срачике на РСДН, и совсем другое — работая в западной конторе. Впрочем, я думаю в Нетфликсе тебе бы очень понравилось.

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

A>>>>If we transfer negative amount money, author don’t throw exceptions, it takes abs value of this amount and transfer positive amount of money.
A>>>>transferring negative amount is something which is odd. So it's a
A>>>>convention. It either has to be documented or exception should be
A>>>>thrown. So I partially agree.
B>>>ИМО это эпичный фэйл, а не partially agree.
A>>эпичный фейл это отсутствие abs. а с abs это просто другая культура
B>Мде.

ну да. где-то -1 — это "все хорощо", а где-то 0. но я в целом согласен, что тут лучше с exception. я не согласен с тем, что это major

A>>>>Author don't know how to catch exceptions in junit
A>>>>minor. Nothing to add.
B>>>Эм. Ты и правда не знаешь как ловить эксепшены или это что-то другое?
A>>эмм, ты и правда доволен своими софт-скилами?
B>Нет, не очень, честно признаться.

если по теме, то я не совсем понял суть предложения "Author don't know how to catch exceptions in junit". как ловить эксепшены вне Junit я, кажется, знаю)

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

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

CAF>Честно говоря, по американским меркам, ты им посто нахамил. Думаю, что можно списать на разницу культур, учитывая общий уровень англ. — но вообще это просто жесть.

а при чем здесь америка? может они из австралии? а по факту русские пацаны из питера

CAF>Ксати в дискусси на форуме нет смысла особенно препираться, это тебе с работой не поможет. Твоя задача, не нас уюедить, а понять что у тебя не так. Лучше подумай почему люди тебя не понимают.

откуда ты знаешь какая у меня задача? может мне тут пободаться в кайф и работа мне вообще не нужна?

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.

CAF>Не поленился — посмотрел, но синхронизации я не нашел. Поясни, как она делается, и это самое атомисити достигается.
CAF>Транзакии/аккаунт — классические пример для синхронизации. И да, для сервиса — это и так понятное требование.

ConcurrentHashMap.merge — атомарен. Строго говоря для совершения транзакции должно соблюдаться три условия:
1 атомарное дебетирование источника
2 атомарное кредитование получателя
3 предшествование первого второму

атомарность всей транзакции — необязательна. я могу сначала списать 2 суммы с одного и того же счета а уже потом перевести их на другие. тут гранулярность не на уровне
перевода со счета на счет, а на уровне изменения баланса аккаунта
единственный вопрос тут может быть к #3 из-за возможного reordering'a инструкций и отсутствия явных memory barriers. но я думаю и тут все чисто

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

A>>Insufficient testing coverage
A>>nothing to say. It's 6hrs test. Not 40hrs
CAF>в принципе тут просто более внятно надо ответить было, и все
CAF>хотя я бы тесты вместе с интерфесами нахерачил, а потом имплементацию лепил

A>>If we transfer negative amount money, author don’t throw exceptions, it takes abs value of this amount and transfer positive amount of money.
A>>transferring negative amount is something which is odd. So it's a
A>>convention. It either has to be documented or exception should be
A>>thrown. So I partially agree.
CAF>ну это вообще саботаж какой-то, кмк

я в ветке уже несколько раз отвечал.

A>>Author don't know how to catch exceptions in junit
A>>minor. Nothing to add.
CAF>мдааа

я вообще не очень понимаю суть претензий от них. ты вот мне можешь вместо "мдааа" написать в чем косяк?

A>>Procedure of transferring money is not clear and difficult to support
A>>no comment.
CAF>Сложность — понятие нескольно субъективное, но да. Пишешь не очень понятно местами. Кучка разбрсанных мелких классов,

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

A>>Poor documentation — there is no specifications of endpoints, how to build a project
A>>KL — there is a README. And there is a build.gradle. It's kind of
A>>misunderstanding what we expect from 6hrs test.

CAF>Вот кстати, уже более внятное объяснение. К концы начало получаться немного.

ну мне не 15 лет чтобы хотеть всем нравиться

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

A>Здравствуйте, 0xCAFEDEAD, Вы писали:

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

CAF>>Честно говоря, по американским меркам, ты им посто нахамил. Думаю, что можно списать на разницу культур, учитывая общий уровень англ. — но вообще это просто жесть.

A>а при чем здесь америка? может они из австралии? а по факту русские пацаны из питера
Я написал для примера.
Раз уж у тебя собеседование на англ., то и культуру в конторе перенимают оттуда скорее всего.


CAF>>Ксати в дискусси на форуме нет смысла особенно препираться, это тебе с работой не поможет. Твоя задача, не нас уюедить, а понять что у тебя не так. Лучше подумай почему люди тебя не понимают.

A>откуда ты знаешь какая у меня задача? может мне тут пободаться в кайф и работа мне вообще не нужна?

Да видимо так и есть.

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.

CAF>>Не поленился — посмотрел, но синхронизации я не нашел. Поясни, как она делается, и это самое атомисити достигается.
CAF>>Транзакии/аккаунт — классические пример для синхронизации. И да, для сервиса — это и так понятное требование.

A>ConcurrentHashMap.merge — атомарен. Строго говоря для совершения транзакции должно соблюдаться три условия:
A>1 атомарное дебетирование источника
A>2 атомарное кредитование получателя
A>3 предшествование первого второму

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

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

Проверил хватает ли денег в первой транзакциии, затем вьорая все списала, и вот ты в минусе
Нужен лок на всю операцию по аккаунту.
A>единственный вопрос тут может быть к #3 из-за возможного reordering'a инструкций и отсутствия явных memory barriers. но я думаю и тут все чисто
Не barriers, a fences. И причем тут они?
A>и тут уже не один раз мешали все в кучу — атомарность, потокобезопасность, concurrency, синхронизация.
A>это все разные вещи.
А причем тут я?

A>>>Insufficient testing coverage
A>>>nothing to say. It's 6hrs test. Not 40hrs
CAF>>в принципе тут просто более внятно надо ответить было, и все
CAF>>хотя я бы тесты вместе с интерфесами нахерачил, а потом имплементацию лепил

A>>>If we transfer negative amount money, author don’t throw exceptions, it takes abs value of this amount and transfer positive amount of money.
A>>>transferring negative amount is something which is odd. So it's a
A>>>convention. It either has to be documented or exception should be
A>>>thrown. So I partially agree.
CAF>>ну это вообще саботаж какой-то, кмк

A>я в ветке уже несколько раз отвечал.
Я видел, но мнение высказал. Это ошибка, и очень груюая.
A>>>Author don't know how to catch exceptions in junit
A>>>minor. Nothing to add.
CAF>>мдааа

A>я вообще не очень понимаю суть претензий от них. ты вот мне можешь вместо "мдааа" написать в чем косяк?
Мдаа по поводу ответа. Вот спросил бы у них, что им не нравится.

A>>>Procedure of transferring money is not clear and difficult to support
A>>>no comment.
CAF>>Сложность — понятие нескольно субъективное, но да. Пишешь не очень понятно местами. Кучка разбрсанных мелких классов,

A>о ужас, разбросанные по именованным модулям мелкие классы. очень обще, давай конкретику

На кой она тебе? Я же говорю, не особо понятно пишеш. В маленком проекте все ок, а в большом не знаю что будет

A>>>Poor documentation — there is no specifications of endpoints, how to build a project
A>>>KL — there is a README. And there is a build.gradle. It's kind of
A>>>misunderstanding what we expect from 6hrs test.

CAF>>Вот кстати, уже более внятное объяснение. К концы начало получаться немного.

A>ну мне не 15 лет чтобы хотеть всем нравиться

Причем тут это?

Сам себя поправлю
Здравствуйте, 0xCAFEDEAD, Вы писали:

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

A>>Здравствуйте, 0xCAFEDEAD, Вы писали:

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

CAF>>>Честно говоря, по американским меркам, ты им посто нахамил. Думаю, что можно списать на разницу культур, учитывая общий уровень англ. — но вообще это просто жесть.

A>>а при чем здесь америка? может они из австралии? а по факту русские пацаны из питера
CAF>Я написал для примера.
CAF>Раз уж у тебя собеседование на англ., то и культуру в конторе перенимают оттуда скорее всего.


CAF>>>Ксати в дискусси на форуме нет смысла особенно препираться, это тебе с работой не поможет. Твоя задача, не нас уюедить, а понять что у тебя не так. Лучше подумай почему люди тебя не понимают.

A>>откуда ты знаешь какая у меня задача? может мне тут пободаться в кайф и работа мне вообще не нужна?

CAF>Да видимо так и есть.

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.

CAF>Проверил хватает ли денег в первой транзакциии, затем вьорая все списала, и вот ты в минусе
CAF>Нужен лок на всю операцию по аккаунту.
Неправду я тут написал, есть там и есть лок (мерж) на всю операцию. Просмотрел.

Трансфер не атомарен, но вроде действительно работает правильно. В реальной жизни, проблема только, с тем что сумма денег не можеть не соответствовать реальной.

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

A>>>кто платит премиальные деньги? откуда такая информация?
B>>Очевидно, что соглашаясь на тестовое задание в 6 часов, ты рассчитываешь на какие-то премиальные деньги. Ты же не станешь делать тестовое задание в контору, где платят в 2 раза меньше чем ты имеешь сейчас.
A>почему какая-то бинарность — либо в 2 раза меньше, либо премиальные? просто нормальные деньги. меньше, чем на моей предыдущей работе
По мне это странно, ну ок.

A>>>и откуда ты знаешь насколько со мной приятно работать?
B>>Из фрагмента твоей деловой переписки. После такого матраса я бы на месте интервьюера порекомендовал бы no-go. Собственно, советую не очень удивляться, получая отлупы на казалось бы ровном месте. Одно дело желание агрессивно заэнфорсить свое мнение в срачике на РСДН, и совсем другое — работая в западной конторе. Впрочем, я думаю в Нетфликсе тебе бы очень понравилось.
A>ну это еще зависит от того как читать, верно? ну и деловая переписка бывает разной )
Читать по-английски, полагаю? Я читаю, и то что я читаю мне совсем не нравится, будь ты 100 раз прав. Контор с культурой Нетфликса тут совсем немного.

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

A>>>>>If we transfer negative amount money, author don’t throw exceptions, it takes abs value of this amount and transfer positive amount of money.
A>>>>>transferring negative amount is something which is odd. So it's a
A>>>>>convention. It either has to be documented or exception should be
A>>>>>thrown. So I partially agree.
B>>>>ИМО это эпичный фэйл, а не partially agree.
A>>>эпичный фейл это отсутствие abs. а с abs это просто другая культура
B>>Мде.
A>ну да. где-то -1 — это "все хорощо", а где-то 0. но я в целом согласен, что тут лучше с exception. я не согласен с тем, что это major
Понимаешь в чем проблема, тебе было очевидно, что надо сделать Abs, а мне — нет. Я, как пользователь API, не должен додумывать за его создателя, я должен получить ясный ответ, в чем моя проблема. Не надо делать странные манипуляции с инпутом, надо просто кидать кастомный эксепшен с объяснением проблемы.

A>>>>>Author don't know how to catch exceptions in junit
A>если по теме, то я не совсем понял суть предложения "Author don't know how to catch exceptions in junit". как ловить эксепшены вне Junit я, кажется, знаю)
Я не джавист, но полагаю что речь вот об этом:

    @Test
    fun testFailedAdd() {

        val s = WalletImpl( StorageImpl())
        try {
            s.add("1", (-1).toBigDecimal())
        }
        catch (e: Exception) {
            Assert.assertTrue(s.list().count() == 0)
            return
        }

        Assert.assertTrue(false)
}

Это собственно, очень печально, поскольку такой функционал появился, судя по release notes, появился в 2006 году. Ты должен был объявить кастомный эксепшен для этой ситуации, и кидать его, а юнит-тест, полагаю, должен был быть таким:

    @Test(expected = WhateverCustomException.class)
    fun Add_should_fail_when_negative_input_value_provided() {
        val s = WalletImpl( StorageImpl())

        s.add("1", (-1).toBigDecimal())
    }

Улучшенная версия, разумеется, не должна содержать конкретной имплементации депенденсис, потому что ты тестируешь поведение твоего кода в контролируемом окружении (повторяю — я не джавист):

    @BeforeClass
    public void setUpClass() throws Exception {
    // тут инициализация абстракций
    _storage = Substitute.For<Storage>() // хз как это делать в джаве
    }

    @Test(expected = WhateverCustomException.class)
    fun testFailedAdd() {
        val s = WalletImpl(_storage);

        s.add("1", (-1).toBigDecimal())
    }

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

...

A>>я, строго говоря, им ничего не должен, как и они мне. вот если бы я на них работал, было бы другое дело.
B>Ты к ним и не попадешь, если будешь и впредь продолжать жить в парадигме совковой настырности. Это не оскорбление, а констатация факта, я сам был таким же, и это стоило мне довольно дорого.

так я и не собираюсь к ним попадать.

A>>>>>>If we transfer negative amount money, author don’t throw exceptions, it takes abs value of this amount and transfer positive amount of money.
A>>>>>>transferring negative amount is something which is odd. So it's a
A>>>>>>convention. It either has to be documented or exception should be
A>>>>>>thrown. So I partially agree.
B>>>>>ИМО это эпичный фэйл, а не partially agree.
A>>>>эпичный фейл это отсутствие abs. а с abs это просто другая культура
B>>>Мде.
A>>ну да. где-то -1 — это "все хорощо", а где-то 0. но я в целом согласен, что тут лучше с exception. я не согласен с тем, что это major
B>Понимаешь в чем проблема, тебе было очевидно, что надо сделать Abs, а мне — нет. Я, как пользователь API, не должен додумывать за его создателя, я должен получить ясный ответ, в чем моя проблема. Не надо делать странные манипуляции с инпутом, надо просто кидать кастомный эксепшен с объяснением проблемы.

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

A>>>>>>Author don't know how to catch exceptions in junit
A>>если по теме, то я не совсем понял суть предложения "Author don't know how to catch exceptions in junit". как ловить эксепшены вне Junit я, кажется, знаю)
B>Я не джавист, но полагаю что речь вот об этом:

B>

B>    @Test
B>    fun testFailedAdd() {

B>        val s = WalletImpl( StorageImpl())
B>        try {
B>            s.add("1", (-1).toBigDecimal())
B>        }
B>        catch (e: Exception) {
B>            Assert.assertTrue(s.list().count() == 0)
B>            return
B>        }

B>        Assert.assertTrue(false)
B>}
B>

B>Это собственно, очень печально, поскольку такой функционал появился, судя по release notes, появился в 2006 году. Ты должен был объявить кастомный эксепшен для этой ситуации, и кидать его, а юнит-тест, полагаю, должен был быть таким:

B>

B>    @Test(expected = WhateverCustomException.class)
B>    fun Add_should_fail_when_negative_input_value_provided() {
B>        val s = WalletImpl( StorageImpl())

B>        s.add("1", (-1).toBigDecimal())
B>    }
B>

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

B>Улучшенная версия, разумеется, не должна содержать конкретной имплементации депенденсис, потому что ты тестируешь поведение твоего кода в контролируемом окружении (повторяю — я не джавист):

B>

B>    @BeforeClass
B>    public void setUpClass() throws Exception {
B>    // тут инициализация абстракций
B>    _storage = Substitute.For<Storage>() // хз как это делать в джаве
B>    }

B>    @Test(expected = WhateverCustomException.class)
B>    fun testFailedAdd() {
B>        val s = WalletImpl(_storage);

B>        s.add("1", (-1).toBigDecimal())
B>    }
B>

у меня прям в коде есть коммент "mock Storage?". Я просто не стал этого делать

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

...

A>>я вообще не очень понимаю суть претензий от них. ты вот мне можешь вместо "мдааа" написать в чем косяк?
CAF>Мдаа по поводу ответа. Вот спросил бы у них, что им не нравится.

не было возможности

...

A>>>>Poor documentation — there is no specifications of endpoints, how to build a project
A>>>>KL — there is a README. And there is a build.gradle. It's kind of
A>>>>misunderstanding what we expect from 6hrs test.

CAF>>>Вот кстати, уже более внятное объяснение. К концы начало получаться немного.

A>>ну мне не 15 лет чтобы хотеть всем нравиться

CAF>Причем тут это?

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

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

...

CAF>>Проверил хватает ли денег в первой транзакциии, затем вьорая все списала, и вот ты в минусе
CAF>>Нужен лок на всю операцию по аккаунту.
CAF>Неправду я тут написал, есть там и есть лок (мерж) на всю операцию. Просмотрел.

супер

CAF>Трансфер не атомарен, но вроде действительно работает правильно.

ага

CAF>В реальной жизни, проблема только, с тем что сумма денег не можеть не соответствовать реальной.

не понял

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

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

A>>>>я, строго говоря, им ничего не должен, как и они мне. вот если бы я на них работал, было бы другое дело.
B>>>Ты к ним и не попадешь, если будешь и впредь продолжать жить в парадигме совковой настырности. Это не оскорбление, а констатация факта, я сам был таким же, и это стоило мне довольно дорого.
A>>так я и не собираюсь к ним попадать.
B>А какой тогда смысл? Не могу уловить.

я написал тест, они посмотрели и ответили что no go. я спросил почему. они прислали список претензий; я ответил

A>>>>>>>>Author don't know how to catch exceptions in junit
A>>>>если по теме, то я не совсем понял суть предложения "Author don't know how to catch exceptions in junit". как ловить эксепшены вне Junit я, кажется, знаю)
B>>>Я не джавист, но полагаю что речь вот об этом:

B>>>Это собственно, очень печально, поскольку такой функционал появился, судя по release notes, появился в 2006 году. Ты должен был объявить кастомный эксепшен для этой ситуации, и кидать его, а юнит-тест, полагаю, должен был быть таким:
A>>почему печально? я просто этого не знал. может быть потому, что на джаве в прод писал я меньше года. и это как-бы публичная инфа для работодателя.
B>Печально потому, что ты утверждаешь, что у тебя 13 лет экспы. За 13 лет можно наверное было поднавтыкаться читать доки на минимальном уровне, да и раньше наверняка занимался чем-то схожим, там должны были быть похожие конструкции.

что за ерунду ты пишешь? первый тут твой комментарий в ветке — "Они, конечно же, правы. Комон сенс здесь как бы орет, что метод должен быть трэдсейф."
то есть ты даже не потрудился разобраться в том, что ты комментируешь. я спокойно тебе ответил на него, не стал делать каких-то выводов о твоей способности
читать, писать и думать. какой смысл делать какие-то далеко идущие выводы на тему умею я читать доки на минимальном уровне или нет?
что за культура предсказателей?

B>Это на самом деле говорит о низкой мотивации, и низком уровне самообразования. Когда у программиста нет любопытства — это так себе программистЪ, просто человек работающий за деньги Кого-то это устроит, кого-то нет. Я бы не рекомендовал брать, выше по трэду говорят что норм.

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

A>>у меня прям в коде есть коммент "mock Storage?". Я просто не стал этого делать
B>А почему не стал? Это же десяток строк полуавтоматического кода.

времени жалко

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

A>...
A>меня просто раздражают тупые люди. последовательно тупые.
Поздравляю. Ты на пути к просветлению.

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

A>когда ты приносишь кеш в банк тоже есть парный счет? здравый смысл подсказывает, что в контексте этого тестового задания они обязаны появляться из воздуха
Представь себе есть и называется он "счет кассы". Деньги вносятся на счет кассы и переходят в активы банка, а взамен этого банк становится тебе должен равную сумму, которая отражается на твоем личном счете и относится к пассивам банка.
И когда ты попросишь свои деньги кешем обратно, банк сделает обратную операцию с твоего счета на счет кассы.

A>вообще без комментариев, учитывая твои предположения об источниках денег
ЧТо-то мне подсказывает, что про источники денег я знаю много больше твоего

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

A>Здравствуйте, 0xCAFEDEAD, Вы писали:

A>...

CAF>>>Проверил хватает ли денег в первой транзакциии, затем вьорая все списала, и вот ты в минусе
CAF>>>Нужен лок на всю операцию по аккаунту.
CAF>>Неправду я тут написал, есть там и есть лок (мерж) на всю операцию. Просмотрел.

A>супер

CAF>>Трансфер не атомарен, но вроде действительно работает правильно.

A>ага

CAF>>В реальной жизни, проблема только, с тем что сумма денег не можеть не соответствовать реальной.

A>не понял

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

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

A>Здравствуйте, 0xCAFEDEAD, Вы писали:

A>...

A>>>я вообще не очень понимаю суть претензий от них. ты вот мне можешь вместо "мдааа" написать в чем косяк?
CAF>>Мдаа по поводу ответа. Вот спросил бы у них, что им не нравится.

A>не было возможности
Ты же им ответ писал?
A>...

A>>>>>Poor documentation — there is no specifications of endpoints, how to build a project
A>>>>>KL — there is a README. And there is a build.gradle. It's kind of
A>>>>>misunderstanding what we expect from 6hrs test.

CAF>>>>Вот кстати, уже более внятное объяснение. К концы начало получаться немного.

A>>>ну мне не 15 лет чтобы хотеть всем нравиться

CAF>>Причем тут это?

A>при том, что у меня не 3 года опыта чтобы хотеть нравиться всем подряд, а 13+.
A>представь, что ты тратишь 10 часов на работу, которую, как многие в этой ветке, проверяют наотвали.
A>тут половина людей, включая тебя, не сразу увидели в чем прикол с потокобезопасностью. но у вас не стоит задачи
A>меня нанять, с вас взятки гладки. а вот у них стоит, и свою задачу они решают очень посредственно. ну я им об этом и говорю. а в какой форме говорить — ну сам выбираю в соответствии со своим впечатлением о них

Я имел ввиду твою манеру письма (ответы им). Это вообще автоматически должно делаться нормальными выражениями.

Конечно по-хорошему, любое более-менее нормально сделанное задание стоит получше обсудить, иначе смысл его давать?

А так забей просто. Если от тебя не ждут познаний в финансах (и не обсуждали явно) — нормально задание сделал. Может и в реальной жизни трансфер не атомарен, хз. Ну может они в голове у себя решение прибили, может уже другого выбрали, может еще много чего. Был бы иы им интересен — сами бы продолжили обсуждение.

Там в этой конторе хоть что-нибудь интересное было?

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

L>Представь себе есть и называется он "счет кассы". Деньги вносятся на счет кассы и переходят в активы банка, а взамен этого банк становится тебе должен равную сумму, которая отражается на твоем личном счете и относится к пассивам банка.
L>И когда ты попросишь свои деньги кешем обратно, банк сделает обратную операцию с твоего счета на счет кассы.
Просто мимо проходил и заинтересовало: а для "счета кассы" какой счет парный? Как туда деньги зачисляют?

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

SL>Просто мимо проходил и заинтересовало: а для "счета кассы" какой счет парный? Как туда деньги зачисляют?
Счет где учитывается сумма на счетах клиента(ов).
Но тут некоторое смешение бух.учета с банковской операционной деятельность. Хотя в реальных системах оно и на самом деле скорее всего ведется вместе.

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

P>Счет где учитывается сумма на счетах клиента(ов).
P>Но тут некоторое смешение бух.учета с банковской операционной деятельность. Хотя в реальных системах оно и на самом деле скорее всего ведется вместе.
Я понимаю, что раз на счет клиента деньги зачисляются со счета кассы, то в рамках перевода возникает пара "счет кассы" — "счет клиента".
Пришел человек с кэшем: как в рамках этой модели кэш попадает на "счет кассы"?

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

E>Так что если кого подобный код на тестовых заданиях не удовлетворит — это их проблемы, зажрались

Никто там не зажрался. Когда на задание, называющееся "Design and implement a RESTful API" выдают такой неумелый треш с кандидатом разговаривать больше не о чем, это полный ноль в означенной теме. И ведь всего то надо было ознакомиться с любым дизайн гайдом по REST API, чтива на полчасика. Но нет, мы сразу бросаемся лопатить 6 часов код не ознакомившись с основами.

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

A>>Author don't know how to catch exceptions in junit
mgu>-- MGIMO ended?
mgu>-- Ask!

Да там и в описании задачки просто суши весла.

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

SL> L>Представь себе есть и называется он "счет кассы". Деньги вносятся на счет кассы и переходят в активы банка, а взамен этого банк становится тебе должен равную сумму, которая отражается на твоем личном счете и относится к пассивам банка.
SL> L>И когда ты попросишь свои деньги кешем обратно, банк сделает обратную операцию с твоего счета на счет кассы.
SL> Просто мимо проходил и заинтересовало: а для "счета кассы" какой счет парный? Как туда деньги зачисляют?

Дт50 — Кт76 (или 79, может 73)

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

A>тут половина людей, включая тебя, не сразу увидели в чем прикол с потокобезопасностью

И это, на самом деле, уже фейл, на что тебе пальцем и указали. Не надо писать неочевидный код. А если уж написал, так хотя бы напиши поясняющий комментарий. Вроде 13 лет опыта заявляешь, а с какими то элементарнейшими вещами проблема.

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

M>Ну в первую очередь вам. Потому что вы хотели продолжения интервью или найма. Хотелось бы мне. Как минимум потому, что приятно поговорить с кандидатом с широким кругозором. За реализацию Rest Level 1 вы бы получили плюсик

Да тут даже не плюсик, просто само задание было прежде всего на RESTful API. Получается что с самой основой проблемы. Все остальное уже несущественно.
Там, кстати, и с возвратом бизнес-ошибок и HTTP status codes бедулька. Я сейчас не про тонкости типа RFC 7807, а про базовые вещи. Так что оно даже на level 0 не тянет.

M>Я несколько лет назад осознал, что "технические решения" — это только половина программирования. А вторая половина — гуманитарные науки, литература в первую очередь.

Ну не литература все таки. Литература все таки про эмоции, эмоции в коде не надо. А надо в прикладную психологию.

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

НС>Второй момент — ты конкретно так накосячил с REST API. Т.е. ты вообще не знаешь что такое REST, у тебя самая примитивная ошибка — глаголы в урлах. Чего не должно быть в принципе.
НС>Итого: не знаешь БД, не знаешь REST.
Ну, справедливости ради очень мало кто использует ортодоксальный подход с HTTP verbs для разделения сути операций, почти все юзают GET и POST.

Вот что не так:

A>Implicit requirements:
A>1. The code produced by you is expected to be of high quality.
A>2. There are no detailed requirements, use common sense.

Common sense для 6-часового эрзаца у всех будет разный. Что имеется в виду под high quality для подобного задания, тоже трудно предполагать. По сути, эти два пункта означают, что соискателю надо угадать, чего от него хотят. Ну нафиг.

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

S>Common sense для 6-часового эрзаца у всех будет разный. Что имеется в виду под high quality для подобного задания, тоже трудно предполагать. По сути, эти два пункта означают, что соискателю надо угадать, чего от него хотят. Ну нафиг.
Тоже верно. Однако никто же не жалуется решать задачки на всяких кодилити по 2 часа безо всякого фидбэка вообще

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

T>Как минимум самая важная операция по ТЗ — transfer, не является атомарной. Думаю, это сильно уменьшило баллов.

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

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

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

A>>зачем? чтобы просто показать, что я умею затащить в апп как депенденси и сделать таблицу из 2х полей?

НС>Чтобы показать что ты знаешь что такое БД, умеешь правильно делать ее схему, знаешь что такое транзакция и уроыень ее изоляции. Ты же показал, что очень далек от финансовых приложений.

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

НС>Второй момент — ты конкретно так накосячил с REST API. Т.е. ты вообще не знаешь что такое REST, у тебя самая примитивная ошибка — глаголы в урлах. Чего не должно быть в принципе.

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

НС>Итого: не знаешь БД, не знаешь REST.

бред

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

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

A>>тут половина людей, включая тебя, не сразу увидели в чем прикол с потокобезопасностью

НС>И это, на самом деле, уже фейл, на что тебе пальцем и указали. Не надо писать неочевидный код. А если уж написал, так хотя бы напиши поясняющий комментарий. Вроде 13 лет опыта заявляешь, а с какими то элементарнейшими вещами проблема.

если ты не в состоянии понять 2 строки кода, то хорошо что мы не вместе работаем.

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

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

M>>Ну в первую очередь вам. Потому что вы хотели продолжения интервью или найма. Хотелось бы мне. Как минимум потому, что приятно поговорить с кандидатом с широким кругозором. За реализацию Rest Level 1 вы бы получили плюсик

НС>Да тут даже не плюсик, просто само задание было прежде всего на RESTful API. Получается что с самой основой проблемы. Все остальное уже несущественно.
НС>Там, кстати, и с возвратом бизнес-ошибок и HTTP status codes бедулька. Я сейчас не про тонкости типа RFC 7807, а про базовые вещи. Так что оно даже на level 0 не тянет.

нет никакой бедульки. неудачно использовал HTTP 500 как код не-HTTP ошибки. но это и не прод.
и бро, если у тебя в этом упражнении основное это показать что ты знаешь про HTTP levels, то ты не врубился в то, про что задание.
ты не можешь распарсать простой concurrent код, зато носишься с REST levels, на который всем реально плевать.

...

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

...

CAF>Я имел ввиду твою манеру письма (ответы им). Это вообще автоматически должно делаться нормальными выражениями.

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

CAF>Конечно по-хорошему, любое более-менее нормально сделанное задание стоит получше обсудить, иначе смысл его давать?

ну этих ребят оказалось другое мнение на этот счет

CAF>А так забей просто. Если от тебя не ждут познаний в финансах (и не обсуждали явно) — нормально задание сделал. Может и в реальной жизни трансфер не атомарен, хз. Ну может они в голове у себя решение прибили, может уже другого выбрали, может еще много чего. Был бы иы им интересен — сами бы продолжили обсуждение.

CAF>Там в этой конторе хоть что-нибудь интересное было?

кроме котлина ничего особенного

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

...

CAF>у тебя на всех аккаунтах в сумме будет неправильное в середине трансфера, где-то списалось, но не начислсилось еще
CAF>на самом деле, все равно все сложнее, так что это только разговор начать

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

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

H>Я выдвину более сильное утверждение. Мне думается, что суть задания и была в том, чтобы реализовать транзакционный перевод денег, с чем ТС не справился.

Суть задания, все таки, судя по названию, была в проектировании RESTful API. С чем он, впрочем, тоже не справился.

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

A>нет никакой бедульки. неудачно использовал HTTP 500 как код не-HTTP ошибки

Тем самым показал, что с REST ты совсем не в теме.

A>. но это и не прод.

При чем тут прод? Это как раз те вещи, которые должно показать тестовое задание.

A>и бро, если у тебя в этом упражнении основное это показать что ты знаешь про HTTP levels, то ты не врубился в то, про что задание.
A>ты не можешь распарсать простой concurrent код, зато носишься с REST levels, на который всем реально плевать.

Бро, хватит меряться пиписками. Меня в любом случае на собеседованиях про совсем другое спрашивают, вообще не про код. И "парсить" мне каждый день на работе приходится куда более сложный и кривой код. Так что мимо.