Уходящий 2022-ой год, стал, безусловно, межевым для отечественной микроэлектроники. Введенные санкции лишили российские дизайн-центры доступа к заводам по производству разрабатываемой ими продукции, в первую очередь, к мощностям флагмана отрасли в лице тайваньской компании TSMC. Фактически, это означает, что на данный момент в России становится невозможным производить сколь либо современную кремниевую микроэлектронику, особенно в части высокопроизводительных решений. Краткий профессиональный разбор ситуации с обзором наших текущих возможностей ещё в марте этого года сделал уважаемый @CorneliusAgrippa. Если резюмировать – на данный момент Россия имеет возможность промышленно производить чипы по технологии 180 нм на заводе Микрон, с перспективой наладить 90 нм в ближайшее время (правительство поставило задачу сделать это до конца 2022-го года). Создание на имеющейся на Микроне линии промышленной технологии на 65 нм и ниже фактически невозможно. Причина в том, что завод Микрон работает на пластинах диаметра 200 мм, а технология производства на 65 нм сопровождалась параллельным переходом на пластины диаметром 300 мм. Поэтому, для такого перехода требуется, по сути, постройка нового завода, хотя имеющееся на Микроне литографическое оборудование потенциально позволяет создание 65 нм техпроцесса.

Давно хотел написать статью на такую интересную и больную тему как импортозамещение. А именно, как это все выглядит и чем пахнет в той сфере, где я работаю – разработка и производство электронной техники, а конкретно – аппаратуры связи. У меня накопилось множество мыслей, занимательных историй, ознакомиться с которыми будет наверняка небезынтересно даже тем людям, кто далек от этой сферы.

Здравствуйте, давно читаю Хабр и все хотел написать кому-нибудь статью, но не знал с чего начать и о чем писать. Но решил что тянуть кота за причинное место. Надо просто взять и написать обзор о чем то что я знаю и что будет просто для начало. Поэтому решил описать алгоритмы сортировки в размере 37 штук. Я понимаю, что на Хабре есть подобные статьи, одна постараюсь их добавить количеством алгоритмов и приведением небольшого числа графиков.

Kubernetes, как система оркестрации, позволяет автоматизировать процесс развертывания сложных приложений и восстанавливать ожидаемое состояние кластера после сбоев. В общем случае приложение представляет собой резидентно запущенные контейнеры, которые обрабатывают запросы клиентов в цикле обработки событий, при этом при росте нагрузки могут создаваться дополнительные реплики (с использованием механизма Horizontal Pod Autoscaling). Однако, нередко бывают случаи, когда сервис используется не очень часто, но при этом в запущенном состоянии он забирает большое количество оперативной памяти или процессорного времени, и желательно обеспечить механизм запуска сервиса по запросу (или по внешнему событию). Для реализации такого варианта использования сейчас доступен инструмент knative, который был принят в марте 2022 года в качестве incubating-проекта в CNCF (Cloud Native Computing Foundation). В этой статье мы разберемся с основными понятиями knative и попробуем создать архитектуру приложения, основанную на событиях, с использованием eventing-возможностей knative.

Туториалы делятся на две больших категории: либо "как нарисовать сову", либо подробно расписанные тысячи шагов в формате "напиши туториал для дурака - и только дурак захочет его читать".

Как какой из двух категорий относится эта статья — решать вам.

В этой статье вы увидите пошаговое создание cloud-native микросервиса на Amazon AWS, пригодное для "чтения с листа". Чтобы понять, что здесь происходит, не нужно разворачивать проект - достаточно обладать живым воображением и прочитать текст по диагонали. Если же вы всё-таки захотите повторить шаги, вам будут жизненно нужны знания вида, как создавать классы в IDE и что такое Spring.

Вначале мы напишем пару простых микросервисов на Spring Boot, докеризуем их, зальём в AWS, настроим красивые доменные имена и HTTPS, прикрутим логирование и мониторинг, Prometheus и Grafana. Это небольшое путешествие по всем кругам ада, из которого вы не вернетесь прежним.

Текст написан на основе текстов и демо-проекта microservice-customer за авторством @kamaruzzaman. Если вы потеряли нить повествования, всегда можно зайти на GitHub и найти весь код в пригодном для запуска виде. Если захочется закопаться в тему, то бро Дима Чуйко (@Teapot) написал вам ещё две части статьи "Микросервисы: от CRUD до Native Image" (раз, два).

Последняя важная оговорка. В этом гайде будут использоваться технологии Amazon и обычные дистрибутивы OpenJDK. Автор осознает, что мы живём в России, и возможно, вместо Amazon куда лучше подойдет что-то вроде SberCloud или MTS Cloud, а вместо обычного OpenJDK - Axiom JDK с сертификацией по ФСТЭК. Особенности российских технологий - тема для отдельной статьи. Если вы захотите таковую после чтения этого гайда - отметьтесь в комментариях.

