Асинхронное программирование за последнее время стало не менее развитым направлением, чем классическое параллельное программирование, а в мире JavaScript, как в браузерах, так и в Node.js, понимание его приемов заняло одно из центральных мест в формировании мировоззрения разработчиков. Предлагаю вашему вниманию целостный и наиболее полный курс с объяснением всех широко распространенных методов асинхронного программирования, адаптеров между ними и вспомогательных проемов. Сейчас он состоит из 23 лекций, 3 докладов и 28 репозиториев с множеством примеров кода на github. Всего около 17 часов видео: ссылка на плейлист.

В предыдущей статье мы разбирали протокол Modbus, являющийся стандартом де-факто в промышленности для M2M-взаимодействия. Разработанный в далеком 1979 году, он имеет ряд существенных недостатков, которые решает MQTT.

Протокол MQTT достаточно молод (стандартизирован только в 2016 году), но уже успел получить широкое распространение в промышленности и IoT. Он был специально разработан максимально компактным, для нестабильных интернет-каналов и маломощных устройств, и позволяет гарантированно доставлять сообщения в случае потери пакетов и обрывов связи.

Главные особенности протокола MQTT:

• Компактный и легковесный — минимальные накладные расходы на пересылку данных, для экономии трафика.
• Устойчивость к потерям — гарантированная доставка в условиях нестабильных сетевых подключений.
• Асинхронный — позволяет обслуживать большое количество устройств, и не зависит от сетевых задержек.
• Поддержка QoS — возможность управлять приоритетом сообщений и гарантировать доставку сообщения адресату.
• Динамическая конфигурация — не требует предварительно согласования полей и форматов данных, может конфигурироваться «на лету».
• Работает за NAT — клиенты могут находиться за NAT, только сервер (брокер) должен иметь реальный IP. Позволяет обойтись без VPN и пробрасывания портов.
• Удобная адресация — поля данных имеют текстовые названия, понятные для человека. Не нужно запоминать цифровые адреса и битовые смещения.

С того момента, когда у вас появляется подруга-анимешница, вы только и слышите, что о Японии. Какие там все странные. Как там круто. Как вас зарежут за невежливое слово. И так далее. Для меня это всегда были ниндзя, самураи, якудза, аниме, богиня Кэнон для фотоаппарата, электроника, суши и щупальца. Думаю, вы можете продолжить список.

На месте оказалось, что всё это есть, но это не главное. Это просто мелочи. Главное то, что если мы будем когда-нибудь строить космические города, я знаю, кто лучше всех справится. Потому что Япония сейчас — это очень технологичная и при этом очень зелёная страна. Они умудрились в одном из самых технологичных городов мира вписать красоту в каждую мелочь и сохранить ощущение, что ты на природе. И максимально эффективно распорядиться ресурсами, включая мусор. И при этом их не беспокоит недоделанность и несовершенство мира вокруг — у нас красота бывает только в оконченном состоянии, а у них ещё и в процессе. То есть всё время.

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

ТОП3 мифов про больную спину, которые мешают людям раз и навсегда решить свою проблему.

• Операции на позвоночнике рискованны, грозят инвалидностью и параличом.
• Хирурги готовы искромсать всех подряд, даже не предлагая пациенту альтернатив.
• Хороший массажист вылечит любую проблему со спиной.

Рассматриваем расширение возможностей System Center Configuration Manager (продукт для управления ИТ-инфраструктурой) при загрузке пользовательских ПК по сети используя PXE. Создаем загрузочное меню на основе PXELinux с функционалом System Center и добавляем возможности антивирусной проверки, образы диагностики и восстановления. В конце статьи касаемся особенностей работы System Center 2012 Configuration Manager совместно с Windows Deployment Services (WDS) при загрузке через PXE.

Все действия производим на тестовой среде, в которой уже есть установленный System Center 2012 Configuration Manager SP1, контроллер домена и некоторое количество тестовых машин. Предполагается, что в SCCM уже используется развертывание по сети используя PXE.

