небольшая статья от архитектора движка PowerShell, изложен его взгляд на индустрию, в статье разъясняется, почему шикарный стал таким, какой он есть.
Семантический разрыв Есть 2 мира: 1. Мир, каким мы его себе представляем.
2. Мир, как мы можем им управлять.
Разница между этими двумя мирами и есть то, что называется смысловой разрыв .
Наша отрасль (примечание переводчика: IT-индустрия) десятилетиями боролся с семантическим разрывом.
Отличным примером семантического разрыва является сообщение в блоге «TechProsaic: VMWare Perl Toolkit против Powershell V1 ToolKit», в котором показано, что 20 строк кода Perl делают то же самое, что делает всего лишь один командлет «Get-VM».
Кто-то перестанет читать дальше на словах «PowerShell мощный, но Perl — отстой»; в этом восклицании будет и истина, и ложь.
Правда в том, что PowerShell — это мощный инструмент, но Perl Нет дерьмо.
(снимаю шляпу перед суперзвездой Ларри Уоллом и его Perl, очень немногие люди и технологии оказали такое (положительное :-)) влияние на нашу отрасль, как они.
И этот мир хорошее место, потому что такие хорошие парни, как он, рождаются!).
Реальная разница между этими двумя примерами заключается в семантическом разрыве.
В примере с PowerShell очень небольшой разрыв между тем, что вы думаете, и тем, что вам следует сделать для решения проблемы.
В примере Perl есть очень большой пробел.
Ведь семантический разрыв «контролируется» людьми, которые разрабатывают инструменты.
VMWare может легко предоставить сценарий PowerShell, который будет содержать такое же количество строк примера Perl, или они могут отправить библиотеку для Perl, которая обеспечивает семантику командлета Get-VM в одной команде.
Так почему же поставщики инструментов закрыли или не закрыли семантический разрыв? Ааа - это тот самый вопрос! Возможно, я ошибаюсь в этом вопросе, но я думаю, что это всего лишь пример иерархии потребностей Абрахама Маслоу.
Технологии используются людьми для того, чтобы упростить то, что раньше было очень сложно сделать, и сделать так, чтобы каждый мог легко этим воспользоваться.
Если бы вы написали код, который сделал что-то очень полезное, вашей первой реакцией было бы не добавление в код раздела с правильными диагностическими сообщениями об ошибках, а пойти в бар и похвастаться перед друзьями.
Типичным примером этого является текстовый редактор «ed» операционной системы Unix, в котором для каждой ошибки имеется одно сообщение: «Э».
(Может показаться смешным, на тот момент это был передовой вариант локализации :) ).
Как только вы убедитесь, что все работает, вы можете беспокоиться о таких вещах, как хорошие сообщения об ошибках.
Позже вы можете беспокоиться о функциях более высокого порядка и удобстве использования.
Преимущество PowerShell заключается в том, что он стоит на плечах гигантов.
Некоторые из этих гигантов являются создателями этой концепции: Bash, C#, Perl, Tcl, VMS/DCL, AS400 CL и т. д. Но что действительно сделало ее волшебной, так это то, что PowerShell опирается на код: .
NET, XML, WMI, ADSI, ADO и т. д. благодаря им мы смогли подняться по иерархии потребностей Маслоу и сосредоточить усилия на закрытии семантического разрыва.
Очевидно, что наша цель — позволить нашим клиентам опираться на нашу работу и закрыть смысловой разрыв между тем, что мы им предоставляем в виде инструментов, и бизнес-задачами, с которыми они сталкиваются при решении повседневных задач.
Я считаю, что это метафизически невозможно для компакт-дисков, которые мы (и любой поставщик) отправляем для решения бизнес-задач.
У каждого бизнеса есть своя среда, философия, политика, история, личности и т. д. Каждому бизнесу необходимо взять то, что дали ему разработчики, и адаптировать это (через действия, операции или сценарии) для удовлетворения своих потребностей (чтобы закрыть собственный смысловой разрыв).
).
Мое видение успеха заключается в том, что PowerShell предоставит клиентам самый простой, быстрый, дешевый и надежный механизм, который позволит им использовать то, что им предоставляют разработчики, и адаптировать его для удовлетворения своих уникальных потребностей.
Эти потребности со временем меняются, поэтому PowerShell должен предоставить легкое, дешевое, безопасное, простое для понимания и обслуживания решение.
Но вернемся к инструментам, предоставляемым разработчиками для устранения семантического разрыва: PowerShell сам по себе предоставляет очень ограниченный инструментарий.
Однако оно играет огромную роль в этом процессе.
Мы занимаемся пропагандой и дизайном.
PowerShell имеет четкое понимание правил для адаптации к опыту клиента, благодаря чему пользователь может легко писать свои собственные абстракции высокого уровня.
Мы подчеркиваем это видение для поставщиков инструментов и предоставляем множество рекомендаций о том, как что-то делать, какие слова для именования использовать для глаголов, параметров, существительных и т. д. Конструкция PowerShell настоятельно требует от разработчиков:
- Используйте общую схему именования (набор команд, правила автоматического добавления префиксов к командным существительным)
- Использование унифицированных процессов разбора команд (привязка)
- Поддерживает общую семантику -WhatIf, -Confirm, -Verbose, -Debug.
- Использование общих утилит для сортировки, фильтрации, манипулирования, форматирования, импорта/экспорта и т. д.
- Поддержка моделей композиции ISA и HASA.
- Единые правила проверки ошибок и одинаковые параметры.
Обеспечить комплексную систему отчетов об ошибках
Другими словами, PowerShell и .
NET решают проблемы низкого уровня и мелочи иерархии Абрахама Маслоу, что освобождает время разработчиков инструментов, чтобы они могли сосредоточиться на проблемах более высокого уровня.
Это, безусловно, подтверждается опытом тех команд, которые пишут командлеты PowerShell. Получая обратную связь, мы постоянно слышим: 1. Ух ты!.
Писать командлеты очень легко.
2. Большую часть времени тратится на продумывание дизайна использования клиента.
На самом деле, в этой небольшой статье о семантическом разрыве многое упущено, если сложить все это вместе, то PowerShell вам понравится.
Например, мы используем систему адаптивных типов (потому что она позволяет вам думать о том, какие данные вам нужны, а не думать о том, где и какой тип вам нужно использовать.
Кроме того, мы поддерживаем как модели композиции ISA, так и HASA, и мы фанатично продвигают идею о том, что все должно «просто работать».
Можно много чего сказать, но думаю, для воскресного утра этого достаточно.
я собираюсь пойти выпить кофе Джеффри Сновер [MSFT] Архитектор партнера по управлению Windows Теги: #администрирование powershell #программирование
-
Hbo Запускает Онлайн-Сервис Hbo On Broadband
19 Oct, 24 -
За Кулисами Формулы 1
19 Oct, 24 -
Конец Истории С Ремонтом Коммуникатора
19 Oct, 24 -
Qt 4.5 И Qt Creator 1.0 Теперь С Нами!
19 Oct, 24
