Пользователь
Достаточно долгое время искал для своего умного дома датчик учета электроэнергии, сначала присматривался к Tuya Smart Life 3 Phase WiFi Energy KWH Meter, но места в щитке у меня не было (думал повесить его за щитком), потом думал собрать на ESP32, но нужно было собирать три устройства - ввод в квартиру у меня 3х фазный, но совсем недавно на рынке появился миниатюрный датчик от известного производителя электроники zemismart - SPM02-D2TZ (у производителя также есть однофазное устройство - SPM01).
В серии предыдущих статей я описывал, почему повсеместно используемые VPN- и прокси-протоколы такие как OpenVPN и L2TP очень уязвимы к выявлению и могут быть легко заблокированы цензорами при желании, обозревал существующие гораздо более надежные протоколы обхода блокировок, клиенты для них, а также описывал настройку сервера двух видов для всего этого.
Многим читателям, однако, ручная настройка показалась сложной и неудобной - хотелось иметь понятный легко устанавливаемый графический интерфейс без необходимости ручного редактирования конфигов и вероятности допустить ошибки, а еще мы не поговорили про механизм "подписок", позволяющих клиентам автоматически подключать список новых серверов с настройками подключений.
Поэтому сегодня мы поговорим об установке и использовании графической панели 3X-UI для сервера X-Ray с поддержкой всего того, что умеет X-Ray: Shadowsocks-2022, VLESS с XTLS и т.д.
Разработка сложной системы предполагает что вы, рано или поздно, столкнетесь с вопросом повышения производительности вашего приложения. Выполнив поиск по разным источникам вы найдете множество рекомендаций по улучшению производительности как для конкретных ситуаций и узких мест, так и применимых для всего приложения. В этой статье мы рассмотрим те рекомендации, которые призваны улучшить производительность всего приложения при минимальных трудозатратах. Мы протестируем оказываемый на приложение эффект, вычислим возможный прирост производительности от каждой из них и рассмотрим нет ли подводных камней, которые стоит учитывать.
Статья будет полезна разработчикам и лидерам команд, стремящимся улучшить производительность системы в целом. Также статья будет полезна опытным разработчикам, которые смогут использовать список рекомендаций из данной статьи в качестве отправной точки для создания или дополнения собственного чеклиста по улучшению производительности ASP NET Core приложений.
Мой опыт подсказывает, что любой более или менее сложный проект по машинному обучению рано или поздно превращается в набор сложных неподдерживаемых внутренних инструментов. Эти инструменты, как правило, мешанина из скриптов Jupyter Notebooks и Flask, которые сложно развёртывать и интегрировать с решениями типа GPU сессий Tensorflow.
Впервые я столкнулся с этим в университете Карнеги, затем в Беркли, в Google X, и, наконец, при создании автономных роботов в Zoox. Зарождались инструменты в виде небольших Jupyter notebooks: утилита калибровки сенсора, сервис моделирования, приложение LIDAR, утилита для сценариев и т.д.
С ростом важности инструментов появлялись менеджеры. Бюрократия росла. Требования повышались. Маленькие проекты превращались в огромные неуклюжие кошмары.
Создадим сайт который динамически поддерживает светлую, тёмную и цветовые темы.
Создаём базовый цвет который будет меняться. Привязываем его к data-theme на html.
в примерах кода используется & из less/scss синтаксиса
html[data-theme='green'] {
--theme-color: 110;
}
Этот перевод появился благодаря хорошему комментарию 0x1000000. В .NET Framework 4 появилось пространство System.Threading.Tasks, а с ним и класс Task. Этот тип и порождённый от него Task<TResult> долго дожидались, пока их признают стандартами в .NET в роли ключевых аспектов модели асинхронного программирования, которая была представлена в C# 5 с его операторами async/await. В этой статье я расскажу о новых типах ValueTask/ValueTask<TResult>, разработанных для улучшения производительности асинхронных методов в случаях, когда издержки на выделение памяти нужно принимать во внимание.
Одной из важнейших задач при проектировании систем является организация мониторинга состояния всех узлов, в том числе большого числа сервисов. В условиях, когда дополнительных сил и средств на это не выделяется, приходится максимально использовать готовые решения.
Думаю, у многих картина в проекте примерно такая:
Что-то куда-то пересылается, как-то обрабатывается и держится на одном гвозде. Задача была собрать со всех точек статистику обработки данных и сложить в одном месте, чтобы потом строить графики и писать отчеты.
Это статья достаточно древняя, но не потерявшая актуальности. Когда разговор заходит об async/await, как правило, появляется ссылка на неё. Перевода на русский найти не смог, решил помочь кто не fluent.
Асинхронное программирование долгое время было царством самых опытных разработчиков с тягой к мазохизму – тех, кто имел достаточно свободного времени, склонность и психические способности размышлять об обратных вызовах (callback) из обратных вызовов в нелинейном потоке выполнения. С появлением Microsoft .NET Framework 4.5, C# и Visual Basic принесли асинхронность всем нам, так что простые смертные теперь могут писать асинхронные методы почти так же легко, как синхронные. Обратные вызовы больше не нужны. Больше не нужна явная передача (marshaling) кода из одного контекста синхронизации в другой. Больше не нужно беспокоиться как двигаются результаты выполнения или исключения. Нет необходимости в трюках, которые искажают средства языков программирования для удобства разработки асинхронного кода. Короче говоря, больше нет мороки и головной боли.
По стандартному шаблону Asp.Net Core MVC в Visual Studio 2017 создаем новый проект, переводим его на четвертый Bootsrtrap, встраиваем туда модульное приложение Vue.js на TypeScript.
Получаем простую, обозримую и легкую заготовку для создания своих веб-приложений на VS2017 с использованием Vue.js и TypeScript. Привычная среда разработки, в которой можно выполнять большую часть кодинга и отладки, а также быстрая пересборка приложения, делают работу вполне комфортной.
В генерации JavaScript-кода приложения принимает участие только штатный компилятор TypeScript и VS2017, что сильно сужает круг подозреваемых при возникновении глюков. А это, в свою очередь, — тоже большая экономия времени и нервов.
Материал рассчитан на способных управиться с VS2017 и знакомых с прогрессивным JavaScript фреймворком Vue.js.