Добро пожаловать на 12-й урок. Сегодня мы поговорим о еще одной весьма важной теме, а именно о работе с логами и отчетами. Порой данная функциональность оказывается чуть ли не решающей при выборе средства защиты. Очень уж любят «безопасники» удобную систему отчетности и функциональный поиск по различным событиям. Трудно их в этом винить. По сути, логи и репорты это важнейший элемент оценки защищенности. Как понять текущий уровень безопасности если вы не видите, что происходит? К счастью, у Check Point в этом плане все в полном порядке и даже более. Check Point имеет одну из лучших систем отчетности, которая работает из коробки! При этом есть возможность кастомизации и созданиях собственных отчетов! Все это дополняется удобным и интуитивно понятным процессом работы с логами. Но давайте обо всем по порядку.

Добро пожаловать на 11 урок! Если помните, то еще в 7 уроке мы упомянули, что у Check Point существует три типа Security Policy. Это:

1. Access Control;
2. Threat Prevention;
3. Desktop Security.

Мы уже рассмотрели большинство блейдов из политики Access Control, главная задача которых — контроль трафика или контента. Блейды Firewall, Application Control, URL Filtering и Content Awareness позволяют уменьшить площадь атаки, отсекая все лишнее. В данном же уроке мы рассмотрим политику Threat Prevention, задача которой — проверка контента, который уже прошел через Access Control.

Оригинал поста + Вспомогательные функции и исходные данные

Оглавление

Взаимоотношения персонажей
— Кто кого родил
— Кто кому брат или сестра
— Кто кого убил
— Кто кому служит
— Кто с кем женат или помолвлен
— У кого с кем был секс
— Все отношения на одном графе
Связь персонажей по сценам
Кто самый «популярный» персонаж Игры престолов?
— Количество экранного времени у персонажей
— Сколько персонажей было в сериях?
— Кто из персонажей был в самом большом количестве серий «Игры престолов»?
Самые популярные локации «Игры престолов»
— Карта локаций «Игры престолов»
— Перемещения персонажей «Игры престолов» от серии к серии
— Кто больше всего «путешествовал» из персонажей «Игры престолов»?
— Самые популярные локации «Игры престолов» (по экранному времени)
В каких фильмах ещё играли актёры Игры престолов и насколько они знакомы?
— Фильмы, в которых играли самые «востребованные» актёры «Игры престолов»:
— Актёры «Игры престолов» в «Гарри Поттере»
— Актёры «Игры престолов» в «Звёздных войнах»
— Актёры «Игры престолов» в «Пиратах карибского моря»
— В каких фильмах/сериалах много актёров «Игры престолов»
— Как тесно связаны между собой актёры «Игры престолов»
Разговоры в «Игре престолов»
Пол персонажей «Игры престолов»: кого больше, мужчин или женщин?

---

В этом посте я расскажу о том, как применять язык Wolfram Languge в анализе и визуализации данных на примере базы данных по «Игре престолов». В этой статье не уделяется особого внимания парсингу данных, об этом я расскажу отдельно. Вместо этого пост целиком посвящен интересной инфографике и её созданию.

Надеюсь, что построенные визуализации заинтересуют тех, кому нравится этот замечательный сериал).

Привет Хабр! В этой статье хотелось бы рассказать о некоторых стандартных возможностях Dynamics CRM (для понимания что это вообще такое), её основных бизнес процессах и средствах расширения функционала прямо из коробки.

Добро пожаловать на юбилейный — 10-й урок. И сегодня мы поговорим о еще одном блейде Check Point — Identity Awareness. Еще в самом начале, при описании NGFW, мы определили, что для него обязательна возможность регулирования доступа на основе учетных записей, а не IP-адресов. Связано это в первую очередь с повышенной мобильностью пользователей и повсеместным распространением модели BYOD — bring your own device. В компании может быть куча народу, которые подключаются по WiFi, получают динамический IP, да еще и из разных сегментов сети. Попробуй тут создай аксес-листы на основе ip-шников. Здесь уже без идентификации пользователей не обойтись. И вот именно блейд Identity Awareness поможет нам в этом деле.

Автор материала, перевод которого мы публикуем, говорит, что в мире разработки программного обеспечения «архитектурным проектированием» можно назвать процесс конструирования приложения, в ходе которого его стремятся сделать качественным, надёжным и хорошо поддающимся поддержке. При этом паттерны (шаблоны) проектирования позволяют оперировать понятиями, представляющими собой подходы к решению распространённых проблем. Эти решения могут варьироваться от абстрактных, концептуальных, до предельно конкретных. Их знание позволяет разработчикам эффективно друг с другом общаться.

