Поскольку блокировки интернета в РФ в последние недели и месяцы многократно активизировались, а маразм все крепчает и крепчает, стоит еще раз поднять тему обхода этих самых блокировок (и делаем ставки, через сколько дней на эту статью доброжелатели напишут донос в РКН чтобы ограничить к ней доступ на территории страны).

Вы, наверняка, помните отличный цикл статей на Хабре в прошлом году от пользователя MiraclePtr, который рассказывал о разных методах блокировок, о разных методах обхода блокировок, о разных клиентах и серверах для обходов блокировок, и о разных способах их настройки (раз, два, три, четыре, пять, шесть, семь, восемь, десять, десять, и вроде были еще другие), и можете спросить, а зачем еще одна? Есть две основные причины для этого.

Написать этот материал меня побудило... отсутствие хороших статей по корутинам в C++ в русскоязычном интернете, как бы странно это не звучало. Ну серьезно, C++20 существует уже несколько лет как, но до сих пор почти все статьи про корутины, что встречаются в рунете, относятся к одному из двух типов. Или обзор начинается с самых глубин и мелочей, пересказывая cppreference, а потом автор выдыхается и все сводится к "ну а дальше все понятно, возьмите и примените это в своем коде", что напоминает известную картинку с совой. Либо иногда в статьях рассматривается применение корутин на примере генераторов, и этим все и ограничивается. Но, давайте будем честны, генераторы — это замечательно, но за все время моей многолетней карьеры разработчика я, вероятно, делал что‑то подобное генераторам разве что разок, в то время как асинхронный ввод‑вывод приходится использовать почти в каждом проекте. И поэтому меня гораздо больше интересует реализация асинхронного ввода‑вывода с использованием корутин, а не генераторы. Поэтому пришлось разбираться во всем самому.

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

Я довольно давно пишу код, и так вышло, что практически всегда на C++. Даже и не могу прикинуть, сколько раз я написал подобную конструкцию:

for (int i=0; i<size; i++) {
    [...]
}

Хотя почему не могу, очень даже могу:

find . \( -name \*.h -o -name \*.cpp \) -exec grep -H "for (" {} \; | wc -l
43641

Наш текущий проект содержит 43 тысячи циклов. Проект пилю не я один, но команда маленькая и проект у меня не первый (и, надеюсь, не последний), так что в качестве грубой оценки пойдёт. А насколько такая запись цикла for хороша? Ведь на самом деле, важно даже не то количество раз, когда я цикл написал, а то количество раз, когда я цикл прочитал (см. отладка и code review). А тут речь очевидно идёт уже о миллионах.

На КПДВ узел под названием «совершенная петля» (perfection loop).

Так каков он, совершенный цикл?

1. Пользовательские процессы изолированы друг от друга и, умирая, не тянут за собой всю систему
2. Пользовательские процессы изолированы от физической памяти, то есть знать не знают, сколько у вас на самом деле оперативки и по каким адресам она находится.
3. Операционная система гораздо сложнее, чем в системах без виртуальной памяти
4. Никогда нельзя знать заранее, сколько времени займет выполнение следующей команды процессора

Некоторое время назад мне в очередной раз потребовался USB-Serial адаптер. И не просто адаптер c RX/TX, а чтобы еще присутствовали управляющие сигналы. И не один UART, а несколько. И еще желательно, в виде одного композитного устройства, чтобы все это хозяйство не занимало больше одного USB-порта. Так и началась эта история...

Для получения требуемого напряжения в схемотехнике, как правило, используются микросхемы импульсных  DC-DC преобразователей. Очень удобные микросхемы - высокий КПД, возможность как понизить, так и повысить напряжение, миниатюрные размеры… Но иногда они словно сходят с ума: выходное напряжение начинает плавать, скакать, они издают чётко слышимый ухом свист (на самом деле свист издаёт выходной дроссель), микросхемы начинают очень сильно нагреваться (вплоть до выхода из строя).. Причём, как правило, это наблюдается не на одном-двух экземплярах, а сразу на всех устройствах из партии, то есть, налицо какая-то схемотехническая ошибка.  Вопросу “почему это происходит, и как с этим бороться” и посвящена эта статья. 

