Все зависит от языка и контейнер DI \ IoC. Т.е. на сколько он дает простор для решения такой задачи
Например у нас есть функционал accaunts и likes. Можно разделить по пакетам в коде все что относится к ним. Реализация должна быть видна только внутри пакетов их или даже подпакетов. Наружу public interface AccauntsService и LikesService и взаимодействие только через них :) Это я имел ввиду. А на ревью по шапке давать всем, кто обходные пути создает. Благо это не так сложно и соглашений куча не надо будет.
Согласен. Оверхед огромный по соглашениям писанным и неписанным - зло
(поставил вам плюсик в карму за интересный диалог)
А есть открытая информация что это за CDN и кто их обслуживает на территории РФ ? Было бы интересно в этих нюансах на досуге разобраться. Потешить любопытство.
Интересная кстати бизнес-модель на счет того, что Гуглу платят и сами работают. Это слухи или просто мысль ? А-то как-то звучит немного необычно: "Тысячи серверов нагружены на наши деньги + оборудование сетевое, люди. Но платят не нам, а мы". Очень необычно :)
лечите зуб сейчас, иначе придется коронку ставить (персональная рекомендация заранее)
не ешьте много сахара - диабет\кариес (а это уже более расширенное)
SMS: "Сегодня очень много зараженных гриппом в Казани, предупреждаем о новой вспышке эпидемии. Вот Вам ссылка на рекомендации "
Примеров много может быть. Конкретных при чем. Не нужно слишком что-то абстрактное придумывать.
Кто-то заранее себе сено подложит, а кто-то просто ничего не станет делать. Главное информировать заранее, что часто и делается, а это лучше, чем молчать сидеть и не информировать. Особенно когда речь идет о мчс
О! Из моего опыта приходилось иметь кластера готовые как на сбере, так и на vk (но он был молод еще год\два назад).
Если выбираете такое сегодня, то готовьтесь к тому, что у них будут баги (сейчас уже меньше), которые могут подпортить жизнь вам и sre специалистам. Либо не баги, а плановые замены стораджей например, что может повлиять на миграции ваших stateful сервисов. Вас будут информировать постоянно о каких-то работах у них там. SLA может снизиться.
Коллеги, гораздо проще свое всегда иметь и дешевле. Да, на старте будет сложновато. :)
Извините. Статья вызывает противоречивые чувства. Сколько вырубается деревьев в день - интересно, идея стартапа - наверное любой в свое время думал о том, что упаковки можно переиспользовать.
Бизнес модель толком не описана, на техническую статью не похожа
Простите, но я ничего не узнал из статьи кроме как у них (США) есть какие-то коробки и их возможно будут сдавать куда-то обратно и в России этого нет (3 раза аж повторено было)
Ну это уже в какой-то степени обман, поскольку кандидат на шарписта откликается, а предлагают другое. Может я неправильно понял посыл
Все зависит от языка и контейнер DI \ IoC. Т.е. на сколько он дает простор для решения такой задачи
Например у нас есть функционал accaunts и likes. Можно разделить по пакетам в коде все что относится к ним. Реализация должна быть видна только внутри пакетов их или даже подпакетов. Наружу public interface AccauntsService и LikesService и взаимодействие только через них :) Это я имел ввиду. А на ревью по шапке давать всем, кто обходные пути создает. Благо это не так сложно и соглашений куча не надо будет.
Согласен. Оверхед огромный по соглашениям писанным и неписанным - зло
(поставил вам плюсик в карму за интересный диалог)
Для этого и нужен hr, либо агенство.
У самого такая же проблема. Времени нет даже
Давайте расскажу секрет самого простого резюме :)
Целыми днями и ночами программируете\читаете книги или статьи. Слушаете своего наставника (если он есть) и продолжаете развиваться по хардскиллам.
В идеале мониторите вакансии и синхронизируете требуемые умения.
Все честно. Идет время, вам все еще нравится программировать и вы привыкаете так жить - развиваться...
А теперь копируете требования с вакансии к себе в резюме :)
Не надо ничего придумывать лишнего
Да. Интересная мысль. Согласен на счет того, что с сетью проблемы будут
Спасибо большое. Почитаю. Похоже на полезную инфу :)
А есть открытая информация что это за CDN и кто их обслуживает на территории РФ ? Было бы интересно в этих нюансах на досуге разобраться. Потешить любопытство.
Интересная кстати бизнес-модель на счет того, что Гуглу платят и сами работают. Это слухи или просто мысль ? А-то как-то звучит немного необычно: "Тысячи серверов нагружены на наши деньги + оборудование сетевое, люди. Но платят не нам, а мы". Очень необычно :)
В любом случае Гугл видимо все еще их содержит и закидывает регулярно денюжку. Никто не будет бесплатно для них это держать. Это очень дорогой бизнес
Согласен, но
То что для модуля реализуется должно быть видно только модулю
Модуль публикует для остальных только интерфейсы
Разработчики обращаются только к интерфейсам
На ревью за говнокод по рукам
А так же если все так плохо и надо по-быстрому сделать говнокод, то сделать страшную какашку с микросервисами еще проще :) разве не так ?
Ну обращаться в органы из-за того, что кто-то смог бесплатно продвинуть свой продукт, да еще и назвать мошенниками - вот это еще тот кринж...
" Ааааа, 650 млн рублей.... Нас обокралиии! Мошенники! "
По JavaCard еще книга замечательная есть и при чем переведенная на русский язык.
Если кому интересно дополнительно почитать так же :)
И никогда не начинайте проект с микросервисной архитектуры просто так.
Вполне возможно MVP можно начать с монолита, разделенного по модулям. Это сэкономит много денег и нервов. Попробуйте -не пожалеете :)
Согласен, но ситуации бывают разные как и врачи.
А вот Вам конкретные примеры предупреждений:
лечите зуб сейчас, иначе придется коронку ставить (персональная рекомендация заранее)
не ешьте много сахара - диабет\кариес (а это уже более расширенное)
SMS: "Сегодня очень много зараженных гриппом в Казани, предупреждаем о новой вспышке эпидемии. Вот Вам ссылка на рекомендации "
Примеров много может быть. Конкретных при чем. Не нужно слишком что-то абстрактное придумывать.
Кто-то заранее себе сено подложит, а кто-то просто ничего не станет делать. Главное информировать заранее, что часто и делается, а это лучше, чем молчать сидеть и не информировать. Особенно когда речь идет о мчс
О! Из моего опыта приходилось иметь кластера готовые как на сбере, так и на vk (но он был молод еще год\два назад).
Если выбираете такое сегодня, то готовьтесь к тому, что у них будут баги (сейчас уже меньше), которые могут подпортить жизнь вам и sre специалистам. Либо не баги, а плановые замены стораджей например, что может повлиять на миграции ваших stateful сервисов. Вас будут информировать постоянно о каких-то работах у них там. SLA может снизиться.
Коллеги, гораздо проще свое всегда иметь и дешевле. Да, на старте будет сложновато. :)
Извините, а мне полезно получать заранее информацию о том, что что-то может случиться.
Так же и врачи многие заранее говорят что вредно, а что нет и что лучше делать (не все конечно на руку чисты или правы).
А как уж поступит с этой информацией сам человек - это его проблемы. Лечить\спасать конечно же его будут, но предупреждали же! :)
при чем курьер сразу заберет при выдаче заказа :) не надо тратить время\бензин\калории чтобы сдавать коробку копеечную ради идеи
а они не клеятся судя по всему, просто такая же конструкция для плотного закрытия как и прежде было
Извините. Статья вызывает противоречивые чувства. Сколько вырубается деревьев в день - интересно, идея стартапа - наверное любой в свое время думал о том, что упаковки можно переиспользовать.
Бизнес модель толком не описана, на техническую статью не похожа
Простите, но я ничего не узнал из статьи кроме как у них (США) есть какие-то коробки и их возможно будут сдавать куда-то обратно и в России этого нет (3 раза аж повторено было)
Из чего коробки ?
Чем они лучше пластиковых?
Какой процент от рынка хотят занять ?
Стартап работает уже или это еще MVP ?
в целом про хабр