Если хотя бы два разработчика в команде разбираются в паттернах, разговор о решении проблем, встающих перед командой, становится весьма продуктивным. Если о паттернах знает лишь один член команды, то обычно просто бывает разъяснить то, что он знает, другим членам команды.



Цель этой статьи заключается в том, чтобы заинтересовать читателей чем-то вроде формального представления знаний в сфере разработки программного обеспечения, продемонстрировав им идею паттернов проектирования и описав несколько паттернов, которые интересны тем, что они нашли применение в современной JavaScript-Разработке.

Сейчас многие покупают точки доступа 802.11n, но хороших скоростей достичь удается не всем. В этом посте поговорим о не очень очевидных мелких нюансах, которые могут ощутимо улучшить (или ухудшить) работу Wi-Fi. Всё описанное ниже применимо как к домашним Wi-Fi-роутерам со стандартными и продвинутыми (DD-WRT & Co.) прошивками, так и к корпоративным железкам и сетям. Поэтому, в качестве примера возьмем «домашнюю» тему, как более родную и близкую к телу. Ибо даже самые администые из админов и инженеристые из инженеров живут в многоквартирных домах (или поселках с достаточной плотностью соседей), и всем хочется быстрого и надежного Wi-Fi.
[!!]: после замечаний касательно публикации первой части привожу текст целиком. Если вы читали первую часть — продолжайте отсюда.

Введение

В связи с тем, что близится 2020 год и «час хэ», когда нужно будет отчитаться об исполнении приказа Минкомсвязи о переходе на отечественное ПО (в рамках импортозамещения), да не простое, а из реестра Минкомсвязи, мне прилетела задача о разработке плана, собственно, по исполнению приказа Министерства связи и массовых коммуникаций №334 от 29.06.2017. И начал я разбираться.

Первая статья была о том, как не надо было делать «Вертолетам России». И вызвала она столько хайпа, под ней было написано столько комментариев, что я, честно говоря, был немного в шоке…

Так что, как было обещано, пришла пора начать «цикл статей о том, как мы приказ исполняли и боролись с обстоятельствами». Уж не знаю, насколько длинным будет этот цикл, но есть желание описать весь процесс от начала до конца, но времени на это не хватает, ибо написание статей занимает гору времени, а семью кормить надо =)

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

В связи с тем, что близится 2020 год и «час хэ», когда нужно будет отчитаться об исполнении приказа Минсвязи о переходе на отечественное ПО (в рамках импортозамещения), мне прилетела задача о разработке плана, собственно, по исполнению приказа Министерства связи и массовых коммуникаций №334 от 29.06.2017. И начал я разбираться. И первое, на что я наткнулся, была статья о том, что «Вертолеты России» уже все сделали и что надо у них опыт перенимать. А все ли так гладко?.. Давайте смотреть.

Не так давно ИТ-директор холдинга «Вертолеты России» Михаил Носов рассказал о том, как они выполняли приказ Министрерства связи об импортозамещении ПО. Показал презентацию с цифрами и выгодами от перехода на отечественный софт… И все бы ничего, но только есть там куча несоответствий…

Для удаленной работы есть миллион причин. Торчать по 8-9 часов в офисе вовсе не так здорово, как это показано в сериалах. В один прекрасный день, летом 2018-го, я просто решила, что мне нужно больше личного пространства и собралась увольняться, тем более на моей должности в то время я доросла до максимума и дальнейших перспектив не предвиделось.



Моя работа была чем-то средним между саппортом, тестировщиком, оператором SQL и Excel-ниндзя, а хотелось углубиться в тестирование.

Так как я уверенно говорила и писала по-английски, я решила сразу искать на зарубежном рынке. Просмотрела несколько бирж фриланса, почитала отзывы об Upwork и ее аналогах и решила не связываться. Сложно конкурировать в мелких проектах с гражданами Индии, которые готовы работать за 3 доллара в час. Также мне показалось непродуктивным подавать заявки в онлайн-сервисы, работающие по принципу глобального посредника между удаленными сотрудниками и компаниями, судя по отзывам, отбор у них очень жесткий, а темп работы невероятно напряженный.

