Это приложение не для знакомств (в плане отношений), а чисто для мужской дружбы. Как я это понял?
Прошёл тесты, в совпадениях чуть больше десяти девушек возрастом 35-52 и совпадением в районе 73%. Поменял пол на Ж, сменил поиск на М, появилось куча парней 25-35 с совпадением 85% =)
По поводу "опыта" и "проекта в породе". Можно же новичкам наработать опыт и получить проект в портфолио на фрилансе. Помимо фриланс платформ есть форумы с заказами (они ещё живы).
Оплата скорее всего будет не велика, ровно как и нет 100% вероятности что вы найдете проект под свой стэк, но всё же для веба (в т.ч. и бэка) найти не сложно. А с учётом, что на бэке можно использовать любой ЯП (не приходит на ум ЯП, который бы нельзя было использовать на бэке), то велика вероятность, что у вас появится проект в портфолио.
Насколько знаю, сейчас относятся скептически к фрилансе в резюме, но всё же если речь про джуна, тем более с прикрепленным проектом, то пойдёт только в плюс.
То, что вы написали никак не отменят моего высказывания.
Почему вы думаете, что использую микросервисы, вы получаете гарантии? Как только вы перестанете за этим следить, сразу всё пойдёт "естественным путем".
Где вы увидели, что я писал про легаси?
Где вы увидели несколько поколений, если сами писали про 3 года?
Мой коммент был направлен именно на утверждение, что для переписывания частями не нужны микросервисы, для возможности переписывать частями нужна нормальная архитектура.
Чтобы переписывать частями нужны микросервисы?
Как по мне (и исходя из опыта), если нормальная архитектура, то и монолит можно переписывать частями без проблем
Две пиццы это на какой срок?
Какие именно пиццы? Диаметр? Вес? Калорийность?
Если это был сарказм, то я не понял)
А так… Смешивать техническое и человеческий фактор прожорливости — не самая лучшая идея.
Две пиццы 35-40см в диаметре я могу легко съесть за часов 5, хотя я не такой и большой (около 85кг).
Контроллер — это Interface Adapter. Таким образом, если библиотека выступает в роли Interface Adapter, то это не означает, что вы не используете данный слой.
Проблемы нет, если вы делегируете обязанности контроллера библиотеке, но будут проблемы, если вы будете писать бизнес логику в контроллерах.
Так много книг было написано по архитектуре.
Почему нельзя было взять аргументы, которые голосуют за разделение из книг от Макконелла, Фаулера, Дяди Боба или из статей на том же хабре и сказать почему те методики, которые описаны в книгах и статьях хуже, чем предлагает автор данной статьи? Тогда бы статья получилась не настолько однобокой.
Только из-за того, что автор ничего не написал про аргументы противоположной стороны, я считаю, что автор и не пытался узнать аргументы за разделение.
Автор пытался рассуждать про плюсы разделения, но это были его мысли, которые навряд ли были подкреплены информацией из книг или статей.
Иначе не было бы вот такого:
Чтобы переиспользовать код? — Нет, флоу перевода денег не подойдет для флоу начисления бонусов.
К тому-же если вы даже найдете возможность совместить 2 фичи, вы рискуете сломав одну — автоматически сломать другую
Все авторы писали, что есть "мнимое повторение", а есть реальное. В таком случае мнимое повторение лишь повторяет алгоритм, но используется совсем другой бизнес логикой. К примеру, если отчет по зп необходимо в двух местах (бухгалтерия и начальство), то вначале алгоритм подсчета может быть одинаковым, и будет соблазн вынести подсчет в единое место, но SRP нам подскажет, что в этом нет необходимости.
Если у вас изменения в одной части приводят к неожиданным неприятностям в других местах, то, скорее всего, у вас не всё в порядке с архитектурой.
Возможно, мы с вами говорим о разных вещах. Я не могу понять о чем именно вы говорите, т.к. ваш пример очень абстрактен и не дает понятия какие практики вы использовали, а так же мне не совсем понятно что вы имеете ввиду под моделью данных (это затрагивает сразу несколько аспектов).
Мне не понятно почему вы написали про объем данных, т.к. я говорил про реализацию абстракции доступа к данным, а не про конкретные бд.
Если решение миграции было принято "просто потому что", то мне жаль, что вам пришлось иметь дело с таким требованием.
Да, заменим в DI контейнере, и другие части этого не заметят.
Если вы захотите использовать оба — то пожалуйста, можете в одном датасурсе это реализовать, либо в разных, а доступ к ним осуществлять через репозиторий.
На случай "А вдруг вернуться захотим" есть инструменты контроля версий
Я так и делаю =)
Создаю интерфейс UserDataasource, в котором описываю методы.
Затем создаю класс UserDatasourceImpl, в котором реализую предыдущий интерфейс и при этом сохраняю данные в переменных.
Затем, когда я завершаю разработку, я либо переписываю методы, либо создаю новый класс (Данный подход не сильно отличается от переписывания методов).
Но чаще я всё таки создаю вначале класс UserDatasourceImplMock, для того, чтобы явно было видно, что это заглушка, а так же переиспользовать в тестах.
К тому же, общение с бд у меня чаще происходит через композицию в этих датасурсах (В приватную переменную кладу объект соединения при инициализации объекта датасурса).
Такое чувство, что автор не пытался разобраться в вопросе, не искал статьи и книги для ответа на вопрос "Почему делают так?". Иначе автор спорил бы с аргументами, которые говорят "за" разделение, а не писал только свои мысли по этому поводу.
К примеру, когда я создаю что-то с нуля (те же петы), я не пишу сразу класс для работы с бд.
Вместо этого я создаю интерфейс и класс, который реализует данный интерфейс. При этом данный класс не общается с бд, а сохраняет в свои локальные переменные.
Это позволяет мне на этапе разработки совершенно не зависеть от бд и легко делать правки. Затем, когда будет готов модуль, я создаю новый класс, где реализовано общение с бд. Но при этом другие части системы вообще ничего не почувствуют, т.к. они как общались с интерфейсом, так и продолжают общаться с интерфейсом
Абстракции позволяют писать легко тестируемый код за счет того, что модули (классы) становятся взаимозаменяемые.
Один раз написав интерфейс для работы с данными, мы можем реализовывать данный интерфейс в своих классах, где будет основная логика работы с конкретными хранилищами данных. Таким образом мы можем использовать mysql, а затем, если нам необходимо будет, мы напишем новый класс, где будет общение с другой бд, или для тестов мы можем написать датасурс, где данные будут сохраняться в переменные.
Так же автор в своём примере превращает DI в сервис локатор, нарушая принципы инкапсуляции
Vue даже не проверяет пропсы на моменте компиляции. Можно создать экземпляр с обязательным пропсом, но не передавать этот пропс при использовании экземпляра. Vue ругнется только в рантайме.
Я с MobX не работал. Как там обстоят дела с модулями? Если там есть модули:
1. Можно ли их подгружать в момент работы?
2. Как происходит работа с модулями (получение состояния, изменение состояния)
Вообщем не должно возникать проблем при использовании vuex только в качестве хранилища. Но проблемы начинаются, если пытаешься делать что-либо помимо хранения данных.
Хотя у меня и с хранением иногда возникают проблемы, приходится решать хуками vuex, что называть кроме как костылем не повернётся язык (проблема была связана с тем, что vuex не обновлял computed реактивно)
Вы про jwt токен или впринципе про токен? =)
Если про jwt, то я не вижу смысла в jwt. Он не жизнеспособен просто из-за того, что не гарантирует консистентность. А чтобы он это гарантированно его нужно валидировать на инвалидность (на то, что его не отозвали), но тогда легче использовать токен в виде рандомной строки, т.к. не будет оверхеда на подписи
Это приложение не для знакомств (в плане отношений), а чисто для мужской дружбы.
Как я это понял?
Прошёл тесты, в совпадениях чуть больше десяти девушек возрастом 35-52 и совпадением в районе 73%.
Поменял пол на Ж, сменил поиск на М, появилось куча парней 25-35 с совпадением 85% =)
По поводу "опыта" и "проекта в породе".
Можно же новичкам наработать опыт и получить проект в портфолио на фрилансе. Помимо фриланс платформ есть форумы с заказами (они ещё живы).
Оплата скорее всего будет не велика, ровно как и нет 100% вероятности что вы найдете проект под свой стэк, но всё же для веба (в т.ч. и бэка) найти не сложно. А с учётом, что на бэке можно использовать любой ЯП (не приходит на ум ЯП, который бы нельзя было использовать на бэке), то велика вероятность, что у вас появится проект в портфолио.
Насколько знаю, сейчас относятся скептически к фрилансе в резюме, но всё же если речь про джуна, тем более с прикрепленным проектом, то пойдёт только в плюс.
Видимо, вы работали только с умными людьми)
На моей практике было такое, что человек вместо написания пары строк кода пишет отдельный класс костылей
То, что вы написали никак не отменят моего высказывания.
Почему вы думаете, что использую микросервисы, вы получаете гарантии? Как только вы перестанете за этим следить, сразу всё пойдёт "естественным путем".
Где вы увидели, что я писал про легаси?
Где вы увидели несколько поколений, если сами писали про 3 года?
Мой коммент был направлен именно на утверждение, что для переписывания частями не нужны микросервисы, для возможности переписывать частями нужна нормальная архитектура.
Не понимаю почему вы пишите оффтоп
Чтобы переписывать частями нужны микросервисы?
Как по мне (и исходя из опыта), если нормальная архитектура, то и монолит можно переписывать частями без проблем
Две пиццы это на какой срок?
Какие именно пиццы? Диаметр? Вес? Калорийность?
Если это был сарказм, то я не понял)
А так… Смешивать техническое и человеческий фактор прожорливости — не самая лучшая идея.
Две пиццы 35-40см в диаметре я могу легко съесть за часов 5, хотя я не такой и большой (около 85кг).
Контроллер — это Interface Adapter. Таким образом, если библиотека выступает в роли Interface Adapter, то это не означает, что вы не используете данный слой.
Проблемы нет, если вы делегируете обязанности контроллера библиотеке, но будут проблемы, если вы будете писать бизнес логику в контроллерах.
Так много книг было написано по архитектуре.
Почему нельзя было взять аргументы, которые голосуют за разделение из книг от Макконелла, Фаулера, Дяди Боба или из статей на том же хабре и сказать почему те методики, которые описаны в книгах и статьях хуже, чем предлагает автор данной статьи? Тогда бы статья получилась не настолько однобокой.
Только из-за того, что автор ничего не написал про аргументы противоположной стороны, я считаю, что автор и не пытался узнать аргументы за разделение.
Автор пытался рассуждать про плюсы разделения, но это были его мысли, которые навряд ли были подкреплены информацией из книг или статей.
Иначе не было бы вот такого:
Все авторы писали, что есть "мнимое повторение", а есть реальное. В таком случае мнимое повторение лишь повторяет алгоритм, но используется совсем другой бизнес логикой. К примеру, если отчет по зп необходимо в двух местах (бухгалтерия и начальство), то вначале алгоритм подсчета может быть одинаковым, и будет соблазн вынести подсчет в единое место, но SRP нам подскажет, что в этом нет необходимости.
Если у вас изменения в одной части приводят к неожиданным неприятностям в других местах, то, скорее всего, у вас не всё в порядке с архитектурой.
Возможно, мы с вами говорим о разных вещах. Я не могу понять о чем именно вы говорите, т.к. ваш пример очень абстрактен и не дает понятия какие практики вы использовали, а так же мне не совсем понятно что вы имеете ввиду под моделью данных (это затрагивает сразу несколько аспектов).
Мне не понятно почему вы написали про объем данных, т.к. я говорил про реализацию абстракции доступа к данным, а не про конкретные бд.
Если решение миграции было принято "просто потому что", то мне жаль, что вам пришлось иметь дело с таким требованием.
Да, заменим в DI контейнере, и другие части этого не заметят.
Если вы захотите использовать оба — то пожалуйста, можете в одном датасурсе это реализовать, либо в разных, а доступ к ним осуществлять через репозиторий.
На случай "А вдруг вернуться захотим" есть инструменты контроля версий
Я так и делаю =)
Создаю интерфейс
UserDataasource, в котором описываю методы.Затем создаю класс
UserDatasourceImpl, в котором реализую предыдущий интерфейс и при этом сохраняю данные в переменных.Затем, когда я завершаю разработку, я либо переписываю методы, либо создаю новый класс (Данный подход не сильно отличается от переписывания методов).
Но чаще я всё таки создаю вначале класс
UserDatasourceImplMock, для того, чтобы явно было видно, что это заглушка, а так же переиспользовать в тестах.К тому же, общение с бд у меня чаще происходит через композицию в этих датасурсах (В приватную переменную кладу объект соединения при инициализации объекта датасурса).
Такое чувство, что автор не пытался разобраться в вопросе, не искал статьи и книги для ответа на вопрос "Почему делают так?". Иначе автор спорил бы с аргументами, которые говорят "за" разделение, а не писал только свои мысли по этому поводу.
К примеру, когда я создаю что-то с нуля (те же петы), я не пишу сразу класс для работы с бд.
Вместо этого я создаю интерфейс и класс, который реализует данный интерфейс. При этом данный класс не общается с бд, а сохраняет в свои локальные переменные.
Это позволяет мне на этапе разработки совершенно не зависеть от бд и легко делать правки. Затем, когда будет готов модуль, я создаю новый класс, где реализовано общение с бд. Но при этом другие части системы вообще ничего не почувствуют, т.к. они как общались с интерфейсом, так и продолжают общаться с интерфейсом
Абстракции позволяют писать легко тестируемый код за счет того, что модули (классы) становятся взаимозаменяемые.
Один раз написав интерфейс для работы с данными, мы можем реализовывать данный интерфейс в своих классах, где будет основная логика работы с конкретными хранилищами данных. Таким образом мы можем использовать mysql, а затем, если нам необходимо будет, мы напишем новый класс, где будет общение с другой бд, или для тестов мы можем написать датасурс, где данные будут сохраняться в переменные.
Так же автор в своём примере превращает DI в сервис локатор, нарушая принципы инкапсуляции
Я с MobX не работал. Как там обстоят дела с модулями? Если там есть модули:
1. Можно ли их подгружать в момент работы?
2. Как происходит работа с модулями (получение состояния, изменение состояния)
Если про это, то да. Почти всегда использую commit'ы в качестве прокси для изменения state
Вообщем не должно возникать проблем при использовании vuex только в качестве хранилища. Но проблемы начинаются, если пытаешься делать что-либо помимо хранения данных.
Хотя у меня и с хранением иногда возникают проблемы, приходится решать хуками vuex, что называть кроме как костылем не повернётся язык (проблема была связана с тем, что vuex не обновлял computed реактивно)
Вы про jwt токен или впринципе про токен? =)
Если про jwt, то я не вижу смысла в jwt. Он не жизнеспособен просто из-за того, что не гарантирует консистентность. А чтобы он это гарантированно его нужно валидировать на инвалидность (на то, что его не отозвали), но тогда легче использовать токен в виде рандомной строки, т.к. не будет оверхеда на подписи