Статья будет полезна тем, кто использовал свой дата-центр или классический хостинг, но затем столкнулся с миром публичных облачных платформ. Если не продумали все детали при планировании, то проблемы почти неизбежны. Рассккажу, как их избежать.

Нижеприведенный список является моей небольшой коллекцией примеров кода на языке С, которые не являются корректными с точки зрения языка С++ или имеют какое-то специфичное именно для языка С поведение. (Именно в эту сторону: С код, являющийся некорректным с точки зрения С++.)

Этот материал я уже публиковал на другом ресурсе в менее причесанном виде, Я бы, наверное, поддался прокрастинации и никогда не собрался опубликовать эту коллекцию здесь, но из-за горизонта уже доносится стук копыт неумолимо приближающегося С23, который безжалостно принесет некоторые жемчужины моей коллекции в жертву богам С-С++ совместимости. Поэтому мне и пришлось встать с печи, пока они еще актуальны...

Разумеется, язык С имеет много существенных отличий от языка С++, т.е. не составит никакого труда привести примеры несовместимостей, основанные, скажем, на ключевых словах или других очевидных эксклюзивных свойствах С99. Таких примеров вы не найдете в списке ниже. Мой основной критерий для включения примеров в этот список заключался именно в том, что пример кода должен выглядеть на первый взгляд достаточно "невинно" для С++-наблюдателя, т.е. не содержать бросающихся в глаза С-эксклюзивов, но тем не менее являться специфичным именно для языка С.

Форматированные строковые литералы, которые ещё называют f-строками (f-strings), появились довольно давно, в Python 3.6. Поэтому все знают о том, что это такое, и о том, как ими пользоваться. Правда, f-строки обладают кое-какими полезными возможностями, некоторыми особенностями, о которых кто-нибудь может и не знать. Разберёмся с некоторыми интересными возможностями f-строк, которые могут оказаться очень кстати в повседневной работе Python-программиста.

Удивительно, но новость из заголовка сообщество почему-то обошло стороной, либо вокруг неё не было особого обсуждения, что достаточно странно, учитывая традиционную заинтересованность аудитории микроэлектроникой. Что ж, давайте восполним этот пробел. Если вам просто интересен вопрос, или же вы специалист и вам есть что сказать - так или иначе добро пожаловать под кат.

Ведь где иначе искать истины в этом вопросе, как не на Хабре...

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

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

Налоговая отдаёт данные ЕГРЮЛ  по организации в виде PDF. Посредники за автоматический доступ по API хотят денег. На многих сайтах часть данных закрыто, часть функций недоступны бесплатно, и полно рекламы. 

Особенно интересно, что на некоторых сайтах предоставляющих данные по API имеется логотип Сколково. Это такой высокотехнологический бизнес, наверное, открытые данные продавать.

Налоговая просит 150 000 рублей в год за доступ к данным ЕГРЮЛ в виде сваленных в архивы XML-файлов. У ФНС классный бизнес. Вы проявляйте должную осмотрительность при выборе поставщиков, но доступ к данным за деньги. Если вы хотите получить доступ и к реестру индивидуальных предпринимателей (ЕГРИП), то платите ещё 150 000 рублей в год. Согласитесь 300 000 рублей в год приличная сумма.

Остальные реестры данных у налоговой доступны бесплатно. Однако, без базы ЕГРЮЛ их вряд ли можно использовать. Самая частая операция в бизнесе подставить реквизиты из ЕГРЮЛ по ИНН.

Сформировалась целая отрасль, можно сказать, торговцев воздухом открытыми данными, создающих ВВП из воздуха как бухгалтеры, работающие руками там, где должны работать программы. Сколько компаний платит налоговой по 300 000р. в год?! Сколько программистов занято написанием одинаковых по функциям парсеров, которые переводят данные из XML налоговой в SQL и JSON?! Сколько серверов заняты под одинаковые функции?! Где добавочная стоимость? Все вроде при деле, а за чей счёт банкет?

Ну, ладно, “скандалить, критиковать каждый может”(с) как говорил бессмертный товарищ Райкин. “А что ты предлагаешь?” — резонно вы меня спросите. А я вам отвечу.

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

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

Особенно отзываются пункты «стройте компактные системы» и «лучший код — это отсутствие кода». Последний совет я превращаю в цитату из какого-то второсортного фильма про самураев: «Лучшая победа — та, которую ты одержал, не доставая меч из ножен» (думаю, сослуживцы за моей спиной уже закатывают глаза). И, конечно, бесконечные разговоры про легендарных 10x-программистов постоянно хочется прервать советом не связываться с 0,1x-программистами (которые реально существуют, в отличие от 10x).