Я решила сосредоточиться на ресурсах, предлагающих постоянную удаленную работу в компаниях, с которыми можно было связаться напрямую. Идея была заманчива, так как очень импонировало работать на иностранного работодателя без цепочки менеджеров-начальников.
Наиболее полезными с точки зрения количества и качества вакансий, а также удобства пользования, выглядели следующие сайты:

ZFS должна быть классной, но меня немного бесит, что она словно застряла в прошлом — даже до того, как её признали крутой и лучшей файловой системой. Она негибкая, ей не хватает современной интеграции с флеш-памятью и она не поддерживается напрямую большинством операционных систем. Но я храню все свои ценные данные на ZFS, поскольку именно она обеспечивает наилучший уровень защиты для условий SOHO (малый офис/домашний офис). И вот почему.

Первая директива систем хранения: не возвращать неправильные данные!

В 1933 году шведский офтальмолог H. Sjogren впервые описал синдром «сухого глаза» при одноименном синдроме Шегрена (аутоиммунное заболевание, при которой снижается секреция слюнных, слезных и др. желез). Это так называемый первичный синдром «сухого глаза», который наблюдается у 1% населения. Развитие современных технологий позволило в 1995 году выделить вторичный синдром «сухого глаза» которым, по разным данным, страдает до 20% населения, и до 48% офисных работников.

Что же это за болезнь?

Когда мы моргаем, мы не только смачиваем роговицу глаза слезой, но и оставляем на ней «слезную пленку». В норме она сохраняется на глазу от 10 до 45 секунд, потом лопается. Мы моргаем снова и процесс повторяется.



Каждый слой слезной пленки очень важен: липидный препятствует испарению и удерживает ее на роговице, водный — увлажняет, питает роговицу, обеспечивает иммунную защиту, муциновый слой — уменьшает поверхностное натяжение слезы. Нарушение выработки одного из компонентов слезной пленки влияет на ее качество. Она начинает быстрее лопаться, появляется чувство дискомфорта и симптомы «сухого глаза».

Зачем?

Даже в этом хабе наблюдается повышение интереса к IoT, по моему субъективному мнению это глобальная тенденция, выходящая далеко за рамки этого сайта. А значит стоит вставить и свои 5 копеек в развитие направления, тем более что давно крутилась мысль сделать узел для умного дома, который смог бы контролировать потребление любого прибора питающегося от сети 220В и давал возможность программировать логику управления в зависимости от параметров потребления, температуры, фазы луны и т.д. Существуют готовые решения, но часто в них что-то не устраивает, да и готовое это не наш метод если можно попробовать построить свой уникальный велосипед.



Параметры будущего велосипеда:

— Дешевое устройство из общедоступных компонентов.
— Контроль тока в цепи потребителя.
— Управление устройством по протоколу MQTT.
— Контроль температуры устройства.
— Два выносных датчика для контроля температуры потребителя.
— Индикация состояния на экране устройства.
— Аварийное отключения потребителя если температура или ток превысили задаваемые значения.

Дорогие мои друзья, отважные критики, тихие читатели и тайные почитатели, СДСМ заканчивается.



Я не могу похвастаться тем, что за 7 лет я затронул все темы сетевой сферы или тем, что хотя бы одну из них раскрыл полностью. Но это и не было целью. А целью этой серии статей было ввести юного студента за руку в этот мир и проводить его шаг за шагом по основной галерее, давая общее представление, и уберечь от болезненных скитаний по тёмным уголкам сознания Олифера и Олифера в мучительных попытках найти ответ на вопрос, как всё это применить в жизни.
СДСМ планировался коротким практическим курсом «как научиться в сети за месяц», а вылился в 16 (на самом деле 19) длинных выпусков, которые мы уже даже переименовали в «Сети Для Самых Суровых». Общее количество символов перевалило за 1 000 000.

GraphQL сейчас, без преувеличения, это — последний писк IT-моды. И если вы пока не знаете о том, что это за технология, о том, как ей пользоваться, и о том, почему она может вам пригодиться, значит статья, перевод которой мы сегодня публикуем, написана специально для вас. Здесь мы разберём основы GraphQL на примере реализации схемы данных для API компании, которая занимается попкорном. В частности, поговорим о типах данных, запросах и мутациях.