В предыдущей статье “Современные технологии обхода блокировок: V2Ray, XRay, XTLS, Hysteria и все-все-все” я рассказывал про прокси-протоколы. Теперь настало время рассказать про клиенты: консольные, GUI для десктопа и для мобильных платформ. 

Надеюсь, что эта статья вам окажется полезной, потому что, как выяснилось, найти хороший клиент даже для тех же V2Ray/XRay в наше время не так-то просто. Потому что большая часть того, что находится при поиске в интернете “в лоб” и даже в списках типа Awesome V2Ray - или уже неподдерживаемое, или довольно кривое, или не умеющее в актуальные версии и фичи (например, XTLS и uTLS), а самые жемчужины прячутся где-нибудь в глубинах Github’а и сторов.

Три месяца назад здесь на Хабре была опубликована статья “Интернет-цензура и обход блокировок: не время расслабляться”, в которой простыми примерами показывалось, что практически все популярные у нас для обхода блокировок VPN- и прокси-протоколы, такие как Wireguard, L2TP/IPSec, и даже SoftEther VPN, SSTP и туннель-через-SSH, могут быть довольно легко детектированы цензорами и заблокированы при должном желании. На фоне слухов о том, что Роскомнадзор активно обменивается опытом блокировок с коллегами из Китая и блокировках популярных VPN-сервисов, у многих людей стали возникать вопросы, что же делать и какие технологии использовать для получения надежного нефильтрованного доступа в глобальный интернет.

Мировым лидером в области интернет-цензуры является Китай, поэтому имеет смысл обратить на технологии, которые разработали энтузиасты из Китая и других стран для борьбы с GFW (“великим китайским файрволом”). Правда, для неподготовленного пользователя это может оказаться нетривиальной задачей: существует огромное количество программ и протоколов с похожими названиями и с разными не всегда совместимыми между собой версиями, огромное количество опций, плагинов, серверов и клиентов для них, хоть какая-то нормальная документация существует нередко только на китайском языке, на английском - куцая и устаревшая, а на русском ее нет вообще.

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

В одной конторе соискателю на позицию Senior C# developer выдали тестовое задание: отсортировать файл со строками определенного формата.

Требования такие:

* Формат строки: число, точка, пробел, далее любые символы до конца строки.

* Порядок сортировки — сначала сортируем текстовой части строки, потом по числу если текстовые части совпадают.

* Кодировка — UTF-8.

* Размер файла — 100гб - гарантированно больше объема ОП.

Должно отработать за 1 час на машине проверяющего, вряд ли там будет супер-быстрый SSD и огромное количество оперативной памяти.

Как и многие другие программисты, узнав о таком тестовом задании, я возмутился. Внешнюю сортировку слиянием практически всех проходили в ВУЗе, но практически никто никогда не писал её. Задача очень непрактическая и непонятно какие навыки проверяет. Так мне казалось.

Эта задача вызвала бурные обсуждения о способах её решения. Многие программисты, причисляющие себя к рангу senior, предложили использовать базы данных, ибо не барское это дело - вручную писать алгоритмы сортировки. Некоторые даже попытались сделать решение на Apache Spark. Однако никто до конца задачу не решил, ибо мало кому удалось отсортировать в нужном порядке даже 10ГБ файл менее чем за 15 минут без SSD.

Я подумал, что стоит решить задачу до конца с помощью программирования, и тоже причислить себя к рангу senior developer.

Я работаю техническим писателем в компании documentat.io. Мы занимаемся заказной разработкой технической документации, в том числе на английском языке. Иногда я дорабатываю уже существующие документы или спецификации к API на английском. Как правило, такие документы написаны русскоязычными разработчиками, которые неплохо владеют английским. И всё же они часто допускают характерные грамматические, пунктуационные и стилистические ошибки.

