• Red Hat заменяет Docker на Podman
    0
    Так и в чём плюсы?
  • Red Hat заменяет Docker на Podman
    +1
    А я вот тоже не понял, чем оно отличается от docker для пользователей? Какие плюсы?
    Только очень много раз прочёл «стандарт».
  • Резервное копирование большого количества разнородных web-проектов
    0
    s3fs в docker работает, проверил.
    Только словил странную ошибку о том, что точка монтирования /mnt/s3 занята, когда два контейнера одновременно запустили бэкап при запуске… видимо это из-за того что /dev/fuse прокинут в контейнеры для корректной работы FUSE.
  • Резервное копирование большого количества разнородных web-проектов
    0
    Про «по всем канонам CI/CD» — а автотестов то в репозитории нет, они где-то в другом месте находятся? Если их нет, то CI/CD становится опасной штукой, которая может распространять беду.
  • Резервное копирование большого количества разнородных web-проектов
    +1
    Сделал версию с дополнительными настройками для S3 и отправкой через сторонние SMTP сервера github.com/Sovetnikov/nxs-backup
  • Резервное копирование большого количества разнородных web-проектов
    0
    Про сторонние S3 очень даже полезная фича в свете импортозамещения :)
    А s3fs в docker ровно работает?
  • Резервное копирование большого количества разнородных web-проектов
    0
    Не туда
  • Резервное копирование большого количества разнородных web-проектов
    +1
    Интересная утилита, но про настройку хранилища S3 ничего нет в документации.
    В документации отмечено, что пользователю надо самостоятельно настраивать s3fs, напишите хотя бы вкратце что и как. Особенно интересно как подключиться не к AWS серверам S3, а к сторонним.
    Разберёмся конечно, но как-то «волшебство» утилиты начинает биться об реальность :)

    И я так понимаю, что нельзя настроить внешний SMTP аккаунт для отправки E-mail оповещений?

    И что за формат конфигурационных файлов? Это yml?
  • Мифы про инфраструктуру в облаке: с какой неграмотностью мы сталкиваемся в России каждый день
    0
    Плюс есть финответственность на уровне SLA

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

    Если бы вы были «Корп софт» и из-за вас на 3 дня упал Битрикс24, вы бы им оплатили маркетинговую компанию для поддержания репутации?

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

    Да вы сами все данные отдадите когда попросят, сделаете из «облака» обычный HDD и отдадите.

    Что-то маркетологи ваши перестарались в статье… перегнули.
  • ААА! Пришло время переписывать на .NET Coreǃ
    –1
    Я не о том, вы бы ещё клиентам предложили Windows Server в виртуализации Linux запустить, если они сервера на Windows не хотят. Вы им тогда и лицензии на vmware продадите, и саппорт виртуализации, и саппорт на Windows сервер в виртуализации… уже я даже сбился со счёт на сколько надо profit множать в таком случае.
    Это всю шутки конечно, но с долей правды.

    И всё же «масло масляное» — от Microsoft вы так заказчиков не сбережете, «они» всёравно будут руководить вами :)

    Microsoft всегда имел хороший маркетинг для программистов и это вот «ВСЁ» с open source и linux на фоне прошлых «неудачных» и выгодных для Microsoft технологий, должно насторожить тревожного разработчика.
  • ААА! Пришло время переписывать на .NET Coreǃ
    +1
    А у вас СУБД «правильная»?
    И только не говорите заказчику, что вы используете технологии Microsoft.
    В «не только в госсекторе» мне кажется импортозамещение началось уже сразу с появлением этого «не только в госсекторе» :)
  • ААА! Пришло время переписывать на .NET Coreǃ
    0
    Ясно.
    Они просто не умеют их поддерживать — просто продайте им ещё и саппорт для Windows серверов :)
    profit x 2
  • Moby/Docker в продакшене. История провала
    0
    Напишите конкретнее, про свой опыт.
  • Moby/Docker в продакшене. История провала
    +1
    Честно не понял откуда всё это вылезло.

    Из собственной личной практики:
    1. Использую несколько лет docker версии 1.12 и 17 в нескольких проектах.
    Везде Ubuntu 14 или 16 с 4 версией ядра.
    Один проект так вообще динамически создаёт контейнеры и постоянно их останавливает, запускает… порядка 1000 контейнеров динамически создаваемых.
    Везде aufs.
    Всё работает… если и бывают какие-то проблемы именно со сотороны докера, то они очень редки.

    2. Удаление образов… не сталкивался с такой проблемой, места на одном сервера впритык а контейнеры бывало часто перестраивались… удаляется всё нормально.

    3. AUFS нестабилен? Не заметил.

    4. Про кривые ключи и мировое падение это перегиб какой-то. Ну уберите репозиторий из иточников, ставьте напрямую из файлов docker… Автоматиеский деплой на то и нужен, чтобы легко можно было всё поправить.

    5. Про свой реестр образов не скажу ничего, не пользовался.

    6. Релизный цикл у докера нормальный, всё живо, ошибки бывают но исправляются.

    7. Хранение данных в докере — даже мыслей никогда не возникало хранить какие-то данные в контейнерах докера, все данные на хосте, а в докер только volume пробрасывается. Кто им посоветовал данные в докере вообще хранить…

    Такое чувство, что авторы статьи просто не особо задумывались когда начали применять docker… и наступили на грабли, которые можно найти везде.
  • История программиста, создавшего компанию «Maxilect», на 100% работающую удаленно
    0
    А чуть подробнее?
    Прямо вот всё тоже самое?
    А как вы понимаете, может кандидат работать самостоятельно или нет?
  • История программиста, создавшего компанию «Maxilect», на 100% работающую удаленно
    0
    Больше всего интересно как вы отбираете кандидатов на работу?
    В чём отличия от очных вакансий?
  • История программиста, создавшего компанию «Maxilect», на 100% работающую удаленно
    0
    Именно принципиально не рассматривают должность с удаленным присутствием работодатели для вашей специальности?
  • ААА! Пришло время переписывать на .NET Coreǃ
    +5
    А зачем мы давно хотим перелезть на .NET Core?
  • Одних тестов недостаточно, нужна хорошая архитектура
    0
    1. А наличие интерфейсов для всех свойств статически проверяется разве? Тоже только при запуске. Или вы о чём?
    Про не нравится бессмыслено что-либо писать, вкус и цвет…
    2. Как ошибиться? Кто-то намеренно скроет свойство от рефлексии?
    3. В том, что не надо копипастить интерфейсы и добавлять стратегии в массив. Поди вспомни через Н недель где там этот интерфейс найти.
    И не надо прописывать строкой название свойства… это утомительно :)
    4. С производительностью не будет проблем только если вы сгенерируете динамически код IsEquivalent, который рефлексию не будет трогать (динамически сгенерируете всё то, что вы предложили с интерфейсами).
    5. А ещё кодогенерацию можно использовать, которая все эти интерфейсы по IOrderHistoryItem сгенерирует. А методы Is{property}Equivalent будут выкидывать исключения, пока не будту вручную реализованы. Тут вообще «откиньте спинки ваших кресел».

    А ещё в сообщении исключения об отсутствии Is{property}Equivalent разработчику можно было бы давать шаблон для релазиции в виде текста. Скопировал его и реализовал, даже руками название метода писать не надо.
  • Одних тестов недостаточно, нужна хорошая архитектура
    0
    Ещё как варинт можно реализовать тест, который через метаданные проверит, что у класса для каждого свойства есть метод Is{property}Equivalent.
    И так же реализовать метод IsEquivalent, который все эти методы будет дёргать.

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

    И ещё IsEquivalent можно будет научить ругаться, если всё же кто-то не запуская тестов выложил сборку на продакшн.
  • Регулярные выражения для самых маленьких
    +1
    Каждый раз глядя на своё программное решение с регулярными выражениями для разбора строк, чувствую, что единственное полезное выражение это «что-то (\d+)» и ничего другого лучше не писать.

    Очень сложно поддерживать регулярные выражения в программе, всегда в первоначальный «простой» вариант вносятся изменения и усовершенствования. В итоге получается мини-монстр.
    Как ящик пандоры — такие надежды всегда, а получается не совсем то.

    На мой взгляд сама история появления регулярных выражений определяет их пределы использования. Они же родились в научной среде как некое теоретическое изыскание вылившееся в такой вот язык (утрирую конечно) и на практике оно впервые появилось в текстовом редакторе, чтобы можно было делать более сложные текстовые замены. И это стихия регулярных выражений.
    Ты сделал замену регулярным выражением и сразу оценил результат, если он тебя устроил то регулярное выражение может кануть в забытие, т.к. оно выполнило свою роль. Это действительно бывает полезно.
  • Путь разработчика ASP.NET → PHP
    0
    Ну я конечно про Python говорю в большей степени, неужени в PHP так всё плохо?
    Одних только готовых компонент к Django целый вагон, комплексное решение можно сделать много быстрее.
    Просто есть готовые, качественные, open-source решения, которые ты можешь взять и использовать.
  • Путь разработчика ASP.NET → PHP
    +1
    Вы не написали о своём опыте работы на .NET, это сильно меняет контекст статьи.
    И почему вы решили сменить стек.

    Разница в языках мне кажется совершенно не важна — важно что вы перешли на стек где большое open-source комьюнити. В сравнении с .NET это огромный плюс, т.к. для .NET попробуй нади хороший сторонний компонент (пусть платный), который решит твою задачу.

    Потоков дейстивтельно нехватает после C#, но всё решаемо если с головой подходить.

    Я правда говорю с точки зрения перехода .NET C# (9 лет) -> Python (3 года).
  • Настройка Minio и Nginx для RoR приложения
    0
    По прямой ссылке в minio с временным ключём или по прямой ссылке через nginx в директорию с файлами minio?
  • Настройка Minio и Nginx для RoR приложения
    0
    А как у вас реализована отдача загруженных в minio файлов клиентам?
  • Блеск и нищета Искусственного Интеллекта
    0
    А в причине не разобрались?
    Очень похоже, что без нормализации (а вы вроде бы её не делаете после перемешивания) функции активации не отрабатывают так как прежде.

    Выложите полный код пожалуйста.
    Непонятно, обучение происходит на исходных нормализованных данных, а потом вы сети скармливаете ненормализованные данные?
  • Запуск/отладка Python скриптов в контейнерах LXC/LXD из под VS Code
    0
    Всё замечательно, но с осторожностью отнеситесь к продуктам Microsoft.
    Много лет работал на стеке .NET и знаю что они работают в стиле Паниковского: «я вас всех продам, куплю, и снова продам, но уже по более дорогой цене».

    За последние годы они конечно одумались и сильно ломанулись в сторону Linux и Open Source, но не очень верится что это они делают для людей.
    Есть другие проверенные решения, например pydevd и его поддерживает не одно IDE.
  • ICO: хайп уйдёт, а мы останемся, или время против токенов
    +3

    Доходность от 100%, отсутствие юридических обязательств, модные слова, где-то же это было.

  • Гибкая система управления доступом на уровне объектов-записей
    +1
    Итого в вашем решении есть плюсы, которых нет в обозначенных готовых решениях:
    1. Реализован доступ «Видеть» с поддержкой в админке (чего я не нашел в своё время в уже готовых решениях).
    2. Унифицировано решение для фильтрации объектов в ModelAdmin.changelist_view на основе доступов (через ModelAdmin.get_query_set).

    Но настораживает ваше решение сделать свой слой управления доступами поверх стандартного механизма Джанго, механизм управления доступами Джанго подключается к вашему, а не наоборот. Это может привести к сложностями при использовании других готовых решений для Джанго… если стороннее приложение будет проверять доступ через has_perm Джанго, оно ведь пролетит мимо доступа заданного правилами в вашем решении?
  • Гибкая система управления доступом на уровне объектов-записей
    0

    Так уже есть Django-rules https://github.com/dfunckt/django-rules, который как раз предоставляет возможность управления доступами используя правила заданные в коде.
    rules + guardian дают гибкую связку для доступов, просто не надо в guardian задавать явный доступ на все имеющиеся объекты.


    Из статьи кажется, что ваш проект может управлять доступом на уровне полей модели, хотя это не так (поправьте, может ошибаюсь). В вашем примере, на странице проекта и в репозитории, вы используете стандартный рецепт с модифицированными get_list_display и get_fieldsets в UserAdmin именно для вашего случая:


        def get_fieldsets(self, request, obj=None):
            fieldsets = list(super(AccessUserAdmin, self).get_fieldsets(request, obj)) or []
            if request.user.is_superuser:
                return fieldsets
            if not obj:
                return fieldsets
            if obj.pk != request.user.pk:
                return self._fieldsets_exclude(fieldsets,['password', 'email'])
            return self._fieldsets_exclude(fieldsets,['is_superuser'])

    И зачем нужен AccessManager, когда джанго поддерживает в своём API проверку доступа на уровне объектов? Как в User.has_perm так и в has_perm для бэкендов аутентификации и авторизации (с версии Django 1.7).
    https://docs.djangoproject.com/en/1.11/ref/contrib/auth/#django.contrib.auth.models.User.has_perm
    https://docs.djangoproject.com/en/1.11/ref/contrib/auth/#django.contrib.auth.backends.ModelBackend.has_perm

  • Comment from a drafted post.
  • Визуализация интеграционных приложений
    +2

    Что из нарисованных диаграм не позволяет изобразить Uml? Uml достаточно гибкий язык и его нотация уже минимально знакома профессионалам.

  • Автоматическое развёртывание Django из GitLab
    0
    Это логично и понятно, а про что darken99 писал я не понял…
  • Автоматическое развёртывание Django из GitLab
    0
    Я и пишу, что «Два инстанса сразу не должны быть доступны для запросов от клиента.»
  • Автоматическое развёртывание Django из GitLab
    0
    1. Это понятно

    2. nginx ведь не вернет ошибку, он внутри обработает запрос на доступный uwsgi. Клиент увидит только результат того uwsgi, который работает. Ошибки не увидит.
    Попытка коннекта на закрытый порт это мне кажется всего несколько миллисекунд, а то и меньше.

    А в случае не идемпотентных запросов, что может произойти?
    Два инстанса сразу не должны быть доступны для запросов от клиента.
    Но получается, что всёравно надо будет портами играться… надо ждать пока новый инстанс запустится, гасить порт старого, открывать порт нового.
    В общем понятно.

    3. Хранение исходных кодов в data volume (или в host директории) или в контейнере это разные стратегии применяемые в разных условиях (проект, команда, организация, куда идёт развертывание и т.п.).
    virtualenv vs docker? Да ну его этот virtualenv…
    uwsgi прекрасно работает, зачем гонять образы, если можно заменить только код и пользоваться его возможностями.
  • Автоматическое развёртывание Django из GitLab
    0
    Тут варианты:
    1. nginx+uwsgi в одном контейнере — да, тут кластер или маршрутизацией управлять.

    2. nginx отдельно (отдельный контейнер или непосредственно на сервере) от uwgi — в этом случае можно ведь настроить nginx failover с proxy_next_upstream и нулевым timeout?
    Спрашиваю, потому что на практике не делал, но думаю что работает.

    3. Исходные коды храняться в data volume (а не в инстансе как в пп.1 и 2), который цепляется в инстанс uwsgi — тут можно использовать возможность uwsgi последовательно перезагружать воркеры, у них довольно подробная инструкция есть на эту тему.

    Всё это конечно с допусками:
    — Нет изменений в БД, которые не позволяют использовать предыдущую кодовую базу с новой версией БД.
    — Время простоя на перезагрузку конфигурации nginx считаем незначительной и отдельный балансировщик делать не будем :)

    Или что-то не так?
  • Автоматическое развёртывание Django из GitLab
    0
    В шагах .gitlab-ci.yml можно выбирать, при коммите в какой бранч выполнять шаг.
    И соответственно разные шаги для разных бранчей с разными скриптами.

    Вот тут подробно https://habrahabr.ru/company/softmart/blog/310502/
    Вот тут официальная документация https://docs.gitlab.com/ce/ci/yaml/README.html#only-and-except
  • Автоматическое развёртывание Django из GitLab
    0
    До zero downtime развертывания не планируете довести? :)
    Было бы тоже интересно.
  • Автоматическое развёртывание Django из GitLab
    +1
    «через переменные, шаблоны и dockerize» — немного непонятно.
    Если мне надо деплоить вместе с кодом проекта конфиг nginx сайта проекта, то как оно должно быть устроено правильнее?
    И где должна храниться конфигурация?