Некоторые разработчики предпочитают объектную инициализацию использованию конструкторов. Кто-то негодует из-за вынужденного "перекладывания" аргументов из одного конструктора в другой при наследовании. Кому-то конструкторы не нравятся просто как таковые. Но возможна ли жизнь без конструкторов?
Чаще всего, когда возникает вопрос о том как улучшить навыки разработки, стандартный ответ: почитать про чистый код, выучить новые языки программирования, посмотреть проекты где реализованы лучшие практики и т.д. Но есть другой способ - пойти от обратного, и попробовать написать код максимально ужасно. Написав по-настоящему плохой код можно в конце концов понять, как писать хороший. Можно небрежно и на скорую руку сделать работу кое-как, но этого будет недостаточно. При условии, что уже есть представление о том, как писать хорошо, очень сложно сознательно писать плохо.
Другого человека можно легко запутать, ведь он не знает ход ваших мыслей. Гораздо сложнее обыграть самого себя, чтобы уже через несколько дней было невозможно разобраться в том, что реально происходит и откуда все эти баги. В этой игре вы и есть ваш самый главный противник. Поэтому попробовать такой челлендж будет интересно как новичкам, так и опытным разработчикам, ведь у опытных разработчиков могут быть все более комплексные ухищрения.
В прошлый раз мы остановились на том, что сделали белый квадратик, перемещающийся по голубому фону. В этой части мы сделаем приемлемые спрайты машинок и, самое главное, создадим камеру, которая будет следовать за игроком.
Недавно у меня появилась задача по снижению аллокации в очень горячем месте кода. Там происходит тривиальное: запускаются Task'и в которых заранее известным набором handler'ов обрабатываются объекты. Вооружившись профайлером, я с удивлением обнаружил, что много памяти (и много времени GC) затрачивается на удаление объектов-замыканий.
Список CWE Top 25 отражает наиболее серьёзные недостатки безопасности ПО. Предлагаю вам ознакомиться с обновлённым топом в обзоре изменений за прошедший год.
Всем привет. Сегодня я хотел бы задеть такую тему, как рендеринг и шейдеры в Unity. Шейдеры - простыми словами это инструкции для наших видео-карт, которые говорят, как правильно отрисовывать и трансформировать объекты в игре. Итак, welcome to the club buddy.
В моей последней статье я поделился с вами десятью доводами в пользу модульного тестирования. В этой статье я разбираю сложности связанные с модульным тестированием кода с интерактивными диалоговыми элементами пользовательского интерфейса, которые требуют какого-либо ответа от пользователя.
Разработчики по всему миру ежедневно используют свои любимые IDE для создания программного обеспечения. Сегодня мы проверим одну из них и рассмотрим самые интересные найденные ошибки.
Всем привет. В своей истории я хотел бы поделиться опытом поиска и анализа московской биржи и историей реализации библиотеки для получения данных из нее. И что по итогу вышло.
Все случилось одним летним тёплым днем. Когда меня озарило, или солнечный удар случился, что надо вложиться в деньги. Пошарив по закромам, я даже нашёл небольшую финансовую подушку с остатками моей стипендии. Отлично, начало положено, теперь надо что-то купить, чтобы стать богатым.
Как-то раз у нас в цеху встала линия оцинкования: захлопнулись тормоза на натяжных станциях, ролики перестали крутиться и вывалилась куча ошибок, т.к. на ходу тормоз не должен накладываться. При выяснении причины, оказалось, что один из компрессоров выпал в ошибку и перестал качать воздух, давление в системе просело и не смогло удерживать тормоза на станциях натяжения в открытом состоянии. По истории ошибок на самом компрессоре тогда обнаружили, что был перегруз частотного преобразователя, а потому после запуска к компрессору стали проявлять особое внимание дабы такая ситуация больше не повторилась. Но она повторялась еще пару раз, компрессор в конце концов все же отревизировали, но написать хотелось конечно не об этом. Дело в том, что данный компрессор, как и многие современные устройства, был довольно умный – ну по крайней мере у него была возможность показывать через веб интерфейс данные о своем состоянии, как то: давление, температура и прочее. Поскольку компрессор может что-то передавать, то почему бы эти данные не собирать и потом при похожих ситуациях не анализировать, чтобы понимать что происходило в этот момент. Вот и возникла идея подключаться к веб-интерфейсу, парсить данные которые там есть и передавать их на специальный сервер который пишет сигналы с других агрегатов и механизмов. Вот об этом я и хотел рассказать, как мы это сделали.
В прошлый раз мы разобрали структуру проекта Monogame. Сегодня мы начнем писать структуру проекта и даже создадим белый квадрат, движением которого сможем управлять.
Данной статьей я открываю серию дневников разработки уже третьей реинкарнации моей будущей игры KARC. Первая версия дошла до минимально играбельного вида и выложена в открытый доступ. Однако, мне не понравилось, как я спроектировал структуру приложения. Поэтому, ошибочно полагая, что я понял, как правильно спроектировать архитектуру приложения, я сделал с нуля вторую версию. В ней мне удалось прогрузить сцену с машинкой игрока, которая реагирует на клавиатуру. Однако, развивать эту версию дальше я не посчитал целесообразным, потому что, увлекшись, накрутил слишком много всего и, самое главное, неправильно. В результате в коде стало очень трудно ориентироваться. Так бы и остался проект в заморозке на неопределенный срок, как и моя мечта делать игры, если бы я в очередной раз не решил попытаться понять архитектурные паттерны, в частности, MVP, и у меня это, внезапно не получилось бы. И так мне MVP понравился, что я понял, как хочу переписать архитектуру KARC. В этот раз я решил фиксировать все свои шаги на бумаге, а потом выложить в широкий доступ. Дело в том, что я делаю игру на фреймворке Monogame, но в сети я не нашел внятного руководства, как сделать на нем что-нибудь законченное. Есть много роликов и статей о том, как сделать какие-то отдельные элементы (например, какой метод подгружает спрайт, но не как лучше это осуществить, если их у вас много и под каждый игровой объект их несколько) или мелкие игры, которые тянут в лучшем случае на технодемку, но не создать какую-либо законченную игру целиком (кое-что на самом деле нашел, и ссылки в последующих статьях будут, но в целом мне не понравилось). Поэтому, возможно, описание моего пути кому-нибудь пригодится.
В разработке программного обеспечения иммутабельным (immutable — неизменяемым) называется объект, который после своего создания не может быть изменен. Зачем вам может понадобиться такой объект? Чтобы ответить на этот вопрос, давайте проведем анализ проблем, которые могут возникнуть в результате мутации (изменения) объектов. Вернемся к основам того, что делает каждое приложение: создает, извлекает, обновляет и удаляет данные (CRUD-операции). Ядро любого приложения манипулирует объектами. Ответ на вопрос о том, работает ли приложение в соответствии со своей спецификацией, в первую очередь определяется правильностью обработки данных. Вам необходимо быть уверенными, что код работает правильно, каждый раз, когда он затрагивает какой-либо объект.
Но что, если бы существовали объекты, которые не могли бы изменяться? Исходя из вышеизложенного, очевидно, что если объект не может измениться, то либо не будет кода, пытающегося изменить его, либо, если такой код все-таки написан, он не будет работать.
Если ваше приложение является многопоточным, иммутабельность должна быть фундаментальной частью вашей архитектуры, поскольку неизменяемые объекты по своей природе являются потокобезопасными и невосприимчивыми к состояниям гонки. Если ваше приложение использует data transport objects (DTO — объекты передачи данных), вам также следует серьезно подойти к иммутабельности ваших объектов. Предметом дискуссий остается лишь то, как наиболее эффективно реализовать и работать с иммутабельными объектами, поскольку C# не предлагает встроенной поддержки таких объектов. Эта статья предлагает ответ на этот вопрос.
В .Net, помимо типов class и struct, с недавних пор есть еще и типы record и record struct. Появление двух новых типов могло внести запутанность по поводу того, в чем их сходства и различия, и в каких случаях стоит их применять. В этой статье мы разберем, в каких ситуациях использовать class, record, struct, и какие преимущества даёт тот или иной тип в различных ситуациях. В конце мы приведем шпаргалку, которая поможет быстро определиться, какой из видов типов лучше подходит в том или ином случае.
Всем привет. Меня зовут Илья Постников. Я старший разработчик ПО в подразделении «Автоматизации бизнес-процессов» компании Digital Design. В этой статье я хотел бы поделиться опытом кастомизации контролов для web-клиента системы Docsvision (DV). Данная информация будет полезна инженерам, обслуживающим Docsvision и знакомым на начальном уровне с веб-технологиями React/Node.js и .Net MVC.
Надежные и постоянно меняющиеся пароли - это здорово. Особенно когда они меняются и на Wi-Fi роутере и WPS на нем вообще отключен. В этом посте: сколько занимает перебор WPS pin и есть ли у этого практическое применение? А еще напишем программу для брутфорса на C#
Привет, habr! Это моя первая статья, поэтому будет хорошим тоном представиться. Я независимый разработчик мобильных игр. Два года работаю на Unity и прогаю на C#. Выпустил одну инди-игрушку, которая хоть и не выстрелила, и не принесла денег, получила неплохие отзывы.
Эта статья про один из возможных способов создания расширяемой системы квестов, которая может пригодится во множестве игр.
Привет, Хабр! Я работаю разработчиком в АльфаСтрахование – в команде, которая занимается электронным документооборотом
В чем суть проблемы, с которой мы столкнулись: несмотря на то, что документооборот внутри компании полностью электронный, на «входе» документы могут поступать к нам в самых разных форматах: отсканированные с бумажных носителей, в «цифре» с ЭЦП или без электронной подписи – чтобы обеспечить сквозную обработку таких документов, в ряде процессов нам требуется распознавать наличие подписи.
Дженерики - мощная фича доступная во многих статически типизированных языках программирования. С их помощью можно писать код, который постоянно работает со множеством разных типов, делая упор на их общие особенности, нежели на сами типы. Они позволяют создавать гибкие и переиспользуемые компоненты без нужды в дублировании кода и жертвы безопасности типов.
Несмотря на то, что дженерики давно в C#, мне всё же удаётся найти новые интересные способы их применения. Например, в одной из моих предыдущих статей я написал об уловке, позволяющей добиться return type inference, что может облегчить работу с контейнерными union types.
Недавно, мне также довелось работать над кодом, использующим дженерики. Тогда передо мной встала нетипичная задача: было необходимо определить сигнатуру, где все типовые параметры опциональны и могут использоваться друг с другом в произвольных комбинациях. Первая попытка подступиться к решению заключалась в манипуляциях с перегрузками типов, однако такой подход оказался довольно непрактичным и не увлекательным.
После нескольких экспериментов, я нашёл способ решить проблему элегантно, используя подход схожий с паттерном проектирования fluent interface, который был применён не к объектам, а к типам. Мой подход предлагает domain-specific language, который позволяет разработчику построить нужный тип за несколько логических шагов, последовательно его "конфигурируя".
В данной статье я расскажу, что из себя представляет этот подход и как его можно использовать для того, чтобы сложные обобщённые типы писать просто.
