Нотатки про програмування, музику, подорожі та плівку
Про мене • Список нотаток • Плівка
Посетил мероприятие, на котором рассказывали о том, что можно сделать с уже проявленной пленкой. Для эксперимента использовали мой негатив.
Идея в следующем:
В итоге получаются очень интересные эффекты:
Совсем недавно о одном open-source проекте, в котором я участвую, потребовалось автоматизировать создание релизов на Github. В моем распоряжении есть TeamCity. Решил написать небольшой план, который состоит из следующих шагов:
Для решения 5-6 пунктов был написан простой powershell скрипт, который можно посмотреть по этой ссылке.
P.S. В дальнейшем, в репозиторий буду добавлять друге полезные скрипты.
Ссылка на репозиторий: https://github.com/teamkiller7112/PowerShellScriptsArchive
Инкапсуляция объединяет данные и код, манипулирующий зтими данными, а также защищает и то, и другое от внешнего вмешательства или неправильного использования. Вместе они создают объект, внутри которого могут быть приватные данные, которыми могут манипулировать только методы объекта. Исходя из этого, у нас появляется еще одно полезное свойство — сокрытие реализации программных частей.
С помощью наследования один объект может приобретать свойства другого. Это позволяет нам строить иерархию классов.
Возможность дополнять объект функционалом. Возможность выступать объекту в разных формах. Классический полиморфизм — замещение, переопределение методов. Ad hoc полиформизм — перегрузка методов, поведение в зависимости от данных. Подмена объектов во время выполнения программы с одинаковыми методами через интерфейс.
Абстракция — в ООП это придание объекту характеристик, которые четко выделяет его на фоне остальных, определяя его концептуальные границы. Абстрагирование — В ООП это способ выделить набор значимых характеристик объекта, исключая из рассмотрения не значимые. Соответственно абстракция это набор таких характеристик.
Посылка сообщения это вызов метода. Так же события и их обработчики.
Все что перечислено выше работает на повторное использование кода.
Объект это сущность, которая хранит в себе состояние и поведение. Должно быть соответствие между состоянием объекта и его поведением.
Объект должен делать только то, что на него возложено и ему соответствует.
Все объекты привязаны к прототипам из реального мира. ООП и повседневная жизнь не могут существовать раздельно.
Данная статья является переводом. Оригинальная статья.
Наиболее распространенная проблема заключается в том, что TeamCity игнорирует ошибки Powershell, по крайней мере, в конфигурации по умолчанию. Если шаг со сценарием PowerShell завершится неудачно, TeamCity по-прежнему считает билд успешным. Это может привести к серьезным ошибкам, которые могут быть незаметны длительное время. Это происходит потому что значение настройки Format stderr output as установлено в warning. Для того чтобы TeamCity видел ошибки, необходимо переключить настройку в error.
Но это еще не все. Может возникнуть ситуация что шаг PowerShell упал но весь пайплайн признан успешным. Для этого нужно перейти в раздел Failure Conditions и установить флаг error message is logged by build runner.
Теперь все ошибки буду корректно обрабатываться и влиять на статус билда.
Также надо понимать модель ошибок в PowerShell. Они могут поделятся на 2 группы:
Если возникло не завершающее исключение, то выполнение скрипта продолжится. Этот эффект может быть крайне нежелательным для сценариев, выполняющих взаимосвязанные операции, зависящие друг от друга. Конечно, мы можем изменить это поведение и превратить все «не завершающиеся» ошибки в «завершающиеся», установив переменную $ErrorActionPreference в начале наших скриптов:
#Error Action Preference:
#
# SilentlyContinue – error messages are suppressed and execution continues.
# Stop – forces execution to stop, behaving like a terminating error.
# Continue - the default option. Errors will display and execution will continue.
# Inquire – prompt the user for input to see if we should proceed.
# Ignore – (new in v3) – the error is ignored and not logged to the error stream. Has very restricted usage scenarios.
$ErrorActionPreference = "Stop"Для начала необходимо превратить все наши функции в настоящие командлеты. Для этого нужно определять входящие параметры с помощью блока param() и пометить его атрибутом [CmdletBinding()]:
function Verb-Noun {
[CmdletBinding()]
param (
#parameters go here
)
}Этот атрибут защищает вызов метода с не определенными параметрами. Каждый раз как кто-то использует не определенный/удаленный параметр или делает ошибку в его названии, PowerShell выбросит ошибку. Если метод не помечен атрибутов, имена параметров не проверяются, что затрудняет обнаружение проблемы.
Также можно обнаружить потенциальные ошибки, вызванные нарушением лучших практик и правил кодирования, включив строгий режим. Чтобы сделать это, добавьте следующий код в начале вашего скрипта:
Set-StrictMode -Version LatestДетальнее можно почитать тут.
Вообще советую использовать VS Core и плагином PowerShell. Он превращает вашу в IDE в аналог PowerShell ISE. Также этот плагин поставляется с PSScriptAnalyzer, что позволяет обнаруживать разные ошибки.
Teamcity дает возможность запускать скрипты не только из файла, но и из встроенного редактора. Но лучшей практикой считается использование файлов. Это позволит держать скрипты в системе контроля версий, вместе с вашим проектом.
Ваши скрипты как и код вашего проекта должен лежать в системе контроля версий, покрыт тестами и пройти ревью. Здесь вы можете найти лучшие практики и стили кодирования для PowerShell. Для тестирования кода можете использовать — Pester.
Связка PowerShell и Teamcity позволяет создать действительно мощный CI/CD. Но без понимания базовых принципов и механизмов вы не достигните максимального профита. Настройки по умолчанию часто могут приводить к непредвиденным ошибкам.
Дизайн
Интересности
Программирование
Ох сколько проблем вызывает документация. И зачастую эти проблемы связаны с ее отсутствием. Почти всегда разработчики считаю что написание документации это: лишнее, бюрократия, скучно. Также часто разработчики приводят в пример цитату из скрам гайда: работающий продукт важнее исчерпывающей
документации.
Я считаю что документация в том или ином виде должна присутствовать. Зачастую ее ценность понимается не сразу, а по прошествию времени. Например так случилось и в нашей команде, когда старые разработчики ушли и новеньким было очень сложно делать экскурс по системе, а она очень большая!
Но я против детально и огромной документации. Для себя и своих личных проектов я придерживаюсь следующего шаблона. Он достаточно компактный и простой в написании. Да это не ГОСТ, не ISO и не IEEE. Но она понятная и ее написание не занимает много времени.
Какие проблемы я пробую решить своим шаблоном:
Назначение: для чего нужен этот модуль, какую задачу решает?
Основная задача: ссылка на задачу в трекере в рамках которой разрабатывалась данный модуль.
Диаграмма: графическое отображение архитектуры. Позволит понять что от кого зависит и как взаимодействует с другими частями системы.
Зоны ответственности: кратко описать элементы модуля и за что они отвечают. Смысл приёма в том, чтобы явно выделить назначение класса. Идеальный результат — получить класс, который можно описать одной фразой или даже одним словом.
Пример использования: небольшой пример того как использовать данный функционал.
Обработка ошибок: как обрабатываются ошибки.
Логирование:
Тесты: каким типом тестов покрыта данная функциональность.
FAQ: вопросы и ответы по данной функциональности. Например: как объединить 2 объекта в сущности?
Инциденты и баги: ссылки на баги, которые были найдены в данной функциональности и исправленные.
Пленка: Kodak ColorPlus 200
Фотоаппарат: Nikon N65
Для чего вообще нужно логирование в приложении:
Какие есть требования к логерам?
Замечание! Никогда не отправляйте пустое исключение в лог. Так как обычно не понятно к чему принадлежит этот стэк-трейс, как программа отреагировала на ошибку. Чтобы избежать этого, в дополнение к трейсам прикладывайте и сообщение, которое обьясняет что именно произошло.