Наверное, правильнее сказать "не у всех банков есть хорошо описанное и публично доступное api."
Именно.
Насколько я понял по опыту Дзен Мани, там реверсится API, используемое мобильными клиентами банков.
Вот лично мне боязно давать доступ стороннему приложению в личный кабинет по реверс апи.
А категории по выпискам из банка все равно для меня фикция, ибо в покупке в "Гипермаркет Глобус" не отделить продукты от бытовой химии или сада/огорода. Если только по QR коду с чека лезть в ИФНС и смотреть конкретные позиции... (Хотя чек я в Дзен-мани фоткаю, чтобы через год ужаснуться, насколько подорожала та же самая бутылка молока)
Такто данные по покупкам складываются в ОФД, которые доступны по номеру телефона на сайте налоговой. Другой вопрос, что далеко не все данные туда падают. А так, в дальнейшем такое действительно будет возможно, но не сейчас, к сожалению.
Также как и вы, курил эту тему с опен банкингом, и также столкнулся с проблемой, что далеко не у всех банков есть api. К слову, у АльфаБанка, Тинька и сбера есть. Но у меня другие банки, к сожалению)
Не обязательно рассматривать Actions как средства для записи в БД. Здесь речь идет скорее об Actions-слое(в терминал Фаулера - Transactions Script), который реализует бизнес-логику. Если вам не по нраву названия Actions, можете переименовать в Handlers или Invokers - без разницы, важна суть) То есть у DDD есть несколько разных реализаций, одна из которых приведена здесь. Автор говорит о том, что Actions не должны иметь зависимостей от БД(нужно использовать репозитории) и должны использовать сервисы, которые реализуют опять-таки интерфейсы.
Главный плюс такого подхода - это совершенно удобное и простое написание юнит-тестов на бизнес-логику, расположенную в Actions.
На моей памяти такого не было. Если проверки и локально и на CI-сервере выполняются на основе одних конфигов, которые лежат вместе с кодом в репозитории, то такого быть не должно.
Исходил из того, что pre-commit вызывается чаще, чем pre-push, а значит и более затратные по времени инструменты должны вызываться именно в pre-push. В моем примере на pre-commit вызывается только принудительный форматтер кода по принятому стандарту. Выходит, в моей схеме на pre-commit проверка phpcs вызывается только для перестраховки.
Фактически, эта практика взята из Open Source сообщества — выживают и наиболее популярны лучшие решения в своей области.
Речь о том, что в Open Source для решения одной и той же задачи на одном стеке обычно существует несколько решений. Однако, обычно есть решение, наиболее популярное у сообщества. Внутри компании организовать тоже самое, но в меньшем масштабе, мне кажется, хорошая идея.Наличие большого количества готовых инструментов внутри компании также является благом.
В контексте предложенной архитектуры сразу становится ясно, что для быстрой продуктовой разработки крайне необходимы готовые библиотеки для.
Как-то уж жиденько вышло. Большие движухи не указаны, добавлены какие-то локальные события
Навскидку два крупных события, которых тут нет: DevFest Siberia 2017 Highload++ 2017
а мелкие и перечислять не берусь
даем задание написать на yii2 простенький новостной сайт с регистрацией и авторизацией используя базовые шаблоны yii2 (чтобы не думали над версткой) и в нем реализовать: CRUD для новостей и CRUD для уведомлений на страницу авторизованному пользователю и на почту. Уведомления должны навешиваться на различные события. В качестве, примера в результате выполнения ТЗ должно быть уведомление, которое видит пользователь на странице при добавлении новой новости.
Это готовая реализация какого-либо функционала, который можно использовать как базу для дальнейшей работы. Например, заменить шаблон верстки на свой и добивать функционал при необходимости. Это действительно может стоить денег.
Такими тестовыми заданиями вы фактически отнимаете время у разработчика, то есть перекладываете на него затраты. Особенно неадекватно это выглядит, если тестовое дается до предварительного собеседования. Поскольку, как вы сказали, вы набирали разработчиков в небольшую компанию, то у кандидата даже нет полной информации об условиях работы, не говоря уже о заработной плате. То есть, выполняя ТЗ, кандидат в итоге получает кота в мешке в виде возможности собеседования в мутную контору. Таких однозначно нужно слать лесом.
Если же тестовое задание дается после собеседования — это нормальная ситуация, поскольку кандидат знает, какие условия ему будут предоставлены в случае успешно выполненного тестового задания.
А что, какие ещё есть бесплатные альтернативы для разработки на нескольких языках из коробки?
Если говорить о том же VSCode, пока накачаешь всяких плагинов и настроишь все - уже и кодить не захочешь.
Именно.
Вот лично мне боязно давать доступ стороннему приложению в личный кабинет по реверс апи.
Такто данные по покупкам складываются в ОФД, которые доступны по номеру телефона на сайте налоговой. Другой вопрос, что далеко не все данные туда падают. А так, в дальнейшем такое действительно будет возможно, но не сейчас, к сожалению.
Дак а какие технические моменты вы бы хотели получить? Парсинг выписок? Приложен пакет на php, который это делает. Загрузка данных в эластик?
в ручном режиме забираются выписки, в ручном))
Также как и вы, курил эту тему с опен банкингом, и также столкнулся с проблемой, что далеко не у всех банков есть api. К слову, у АльфаБанка, Тинька и сбера есть. Но у меня другие банки, к сожалению)
Не обязательно рассматривать Actions как средства для записи в БД. Здесь речь идет скорее об Actions-слое(в терминал Фаулера - Transactions Script), который реализует бизнес-логику. Если вам не по нраву названия Actions, можете переименовать в Handlers или Invokers - без разницы, важна суть) То есть у DDD есть несколько разных реализаций, одна из которых приведена здесь. Автор говорит о том, что Actions не должны иметь зависимостей от БД(нужно использовать репозитории) и должны использовать сервисы, которые реализуют опять-таки интерфейсы.
Главный плюс такого подхода - это совершенно удобное и простое написание юнит-тестов на бизнес-логику, расположенную в Actions.
На моей памяти такого не было. Если проверки и локально и на CI-сервере выполняются на основе одних конфигов, которые лежат вместе с кодом в репозитории, то такого быть не должно.
Спасибо за вопрос.
Исходил из того, что pre-commit вызывается чаще, чем pre-push, а значит и более затратные по времени инструменты должны вызываться именно в pre-push. В моем примере на pre-commit вызывается только принудительный форматтер кода по принятому стандарту. Выходит, в моей схеме на pre-commit проверка phpcs вызывается только для перестраховки.
Речь о том, что в Open Source для решения одной и той же задачи на одном стеке обычно существует несколько решений. Однако, обычно есть решение, наиболее популярное у сообщества. Внутри компании организовать тоже самое, но в меньшем масштабе, мне кажется, хорошая идея.Наличие большого количества готовых инструментов внутри компании также является благом.
Поправил, «для» в конце не нужно.
Навскидку два крупных события, которых тут нет:
DevFest Siberia 2017
Highload++ 2017
а мелкие и перечислять не берусь
Это готовая реализация какого-либо функционала, который можно использовать как базу для дальнейшей работы. Например, заменить шаблон верстки на свой и добивать функционал при необходимости. Это действительно может стоить денег.
Такими тестовыми заданиями вы фактически отнимаете время у разработчика, то есть перекладываете на него затраты. Особенно неадекватно это выглядит, если тестовое дается до предварительного собеседования. Поскольку, как вы сказали, вы набирали разработчиков в небольшую компанию, то у кандидата даже нет полной информации об условиях работы, не говоря уже о заработной плате. То есть, выполняя ТЗ, кандидат в итоге получает кота в мешке в виде возможности собеседования в мутную контору. Таких однозначно нужно слать лесом.
Если же тестовое задание дается после собеседования — это нормальная ситуация, поскольку кандидат знает, какие условия ему будут предоставлены в случае успешно выполненного тестового задания.