Иллюстрация из книги «Справочник киберсантехника»

Протокол SSH — очень мощный инструмент, который используется для удалённой консоли или передачи файлов (scp, sftp). Есть менее известная функция перенаправления портов. Такие SSH-туннели используются для пробития файрволов и хорошо скрываются от обнаружения стандартными средствами мониторинга типа Trisul, Zeek (ранее был известен как Bro), Suricata и Snort. Поэтому для их обнаружения в корпоративной сети используются другие методы.

Время выполнения общих команд Git в Ubuntu и Windows 11 (в секундах, чем меньше — тем лучше), источник: OpenBenchmarking.org

В далёком 2013 году один из разработчиков Microsoft детально объяснил, в чём главные технические проблемы при разработке ядра Windows NT. Спустя десять лет Windows 10/11 работает на том же ядре, а многие старые проблемы так и остались нерешёнными.

Хотя в ряде задач Windows превосходит Linux, но в большинстве тестов она действительно медленнее. По словам разработчика, это отставание усугубляется, а причина «социальная». Суть в том, как организован процесс разработки, внесения изменений в ОС. Если в мире опенсорса это открытый процесс, который несёт пользу и улучшает систему, то в мире корпоративного ПО зачастую изменения вносятся по причинам эгоизма, желания продвижения по карьерной лестнице, славы и т. д. Всё это ведёт к деградации продукта.

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

26 мая 2023 года произошёл массовый дефейс веб-серверов национального сегмента сети интернет .РФ. В качестве цели атаки выступила CMS «Битрикс».

В ходе расследования выяснилось, что атака подготовлена заранее. Подготовка велась с 2022 года через известные уязвимости, включая CVE-2022-27228. Техническое описание см. на форуме разработчиков. Возможно, это самая крупная атака против национального сегмента .РФ в его истории.

Компания CyberOK выпустила отчёт c описанием атаки и разъяснением необходимых действий для того, чтобы удалить с сервера бэкдор, устранить уязвимости «Битрикса» и восстановить приложение. Также приведены рекомендации по защите веб-приложения.

Многие знают о существовании такого ПО, как TeamViewer, но не все в курсе о нестандартных сценариях его использования. Знали ли вы, что можете легально использовать сессии, неограниченные во времени? Это осуществимо благодаря возможности TeamViewer подключаться не только с использованием уникального ID, но и по IP-адресу.

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

Картинка, конечно, стронгли анрилейтед

Разные трюки я тестировал на Google Chrome 107.0.5304.107 и Mozilla Firefox 107.0 на Windows 10.

Чтобы результаты всегда были железно воспроизводимыми, я отключил все С-State’ы, ядра зафиксировал на 5 ГГц.

У меня 9900К, это Coffee Lake c AVX256, какие оптимизации применит Jit для вашего процессора — я не знаю, результат на вашем компьютере может отличаться от моего, в т.ч. из-за микроархитектуры процессора.

Скорость парсинга кода тоже входит в бенчмарк, поэтому браузер с быстрым парсером будет впереди.

Любая работа java-программиста опирается на базис, под которым подразумевается не только непосредственно знание самого языка программирования, но также и знание дополнительных компонентов, без которых программирование в чистом виде, становится достаточно затруднительным либо неконкурентоспособным по времени. Именно об этом мы поговорим в этой статье.

Казалось бы, для чего редакции может понадобиться telegram-бот? Мы смогли вполне точно ответить на это, когда число наших авторов начало превышать разумные возможности редакторов. В новых экономических реалиях ценна каждая рабочая минута, потому встала задача убрать часть работы, связанной с повторяющимися вопросами, которые можно было бы свалить на бота, для улучшения комфорта взаимодействия всех сторон и, конечно, экономии бесценного времени. А учитывая, что большая часть общения происходит именно внутри телеграма, то и было принято решение завести себе там электрического помощника. Как говорится: телеграм-бот — это не только 40 строчек кода, но ещё и очень полезный выхлоп.

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

Разработчик программного обеспечения в нашем современном мире имеет самое большое влияние. Буквально нет ни одного уголка человеческой жизни на этой планете, на который не повлияло бы качество нашего программного обеспечения Composing Software Eric Elliott. Но вместе с ростом количества разработчиков в современном мире растёт ли качество программного обеспечения? Да, количество разработчиков растёт, но растёт ли количество хороших разработчиков?

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

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

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

Такими словами обычно начинают стендапы в клубе анонимных алкоголиков. И сегодня я пришёл сюда, чтобы рассказать вам о моей зависимости. Может это и не зависимость даже, а вполне нормальное поведение. В любом случае я хочу вынести это на ваш суд. Итак, вот моя проблема: я очень хорошо прохожу собеседования на позицию старшего разработчика и соглашаюсь на эти собеседования раз в месяц, если меня приглашают. Звучит не очень впечатляюще? Насколько хорошо я прохожу собеседования? Последние шесть собеседований я прошёл с лёгкостью и по результату каждого из них получил оффер. А если сложить предложенные суммы ЗП из этих офферов, то получится сумма немного превышающая 21 тысячу евро! Конечно, на финишной прямой с потенциальным работодателем у меня устанавливается почти полное взаимопонимание, мы улыбаемся друг другу в скайпе, мне задают последний вопрос, что-то вроде: «а что тебя не устраивает на текущем месте работы, почему ты в поиске?». И вот в этом месте я добавляю изюминку, говорю: «я не в поиске, просто мне предложили пройти собеседование, и я согласился — вдруг, что интересное подвернётся». Возможно, это моё заявление и стреляет точнее всего.

