Мде. А где можно узнать степень достаточности этого diversity для проведения конференции?
Ну допустим наберем докладчиков всех полов, пусть даже единственная желающая женщина выступает с неактуальной темой. Но вот уже с цветом кожи будет посложнее. Мы ведь не хотим кого то обделить, у каждого должен быть свой представитель среди спикеров.
Так что нужно составить таблицу различаемых оттенков кожи и просить кандидатов указать свой в заявке. Это может немного озадачить желающих, но еще сложнее будет с сексуальной ориентацией, некоторые не желают о ней распространятся.
Потом, конечно, нужно будет не забыть позвать в спикеры представителей всех религиозных учений и представителей всех возрастов.
И вот еще какой вопрос, например если мы позвали католическую темнокожую женщину средних лет, это засчитывается во все категории по отдельности или необходимы все вариации, и раз позвали католическую темнокожую женщину средних лет, то уж извольте и позовите католическую светлокожую женщину средних лет и не средних лет и тд.
Кажется единственным решением задачи будет заявить спикерами всё ныне живущее население планеты. Правда таким образом можно оскорбить уже умерших и еще не рожденных…
А если серьезно, требование разнообразия в этом вопросе — это натуральная дискриминация так как реализуется через выделение признаков и классификации людей по ним. Правильным решением без дискриминаций, было бы не обращать на эти признаки никакого внимания.
Не удивлюсь если на деле они делают отложенную отправку ответа на +3-5 недель.
Писал в РКН 19.04.18 (во время блокировок), получил ответ 11.05.18:
Текст ответного письма (можно не читать, под копирку)
Здравствуйте.
Уведомляем Вас о том, что Решением Таганского районного суда г. Москвы от 13.04.2018 по делу № 2-1779/2018 на Роскомнадзор и иных лиц возлагается обязанность прекратить создание технических условий для приема, передачи, доставки и (или) обработки электронных сообщений пользователей сети «Интернет», распространяемых посредством информационных систем и (или) программ для электронных вычислительных машин, функционирование которых обеспечивает Telegram Messenger Limited Liability Partnership.
Указанный Вами IP адрес входит в подсеть 165.227.0.0/16, используемую для обеспечения функционирования коммуникационных интернет-сервисов указанного организатора распространения информации в сети «Интернет», о чем в адрес провайдера хостинга было направлено соответствующее уведомление.
В целях исключения сетевого адреса из выгрузки хостинг-провайдеру необходимо направить сообщение о принятых мерах по прекращению создания технических условий функционирования приложения Telegram. На основании такого сообщения Роскомнадзором проводится проверка и после подтверждения этого факта, доступ к соответствующему сетевому адресу и располагающимся на нем информационным ресурсам возобновляется.
За дополнительной информацией рекомендуем Вам обратиться к обслуживающему Вас провайдеру хостинга и (или) оператору связи.
Следует отметить, что российские провайдеры хостинга в подавляющем большинстве случаев соблюдают требования российского законодательства и крайне редко допускают блокировку своих ресурсов.
Консультант горячей линии по вопросам
реализации статей 15.1-15.3 Федерального закона
«Об информации, информационных
технологиях и о защите информации»
Кстати, тогда тоже хотел опубликовать на хабре, не прошло модерацию, но не суть. Как видно, спустя год шаблон у них не поменялся, разница только в адресах. И всё так же предлагается два варианта: 1 — давить на хостера; 2 — переезжать к РФ провайдерам.
Фича для удобства запоминания и ввода говорите? Если первый и третий символ всегда одинаковые, не удобнее ли было бы запоминать и вводить трехзначный код?
Вопроса не было. Просто хотел сказать, что правильнее было бы отделить брокера очереди от воркеров. Кстати, возможно, конечно, в вашем случае есть какие то сложности с тем чтобы сделать так, но php монолит может вполне себе на той же ноде гоняться и как воркер (не подходит если нод с воркерами нужно больше, чем есть нод с приложением).
В вашем случае задача была успешно решена, просто дальше не совсем ясно как этот подход развивать. Во первых как масштабировать, во вторых, всё таки это получился вырожденный случай, например, что делать если понадобится помещать в очередь и другие задачи, посложнее, для выполнения которых нужна будет бизнес логика реализованная в монолите?
Так ведь вынос хранения очереди в отдельное, специальное место — стандартное решение. Есть же всякие специально для этих целей предназначенные кролики, кафки, beanstalkd, Amazon SQS. В итоге получаем не только хранимую очередь вне зависимости от падений приложения, но и возможность легко масштабироваться добавлением воркеров работающих с этой очередью. Воркеры эти могут жить на разных машинах, причем хоть в монолите, хоть отдельно и на другом ЯП.
В том то и дело, что идет движение в сторону более строгих типов. То есть то что описывает RFC будет работать на уровне языка и позволит более продвинуто описывать и контролировать типы, а не как вы предположили:
Работать я так понимаю, это будет на уровне IDE, и никак не будет если я правлю код в блокнотике, меня там ничто не ограничит и не остановит.
А то что описывается в этой статье — применение для тех же целей дополнительных инструментов (так как пока на уровне языка таких возможностей нет). Статический анализатор прогоняет проверки, например, на каждый Pull Request, в случае обнаружении проблем код разворачивается. То есть это исключительно метод контроля качества кода.
Таким образом в исходном сообщении вы половину сочинили, половину потратили на бессмысленные придирки к термину, который у других никаких проблем в понимании не вызывает.
Вам в общем случае не должно требоваться обращение к третьему уровню вложенности стейта.
Если это произошло, то у вас что-то пошло не так как минимум в рамках SRP
Хм, извините, но причем тут я…
Ну если уж на то пошло, то я бы и не стал на этом архитектуру делать. Вытащить что-то из ответа апи, мапнуть данные в другую структуру, форматирование во вьюхе — вон там это может пригодиться. При работе с тупыми объектами данных.
Вот ожидаете вы получить объект с вложенным объектом и обратиться к какому нибудь свойству последнего. Но так сложилось, что в обоих случаях вместо объекта может быть и нул. И вот, предлагается сахарок, чтобы упростить конструкции с проверками на нул.
В асинхронщину сам язык вроде как не лезет. Сторонние разработки. Основной вектор как мне кажется на добавление «строгих» возможностей, улучшение стат анализа.
Все отличия что вы описываете прекрасно объясняются интеллектуальным превосходством одних видов над другими. Более интеллектуальные животные демонстрируют более сложные и вариативные формы поведения. Так можно взять не только «шимпанзе — человек», но любую другую пару животных и произвести на этом разнообразные, но ложные логические построения, например, о свободе воли или её отсутствии.
Мне, как заказчику, совершенно все равно на те 18000 деталей и нюансы конструкций. В автомобиле я вижу решение своей конкретной задачи. Добраться из пункта а в пункт б.
Если вам нужен автомобиль, чтобы «добраться из пункта а в пункт б», скорее всего лучше всего будет вызвать такси. Или, возможно, купить готовое авто, если это надо делать регулярно. Обычно не нужно заказывать разработку автомобиля для решения этой задачи.
Другими словами, вы не должны ставить задачу «сделать копию автомобиля». Вы должны объяснить из какой точки в какую вы планируете добраться, разово или регулярно, как быстро, насколько комфортно, с каким бюджетом и тп. То есть описать свою проблему. И тогда специалисты смогут предложить вам наилучшее ее решение.
Часто задаю такого рода вопросы. Исполнитель заведомо имеет более глубокое погружение в задачу, возможно он всё учел и осознано не использовал наиболее, как мне кажется, очевидное или правильное решение.
Таким образом, если исполнитель не знал или что-то забыл, то теперь он узнал/вспомнил, а если у него есть аргументированное объяснение, то, возможно, что-то полезное узнаю я.
Тут, нигде. Расскажите лучше как будет происходить управление анимацией и где вы разместите логику различных боевых правил. Например: класс монстра не восприимчив к магическим атакам; броня монстра имеет бонус против стального оружия; атака героя бьет по площади; атака героя имеет свойство «вампиризм» против «живых» противников и тп.
А такой алгоритм проще сделать на основании информации лидара.
Почему это? Часть ПО отвечающая за принятие решений вообще может не зависеть от части отвечающей за «зрение» (распознание, класификацию, вычисление расстояния, скорости, вектора и тп). То есть что данные с лидара, что с камер после обработки в таком случае будут приводится к одному формату.
Я думаю что в этих иллюзиях (в том числе с кубиком) объемность и тени вообще не причем, скорее всего дело в том, что мозг воспринимает элемент более светлым в темном окружении и более темным в более светлом окружении (что то типа автоповышения контраста для лучшего различения?) или же возможно он пытается выполнить сравнение цвета элементов не напрямую, а относительно окружения.
Ну допустим наберем докладчиков всех полов, пусть даже единственная желающая женщина выступает с неактуальной темой. Но вот уже с цветом кожи будет посложнее. Мы ведь не хотим кого то обделить, у каждого должен быть свой представитель среди спикеров.
Так что нужно составить таблицу различаемых оттенков кожи и просить кандидатов указать свой в заявке. Это может немного озадачить желающих, но еще сложнее будет с сексуальной ориентацией, некоторые не желают о ней распространятся.
Потом, конечно, нужно будет не забыть позвать в спикеры представителей всех религиозных учений и представителей всех возрастов.
И вот еще какой вопрос, например если мы позвали католическую темнокожую женщину средних лет, это засчитывается во все категории по отдельности или необходимы все вариации, и раз позвали католическую темнокожую женщину средних лет, то уж извольте и позовите католическую светлокожую женщину средних лет и не средних лет и тд.
Кажется единственным решением задачи будет заявить спикерами всё ныне живущее население планеты. Правда таким образом можно оскорбить уже умерших и еще не рожденных…
А если серьезно, требование разнообразия в этом вопросе — это натуральная дискриминация так как реализуется через выделение признаков и классификации людей по ним. Правильным решением без дискриминаций, было бы не обращать на эти признаки никакого внимания.
Писал в РКН 19.04.18 (во время блокировок), получил ответ 11.05.18:
Уведомляем Вас о том, что Решением Таганского районного суда г. Москвы от 13.04.2018 по делу № 2-1779/2018 на Роскомнадзор и иных лиц возлагается обязанность прекратить создание технических условий для приема, передачи, доставки и (или) обработки электронных сообщений пользователей сети «Интернет», распространяемых посредством информационных систем и (или) программ для электронных вычислительных машин, функционирование которых обеспечивает Telegram Messenger Limited Liability Partnership.
Указанный Вами IP адрес входит в подсеть 165.227.0.0/16, используемую для обеспечения функционирования коммуникационных интернет-сервисов указанного организатора распространения информации в сети «Интернет», о чем в адрес провайдера хостинга было направлено соответствующее уведомление.
В целях исключения сетевого адреса из выгрузки хостинг-провайдеру необходимо направить сообщение о принятых мерах по прекращению создания технических условий функционирования приложения Telegram. На основании такого сообщения Роскомнадзором проводится проверка и после подтверждения этого факта, доступ к соответствующему сетевому адресу и располагающимся на нем информационным ресурсам возобновляется.
За дополнительной информацией рекомендуем Вам обратиться к обслуживающему Вас провайдеру хостинга и (или) оператору связи.
Следует отметить, что российские провайдеры хостинга в подавляющем большинстве случаев соблюдают требования российского законодательства и крайне редко допускают блокировку своих ресурсов.
Консультант горячей линии по вопросам
реализации статей 15.1-15.3 Федерального закона
«Об информации, информационных
технологиях и о защите информации»
Кстати, тогда тоже хотел опубликовать на хабре, не прошло модерацию, но не суть. Как видно, спустя год шаблон у них не поменялся, разница только в адресах. И всё так же предлагается два варианта: 1 — давить на хостера; 2 — переезжать к РФ провайдерам.
В вашем случае задача была успешно решена, просто дальше не совсем ясно как этот подход развивать. Во первых как масштабировать, во вторых, всё таки это получился вырожденный случай, например, что делать если понадобится помещать в очередь и другие задачи, посложнее, для выполнения которых нужна будет бизнес логика реализованная в монолите?
А то что описывается в этой статье — применение для тех же целей дополнительных инструментов (так как пока на уровне языка таких возможностей нет). Статический анализатор прогоняет проверки, например, на каждый Pull Request, в случае обнаружении проблем код разворачивается. То есть это исключительно метод контроля качества кода.
Таким образом в исходном сообщении вы половину сочинили, половину потратили на бессмысленные придирки к термину, который у других никаких проблем в понимании не вызывает.
Хм, извините, но причем тут я…
Ну если уж на то пошло, то я бы и не стал на этом архитектуру делать. Вытащить что-то из ответа апи, мапнуть данные в другую структуру, форматирование во вьюхе — вон там это может пригодиться. При работе с тупыми объектами данных.
Если вам нужен автомобиль, чтобы «добраться из пункта а в пункт б», скорее всего лучше всего будет вызвать такси. Или, возможно, купить готовое авто, если это надо делать регулярно. Обычно не нужно заказывать разработку автомобиля для решения этой задачи.
Другими словами, вы не должны ставить задачу «сделать копию автомобиля». Вы должны объяснить из какой точки в какую вы планируете добраться, разово или регулярно, как быстро, насколько комфортно, с каким бюджетом и тп. То есть описать свою проблему. И тогда специалисты смогут предложить вам наилучшее ее решение.
Таким образом, если исполнитель не знал или что-то забыл, то теперь он узнал/вспомнил, а если у него есть аргументированное объяснение, то, возможно, что-то полезное узнаю я.
Почему это? Часть ПО отвечающая за принятие решений вообще может не зависеть от части отвечающей за «зрение» (распознание, класификацию, вычисление расстояния, скорости, вектора и тп). То есть что данные с лидара, что с камер после обработки в таком случае будут приводится к одному формату.
Я думаю что в этих иллюзиях (в том числе с кубиком) объемность и тени вообще не причем, скорее всего дело в том, что мозг воспринимает элемент более светлым в темном окружении и более темным в более светлом окружении (что то типа автоповышения контраста для лучшего различения?) или же возможно он пытается выполнить сравнение цвета элементов не напрямую, а относительно окружения.