Корень этих ошибок один — разные языковые механизмы. Нам бывает легко запутаться в употреблении временных форм, порядке слов или непонятно зачем придуманных артиклях. 

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

Статья навеяна этой новостью на Хабре

Печальные новости о проекте YouTube Vanced. Гугл потребовал закрытия проекта и удаления готовых дистрибутивов. Разработчики подчинились. Поэтому больше YouTube Vanced с официального сайта не скачать. Возможно есть где-нибудь на зеркалах, но надо быть осторожным. В дистрибутиве могут быть вредные присадки.

Доброго дня всем хабровчанам. Примерно месяц назад я переехал из Москвы жить и работать в Ереван. С тех пор периодически меня спрашивают про то как мне удалось доехать до Армении на автомобиле, как вообще устроена релокация и как мне живется после переезда. Так что я подумал-подумал и решил написать об этом статью на Хабр.

Когда у меня появился умный чайник Xiaomi Mi Smart Kettle Pro - у меня возник тот же вопрос, что и у многих его пользователей: почему его нельзя включить удаленно? Чайник позволяет подключиться к нему через блютуз, задать температуру которую он будет поддерживать и еще пару незначительных параметров, но его невозможно удаленно включить, что нивелируют его ценность как компонента умного дома.

Ряд наших устройств имеет встроенный порт RS-485 для прямого подключения электросчётчиков, имеющих данный интерфейс. Для облегчения тестирования устройств мы разработали небольшую программу-эмулятор. Именно о ней дальше и пойдёт речь.

Бреши в устройствах не всегда можно закрыть, в отличие от уязвимостей в софте. Однако это не повод для фрустрации! Исследовать безопасность IoT, телефонов, планшетов, блоков управления и т. д. все равно нужно. По крайней мере, можно предупредить пользователей об уязвимостях, а также устранить недостатки в новых версиях продуктов.

Мы с командой покопались в одном из самых популярных отладчиков для микроконтроллеров — J-Link. В результате нашли уязвимости в его системе лицензирования, которые позволяют за несколько секунд превратить бюджетную версию устройства в дорогую. 

В современных embedded-устройствах используется огромное количество различных разъемов, таких как USB Type-B, miniUSB, microUSB и так далее. Все они отличаются форм-фактором, максимальной пропускной способностью и другими различными характеристиками. Самым верным решением в данной ситуации было бы минимизировать количество используемых разъемов и остановиться на каком-то одном, «едином» для большинства разработок. Наиболее перспективным выглядит использование разъема Type-C. В нем объединены невероятная пропускная способность с высокой мощностью питания. Такие производители, как Apple, Huawei, Sony уже внедряют разъем Type-C в свои разработки, постепенно отказываясь от использования «старых» разъемов. А чем embedded-разработчики хуже?

В данной статье мы приведем общую информацию, необходимую для практического применения Type-C. Наиболее полезной она будет для новичков в сфере embedded, но надеемся, что каждый найдет в ней что-то интересное.

Каждый электронщик, работающий (или отдыхающий) с цифровыми микросхемами рано или поздно обязательно сталкивается с протоколом JTAG. Значительное количество материалов о данном протоколе содержит три раздела:
1) Обширный экскурс в историю и рассказ о том, как стенд с летающими щупами и рентгеновская установка легко могут быть заменены отладчиком на 2-3 порядка дешевле их.
2) Достаточно сжатое описание протокола JTAG (с картинкой его конечного автомата).
3) Рассказ о том, что фирменный отладчик, а также программное обеспечение компании <COMPANY NAME> позволят почти без усилий протестировать почти любое устройство почти любой сложности и конфигурации.

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

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

Но, прежде чем рассылать резюме и отклики на подобные вакансии важно привести свое СV в принятый в Европе и Америке вид.