Coding assignment

[ovedernio]

Коллеги!

У меня на следующей неделе final interview. Сказали сделать Coding assignment и выслать перед интервью.
Я ожидал что то не тривиальное, а получил вот это.....

Тупо REST API. Десять раз перечитал. В чем тут подвох? Какие подводные камни могут быть?

Спасибо.

Purpose
The purpose of this exercise is for you to demonstrate the ability to architect and code a solution in Java or NodeJS.

Scope
We would like you to architect and implement a contact management application that will allow the following functionality:
· Add contact
· Edit contact
· Remove contact
A contact should contain a least the following fields:
· First name
· Last name
· Email address

Architecture and Frameworks
You are free to choose how you architect the solution. It could be a command line app, a REST API, a web page or another interface of your choice.
You can also select the framework(s), libraries and dependency management of your choice (if any). The only requirement is the use of Java or NodeJS.

Guidelines
· The solution can persist the contacts in memory and only during the runtime – it does not have to use a more permanent storage
· For the sake of time, you can leave comments in the code indicating TODOs that would need to be implemented in order for the complete solution to work

[3DD]

Ну обычный скриниг. Любят еще попросить написать todo list: add/remove/edit todo item.

[valchkou]

Тупо REST API. Десять раз перечитал. В чем тут подвох? Какие подводные камни могут быть?

подвоха нет, от вас требуют рабочий микросервис с юнитестом и интеграйшн тестом.
чтобы он билдился, запускался и был селф контейнед.
судя по всему не требуется outh rbac openid https но видимо комментарии к этому будут уместны

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

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

немного аутдейтед но как пример сойдет
https://github.com/valchkou-app/fibonacci-microservice

[caltrain]

В чем тут подвох? Какие подводные камни могут быть?

The purpose of this exercise is for you to demonstrate the ability to architect and code a solution in Java or NodeJS.

We would like you to architect and implement a contact management application that will allow the following functionality:

Architecture and Frameworks

Ну, подвох как со всеми задачами на дизайн. То есть должны быть красивые картинки, оценки и решение как это scale.
А поскольку это scale, то ведь не для одного пользователя целый сервис. А раз много пользователей то соотвествующие поля-таблица, вопросы authenticate/authorize хотя бы в виде полузаглушек и квадратиком на схеме.
Кроме того это REST API, поэтому MVC рендеринга уже не должно быть. А должен быть клиент. И клиент этот - web.
Наверное, можно упростить, не обязательно React/Reduх, JQuery-JQueryUI или AngularJS (старый простой)
Но всё равно, клиент авторизуется, после этого уже показывать CRUD операции.
Где-то вылезет вопрос pagination.

То есть по идее уже два модуля должно быть: webapp - JS  и REST - Java
По хорошему, REST должен быть отдельно, entities в отдельный модуль (скажем maven), возможно отдельный слой для доспупа к данным (пусть даже in-memory)
По чуть-чуть но до фига работы.
По хорошему Docker Compose file, который внутри докера билдится и запускается
То есть демо выглядит так, скачали исходники из git, запустили докер. Он сам на базе maven, JDK скачал dependencies, собрался перекинул собранный артифакты в чистую фазу и запустился. А может даже несколько контейнеров запустилось, и они друг друга видят. Один порт для webapp наружу.
Зашли, авторизовались с одним и пары захардкоженных пользователей, поработали, сменили пользователя

Но это хорошее демо.

Можно проще и на своём компе -  скачали чистый репозиторий, сами собрали, сами запустили (команды заранее заготовьте)
И показали на "этом" и "том" пользователе. Один из пользователей может быть с предзагруженными данными
Когда показывать дизайн картинку, наверное, до кодовой части. После всего уже можно обзор кода делать, или во время билда.

Шоу тоже отрепетируйте.

[valchkou]

Кроме того это REST API, поэтому MVC рендеринга уже не должно быть. А должен быть клиент. И клиент этот - web.
Наверное, можно упростить, не обязательно React/Reduх, JQuery-JQueryUI или AngularJS (старый простой)

писать свой UI это уже перебор. По мне достаточно воткнуть готовый openapi/swagger-ui

[caltrain]

Кроме того это REST API, поэтому MVC рендеринга уже не должно быть. А должен быть клиент. И клиент этот - web.
Наверное, можно упростить, не обязательно React/Reduх, JQuery-JQueryUI или AngularJS (старый простой)

писать свой UI это уже перебор. По мне достаточно воткнуть готовый openapi/swagger-ui

