В конце технического интервью, если кандидат ответил на вопросы и справился с задачами, у нас есть время для свободных вопросов, которые можно задать команде или кому-то из интервьюеров. Эту практику я переносил из компании в компанию, и она всегда помогала разрядить обстановку или вывести человека на разговор, если он был напряжен во время общения. Вопросы могут быть любые, кроме личных или тех, что под NDA. Обычно кандидаты задают технические вопросы по стеку, пайплайнам, иногда пытаются задать каверзные вопросы, особенно по плюсам, чтобы проверить нас. Иногда мы не можем ответить на них. Вопросы в стиле Google — например, «почему таблетки круглые?» — тоже встречаются, но недавно на одном из интервью прозвучал вопрос, на который вроде все и знали ответ, но никто сразу не смог его дать. Вопрос звучал так: «Какие общие технологии и решения появились в процессорах с времён 486, которыми мы часто пользуемся?»

Вопрос действительно интересный — что нового появилось, чем мы пользуемся каждый день? Что умеют современные процессоры, чего не могли процессоры год или два назад, пять или десять лет назад, сорок лет назад? Мы просто используем миллиарды транзисторов, даже не зная, как они работают. Покопавшись в Википедии, на сайте Агнера Фога и в документации Intel, я составил список того, что появилось и используется в современных процессорах. Всё, что указано ниже, относится в основном к x86 и консолям, если не указано иное. Поскольку консоли после третьего поколения PlayStation — фактически ПК с минимальными отличиями, речь дальше пойдёт в основном о ПК. История имеет склонность повторяться, и многое из того, что мы сейчас имеем, вводилось не один раз, просто под разными названиями.

Во многих современных домах подъездное освещение часто включает в себя два контура: тусклое освещение вечером и яркое днём. Но мой многоквартирный дом не настолько современный и в подъезде для освещения использовались обычные лампы с патроном e27. Они всегда горят настолько ярко, насколько мощная в них установлена лампа, а включаются по датчику движения, установленном на месте обычного выключателя.

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

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

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

Но это не решало проблему двух контуров освещения: тусклого вечером и яркого днём.

На чем только уже не запускали Doom. Мы же будем запускать Linux. Да не где-нибудь, а на Python. Да-да, прямо вот внутри него, где в качестве среды выполнения будет выступать интерпретатор Python. Ну как... Не будем пытаться переписать ядро и другие части Linux на этот язык, а попробуем написать (точнее портировать) виртуальную машину на Python и уже в ней запускать ОС.

Начнем с позитивного, а именно с плюсов такого решения.

– Можно будет запустить Linux вообще везде, где есть интерпретатор Python.

– Можно использовать как бенчмарк конкретного интерпретатора.

– Веселимся, пока все это пишем и отлаживаем. Пожалуй, это самый главный плюс.

Минусы: будет работать оооочень не быстро (ну логично же).

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

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

В моей первой статье на сайте об автоматизации оборудования Juniper в качестве подопытного выступал коммутатор, который стоит под столом, и до которого имеется полный прямой доступ по сети. Однако, такая ситуация скорее исключение. Практически всегда сейчас используют для доступа на сетевые устройства Jump Host. В этой статье я хотел бы рассмотреть, какие решения мы можем использовать при автоматизации работы с сетевым оборудованием на Python, чтобы учесть наличие промежуточного устройства.

Представьте себе время, когда персональные компьютеры только появились, а концепция графического интерфейса пользователя была еще далекой мечтой. Эта эпоха ознаменовала собой расцвет MS-DOS. Почти пятнадцать лет DOS была основой, от которой зависели тысячи прикладных программ, работающих на миллионах IBM PC и клонов PC.

В статье рассмотрим, как появилась MS-DOS. Расскажем, почему создателя MS-DOS обвиняли в плагиате, как IBM совершила огромную коммерческую ошибку, и что позволило Microsoft занять лидирующие позиции на рынке ПО.

Python 3.13 — отличный релиз, полный различных фич и улучшений, но уже есть тонна статей, которые подробно разбирают release notes. Если вам нужна хорошая выжимка — у RealPython есть хорошая статья, но я не вижу смысла проходиться по ним еще раз в этой статье.

