Решил тут склепать платформу с задачками по программированию, но отличную от существующих.

http://frocate.com/

Обычно в онлайн платформах есть 2 варианта тестов по программированию: либо multiple choice вопросы, либо олимпиадные задачки. Вот я решил предложить альтернативу и делать более реалистичные задачки, типа как домашнее задание до/после собеседования бывает - некие более менее реалистичные требования и возможность использовать любые библиотеки.

Пока задачки предполагалось использовать для тренировки/обучения и как вариант тестового задания в рамках собеседования.

Собственно задачка пока готова только одна - написать приложение, которое принимает http запросы и дергает third-party сервис. Тема - денежные переводы. Подразумевается, что у нас есть legacy сервис, который позволяет изменять баланс счета, а нам нужно сделать сервис, который обернет такой АПИ в некоторое подобие транзакций и сможет делать retry/rollback.

В минимальном варианте можно сделать часа за 2, оптимальный вариант может занять часов 15. Плюс, если конкретно такого типа задачки никогда не делали, то смело умножайте время на 5 :)

Платформа пока еле работает, поэтому ошибки могут быть..

Любой фидбек приветствуется - от общих мыслей насчет осмысленности такого подхода, до найденных косяков и даже (!!!) собственно попыток решить задачку :)

Let's roll!

rema174че то я сомневаюсь в целесообразности этой затеи, ведь те кто уже может-умеет делать такое, то врядли будут себя на это растрачивать, а те кто не умеет, врядли будут браться. разумеется, это только имхо :)

Любое имхо пригодится :)

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

Я предполагал 2 юз кейса:

1. Начинающие (кто еще не работал программистом или работает недавно) порой спрашивают "как бы понять - я разрабатывать то умею/возьмут меня на работу или надо что-то срочно подтягивать?". Вот задачки, которые в итоге вам автоматически выдают результат в каком-то виде в этом случае помогают, решил задачку - можешь писать код, нет вопросов, не решил или как-то неожиданно много времени заняло - можно разобраться почему.

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

uid uniquerrrrrrrr,

Вопрос по обработке ошибок - имеет ли смысл выносить на траспортный уровень (http) сообщения типа NOT_ENOUGH_MONEY?

В случае возврата ошибки уровня бизнес логики в 200 response code в виде объекта расширение функционала будет проще и без разницы какой транспорт. Хоть на MQ Series переноси - вопрос 5 минут.

Хороший поинт, спасибо, поправлю на днях, правда немного в другом виде, наверное.

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

Status performDebitOperation()

Которая будет возвращать enum с NOT_ENOUGH_MONEY и другими ошибками. То есть, например, класс-транспорт будет мапить http code + header value на Status.

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

Насчет json все хитро. Я думал делать задачку близкую к реальности, грубо говоря завтра будешь писать настоящий код, который twitter вызывает и он вернет json, значит в задачке тоже неплохо бы json. Однако в задачке мы билдим jar-with-dependencies, а значит json библиотеку нужно паковать, что увеличивает размер бинарника. Хотелось бы чтобы он не стал огромным, тогда его можно сохранять на память, вместе с результатами билда :)

Конкретно json-парсер наверное не занимает много места и его можно добавить, но возможно достаточно просто возвращать значение enum в теле запроса? Всем проще.

Для информации - результаты тестов выглядят вот так:

http://frocate.com/task.jsp?taskId=task-account-transfer#buildId=task-account-transfer__05-09-2016__12h-20m-00s-b1
http://frocate.com/task.jsp?taskId=task-account-transfer#buildId=task-account-transfer__04-09-2016__17h-08m-32s-b1

BlazkowiczNixicА можно подробнее? Что использовали для создания?
Мне нравится оформление и навигация просто :)
Bootstrap же

Да, это конечно же bootstrap (использованный в стиле my first webapp). В остальном все тоже стандартно: jetty, docker, jsp.

Герой дняrrrrrrrr,

красиво и понятно

Спасибо, стараемся :)

Пока начальный фидбек такой, что все хотят симпатичную картинку и низкий порог вхождения. Поэтому в ближайшее время разнообразим описание задачки картинками, спрячем большие объемы текста в требованиях под кат, чтобы не отпугивать пользователей и немного доработаем формат результата - там будут более подробные описания кейсов и референсные значения для BAD/GOOD/EXCELLENT результатов, чтобы легче было понять чего от вас хотят.

uid uniqueОтладка кода (и создание тестов) упрощается - за транспорт отвечает внешняя библиотека или отдельный отлаженный модуль, проверка нужна только для бизнес логики.


Да мне кажется нет разницы. Вот берете вы http библиотеку, какой-нибудь Unirest например, вы можете ее дергать прям из кода - Unirest.get() и прям тут же парсить респонс с кодами, хедерами и json-контентом, а можете обернуть в отдельный класс и дергать BalanceServiceHttpImpl.performDebit(), который скроет все эти штуки. Замокали его для юнит тестов и нет разницы какой транспорт.

uid uniqueПри выполнении задачи у меня мысли о том не как написать а как расширять и поддерживать в будущем (работать с support division, объяснить как добыть нужную информацию, как понять в чем проблема так как у меня может не быть доступа к системе заказчика) и расширять текищий функционал с минимумом переделок и хорошим покрытием тестами, желательйо чтоб новый код не ломал сильно старые тесты (рефакторинг с умеренными усилиями и расходом времени).


Я думаю это слишком out of scope, хотя имхо, в этой конкретной задачке подобные моменты должны несильно влиять на код: базовая модульность всегда пригодится, а продвинутые вещи типа сложной системы мониторинга, ведения истории операции, автодетекта перформанс проблем тут не требуются (мне кажется их вообще нельзя проверить на проекте длинной меньше месяца).

Между тем - новая задачка и немного обновленный UI по части результатов. Кто еще не успел попробовать - вперед :)