Должен быть API для какого-то flow, или web, или device, хоть в пару шагов, типа cначала получил token, потом CRUD-операции. Для вэба нужен CORS.
А можно упростить, типа REST возвращает данные только, но то тогда auth/auth делегирован туда-и-туда-то, что описано в дизайне. Подвох всё-таки в том, сначала - слайды с дизайном, а кодинг по этому дизайну.

Что потом можно захотеть к такому API? Rate limiter, cache, логи, роли, pagination, sorting, filtering, выбор json/xml/etc, SSO

[mister-X]

Кодирование REST API для интервью не грех. Но на реальном проекте ручками кодить get/post/put/delete ? Это даже не велосипед изобрести, как не старайся все равно поделка будет. Все уже давно придумали
- берёшь jhipster и за 10 минут весь проект с REST Swageer, Angular,Vue,React plus OAuth и много ещё чего генериш...хочешь в Docker или так...потом напильником чуть чуть пофихить и только бизнес логику добовляй.

[vdfs]

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

Как вы себе представляете этот "реальный проект"? Наняли вас, такого сениорного помидора, в пустое поле, где ничего нет, писать систему с нуля? А до этого дня че они делали?

[mister-X]

Можно старье и на ещё и сокетах найти. Только зачем что-то серьёзное там делать? Пофихить и забыть. По моему опыту в среднем корпоративный софт живёт лет 5-10.бывают конечно исключения. Так что не все так легаси. Даже в старый проект можно сгенеренные файлы подложить, в spring это не проблема. А вот напишите ручками http get поиск на таблицу с 30+ полями в базе и поиском по всем полям через url query parameters <>=in,sorting, paging...неделю минимум и все равно ошибок будет на месяц фихить. А генирилка это за минуту делает.

[vdfs]

PagingAndSortingRepository / Querydsl всё это делает из коробки, paging, sorting, поиск по полям. CRUD эндпоинты автоматически предоставляет.
@Document повесили на domain object, и оно само создаст коллекцию в БД. Всякие штуки типа индексов, типов данных, валидации параметров пишутся аннотациями на этом же классе.

У нас на проекте все это прекрасно работает. Пишется это всё в несколько строк.
Да, поля надо 1 раз написать в самой сущности, но их же все равно надо где-то писать минимум 1 раз?

Сколько раз пробовал эти генерилки - больше времени тратишь чтобы они заработали. Потом еще чистить ненужное за ними. Всё что вы описали выше, идет из коробки в Spring Boot. Может вам стоит про него посмотреть / почитать.

[mister-X]

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

[caltrain]

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

Я очередной раз попробовал посмотреть, что нынче генерит Swagger для Spring. https://editor.swagger.io/
Они перестали давать доморощенный пример со зверушками, но многие проблемы так и остались.
Код генерится только для обмена на стыке REST-browser. То есть конвертацию web POJO -> JPA надо додумывать самому.
90% это 1:1 но все-равно, это должен быть контролируемый процесс, чтобы с веба не подсунули каку, и наоборот, чтобы наружу не утекло лишнее. MapStruct, вроде, хорошо делал это раньше.
CRUD всё равно надо доделывать.
Где есть хорошие шаблоны для Swagger+Spring и не обязательно шваггера, но всего остального?

[valchkou]

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

[vdfs]

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

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

Это было больше в сторону "...поиск ... <>=in,sorting, paging...неделю минимум и все равно ошибок будет на месяц фихить". Какое там неделю и месяц, когда это всё стандартная функциональность фреймворка, и пишется чуть ли не 1-й строкой типа

Code: Select all

public interface TableRepository extends PagingAndSortingRepository<Table, Integer>, QuerydslPredicateExecutor<Table>

Чего тут генерить-то можно, в принципе? И тем более фиксить.

[kostik78]

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

А потом возникают удивление что код над нагрузкой еле шевелятся. Spring AOP все делает через proxy (reflection) при этом когда микровсервис обрастает фичами стек имеет несколько сотен вложений одного прокси зовущего другой прокси и третьего прокси погоняющий. Извините конечно но это поделки а не серьезные сервисы рассчитанные хоть та какую то нагрузку.

[vdfs]

Я работаю в автостраховании. Кто хоть раз арендовал автомобиль здесь, уверен, что слышал. У нас нет бешеной нагрузки в миллионы запросов в минуту. Скорее - в день. API на Spring Boot прекрасно справляется с этим.

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

[kostik78]

