• Терминология: почему контейнеры называют микросервисами?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    Насколько я понимаю, микросервис - это обычный сервис, который решает одну маленькую задачу. Микросервис может состоять как из одного контейнера, так и из нескольких контейнеров (если используются контейнеры).

    да
    вобще терминология немного вводит в заблуждение, обычно говорят не микросервис, а микросервисная архитектура, тоесть такая архитектура сервиса при которой сервис состоит из множества независимых друг от друга узлов, которые ты можешь независимо разрабатывать и деплоить, без необходимости изменений в остальных узлах. сколько самих узлов и их размер уже не так важен.
    Ответ написан
    Комментировать
  • Кластер: обязательно ли наличие нескольких серверов?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    2. дополнительная пропускная способность? - ну если только ДО БД, а дальше бд то одна, соответственно перфоманс всего приложения всё равно не изменится.
    Ответ написан
    Комментировать
  • Apple взимает плату за изменение диалоговых окон, попап и меню?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    1 и 2 -> кому-то сложно, кому-то не сложно, у каждого исполнителя своя оценка что есть сложно, а что нет.
    3 -> стоит это столько, сколько просит исполнитель (ни больше, ни меньше), к сложности это имеет лишь косвенное отношение (цена зависит от рыночка).
    Ответ написан
    Комментировать
  • Что такого хорошего в иммутабельности?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    ну например можно эффективно переиспользовать и хранить структуры данных.

    вот например сложить 2 списка:
    в случае с иммутабельным чтоб создать третий общий список, тебе достаточно только ссылки указать где надо, на первый и второй список - оба списка у тебя будут переиспользоваться, а в память добавится только пару дополнительных ссылок (это вычислительно быстро и требует мало памяти).

    в случае с мутабельными списками - тебе нужно создать третий, копируя все элементы первого и второго, что затратно как по времени исполнения, так и по объему хранения.
    если ты в мутабельной структуре попробуешь тоже ссылочками сделать новую структуру, у тебя может получится такая ситуация, что уже ПОСЛЕ создания нового списка, при изменении в исходной структуре - эти изменения появятся в твоём новом списке, как неконтролируемое изменение, которое ты не выполнял.
    В итоге поскольку в иммутабельных структурах есть гарантии, что они будут не измены, то их можно переиспользовать при создании новых структур данных, мутабельные же нельзя.
    Ответ написан
    Комментировать
  • Реально ли работать в одном IT-проекте (продуктовом) больше 5-ти лет и не деградировать профессионально?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    очень сложно работать над одним проектом и быстро развиваться, тк у каждого проекта есть жизненный цикл, разработка постепенно сменяется поддержкой, рост и развитие замедляется, в результате если хочется роста, нужно менять проекты, обычно внутри компании переходить между проектами проще.
    П. С.
    с точки зрения позиции и доходов внутри компании такой рост очень медленно происходит, поэтому тоже приходится компанию менять.
    Ответ написан
    Комментировать
  • Один микросервис или два?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    есть такой подход: посмотреть на сколько пересекаются сущности с которыми приходится работать, и специфичная для работы терминология - мне кажется что тут полное пересечение до степени смешения - поэтому я бы делал как один сервис.
    Ответ написан
    Комментировать
  • Микросервисная архитектура: насколько микро? и почему не возникает проблем с долгим ожиданием?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    обычно микросервисы нарезают так чтоб они обслуживали отдельную "тематику", которую можно было бы отдельно маштабировать и отдельно дорабатывать, от всех остальных. Пример:
    микросервис который обрабатывает работу каталога (и всё что связанно с ним), отдельно микросервис который будет работать с доставкой и отправкой заказов, микросервис который работает с партнёрской программой и начислением балов лояльности, и микросервис который занимается обработкой платежей. У каждого из этих микросервисов желательно иметь свою БД, тогда они могут независимо друг от друга работать и независимо маштабироваться, только отвечая потребностям свой нагрузки - очевидно нагрузка на каталог сильно выше чем на сервис обработки платежей (например каталог может обрабатывать 10 узлов, заказы обрабатывают 3 узла а платежи 1 узел)
    При использовании монолита вы масштабируете сразу все сервисы на узлы, что не так эффективно.
    -------
    По поводу перфоманса - при такой нарезке как описал выше, у вас крайне редко будет ситуация когда для ответа на один запрос от пользователя, нужно будет опрашивать сразу несколько сервисов, НО даже в таких ситуациях не так важна задержка между вызовами, сколько возможность масштабировать обработку этих запросов.
    -------
    транзакционность обычно осуществляется через SAGA паттерн.
    По поводу консистентности - если ты начинаешь масштабировать систему, значит состояние размазывается по множеству разных узлов/сервисов, вся суть что эти узлы/сервисы могут независимо друг от друга работать, значит консистентность будем мешать независимой работе (тоесть производительности), если сервисы зависимы то они не маштабируются (раз один узел ожидает что-то для работы от другого узла), поэтому там предъявляются "ослабленные требования" к консистентности состояния, как правило используют eventual consistency (согласованность в конечном счете), говорят что рано или поздно типа состояние в системе будет согласованно, если не будут поступать новые данные)
    ну а пока данные поступают, то состояние может быть не согласованно между узлами.
    Ответ написан
    Комментировать
  • Что происходит на рынке труда в айти?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    выделю два момента, который почему-то из фокуса внимания всегда уходит:
    1) есть куча книг/курсов например по математике или там программированию - там всё примерно одно и тоже, отличаются ну разве что подачей материала или форматом (ну вот нравиться кому-то получать "домашку" и за это платить по 100к в месяц - пожалуйста).
    2) ни одна из этих книжек сама по себе не сделает из тебя математика или программиста. Вот есть например книжка - "искусство бокса" в 3х томах - наверно глупо считать, что прочитав её вы станете профессиональным боксёром и сможете как Майк Тайсон зарабатывать за бои по миллиону долларов, но обещая такие фантазии проще продавать курсы или книжки (наивность людей просто удивляет)
    П. С.
    только от тебя (твоих талантов/вложенного труда) зависит станешь ты кем-то или нет и вообще без разницы какие именно курсы или книжки ты выберешь.
    Ответ написан
    Комментировать
  • Сколько часов кодить на работе?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    можно провести аналогию с бегом - сколько кто может бегать? - неподготовленный человек не долго, подготовленный намного дольше.
    На моей практике обычно от 2х до 4х часов разработчики кодят.
    Если человек очень хорошо подготовлен то может больше - у меня обычно после 6-7 часов кодинга голова перестаёт соображать, можно только что-то на лайте делать)
    Но помимо кодинга куча сопутствующих задач ещё есть, начиная от изучения проблемы, заканчивая тестированием, документированием ну и личным развитием.
    Ответ написан
  • Как правильно решить конфликты в dev ветке для двух веток в разработке?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    перед слиянием дев ветки, её можно подготавливать, делать например операцию squash

    обычно есть опция перед слиянием, автоматически делать squash.
    Ответ написан
    Комментировать
  • Вопрос по тестовому заданию, масштабируемый сервис?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    видимо ожидается маштабирование вашего сервиса.
    для этого есть несколько подходов:
    например подходы связанные с "реплицированием", тоесть просто дублируются базы данных, что позволяет ускорять чтение (запись из-за этого наоборот будет медленней, тк требуется синхронизация записи между копиями),
    и второй подход "шардирование", когда на разных базах хранятся разные группы данных (например пользователи с 1-1000 хранятся и обрабатываются на сервере 1, с 1000 по 2000 на сервере 2 и тд).
    есть и более хитрые подходы типа умных кэшей.
    Также судя по пункту 4, ожидается какой-то "кэширующий слой" между вашим сервисом и сторонним источником котировок.
    Ответ написан
    Комментировать
  • Что делать, если тяжело работать?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    Делай, что должно, и будь, что будет​. . .
    Тебе стоит просто расслабиться, раз тебе одному дали проект, то тебе стоит делать то что ты считаешь нужным, ТАК как ты считаешь нужным. Ты же не бизнесом занимаешься, все риски от бизнес решений лежат на руководстве, с тебя спроса никакого.
    Ответ написан
    Комментировать
  • Автоматизация пересборки контейнера после установки пакета в проекте. Возможно ли?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    ну есть такая команда docker commit - которая позволяет сохранить изменения в контейнере. но думаю всё равно стоит сохранять в докер фаил все шаги необходимые для новой сборки имиджа (просто не всегда его пересобирать).
    а для того чтоб автоматизировать сборку, обычно выстраивают CI/CD пайплайны, завязывая их на изменениях в репозитории. Тоесть в своём репозитории описываются дополнительно шаги по сборке контейнера, которые срабатывают каждый раз когда происходят изменения в репозитории (ну например изменения докер файла или какие-то изменения в коде проекта).
    П. С.
    сборка разумеется идет с нуля, но за счет того что каждая инструкция в докер файле - это отдельный слой который кэшируется, то процесс может неплохо так ускоряться.
    Ответ написан
    Комментировать
  • Пишут ли в компаниях коммиты в git на русском?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    Работаю в российской компании, очень очень редко видел, чтоб писали на английском описания комитов)
    В первую очередь вы эту историю ведете для себя и для своих коллег разработчиков, поэтому лучше исходить из того как вам самим комфортнее работать.
    Если команда состоит из русскоязычных, то нет смысла из себя чего-то там выдавливать на английском.
    П. С.
    есть инструменты которые по определенным стандартам обрабатывают коммиты, они как правило опираются на ключевые слова, например указания типа коммита (fix, feature и тд) эти типы можно расширять разумеется русскими словами, но обычно этим не занимаются, а используют преднастроеные типовые варианты.
    Поэтому обычно происходит комбинация и русского и английского, где ключевые слова (например тип комита) на английском, а пояснения и описания на русском.
    Ответ написан
    Комментировать
  • Как запустить 2 процесса в контейнере Docker?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    CMD - это просто аргументы которые используются по умолчанию при запуске контейнера, последний CMD перезаписывает предыдущий.
    вобще чтоб запустить параллельно процессы можно команды соединить амперсандом — &
    Однако лучше это не делать, гипотетически это создаст проблемы при ограничении ресурсов на один контейнер, и сложности при масштабировании контейнеров.
    Ну и плюс сами контейнеры и есть процессы, просто с определенными слоями изоляций.
    Ответ написан
  • Почему наблюдается разное поведение при сборке Dockerfile локально и в CI / DI?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    ну вроде как у вас на врокере, на котором идет сборка из гитлаба, не установлен какой-то модуль)
    Ответ написан
  • Как оценить себя или сколько стоит мое время?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    твой час стоит ровно столько, за сколько ты его можешь продать, это скорее от "рынка" и от умения продавать зависит, а не от твоих навыков.
    хотя есть конечно ориентиры типовых ставок. Вижу часто мидлы себя умудряются очень дорого продать, сильно выше этих средних ориентиров и наоборот. Как себя оценить - ну только пробовать продавать свой труд дороже, чаще собеседоваться получать может какие-то офферы и уже из таких предложений формировать свою оценку.
    Ответ написан
  • Как составить план развития для сильного разработчика?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    ну если они такие крутые ребята, наверняка у них есть своё виденье куда и как развиваться - просто обсуди с ними их план, их пожелания и формализируй его так как требуется в компании.
    Ответ написан
    Комментировать
  • Свои проекты/воображение/проекты по совету старших коллег VS Codewars/Hackerrank/Leetcode?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    1. Да
    2. Да
    и все остальное да
    нет никакого или или, все нужно делать
    Ответ написан
    Комментировать
  • Как быть эффективным в новой команде?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    позволять людям тупо делать свою работу, понимая что она не совершенна - это редкий навык профессионала.
    К сожалению не каждый тимлид этим навыком обладает, ищут единственно верное идеальное решение)
    С другой стороны ваша задача уметь делать так как просят, пока вы не на той позиции где принимают решения, и к сожалению вам таких полномочий не дают - либо нужно уходить компанию где позволяют решать и самостоятельно делать, либо делать так как сказали.
    Единственный совет, учитесь продавать свои решения и подходы - если не можете их продать (не навязать, а заинтересовать в вашем подходе) - может тогда такое решение и не стоит использовать.
    Ответ написан
    Комментировать