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

Другой вопрос, что мне субъективно не очень нравится, как объясняется его работа. Потому, предлагаю альтернативный подход, описанный в моей книге, .NET Platform Architecture.

Если мы с вами будем досконально разбираться, почему были выбраны именно эти два алгоритма управления памятью: Sweep и Compact, нам для этого придётся рассматривать десятки алгоритмов управления памятью, которые существуют в мире: начиная обычными словарями, заканчивая очень сложными lock-free структурами. Вместо этого, оставив голову мыслям о полезном, мы просто обоснуем выбор и тем самым поймём, почему выбор был сделан именно таким. Мы более не смотрим в рекламный буклет ракеты-носителя: у нас на руках полный набор документации.

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

В этой статье я рассмотрю компоненты платформы .NET Core 2.0, необходимые для загрузки и выполнения .NET Core-приложений, а также артефакты для двух возможных типов развертывания.

Текст объемный и рассчитан на:

• начинающих разработчиков, которые только знакомятся с платформой .NET Core;
• опытных разработчиков, выполняющих роль DevOps-инженеров в produсtion-окружении.

В статье не упоминается процесс создания приложений при помощи SDK (dotnet CLI), однако эта информация будет полезной для понимания, как работает SDK, а именно её основной компонент (ядро) — «драйвер» dotnet.dll, поскольку эта библиотека является управляемой сборкой и выполняется на .NET Core.

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

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

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

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

Привет! Меня зовут Макс Матюхин, я работаю в SRV-команде Badoo. Мы в Badoo не только активно пишем посты в свой блог, но и внимательно читаем блоги наших коллег из других компаний. Недавно ребята из Dropbox опубликовали шикарный пост о различных способах оптимизации серверных приложений: начиная с железа и заканчивая уровнем приложения. Его автор – Алексей Иванов – дал огромное количество советов и ссылок на дополнительные источники информации. К сожалению, у Dropbox нет блога на Хабре, поэтому я решил перевести этот пост для наших читателей.

Сразу о конце: в P.S. можно найти краткое содержание и понять — стоит ли это всё осмысленно читать. Скажу сразу — стоит, потому всё не так просто, как хотелось бы.

Сразу скажу, что есть статьи на Хабре о проверках Роскомнадзора, они интересные, но рассказывают несколько об ином (например, вот эта, эта или вот ещё одна).

О Роскомнадзоре (РКМ) ходят легенды: часть из них — мифы, часть — истории «о чёрной, чёрной комнате», а вот часть — сущая правда. Материал ниже — о том, как и когда ваш сайт может пострадать от РКМ и почему.

Двухместный стандарт в Сочи в отеле Bridge Mountain стоит 86 рублей за сутки на человека на 1-6 апреля, и его можно взять отдельно от тура за 860 рублей на 5 ночей

5 лет назад мы обнаружили, что «Букинг» продаёт отели, всякие «Скайсканеры» и AWAD — авиабилеты, и голову поднимает AB&B. Но никто не продаёт туры целиком. Я тогда сказал своему другу: «Мужик, давай продавать туры. Это же очень просто сделать!»

А дальше начались такие круги ада, что мы несколько раз проклинали тот день. Началось всё с довольно простой задачи — синхронизации туров и их поиска. А прикол был в том, что если до нас у туроператора искали только руками из офисов, то с нашими поисками-сравнениями (на один запрос «Травелаты» поднимается около 500–600 туров в общем) мы просто клали их сервера к едрене фене. И туры не находились. Вообще, системы бронирования были сделаны в 90-х годах, а некоторые системы бронирования авиабилетов тащат легаси ещё чуть ли не со времён телеграфа.

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

Хочу рассказать вам еще об одном способе балансировки нагрузки. Про Pacemaker и IPaddr (ресурс-агент) и настройке его для Active/Passive кластера сказано уже и так достаточно много, но информации по организации полноценного Active/Active кластера, используя этот модуль я нашел крайне мало. Постараюсь исправить эту ситуацию.

Для начала расскажу подробнее чем такой метод балансировки примечателен:

• Отсутсвие внешнего балансировщика — На всех нодах в кластере настраивается один общий виртуальный IP-адрес. Все запросы отправляются на него. Ноды отвечают на запросы на этот адрес случайно и по договоренности между ссобой.
• Высокая доступность — Если одна нода падает ее обязаности подхватывает другая.
• Простота настройки — Настройка осуществляется всего в 3-5 команд.
  

Wireless Society by JOSS7

Wi-Fi в офисах Mail.Ru Group за последние десять лет пережил несколько смен оборудования, подходов к построению сети, схем авторизации, администраторов и ответственных за его работу. Начиналась беспроводная сеть, наверное, как и во всех компаниях — с нескольких домашних роутеров, которые вещали какой-то SSID со статичным паролем. Долгое время этого было достаточно, но количество пользователей, площади и количество точек доступа стало расти, домашние D-Linkʼи постепенно заменили на Zyxel NWA-3160. Это уже было относительно продвинутым решением: одна из точек могла выступать в качестве контроллера для остальных и давала единый интерфейс для менеджмента всей сети. Какой-то более глубокой логики и автоматизации софт NWA-3160 не давал, только возможность настройки подключенных к контроллеру точек, пользовательский трафик обрабатывался каждым устройством независимо. Следующей сменой оборудования стал переход на контроллер Cisco AIR-WLC2006-K9 + несколько точек доступа Aironet 1030. Уже совсем взрослое решение, с безмозглыми точками доступа и обработкой всего трафика контроллером беспроводной сети. После еще была миграция на пару AIR-WLC4402-K9, сеть уже выросла до сотни точек Cisco Aironet 1242AG, 1130AG, 1140AG.