Я работаю в автостраховании. Кто хоть раз арендовал автомобиль здесь, уверен, что слышал. У нас нет бешеной нагрузки в миллионы запросов в минуту. Скорее - в день. API на Spring Boot прекрасно справляется с этим.

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

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

[vdfs]

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

Не, там побольше, чем парочка аннотаций. Довольно много микросервисов написано вокруг. Моно-репо с десятком API, общими модулями, тысячи тестов, несколько UI проектов на Angular. Работает вполне успешно с 2019 года, когда мы мигрировали и переписали старые ivy проекты на spring boot.

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

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

[kostik78]

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

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

По факту чтобы не быть голословным, мне к сожалению не один раз уже приходилось разбираться и решать проблемы созданные «магией» Spring и то что он позволяет построить монстров и девелоперы которые не задумывались, что стоит за @Controller, @Transaction, @Aspect and etc. Да со Спрингом можно легко налабать сервисов а потом ругать что железо медленное, то что нужно сервера скалировать и вертикально и горизонтально и платить деньги за ресурсы - расходов которых зачастую можно было легко избежать просто подумав о других путях. (Пожалуйста не надо мне начинать говорить про то, что время девелопера дороже, ресурсы дешевые и т.п. Я про это достаточно знаю и не один бюджет за свою карьеру считал)

[tessob]

По факту чтобы не быть голословным, мне к сожалению не один раз уже приходилось разбираться и решать проблемы созданные «магией» Spring и то что он позволяет построить монстров и девелоперы которые не задумывались, что стоит за @Controller, @Transaction, @Aspect and etc. Да со Спрингом можно легко налабать сервисов а потом ругать что железо медленное, то что нужно сервера скалировать и вертикально и горизонтально и платить деньги за ресурсы - расходов которых зачастую можно было легко избежать просто подумав о других путях. (Пожалуйста не надо мне начинать говорить про то, что время девелопера дороже, ресурсы дешевые и т.п. Я про это достаточно знаю и не один бюджет за свою карьеру считал)

Подпишусь под каждым словом! Сейчас сам пытаюсь разгрести подобную хер... магию.

[vdfs]

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

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

Давайте отойдем немного к исходной точке и посмотрим, с чего все началось. Мне выше товарищ говорил, что он использует jhipster для автогенерации CRUD / Search / Paging endpoints в Spring Boot. На что я заметил, что это руками пишется в 1 строчку на этом же Spring Boot. Соответственно, генерация этой же строчки кода в течение 10 минут (с) не имеет практического смысла. Вот, собственно, и весь мой поинт.

[Big W]

Че-то не соображу, в чем предмет спора. Что-ли предлагается там где Spring Boot не тянет использовать другие фреймворк/тулзы (какие?) или обойтись вообще без фреймворкс?

[kostik78]

Че-то не соображу, в чем предмет спора. Что-ли предлагается там где Spring Boot не тянет использовать другие фреймворк/тулзы (какие?) или обойтись вообще без фреймворкс?

Если Spring boot использовать с умом и не тыкать(copy/paste from stackoverflow/documentation) бездумно аннотации и не использовать @Aspect без Aspectrt+CTW то для среднезагруженых не сильно распределённых систем (ака microservices) вполне съедобен.

Для сильно нагруженных систем (not soft real-time - это другая ниша) я бы брал plain jetty с NIO и дописывал руками под конкретную задачу с использованием точечных библиотек (типа сериализация, media conversion, crypto and etc). Причём часть внутренних компонентов системы написал бы на golang (если мы говорим о деплоейменте в контейнерах ). Вообщем надо смотреть на конкретную задачу.

Ладно я тут в офтопик свалился. Простите не удержался - наболело. Как раз с очередной «проделкой» на спринг работаю и в порядок привожу.

[vdfs]

[3DD]

Еще coding assignment: calculator with roman numbers.

Input (string): "(XV+MCD)*III-IV*(V-I)"
Output: decimal number
(Operators: +,-,*,/)

Take home task, 2 hours

Что в моей имплементации (JS) было:
1. Validate input (if only roman letters and operators, no decimals or other chars)
2. Validate if brackets are balanced, no situations like: (V+III*X
3. Create converter for romans-to-decimals
4. Break string into numbers and operators
5. Convert roman numbers into decimals using converter at step 3
6. Execute eval(..)

Step 6 could be implemented as fully custom calculator:
1. extract bracket contents, do operation inside them (recursion for nested brackets)
2. execute * and / operations
3. execute the remaining operations

А как бы вы решали и за какое время?