Так что мы не будем говорить про новый REPL, no‑GIL сборку, экспериментальный JIT‑компилятор, устаревшие штуки, новые плюшки системы типов или улучшенные сообщения об ошибках (как всегда, мое любимое).

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

Решение проблемы зачастую упирается в использование роутеров с ограниченными ресурсами, таких как ASUS RT-N12 VP B1 с ROM/ОЗУ 8/32 Мб. В этой статье я расскажу, как настроить связку ByeDPI и Redsocks на роутере с OpenWRT, даже если ваш роутер далеко не топ по характеристикам.

## Зачем нужны ByeDPI и Redsocks?

ByeDPI — это утилита для обхода DPI (Deep Packet Inspection), которая изменяет сетевые пакеты таким образом, чтобы они не распознавались системами фильтрации трафика.

Redsocks — это прокси-инструмент, который перенаправляет трафик через SOCKS или HTTP прокси, даже если приложение не поддерживает прокси напрямую.

Сочетание этих двух инструментов на роутере позволяет обходить блокировки на уровне провайдера, обеспечивая свободу в домашней сети без необходимости установки ПО на каждом устройстве.

Почему я задался целью обойти время применения политик к локальным компьютерам?

Обычный интерес — как это сделать. Как сказал один комментатор — работа ради работы.

Для чего все это надо — на это вопрос я сам себе не смог ответить. Но охота пуще неволи. Очень хотел найти решение.

Методом серфинга в Инете начал собирать разную информацию по политикам, времени их применения.

В итоге нашел все необходимое. Нужное оставил, ненужное отсеял.

Это ответ, точнее мысли по статье, опубликованной на Хабре: «Зарплаты в IT: сравнение Германии и России — где программисты и айтишники получают больше». Советую сначала ее прочитать и потом уже здесь продолжить.

Здравствуйте, дорогие читатели!

Меня зовут Алексей Карпенко. Проработав в разработке игр больше 5 лет, разрабатывая экономику и баланс для проектов, принесших более 150M$+ выручки, я решил подытожить все свои знания в экономике, балансировке и монетизации игр в одну работу, и поделиться с другими разработчиками.

Материалов в данной сфере совсем немного, на момент написания статьи осень 2024 года, всего +-20 научных статей и пару книг, одна из которых 800 страничный фолиант от Brenda Romero and Ian Schreiber. Я собрал всю эту информацию в одной статье, а также добавил свои знания и опыт, поэтому я считаю что мои знания будут полезны для вас.

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

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

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

Приятного чтения! 😊

Делимся книгами, видео и телеграм-каналами в разных областях: от проектного менеджмента до работы с базами данных. Полезными ресурсами и материалами поделились наши коллеги из beeline cloud, а также авторы нашего медиа «вАЙТИ».

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

Производство хлеба «Никитин-хлеб» закрылось 8 октября 2024 года спустя ровно 9 лет: с 8 октября 2015 года.

Мы покупали новое оборудование, открывали новые точки, пекли по 1 700 буханок в день, но в 2024-м выручка резко упала, а расходы также резко выросли.

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

Всем привет! Это новая подборка примечательных новостей из мира IT и технологий. Смотрим на самые громкие заголовки российских СМИ, вспоминаем самые забавные темы недели и пытаемся разобрать самые важные явления. Ничего серьезного — просто дайджест любопытных новостей для тех, кто не успевает за ними следить в будни.

Современное сообщество программистов разбито на два лагеря - на тех, кто любит языки программирования с управляемой памятью, и тех кто их не любит. Два лагеря яро спорят друг с другом, ломая копья по поводу преимуществ в каком-то из аспектов программирования. Языки с неуправляемой памятью представляются как более быстрые, управляемые, контролируемые. А языки с управляемой памятью считаются более удобными в разработке, в то время как их отставание по скорости выполнения и потребляемой памяти считается несущественным. В этой статье мы проверим, так ли это на самом деле. Со стороны олдскульных языков программирования выступит мастодонт мира разработки - С.

Сторону языков последних поколений будет представлять С#.

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