Это сейчас врачи разбалованы гуглом, а еще совсем недавно все эти дозы нужно было помнить наизусть. Плюс фармацевт не сядет пересчитывать дозировку в рецепте, если конкретного вещества нет в аптеке, а его гомолог/аналог или, тем более, смешанный препарат есть.
Кстати, биологический эквивалент Рентгена и Зиверт — это из той же оперы, у врача нет времени пересчитывать дозу по каждому типу облучения.
МЕ используются не по прихоти врачей, а по суровой необходимости. Дело в том, что большинство биологически активных веществ, включая витамины, это не одно вещество с конкретной формулой, а группа веществ с одинаковыми свойствами, но с разной активностью на грамм вещества. Возьмем, к примеру тот самый ретинол. В чистом виде он в препаратах не встречается из-за низкой биодоступности, поэтому применяют его соли — ретинола ацетат и ретинола пальмитат. За счет гораздо большей молекулярной массы пальмитиновой кислоты, пальмитата нужно по массе гораздо больше, чем ацетата для достижения того же эффекта. Поэтому такие смеси часто просто пересчитывают по активности в МЕ или заморачиваются и пересчитывают в эквивалентную массу основного действующего вещества (в данном случае — чистого ретинола).
Я много чего видел и слышал. И отнесение изменения состояния интерфейса к бизнес-логике, и обзывание роутинга на сервере фронтендом (или даже фронтендом бэкенда или бэкендом фронтенда), и то, как три строчки размытых хотелок называют ТЗ.
Моё мнение, что любой сервис должен быть в первую очередь доступен и полностью работоспособен через API, во вторую — иметь доступ к этому API через максимально простой интерфейс, и только на третьем месте — свистелки, метеоризм и прочий реакт с вебпаком, как бы ни странно это звучало от человека, чьим основным хлебом очень долго был фронт.
Так фишка именно в том, что бизнес-логика как раз и реализована на бэке, а на фронте только максимально удобный UI для неё. И как бы пафосно это не звучало, но хороший программист может писать код на любом человеческом языке программирования (не считая, может быть, марсианских чисто функциональных языков и диалектов брейнфака) и вынос кода с фронта на бэк должен быть если не тривиальной, то, по крайней мере, решаемой задачей. Подход с бизнес-логикой на фронте, когда для бэка остается роль тонкой прокладки для роутинга и синхронизации с другими сервисами, мне совершенно не нравится — получаются какие-то совершенно неповоротливые монстры. Вот и выходит где-то 60% работы на бэке, 35% на фронте и 5% DevOps (минимум для разворачивания собственного окружения и как черновик для прода)
Есть еще вариант. В эпоху микро- и наносервисов часто возникает ситуация, когда фронт, бэк и овнер — одно лицо, потому что больше нет смысла. Я пришел во фуллстек из фронта. Создать простенький бэк для общения с остальными сервисами на основе современного фреймворка — не особая проблема, большая часть проекта — привычный мне фронт
Смешались в кучу кони, люди,
И залпы тысячи орудий
Слились в протяжный вой…
О том, что здесь использована стрельба из крупнокалиберных орудий по малым целям, уже написано.
Я же со своей стороны хочу отметить, что
называть любой кусок серверного кода «фронтэндом» — плохая практика, большинство разработчиков резервирует это слово для кода, выполняемого исключительно на клиенте, вместо вашего «frontend» стоит употреблять router, а вместо «backend» — API-server
при наличии живого роутера, делать прямой доступ с клиента аджаксом на апи-сервер — нарушение инкапсуляции и создание проблем с CORS на ровном месте
Пардон. Забыл уточнить, что речь идет об украинской части зоны. И для того, чтобы зубр мигрировал туда из Беларуси, он должен был, скорее всего, переплыть Припять
Интересно, что в Чернобыльской зоне отчуждения на фотоловушки стали попадаться зубры. Пока непонятно, то ли это единичные случаи «прогулок» зубров из Беловежской Пущи, то ли там уже сформировалась местная популяция.
Нет, хоть урезанный, но линукс будет. Откройте Dockerfile любого образа контейнера на докер хабе и посмотрите что там происходит. Обычно в самой первой директиве FROM описано какой дистрибутив взят за основу. Но даже если там написано FROM scratch, всё равно используется докеровский дистрибутив по умолчанию
Абсолютно. Вы не получите некоторой части плюшек, связанных с модульностью, например горизонтальное масштабирование, но это будет вполне работоспособное решение — преимущества стандартного и изолированного окружения, а также возможность разворачивания через службы CI/CD никуда не деваются
А почему nginx и mysql не поставить в тот же контейнер, где и php-fpm с утилитами?
Потому что гораздо быстрее взять готовые образы и подключить их к связке, чем устанавливать их внутрь контейнера основного приложения. И бонусом получить горизонтальное масштабирование на проде
Для вас оптимально будет использовать docker-compose с тремя контейнерами — отдельно nginx, отдельно mysql (можно брать прямо официальные образы), отдельно php-fpm+утилиты (скорее всего придется сбилдить свой образ на основе официального, но это несложно, в него же можно прикрутить composer с phpmyadmin), возможно еще +контейнер под хранение файлов если связку предполагается таскать с машины на машину. Можно заводить отдельный контейнер на phpmyadmin, а можно и нет. Но работать с кучей небольших официальных образов контейнеров часто проще, чем городить один свой, в котором запихнуто всё. И вся эта конструкция будет элементарно запускаться/глушиться одной командой.
Учитывая, что если включить VMWare/Hyper-V, то, фактически, перестают работать другие виртуалки, то у нас многие не заморачиваются с «нативным» докером под виндой, а ставят в Virtualbox любой серверный линукс и ставят докер уже на него. С одной стороны, добавляется немного головной боли на пробрасывание ресурсов туда-сюда, с другой — нет проблем с несовместимостью VMWare/Hyper-V, всё отлично работает хоть из-под XP
Докер использует от хостового линукса только ядро (это если говорить упрощенно). Поэтому внутри контейнера можно поднять абсолютно любой дистрибутив. Часто там используются специально заточенные под использование внутри контейнера минимальные версии дистрибутивов. OpenVZ использует очень похожий подход, но сложнее в использовании и не имеет столь широкой базы готовых контейнеров
воспроизводимость окружения, чтобы не случилось так, что разработчик говорит, что у него всё работает, а при разворачивании на сервере всё ломается из-за того, что разработчик забыл описать в требованиях какую-то зависимость.
изолированость окружения, чтобы не случилось так, что для работы одному проекту нужна версия 1 какого-то инструмента, а другому проекту — версия 2, а одновременно на одну машину эти версии не становятся.
поддержка чистоты на хост-машине, чтобы не случилось так, что для проекта нужно установить с десяток зависимостей, которые потом нужно долго и нудно выковыривать из системы, контейнер удаляется в одну команду, не зависимо от того, насколько глубоко пакеты в нём интегрированы в систему
замена пакетному менеджеру(?), чтобы не случилось так, что для вашего дистрибутива или для вашего пакетного менеджера нет готовых бинарников нужного пакета, можно просто поднять его в докере и не морочить себе голову с курением мануалов (на самом деле этот пункт — лишь забавный побочный эффект от других преимуществ докера)
простота разворачивания, чтобы можно было проще настраивать инструменты непрерывного развертывания
Кстати, биологический эквивалент Рентгена и Зиверт — это из той же оперы, у врача нет времени пересчитывать дозу по каждому типу облучения.
Моё мнение, что любой сервис должен быть в первую очередь доступен и полностью работоспособен через API, во вторую — иметь доступ к этому API через максимально простой интерфейс, и только на третьем месте — свистелки, метеоризм и прочий реакт с вебпаком, как бы ни странно это звучало от человека, чьим основным хлебом очень долго был фронт.
И залпы тысячи орудий
Слились в протяжный вой…
О том, что здесь использована стрельба из крупнокалиберных орудий по малым целям, уже написано.
Я же со своей стороны хочу отметить, что
Потому что гораздо быстрее взять готовые образы и подключить их к связке, чем устанавливать их внутрь контейнера основного приложения. И бонусом получить горизонтальное масштабирование на проде