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

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

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

В связи с переходом на отечественное ПО в организации пришлось искать замену Windows утилиты администрирования кластера. После изучения вопроса выяснилось, что для администрирования кластера 1С существует 3 подхода, но они не совсем подходят для комфортной работы.

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

Приглашаю под кат, чтобы посмотреть, что получилось и обсудить, как можно сделать ещё лучше :)

Привет! Я Женя, CPO в корпоративном мессенджере Compass. В свободное время люблю покопаться в чем-то новом. Недавно решил поглубже закопаться в нейрофизиологию коммуникации, чтобы понять, как мы воспринимаем речь, как мы ее «создаем» и в какой точке возникают сложности с пониманием друг друга. Эти знания пригодятся для любого общения, в том числе и для работы.

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

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

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

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

Что вам приходит в голову при слове «Golang»? Google и микросервисы? Я тоже так думал, но реальность оказалась значительно интересней.

В арсенале специалистов по информационной безопасности и пентесту есть много инструментов и методов для защиты безопасности информационных систем и сетей. Рассказываем о популярных.

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

Данную статью я написал после того, как сделал собственную библиотеку, генерирующую сообщения протокола Kerberos, а также после того, как я протестировал «стандартный клиент» Kerberos в Windows — набор функций SSPI. Я научился тестировать произвольные конфигурации сервисов при всех возможных видах делегирования. Я нашёл способ, как выполнять пре‑аутентификацию в Windows как с применением имени пользователя и пароля, так и с помощью PKINIT. Я также сделал библиотеку, которая умещает «стандартный» код для запроса к SSPI в 3–5 строк вместо, скажем, 50-ти.

Хотя в названии статьи фигурирует «простыми словами» однако эта статья предполагает, что читатель уже имеет какое‑то представление о Kerberos.

Всем привет! Я расскажу, с помощью каких алгоритмов и архитектуры можно разработать с нуля интерактивную диаграмму Ганта, способную без лагов отображать тысячи задач.

Вопрос из области ненормального программирования: насколько сложные программы вы сможете написать на питоне, не пользуясь в принципе переменными (а также агрументами функций), за исключением пары глобальных массивов? Правильный ответ: да любой сложности. Если что-то можно сделать на ассемблере, то уж на питоне и подавно! Правда, пусть лучше код вместо меня сгенерирует машина :)

Продолжаем разговор о минималистичном компиляторе, который вполне реально написать за выходные. Задачей стоит транслировать код из придуманного мной языка в x86 ассемблер. Мой компилятор состоит из 611 строк кода, при этом не имеет ни единой зависимости:

ssloy@khronos:~/tinycompiler$ cat *.py|wc -l

611

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

Итак, тема сегодняшнего разговора: генерация кода на питоне без использования переменных.

Привет! Меня зовут Денис, я - разработчик ПО SEDMAX. Это промышленное ПО для сбора и визуализации данных в энергетике. Как и у всех, у нас бывают баги. Мне бы хотелось поделиться опытом в поиске таких багов, а так же порассуждать на тему того, что необходимо было сделать, чтобы баг не появился. У нас серверная часть написана на go в виде некоторого множества сервисов, поэтому специфика большинства багов будет асинхронное взаимодействие, а код примеров представлен на go.

Хочу поделиться с сообществом простым и полезным шаблоном скрипта-обёртки на bash для запуска заданий по cron (а сейчас и systemd timers), который моя команда повсеместно использует много лет.

Сначала пара слов о том зачем это нужно, какие проблемы решает. С самого начала моей работы системным администратором linux, я обнаружил, что cron не очень удобный планировщик задач. При этом практически безальтернативный. Чем больше становился мой парк серверов и виртуальных машин, тем больше я получал абсолютно бесполезных почтовых сообщений "From: Cron Daemon". Задание завершилось с ошибкой - cron напишет об этом. Задание выполнено успешно, но напечатало что-нибудь в STDOUT/STDERR - cron всё равно напишет об этом. При этом даже нельзя отформатировать тему почтового сообщения для удобной автосортировки. Сначала были годы борьбы с использованием разных вариаций из > /dev/null, 2> /dev/null, > /dev/null 2>&1, | mail -E -s '<Subject>' root@.

