В этом посте я кратко поведаю о разных интересных возможностях XRay (клиент и сервер для протоколов VMess, VLESS, Trojan и других, в том числе с XTLS-Reality и XTLS-Vision), о которых, кажется, мало кто знает, но которые могут оказаться очень полезными.

Оглавление:

- Фрагментирование запросов
- QUIC-транспорт
- Мониторинг и автоматический выбор outbound'а
- Сбор статистики
- Browser dialer

В свете последних событий (для потомков: гуглим Россия, Украина, 24 февраля 2022), приведших к введению санкций против России в сфере высоких технологий и, в частности, микроэлектроники, я часто слышу вопрос: а что дальше? В каком сейчас состоянии российское микроэлектронное производство? Россия сможет создать полностью локальное производство чипов?

Выборы архитектора происходят всегда по‑разному. Это только политиков одинаково выбирают — по принципу лишь бы не этот… А вот с архитекторами везде свой сценарий. Где‑то в половине мест сидят эстеты и предлагают что‑то изобразить да обсудить. Четверть мест явно химики с мензурками в сейфе — спрашивают про правильный код или просят пузырьковую сортировку. Ещё реже циркачи просят пожонглировать стеклянными шариками на башне или погонять трамваи. Остальные просто хотят обсуждения с залом. Как бы намекая, что нельзя вот так просто прийти в училище имени Гнесиных с фамилией Иванов. Кто‑то из гильдии таки должен сказать, что в мальчике что‑то есть.

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

Испытательный срок – сложное время. Нужно разобраться в проекте, процессах. Привыкнуть к новой компании. А если ты тимлид? Ко всему этому нужно еще и быстро разобраться с командой и показать какие-то результаты руководству. Сложность возрастает.

Что делать тимлиду, чтобы эффективно пройти испытательный срок? Приглашаю почитать.

Есть у нас такая традиция – начальство не любить. А как быть, если начальство – ты сам? Хочется ж быть хорошим, всегда и для всех. Но получается так, увы, редко.

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

В кульминационный момент Второй мировой войны ЦРУ выпустило потрясающую книгу Simple Sabotage. В ней изложены различные способы, которыми диверсанты могут снижать продуктивность компании. Некоторые из этих советов не стареют, например, раздел «Общие помехи организациям и производству»:

1. Настаивайте на том, чтобы всё выполнялось через «каналы». Не допускайте того, чтобы для ускорения реализации решений выбирались кратчайшие пути.

2. Делайте «доклады». Говорите как можно чаще и пространнее. Иллюстрируйте свои «идеи» долгими историями из жизни и ссылайтесь на личный опыт. С готовностью делайте «патриотические» комментарии.

3. По возможности отправляйте все вопросы в комитеты для «более глубокого изучения и рассмотрения». Стремитесь делать комитеты как можно больше, не менее чем из пяти членов.

4. Как можно чаще поднимайте вопросы о несущественных проблемах.

5. Спорьте о чётких формулировках в общении, протоколах, резолюциях.

6. Возвращайтесь к темам, по которым было принято решение на последнем совещании, и пытайтесь повторно открыть вопрос о целесообразности этого решения.

7. Советуйте «быть аккуратными». Будьте «разумны» и подталкивайте других участников совещаний к «разумности», к тому, чтобы они избегали спешки, которая может в будущем вызвать неудобства или сложности.

8. Беспокойтесь о правильности каждого решения, поднимайте вопрос о том, будет ли рассматриваемое действие относиться к юрисдикции группы или оно может вызвать конфликт с политикой какого-то более высокого эшелона.

Меня всегда поражало, насколько хорошо эти советы прошли проверку временем.

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

Вроде все логично. Но как же быть с этим:

Я работаю в крутейшей инжиниринговой компании!

Я работаю над интересным проектом!

Мне нравится мой график, удобно ребенка из сада забирать.

У меня клевый босс, мы с ним на одной волне.

Подробный рассказ о том, как я свой дом и сад сделал умными. С фото, техническими деталями, стоимостями и выводами на будущее.

