Ну я бы из автоматизации выделил еще механизацию и информатизацию - научно-технические революции, каждая из которых вносит свой вклад текущее состояние. Сейчас у нас происходит НТР связанная с информационными технологиями. Сравнительно недавно (вторая половина ХХ века) произошла НТР связанная с автоматизацией и она все еще не завершена. На начало 20 века выпала еще одна НТР связанная с механизацией. Точнее механизация началась гораздо раньше, но именно на начало 20 века пришлось изобретение компактного, мощного и автономного двигателя внутреннего сгорания. Что превратило прогресс в революцию и сделало переход резким и болезненным - Великая депрессия, Первая и Вторая мировые войны - все это следствия появления "ненужных" людей в результате распространения тракторов и автомобилей. Зато сейчас никого не беспокоят мысли о безработных коневодах и извозчиках вытесненных автомобилями и тракторами. Что характерно, население увеличилось, производительность труда увеличилась, а работы меньше не стало. Говоря про появление новых профессий, хочу отметить, что для многих из них общей особенностью является возросшая цена ошибки. Там где раньше рабочий фигачил напильником по железной заготовке имея возможность проверять геометрию после каждого движения, появляется фрезеровщик со станком, способный запороть деталь легким движением руки. Ну или водитель телеги максимум мог убить кобылу о стену небольшого дома, а водитель грузового автомобиля - может и снести этот же дом. Справиться с ростом цены ошибки можно двумя способами: повышать квалификацию и многократно дублировать. Повышение квалификации поднимает стоимость работника, а многократное дублирование увеличивает количество занятых. В результате получаем мегадорогого специалиста которому можно дать удаленно порулить абстрактным тесламобилем. И массового дешевого специалиста который может порулить только виртуальным тесломобилем в рамках одной из задач датасета на котором потом будет обучена нейронка автопилота. Причем одну и ту же задачу на виртуальной модели будут многократно выполнять разные люди, что даст возможность сделать датасет более-менее качественным. Потом владельцы больших датасетов обнаружат, что датасеты теряют качество со временем и их надо обновлять. Мир меняется не только в результате деятельности человека. Так что так что массовые профессии будущего будут основаны на выполнении задач на виртуальных моделях, элитные профессии - взаимодействие с объектами реального мира.
ИМХО - на АСУТП с одной стороны давит IT, с другой - универсализация средств автоматизации. В результате АСУТП выродится в дисциплину или группу дисциплин типа "Автоматизация технологического процесса" для профильного инженера-технолога, в рамках которой будет изучаться небольшой набор универсальных блоков и способов их соединения. Там где раньше для получения сложной траектории точки в трехмерном пространстве требовалась забубенная кинематика, сейчас достаточно трех одинаковых линейных актуаторов управлемых МК. И для изменения этой траектории уже не требуется перепроектирования всей кинематической схемы - достаточно смены программы МК. И даже программировать МК уметь не обязательно - достаточно задать необходимую траекторию в CAD и прогнать через CAM для получения программы. В результате становится проще доучить специалиста понимающего что, как и зачем должно происходить инструментам автоматизации.
Прикольная игрушка, не больше. Основная проблема - износ рабочих поверхностей в результате трения. А это изменение геометрии в зоне контакта, появление зазоров и в результате - потеря точности.
Профиль зуба шестерни проектируется таким образом, чтобы рабочие поверхности не терлись друг об друга, а катились одна по другой.
Смысловая нагрузка слов сильно меняется когда человек прикладывает усилия для выражения мысли в письменном виде. Зачастую голос и невербальные сигналы - просто шум, не несущий полезной нагрузки. А еще не все люди умеют даже формулировать мысли и выкручиваются по жизни за счет собеседника. Т.е. аудио-визуальное общение превосходно подходит для имитации бурной деятельности, когда за счет шума раздувается микроскопическое количество полезной информации. Например сталкивался с случаем, когда из пятнадцатиминутного эмоционального спича за два часа общения извлекли аж два небольших абзаца текста, которые зачитываются секунд за тридцать.
Текст так же подходит для общения как и аудио/видео. Но требует больше усилий от автора - плохая формулировка, отсутствие структуры в тексте видно гораздо лучше, чем в видео/аудио.
Так что видео форумы - могут обрести популярность только как очередная реинкарнация тайм-киллера. Накопительного эффекта они не имеют - видео и аудио плохо индексируется для поиска, а перевод в текстовое представление - выставляет напоказ все недостатки.
Слабенько как-то. Общие слова вроде правильные, а вот приведенные примеры - ниочем. Только для рекламы. Узкоспециализированные решения которые нужно обслуживать вручную - тупиковый путь. Для реальной эксплуатации нужны массовые универсальные решения. Например линейка самоходных платформ числом K, к ним линейка совместимого навесного/подключаемого оборудования числом L, вместе дают M моделей. К ним еще добавить стационарные пункты автоматизированного обслуживания, автоматизированной крупноблочной сборки/разборки. Ну чтобы не гонять бригаду на недельную командировку для обслуживания и ремонта одного-двух роботов в дальних ебенях. Тогда будет похоже на правду.
А теперь включаем мозг и задумываемся, что же на самом деле видят абоненты с их зоопарком платформ-приложений-настоек, если косяки вылезли даже при развертывании в контролируемом окружении рабочего места оператора.
Гибрид землянки с юртой - это ж классический американский дом. Вот даже не знаю что думать...
Может дело в системе управления? Жесткая иерархическая система класса "я начальник - ты дурак" позволяет сделать сделать быстро и много, но делает результат непредсказуемым и нестабильным. Мягко манипулирующая условиями - достигает результата гораздо медленнее, но делает результат гораздо более предсказуемым и стабильными.
Голосовой ввод не взлетит для массового использования. Он последовательный как консоль, требовательный к окружению да еще и очень языкозависимый. Ткнуть пальцем - более универсально. Моторика и физиология у всех людей одинаковая. В плане прогресса устройств ввода можно ожидать скорее браслетов считывающих данные с сухожилий и мышц предплечий. Тогда устройство ввода всегда будет с пользователем и тач-скрины, клавитуры, мышки с джойстиками уйдут в прошлое.
Складные экраны - они дорогие и сложные. Главная проблема - они не имеют особого преимущества и не могут конкурировать с устройствами другого класса. Основной момент - для удвоения диагонали, площадь поверхности надо увеличить в четыре раза. Так что складной экран при развертывании увеличивает диагональ всего в 1.4 раза. Т.е. 7" раскладывается в 10". Кардинально поменять картину может только технология типа дополненной реальности высокого разрешения на базе очков/линз. Тогда станет иметь значение не линейный физический размер, а угловой виртуальный. Но это сделает ненужным значительную часть экранов вообще - их будут ставить только в качесте аварийного варианта вывода информации.
Процессор, память, модули связи, аккумуляторы - все это наиболее логично разместить как можно ближе к центу тяжести пользователя - например на поясе.
В сумме получается что мобильное устройство будущего это пояс, браслеты, очки с наушниками. А пользователь взаимодействующий с таким устройством со стороны выглядит как псих крутящий фиги, мудры, перебирающий пальцами в воздухе, разговаривающий с невидимками. Хотя последнее уже реальность, когда не понять псих или блютус ;)
Достаточно развитая технология неотличима от магии, так что ждем запасаемся попкорном и ждем появления обыкновенных волшебников крутящих фиги для открытия замков, распальцовками управляющих кондиционерами и дверями...
Ну если специалист по ИБ приходит с россказнями типа "АТАТА" - никто к нему серьезно относиться не будет. Любой бизнесмен скажет "Боюсь-боюсь", но денег не даст. Потому что надо показывать не произошедшие взломы, а вероятность наступления риска, умножать на сумму потенциального ущерба для бизнеса и сравнивать с ценой предотвращения.
Чтобы начинающие не хватались за инструменты - нужно разрабатывать методологию оценки готовности предприятия к внедрению СЕ, а не изобретать еще один универсальный инструмент для сферического предприятия в вакууме. Если поковыряться в вопросе - внезапно выходит, что СЕ строится не на пустом месте, а на вполне таки солидном фундаменте ITSM, ITIL и связанных стандартов. И при наличии фундамента стоимость внедрения СЕ действительно не так уж и велика. А когда фундамента нет - компания получит гораздо больший эффект если займется основами. Тогда и управление рисками будет формализованно и инструменты регистрации событий будут существовать и регламенты с инструкциями будут прописаны к началу внедрения СЕ.
Chaos monkey и т.п. инструменты это только вершина айсберга которую все видят. Под этой вершиной лежит толстый-толстый слой тестирования, в котором проверяется поведение при негативный событиях. Под тестированием - еще более толстый слой разработки, в котором и закладывается поведение. Еще ниже разработки - сбор требований, которые и определяют негативные события для которых должно быть определено поведение. События тоже не берутся от балды - есть такая штука как управление рисками. В рамках которого и производится оценка вероятности события и ущерб в результате наступления этого события. В результате весь этот банкет оплачивается из бюджета предотвращения финансовых потерь. Только когда все слои собираются вместе - появляется chaos engineering. И да, это все имеет смысл только для достаточно крупных компаний. Для мелкой компании многие риски просто слишком дорого предотвращать.
Так что chaos engineering начинается с управления рисками. Метрика берется не от балды, а от возможного ущерба. Гипотеза тоже не придумывается, а выбирается исходя из событий которые агрегируются метрикой и вероятности наступления события. Планируется не только как ломать, но и как регистрировать происходящее после поломки - какие скрипты и когда должны запуститься, кто, что и когда должен сделать по регламентам и инструкциям. Замерять нужно не саму метрику, а время восстановления после поломки. Мда. Единственное, к чему не могу придолбаться - это "Оценить результаты, сделать выводы".
Автору могу порекомендовать исследовать пучины Краваго Ынтерпрайза. Ну там где мелкие изменения в микроскопический проект вносят три дев-синьора с солидной зарплатой в течении месяца, а тестируют два месяца четыре кьюэй-синьора. Просто потому что каждый час простоя сервиса компания теряет $10+К и все эти синьоромесяцы стоят меньше полусуток оффлайна.
Ну из того, с чем я сталкивался — внутрипроектная документация еще и в другое время пишется. И в результате клиентская документация на ревью приходит в лучшем случае через месяц после окончания работы над фичей. А в худшем — и через полгода может прийти. И менеджер далеко не всегда согласен, что ревью на потребуется 4-6 часов, потому что чтения там минут на 15. Как будто я помню, что делал 3-6 месяцев назад. И моя голова не забита актуальной информацией по фиче над которой я работаю прямо сейчас. Ну и в результате качество такого ревью, скажу мягко, весьма низкое.
Использование внутрипроектной документации как начального источника — позволяет опереться на элементы, которые и в пользовательской документации и во внутрипроектрой одинаковы, типа вывода командной строки, скриншота, названия элемента интерфейса и т.д. И при включении блоков пользовательской документации во внутрипроектную — этот текст ревьювится и обновляется еще на этапе проектирования.
Преобразовать любую внутрипроектную документацию в текст и выкинуть лишнее — эта задача вполне автоматизируется даже без патчей. А с патчами появляется возможность автоматизировать добавление и изменение текста (когда с командой не удалось договориться про включение пользовательской документации во внутрипроектную). При значительных изменениях внутрипроектной документации — патч ломается, сразу показывая необходимость ручной правки.
Когда все блоки текста пользовательской документации готовы и отревьюваны — сборка финальной версии тоже прекрасно автоматизируется. В результате пользовательская документация может собираться в виде одного из шагов буквально для каждого билда.
Ну и могу предположить, что многие разработчики, как и я, пользуются шаблонами при написании текста, производя тонны квадратно-гнездового текста просто потому что не выделяются талантами на ниве писательства. А уж когда и язык в добавок иностранный…
И с удовольствием воспользуются своевременной помощью при создании внутрипроектной документации.
Отличное начало! А почему вы не конвертируете MD в RST и не пускаете все по одному пайплайну?
Ну и я бы посоветовал освоить работу с патчами и 3-way merge. После этого можно начать движение в сторону источников контента — тесткейсов, юзер сториз, спек, тикетов и где там еще у вас ведется внутрипроектная документация. Если технически возможно и удалось договориться с командой на разметку и редактирование нужных вам блоков текста в оригинальном источнике — в выигрыше и команда и вы. Не удалось договориться — все равно можно выдернуть данные из источника — и наложить патч дополняя текстом например наборы команд из тесткейса, ну и заодно убрать ненужные детали. Если источник сильно поменялся — патч просто не применится.
Ну и самое главное — документация перестанет быть самостоятельной сущностью со своим независимым жизненным циклом, который приходится принудительно синхронизировать с SDLC.
Python крут! Он дает кучу возможностей отстрелить себе ногу почесав ухо. Так что функциональные фичи Python нужно применять с осторожностью. Примерно на уровне регулярных выражений. Когда нет альтернативы и когда альтернатива требует кучи кода, да и пожалуй все. Работая с Python надо помнить про duck typing. Даже такой кривой итератор как в примере ниже, работает и с map, и с filter, и с reduce.
from functools import reduce
from random import randrange
class MyIterator():
def __iter__(self):
return self
def __next__(self):
result = randrange(10)
print("Generated:", result)
if result == 0:
raise StopIteration()
return result
if __name__ == '__main__':
my_iterator = MyIterator()
print("Map example call:", list(map(lambda x: x, my_iterator)))
print("Filter example call:", list(filter(lambda x: x % 2 == 0, my_iterator)))
print("Reduce example call:", reduce(lambda acc, x: acc + x, my_iterator, 0))
Результат будет вроде такого: ...
First call of mapped static: [1, 2, 3, 4, 5, 6, 7, 8, 9]
Second call of mapped static: []
Generated: 2
Generated: 6
Generated: 6
Generated: 9
Generated: 8
Generated: 2
Generated: 6
Generated: 5
Generated: 7
Generated: 5
Generated: 4
Generated: 4
Generated: 0
First call of mapped dynamic: [2, 6, 6, 9, 8, 2, 6, 5, 7, 5, 4, 4]
Generated: 6
Generated: 5
Generated: 1
Generated: 1
Generated: 6
Generated: 8
Generated: 0
Second call of mapped dynamic: [6, 5, 1, 1, 6, 8]
Не то чтобы ужас-ужас, но неприятно.
А уж что там на самом деле за объект в более-менее сложном проекте — это вопрос на миллион. Иногда смотришь на код — вроде обычный for item in some_list:, но присмотревшись к этому some_list понимаешь, что там внутри нифига не список. А нечто навороченное, читающее данные из очереди сообщений в дополнительных потоках, с вычиткой данных наперед и буферизацией в памяти. Ну или какой-нибудь словарь с конфигом. Присматриваешься — а там Содом с Гоморрой с получением данных из переменных окружения, локальных конфигурационных файлов и базы данных. Все это смешивается, но не взбалтывается и время от времени перечитывается. Но при этом по большей части снаружи выглядит как обычный дикт. А меньшая часть — иногда стреляет, даря незабываемые ощущения батхерта на вроде бы ровном месте.
Впрочем, проблем может доставить даже изменение типа с тапла на лист.
Так что функциональные возможности Python знать нужно, но применять — только четко понимая, что ты делаешь и к каким последствиям это приведет.
Бизнес может хотеть что угодно, в том числе и вещи противоречащие здравому смыслу, логике и известным нам законам физики.
Так что при возникновении ситуации типа «семь перпендикулярных красных линий, часть из которых синим цветом» настоящий профессионал рисует черную точку и методично выносит мозг недоговороспособным представителям бизнеса рассказом про многомерные измерения, неэвклидову геометрию с примерами из геометрии Лобачевского, проекции в точку и т.д. пока они таки не увидят эти свои линии в точке. PROFIT!
С договороспосбными — процесс выработки договора. Ну хочет бизнес «яблони цветущие на Марсе» — ок, 500 лет и хреннилиард долларов. В процессе пошаговых уступок — сводим все к плесени цветущей на МКС за три года и пару миллиардов. Миллиард заносим НАСА на программу биологических опытов с плесенью на МКС, фоточки цветущей плесени с подтверждающими документами от НАСА заносим заказчику. PROFIT!
Так что при решении задач реального мира — первая итерация это выловить противоречия хотелок заказчика и реальности. И сводить их к общему знаменателю, учитывая что изменение реальности — дороже изменения пожеланий заказчика.
Это линейные менеджеры. А принципал с которым сталкивался — это придумать идею, написать пруф-оф-консепт в виде башевского однострочника на пол экрана и получить под него бюджет на команду разрабов которые всего за годик-полтора сделают на основе пок полноценный сервис который будет крутиться 24/7 на кластере в пару десятков машин.
Factory must grow! Опытные игроки доводят игру до состояния фпс<10 или ООМ. А потом начинают новую ;)
А опытные ведущие (те которые Principal, а не Team/Tech Lead) как раз и ставят задачи для себя и подчиненных. И задают рамки в которых эти задачи надо решать.
Ну позыв «переписать ВСЕ» купируется запросом плана работ с детализацией задач до 1-3 дней на человека. Если ПМ — руководитель, а не водитель руками, и таки разбирается в продукте — он легко наловит пропущенных фич. Или получит нормальный план работ. А вот когда ПМ — водитель руками считающий главной своей функцией подгонять ленивых рабов разработчиков, то ему впарят туфту хоть в виде «переписать все», хоть в виде липового плана.
Вообще, лично я сталкивался с заявками «переписать все» только от людей которые не знают продукт. Как правило, познакомившись с продуктом, даже на очень фиговой кодовой базе, люди приходят с более конкретными предложениями — поменять А, Б, В, не трогать и переиспользовать Г, Д, Е, чтобы получить профит в виде Ж, З, И.
Во-первых, люди зачастую слушают, но не слышат что им говорят. А у синьера или лида и так есть работа кроме стояния над головой джуна. И документ в котором зафиксирован недостаток и шаги необходимые для его преодоления — воспринимается гораздо серьезнее устной рекомендации проделать некоторые действия.
Во-вторых, заставлять программистов делать что-либо нет возможности — уйдут в другую команду/компанию. Зато предолжение поучаствовать в проведение демки чтобы прокачать активность «проведение презентаций» в аппрайзале — вполне себе аргумент для джуна, чтобы преодолеть первоначальную неуверенность.
В-третьих, это и для руководителя метод контроля — когда находится такой себе синьер-помидор формирующий из зеленого джуна узкого исполнителя самых нелюбимых активностей. И забивающего болт на дальнейшее развитие этого джуна. А на аппрайзале джуна — это прекрасно видно.
Наверняка есть и другие варианты.
Как я понимаю процесс — HR не должен выносить оценку. Только модерировать общение, помогая сторонам договориться и фиксировать достигнутые договоренности. Ну а при реальном конфликте решать его будут именно HR — двигая людей между командами или рекомендуя увольнение.
Ну я бы из автоматизации выделил еще механизацию и информатизацию - научно-технические революции, каждая из которых вносит свой вклад текущее состояние.
Сейчас у нас происходит НТР связанная с информационными технологиями. Сравнительно недавно (вторая половина ХХ века) произошла НТР связанная с автоматизацией и она все еще не завершена. На начало 20 века выпала еще одна НТР связанная с механизацией. Точнее механизация началась гораздо раньше, но именно на начало 20 века пришлось изобретение компактного, мощного и автономного двигателя внутреннего сгорания. Что превратило прогресс в революцию и сделало переход резким и болезненным - Великая депрессия, Первая и Вторая мировые войны - все это следствия появления "ненужных" людей в результате распространения тракторов и автомобилей. Зато сейчас никого не беспокоят мысли о безработных коневодах и извозчиках вытесненных автомобилями и тракторами. Что характерно, население увеличилось, производительность труда увеличилась, а работы меньше не стало.
Говоря про появление новых профессий, хочу отметить, что для многих из них общей особенностью является возросшая цена ошибки. Там где раньше рабочий фигачил напильником по железной заготовке имея возможность проверять геометрию после каждого движения, появляется фрезеровщик со станком, способный запороть деталь легким движением руки. Ну или водитель телеги максимум мог убить кобылу о стену небольшого дома, а водитель грузового автомобиля - может и снести этот же дом.
Справиться с ростом цены ошибки можно двумя способами: повышать квалификацию и многократно дублировать. Повышение квалификации поднимает стоимость работника, а многократное дублирование увеличивает количество занятых. В результате получаем мегадорогого специалиста которому можно дать удаленно порулить абстрактным тесламобилем. И массового дешевого специалиста который может порулить только виртуальным тесломобилем в рамках одной из задач датасета на котором потом будет обучена нейронка автопилота. Причем одну и ту же задачу на виртуальной модели будут многократно выполнять разные люди, что даст возможность сделать датасет более-менее качественным.
Потом владельцы больших датасетов обнаружат, что датасеты теряют качество со временем и их надо обновлять. Мир меняется не только в результате деятельности человека. Так что так что массовые профессии будущего будут основаны на выполнении задач на виртуальных моделях, элитные профессии - взаимодействие с объектами реального мира.
ИМХО - на АСУТП с одной стороны давит IT, с другой - универсализация средств автоматизации. В результате АСУТП выродится в дисциплину или группу дисциплин типа "Автоматизация технологического процесса" для профильного инженера-технолога, в рамках которой будет изучаться небольшой набор универсальных блоков и способов их соединения.
Там где раньше для получения сложной траектории точки в трехмерном пространстве требовалась забубенная кинематика, сейчас достаточно трех одинаковых линейных актуаторов управлемых МК. И для изменения этой траектории уже не требуется перепроектирования всей кинематической схемы - достаточно смены программы МК. И даже программировать МК уметь не обязательно - достаточно задать необходимую траекторию в CAD и прогнать через CAM для получения программы. В результате становится проще доучить специалиста понимающего что, как и зачем должно происходить инструментам автоматизации.
Прикольная игрушка, не больше. Основная проблема - износ рабочих поверхностей в результате трения. А это изменение геометрии в зоне контакта, появление зазоров и в результате - потеря точности.
Профиль зуба шестерни проектируется таким образом, чтобы рабочие поверхности не терлись друг об друга, а катились одна по другой.
Смысловая нагрузка слов сильно меняется когда человек прикладывает усилия для выражения мысли в письменном виде. Зачастую голос и невербальные сигналы - просто шум, не несущий полезной нагрузки. А еще не все люди умеют даже формулировать мысли и выкручиваются по жизни за счет собеседника. Т.е. аудио-визуальное общение превосходно подходит для имитации бурной деятельности, когда за счет шума раздувается микроскопическое количество полезной информации. Например сталкивался с случаем, когда из пятнадцатиминутного эмоционального спича за два часа общения извлекли аж два небольших абзаца текста, которые зачитываются секунд за тридцать.
Текст так же подходит для общения как и аудио/видео. Но требует больше усилий от автора - плохая формулировка, отсутствие структуры в тексте видно гораздо лучше, чем в видео/аудио.
Так что видео форумы - могут обрести популярность только как очередная реинкарнация тайм-киллера. Накопительного эффекта они не имеют - видео и аудио плохо индексируется для поиска, а перевод в текстовое представление - выставляет напоказ все недостатки.
Палиндромы же:
Слабенько как-то. Общие слова вроде правильные, а вот приведенные примеры - ниочем. Только для рекламы. Узкоспециализированные решения которые нужно обслуживать вручную - тупиковый путь. Для реальной эксплуатации нужны массовые универсальные решения. Например линейка самоходных платформ числом K, к ним линейка совместимого навесного/подключаемого оборудования числом L, вместе дают M моделей. К ним еще добавить стационарные пункты автоматизированного обслуживания, автоматизированной крупноблочной сборки/разборки. Ну чтобы не гонять бригаду на недельную командировку для обслуживания и ремонта одного-двух роботов в дальних ебенях. Тогда будет похоже на правду.
А теперь включаем мозг и задумываемся, что же на самом деле видят абоненты с их зоопарком платформ-приложений-настоек, если косяки вылезли даже при развертывании в контролируемом окружении рабочего места оператора.
Гибрид землянки с юртой - это ж классический американский дом. Вот даже не знаю что думать...
Может дело в системе управления? Жесткая иерархическая система класса "я начальник - ты дурак" позволяет сделать сделать быстро и много, но делает результат непредсказуемым и нестабильным. Мягко манипулирующая условиями - достигает результата гораздо медленнее, но делает результат гораздо более предсказуемым и стабильными.
Голосовой ввод не взлетит для массового использования. Он последовательный как консоль, требовательный к окружению да еще и очень языкозависимый. Ткнуть пальцем - более универсально. Моторика и физиология у всех людей одинаковая. В плане прогресса устройств ввода можно ожидать скорее браслетов считывающих данные с сухожилий и мышц предплечий. Тогда устройство ввода всегда будет с пользователем и тач-скрины, клавитуры, мышки с джойстиками уйдут в прошлое.
Складные экраны - они дорогие и сложные. Главная проблема - они не имеют особого преимущества и не могут конкурировать с устройствами другого класса. Основной момент - для удвоения диагонали, площадь поверхности надо увеличить в четыре раза. Так что складной экран при развертывании увеличивает диагональ всего в 1.4 раза. Т.е. 7" раскладывается в 10". Кардинально поменять картину может только технология типа дополненной реальности высокого разрешения на базе очков/линз. Тогда станет иметь значение не линейный физический размер, а угловой виртуальный. Но это сделает ненужным значительную часть экранов вообще - их будут ставить только в качесте аварийного варианта вывода информации.
Процессор, память, модули связи, аккумуляторы - все это наиболее логично разместить как можно ближе к центу тяжести пользователя - например на поясе.
В сумме получается что мобильное устройство будущего это пояс, браслеты, очки с наушниками. А пользователь взаимодействующий с таким устройством со стороны выглядит как псих крутящий фиги, мудры, перебирающий пальцами в воздухе, разговаривающий с невидимками. Хотя последнее уже реальность, когда не понять псих или блютус ;)
Достаточно развитая технология неотличима от магии, так что ждем запасаемся попкорном и ждем появления обыкновенных волшебников крутящих фиги для открытия замков, распальцовками управляющих кондиционерами и дверями...
Ну если специалист по ИБ приходит с россказнями типа "АТАТА" - никто к нему серьезно относиться не будет. Любой бизнесмен скажет "Боюсь-боюсь", но денег не даст. Потому что надо показывать не произошедшие взломы, а вероятность наступления риска, умножать на сумму потенциального ущерба для бизнеса и сравнивать с ценой предотвращения.
Чтобы начинающие не хватались за инструменты - нужно разрабатывать методологию оценки готовности предприятия к внедрению СЕ, а не изобретать еще один универсальный инструмент для сферического предприятия в вакууме. Если поковыряться в вопросе - внезапно выходит, что СЕ строится не на пустом месте, а на вполне таки солидном фундаменте ITSM, ITIL и связанных стандартов. И при наличии фундамента стоимость внедрения СЕ действительно не так уж и велика. А когда фундамента нет - компания получит гораздо больший эффект если займется основами. Тогда и управление рисками будет формализованно и инструменты регистрации событий будут существовать и регламенты с инструкциями будут прописаны к началу внедрения СЕ.
Уххх.
offtop
Chaos произносится скорее как кэйос, а не хаус.
Chaos monkey и т.п. инструменты это только вершина айсберга которую все видят. Под этой вершиной лежит толстый-толстый слой тестирования, в котором проверяется поведение при негативный событиях. Под тестированием - еще более толстый слой разработки, в котором и закладывается поведение. Еще ниже разработки - сбор требований, которые и определяют негативные события для которых должно быть определено поведение. События тоже не берутся от балды - есть такая штука как управление рисками. В рамках которого и производится оценка вероятности события и ущерб в результате наступления этого события. В результате весь этот банкет оплачивается из бюджета предотвращения финансовых потерь. Только когда все слои собираются вместе - появляется chaos engineering. И да, это все имеет смысл только для достаточно крупных компаний. Для мелкой компании многие риски просто слишком дорого предотвращать.
Так что chaos engineering начинается с управления рисками. Метрика берется не от балды, а от возможного ущерба. Гипотеза тоже не придумывается, а выбирается исходя из событий которые агрегируются метрикой и вероятности наступления события. Планируется не только как ломать, но и как регистрировать происходящее после поломки - какие скрипты и когда должны запуститься, кто, что и когда должен сделать по регламентам и инструкциям. Замерять нужно не саму метрику, а время восстановления после поломки. Мда. Единственное, к чему не могу придолбаться - это "Оценить результаты, сделать выводы".
Автору могу порекомендовать исследовать пучины Краваго Ынтерпрайза. Ну там где мелкие изменения в микроскопический проект вносят три дев-синьора с солидной зарплатой в течении месяца, а тестируют два месяца четыре кьюэй-синьора. Просто потому что каждый час простоя сервиса компания теряет $10+К и все эти синьоромесяцы стоят меньше полусуток оффлайна.
Использование внутрипроектной документации как начального источника — позволяет опереться на элементы, которые и в пользовательской документации и во внутрипроектрой одинаковы, типа вывода командной строки, скриншота, названия элемента интерфейса и т.д. И при включении блоков пользовательской документации во внутрипроектную — этот текст ревьювится и обновляется еще на этапе проектирования.
Преобразовать любую внутрипроектную документацию в текст и выкинуть лишнее — эта задача вполне автоматизируется даже без патчей. А с патчами появляется возможность автоматизировать добавление и изменение текста (когда с командой не удалось договориться про включение пользовательской документации во внутрипроектную). При значительных изменениях внутрипроектной документации — патч ломается, сразу показывая необходимость ручной правки.
Когда все блоки текста пользовательской документации готовы и отревьюваны — сборка финальной версии тоже прекрасно автоматизируется. В результате пользовательская документация может собираться в виде одного из шагов буквально для каждого билда.
Ну и могу предположить, что многие разработчики, как и я, пользуются шаблонами при написании текста, производя тонны квадратно-гнездового текста просто потому что не выделяются талантами на ниве писательства. А уж когда и язык в добавок иностранный…
И с удовольствием воспользуются своевременной помощью при создании внутрипроектной документации.
Ну и я бы посоветовал освоить работу с патчами и 3-way merge. После этого можно начать движение в сторону источников контента — тесткейсов, юзер сториз, спек, тикетов и где там еще у вас ведется внутрипроектная документация. Если технически возможно и удалось договориться с командой на разметку и редактирование нужных вам блоков текста в оригинальном источнике — в выигрыше и команда и вы. Не удалось договориться — все равно можно выдернуть данные из источника — и наложить патч дополняя текстом например наборы команд из тесткейса, ну и заодно убрать ненужные детали. Если источник сильно поменялся — патч просто не применится.
Ну и самое главное — документация перестанет быть самостоятельной сущностью со своим независимым жизненным циклом, который приходится принудительно синхронизировать с SDLC.
Правда, добавляет перчинки:
Результат будет вроде такого:
...First call of mapped static: [1, 2, 3, 4, 5, 6, 7, 8, 9]
Second call of mapped static: []
Generated: 2
Generated: 6
Generated: 6
Generated: 9
Generated: 8
Generated: 2
Generated: 6
Generated: 5
Generated: 7
Generated: 5
Generated: 4
Generated: 4
Generated: 0
First call of mapped dynamic: [2, 6, 6, 9, 8, 2, 6, 5, 7, 5, 4, 4]
Generated: 6
Generated: 5
Generated: 1
Generated: 1
Generated: 6
Generated: 8
Generated: 0
Second call of mapped dynamic: [6, 5, 1, 1, 6, 8]
Не то чтобы ужас-ужас, но неприятно.
А уж что там на самом деле за объект в более-менее сложном проекте — это вопрос на миллион. Иногда смотришь на код — вроде обычный for item in some_list:, но присмотревшись к этому some_list понимаешь, что там внутри нифига не список. А нечто навороченное, читающее данные из очереди сообщений в дополнительных потоках, с вычиткой данных наперед и буферизацией в памяти. Ну или какой-нибудь словарь с конфигом. Присматриваешься — а там Содом с Гоморрой с получением данных из переменных окружения, локальных конфигурационных файлов и базы данных. Все это смешивается, но не взбалтывается и время от времени перечитывается. Но при этом по большей части снаружи выглядит как обычный дикт. А меньшая часть — иногда стреляет, даря незабываемые ощущения батхерта на вроде бы ровном месте.
Впрочем, проблем может доставить даже изменение типа с тапла на лист.
Так что функциональные возможности Python знать нужно, но применять — только четко понимая, что ты делаешь и к каким последствиям это приведет.
Так что при возникновении ситуации типа «семь перпендикулярных красных линий, часть из которых синим цветом» настоящий профессионал рисует черную точку и методично выносит мозг недоговороспособным представителям бизнеса рассказом про многомерные измерения, неэвклидову геометрию с примерами из геометрии Лобачевского, проекции в точку и т.д. пока они таки не увидят эти свои линии в точке. PROFIT!
С договороспосбными — процесс выработки договора. Ну хочет бизнес «яблони цветущие на Марсе» — ок, 500 лет и хреннилиард долларов. В процессе пошаговых уступок — сводим все к плесени цветущей на МКС за три года и пару миллиардов. Миллиард заносим НАСА на программу биологических опытов с плесенью на МКС, фоточки цветущей плесени с подтверждающими документами от НАСА заносим заказчику. PROFIT!
Так что при решении задач реального мира — первая итерация это выловить противоречия хотелок заказчика и реальности. И сводить их к общему знаменателю, учитывая что изменение реальности — дороже изменения пожеланий заказчика.
А опытные ведущие (те которые Principal, а не Team/Tech Lead) как раз и ставят задачи для себя и подчиненных. И задают рамки в которых эти задачи надо решать.
рабовразработчиков, то ему впарят туфту хоть в виде «переписать все», хоть в виде липового плана.Вообще, лично я сталкивался с заявками «переписать все» только от людей которые не знают продукт. Как правило, познакомившись с продуктом, даже на очень фиговой кодовой базе, люди приходят с более конкретными предложениями — поменять А, Б, В, не трогать и переиспользовать Г, Д, Е, чтобы получить профит в виде Ж, З, И.
Во-вторых, заставлять программистов делать что-либо нет возможности — уйдут в другую команду/компанию. Зато предолжение поучаствовать в проведение демки чтобы прокачать активность «проведение презентаций» в аппрайзале — вполне себе аргумент для джуна, чтобы преодолеть первоначальную неуверенность.
В-третьих, это и для руководителя метод контроля — когда находится такой себе синьер-помидор формирующий из зеленого джуна узкого исполнителя самых нелюбимых активностей. И забивающего болт на дальнейшее развитие этого джуна. А на аппрайзале джуна — это прекрасно видно.
Наверняка есть и другие варианты.
Как я понимаю процесс — HR не должен выносить оценку. Только модерировать общение, помогая сторонам договориться и фиксировать достигнутые договоренности. Ну а при реальном конфликте решать его будут именно HR — двигая людей между командами или рекомендуя увольнение.