Перед вами — седьмая (заключительная) часть серии статей о разработке REST-серверов на Go. В предыдущих статьях мы занимались, в основном, различными подходами к разработке REST API для простого приложения, автоматизирующего управление задачами. Сегодня мы исследуем кое-что совершенно новое и поговорим о том, как сделать похожий API, пользуясь не REST, а GraphQL.



Хотя тут я уделяю определённое внимание причинам выбора GraphQL и сравнению GraphQL и REST, это здесь не главное. Есть множество статей, освещающих эти вопросы, и я советую вам поискать их и почитать. Главная цель этого материала заключается в том, чтобы привести пример создания GraphQL-сервера на Go. Для того чтобы не усложнять нашу задачу, этот сервер использует модель данных, очень похожую на модель, реализованную в одном из вариантов сервера из предыдущих материалов (речь идёт о простом бэкенде, дающем возможность работать со списком задач).

Перед вами — шестой материал из серии статей, посвящённых разработке REST-серверов на Go. Наша сегодняшняя тема — безопасность, а именно — аутентификация. Если бы сервер, разработанный в предыдущих материалах, был бы развёрнут, и к нему мог бы обратиться кто угодно, то у любого, имеющего выход в интернет, был бы полный доступ к его API. Хотя некоторым REST-серверам это вполне подходит, такой сценарий работы с сервером желателен далеко не всегда. Обычно как минимум часть API должна быть защищена таким образом, чтобы доступ к ней могли бы получить лишь аутентифицированные пользователи.

Это — пятый материал из серии статей, посвящённой разработке REST-серверов на Go. Здесь мы поговорим о middleware. У меня есть материал, посвящённый жизненному циклу HTTP-запросов в серверах, написанных на Go. Для того чтобы разобраться в том, о чём пойдёт речь ниже, вам нужно ориентироваться в этой теме.

Перед вами четвёртый материал о разработке REST-серверов на Go. Здесь мы поговорим о том, как можно воспользоваться OpenAPI и Swagger для реализации стандартизированного подхода к описанию REST API, и о том, как генерировать Go-код на основе спецификации OpenAPI.

Сегодня, в третьей части серии материалов, посвящённых разработке серверов на Go, мы займёмся реализацией нашего REST-сервера с использованием Gin — одного из самых популярных веб-фреймворков для Go. Вот код, который мы будем тут обсуждать.

Перед вами второй материал из серии статей, посвящённой разработке REST-серверов на Go. В первом материале этой серии мы создали простой сервер, пользуясь стандартными средствами Go, а после этого отрефакторили код формирования JSON-данных, вынеся его во вспомогательную функцию. Это позволило нам выйти на достаточно компактный код обработчиков маршрутов.


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



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

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

Первый вопрос разработчиков, которые только начинают применять Go, часто выглядит так: «Какой фреймворк стоит использовать для решения задачи X». И хотя это — совершенно нормальный вопрос, если задавать его, имея в виду веб-приложения и серверы, написанные на многих других языках, в случае с Go при ответе на этот вопрос нужно принять во внимание множество тонкостей. Существуют серьёзные аргументы как «за», так и «против» использования фреймворков в Go-проектах. Я, работая над статьями из этой серии, вижу своей целью объективное разностороннее исследование этого вопроса.

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

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



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

Мы уже создали вполне рабочий эмулятор CHIP-8, но он, к сожалению, получился очень медленным. Почему? Если заглянуть в его главный цикл — можно увидеть, что данные на экран выводятся после выполнения каждого шага цикла. При включённом vsync SDL пытается привязать скорость рендеринга к частоте обновления кадров дисплея (возможно это — 60 Гц). Для нас это означает то, что метод SDLViewer::Update, почти при каждом его вызове, долго будет находиться в заблокированном состоянии, ожидая сигнала vsync от монитора.



Насколько быстро должен работать наш эмулятор? Точный ответ на этот вопрос дать не так уж и просто. На реальном компьютере на выполнение операций с разными кодами нужно разное время, но известны ориентировочные временные показатели выполнения различных операций. Можно выполнить инструкцию, выяснить то, сколько времени её выполнение должно занимать на реальном аппаратном обеспечении, а после этого «усыпить» программу до того момента, когда можно будет продолжать работу. Но тут есть одна проблема, которая заключается в том, что у нас, при таком подходе, нет доступа к временным параметрам работы CPU. На выполнение большинства этих инструкций должна уходить пара микросекунд, но на современных системах «усыплять» программы можно, как минимум, на одну миллисекунду.

Недавно мы опубликовали перевод первого материала из серии статей, посвящённой эмуляции компьютера. Автор этих статей подробно рассказывает о написании интерпретатора CHIP-8 на C++. В той публикации мы устроили опрос о целесообразности перевода продолжения цикла. Почти 94% тех, кто принял участие в опросе, продолжение перевода поддержали. Поэтому сегодня мы представляем вашему вниманию второй материал о CHIP-8.