• История одной оптимизации: передача и обработка результатов боя
    +2
    На инсте гейта минусовый хуррик, в бубле, в агре.
  • 30 лет работы сисадмином
    +6
    Статью отлично смотрелась бы на главной в на день сисадмина.
    P.S. теги в тему.
  • История одной оптимизации: передача и обработка результатов боя
    0
    Хм. А что плохого в подобного рода боях? Ведь в половине случаев победа принадлежит союзной команде. Опять-таки, баланс по роли — сложная вещь, очень. Тот же Т-34 можно использовать как в роли флангового дырокола, так и в роли светляка. Роль сильно зависит от экипажа, модулей, используемого вооружения. Балансировать по множеству параметров — долго, и результат не гарантирован.

    Насчет +2 — вопрос тоже спорный, ибо есть исключения. Luchs, ELC и иже с ними демонстрируют, что вражеский танк +3 можно отлично засветить.

    САУ, возможно, дисбалансна, но она дисбалансна в обеих командах.

    P.S. Предлагаю на этом завершить. Оказывается, тема весьма холиварна, и не раз поднималась на танковых ресурсах.
  • История одной оптимизации: передача и обработка результатов боя
    0
    А зачем? Танки одного уровня сильно различаются по полезности. Сравните AMX 40 и БТ-7: первый выше уровнем, но в большинстве случаев бесполезен. Второй картонный, без урона, но шустрый и зело полезный.
    Интуитивно кажется, что бои с выровненными по уровню составами будет лучше, но знатоки наверняка приведут немало контрпримеров.
    Погуглил, каждый танк в балансере имеет свой коэффициент полезности. В вашем пример количество компенсируется качеством.
  • История одной оптимизации: передача и обработка результатов боя
    0
    Если не секрет, что требуется от идеального балансера? И чем плох текущий? Играю как «казуал» с племянником, и особых проблем вроде бы нет.
  • Когда людям свойственно ошибаться
    0
    Вы не совсем верно описали знаменитую задачу
    Как заметили ниже считается «Количество дырок, вырезанных числами в ряду из плоскости». Проблема в том, что в использованном шрифте у нуля две дырки («перечеркнутый ноль»), и в третьей линии свободный член должен быть равен 3.
  • Почему наши высокоуровневые языки до сих пор не такие уж и высокоуровневые?
    +1
    Еще можно использовать foreach конструкцию. И indexof, если индекс действительно нужен.
    В целом, вы просто неправильно читаете код.
    a[0] — это не «нулевой» элемент массива, а элемент с нулевым смещением от начала.
  • Релиз близко…
    +5
    С одной стороны, проект вызывает кучу сомнений. С другой стороны, 70000 коммитов, несколько лет целенаправленной разработки и общее продвижение проекта свидетельствуют о недюжином упорстве.
    Удачи вам, и скорейшего выпуска 1.0.
  • Экспериментальная версия PVS-Studio, поддерживающая C#
    –5
    Делить мы ничего не будем, так как вообще не понятно зачем это нужно.

    Скорость создания. Продукт с уникальными проверками создается быстрее, чем с уникальными и дублирующимися. Плюс, сразу исчезают сомнения вроде «а нафиг мне PVS, если 90% его функционала так или иначе покрывается R#?»

    Сейчас нет возможности проверить (чуть выше я уже ошибся), но почти все проверки в статье (сомневаюсь насчет enum-ов) так или иначе покрываются R# (как минимум, R# привлекает внимание к проблемным местам).
  • Экспериментальная версия PVS-Studio, поддерживающая C#
    +2
    Да, проверил, R# предложит упростить до true.
    Более того, даже
    Random r = new Random();
                if (r.Next(2) == r.Next(2))
                {
                    // Logic here
                }
    

    R# предложит заменить на
    if(true){// Logic here}
    
  • Экспериментальная версия PVS-Studio, поддерживающая C#
    –1
    Насколько я понял из статьи, вы пока мигрируете самые простые проверки. Вы дублируете проверки R#, или выделяете уникальные проверки? Можно ли будет разделить проверки на «дублирующие» и «оригинальные», и отключить все проверки одной группы?
  • Экспериментальная версия PVS-Studio, поддерживающая C#
    0
    Даже сейчас R# поможет в первом случае, частично в четвертом (подсветит серым неюзаный аргумент), но не в третьем. Так что кое-какие мелочи все-равно останутся.
    Можно ли прикрутить PVS к TFS? В билд-процессы, или в RM?
  • Как мы себя заново писали, или как потерять исходники и не подать виду
    0
    Сервер сборок от данной проблемы не спасет. «Новобранец» спокойно отошлет заказчику локально собранный проект.
  • Пользуйтесь подсветкой кода
    0
    Это скорее пример вредности плохой подсветки.
  • Пользуйтесь подсветкой кода
    +1
    Думаю, более подробных экспериментов не будет. В первоисточнике указаны ранние исследования той же проблемы, везде прирост производительности относительно небольшой. Эксперимент-прототип проверил, что ситуация не изменилась, и более серьезные эксперименты не нужны.
  • Как мы себя заново писали, или как потерять исходники и не подать виду
    +1
    Врезать код — да. Полагаю, операция почти одинаковая для любого популярного языка.
    Восстановить исходный код из dll для анализа — сложнее. .NET код восстанавливается без проблем. При восстановлении С++ кода уже придется потрудиться.
  • Как мы себя заново писали, или как потерять исходники и не подать виду
    +1
    даже потеря исходных кодов — не катастрофа

    А вот это зависит от декомпиляторов\рефлекторов\дизасмов. В Java и .NET все ок, у АСМщиков таких проблем вообще нет, а вот сишникам придется хуже.
    Кстати, краем уха слышал про подписанные библиотеки, вроде как в них врезать свой код совсем тяжко.
  • Пользуйтесь подсветкой кода
    +1
    Он хорош тем, что дает точные цифры: 8.4 секунды и 2.5 минут (150 секунд) экономится.
    Интересно было бы поставить другой эксперимент: 100 студентов, анализируют задачи. Подсвечивать задачу или нет для каждой пары «студент\задача» — определяется случайно. Хотя переключения внимания так не проанализируешь.
  • Пользуйтесь подсветкой кода
    +1
    Не скажу за IDE для Python, выскажусь за Visual Studio ( где на большую часть подсветки даже внимания не обращал до прочтения статьи).
    В контексте «качества» стоит выделить три типа кода:
    1. Свой+недавний код. Понятный, забыть еще не успел. При разработке прототипов частенько мелькают // TODO, или throw new NotImplementedException();, так что подсветка помогает. Как минимум не мешает подсветка строк, уходящее ныне выделение цветом {0} в String.Format. Я молчу про огромную помощь R# — не уверен, можно ли рассматривать подсветку R# в том же смысле, что и авторы исследования. Короче, подсветка как минимум не вредит.
    2. Чужой хороший или свой+давний+хороший код. Разделение цветом классов и интерфейсов, базовых и составных типов не мешает. Пожалуй, читать код проще: легче выделяются конструкторы и исключения.
    3. Чужой или свой+давний не очень хороший код. Полагаю, чем хуже код в смысле выравнивания, тем меньше польза подсветки. При этом подсветка помогает читать код с плохой системой именования.

    Резюмируя: подсветке в её VS-проявлении быть. Скромная, незаметная, простые правила цвета.

    P.S. Если есть желание поставить свой эксперимент — покодируйте скрипты на T4 в той же студии. Ценность подсветки осознается моментально.
  • Разработка защищенных банковских приложений: главные проблемы и как их избежать
    0
    У вас в примерах кода используется http (UriComponents.HttpRequestUrl). Это просто безразличный к http/https парсер, или в рассматриваемом куске кода применяются http запросы?
  • Тех деревня от нуля до единицы. Теперь и с отзывами о компаниях
    0
    Многие просили, чтобы мы упростили форму отзыва и убрали часть полей — тогда писать будут больше. Но мы не стали этого делать, чтобы отзывы были максимально полезными.

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

    P.S. Порадовало описание городка в Сомали:
    Преступность
    нет, убивают сразу из автомата или вначале похищают
  • Outlook Add-Ins или куда уходит 25% рабочего времени и можно ли его вернуть?
    +2
    Рад, что вы за это взялись. В моей старой фирме на оформление подобного отчета приходилось совершать 13 действий.

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

    Если отвлечься от существующего UI: «программистам» пригодится интеграция с различными системами учета времени вроде Toggl. И интеграция с TFS, TeamCity и т.д.: оттуда (потенциально) выдирается немало информации о проектах, тасках и прочих коммитах. По-хорошему, если данные есть в TFS проще воспользоваться запросами, но иногда у начальника нет доступа к ТФС, или он не желает настраивать запросы, или информация из писем будет сводиться потом в отдельные таблицы. Для последнего варианта желателен парсер отчетов.
  • SolutionCop
    +1
    Занимаясь автоматизацией билдов, я проверял статусы пару раз каждый день, плюс регулярные проверки тим-лида. Потеря 200 файлов — это сокращение тогдашнего билда минут на 10, и уменьшение числа тестов. Так что ошибка обнаруживается за 4-8 часов.

    Но в целом, если тула ставится из коробки, настраивается один раз на солюшн и отнимает меньше у.е. времени при билде — вполне себе нормальный инструмент. Проблемы с версиями и отсутствием либ редкие, но времени на исправление могут отнять немало.
  • SolutionCop
    +1
    Самая элементарная вещь — инкапсуляция. Модификатор internal защищает код проекта от внешнего доступа. Если все проекты слить — защита падет. Размываются интерфейсы, увеличивается вероятность прострелить себе ногу.

    Чуть менее элементарная — конфликты слияния. Когда в один проект коммитят 20 разработчиков, при добавлении\переименовании\добавлении файлов конфликты слияния будут возникать чаще, чем при разработке «каждый разраб пилит свой проект». Каждый конфликт слияния — это потеря времени минимум одного человека.

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

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

    Время сборки. Билд слитого-из-20 проекта может длиться пару минут, в то время как билд малого проекта — несколько секунд.

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

    Работать со слитым проектом можно, но это неудобнее, чем работать с 20 малыми проектами: больше времени на поиск ошибок, больше времени на тесты\билды, выше вероятность ошибки. Как верно заметили ниже, если проект небольшой — проблем нет. Если же проект кроссплатформенный\пишется большой командой\содержит много логики — стоит разбить его на проекты.
  • Почему нельзя пускать программистов на сервера, или Почему девопсы еще не вымерли, хотя об этом много говорили
    –2
    Скорее, больше опыта работы в соответствующей сфере.

    Какая типовая задача админа? Сделать так, чтоб на моем компе работал инет, и чтоб было достаточно прав вот на те машины, и чтоб там блокировщиков порта ***** не было. Да, на стороне админов могут крутиться сервера, настраиваться маршрутизаторы, конфигурироваться файрволлы и еще куча всего, но это скорее способ достижения цели. Функция админа: чтоб все работало.

    Функция тестировщика, утрируя: чтоб не было багов, читай, чтоб работало стабильно.

    А какие функции у среднего\начинающего программиста в средней\большой конторе, этакого винтика в машине разработки? Чтоб был написан конкретный модуль (модули). Обратите внимание, модуль работал, а не «все». Про все остальное человек может и не знать, отгородившись интерфейсом. В итоге несколько лет человек может работать над конкретными модулями даже не задумываясь, как они связаны в систему.

    Отсюда, частично, и возникает разница в складах ума. Скурпулезность, въедливость, аккуратность админов и тестировщиков обуславливается необходимостью выполнять свою админскую\тестерскую функцию; со временем эти качества превращаются в привычку.
    С этим даже начинающий админ/DevOps справился бы на автомате, не особо задумываясь, зачем это надо. Просто «для порядка».

    У программистов другие функции, отсюда и другой склад ума, другие привычки.
  • Как приготовить DTO?
    +1
    Да, с атрибутами приходится использовать *Specified, и красивого способа решить эту проблему я пока не вижу. Разве что, сниппет написать, или над когогенерирующей утилитой задуматься.

    С перечислениями тоже неудобно работать. Писать обертку на каждый enum — раздувать проект, а удобную обобщенную оболочку вроде
    public class EnumWrapper<T> where T : Enum
    

    написать не получится.
  • Как мы писали AI для Шакала, и почему у него шизофрения
    +2
    Вы можете обучать AI в плане корректировки коэффициентов. На время хода это не повлияет.
    Если же AI откорректировался слишком сильно, вы можете уменьшить глубину обхода, что сбалансирует сложность и уменьшит время хода.

    Можно поподробнее насчет предсказуемости, зачем она? Разработчику понятно, для отладки, как гарантия отсутствия глупых ходов (которые искореняются в процессе отладки), но зачем она игроку?

    P.S. совершенно забыл написать в первом комментарии, спасибо за отличные статьи.
  • Как мы писали AI для Шакала, и почему у него шизофрения
    +2
    Позже будем использовать результаты реальных игр для обучения AI.

    Не боитесь Скайнета? Когда AI способен проиграть лишь мистеру Андерсену Коннору, обычный игрок будет обречен на проигрыш. Так что придется задумываться об упрощении AI (хотя это проще — достаточно уменьшить глубину просмотра).

    В целом — задумка очень занятная. Интересно было бы увидеть игру, где AI обучается у игрока, а затем командируется на онлайн инет-турниры. Если Шакал действительно сильно вариативен, и абсолютная функция сильно сложна, серебряной пули не будет, и как и абсолютных лидеров.
  • Скрытые зависимости как «запах» проектирования
    0
    Если в один класс модели придется класть разные IProgress — вы в любом случае откажетесь от ServiceLocator, и будете инжектить нужный Progress-класс руками.
    Если говорить конкретно про IoC, при инициализации контейнера обычно получается список вида «Интерфейс I1 по дефолту реализовывать классом C1, Интерфейс I2 по дефолту реализовывать классом С2...» В вашем случае возможны пять разных реализаций, а значит, дефолта быть не может.
  • Как приготовить DTO?
    +1
    Знаю.
    Но в данном случае они будут усложнять код DTO-класса.
    Сравните:
    [XmlElement]
    public XmlDecimalWrapper NullableDecimal{get;set;}
    

    и
    [XmlElement]
    public decimal NullableDecimal{get;set;}
    
    [XmlIgnore]
    public bool NullableDecimalSpecified{get{ AnyAdditionalLogicHere;}}
    


    При наличии одного-двух полей — можно и IsSpecified использовать; плюс, этот способ приходится использовать с атрибутами.
    При наличии же большого числа Value Type полей мне кажется более удобным использовать оберточные типы, особенно, если они уже есть в готовом виде.