С чего начать изучение docker:
- «Использование Docker» (Моуэт Эдриен), O’Reilly Media скачать pdf
http://www.managepy.ru/использование-docker-pdfdrive/
С чего начать изучение docker:
Краткие тезисы книги М.Фаулера Шаблоны корпоративных приложений
Три слоя
Представление — отображение данных, обработка пользовательских событий, запросов
Домен — Бизнес-логика приложения
Источник данных — управление БД и пр.
Бизнес-логика
Сценарий транзакции (Transaction Script)
стр. 133
Организует бизнес-логику в процедуры, которые управляют каждая своим запросом. В некоторых случаях это может быть просто вывод данных из БД. В других случаях эти действия могут содержать в себе множество вычислений и проверок. Но для каждого пользовательского действия должна быть определена единая процедура, содержащая необходимые действия.
Модель предметной области (Domain Model)
стр. 140
Cеть взаимосвязанных объектов, в которой каждый объект представляет собой отдельную значащую сущность: может быть настолько большую, как корпорация или настолько малую, как строка из формы заказа.
Модуль таблицы (Table Module)
стр. 148
Очень напоминает DomainModel. Однако, если в Domain Model каждый объект сущности соответствует одному объекту класса, то в данном паттерне 1 объект управляет всеми объектами представляемой сущности.
Слой служб (Service Layer)
стр. 156
Инкапсулирует бизнес-логику приложения, предоставляя интерфейс, который принимает на себя взаимодействие с «внешним миром»
Источники данных
Шлюз таблицы данных (TableDataGateway)
стр. 167
Представляет собой объект-прослойку между таблицей и приложением. В нем реализованы методы, которые позволяют выполнять операции над таблицей, не вдаваясь в подробности SQL-команд.
Шлюз записи данных (RowDataGateway)
стр. 175
см. Шлюз таблицы данных, только для 1 строки
Активная запись (ActiveRecord)
стр. 182
объект управляет и данными и поведением, подобно Шлюз записи данных предоставляет операции с записью таблицы, а также дополняется методами прочих операций.
Преобразователь данных (DataMapper)
стр. 187
Паттерн разделяющий объект и БД, служащий прослойкой между ними, направлен на исключение из класса объекта кода по работе с БД.
Моделирование поведения
Единица работы (Unit Of Work)
стр. 205
По сути представляет собой объект работы транзакции. Отслеживает изменения в БД.
Коллекция объектов (Idenity Map)
стр. 216
хранит записи об объектах, которые были извлечены из БД. при запросе, сначала ищет объект в коллекции, а затем идет в БД.
Загрузка по требованию (LazyLoad)
стр. 222
паттерн, использующий стратегию загрузки данных только тогда, когда они нужны. сейчас широко распространен в JS расширениях, когда изображения и данные загружаются только тогда, когда пользователь действительно должен их увидеть.
Предоставление данных в WEB
Модель — представление — контроллер (MVC)
стр. 347
основа большого количества фреймворков, отвечающая делению на слои, которые указаны в начале данного поста.
Контроллер страниц (Page Controller)
стр. 350
паттерн, предполагающий наличие контроллера для каждой отдельно взятой web-страницы. анализирует url, извлекает данные из модели, определяет представление, которое должно быть предоставлено пользователю.
Контроллер запросов (Front Controller)
стр. 362
предоставляет объкт-обработчик, который объединяет действия по обработке запроса (контроль доступа, язык, спец. возможности)
Представление по Шаблону (Template View)
стр. 368
представляет возможности динамического изменения шаблона, используя замену специальных вставок (маркеров) на соответствующую им информацию.
Представление с преобразованием (Transform View)
стр. 379
представление данных, полученных из модели в пригодном для отображения на странице виде.
Двухэтапное представление (Two step view)
стр. 383
получает данные от модели в некую логическую структуру, которая затем проходит второй этап и встраивается в страницу.
Контроллер приложения (Application Controller)
cтр. 397
Перемещает логику выбора действия над моделью или отображения преставления в одну точку, к которой обращается контроллер входа.
Распределенная обработка данных
Интерфейс удаленного доступа (Remote Facade)
стр. 405
Предоставляет более общий интерфейс, объединяющий вызовы более мелких методов объекта. Позволяет сэкономить межсетевое взаимодействие.
Объект переноса данных (Data Transfer Object)
стр. 419
Позволяет за один запрос-ответ получить данные например по нескольким объектам, также экономя ресурсы на обращение к удаленному интерфейсу. В ответ мы получаем сериализованный объект, например по формату json, xml.
Базовые типовые решения
Шлюз (GateWay)
стр. 483
Объект, который инкапсулирует доступ к внешней системе или ресурсу.
Преобразователь (Mapper)
стр. 489
Объект, который управляет сообщением между независимыми друг от друга объектами.
Супертип слоя (Layer Supertype)
стр. 491
Это суперкласс для всех объектов слоя, объединяющий основные функции.
Отдельный интерфейс (Separated Interface)
стр. 492
Выделение какого-либо интерфейса к объекту в отдельный от объекта пакет. Обычно нужно для реализации логики, противоречащей концепции.
Реестр (Registry)
стр. 495
Паттерн реализующий статический набор методов, который позволяет организовать хранилище объектов с адресацией по ключам.
Объект-значение (Value Object)
стр. 500
объект класса, который хранит специфические значения, реализующий например нестандартную логику сравнения.
Деньги (Money)
стр. 502
Класс реализующий объекты денег, и методы их сложения, перевода, округления и т.п.
Частный случай (Special Case)
стр. 511
Практика вместо null значений возвращать объект класса с тем же интерфейсом, чтобы сократить ситуации с вызовом метода от null.
Дополнительный модуль (Plugins)
стр. 514
Связывает классы на основе конфигурации, а не явного указания в коде.
Фиктивная служба (Service stub)
стр. 519
заглушка, использующаяся как на этапе разработки и тестирования, чтобы не вносить ложные данные в продуктивный контур сервиса, так и для обхода зависимости системы от работоспособности стороннего сервиса.
Множество записей (Record Set)
стр. 523
Предоставляет объект соответствующий результату запроса к таблице или записи, позволяющий добавлять бизнес-логику.
Краткие тезисы из книги Т.Демарко Т. Листер Человеческий фактор: успешные проекты и команды
скачать книгу Т.Демарко Т. Листер Человеческий фактор: успешные проекты и команды
Основные цитаты:
Серьѐзные проблемы в нашей работе имеют не столько технологическую сколько социологическую природу.
Когда люди совершают ошибки, их следует поздравлять, потому что они получают деньги в том числе и за ошибки.
Единственное стабильное состояние в жизни проекта – трупное окоченение. Проект постоянно находится в движении. Человек, способный заставить проект шевелиться, стоит двух, просто выполняющих работу.
В паре лишних субботних часов, позволяющих уложиться в сроки и сдать проект в понедельник, может быть очевидная польза, но за ними всегда следует равносильный период компенсации, сокращения рабочего времени, позволяющий сотрудникам вернуться в ритм привычной жизни. В конечном итоге каждый час сверхурочных компенсируется часом недоработки. В краткосрочной перспективе такой компромисс может принести пользу проекту, но в долгосрочной польза нивелируется.
Под давлением люди работают не лучше, а всего лишь быстрее
Коварный эффект текучки в том, что она порождает текучку. Люди уходят быстро, поэтому нет смысла тратить деньги на их обучение. Поскольку компания ничего не вкладывает в человека, ему легко с нею распрощаться. Новых сотрудников нанимают не за их превосходные качества, поскольку заменить такие качества будет слишком сложно. Ощущение же, что компания не видит в сотруднике ничего необычайного, вызывает у этого сотрудника чувство неоцененности как индивидуума. Другие, кстати, постоянно увольняются, значит, с вами что-то не так, если вы ещѐ на год задержитесь здесь.
Есть несколько характерных признаков того, что произошла кристаллизация команды. Самый важный – низкая текучесть кадров в проектах и в ходе выполнения чѐтко сформулированных заданий. Участники команды никуда не собираются идти, пока не сделают работу. При этом невозможно найти универсальный катализатор. Процесс слишком хрупок, чтобы им управлять
перечень элементов стратегии создания здоровой химии для процветающей организации:
• Возводить качество в ранг культа.
• Создавать многочисленные промежуточные финиши, приносящие удовлетворение.
• Внушать чувство элитарности.
• Допускать и поощрять неоднородность.
• Сохранять и защищать успешные команды.
• Раздавать стратегические, но не тактические указания.
К-О-М-А-Н-Д-Н-А-Я Р-А-Б-О-Т-А …Позволяет Простым Людям Достигать Непростых Результатов
Самый страшный грех руководителя – впустую тратить чужое время.
Вывод: книга, которую нужно перечитывать несколько раз.
Краткая идея и тезисы книги «Deadline. Роман об управлении проектами»
Самая основная мысль книги в том, что для руководителя важнее всего — это человек.
Его текущее моральное и физическое состояние, мысли, страхи.
Основные цитаты (на мой взгляд):
Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени. Люди не начнут быстрее соображать, если руководство будет давить на них. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего-то очень боятся.
Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
Нам кажется, что самое страшное — не знать чего-то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.
Далее будет почти полная выдержка цитат из блокнота Томпкинса
Скачать книгу Краткая идея и тезисы книги «Deadline. Роман об управлении проектами»
«Мифический человеко-месяц, или Как создаются программные системы»
Ф.Брукс
Вводимые термины в книге:
программный комплекс — набор взаимодействующих
программ, согласованных по функциям и форматам, и вкупе составляющих полное
средство для решения больших задач.
программный продукт — Чтобы стать общеупотребительным программным продуктом, программа должна быть написана в обобщенном стиле. В частности, диапазон и вид входных данных должны быть настолько обобщенными, насколько это допускается базовым алгоритмом. Затем программу нужно тщательно протестировать, чтобы быть уверенным в ее надежности. Для этого нужно подготовить достаточное количество контрольных примеров для проверки диапазона допустимых значений входных данных и определения его границ, обработать эти примеры и зафиксировать результаты. Наконец, развитие программы в программный продукт требует создания подробной документации, с помощью которой каждый мог бы использовать ее, делать исправления и расширять.
системный программный продукт — отвечает требованиям к программному комплексу, и программному продукту.
Хирург — лично определяет технические условия на функциональность и эксплуатационные характеристики программы, проектирует ее, пишет код, отлаживает его и составляет документацию. Он пишет на языке структурного программирования, и имеет прямой доступ к компьютерной системе, на которой не только производится отладка, но и сохраняются различные версии его программ с возможностью легкой модификации файлов, а также осуществляет редактирование документации. Он должен обладать большим талантом, стажем работы свыше десяти лет и существенными знаниями в системных и прикладных областях.
Второй пилот — может выполнять любую работу хирурга, но менее опытен. Его главная задача — участвовать в проектировании, где он должен думать, обсуждать и оценивать. Хирург испытывает на нем свои идеи, но не связан его предложениями.
Администратор — отвечает за деньги, людей, помещения, машины, и контакты с административным механизмом организации в целом.
Редактор — Задача редактора — взять созданный хирургом черновик, критически переработать, снабдить ссылками и библиографией, проработать несколько версий и обеспечить публикацию.
Два секретаря — Администратору и редактору нужны секретари. Секретарь администратора обрабатывает переписку, связанную с проектом, а также документы, не относящиеся к продукту.
Делопроизводитель — отвечает за регистрацию всех технических данных бригады в библиотеке программного продукта, превращение программирования «из личного искусства в общественную деятельность»
Инструментальщик — ответственный за обеспечение доступа к основным службам, а также за создание, поддержку и обновление специальных инструментов — в основном, интерактивных служб, которые требуются его команде. Инструментальщик обычно пишет специализированные утилиты, каталогизированные процедуры, макробиблиотеки.
Отладчик — планирует последовательность тестирования и создание среды для тестирования компонентов.
Языковед — может найти эффективные способы использования языка для решения сложных, неясных и хитроумных задач. Иногда ему требуется провести небольшое исследование (два-три дня) для нахождения удачной технологии. Один языковед может работать с двумя или тремя хирургами.
Полезные цитаты из контекста:
Об удовольствии создания программ
..программирование доставляет удовольствие, поскольку отвечает глубокой внутренней потребности в творчестве и удовлетворяет чувственные потребности, которые есть у всех нас..
про оценку времени выполнения задач
Во-первых, слабо развиты наши методы оценок. В сущности, они отражают молчаливое и совершенно неверное предположение, что все будет идти хорошо.
Во-вторых, наши методы оценки ошибочно путают достигнутый прогресс с затраченными усилиями, неявно допуская, что скорость выполнения проекта пропорциональна количеству занятых в нем сотрудников.
В-третьих, поскольку менеджеры программных проектов не уверены в своих оценках, им часто недостает вежливого упрямства, как у шеф-повара ресторана «Антуан».
В-четвертых, выполнение графика работ слабо контролируется. Типовые опробованные в других инженерных дисциплинах методы считаются радикальными нововведениями при разработке программного обеспечения.
В-пятых, при обнаружении отставания от графика естественной и общепринятой реакцией является увеличение числа разработчиков. Это все равно, что тушить пламя бензином. В результате дела идут значительно хуже. Чем сильнее пламя, тем больше нужно бензина, и в итоге этот путь приводит к катастрофе.
1/3 — планирование,
1/6 — написание программ,
1/4 — тестирование компонентов и предварительное системное тестирование,
1/4 — системное тестирование при наличии всех компонентов.Это правило имеет несколько важных различий с общепринятым планированием:
1. На планирование отводится больше времени, чем обычно. И все равно этого времени едва достаточно для разработки подробных и надежных технических условий и недостаточно для проведения исследовательских работ или поиска новейших технологий.
2. Половина графика работ, отведенная на отладку законченного кода, значительно выше нормы.
3. Та часть, которую легко оценить, т.е. написание кода, занимает всего одну шестую общего времени.Омлет, обещанный через две минуты, может успешно жариться, но если через две минуты он не готов, то у клиента есть две возможности: ждать еще или съесть его сырым. Тот же выбор встает и перед заказчиком программного обеспечения. У повара есть еще одна возможность: добавить жару. В результате омлет часто оказывается безнадежно испорченным: горелым с одного края и сырым — с другого.
Закон Брукса
Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
Система 10
Концептуальная целостность
Во всех частях должны найти отражение единая философия и единообразные пропорции между желаемыми целями. В каждой части должны также использоваться одинаковый синтаксис и сходные семантические обозначения. Таким образом, простота использования требует единства проекта, концептуальной целостности.
Оптимизация
Во-первых, организовать обучение технике программирования, а не просто полагаться на природный ум и предшествующий опыт. Это особенно важно, если машина или язык новые. Особенности их эффективного использования нужно быстро изучить и сделать общим достоянием, возможно, присуждая особые призы за освоение новой техники.
Во-вторых, нужно понять, что у программирования есть технология и компоненты нужно собирать из готовых частей. В каждом проекте должен иметься набор хороших процедур или макросов для обработки очередей, поиска, хеширования и сортировки, причем не менее чем в двух вариантах: одном быстром, другом экономящем память.
Количество ошибок по времени внедрения
В начале существует тенденция повторного появления ошибок, найденных и устраненных в предыдущих версиях. Обнаруживаются ошибки в функциях, впервые появившихся в новой версии. Все они исправляются, и в течение нескольких месяцев все идет хорошо. Затем количество обнаруженных ошибок снова начинает расти. По мнению Кэмпбелл, это происходит потому, что пользователи выходят на новый уровень сложности, начиная полностью применять новые возможности версии. Эта интенсивная работа выявляет более скрытые ошибки в новых функциях.
Концептуальные ошибки дороже, чем синтаксические. К.О.
сложность создания программного обеспечения заключается в задании технических требований, проектировании и проверке этой концептуальной конструкции, а не в затратах, связанных с ее представлением и проверкой точности представления.
Как растить выдающихся проектировщиков?
• Систематически и как можно раньше выявлять первоклассных проектировщиков. Лучшие — не всегда самые опытные.
• Назначить наставника, ответственного за рост перспективного проектировщика и тщательно следить за его карьерой.
• Разработать и осуществлять план служебного роста для каждого перспективного проектировщика, включающий тщательно продуманное обучение у передовых проектировщиков, периоды дополнительного формального обучения, краткосрочные курсы, перемежающиеся с самостоятельным проектированием и назначением на руководящие технические должности.
• Обеспечить возможности для взаимодействия и взаимного стимулирования растущих проектировщиков.
Скачать книгу «Мифический человеко-месяц, или Как создаются программные системы»
Список хорошей литературы
1. Архитектура корпоративных приложений Фаулер pdf.
+ Шаблоны корпоративных приложений
arhitektura_korporativnyh_programmnyh_prilozhenij_fauler_m
2. «Мифический человеко-месяц, или Как создаются программные системы» автора Фредерик Брукс pdf скачать
«Мифический человеко-месяц, или Как создаются программные системы» автора Фредерик Брукс pdf
3. Том Демарко Тимоти Листер Человеческий фактор: успешные проекты и команды
Демарко-Т.-Человеческий-фактор.pdf
4. Фримен Эр., Фримен Эл., Бейтс Б., Сьерра К. «Паттерны проектирования»
HeadFirst Паттерны проектирования
5. Том ДеМарко “Deadline. Роман об управлении проектами”
Том ДеМарко “Deadline. Роман об управлении проектами”