В предыдущих статьях мы пришли к выводу, что для того, чтобы UI‑код не превращался в легаси, нам нужно отделить представление от бизнес‑логики и немного иначе, чем это делают Redux и Elm, так как оба подхода не позволяют сделать это полностью.

В данной статье мы порассуждаем о том, как такое разделение сделать.

React view как чистая функция состояния

React изменил наш подход к пользовательскому интерфейсу — его философия основана на простых, но мощных концепциях использования компонентов и однонаправленного потока данных.

Ещё считается, что React внес реактивность в пользовательский интерфейс, но это не так, так как шаблоны MVVM и фреймворки, которые сильно полагаются на реактивность, были введены раньше React. (Knockout и Angular с двойным биндингом данных, Ember.js Observable)

Эти концепции делают UI разработку не только интуитивнее, но и объединяют дизайн и разработку в одном инфополе. Кстати, Elm тоже полагается на подобные концепции и использует чистые композируемые функции представления без состояния.

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

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

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

Всем привет, я Алексей Сизиков, руководитель отдела User Experience в Yandex Cloud. В этой статье я хочу поделиться новостью: мы выпустили нашу дизайн-систему и библиотеку компонентов Gravity UI в опенсорс. 

Под катом — рассказ, зачем мы сделали Gravity UI, как его используем, в чём особенности и преимущества нашего подхода и как мы планируем развивать его дальше. А ещё — как настроить разные цветовые схемы в своих проектах и почему у нас четыре темы вместо двух стандартных.

В серии предыдущих статей я описывал, почему повсеместно используемые VPN- и прокси-протоколы такие как OpenVPN и L2TP очень уязвимы к выявлению и могут быть легко заблокированы цензорами при желании, обозревал существующие гораздо более надежные протоколы обхода блокировок, клиенты для них, а также описывал настройку сервера двух видов для всего этого.

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

Поэтому сегодня мы поговорим об установке и использовании графической панели 3X-UI для сервера X-Ray с поддержкой всего того, что умеет X-Ray: Shadowsocks-2022, VLESS с XTLS и т.д.

Компания Vinteo разработала уникальный на сегодняшний день групповой видео терминал - Vinteo ST. Терминал обладает гибким подключением аудио и видео периферии, имеет высокое качество и разрешение передачи видео вплоть до 4К, но самое главное - терминал Vinteo ST имеет встроенный сервер ВКС, позволяющий собирать на себе конференции до 20 участников без использования сервера видеоконференцсвязи или облачного сервиса ВКС.

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

Уникальный AV-концентратор от Yealink. Комплексное решение для ВКС

Обзор новой камеры Yealink UVC86: наведение на голос и режим лектора

Уникальная ВКС-камера от Yealink — оптимальное решение для ZOOM/Skype/Teams

В этой статье мы рассмотрим терминал Vinteo ST совместно с комплектом оборудования Yealink на базе уже хорошо известной камеры UVC84 и нового конференц-телефона CP965 с дополнительными беспроводными микрофонами CPW65.

Двухтрубные системы отопления тупикового и попутного типа. В чём разница и что об этом говорят современные строительные нормы.

Ранее в одной из статей я уже рассказывал об однотрубных системах отопления.

Теперь настала очередь рассмотреть особенности проектирования и эксплуатации двухтрубных систем, которые крайне популярны у частных домовладельцев в ИЖС.

Так же двухтрубные вертикально-стояковые системы отопления пытаются применять и в многоквартирных домах.

Далее мы рассмотрим гидравлический расчёт систем для одного этажа частного дома с периметром в те же 50м для дом 10х15м по внутренним стенам (150м.кв на этаж).

А позже попытаемся применить те же подходы для максимальной высоты 50м в стояковой системе высотного дома.

Тупиковая система

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