Многие знают о существовании такого ПО, как 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.

Меня, по ряду причин, всегда завораживала эмуляция. Программа, которая выполняет другую программу… Мне эта идея кажется невероятно привлекательной. И у меня такое ощущение, что тот, кто напишет подобную программу, не пожалеет ни об одной минуте потраченного на это времени. Кроме того, написание эмулятора — это очень похоже на создание настоящего компьютера программными средствами. Мне было очень интересно разбираться в устройстве компьютерной архитектуры, писать простой HDL-код, но эмуляция — это гораздо более простой способ ощутить себя тем, кто своими руками создаёт компьютер. А ещё, в детстве, когда я впервые увидел игру Super Mario World, я поставил себе цель, которая до сих пор не потеряла для меня ценности. Она заключается в том, чтобы полностью понять то, как именно работает эта игра. Именно поэтому я уже некоторое время подумываю о написании эмулятора SNES/SNC. Недавно я решил, что пришло время сделать первый шаг к этой цели.

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

Это — последний материал из серии четырёх статей (часть 1, часть 2, часть 3), посвящённой реализации epoll. Тут речь пойдёт о том, как epoll передаёт события из пространства ядра в пользовательское пространство, и о том, как реализованы режимы срабатывания по фронту и по уровню.



Эта статья написана позже остальных. Когда я начинал работу над первым материалом, самой свежей стабильной версией ядра Linux была 3.16.1. А во время написания данной статьи это уже версия 4.1. Именно на коде этой версии ядра и основана данная статья. Код, правда, изменился не особенно сильно, поэтому читатели предыдущих статей могут не беспокоиться о том, что что-то в реализации epoll очень сильно изменилось.

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

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