• Череда проблем длиною в 16 лет
    0
    Верю. Но игра в целом соревновательная (шутер) и в обычном ПВП режиме у игрока преимущество за счет правильного использования навыков, бонусов и т.д. Поэтому это хороший соревновательный элемент. А уже именно для интересного геймплея нужны живые соперники, но их не оказалось.
  • Череда проблем длиною в 16 лет
    0
    За это время было целых три проекта, которые использовали этот движок. И все закрылись до релиза или сразу после него. До боевого тестирования по-сути дожил только последний, четвертый.
  • Череда проблем длиною в 16 лет
    0
    Знаете, я и так сделал весьма мощный АИ (не нейросеть, скриптовый), с ним интересно играть, потому что у него есть полная информация. Конечно, это не полная имитация игроков — он не может прокачиваться и брать квесты. Но чтобы сделать именно подключаемых по сети ботов, надо потратить вагон времени на игру с неполной информацией — без знания всей карты, положения врагов, точек куда лететь для захвата флага и т.д.
  • Череда проблем длиною в 16 лет
    0
    Нет, если самому все делать, то можно с ума сойти :) В случае с эмулятором за все время человек 15 поучаствовало, кто базы наполнял, кто скрипты писал. В новом же проекте я собрал маленькую инди фирму. Пусть и кодеров было только двое, но это тоже немало.
  • Череда проблем длиною в 16 лет
    0
    Да, это очень хороший вариант. Не раз о нем думал, но так и не дошли руки его реализовать.
  • Череда проблем длиною в 16 лет
    +3
    Тут две разные истории. Легаси код начинался с версии .Net 1.1, дожил до полноценного перехода 4.0, был хорошо вычищен и отрефакторен, достиг неких высот.
    Вторая история про то, как через много лет, уже далекий наследник этого кода (опять же, переписанный и вычищенный не один раз) неожиданно повторил тот же самый путь. В основном, потому что при рефакторинге вместе с водой выплеснули и ребенка — старые проблемы забылись, их методы решения тоже.
    Я соглашусь, что вышло в целом сумбурно — много рассуждений, мало технических деталей, мало описаний инструментов, только основные подходы к решению проблем.
  • Череда проблем длиною в 16 лет
    +1
    Там чуть ниже в тегах написано.
  • Череда проблем длиною в 16 лет
    +2
    Чтобы сохранить большую часть старого кода, разумно было мигрировать только на .Net 5.0. А он вышел уж слишком поздно. Я на тестовом сервере перенешел на него, порадовался появлению давно забытых на Mono номеров строк в Exceptions релизной версии. Да и все на этом.
    Но это было уже весной, и он отнес ёлку обратно
  • Собеседование на миддла за деньги, после которого я готов идти джуном за еду
    +23
    Иногда предпочитают разобраться и взять толкового человека, который сумеет выучиться и работать, а не того, который зазубрил методичку «ответы на вопросы собеседований». К сожалению, далеко не всегда.
  • Comment from a drafted post.
  • Comment from a drafted post.
  • Смешные собеседования: истории ИТ-рекрутеров (часть 1)
    +3
    Как-то раз зашел я в отделении милиции с ножом в руках. Ребята побледнели и потянулись к кобурам; тут я их добил: говорю, сейчас я там машину вскрывать буду, под вашим зданием. Вы не пугайтесь, она моя — захлопнулись ключи внутри. Оценили, ржали :)
  • Меня перевезли в другую страну и через две недели выставили на мороз — потому что передумали нанимать
    +21
    А у нас как-то был случай, когда крутой спец не смог начать работать. Он отлично прошел собеседование, он разобрался в нашем коде и продукте (порядочно раскритиковав его слабые стороны), он участвовал в совещаниях, он помогал другим сотрудникам. Но не мог начать кодить сам — сидел в интернете, в курилке, настраивал и перенастраивал рабочее место, выбирал имя для проекта и классов. Неделю, две, три. Сначала это было странно, затем пришлось одну задачу у него забрать и выдать другую попроще. Один раз повели его на прямой разговор и он обещался, что начнет работать, но «просто что-то пока не выходит войти в строй». На четвертой неделе мы пошли к начальству, оно провело ревью всех 50 строк написанного кода и по итогам с человеком полюбовно разошлись. Наверняка дело было в нас. Задачи, атмосфера, отсутствие жесткого менеджмента — все это не дало ему настроится на работу, но и продолжать так было нельзя. Если бы все усложнялось релокейтом и праздниками — была бы схожая с автором история, благо обошлось лишь потерей небольших денег и месяца работы.
  • Mikrotik (RouterOS) + Wireguard
    0
    Он у меня завелся еще N времени назад, но приходилось прописывать NAT для доступа к ресурсам сервера, а это откровенно ненормально. А как сделать двусторонний NAT (точнее, Transparent Firewall) я так и не разобрался.
    В целом, из ненормального тут только настройка endpoint и allowed-address на Mikrotik, за счет того, что конфиг WG хранится в текстовом виде и редактируется через текстовый редактор, доступный только по SSH.
    А, ну еще на старом RB750UP все настроилось, но не заработало и сильно-сильно кушало процессор. Видимо, не по нему эта задача.
  • Mikrotik (RouterOS) + Wireguard
    0
    Наверное все-таки на 192.168.1.20 знает «192.168.68.0/24 через 192.168.1.254»

    Да, опечатался. Ясное дело, у меня ж сетки совсем иначе называются.

    Чаще всего я ошибался AllowedIPs или маршрутах.
    Недостаточно прописать «дома» маршрут «192.168.68.0/24 через 192.168.1.254»

    Итого, проблема оказалась именно тут — в AllowedIPs на сервере должен быть адрес сети клиента, которая хочет работать с этим интерфейсом.
  • Mikrotik (RouterOS) + Wireguard
    0
    Задача — соединить wg сетку и локальную. Маршрутизация допустима.

    — Домашняя сеть 192.168.1.0/24
    — Удаленная машина 192.168.68.20
    — WG сервер 192.168.1.254, WG сетка 192.168.68.0/24
    — прописан маршрут 192.168.68.0/24 через 192.168.68.254 и он не думает работать

  • Mikrotik (RouterOS) + Wireguard
    0
    А у кого-нибудь получилось добавить wireguard интерфейс в bridge? Или связывать его с сеткой реально только через фаервол?
  • В Steam проходит фестиваль инди-игр Indie Cup Celebration со скидками и бесплатными демо-версиями
    0
    Ну наверное это хороший фестиваль, но я как инди разработчик из Восточной Европы узнал о нем аж прямо сейчас. Мы были бы заинтересованы там свою игру показа, но информации о событии не было в принципе нигде.
    Ну и Steam Summer Festival of Games показал, что эти мероприятия сродни поиску чего-то ценного на гаражной распродаже.
  • Принятого не воротай: Enumerable vs List
    +2
    У массивов есть куча важных и неприятных недостатков, из-за которых они не всегда подходят для возвращаемого типа из метода и точно не стоит делать ToArray() на каждом шагу.

    1. Массив это объект и подвержен сборке мусора. И если мы возвращаем его из функции, то он сразу попадет в GC Gen 1. А в плохом раскладе и в Gen 2. Массовый ToArray() по всему коду может удвоить нагрузку на GC, что не критично для небольшого проекта, но может быть важно в бекэнде. Чтобы бороться с этим в .Net Core сделан ArrayPool<>, но с ним есть нюанс №2.
    2. Получив из ArrayPool<> массив нельзя быть уверенным, что его длина не больше, чем надо и что вы заполните все его элементы. В итоге некоторые программисты начинают возвращать из каждого метода ArraySegment, собственную обертку, отдельно значение count. Либо таки возвращают массив и каждый элемент при переборе сравнивают с null или default. Отдельно остается вопрос, что массивы надо бы и возвращать в пул, а за этим автор метода уже проследить не может.
    3. Массив структур физически хранит в себе эти структуры и его создание через ToArray() или CopyTo приведет к массовому копированию. Ну а сам массив потенциально может попасть в LOH, для этого достаточно иметь всего 85000 байт размера. Обработка LOH объектов обычно блокирующая, т.е. останавливает ваше приложение. Есть исключения, но речь не о них.
    4. В отличие от IReadOnlyList<>, в массиве можно заменить элемент с каким-то индексом и изначальный метод не узнает об этом.

    Моя рекомендация: возвращайте из методов IEnumerable, IReadOnlyCollection, IReadOnlyList (если нужен доступ по индексу). Не заморачивайтесь с массивами, если это не требуется явно. И точно не делайте ToArray по поводу и без повода, от этого код не станет работать быстрее.
  • Epic потеряла 60 % аудитории Fortnite на iOS. Компания просит суд заставить Apple вернуть игру на место
    +5
    Это как если бизнесмен скажет, что он не смог с партнером выкурить сигару в самолете и это привело к срыву сделки. Или таки ее выкурит, а затем подаст в суд на компанию, говоря, что закона он не нарушил, только надуманные правила авиакомпании. А вот пребывание в тюрьме подорвало его авторитет, здоровье и прибыль фирмы. Плюс попал в черный список и не может летать, что тоже чревато убытками.
  • Вред хранимых процедур
    –1
    У меня какое-то странное впечатление, будто кто-то подсмотрел как делаются системы в энтерпрайзе и попытался натянуть этот подход на более широкий глобус. Хранимые процедуры есть почти везде, но в Oracle и MSSQL они выведены на совсем высокий уровень, включая CLR Stored Procedures на .Net и их отладку в Visual Studio. А так с Postgres я вижу непонятную борьбу с кактусом, логированием вместо отладки, отсутствие тестов и написание кода чуть ли не в emacs, а потом жалобы, что это неудобно.
  • Затененные пятна на картах Китая помогли обнаружить обширные лагеря для интернированных
    0
    Чем ближе лагерь к границе, тем удобнее будет туда возить несогласных из нового Казахского автономного региона КНР :)
    Кстати, рискну предположить, что у базы ПВО и лагеря отличаются площади и тип строений. Все-таки ПВО подразумевает меньше казарм для личного состава
  • Затененные пятна на картах Китая помогли обнаружить обширные лагеря для интернированных
    +2
    Давайте пофантазируем о геополитике (прямо как профессиональные таксисты). Не думаю, что Таджикистан, Афганистан, Монголия, Киргизстан и Казахстан относятся к потенциальным противникам Китая, с этими странами отношения условно приемлемые, их военная мощь сравнительно невелика. Остаются Индия, Пакистан и Россия, вот с ними вероятность войны заметно выше (хотя и протяженность границы меньше). Можно предположить, что концентрация лагерей на границах именно с этими странами существенно ниже. Посмотрим теперь на карту — действительно, скопления видны возле совсем «безвредных» границ, например, возле Казахстана.
    Конечно война может быть сразу региональная, масштабная. Но в таком случае скорее всего сама граница отодвинется на территории этих стран и не удивлюсь, если у китайских генералов давно висят на стенах карты с пунктирными линиями.
  • Затененные пятна на картах Китая помогли обнаружить обширные лагеря для интернированных
    +2
    Там пустыня и горы, это крайне отдаленный Синьцзян-Уйгурский автономный район. Если бы современная война и подразумевала пересечение границы огромной армией, то в этой местности это было бы крайне не удобно.
  • Совершенный цикл for
    +1

    У вас конструкция из 5 вложенных циклов. Это операция такой сложности для понимания и отладки, что макросами и синтаксическим сахаром вы можете ее сделать только менее понятной для стороннего человека. У вас отличные комментарии в коде, сам он весьма читабельный. Если в первую секунду не ясно, что и как итенируется, то потом видны комментарии и все становится на свои места. Смешайте это на половину с for-range или for each и читабельность упадёт. Буквально мне не нравятся только константы 4 и пр. в цикле.

  • Голландским хакерам удалось взломать светофоры в нескольких городах
    0
    А можно даже дальше пойти — в дорогу встраивать датчик! Фантастика, правда?
  • IT-эмиграция и русский язык
    +1
    Люцерн на фото Олега Ненашева

    Люцерн находится в германоязычном кантоне Люцерн в самом центре страны. Так что, фото хорошее, но, кхм, мимо кассы.
  • Голландским хакерам удалось взломать светофоры в нескольких городах
    +3
    На каждом светофоре держать WiFi точку, которая передаст в явном (подключение) или скрытом виде (в названии) токен, меняющийся каждые 5 минут. Не зная токена нельзя подтвердить, что ты возле этого светофора.
  • Новостные издательства потребовали у Apple снизить комиссию в AppStore
    +3
    Без поддержки Unreal Engine большинство AAA тайтлов не будут выходить на MacOS, что сильно ограничит возможность apple наращивать долю рынка потребительских компьютеров.

    Apple не поддерживает даже видеокарты NVidia, им наличие AAA игр на «потребительских компьютерах» вообще не существенно. И отсутствие UE на iOS ударит сильно не по Apple, а по самим Эпикам и тем, кто на этом движке собрался релизиться.
  • В RouterOS 7 добавили поддержку WireGuard
    0
    Они лет 5 обещали это, как и MBIM режим в 7й версии. Так на форуме все и смеялись «в 7-ке будет». Ну вот это время настало. :)
  • В Беларуси блокируют большое количество интернет-сервисов
    0
    Если это китайская технология, то есть важный плюс: любое доморощенное решение, проходящее через анализатор будет работать несколько недель, пока не будет апдейта из Китая. Ну или система самообучается, но тогда бы не работали Psiphone и прочие варианты.
  • NextCloud в качестве сервиса по созданию защищенных ссылок
    +1
    У нас вообще NextCloud работает как оболочка для Amazon S3 — интерфейс проще, права настраиваются, можно приложение для синхронизации поставить, есть прямые ссылки. Под эту нагрузку вполне хватает бесплатного инстанса Amazon EC2, выходит хороший довесок к облачному хранилищу. До этого был Google Cloud Storage для хранилища, вот там не все хорошо со скоростью и интеграцией.
    А если вообще на локальный диск его направлять, то можно о коммерческих облаках и не задумываться, если, конечно, с бекапами вопрос продуман.
  • Как перезапустить закон Мура программными методами. Ускорение софта в тысячи раз
    +2
    А я бы пользовался таким. Мне не страшно клеймо идиота или программиста на костылях, я согласен с мыслью, что алгоритмы и оптимизации могут развиваться быстрее, чем я их изучу.
    Напишу где-нибудь (x*x*3 — x*x*x*2), а мне анализатор сразу «вы изобрели smoothstep, может не делать велосипед, а взять библиотечную функцию?»
    Ясное дело, в голову приходят только примеры, которые я знаю как оптимизировать. Но наверняка есть еще сотня таких, о которых не в курсе.
  • Как перезапустить закон Мура программными методами. Ускорение софта в тысячи раз
    +2
    Окей, отставим в сторону автоматическую замену кода будущим поколениям. Но даже полу-автоматический режим может быть весьма полезен — представьте, если анализатор скажет «вы пытаетесь перебрать коллекцию из 1000500 элементов в один поток, может стоит тут распараллелить или убрать прямой перебор?». Буквально, только PVS Studio движется в подобном направлении. Огромного количества медленных мест можно избежать, если IDE будет проводить глубокий анализ, а не примитивные советы вроде «результат функции нигде не используется». И технологии для этого уже есть, просто задачи такой нет.
  • Как перезапустить закон Мура программными методами. Ускорение софта в тысячи раз
    0
    Никакой оптимизатор не знает с какой целью создан код, а без знания цели можно только оптимизировать очевидные вещи, которые хоть и помогают иногда, но всё же не далеко не всегда.
    Сейчас DLSS умеет достраивать изображение в игре в реалтайме, повышая разрешение почти в два раза. Неужели рано или поздно оптимизатор не сможет понять, что конкретно в этом примере — умножение матриц, которое можно сделать с помощью AVX?
    Аналогично с распараллеливанием — OpenMP и GCC уже два десятка лет обрабатывают #pragma omp parallel for, но аж в трех языках программирования и только с прямым указанием, что этот цикл можно параллелить.
  • Как перезапустить закон Мура программными методами. Ускорение софта в тысячи раз
    0
    Мое сообщение говорит о том, что код с .Net Framework не запустится на .Net Core. Разные CLI.
  • Как перезапустить закон Мура программными методами. Ускорение софта в тысячи раз
    +5
    А почему никто не говорит, что надо улучшать компиляторы? Если работа высокоуровневого программиста — перемножать матрицы в 4 строки и двигаться дальше, то почему он должен каждый раз нырять в низкоуровневые дебри? Описанный код вполне может быть ускорен, распараллелен и векторизован умным анализатором, JIT, AI компилятором и чем-либо еще. Если мы хотим сохранить разделение на уровни абстракции, а не смешивать все слои в попытках оптимизировать все перед релизом, то сами инструменты должны эволюционировать каждый год. Но никто из разработчиков ОС/языков/компиляторов не хвастается, что с новым апдейтом Windows или MacOS стала быстрее запускать программы, а код для Python 3.8 с апдейтом до 3.9 станет автоматом подключать numpy, прогонять нужный кусок на автоматических тестах и в итоге его заменять на быструю версию. Даже в случае явной эволюции .Net Framework -> .Net Core нельзя запустить старый код и получить прирост производительности за счет RyuJIT и других вкусностей.
  • A* pathfinding на C#: двоичные кучи и борьба с аллокациями
    0
    Как водится, я написал не сильно вчитавшись в код, а народ еще и заплюсовал. Якорь в корму мне за менторский тон и поспешность!
    У автора Vector2Int.DistanceEstimate считает точное диагональное расстояние до точки (0,0), это значит, что два весовых коэффициента (уже пройденный путь и тот, который надо пройти) имеют 1в1 одинаковую размерность и, по-сути для пути без препятствий показывают точное расстояние от старта до точки и точки до цели:
    double traverseDistance = parent.TraverseDistance + cost;
    double heuristicDistance = (position - target).DistanceEstimate();


    Это превращает алгоритм в точный A*, без намека на «жадность». Путь получается гарантированно кратчайшим по расстоянию и недостаток у него лишь один — излишняя геометричность:
    Скрытый текст
    image

    Еще раз по пунктам, как это работает: в каждой точке алгоритм оценивает следующий шаг, сортируя возможные шаги по приблизительному расстоянию до цели heuristicDistance. Когда происходит возврат назад из финальной точки к конечной (разворачивание всех точек пути), используется traverseDistance. Т.к. эти значения считаются по одинаковому принципу, то обратный путь будет гарантировано кратчайшим.
    Единственное, что надо проверить, так это заменяет ли автор уже в найденных точках значение traverseDistance, если к ним нашелся более короткий путь. Update: заменяет, это как раз последняя строка кода в листинге в статье.

    P.S. На счет массивов и хешсетов. Я бы использовал вообще все коллекции другие. Но это уже детали. Правильно сделать сначала так, а потом уже оптимизировать по мере надобности. Если собственное бинарное дерево решило вопросы производительности, значит в задаче автора этого достаточно.
    P.P.S. Навигация по навмешу это та же самая навигация по графу с эвристикой и для нее A* подходит идеально. В моем текущем проекте ноды графа это места, куда можно доехать, зажав комбинацию клавиш «влево», «вправо» и «акселератор» на разные промежутки времени, двигаясь по кривой Корню с учетом ускорения, текущей линейной и угловой скорости, вязкости среды. Визуально эти точки образуют сложное облако, ничуть не похожее на сетку или навмеш.
  • Flipper Zero собрал $1 млн за полтора дня на Kickstarter
    0
    Эти 30-40% (точнее 37% в 2020м для владельцев-физлиц по таксу 1446) засчитываются в уплаченные налоги и частично вернутся как tax refund. Только вот все участники должны получить ITIN и стать налогоплательщиками США для этого.
    Ну или таки оптимизировать.
  • A* pathfinding на C#: двоичные кучи и борьба с аллокациями
    +6
    В целом ок. Реализация не блещет, но это хорошая заготовка.
    То, что вы называете «DistanceEstimate» это эвристическая функция — ядро алгоритма А*. Обычно для него используется Манхеттенское расстояние между точками, иногда Евклидово. Правда, обычно считается расстояние до соседней ноды, а не до конечной, а уже сумма этих расстояний для выбрных нод дает длину пути. Когда вы в эвристике делаете расчет расстояния сразу до конечной точки, вы превращаете алгоритм в «жадный», который стремится в первую очередь выбирать ноды, которые как можно ближе к последней точке. И в момент прихода к последней точке вы алгоритм останавливаете, поэтому путь будет де-факто не кратчайшим.
    Чуток моих замшелых исследований по эвристике тут.