Сейчас многие покупают точки доступа 802.11n, но хороших скоростей достичь удается не всем. В этом посте поговорим о не очень очевидных мелких нюансах, которые могут ощутимо улучшить (или ухудшить) работу Wi-Fi. Всё описанное ниже применимо как к домашним Wi-Fi-роутерам со стандартными и продвинутыми (DD-WRT & Co.) прошивками, так и к корпоративным железкам и сетям. Поэтому, в качестве примера возьмем «домашнюю» тему, как более родную и близкую к телу. Ибо даже самые администые из админов и инженеристые из инженеров живут в многоквартирных домах (или поселках с достаточной плотностью соседей), и всем хочется быстрого и надежного Wi-Fi.
[!!]: после замечаний касательно публикации первой части привожу текст целиком. Если вы читали первую часть — продолжайте отсюда.

Привет всем читателям Habrahabr, в этой статье я хочу поделиться с Вами моим опытом в изучении нейронных сетей и, как следствие, их реализации, с помощью языка программирования Java, на платформе Android. Мое знакомство с нейронными сетями произошло, когда вышло приложение Prisma. Оно обрабатывает любую фотографию, с помощью нейронных сетей, и воспроизводит ее с нуля, используя выбранный стиль. Заинтересовавшись этим, я бросился искать статьи и «туториалы», в первую очередь, на Хабре. И к моему великому удивлению, я не нашел ни одну статью, которая четко и поэтапно расписывала алгоритм работы нейронных сетей. Информация была разрознена и в ней отсутствовали ключевые моменты. Также, большинство авторов бросается показывать код на том или ином языке программирования, не прибегая к детальным объяснениям.

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

В этой статье мы поговорим о шаблонах проектирования «Единица работы» и «Репозиторий» в контексте тестового веб-приложения на ASP.NET Core (с использованием встроенного DI), которое мы с вами вместе и разработаем. В результате мы получим две реализации взаимодействия с хранилищем: настоящую, на основе базы данных SQLite, и фейковую, для быстрого тестирования, на основе перечисления в памяти. Переключение между этими двумя реализациями будет выполняться изменением одной строчки кода.

В продолжение Части 1 — Colocation

Следующая часть — Переезд

Здравствуйте друзья! Прежде всего спасибо Вам за комментарии и интерес к прошлой нашей статье. Как мы уже говорили, при строительстве нашего цода, мы взяли с хабра очень много полезной информации, которая по итогу нам очень пригодилась. Поэтому данный цикл статей — некая благодарность площадке и авторам за их статьи, без них было бы в разы сложнее. Спасибо!

Итак, прошлую часть мы закончили на моменте с поиском нового помещения для «строительства» собственного ЦОДа. Как мы уже писали это было жизненно необходимо для нашего молодого проекта, который испытывал трудности в моменты серьезных проблем в дата-центре. Покажу несколько кадров здания ЦОДа. При этом хочу сказать что с владельцами мы работаем до сих пор в других направлениях и расстались хорошими друзьями. Сейчас (по слухам от коллег которые там размещаются) — все отлично.

Внимание! Много изображений. Есть не сжатые фото панорам, ибо при их сжатии — очень сильно теряется качество.

В сети появился сайт, содержащий БД с номерами телефонов и их владельцами. По некоторым номерам даже есть адрес прописки.

Разработчик Робин Линус на своей странице на GitHub Pages (визит по следующей ссылке небезопасен и его не рекомендуется выполнять с рабочего места, так как кроме видимой части сервисов страница проверяет, залогинены ли вы на сайтах для взрослых, а это останется в логах файрволла как попытка перехода прим.) продемонстрировал, как сайты могут снимать с вас «медийный отпечаток», то есть вести учет того, в каких популярных сервисах залогинены посетители даже без какой-либо авторизации на посещаемой странице.

Для автора публикации «медийный отпечаток» выглядит следующим образом и является абсолютно верным:



И это весьма неприятно.

Несколько месяцев назад у нас сильно вырос показатель отказов по Google Analytics. Мы сделали стандартный набор действий, который рекомендуют делать в Сети: создали в аналитике представление «без пауков и ботов» (настройка «Фильтрация роботов» в представлении), проверили качество настройки кода Analytics, проверили и настроили длительность сессии и так далее. Все это заняло время, но не дало результатов. Показатель отказов в некоторые дни превышал 90%. При этом качество контента на нашем сайте или структура входящего трафика никак очевидным образом не менялась. Это просто «случилось в одночасье» и всё. Поскольку ничего подобного описанного в Сети я не нашел, решил описать как мы нашли и исправили проблему и снизили показатель отказов до приемлемых 42-55%.

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

Есть несколько вариантов решения такого класса задач. Наиболее оптимальное и распространенное решение – это подписка на события. Как это реализуется в нагруженных проектах?

Всем привет!
Вы читаете вторую часть статьи про создание VST-синтезатора на С#. В первой части был рассмотрен SDK и библиотеки для создания VST плагинов, рассмотрено программирование осциллятора.
В этой части я расскажу про огибающие сигнала, их разновидности, применение в обработке звука. В статье будет рассмотрено программирование ADSR-огибающей для управления амплитудой сигнала, генерируемого осциллятором.
Огибающие есть в любом синтезаторе, применяются не только в синтезе, а повсеместно обработке звука.

Исходный код написанного мною синтезатора доступен на GitHub'е.