Если рассуждать, что может быть, то как вам такой вариант?
IBM теперь сотрудничает с правительством по этому проекту.
Технология засекречена. А официально они обьявили, что не занимаются этим, чтоб вопросов не было.
С сетевым стеком были проблемы несколько раз. Лучше чем Toolbox но не идеально. При рестарте проекта в композе внешните порты остались заняты для системы, и проект не подымался пока не перезагрузили машину.
"У всех код должен отображаться одинаково" — выражение верно только условно. Цвет, размер шрифта, междуквенное растояние, каждый настраивает, как ему угодно. Разве есть задача чтобы все видели одинаковую картинку? Тогда и мониторы у всех должны быть одинаковые.
Я думаю тут подмена понятий и реальная задача здесь, это чтобы соблюдались стандарты кодирования. Например чтобы одинаковый код, сделаный двумя разными разработчиками выглядет одинакого при просмотре в одном редакторе. И в моем случае это соблюдается.
И моя идея была в том что табы используются только для формирования блоков. Тогда каждый может настроить, как визуально сдгивается код, на маленьком экране меньший отступ даст больше видимость кода.
Внутристрочное выравнивание — там нужны проблелы, но там и другая логика выравнивания, там нет бложеных блоков, более того, там по сути "ручная" работа.
Внутристрочное выравнивание это, например, когда несколько строк с присваиванием и хочется выровнять значение по вертикале.
У каждого программиста свои предпочтения. как должен выглядеть код в его среде разработки.
Кому-то нравится темными буквами на светлом, кому то наоборот. При этом байты кода будут одни и те же, это просто настройки отображения.
Тоже самое с отступами, кому-то нравится сильный отступ. кому-то приятнее. что бы было все рядом.
Если мы используем табы, то все четко, один уровень вложенности соотвествует одному табу. В среде я могу настраивать отображать таб. как два пробела или как четыре. В файле это вcеравно будет один символ таба.
Если же мы используем проблемы, то во-первых надо убедиться, чтобы среда вставляла таб проблемами одиноковой размерности. Во-вторых, я не могу настроить представление кода, как мне удобнее.
В чем же плюс пробелов?
П.С. У меня в компании стандарт кода предписывает использовать проблелы, и я их использую, но реальных плюсов я что-то не вижу.
Конечно, не так изящно как у вас. У нас как-то нет необходимости так проэкты запускать.
Хотя у нас около сотни своих сервисов (несчитая публичные типа мемкеш, редис, мускуль и т.д.) и 25 проект yml файлов.
Сейчас заметил v3 инклюды не поддерживает пока.
Для v3 все выше так же справедливо, однако определение сервиса придется хранить в определении проекта.
Вы эту проблему решили генерацией конфига, как я понимаю.
Есть принципы похожие с вами, но помойму мы гораздо проще решили.
docker-compose.yml поддерживает инклюды.
Опредение сервиса хранится в репе сервиса.
В репе проекта хранится главный docker-compose.yml в котором прописаны инклюды и переопределены порты если пересекаются у сервисов.
Там же через лейблы прописаны гит ссылки на зависимости (репы сервисов).
Простой улилитой (рнр скрипт собраный в один исполняемый файл) https://habrahabr.ru/post/306384/
Подтягиваются зависимости
Ей же билдятся все зависимости (у нас билд приложение и билд имиджа два разных этапа)
Запуск проекта выглядит приблизительно так
git clone git://project
cd project
docker-project update # с этого момента инклюды в проекте становятся действительными
docker-project build # если у вас свой билд процесс
docker-compose up
Из плюсов
1 Минимальный уровень входа
2 Нет дополнительных конфиг файлов
3 Нет влияния на код микросервиса
Из минусов
1 Утилита требует установленного php-cli
(Можно переписать на питон или лучше Го, но пока руки не доходят.)
Как я понимаю, блокчейн в чистом виде — это список обьектов хранящих в себе:
данные, хеш родителя, собственный хеш от данных + хеш родителя.
Что бы вставить данные в такую цепочку "задним" числом, надо пересчитывать все хеши от момента изменения. Это будет невозможно, если хеши уже были известны публично, контролирующий орган заметит.
Например, это бы защитило в ситуации, муниципалитет заключил контрант с компанией на постаку чего-то, потом ситуация на рынке изменилась и они что-то изменили задним числом, чтобы попилить деньжат. Даже если в муниципалитете и компании договорятся сделать это задним числом, добавить в систему им это не получится, тем сама город усиливает контроль над муниципалитетами.
Друго дело, что это можно и без блокчейна сделать, но как алгоритм вполне рабочий.
Дело не в скорости. Эта функция рано или поздно перестанет работать при обновлении или переносе кода на новые серера. Она обьявлена как deprecated 5.5.0 и убрана в php 7.0.0
1 Они привязаны к конкретному коммиту и именение любого из модулей вызывает необходимость коммита в проджект репозиторий
2 Не все разработчики знают, как с ними работать = больше стоимость разработки
есть еще git subtree с приблизтельно темиже проблемами.
Я не рассматриваю проект репозиторий, как мета приложение, это скорее среда разработки.
Она не должна меняться если происходят внутренние изменения в микросервисах.
Аналогично, я тоже имел ввиду про git clone на машине разработчика.
А если это открытый проект или нет просто доступа к машине разработчика, он удаленный.
docker-project используется, что бы развернуть приложение из нескольких репозиториев и собрать его.
Получается привычный, классический флоу:
git clone
make
и работает
Когда тебе что-то разворачивают на машине. Это ненужная зависимость от людей.
Установить себе на машину нужную версию docker/compose обычно люди могут без проблем.
Если не могут, сами тогда Ансибл уже в помошь, но на уровне установки рантайма, а не самого приложения.
Собирать проект в продакшен докер файле тоже не лучший вариант.
Лучше разделять процессы сборки и упаковки, что бы не тянуть утилиты разработчика в продакшен.
Как из микросервис из репозитория в продакшен — это отдельный процесс опять же.
Мы используем Ansible для провижена серверов, которые образуют облако Mesos/Marathon.
А оркестирует контейнеры уже соотвественно Marathon.
С содержимым Dockerfile эта часть вообще уже никак не связана (как и docker-project). Контейнер проектируется максимально закрытым и условно не важно, где и кто его запускает.
Я не занимаюсь администрированием, Ansible в случае выпадения сервера может автоматом перекинуть контейнеры на другой более свободный сервер?
У нас эта задачу решает Marathon.
Опять же, это не значит вы делаете неправильно. У нас разные проекты, нагрузка и вводные.
Вообще, работающих решений обычно несколько, и что из них лучшее зависит не только от задачи но и исполнителя.
Если рассуждать, что может быть, то как вам такой вариант?
IBM теперь сотрудничает с правительством по этому проекту.
Технология засекречена. А официально они обьявили, что не занимаются этим, чтоб вопросов не было.
В JavaScript еще можно так
С сетевым стеком были проблемы несколько раз. Лучше чем Toolbox но не идеально. При рестарте проекта в композе внешните порты остались заняты для системы, и проект не подымался пока не перезагрузили машину.
Современые головки могут менять геометрию и регулировать высоту полета. Возможно это будет компенсировать эффект.
"У всех код должен отображаться одинаково" — выражение верно только условно. Цвет, размер шрифта, междуквенное растояние, каждый настраивает, как ему угодно. Разве есть задача чтобы все видели одинаковую картинку? Тогда и мониторы у всех должны быть одинаковые.
Я думаю тут подмена понятий и реальная задача здесь, это чтобы соблюдались стандарты кодирования. Например чтобы одинаковый код, сделаный двумя разными разработчиками выглядет одинакого при просмотре в одном редакторе. И в моем случае это соблюдается.
И моя идея была в том что табы используются только для формирования блоков. Тогда каждый может настроить, как визуально сдгивается код, на маленьком экране меньший отступ даст больше видимость кода.
Внутристрочное выравнивание — там нужны проблелы, но там и другая логика выравнивания, там нет бложеных блоков, более того, там по сути "ручная" работа.
Внутристрочное выравнивание это, например, когда несколько строк с присваиванием и хочется выровнять значение по вертикале.
Вопрос к защитникам пробелов.
У каждого программиста свои предпочтения. как должен выглядеть код в его среде разработки.
Кому-то нравится темными буквами на светлом, кому то наоборот. При этом байты кода будут одни и те же, это просто настройки отображения.
Тоже самое с отступами, кому-то нравится сильный отступ. кому-то приятнее. что бы было все рядом.
Если мы используем табы, то все четко, один уровень вложенности соотвествует одному табу. В среде я могу настраивать отображать таб. как два пробела или как четыре. В файле это вcеравно будет один символ таба.
Если же мы используем проблемы, то во-первых надо убедиться, чтобы среда вставляла таб проблемами одиноковой размерности. Во-вторых, я не могу настроить представление кода, как мне удобнее.
В чем же плюс пробелов?
П.С. У меня в компании стандарт кода предписывает использовать проблелы, и я их использую, но реальных плюсов я что-то не вижу.
tiandrey Расскажите. пожалуйста, про железные мощности подробнее.
Сколько физических серверов под что используется.
Под картинки, под базы, редис, ребит, под кубернетис облако, балансеры и т.д.
Да, я так и понял.
У вас идея в корне очень интересная. Я бы конфиги попробовал сделать композер совместимыми, что бы работа была более прозначной.
Через указывание несколько проектов
Конечно, не так изящно как у вас. У нас как-то нет необходимости так проэкты запускать.
Хотя у нас около сотни своих сервисов (несчитая публичные типа мемкеш, редис, мускуль и т.д.) и 25 проект yml файлов.
Сейчас заметил v3 инклюды не поддерживает пока.
Для v3 все выше так же справедливо, однако определение сервиса придется хранить в определении проекта.
Вы эту проблему решили генерацией конфига, как я понимаю.
Мы делаем немного подругому.
Есть принципы похожие с вами, но помойму мы гораздо проще решили.
docker-compose.yml поддерживает инклюды.
Опредение сервиса хранится в репе сервиса.
В репе проекта хранится главный docker-compose.yml в котором прописаны инклюды и переопределены порты если пересекаются у сервисов.
Там же через лейблы прописаны гит ссылки на зависимости (репы сервисов).
Простой улилитой (рнр скрипт собраный в один исполняемый файл) https://habrahabr.ru/post/306384/
Подтягиваются зависимости
Ей же билдятся все зависимости (у нас билд приложение и билд имиджа два разных этапа)
Запуск проекта выглядит приблизительно так
Из плюсов
1 Минимальный уровень входа
2 Нет дополнительных конфиг файлов
3 Нет влияния на код микросервиса
Из минусов
1 Утилита требует установленного php-cli
(Можно переписать на питон или лучше Го, но пока руки не доходят.)
Майнинг не связан с блокчейном.
Это другой из множества внутренних алгоритмов биткоина.
Блокчейн это просто инструмент делающий невозможным скрытно поменять старые записи, если последующие уже известны.
В биткоине это контролируется большинством по вычислительной мощности.
В городе контроль может быть совершенно другой, первое что в голову приходит:
Блокчейн скажет, что хеши не совпадают, а что с этим делать, уже организационный вопрос, в первую очередь.
Распределенный блокчейн — это частный случай.
Как я понимаю, блокчейн в чистом виде — это список обьектов хранящих в себе:
данные, хеш родителя, собственный хеш от данных + хеш родителя.
Что бы вставить данные в такую цепочку "задним" числом, надо пересчитывать все хеши от момента изменения. Это будет невозможно, если хеши уже были известны публично, контролирующий орган заметит.
Например, это бы защитило в ситуации, муниципалитет заключил контрант с компанией на постаку чего-то, потом ситуация на рынке изменилась и они что-то изменили задним числом, чтобы попилить деньжат. Даже если в муниципалитете и компании договорятся сделать это задним числом, добавить в систему им это не получится, тем сама город усиливает контроль над муниципалитетами.
Друго дело, что это можно и без блокчейна сделать, но как алгоритм вполне рабочий.
Дело не в скорости. Эта функция рано или поздно перестанет работать при обновлении или переносе кода на новые серера. Она обьявлена как deprecated 5.5.0 и убрана в php 7.0.0
1 Они привязаны к конкретному коммиту и именение любого из модулей вызывает необходимость коммита в проджект репозиторий
2 Не все разработчики знают, как с ними работать = больше стоимость разработки
есть еще git subtree с приблизтельно темиже проблемами.
Я не рассматриваю проект репозиторий, как мета приложение, это скорее среда разработки.
Она не должна меняться если происходят внутренние изменения в микросервисах.
Он будет переписан на питоне и поэтому будет запускаться без дополнительных записимостей.
Аналогично, я тоже имел ввиду про git clone на машине разработчика.
А если это открытый проект или нет просто доступа к машине разработчика, он удаленный.
docker-project используется, что бы развернуть приложение из нескольких репозиториев и собрать его.
Получается привычный, классический флоу:
git clone
make
и работает
Когда тебе что-то разворачивают на машине. Это ненужная зависимость от людей.
Установить себе на машину нужную версию docker/compose обычно люди могут без проблем.
Если не могут, сами тогда Ансибл уже в помошь, но на уровне установки рантайма, а не самого приложения.
Собирать проект в продакшен докер файле тоже не лучший вариант.
Лучше разделять процессы сборки и упаковки, что бы не тянуть утилиты разработчика в продакшен.
Как из микросервис из репозитория в продакшен — это отдельный процесс опять же.
Мне он не очень нравится.
Мы используем Ansible для провижена серверов, которые образуют облако Mesos/Marathon.
А оркестирует контейнеры уже соотвественно Marathon.
С содержимым Dockerfile эта часть вообще уже никак не связана (как и docker-project). Контейнер проектируется максимально закрытым и условно не важно, где и кто его запускает.
Я не занимаюсь администрированием, Ansible в случае выпадения сервера может автоматом перекинуть контейнеры на другой более свободный сервер?
У нас эта задачу решает Marathon.
Опять же, это не значит вы делаете неправильно. У нас разные проекты, нагрузка и вводные.
Вообще, работающих решений обычно несколько, и что из них лучшее зависит не только от задачи но и исполнителя.
Спасибо за отзыв.
У меня есть в планах переписать ее на питоне. Лишние зависимости никто не любит.
Она нужна была срочно для команды в 20 человек.
Поэтому я взял язык, который знаю лучше. А утилита внезапно всем понравилась.