Подошли к концу 3 года моей работы преподавателем в одном из рейтинговых московских колледжей, готовящих будущих IT специалистов. Хочу раскрыть часть внутренней кухни системы среднего профессионального образования (СПО), имеющей общие черты как с системой высшего образования, так и школьного.

В статье:

• Куда попадают те, кто ушёл после 9-го;

• Кого берут в преподаватели;

• С кем приходилось работать;

• Соревнования, от которых зависит зарплата;

• Роль государства, патриотическое воспитание;

• Плюсы и минусы работы преподавателем;

• Что делать, если вы студент.

В 2019 году я был на очередной конференции по IoT и до гостиницы меня подвозил местный коллега. По пути мы обсуждали умное ЖКХ и, конечно же, коснулись LoRaWAN. Коллега сказал фразу, которая надолго мне запомнилась: «Мне кажется, будто рынок сопротивляется внедрению Лоры».

Да, в 2019-м именно так всё и было. Лору тогда попробовали внедрить в ЖКХ и в промышленности. Проекты строили с огромным упорством, взлетали они тяжело, часто сразу падали. После общего подъёма и веры в тему IoT парой лет ранее столкновение с реальностью воспринималось болезненно. Но уже тогда я потихоньку начал признаваться себе: не будет Лоры в каждом утюге. Очень уж ограничен круг её использования. А всякие NB-IoT и Wi-Fi 6 её просто добьют. 

Каково же было мое удивление, когда в 2022 году технология обрела вторую жизнь! Несколько крупных игроков (ММК, Сибур) начали развёртку сети на своих заводах. 

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

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

Мне нужен был гайд, который сочетает эти две вещи: сначала «почему так принято», а затем — «как правильно делать». В результате такой гайд мне пришлось написать самому. Его цель — объяснить разработчикам с любым бэкграундом, что такое метрики, как правильно о них думать и осмысленно использовать. Сначала гайд жил во внутренней документации Точки, но я решил сделать его публичным — возможно, кому-то этот опыт будет полезен. Разбираться будем с Prometheus и Grafana. Если у вас другой стек — не страшно. Мы затронем и фундаментальные темы: например, перцентили, производные и кардинальность.

Гайд будет выходить как цикл статей. Сначала посмотрим на архитектуру: как собираются метрики и где хранятся. Дальше разберемся с типами метрик — они не так просты, как кажется. Потом придется немного отвлечься на математику (но только с инженерной точки зрения!). И, наконец, научимся писать запросы, но не просто так: сразу посмотрим на разные грабли и неочевидные моменты.

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

Под катом: формат данных, способы отправки, типы метрик и их применение, кардинальность.

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

Крепостными становятся, обычно, ИТ-специалисты, работающие в штате клиентов. Соответственно, это ИТ-директора, программисты (обычно 1С) и сисадмины. Есть ли такое в ИТ-компаниях – не знаю, тут интересно вас послушать.

Кратко напишу, что это за дичь.

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

Желание неукоснительно придерживаться ТЗ при недостигнутых задачах бизнеса.

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

Знаю-знаю, вы – крутой программист и тут же возразите мне – а что же, я должен предвидеть все, что нужно бизнесу? Должен догадаться, чего хочет заказчик? Бесконечно реализовывать его странные хотелки?

А имеете ли вы моральное право задавать такие вопросы? Проверьте, что из этого списка вы сделали для этого:

Вы не используете очередь? Вы просто не умеете её готовить. Но прежде чем этому научиться, нужно разобраться, что это вообще такое и где это применяется. Потому что большинству достаточно 10 000 запросов в секунду, а это дает любой брокер. Но если вам нужно больше, придется погрузиться в очереди достаточно глубоко.

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

Queue (очередь) — структура данных на диске или в оперативной памяти, которая хранит ссылки на сообщения и отдает их копии consumers (потребителям). Queue представляет собой Erlang-процесс с состоянием (где могут кэшироваться и сами сообщения). 1 тысяча очередей может занимать порядка 80Mb.

Binding (привязка) — правило, которое сообщает обменнику в какую из очередей должны попадать сообщения.