Не скажу за IDE для Python, выскажусь за Visual Studio ( где на большую часть подсветки даже внимания не обращал до прочтения статьи).
В контексте «качества» стоит выделить три типа кода:
1. Свой+недавний код. Понятный, забыть еще не успел. При разработке прототипов частенько мелькают // TODO, или throw new NotImplementedException();, так что подсветка помогает. Как минимум не мешает подсветка строк, уходящее ныне выделение цветом {0} в String.Format. Я молчу про огромную помощь R# — не уверен, можно ли рассматривать подсветку R# в том же смысле, что и авторы исследования. Короче, подсветка как минимум не вредит.
2. Чужой хороший или свой+давний+хороший код. Разделение цветом классов и интерфейсов, базовых и составных типов не мешает. Пожалуй, читать код проще: легче выделяются конструкторы и исключения.
3. Чужой или свой+давний не очень хороший код. Полагаю, чем хуже код в смысле выравнивания, тем меньше польза подсветки. При этом подсветка помогает читать код с плохой системой именования.
Резюмируя: подсветке в её VS-проявлении быть. Скромная, незаметная, простые правила цвета.
P.S. Если есть желание поставить свой эксперимент — покодируйте скрипты на T4 в той же студии. Ценность подсветки осознается моментально.
У вас в примерах кода используется http (UriComponents.HttpRequestUrl). Это просто безразличный к http/https парсер, или в рассматриваемом куске кода применяются http запросы?
Многие просили, чтобы мы упростили форму отзыва и убрали часть полей — тогда писать будут больше. Но мы не стали этого делать, чтобы отзывы были максимально полезными.
Идея не сработала. Теперь вместо пустого поля пишут «не в курсе», «не занимался» и т.д. В итоге больше мусора бесполезной информации в отзывах. Может, дать людям возможность оставить пустыми два-три поля?
P.S. Порадовало описание городка в Сомали:
Преступность
нет, убивают сразу из автомата или вначале похищают
Рад, что вы за это взялись. В моей старой фирме на оформление подобного отчета приходилось совершать 13 действий.
Из хотелок: для «непрограммистов» есть смысл сделать счетчик рядом с часами, чтоб заполнять не с клавиатуры, а с мышкой. Дефолтное значение — час, шаг — полчаса. Сделать выпадающий список последних проектов — название длинное, перепечатывать долго. «Программистов» сделать удобную табуляцию (пропускающую счетчик).
Если отвлечься от существующего UI: «программистам» пригодится интеграция с различными системами учета времени вроде Toggl. И интеграция с TFS, TeamCity и т.д.: оттуда (потенциально) выдирается немало информации о проектах, тасках и прочих коммитах. По-хорошему, если данные есть в TFS проще воспользоваться запросами, но иногда у начальника нет доступа к ТФС, или он не желает настраивать запросы, или информация из писем будет сводиться потом в отдельные таблицы. Для последнего варианта желателен парсер отчетов.
Занимаясь автоматизацией билдов, я проверял статусы пару раз каждый день, плюс регулярные проверки тим-лида. Потеря 200 файлов — это сокращение тогдашнего билда минут на 10, и уменьшение числа тестов. Так что ошибка обнаруживается за 4-8 часов.
Но в целом, если тула ставится из коробки, настраивается один раз на солюшн и отнимает меньше у.е. времени при билде — вполне себе нормальный инструмент. Проблемы с версиями и отсутствием либ редкие, но времени на исправление могут отнять немало.
Самая элементарная вещь — инкапсуляция. Модификатор internal защищает код проекта от внешнего доступа. Если все проекты слить — защита падет. Размываются интерфейсы, увеличивается вероятность прострелить себе ногу.
Чуть менее элементарная — конфликты слияния. Когда в один проект коммитят 20 разработчиков, при добавлении\переименовании\добавлении файлов конфликты слияния будут возникать чаще, чем при разработке «каждый разраб пилит свой проект». Каждый конфликт слияния — это потеря времени минимум одного человека.
Есть еще переносимость. Если часть кода используют несколько приложений, разумнее выделить её в проект\сервис, поддерживать и изменять будет проще.
Поиск коммита поломавшего солюшн. Локализовав ошибку с точностью до проекта, можно банально посмотреть последние коммиты и узнать в каком из них ошибка. В один проект из 20 коммитят где-то раз в 20 меньше, чем в один проектосолюшн.
Время сборки. Билд слитого-из-20 проекта может длиться пару минут, в то время как билд малого проекта — несколько секунд.
Время тестирования. Модульные тесты на проект проходят быстрее модульных тестов на солюшн. Если разрабатываете малыми итерациями, гонять тесты всего солюшна может быть накладно.
Работать со слитым проектом можно, но это неудобнее, чем работать с 20 малыми проектами: больше времени на поиск ошибок, больше времени на тесты\билды, выше вероятность ошибки. Как верно заметили ниже, если проект небольшой — проблем нет. Если же проект кроссплатформенный\пишется большой командой\содержит много логики — стоит разбить его на проекты.
Скорее, больше опыта работы в соответствующей сфере.
Какая типовая задача админа? Сделать так, чтоб на моем компе работал инет, и чтоб было достаточно прав вот на те машины, и чтоб там блокировщиков порта ***** не было. Да, на стороне админов могут крутиться сервера, настраиваться маршрутизаторы, конфигурироваться файрволлы и еще куча всего, но это скорее способ достижения цели. Функция админа: чтоб все работало.
Функция тестировщика, утрируя: чтоб не было багов, читай, чтоб работало стабильно.
А какие функции у среднего\начинающего программиста в средней\большой конторе, этакого винтика в машине разработки? Чтоб был написан конкретный модуль (модули). Обратите внимание, модуль работал, а не «все». Про все остальное человек может и не знать, отгородившись интерфейсом. В итоге несколько лет человек может работать над конкретными модулями даже не задумываясь, как они связаны в систему.
Отсюда, частично, и возникает разница в складах ума. Скурпулезность, въедливость, аккуратность админов и тестировщиков обуславливается необходимостью выполнять свою админскую\тестерскую функцию; со временем эти качества превращаются в привычку.
С этим даже начинающий админ/DevOps справился бы на автомате, не особо задумываясь, зачем это надо. Просто «для порядка».
У программистов другие функции, отсюда и другой склад ума, другие привычки.
Да, с атрибутами приходится использовать *Specified, и красивого способа решить эту проблему я пока не вижу. Разве что, сниппет написать, или над когогенерирующей утилитой задуматься.
С перечислениями тоже неудобно работать. Писать обертку на каждый enum — раздувать проект, а удобную обобщенную оболочку вроде
Вы можете обучать AI в плане корректировки коэффициентов. На время хода это не повлияет.
Если же AI откорректировался слишком сильно, вы можете уменьшить глубину обхода, что сбалансирует сложность и уменьшит время хода.
Можно поподробнее насчет предсказуемости, зачем она? Разработчику понятно, для отладки, как гарантия отсутствия глупых ходов (которые искореняются в процессе отладки), но зачем она игроку?
P.S. совершенно забыл написать в первом комментарии, спасибо за отличные статьи.
Позже будем использовать результаты реальных игр для обучения AI.
Не боитесь Скайнета? Когда AI способен проиграть лишь мистеру Андерсену Коннору, обычный игрок будет обречен на проигрыш. Так что придется задумываться об упрощении AI (хотя это проще — достаточно уменьшить глубину просмотра).
В целом — задумка очень занятная. Интересно было бы увидеть игру, где AI обучается у игрока, а затем командируется на онлайн инет-турниры. Если Шакал действительно сильно вариативен, и абсолютная функция сильно сложна, серебряной пули не будет, и как и абсолютных лидеров.
Если в один класс модели придется класть разные IProgress — вы в любом случае откажетесь от ServiceLocator, и будете инжектить нужный Progress-класс руками.
Если говорить конкретно про IoC, при инициализации контейнера обычно получается список вида «Интерфейс I1 по дефолту реализовывать классом C1, Интерфейс I2 по дефолту реализовывать классом С2...» В вашем случае возможны пять разных реализаций, а значит, дефолта быть не может.
Знаю.
Но в данном случае они будут усложнять код DTO-класса.
Сравните:
[XmlElement]
public XmlDecimalWrapper NullableDecimal{get;set;}
и
[XmlElement]
public decimal NullableDecimal{get;set;}
[XmlIgnore]
public bool NullableDecimalSpecified{get{ AnyAdditionalLogicHere;}}
При наличии одного-двух полей — можно и IsSpecified использовать; плюс, этот способ приходится использовать с атрибутами.
При наличии же большого числа Value Type полей мне кажется более удобным использовать оберточные типы, особенно, если они уже есть в готовом виде.
В контексте «качества» стоит выделить три типа кода:
1. Свой+недавний код. Понятный, забыть еще не успел. При разработке прототипов частенько мелькают // TODO, или throw new NotImplementedException();, так что подсветка помогает. Как минимум не мешает подсветка строк, уходящее ныне выделение цветом {0} в String.Format. Я молчу про
огромнуюпомощь R# — не уверен, можно ли рассматривать подсветку R# в том же смысле, что и авторы исследования. Короче, подсветка как минимум не вредит.2. Чужой хороший или свой+давний+хороший код. Разделение цветом классов и интерфейсов, базовых и составных типов не мешает. Пожалуй, читать код проще: легче выделяются конструкторы и исключения.
3. Чужой или свой+давний не очень хороший код. Полагаю, чем хуже код в смысле выравнивания, тем меньше польза подсветки. При этом подсветка помогает читать код с плохой системой именования.
Резюмируя: подсветке в её VS-проявлении быть. Скромная, незаметная, простые правила цвета.
P.S. Если есть желание поставить свой эксперимент — покодируйте скрипты на T4 в той же студии. Ценность подсветки осознается моментально.
Идея не сработала. Теперь вместо пустого поля пишут «не в курсе», «не занимался» и т.д. В итоге больше
мусорабесполезной информации в отзывах. Может, дать людям возможность оставить пустыми два-три поля?P.S. Порадовало описание городка в Сомали:
Из хотелок: для «непрограммистов» есть смысл сделать счетчик рядом с часами, чтоб заполнять не с клавиатуры, а с мышкой. Дефолтное значение — час, шаг — полчаса. Сделать выпадающий список последних проектов — название длинное, перепечатывать долго. «Программистов» сделать удобную табуляцию (пропускающую счетчик).
Если отвлечься от существующего UI: «программистам» пригодится интеграция с различными системами учета времени вроде Toggl. И интеграция с TFS, TeamCity и т.д.: оттуда (потенциально) выдирается немало информации о проектах, тасках и прочих коммитах. По-хорошему, если данные есть в TFS проще воспользоваться запросами, но иногда у начальника нет доступа к ТФС, или он не желает настраивать запросы, или информация из писем будет сводиться потом в отдельные таблицы. Для последнего варианта желателен парсер отчетов.
Но в целом, если тула ставится из коробки, настраивается один раз на солюшн и отнимает меньше у.е. времени при билде — вполне себе нормальный инструмент. Проблемы с версиями и отсутствием либ редкие, но времени на исправление могут отнять немало.
Чуть менее элементарная — конфликты слияния. Когда в один проект коммитят 20 разработчиков, при добавлении\переименовании\добавлении файлов конфликты слияния будут возникать чаще, чем при разработке «каждый разраб пилит свой проект». Каждый конфликт слияния — это потеря времени минимум одного человека.
Есть еще переносимость. Если часть кода используют несколько приложений, разумнее выделить её в проект\сервис, поддерживать и изменять будет проще.
Поиск коммита поломавшего солюшн. Локализовав ошибку с точностью до проекта, можно банально посмотреть последние коммиты и узнать в каком из них ошибка. В один проект из 20 коммитят где-то раз в 20 меньше, чем в один проектосолюшн.
Время сборки. Билд слитого-из-20 проекта может длиться пару минут, в то время как билд малого проекта — несколько секунд.
Время тестирования. Модульные тесты на проект проходят быстрее модульных тестов на солюшн. Если разрабатываете малыми итерациями, гонять тесты всего солюшна может быть накладно.
Работать со слитым проектом можно, но это неудобнее, чем работать с 20 малыми проектами: больше времени на поиск ошибок, больше времени на тесты\билды, выше вероятность ошибки. Как верно заметили ниже, если проект небольшой — проблем нет. Если же проект кроссплатформенный\пишется большой командой\содержит много логики — стоит разбить его на проекты.
Какая типовая задача админа? Сделать так, чтоб на моем компе работал инет, и чтоб было достаточно прав вот на те машины, и чтоб там блокировщиков порта ***** не было. Да, на стороне админов могут крутиться сервера, настраиваться маршрутизаторы, конфигурироваться файрволлы и еще куча всего, но это скорее способ достижения цели. Функция админа: чтоб все работало.
Функция тестировщика, утрируя: чтоб не было багов, читай, чтоб работало стабильно.
А какие функции у среднего\начинающего программиста в средней\большой конторе, этакого винтика в машине разработки? Чтоб был написан конкретный модуль (модули). Обратите внимание, модуль работал, а не «все». Про все остальное человек может и не знать, отгородившись интерфейсом. В итоге несколько лет человек может работать над конкретными модулями даже не задумываясь, как они связаны в систему.
Отсюда, частично, и возникает разница в складах ума. Скурпулезность, въедливость, аккуратность админов и тестировщиков обуславливается необходимостью выполнять свою админскую\тестерскую функцию; со временем эти качества превращаются в привычку.
У программистов другие функции, отсюда и другой склад ума, другие привычки.
С перечислениями тоже неудобно работать. Писать обертку на каждый enum — раздувать проект, а удобную обобщенную оболочку вроде
написать не получится.
Если же AI откорректировался слишком сильно, вы можете уменьшить глубину обхода, что сбалансирует сложность и уменьшит время хода.
Можно поподробнее насчет предсказуемости, зачем она? Разработчику понятно, для отладки, как гарантия отсутствия глупых ходов (которые искореняются в процессе отладки), но зачем она игроку?
P.S. совершенно забыл написать в первом комментарии, спасибо за отличные статьи.
Не боитесь Скайнета? Когда AI способен проиграть лишь мистеру
АндерсенуКоннору, обычный игрок будет обречен на проигрыш. Так что придется задумываться об упрощении AI (хотя это проще — достаточно уменьшить глубину просмотра).В целом — задумка очень занятная. Интересно было бы увидеть игру, где AI обучается у игрока, а затем командируется на онлайн инет-турниры. Если Шакал действительно сильно вариативен, и абсолютная функция сильно сложна, серебряной пули не будет, и как и абсолютных лидеров.
Если говорить конкретно про IoC, при инициализации контейнера обычно получается список вида «Интерфейс I1 по дефолту реализовывать классом C1, Интерфейс I2 по дефолту реализовывать классом С2...» В вашем случае возможны пять разных реализаций, а значит, дефолта быть не может.
Но в данном случае они будут усложнять код DTO-класса.
Сравните:
и
При наличии одного-двух полей — можно и IsSpecified использовать; плюс, этот способ приходится использовать с атрибутами.
При наличии же большого числа Value Type полей мне кажется более удобным использовать оберточные типы, особенно, если они уже есть в готовом виде.