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

В общем-то вся инструкция сводится к фразе "поднимите с роутера WireGuard соединение КУДА_НИБУДЬ и настройке отдельную WiFi сеть с этим WireGuard как внешним соединением", но зачастую спрашивающие хотели бы видеть скучную пошаговую инструкцию.

Чтобы не плодить сущности – подготовил статейку с пошаговой инструкцией.

TL;DR

Игры от Zachtronics:

TIS-100, EXAPUNKS, SHENZHEN I/O

Про создание процессора от логических элементов и до написания кода на ассемблере: браузерная бесплатная nandgame.com, более продвинутая Turing complete.

Если Вам нравится какая-то игра из перечисленных - наверно, и остальные тоже подойдут. В каждую из них я наиграл по 30+ часов, получил кучу удовольствия и научился чему-то новому.

Всем привет! Я Аня Шабаева, HRG в AGIMA. Как-то я уже обсуждала с вами, стоит ли делать тестовое задание. Сегодня хочу рассказать, как дойти до этапа с тестовым. Как сделать свое резюме запоминающимся? Как правильно показать свои навыки, чтобы получить должность мечты? Наливайте чаёк и давайте разбираться. 

Рыская по интернетам, зашел на страницу про URI и спустя несколько часов осознал, как мало я знал об этом монстре. Признаюсь, до этого я думал, что URI это либо URL, либо URN. Но это не так! Есть и другие варианты идентификации ресурса в сети.

Эта статья познакомит вас с новыми типами, представленными в C# 7.2: Span и Memory. Я подробно разберу Span<T> и Memory<T> и покажу, как работать с ними в C#.

От переводчика

Привет, Хабр!

Часто некоторые проекты требуют от нас все более новых подходов к решению задач. Одна из таких задач - эффективное взаимодействие управляемого кода .NET с нативным кодом, которое позволяет по максимуму использовать ресурсы ОС и другого ПО, написанного не на .NET.

Интероперабельность необходима для использования уже существующих библиотек, написанных на C, C++ или других языках, которые выполняют важные или высокопроизводительные функции. Таким образом открывается возможность интеграции .NET-приложений с различными системными компонентами и устройствами, доступ к которым возможен только через нативные API.

В основе интероперабельности лежит взаимодействие управляемого кода. Управляемый код исполняется под управлением CLR — виртуальной машины .NET, которая обеспечивает такие возможности, как сборка мусора, безопасность типов и другие виды абстракции. А вот нативный код компилируется напрямую в машинный код, специфичный для конкретной платформы, и исполняется ОС без промежуточных слоев, что обеспечивает высокую производительность и прямой доступ к ресурсам системы...

В этой статье я хотел бы рассказать о различиях между сборкой мусора в Unity (IL2CPP) и .NET. Несмотря на то что IL2CPP существует более 10 лет, я до сих пор встречаю недоумение, когда беседа заходит на тему Garbage Collector (GC) касательно Unity. Считать реализацию GC в .NET, ровно как и в JVM, единственным существующим решением — не верно. А тем более принимать такую реализации как "по умолчанию" используемую в Unity — есть заблуждение. Надеюсь эта статья будет полезной, даст верное понимание и устранит заблуждения. Ну а в конце статьи затронем грядущие серьезные изменения в Unity.

Придерживаясь великой цитаты "правила созданы для того, чтобы их нарушать", давайте нарушим какие-то основополагающие правила CLR. Как на счет того, чтобы послать GC с его работой в отставку и самим заняться размещением в памяти экземпляров классов? Заодно разберемся, как все это работает где-то там под капотом CLR.

Давным-давно, когда Linux был ещё на ядре 2.6, а PHP5 был глотком свежего воздуха, я впервые заинтересовался миром веб-технологий. Читал учебники, статьи, зависал на форумах, но все равно мало мог понять как код, который я вижу на экране, превращается в волшебные сайты с кнопками, формами и анимациями. Узнал про LAMP и его аналоги для Windows, узнал, что, оказывается, есть хостинги, где такие сайты размещаются. Как только появился внешний интернет без трафика, я поспешил перенести свои локальные поделия во внешний мир, попутно узнав про замечательный протокол FTP. Просто мир волшебных открытий был для меня, особенно когда узнал, что не нужно писать свой форум с нуля, а можно использовать что-то из phpBB, vBulletin и других уже готовых движков.

И когда я много лет спустя переключился в мир .NET, перечисленные ранее умения сыграли со мной злую шутку – я долго не мог понять, как мне найти хостинг для .NET приложений. Почему все известные мне хостинги с лёгкостью предоставляли возможность развернуть PHP приложения, причём даже предлагая какие-то предустановленные версии CMS, но днём с огнём не сыщешь хостинг под .NET. Мое непонимание принципа развертывания приложений усугубляли статьи, которые предлагали их размещать в подходящих сервисах типа Heroku, Digital Ocean или Azure – ведь это так просто и дешево…

Поэтому предлагаю максимально подробно рассмотреть вопрос публикации .NET приложений в арендованном VPS.

Совсем скоро, 29-30 ноября в Санкт-Петербурге и 06-07 декабря — в Москве мы запустим шестой семинар по .NET. На этот раз — по теме многопоточки и конкурентности. Мы уже писали об этом пару раз на Хабре, но сегодня есть отдельный повод для этого: на семинаре настоящий эксклюзив. Будет описана работа гибридного примитива синхронизации: Monitor. Да, всем привычная вещица достойна отдельного доклада. Ведь он в своей работе учитывает и частоту процессора и количество ядер, учитывает lock convoy/starvation и вообще, очень сложен.

А в конце статьи развлечения ради предложу пройти парочку QUIZов по многопоточке.

Продолжаем говорить о производительности и оптимизации кода. Сегодня поговорим о том, как и зачем оценивать сложность алгоритмов,  а также наглядно покажем, как эта сложность влияет на производительность кода.

Структура объектов в памяти

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

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

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