Pull to refresh
6
0

User

Send message

Если рассуждать, что может быть, то как вам такой вариант?
IBM теперь сотрудничает с правительством по этому проекту.
Технология засекречена. А официально они обьявили, что не занимаются этим, чтоб вопросов не было.

В JavaScript еще можно так


for (i in someArray) {
    x = someArray[i];
}

С сетевым стеком были проблемы несколько раз. Лучше чем Toolbox но не идеально. При рестарте проекта в композе внешните порты остались заняты для системы, и проект не подымался пока не перезагрузили машину.

Современые головки могут менять геометрию и регулировать высоту полета. Возможно это будет компенсировать эффект.

"У всех код должен отображаться одинаково" — выражение верно только условно. Цвет, размер шрифта, междуквенное растояние, каждый настраивает, как ему угодно. Разве есть задача чтобы все видели одинаковую картинку? Тогда и мониторы у всех должны быть одинаковые.


Я думаю тут подмена понятий и реальная задача здесь, это чтобы соблюдались стандарты кодирования. Например чтобы одинаковый код, сделаный двумя разными разработчиками выглядет одинакого при просмотре в одном редакторе. И в моем случае это соблюдается.


И моя идея была в том что табы используются только для формирования блоков. Тогда каждый может настроить, как визуально сдгивается код, на маленьком экране меньший отступ даст больше видимость кода.


Внутристрочное выравнивание — там нужны проблелы, но там и другая логика выравнивания, там нет бложеных блоков, более того, там по сути "ручная" работа.


Внутристрочное выравнивание это, например, когда несколько строк с присваиванием и хочется выровнять значение по вертикале.

Вопрос к защитникам пробелов.


У каждого программиста свои предпочтения. как должен выглядеть код в его среде разработки.
Кому-то нравится темными буквами на светлом, кому то наоборот. При этом байты кода будут одни и те же, это просто настройки отображения.


Тоже самое с отступами, кому-то нравится сильный отступ. кому-то приятнее. что бы было все рядом.
Если мы используем табы, то все четко, один уровень вложенности соотвествует одному табу. В среде я могу настраивать отображать таб. как два пробела или как четыре. В файле это вcеравно будет один символ таба.


Если же мы используем проблемы, то во-первых надо убедиться, чтобы среда вставляла таб проблемами одиноковой размерности. Во-вторых, я не могу настроить представление кода, как мне удобнее.


В чем же плюс пробелов?


П.С. У меня в компании стандарт кода предписывает использовать проблелы, и я их использую, но реальных плюсов я что-то не вижу.

tiandrey Расскажите. пожалуйста, про железные мощности подробнее.


Сколько физических серверов под что используется.
Под картинки, под базы, редис, ребит, под кубернетис облако, балансеры и т.д.

Да, я так и понял.


У вас идея в корне очень интересная. Я бы конфиги попробовал сделать композер совместимыми, что бы работа была более прозначной.

Через указывание несколько проектов


docker-project update -f pro-a.yml
docker-project update -f pro-b.yml
docker-compose -f pro-a.yml -f pro-b.yml up

Конечно, не так изящно как у вас. У нас как-то нет необходимости так проэкты запускать.
Хотя у нас около сотни своих сервисов (несчитая публичные типа мемкеш, редис, мускуль и т.д.) и 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.


Опять же, это не значит вы делаете неправильно. У нас разные проекты, нагрузка и вводные.
Вообще, работающих решений обычно несколько, и что из них лучшее зависит не только от задачи но и исполнителя.

Спасибо за отзыв.


У меня есть в планах переписать ее на питоне. Лишние зависимости никто не любит.


Она нужна была срочно для команды в 20 человек.
Поэтому я взял язык, который знаю лучше. А утилита внезапно всем понравилась.

1

Information

Rating
Does not participate
Location
Россия
Registered
Activity