А военные шлемы под патент попадают?Тоже как бы головной убор, но там технологии дополненной реальности у всяких пилотов уже довольно давно используются. Во всяком случае в кино точно :-)
Проблема подобных статей в том, что они рассказывают как можно удалить гланды ректально сделать какие-то операции нестандартным способом, но никогда не описывают в каких случаях это имеет смысл делать.
Мне вот вообще не очевидно зачем дергать баш из ноды а уж для чтения и создания файла, как это показано в статье и подавно.
Были бы примеры, ценность бы статьи возросла на пару порядков.
А что HTTPS на kremlin.ru уже прикрутили? Что-то не вижу его в списке.
И ладно бы если там только читать можно, но там же еще электронная приёмная есть
letters.kremlin.ru, где чтобы отправить сообщение надо нехило так персданных отправить плейнтекстом.
Есть предположение, что потом его все-равно придется поменять на постоянный имплант, потому что молочные зубы не такие прочные, как постоянные и структура эмали у них пористая. Именно поэтому любой кариес на молочных зубах распространяется очень быстро.
А сделали это, скорее всего, для того, чтобы прикус не уехал.
Задача несколько сложнее, ИМХО. Блик = пересвет. Потеря части информации, причем не только непосредственно на отражающей поверхности, но и вокруг нее на некотором расстоянии из-за засветки. Т.е. большинство изображений восстановить не получится в принципе, потому что там только #ffffff и больше нету ничего. Ну, или это будет тупо додумывание нейросетью до какого-то среднестатистического результата ничего не имеющего с реальностью. Мне кажется, что тут, скорее, с видео прокатит, чем с фотографией. Потому что некорректность с логической точки зрения (вдруг там нейросеть крокодила нарисует), одного кадра практически не заметна будет.
Это немного другое, тут осознанный риск. Или мы выпускаем к Рождеству, или то, что мы делали полгода уже нафиг никому не нужно. В таком ключе оно уже немного подругому звучит, неправда ли?
Любая новая фича это всегда баланс между «улучшить что-то и нам будут платить больше», «не попасть в ожидания и платить будут меньше» и «случайно всё сломать нафиг, потому что задеплоили с багами»
Удивительно другое, что такая фигня творится обычно только на клиентских проектах. Когда команда разрабатывает свой продукт, то менеджер продукта обычно так не делает. Потому что когда у тебя тысяч 100 платящих пользователей, которые из-за косяков в новом релизе могут внезапно перестать быть таковыми, начинаешь очень хорошо все продумывать.
И ещё момент, очень часто разработчики не понимают, что руководитель проекта это функциональная роль, а не уровень подчинённости. РП не является начальником разраба. Почему разраб не стесняется своему коллеге на код ревью указывать на плохие места и не аппрувить пулл-реквест, а послать менеджера проекта думать дальше стесняется?
Мне не очень нравится подход из yii2, он как раз делает приложение безумно связным.
На наших проектах правила следующие:
Клиентский код никогда не работает напрямую с провайдером данных. Используйте для этого репозитории.
Если у вас есть сущность Book, то должен быть BookRepository, который в идеале реализует BookRepositoryInterface с описанием всех нужных методов по получению этих самых книг. Т.е. отделяйте клиентский код от деталей реализации. Тут тонкий момент, что если в одном месте клиентского кода нужно получить что-то из репозитория, то проще прописать это в методе репозитория, вроде getTopTenBooks(), а вот если фильтры планируются разные и в разных сочетаниях, то тут уже подход с фильтрами.
По поводу фильтров, мы юзаем https://github.com/Happyr/Doctrine-Specification
У репозитория есть метод match(), в который можно передать массив фильтров, а сами фильтры описаны в классе BookFilters и представляют из себя набор методов, возвращающих спецификацию. Например activeBook(), userBook(User $user) и т.п.
В клиентском коде их можно комбинировать и всей кучей передать в репозиторий, чтобы получить набор книг по кастомному фильтру:
В клиентском коде это будет примерно так выглядеть:
$books = $this->$bookRepository->match([BookFilters::activeBook(), BookFilters::userBook($user)]);
Плюсы:
клиентский код полностью отделен от реализации получения данных
в клиентском коде все фильтры имеют человекопонятные названия, т.е. мы мысли доменными категориями, а не категориями реализации
Минусы:
иногда фильтров может не хватить. Тогда в класс BookFilters придется чего-нить дописать. Но в этом я не вижу беды, потому что, во-первых, можно не дописывать, а отнаследоваться, а, во-вторых, все методы статические и BookFilters это, по сути, просто библиотека и дописывание туда новых методов не сделает весь подход менее SOLID
А использование слова "Black" контексте негативного экрана никого уже не оскорбляет?
А военные шлемы под патент попадают?Тоже как бы головной убор, но там технологии дополненной реальности у всяких пилотов уже довольно давно используются. Во всяком случае в кино точно :-)
удалить гланды ректальносделать какие-то операции нестандартным способом, но никогда не описывают в каких случаях это имеет смысл делать.Мне вот вообще не очевидно зачем дергать баш из ноды а уж для чтения и создания файла, как это показано в статье и подавно.
Были бы примеры, ценность бы статьи возросла на пару порядков.
И ладно бы если там только читать можно, но там же еще электронная приёмная есть
letters.kremlin.ru, где чтобы отправить сообщение надо нехило так персданных отправить плейнтекстом.
А доступ будут давать только при условие отсутствия задолженности по ЖКХ
А сделали это, скорее всего, для того, чтобы прикус не уехал.
Задача несколько сложнее, ИМХО. Блик = пересвет. Потеря части информации, причем не только непосредственно на отражающей поверхности, но и вокруг нее на некотором расстоянии из-за засветки. Т.е. большинство изображений восстановить не получится в принципе, потому что там только #ffffff и больше нету ничего.
Ну, или это будет тупо додумывание нейросетью до какого-то среднестатистического результата ничего не имеющего с реальностью.
Мне кажется, что тут, скорее, с видео прокатит, чем с фотографией. Потому что некорректность с логической точки зрения (вдруг там нейросеть крокодила нарисует), одного кадра практически не заметна будет.
Т.е. рассказывать про "Базы данных для малышей" надо обязательно на примере одной из самых люто-коммерческих энтерпрайзных БД Oracle?
Любая новая фича это всегда баланс между «улучшить что-то и нам будут платить больше», «не попасть в ожидания и платить будут меньше» и «случайно всё сломать нафиг, потому что задеплоили с багами»
Удивительно другое, что такая фигня творится обычно только на клиентских проектах. Когда команда разрабатывает свой продукт, то менеджер продукта обычно так не делает. Потому что когда у тебя тысяч 100 платящих пользователей, которые из-за косяков в новом релизе могут внезапно перестать быть таковыми, начинаешь очень хорошо все продумывать.
И ещё момент, очень часто разработчики не понимают, что руководитель проекта это функциональная роль, а не уровень подчинённости. РП не является начальником разраба. Почему разраб не стесняется своему коллеге на код ревью указывать на плохие места и не аппрувить пулл-реквест, а послать менеджера проекта думать дальше стесняется?
Какие данные может получить от этого гугл и как сопоставить их с моим обычным профилем?
Можно еще быстрее:
docker run -d --name some-postgres --network some-network -e POSTGRES_PASSWORD=secret -e POSTGRES_USER=redmine postgres
docker run -d --name some-redmine --network some-network -e REDMINE_DB_POSTGRES=some-postgres -e REDMINE_DB_USERNAME=redmine -e REDMINE_DB_PASSWORD=secret redmine
А потом проксируйте с уже установленного nginx на порт nginx
Мне не очень нравится подход из yii2, он как раз делает приложение безумно связным.
На наших проектах правила следующие:
Клиентский код никогда не работает напрямую с провайдером данных. Используйте для этого репозитории.
Если у вас есть сущность Book, то должен быть BookRepository, который в идеале реализует BookRepositoryInterface с описанием всех нужных методов по получению этих самых книг. Т.е. отделяйте клиентский код от деталей реализации. Тут тонкий момент, что если в одном месте клиентского кода нужно получить что-то из репозитория, то проще прописать это в методе репозитория, вроде getTopTenBooks(), а вот если фильтры планируются разные и в разных сочетаниях, то тут уже подход с фильтрами.
По поводу фильтров, мы юзаем https://github.com/Happyr/Doctrine-Specification
У репозитория есть метод match(), в который можно передать массив фильтров, а сами фильтры описаны в классе BookFilters и представляют из себя набор методов, возвращающих спецификацию. Например activeBook(), userBook(User $user) и т.п.
В клиентском коде их можно комбинировать и всей кучей передать в репозиторий, чтобы получить набор книг по кастомному фильтру:
В клиентском коде это будет примерно так выглядеть:
$books = $this->$bookRepository->match([BookFilters::activeBook(), BookFilters::userBook($user)]);
Плюсы:
Минусы: