Да, это именно то, что вы представили. Доступ к cloud.mail.ru как к диску прямо внутри файлового менеджера. Ссылка в конце статьи.

А ещё TC научился показывать иконки во вкладках!

Будем откровенны: безальтернативный механизм работы с облаком Mail.ru через синхронизацию очень неудобен. По сути, у пользователя нет полноценного контроля над единичными файлами; всё, что предлагает ему стандартный клиент — двустороннее зеркалирование указанных им данных. Если же нужно отойти от этого сценария, скажем, скачать из облачного архива единственный файл на несинхронизированном устройстве — приходится запускать браузер и пытаться сделать что-то через веб-интерфейс, в котором даже поиска нет. Учитывая, что содержимое облачных каталогов подгружается по мере прокрутки, поиск в браузере может и не помочь.
Есть и другие кейсы, при которых работа с облаком становится затруднительна. Доступ к облаку по webdav, который решил бы все проблемы, отключён (хотя работал какое-то время после запуска сервиса).
При этом сервис бесплатно предоставляет довольно значительный объём хранилища (раздачу террабайтов все помнят?), лимитирования скорости я ни разу не замечал, и за всё время работы с сервисом нареканий к нему не возникло. Для резервирования и пересылки не слишком приватных данных облако Mail.ru подходит очень хорошо. Ограниченность клиента — единственная проблема.

Раз она есть — надо её решать.

Здравствуйте и добро пожаловать в Библию движений Doom! В статье разобраны и рассортированы по категориям все причуды и капризы кода движений в Doom, включая замысловатые трюки с описанием их работы.

Метрика

Начнем с основ. Код движка для движений игрока в Doom имеет следующий вид:

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

Рассмотрим все поподробней.
Благодаря только этому и паре переменных мы сможем определить возможные максимальные скорости персонажа игрока.

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

Написать этот пост меня вдохновила замечательная статья в блоге Gaffer on Games «Reading and Writing Packets» и неуёмная тяга автоматизировать всё и вся (особенно написание кода на C++!).

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

• Выбор формата. Если бы мы писали простенькую игру на JavaScript, нас бы устроил JSON или любой его самописный родственник. Но мы пишем серьёзную многопользовательскую игру, требовательную к трафику; мы не можем позволить себе отправлять ~16 байт на float вместо четырёх. Значит, нам нужен «сырой» двоичный формат. Однако, двоичные данные усложняют отладку; было бы здорово, если бы мы могли менять формат в любой момент, не переписывая целиком все наши функции чтения/записи.
• Проблемы безопасности. Первое правило сетевой игры: не доверяй данным, присланным клиентом! Функция чтения должна уметь оборваться в любой момент и вернуть false, если что-то пошло не так. При этом использовать исключения считается неважной идеей, поскольку они слишком медленные. Мамкин хакер пусть и не сломает ваш сервер, но вполне может ощутимо замедлить его беспрерывными эксепшнами. Но вручную писать код, состоящий из if'ов и return'ов, неприятно и неэстетично.
• Повторяющийся код. Функции чтения и записи похожи, да не совсем. Необходимость изменить структуру пакета приводит к необходимости поменять две функции, что рано или поздно приведёт к тому, что вы забудете поменять одну из них или поменяете их по-разному, что приведёт к трудно отлавливаемым багам. Как справедливо замечает Gaffer on Games, it is really bloody annoying to maintain separate read and write functions.

Всех интересующихся тем, как Бендер выполнил своё обещание и при этом решил обозначенные проблемы, прошу под кат.

Преамбула

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

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

Итак, это уже четвёртая статья, для лучшего понимания происходящего неплохо бы прочитать предыдущие три:

• 1. Методы наименьших квадратов
• 2. Линейно-квадратичный регулятор, вводная
• 3. Управление двигателем постоянного тока при помощи линейно-квадратичного регулятора

Вот фотография системы (кликабельно):

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

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

Как кое-кто уже мог догадаться, я сегодня расскажу про паттерн “Command” и как его использовать для разработки игр с использованием движка Unity 3D. Это один из ключевых паттернов в этом подходе. Код будет упрощенным, но рабочим и должен дать понимание процесса.

Опять здравствуйте, Хабровчане! В прошлой статье я рассказывал о командах и как ими пользоваться, а сегодня я буду развивать тему и расскажу как привязать команду к конечному автомату. Тема на хабре не нова, поэтому я не буду углубляться в объяснения что такое конечный автомат и зачем он используется, а сосредоточусь на реализации. Сразу оговорюсь что для понимания лучше прочитать предыдущую статью, ведь команды будут практически без изменения использоваться в качестве состояний. Перед началом хочу сказать спасибо OnionFan за его комментарий — не все привычки хороши и его вопрос позволил сделать удобней типизацию конечных автоматов, про которые я расскажу, просто добавив ключевое слово params (я уже поправил в предыдущей статье).

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

Пролог

Доброго времени суток! После опубликовании статьи о визуализации квадратичного дерева(Quad-tree), меня попросили написать статью, показывающую работу шейдера, переводящего изображение в «кофту».



Так что, давай рассмотрим данную методику.

Один мой приятель, учитель латинского языка, в начале урока спрашивал своих студентов, выполнили ли они домашнее задание. Как правило, если не первый, то второй или третий ученик сознавался: простите, господин Учитель, я ничего не сделал. «Фак!» — говорил учитель. «Фак!» — повторял он, вводя в еще большее недоумение своих чад. «Сегодня мы будем проходить глагол третьего спряжения facio – делать», который в повелительном наклонении единственного числа так и произносится: fac! – делай!

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

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

