Курс преследует цель формирования у обучающихся, как предметной компетентности в области технического проектирования и моделирования с использованием информационных компьютерных технологий для личного развития и профессионального самоопределения.
Макашева А.Н.
Описание разработки
Пояснительная записка
Предлагаемый курс составлен на основе элективного курса «Учимся проектировать на компьютере», созданного авторским коллективом М. Ю. Монаховым, С. Л. Солодовым, Г. Е. Монаховой.
Цели, задачи, образовательные результаты.
Курс преследует цель формирования у обучающихся, как предметной компетентности в области технического проектирования и моделирования с использованием информационных компьютерных технологий для личного развития и профессионального самоопределения.
Задачи: ознакомление с предметом автоматизированного проектирования и профессиональной деятельностью инженеров – проектировщиков — дизайнеров; овладение практическими навыками работы с современными графическими программными средствами.
Проектирование частного дома, с чего начинать? Основы. Видео №1
Задачи решаются посредством: модульного обучения, проведения теоретических (лекции) и практических (лабораторные работы) занятий по тематике курса, разработки и публичной защиты проекта.
Обучающиеся будут знать: характеристики и основные принципы построения композиции при создании графических изображений, основные понятия, способы и типы компьютерной графики принцип работы прикладных компьютерных систем AutoCAD.
Будут уметь: использовать законы композиции, освещения цвета и формы при создании графических образов, использовать основные команды и режимы системы AutoCAD.
Приобретут навыки: в построении композиции при создании графических изображений, в использовании системы автоматизированного проектирования AutoCAD.
Задачи решаются посредством:
проведения теоретических (лекции) и практических (лабораторные работы) занятий по тематике курса;
выбора различных заданий для самостоятельной работы;
углубленного изучения тематики посредством подготовки рефератов;
самостоятельного выбора обучающимися объекта для проектирования (компьютерного моделирования), разработки и публичной защиты проекта;
использования в ходе реализации индивидуального проекта различных информационных ресурсов (в том числе Интернета);
выполнения как индивидуальных, так и групповых заданий на проектирование и компьютерное моделирование различных объектов.
Рекомендуемые учебные материалы.
Практикум «учимся проектировать на компьютере».
Электронное учебное пособие «Учимся проектировать на компьютере».
Учебное пособие «Создаем чертежи на компьютере». Съемщикова Л. С. г. Москва, 2005 г.
Курс рассчитан на 1 год обучения. Занятия проводятся по 2 часа в неделю. В рамках курса общим объемом 70 часов предполагается развитие пользовательских навыков работы с ПЭВМ, использование готовых программных продуктов, облегчающих и автоматизирующих труд в сфере дизайна и конструирования. Курс не требует серьезного знания математического аппарата и языков программирования.
Как научиться проектировать дома? С чего начать? Сколько учиться?
Учащиеся будут знать:
характеристики и основные принципы построения композиции при создании графических изображений в изобразительном творчестве, техническом дизайне, анимации;
основные принципы освещения объектов на предметной плоскости, виды освещения и особенности цветопередачи;
принципы и способы передачи движения при создании компьютерной анимации;
основные понятия, способы и типы компьютерной графики, особенности воспроизведения изображений на экране монитора и при печати на принтере;
принципы работы прикладной компьютерной системы автоматизированного проектирования AutoCAD, приемы использования меню, командной строки, панели инструментов, строки состояния;
основные методы моделирования графических объектов на плоскости;
системные способы нанесения размеров на чертеж и их редактирование;
принципы работы прикладной компьютерной системы трехмерного моделирования 3D Studio MAX, основные приемы работы с файлами, окнами проекций, командными панелями;
приемы формирования криволинейных поверхностей;
особенности системного трехмерного моделирования;
приемы моделирования материалов;
основные способы создания фона для трехмерной сцены;
базовые системные средства управления анимацией объектов и визуализацией сцен.
Учащиеся будут уметь:
использовать законы композиции, освещения, цвета и формы при создании графических образов;
мотивированно выбирать определенный тип компьютерной графики под конкретную задачу;
использовать основные команды и режимы прикладной компьютерной системы автоматизированного проектирования AutoCAD;
создавать и вносить изменения в чертежи (двумерные модели) объектов проектирования средствами компьютерной прикладной системы;
использовать основные команды и режимы системы трехмерного моделирования прикладной компьютерной системы трехмерного моделирования 3D Studio MAX;
выполнять анимацию объекта и визуализацию трехмерной сцены.
Учащиеся приобретут навыки:
построения композиции при создании графических изображений;
выбора правильного освещения объектов и их цветов на предметной плоскости;
использования меню, командной строки, панели инструментов, строки состояния прикладной компьютерной системы автоматизированного проектирования AutoCAD;
нанесения размеров на чертеж и их редактирование;
работы с файлами, окнами проекций, командными панелями прикладной компьютерной системы трехмерного моделирования 3D Studio MAX;
создания криволинейных поверхностей моделей объектов;
проектирования несложных трехмерных моделей объектов;
проектирования материалов объектов;
создания фона для трехмерной сцены;
работы в группе над общим проектом.
Преподавание курса включает традиционные формы работы с учащимися: лекционные, практические (лабораторные) занятия и самостоятельную работу. Все эти формы желательно проводить в компьютерном классе. Лабораторные (практические) занятия проводятся по одному заданию для всех одновременно.
Самостоятельная работа предназначена для выполнения индивидуального задания, например в рамках группового проекта. Упор в освоении курса сделан на практические занятия (лабораторные и самостоятельные), доля которых составляет приблизительно 85% от объема всего курса. За счет времени, отведенного на самостоятельную работу, возможен резерв для более глубокого изучения тем.
Тематическое планирование:
Весь материал — смотрите документ.
Источник: videouroki.net
Книги по проектированию и архитектуре приложений
Недавно я ответил на вопрос про Хранилище (Repository) на русском Stack Overflow. Автор вопроса попросил порекомендовать литературу по дизайну и архитектуре приложений. В рамках комментария отвечать оказалось неудобно, и я написал эссе о полезных книгах.
Приёмы объектно-ориентированного проектирования
Книга, известная в народе, как GoF или главная книга о паттернах. Я не нашёл в интернете информации, как познакомились авторы и почему они назвали себя бандой четырёх. Знаю, что все они в то или иное время работали в IBM. Эрих Гамма вместе с Кентом Беком разработал JUnit — предтечу всех современных фреймворков модульного тестирования.
Если вы пишите модульные тесты, вы знаете, кого за это благодарить. Джон Влисидис умер в 2005-м в возрасте сорока четырёх лет.
Хелм и Джонсон не участвовали в известных мне проектах.
С момента выхода первого издания прошло 25 лет. Что мы узнали за это время?
- Термин паттерн трактуется слишком широко. Я слышал про паттерны многозвенное приложение, инверсия зависимостей и микросервис-заместитель (proxy microservice). Ничто из этого я бы к паттернам не отнёс. Автор оригинальной концепции Кристофер Александр говорит не просто о паттернах, а об языке паттернов. Язык предполагает общение и понимание, поэтому я против того, чтобы паттернами называли что угодно. Многозвенная архитектура — это модель, а инверсия зависимостей — принцип. Авторы книги дали паттернам узкое определение, ограничившись объектно-ориентированными языками. Они сформулировали ясную нижнюю границу — паттерном не может быть то, что входит в стандартную библиотеку. Нет паттернов массив и поток.
- Шестнадцать из двадцати трёх оригинальных паттернов могут быть выражены простыми языковыми средствами, что и продемонстрировал Петер Норвиг в своей статье. Языком программирования был не C++, а LISP. Получается, что некоторые паттерны — это просто досадная необходимость, вызванная слишком низким уровнем языка. Впрочем, в функциональных языках могут быть свои паттерны. Кроме того, паттерн может быть всё-таки языковым средством, который говорит о назначении объекта. Видя в коде Хранилище пользователей (User Repository) мы понимаем, что пользователи хранятся в базе, но нам, слава богу, не надо ничего знать об этой базе. Мы концентрируемся на бизнес-логике.
- Паттерн Одиночка (Singleton) на поверку оказался антипаттерном. Он нарушает принцип единственной ответственности, потому что экземпляр одиночки выполняет свою основную функцию и одновременно управляет временем своей жизни. Избавиться от одиночки можно, передав управление временем жизни в IoC-контейнер. Термин антипаттерн прочно вошёл в наш лексикон вместе с паттерном.
- Язык паттернов оказался полезным. Я ни разу в жизни не использовал Интерпретатор (Interpreter) и трепещу перед Посетителем (Visitor), считая его сложным. Я с удовольствием использую Единицу работы (Unit of Work), Хранилище (Repository), Корень композиции (Composite Root), Внедрение через свойство (Property Injection) и десятки других паттернов.
Резюме
На определённом этапе профессионального становления книгу надо обязательно прочитать. Названия паттернов надо использовать в своей речи и в своём коде. Важно не путать паттерны друг с другом, потому что это и правда язык. Неправильный язык ведёт к заблуждениям.
Обращайте внимание на источники. Если ваш друг Жора придумал паттерн, это не паттерн. Настоящий паттерн, как элемент общего языка, должен быть описан в популярной книге или в статье на посещаемом ресурсе. Паттерн должен быть описан в классической форме, то есть как в GoF, с разделами Название, Назначение, Реализация, Плюсы и минусы.
Словосочетание паттерн микросервис в какой-то статье из интернета не делает микросервис паттерном.
Шаблоны корпоративных приложений
Основной автор книги Мартин Фаулер. У него пять соавторов, про которых я ничего не слышал. Google подсказывает, что у одного из них есть забытый профиль на GitHub, другой последние десять лет работает управленцем, а третий что-то там из Oracle.
Не смотря на таинственность авторов, книгу следует признать самой полезной книгой о паттернах. У неё есть сокращённое название P of EAA, то есть Patterns of Enterprise Application Architecture. Если GoF вводит нас в тему, то P of EAA погружает нас в самую пучину.
Рассмотрим на примере. В Entity Framework доступ к данным осуществляется через класс DbContext .
В DbContext изменения в базу вносятся не тогда, когда вы обновляете поля сущностей или вызываете методы удаления, а когда вызываете SaveChanges . Объект накапливает сделанные вами изменения и затем разом их вносит. Вам не приходится следить за тем, чтобы записи добавлялись или удалялись в правильном порядке — DbContext делает это за вас. Все ваши составные операции атомарны — если одна из них завершится ошибкой, отвергнуты будут все накопленные изменения.
На уровне базы данных мы называем такие операции транзакциями, но транзакции слишком детальны для слоя бизнес-логики. Мы можем игнорировать всё, что относиться к уровням изоляции или к вложенности. Паттерн Единица работы (Unit of Work) нужен как раз для этого и DbContext его реализует.
Почему в DbContext нет групповой операции удаления? Потому что в Unit of Work нет такой операции. Как обычно, паттерн хорош в одних сценариях, и не очень хорош в других. Полезно знать его ограничения, чтобы делать свою программу эффективной.
Entity Framework умеет преобразовывать деревья выражений в SQL-запросы. Дерево выражений в данном случае — это Объект-запрос (Query Object), паттерн, описанный Фаулером.
После загрузки данных, Entity Framework заполняет поля объектов из базы. Задача эта нетривиальная. Фаулер описывает набор классов, необходимых для заполнения полей, как паттерн Преобразователь данных (Data Mapper). Наряду с преобразователям, в программах регулярно встречаются Активная запись (Active Record), Шлюз к данным записи (Row Data Gateway), Шлюз к данным таблицы (Table Data Gateway) и другие. Их нет в Entity Framework, но вы найдёте их в ADO.NET или zend-db.
Резюме
Эту книгу надо прочитать, чтобы понимать, что встречается в современной бизнес-разработке. Не обязательно уметь готовить все эти паттерны, достаточно иметь представление о разнообразии решений.
Внедрение зависимостей в .NET
Инверсия зависимостей (Dependency Inversion) — не самая простая концепция. Её трудно объяснить на пальцах, и если вы поняли её на пальцах, возможно, вы поняли её неправильно.
Инверсия зависимостей — старая идея, которую можно встретить даже в стандартной библиотеке C, а именно в функциях bsearch и qsort . Наверняка, это не самый ранний пример, но языку C в 2019-м году исполняется 50 лет, и это значит, что DI, как принцип, известен в мире программирования уже очень давно.
Чтобы принцип работал, нужно придумать, как внедрять зависимости. В C это делается через указатель на функцию с известной сигнатурой, в объектно-ориентированных языках — через параметры конструктора, свойства класса или параметры методов. Паттерны Constructor Injection, Property Injection и Method Injection как раз об этом.
Помимо общих принципов важны, конечно, и детали. Симан показывает, как внедрять зависимости вручную, как внедрять их через Castle, Autofac, Unity. Этого достаточно, чтобы перестать беспокоиться о конкретных библиотеках. Они похожи.
Резюме
Локатор служб (Service Locator) — это антипаттерн, а не паттерн. Книгу надо прочитать, если вы пишете на C#. Если вы пишете на другом объектно-ориентированном языке, она тоже может быть полезна.
Искусство автономного тестирования с примерами на С#
Как писать модульные тесты (unit tests)? Есть несколько рекомендаций, которые, к сожалению, трудно применять на практике. Когда я начинал осваивать автоматическое тестирование, я по два часа зависал на тестах. Мне казалось, что для тестирования вот этой вот штуки мне потребуется другая штука, которую тоже нужно написать.
С тестами не задавалось. После того, как они были написаны, их приходилось постоянно переписывать. Да, я знаю, что тесты должны быть устойчивы. Спасибо.
Оказалось, что модульное тестирование, если его готовить правильно, требует серьёзного изучения. На помощь, конечно, приходит книга, и в случае юнит-тестов это книга Роя Ошероува. Причём здесь архитектура, спросите вы? Архитектура притом, что при написании тестов вам придётся делать классы маленькими и слабо сцепленными.
Резюме
Книга полезна и для того, чтобы практически освоить искусство написания модульных тестов, и для того, чтобы практически освоить принципы SOLID.
Чистая архитектура
Последняя в списке, но не по значению.
Роберт Мартин, он же дядюшка Боб, известен нам с давних пор. Был такой журнал — C++ Report, который выходил c 1989 по 2002 год. Время рассвета C++. Именно там появились первые современные практики проектирования — до того, как придумали Java.
Дядюшка Боб был редактором этого журнала. Он сформулировал принципы SOLID. Он участвовал в обсуждении Манифеста гибкой разработки.
Он написал книгу о чистой архитектуре. Главная идея книги — кто управляет зависимостями, тот управляет миром. Чтобы проект оставался подконтрольным, снижайте количество зависимостей. Организуйте зависимости, без которых нельзя.
Важное знание, которое я получил из книги — никто не знает будущего. Никто не знает, что потребуется от программы через два года. И никакие ваши усилия не позволят вам придумать архитектуру, способную поддержать изменения, которые потребуются через два года. Каким бы умным вы ни были, вы ошибётесь.
Резюме
Книгу стоит перечитывать время от времени. С каждым новым проектом ваш опыт растёт, и этот опыт надо реструктурировать с помощью специальной литературы. Дело не в том, чтобы узнать новое. Дело в том, чтобы устаканить то, что уже есть в голове.
Написать мне в Telegram
Источник: markshevchenko.pro
Блог Степана Родионова
Основным направлением деятельности нашей компании является создание интернет-проектов, потенциально рассчитанных на средние и высокие нагрузки. Такие проекты требуют иногда совершенно другого подхода к проектированию архитектуры в отличие от типичных корпоративных приложений. Нам приходится изучать много материалов по теме highload.
Этой публикацией я хочу начать серию небольших статей, в которых раскрою основные темы, необходимые для понимания устройства систем, рассчитанных на работу под высокими нагрузками. Эти статьи являются компиляцией нашего опыта, полученного при работе над сложными проектами, а также опыта наших коллег и материалов с конференций Highload++.
Начну с самого начала.
Подходы к построению веб-приложений.
Монолитные приложения.
Монолитное приложение — это один большой кусок кода. Как правило, такие приложения могут работать очень быстро, т.к. у них нет никаких задержек на коммуникацию между модулями, но при этом крайне сложно поддаваться масштабированию.
Помимо проблем с масштабированием самого приложения, монолитные системы имеют проблемы с масштабированием разработки, т.е. очень трудно подключить к разработке новых программистов. Как правило, их разрабатывает один или несколько специалистов и уход из команды одного из них создает большие проблемы. Однако, при правильном проектировании архитектуры, при соблюдении хороших принципов проектирования, можно без проблем масштабировать разработку таких приложений. При этом, как правило, большая часть команды должна быть достаточно высокого профессионального уровня.
Сервис-ориентированные приложения.
Сервис-ориентированные приложения предполагают разбиение программного решения на некоторые сервисы, каждый из которых решают свою определенную задачу. Общение между сервисами происходит по некоторому протоколу, например, HTTP.
Основная проблема таких систем — наличие некоторой задержки при передаче данных от одного сервиса другому. Помимо этого, деплоить такие системы, как правило, сложнее, чем монолитные приложения.
Один из главных плюсов сервис-ориентированного подхода — возможность без проблем вести распределенную разработку. Речь не о географической распределенности. Я говорю про ситуацию, когда разработку определенной части системы можно отдать другой команде или на аутсорс. Просто сказать: «Есть такая-то задача, API должен быть такой».
Весь остальной проект продолжает жить как жил раньше, а отдельная команда делает новый сервис. Кстати, обычно так проект и развивается. Берется монолитное приложение и постепенно разбивается на отдельные сервисы, каждый из которых берет на себя строго одну задачу.
Теперь давайте перейдем к понятию масштабирования архитектуры. Существует два типа масштабирования — вертикальное и горизонтальное.
Масштабирование архитектуры.
Вертикальное масштабирование.
Вертикальное масштабирование заключается в увеличении производительности системы за счет увеличения мощности сервера. Всё. По сути, задача увеличения производительности ложится на плечи производителей железа. Заменили железо на более мощное — система начала работать быстрее.
Главный недостаток — у вертикального масштабирования есть определенный предел. В какой-то момент закупить такое железо станет либо нерентабельно, либо невозможно. Плюс ко всему, не всегда наблюдается прямая зависимость от мощности сервера к производительности системы.
Горизонтальное масштабирование.
Основной принцип горизонтального масштабирования заключается в том, что у нас есть возможность подключать дополнительные серверы, хранилища для увеличения производительности системы. Основная сложность — научить наше программное решение правильно использовать их все.
Конечно, ограничения есть и в этом подходе (нет ничего идеального :)). Иногда даже употребляют термин «диагональное» масштабирование, оно предполагает совмещение этих двух подходов, т.е. вы одновременно покупаете новое железо и активно переписываете приложение. Примерно так построена работа во всем известном Stack Overflow.
Вообще, чтобы правильно выполнять любое масштабирование, нужно хорошо понимать предметную область проекта: как движутся данные внутри системы, как они обрабатываются, откуда и куда переходят. Иногда можно заметить, что некоторые данные всегда должны быть актуальными, а на другие можно на время «забить» и показывать обновления не сразу.
Реальный пример из реального проекта. Когда вы постите фотку в Instagram, вы сразу видите ее в своей ленте, а ваши подписчики увидят ее только через какое-то время (причем разные подписчики через разное время). Это связано с так называемой отложенной (или асинхронной) обработкой данный. Запрос на добавление фотографии в ленту подписчика добавляется в специальную очередь, поэтому фотография появляется с небольшой задержкой.
Вообще такой подход называется «масштабированием во времени». В его основе лежит понимание того, что разные данные имеют разные требования к обновлению, что позволяет нам отложить их обработку до более удачного случая.
Трехзвенная архитектура.
Нагруженные распределенные системы, как правило, имеют три звена — frontend, backend и storage (хранение данных). У каждого звена свои функции и оно по своему масштабируется. Наличие такой архитектуры серверов уже говорит о том, что система — высоконагруженная.
Изначально запрос от пользователя приходит на frontend. Frontend-серверы обычно отвечают за отдачу статики. Дальше запрос идет на backend-сервер, где происходят все нужные вычисления и сборка страницы. Если нужно, то backend взаимодействует с третим — хранилищем. Вообще, frontend-сервер — это, как правило, такой легкий и быстрый веб-сервер (обычно nginx), который не занимается вычислениями, и если может, то сразу отдает клиенту ответ, либо проксирует его на backend.
На этом вводная статья закончена. Мы познакомились с основными определениями и терминами, в следующей статье мы попробуем разобраться как масштабируются и оптимизируются backend и frontend.
Источник: blog.antidasoftware.com