Довольно долгое время я никак не мог понять, в чём же разница между «библиотекой» и «фреймворком». Нет-нет, я умел и читать, и гуглить, но до меня всё никак не доходил смысл этих понятий. Начав же программировать под андроид, я наконец понял, что значат слова «библиотеку использует программист, но программиста использует фреймворк».
В этой серии статьей я хочу рассказать о проблемах, с которыми мне пришлось столнулся при разработке под андроид. Моей целью является не предоставление каких-либо убер-решений приведенных проблем, а лишь информирование о том, с какими проблемами может столкнуться тот, кто посягнет на святой грааль Android SDK. Не думаю, что суровые синьоры откроют для себя Америку, но как говорится: «повторение — мать учения».

Журнал «Светотехника» провёл независимую проверку качества светодиодных ламп, офисных светильников, светильников ЖКХ, промышленных и уличных светильников.



Результаты тестирования светодиодных ламп удручают:

«Полностью соответствуют заявленным параметрам 9 ламп из 64 (14%)».

«Производители 53 ламп из 63 (84%) вводят потребителя в заблуждение, указывая явно завышенную мощность эквивалентной по световому потоку ЛН».

«28 ламп из 64 (44%) имели световой поток менее 90% от заявленного».

Немногим более года назад я поделился своими исследованиями о версиях Windows 8.1 (и Windows Server 2012 R2). Материал вызвал бурную дискуссию, которая могла бы быть еще большей, если бы не ограничения данного блога на возможность комментировать заметку пользователям с нулевым рейтингом. Так ту как мою заметку перенесли с Хабра на GT, где я сам уже не мог комментировать свою же статью или вносить в нее изменения, я упустил момент и практически полгода не добавлял материала. Сейчас я хочу в новой заметке начать собирать информацию о сборках Windows 10, коих уже по некоторым подсчётам уже три, а по другим четыре. Планирую пополнять эту заметку с выходом Windows Server 2016 и Redstone1 сборки Windows 10.

Для начала следует понимать, — «Windows 10» это надолго, и это не одна ОС, как было ранее, а линейка, которую компания будет развивать годами. То есть, по сути, за табличкой «Windows 10» Microsoft меняет ядра ОС, предлагая новые версии, как глобальные обновления, которые не в привычном нам смысле устанавливаются как дополнение к ОС, а ставятся поверх неё как новая ОС. На данный момент глобальных версии ОС было две – Threshold1 и Threshold2, сейчас в процессе активного тестирования находится Redstone1 со сроком выхода в конце июля 2016. В пределах глобальной версии существуют разные сборки. Версия текущей установленной ОС повышается путем инсталляции обновлений с Windows Update. Некоторые сборки выпускаются в виде отдельных образов, доступных для загрузки и первоначальной установки, большинство же представляют собой просто накопительные обновления. Сегодня я расскажу о глобальных версиях ОС и тех сборках, которые можно загрузить и установить с нуля.

Цель данной статьи — рассказать об интересном ключе реестра Windows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\CrashOnAuditFail

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

Читая публикации на Хабре нашел пару статей об алгоритмах игры гомоку: эту и эту. В первой статье разобраны различные варианты решения задачи, но нет реализации в виде игры, во второй — игра есть, но компьютер «играет» слабовато. Я решил сделать свой вариант игры гомоку с блэкджеком достаточно сильной игрой компьютера. Публикация о том, что в итоге получилось. Для тех, кто любит сразу в бой — сама игра.

Последняя статья про классические примитивы синхронизации.

(Наверное, потом напишу ещё одну про совсем уже нетипичную задачу, но это потом.)

Сегодня мы немножко заглянем в процессор. Чуть-чуть.

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

В комментариях к предыдущим заметкам возникла дискуссия — насколько справедливо вообще выделять спинлок как примитив, ведь по сути он — просто мьютекс, верно? Он выполняет ту же функцию — запрещает одновременное исполнение фрагмента кода несколькими параллельными нитями.

На уровне процесса всё так и есть — различия между спинлоком и мьютексом — чисто технические, вопрос реализации и производительности.

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

Дело в том, что внутри ядра мьютекс реализован с помощью спинлоков, а вот спинлоки реализованы сами по себе, автономно. Они — действительно базовый примитив. Ниже — только сам процессор.

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

Итак, иерархия реализации такова: mutex/cond/sema сделаны на базе спинлоков, спинлоки — на базе атомарных операций, предоставляемых процессором. Мы в них немного заглянем сегодня.

Как устроен спинлок?

С июня по август прошлого, 2015 года, на Хабре мною были опубликованы 18 статей, озаглавленные "Магия тензорной алгебры". Проект начинался как амбициозная попытка в относительно простой и доступной форме изложить теорию тензорного исчисления с её приложениями к практике.

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

Но беда пришла оттуда, откуда её не ждали.

Windows 7 по-прежнему остается популярной операционной системой в корпоративной среде, несмотря на то, что уже вышли две новые версии клиентских ОС. Расширенная поддержка «семёрки» закончится лишь 14 января 2020 г., а это значит, что ближайшие 4 года для нее будут выходить обновления, исправляющие обнаруженные уязвимости.

Существует правило – если есть обновления, то есть и проблемы с их установкой. Давайте разберем, какие основные проблемы возникают при обновлении Windows 7 через Windows Server Update Services (WSUS) и как их исправить с наименьшими затратами.

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



Чтобы упростить алгоритм, без потери качества, нужно немного «битовой магии», что интересная тема сама по себе.