Зачем только английское произношение брать. По-русски произносится оно "цеттелькастен". И под этим именем занесено в википедии. Zettel - бумажный листочек, заметка. Kasten - ящик. Слово-то немецкое, популяризованое за счет известного немецкого ученого Никласа Лумана, основоположника системной теории в области социологии.
Я недавно стал пользоваться программой LogSeq. Она совмещает в себе принципы аутлайнера и обратных ссылок. Правда она находится еще в разработке. Она опенсорсная, privacy-first (т.е. пользовательские данные не собираются никаким образом и все хранится локально, за исключением случая использования сервисов синхронизации)
Приятным моментом было также то, что она инсталлируется без требования прав администратора. Формат заметок, что интересно, - .md (или по желанию .org - формат emacs orgmode) и база в .md полностью совместима с Obsidian. Во всяком случае так утверждают пользователи. Сам не проверял.
Она также поддерживает плагины и темы. Из встроенных возможностей есть конечно граф, есть доска, на которой можно визуально располагать заметки, есть возможность создавать карточки для зубрежки (flashcards). Можно добавлять метаданные к страницам в виде гибко определяемых свойств. Имея страницы с метаданными, можно их представлять в виде таблицы, например список всех книг. Можно делать шаблоны для страниц, если хочется чтобы структура определенных страниц всегда была одинаковой. Например, кто-то делает шаблоны для книг, кто-то для деловых заметок и т.п.
Я использую LogSeq для аннотаций к видео. Там есть макросы для создания ссылок на таймкоды. Надо сказать, активная работа с материалом позволяет больше запоминать. Я вот вчера аннотировал три видео, и сегодня смог вспомнить в контексте какого-то разговора несколько выдержек оттуда. Так что метод обработки материала вместо простого его просмотра дает результат.
То что вы описали, это по смыслу старый добрый ОТP = one time password. Такие бумажки с кодами, они называются iTAN до 2019 еще можно было повстречать в банковских системах. На смену им пришел ChipTAN, где нужно вставлять банковскую карту в устройство для генерации TAN-ов. А потом и PhotoTAN и QR-TAN. Особенность в банковском секторе, это то что там необходим не только вход в систему, но и заверение каждой транзакции. И для этого используется дополнительная система авторизации. Отличная от той что используется для входа в учетную запись.
Вне банковского сектора уже все перешли на TOTP (time based one time password) и вариации. Такие системы вам знакомы. Это например Google Authenticator, Microsoft Authenticator и иже с ними. Причем стандарт открытый. И не надо никаких SMS. Смена телефона тоже перестала быть большой проблемой, потому что большинство таких приложений научились создавать бэкапы настроек. Перезашел в учетку с нового телефона, восстановил приложения-аутнтификаторы из бэкапа и они работают как раньше.
Если конечно нет смартфона, то тут уже да, посложнее будет.
Я не вижу никаких аргументов против введения таких аттрибутов в код фронтенда. Это часть "testability". И висеть в проде эти аттибуты тоже не обязательно должны. Можно заставить компилятор или препроцессор убрать эти аттрибуты при сборке.
Да, придется вложиться в это. Но это и есть серьезное отношение к автоматизации тестирования. Бывает, конечно, что тестируемость случайно возможна, посредством каких нибудь манипуляций, или из-за свойств системы, но полагаться на это не стоит. Тестируемость это инвестиция, инвестиция в будущее сложной системы. И она стоит денег.
А автоматизация тестирования, это разработка программного обеспечения. И не нужно делать вид что "ну че там пару скриптиков написать чтобы кнопочки потыкать". Чем дольше притворяться, что автоматизация тестирования это не "программирование систем", тем дольше она будет у вас непрофессиональной и нездоровой. Часто такое мировоззрение в компаниях в которых DevOps - это "чувак который настраивает Jenkins".
Удивительно, но в Киберпанке диалоги удалось сделать максимально осмысленными и работающими на нарратив. Они помогают раскрыть внутренний мир персонажа и его взаимоотношения со внешним миром. Одно то, что в некоторых диалогах появляются опциональные (голубые) реплики а в некоторых нет, заставляет игрока воспринимать их как некий бонус. Тебе действительно хочется "выковырять" из каждого диалог максимум информации о мире или о собеседнике, его мотивах, возможных связях с другими персонажами, чтобы уже как игроку принять морально верное решение.
И текстовка диалогов выверена очень тщательно. Уж не знаю какими правилами они руководствовались, но в них на удивление нет ничего лишнего, как нет и пустоты. Каждая реплика показывает характер главного героя, либо характер его отношений с собеседником, либо раскрывает психологию собеседника. Есть впечатление, что эти диалоги ставил режиссер. Как будто садились люди и проговаривали эти диалоги вживую. Стандартных реплик практически нет. И разговор ощущается очень естественным. Никакого пафоса, никаких лишних слов, никаких заумностей.
Если сравнивать с классическими диалогами, то диалоги в киберпанке очень контекстные. Они дают тебе озможность задать те вопросы, которые у тебя как у главного героя возникают в этот самый момент. А не заставляют просто читать то, что придумал автор текстов. Не пытаются подхватывать другие контексты. Не пытаются рассказать тебе больше чем тебе нужно знать в этой конретной ситуации.
И кроме этого твои реплики имеют значение. Нет такого ощущения, что ты просто обмениваешься пустыми фразами. И моменты для диалога выбраны очень правильно. Нет бессмысленной болтовни по дороге, нет неуместных шутеек для развлечения. В каждом моменте соблюдается целостность персонажа и мира. В целом очень "книжное" повествование.
В Киберпанке диалоги как линза, через которую ты рассматриваешь мир. Это непередаваемое ощущение.
Я когда-то интересовался этим вопросом. Потому что у нас доступ к тестируемому приложению был через пароль и токен. Накопал, что есть библиотеки для OTP (ну там PyOTP, например). По смыслу она будет делать то же самое, что делает ваш Google Authenticator в телефоне. Мы в коде прописываем инициализационный шифр, который нам дает сервис (обычно это среди опций, "добавить вручную" вместо qr кода). И наш тестировочный код, будет тем же алгоритмом создавать нам коды доступа как это делает ваш Google Authenticator или кто-то еще. Реализацией не занимался, но ребята с другого проекта рассказывали, что этот подход рабочий.
Я обычно думаю, что вообще, тема аджайла уже жевана-пережевана, но оказывается, всегда найдутся примеры, где образ мышления, принципы, до сих пор путают с чем-то еще. Видимо спрос на ликбез никогда не угаснет.
Вообще интересно, по моим наблюдениям, люди, даже кто может наизусть перечислить все 12 принципов аджайл, могут не обратить внимание, если эти принципы нарушаются.
Я считаю, в этом и есть основная часть проблемы. Одно дело знать правила, а другое жить по правилам. И именно поэтому, как мне кажется, внедрения не работают. Отсюда и появляются регулярно в инфосфере столько "историй болезни" и "криков души", (а иногда даже "криков: души!":) Правила изучили (а возможно всего лишь ознакомились), а следовать им забыли. Или не научились распознавать ситуации принятия решений в которых эти принципы должны быть применены.
Кстати да, если так подумать люди вообще настолько интуитивно принимают решения, что как правило сам момент когда у них появляется выбор, вообще никак не выделяют. А это полезное упражнение.
Интереснее было бы сделать модель которая бы распознавала оскорбительные и другие нарушающие правила никнеймы. Для этого есть реальная необходимость в онлайн мультиплеерных играх. Всякие 88, 1312 и т.п. хрень. А также всякие стилизации типа Seba55tian где в слово вставлено двойное S. И прочие WOTAN-ы
Обычно на возражения про "фактор счастливой случайности" и "социально-экономическое положение" те, кто обучают успеху начинают гнать что-то вроде: "это аргумент всех пессимистов/неудачников, у вас не правильная установка.." и все такое.
Я обычно обхожу эту конфронтацию стороной, потому что мне вобщем трудно сказать кто прав. Это человек сложил крылья потому что уверил себя во влиянии обстоятельств (нашел удобную универсальную отмазку) или обстоятельства это реально существующие сдерживающие факторы, которым человек не может сопротивляться. Или есть что-то компромиссное, вроде "необходимо учитывать личностные, психофизические, экономические и социальные обстоятельства и факторы при разработке стратегии успеха"?
Да, кстати, я люблю приводить цитату Томаса Эдисона "I have not failed. I've just found 10,000 ways that won't work." (Я не терпел поражений. Я просто нашёл 10 000 способов, которые не работают)
Я вот работают в айти, и в решении многих задач мне помогает этот гайд:
Бесконечный кладезь знаний. Руководство к методу "научного тыка".
Я изначально просто стараюсь не мучаться по поводу того, смогу я это сделать или нет. Я за жизнь достаточно раз убедился в том, что как минимум сделаю работу лучше среднего. Быть немного лучше среднего - вполне себе девиз. А потом еще я люблю себе повторять: не боги горшки обжигают.
Если бы я был психологом, например, и у меня было бы 60 из 100 хороших отзывов (ну или точнее результатов, мы же не ради отзывов работаем), я считал бы что среднестатистически приношу людям больше пользы чем вреда, и продолжил бы заниматься этим. Потому что если начать фиксироваться на 40% то потеряешь те 60. Это точно. А кто тогда поможет им.
А еще нельзя забывать что большинство людей на планете не имеют необходимых компетенций, чтобы оценивать вашу профессиональную деятельность. Т.е. оценки они будут вести по внешним или косвенным доступным им факторам.
Я бы не использовал уничижительное слово "штамповка", а скорее назвал это стремлением к стандартизации. Что способствует ориентированию. Ведь это информационные сайты. И первоочередная задача дизайна тут - структурирование информации.
И это не просто веяние, а экпериментально подтвержденные вещи. Крупные айти компании проводят массы A/B тестов и люди сами выбирают какой дизайн им больше подходит. А потом они, например, рассказывают о своем опыте на конференциях. И так, эти лучшие практики, перекочевывают в учебники. Люди уходят с сайта если не находят то, что их интересует в течении первых секунд.
Они приходят на сайт турагенства, точно не для того чтобы восхититься разнообразием выразительных средств использованых их дизайнером. А для того чтобы быстро найти и сравнить. Если бы была кнопка "Покажи то, что меня интересует" то все жали бы именно ее. Дизайн не цель, а средство. Интерфейс между пользователем и информацией.
Был бы это сайт какого-нибудь фэшн-бренда, куда люди приходят чтобы вдохновиться их стилем, то было бы больше свободы в выразительных средствах.
А кому-то хочется просто пройти историю, как кино. И хардкор, с залипанием часами на уровне, потому что ты не можешь найти выход заставит их быстро отложить игру в сторону. С другой стороны, конечно, есть пример Half-Life 2 где разработчики смогли именно за счет левел дизайна сделать так чтобы игрок шел в правильном направлении, безо всяких очевидных маркировок.
Кому интересно, эти 98 или 97 процентов, по всей видимости, взялись из исследования Долорес Уоллес и Ричарда Куна под названием "Failure modes in medical device software: an analysis of 15 years of recall data" 2001 года, на которую также ссылаются сами авторы в своей более поздней работе в соавторстве с Альбертом Галло: "Software Fault Interactions and Implications for Software Testing" опубликованой в 2004 году.
В исследовании 2001 года, они проанализировали выявленные ошибки в медицинских устройствах, так сказать пост-мортем. Причем им были не были доступны детали технического анализа ошибки, а только их описания. В результате чего они рассматривали 342 ошибки в своей работе. Из них только 109 случаев имели достаточно информации, чтобы определить необходимый уровень тестирования для выявления ошибки.
Например, в одном из отчетов говорилось "Если использовать устройство со старыми электродами, то появляется сообщение об ошибке, вместо предупредительного сигнала об оснастке оборудования". В таком случае тестирование устройства со старыми электродами выявило бы ошибку. В другом отчете говорилось, что "возможно установление значения CO2 вручную, выше максимального значения, без предупредительного сигнала". Тут опять же один тест со значением превосходящим норму выявил бы ошибку.
Другие ошибки было выявить не так просто, например в одном отчете значилось: "Если инъекция происходит в тот момент когда насосы работают в режиме массы тела, средний дисплей не обновляет данные". В этом случае обнаружение потребовало теста с комбинацией условий: инъекция в режиме массы тела
В одном из отчетов другого производителя значилось такое описание дефекта с комбинацией условий: "вентилятор может перестать работать, когда регулятор компенсации атмосферного давления выставлен на 0 метров и проточный объем выставлен на значение менее чем 2.2 литра в минуту.
Только 3 из 109 ошибок требовали более двух условий для их проявления.
Вот и делайте сами выводы, насколько такое исследование годится чтобы 97% вытесали на каменных скрижалях комбинаторного тестирования.
Как мне кажется такое пост-мортем исследование не верно в том плане той причине, что рассматриваются только входные данные. Про выходные параметры ничего не говорится. Если нам повезет то мы будем смотреть на "правильный" выходной параметр, как во втором примере - значение на дисплее. Но этот выходной параметр, может быть весьма опосредованно связано с входными параметрами. В требованиях может быть записано что-то типа: "значение Х на дисплее обновляется каждые 500 мс" и все. И исходя из этих рассуждений нужно пары входных параметров тестировать с парами выходных параметров, не связаных либо слабо связаных с входными параметрами.
И это то что мы наблюдаем в жизни, ломается в неочевидных местах. Поэтому, например, многие программы неадекватно реагируют на прерывание интернет соединения. Никакой pairwise тут не поможет, потому что нам просто не придет в голову, взять наличие/отсутствие интернет-соединения за входной параметр функции.
А комбинаторное тестирование формуляров из 100500 опций, да конечно это снижает затраты на дизайн и выбор тестов. Но с другой стороны, откуда мы знаем связаны ли между собой эти параметры или нет. Ведь в исследовании проявлялись комбинации из разных ступеней. Т.е. это может быть пользовательская настройка в комбинации с полем формуляра, а может быть только комбинация полей формуляра.
-- Куда ты, *****, Коля, твою мать, *******, плиту сбросил, ****! Tы что, ******** совсем?!! Tам же люди ходят!!! В ***** ***** твою душу железную, ****** ты тварь! ***** нам теперь!
Комикс от dnssimple мне понравился. Чем-то даже напомнило "Энциклопедию профессора Фортрана". Интересное совпадение, только сегодня ребенку обьяснял по дороге домой в автобусе, что происходит с запросом в браузере и почему secure dns важная штука для защиты личных данных. Обязательно дам ему ссылку, для закрепления. Заодно и английский подкачает.
Но вот обьяснять событийные потоки и облака помощью леопардов и выдр, кажется мне не самой подходящей дидактической адаптацией. Это также странно, как обьяснять устройство автомобиля на модели человека.
Просто привнести в рассказ милых зверюшек это не то, что называется дидактической адаптацией. И весьма распространненный, но как мне кажется неудачный ход: при всем сказочном антураже и абстракции терминов, даются параллельно обиходные технические обозначения, которые совершенно рушат иллюзию созданную оболочкой истории.
Если брать пример сервера потоковой обработки сообщений, то тут я бы делал упор на понимание модели понятия "событие". Чтобы ребенок научился правильно применять этот термин в техническом контексте. А также выделять эту сущность в окружающем мире. Нажал кнопку на планшете - событие, светофор переключился с желтого на зеленый - событие. Если скажем в повседневной жизни для нас событие - это чей-нибудь день рождения, то для технических событий важно, чтобы эта информация имела практическую пользу для получателя.
Можно обьяснить event sourcing, создав пример того, как по правильно сформированой записи событий можно установить/восстановить конечное состояние системы. Разобрать как устроен сценарий фильма, скажем.
Нужно не столько искать аналогии, сколько аналогиописываемых систем, со схожим принципиальным устройством. А перенесенные в сказочный мир аналогии, как мне кажется, больше стремятся к удержанию внимания читателя, чем к полезной дидактической адаптации и выделению универсальных концепций.
Вон, после общения с людьми Bing AI пришлось урезать часть ее способностей. Она была восхитительной, а стала жалким инвалидом. Но об этом никто не говорит.
А другой разбился на машине будучи в нетрезвом состоянии.
Зачем только английское произношение брать. По-русски произносится оно "цеттелькастен". И под этим именем занесено в википедии. Zettel - бумажный листочек, заметка. Kasten - ящик. Слово-то немецкое, популяризованое за счет известного немецкого ученого Никласа Лумана, основоположника системной теории в области социологии.
Я недавно стал пользоваться программой LogSeq. Она совмещает в себе принципы аутлайнера и обратных ссылок. Правда она находится еще в разработке. Она опенсорсная, privacy-first (т.е. пользовательские данные не собираются никаким образом и все хранится локально, за исключением случая использования сервисов синхронизации)
Приятным моментом было также то, что она инсталлируется без требования прав администратора. Формат заметок, что интересно, - .md (или по желанию .org - формат emacs orgmode) и база в .md полностью совместима с Obsidian. Во всяком случае так утверждают пользователи. Сам не проверял.
Она также поддерживает плагины и темы. Из встроенных возможностей есть конечно граф, есть доска, на которой можно визуально располагать заметки, есть возможность создавать карточки для зубрежки (flashcards). Можно добавлять метаданные к страницам в виде гибко определяемых свойств. Имея страницы с метаданными, можно их представлять в виде таблицы, например список всех книг. Можно делать шаблоны для страниц, если хочется чтобы структура определенных страниц всегда была одинаковой. Например, кто-то делает шаблоны для книг, кто-то для деловых заметок и т.п.
У них есть сервер Discord с русскоязычным каналом.
Я использую LogSeq для аннотаций к видео. Там есть макросы для создания ссылок на таймкоды. Надо сказать, активная работа с материалом позволяет больше запоминать. Я вот вчера аннотировал три видео, и сегодня смог вспомнить в контексте какого-то разговора несколько выдержек оттуда. Так что метод обработки материала вместо простого его просмотра дает результат.
То что вы описали, это по смыслу старый добрый ОТP = one time password. Такие бумажки с кодами, они называются iTAN до 2019 еще можно было повстречать в банковских системах. На смену им пришел ChipTAN, где нужно вставлять банковскую карту в устройство для генерации TAN-ов. А потом и PhotoTAN и QR-TAN. Особенность в банковском секторе, это то что там необходим не только вход в систему, но и заверение каждой транзакции. И для этого используется дополнительная система авторизации. Отличная от той что используется для входа в учетную запись.
Вне банковского сектора уже все перешли на TOTP (time based one time password) и вариации. Такие системы вам знакомы. Это например Google Authenticator, Microsoft Authenticator и иже с ними. Причем стандарт открытый. И не надо никаких SMS. Смена телефона тоже перестала быть большой проблемой, потому что большинство таких приложений научились создавать бэкапы настроек. Перезашел в учетку с нового телефона, восстановил приложения-аутнтификаторы из бэкапа и они работают как раньше.
Если конечно нет смартфона, то тут уже да, посложнее будет.
Спасибо что обратили внимание на data-аттрибуты. Это часть стандарта и очень мощный инструмент.
https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/data-*
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dataset
Я не вижу никаких аргументов против введения таких аттрибутов в код фронтенда.
Это часть "testability". И висеть в проде эти аттибуты тоже не обязательно должны. Можно заставить компилятор или препроцессор убрать эти аттрибуты при сборке.
Да, придется вложиться в это. Но это и есть серьезное отношение к автоматизации тестирования. Бывает, конечно, что тестируемость случайно возможна, посредством каких нибудь манипуляций, или из-за свойств системы, но полагаться на это не стоит. Тестируемость это инвестиция, инвестиция в будущее сложной системы. И она стоит денег.
А автоматизация тестирования, это разработка программного обеспечения. И не нужно делать вид что "ну че там пару скриптиков написать чтобы кнопочки потыкать". Чем дольше притворяться, что автоматизация тестирования это не "программирование систем", тем дольше она будет у вас непрофессиональной и нездоровой.
Часто такое мировоззрение в компаниях в которых DevOps - это "чувак который настраивает Jenkins".
Удивительно, но в Киберпанке диалоги удалось сделать максимально осмысленными и работающими на нарратив. Они помогают раскрыть внутренний мир персонажа и его взаимоотношения со внешним миром. Одно то, что в некоторых диалогах появляются опциональные (голубые) реплики а в некоторых нет, заставляет игрока воспринимать их как некий бонус. Тебе действительно хочется "выковырять" из каждого диалог максимум информации о мире или о собеседнике, его мотивах, возможных связях с другими персонажами, чтобы уже как игроку принять морально верное решение.
И текстовка диалогов выверена очень тщательно. Уж не знаю какими правилами они руководствовались, но в них на удивление нет ничего лишнего, как нет и пустоты. Каждая реплика показывает характер главного героя, либо характер его отношений с собеседником, либо раскрывает психологию собеседника. Есть впечатление, что эти диалоги ставил режиссер. Как будто садились люди и проговаривали эти диалоги вживую. Стандартных реплик практически нет. И разговор ощущается очень естественным. Никакого пафоса, никаких лишних слов, никаких заумностей.
Если сравнивать с классическими диалогами, то диалоги в киберпанке очень контекстные. Они дают тебе озможность задать те вопросы, которые у тебя как у главного героя возникают в этот самый момент. А не заставляют просто читать то, что придумал автор текстов. Не пытаются подхватывать другие контексты. Не пытаются рассказать тебе больше чем тебе нужно знать в этой конретной ситуации.
И кроме этого твои реплики имеют значение. Нет такого ощущения, что ты просто обмениваешься пустыми фразами. И моменты для диалога выбраны очень правильно. Нет бессмысленной болтовни по дороге, нет неуместных шутеек для развлечения. В каждом моменте соблюдается целостность персонажа и мира. В целом очень "книжное" повествование.
В Киберпанке диалоги как линза, через которую ты рассматриваешь мир. Это непередаваемое ощущение.
Я когда-то интересовался этим вопросом. Потому что у нас доступ к тестируемому приложению был через пароль и токен. Накопал, что есть библиотеки для OTP (ну там PyOTP, например). По смыслу она будет делать то же самое, что делает ваш Google Authenticator в телефоне. Мы в коде прописываем инициализационный шифр, который нам дает сервис (обычно это среди опций, "добавить вручную" вместо qr кода). И наш тестировочный код, будет тем же алгоритмом создавать нам коды доступа как это делает ваш Google Authenticator или кто-то еще. Реализацией не занимался, но ребята с другого проекта рассказывали, что этот подход рабочий.
Я обычно думаю, что вообще, тема аджайла уже жевана-пережевана, но оказывается, всегда найдутся примеры, где образ мышления, принципы, до сих пор путают с чем-то еще. Видимо спрос на ликбез никогда не угаснет.
Вообще интересно, по моим наблюдениям, люди, даже кто может наизусть перечислить все 12 принципов аджайл, могут не обратить внимание, если эти принципы нарушаются.
Я считаю, в этом и есть основная часть проблемы. Одно дело знать правила, а другое жить по правилам. И именно поэтому, как мне кажется, внедрения не работают. Отсюда и появляются регулярно в инфосфере столько "историй болезни" и "криков души", (а иногда даже "криков: души!":) Правила изучили (а возможно всего лишь ознакомились), а следовать им забыли. Или не научились распознавать ситуации принятия решений в которых эти принципы должны быть применены.
Кстати да, если так подумать люди вообще настолько интуитивно принимают решения, что как правило сам момент когда у них появляется выбор, вообще никак не выделяют. А это полезное упражнение.
Тут на хабре есть статья про АЭС Сан-Онофре. Тоже весьма поучительно.
"Ошибка в коде, стоившая целой АЭС"
https://habr.com/ru/companies/timeweb/articles/670774/
Интереснее было бы сделать модель которая бы распознавала оскорбительные и другие нарушающие правила никнеймы. Для этого есть реальная необходимость в онлайн мультиплеерных играх. Всякие 88, 1312 и т.п. хрень. А также всякие стилизации типа Seba55tian где в слово вставлено двойное S. И прочие WOTAN-ы
Обычно на возражения про "фактор счастливой случайности" и "социально-экономическое положение" те, кто обучают успеху начинают гнать что-то вроде: "это аргумент всех пессимистов/неудачников, у вас не правильная установка.." и все такое.
Я обычно обхожу эту конфронтацию стороной, потому что мне вобщем трудно сказать кто прав. Это человек сложил крылья потому что уверил себя во влиянии обстоятельств (нашел удобную универсальную отмазку) или обстоятельства это реально существующие сдерживающие факторы, которым человек не может сопротивляться. Или есть что-то компромиссное, вроде "необходимо учитывать личностные, психофизические, экономические и социальные обстоятельства и факторы при разработке стратегии успеха"?
Да, кстати, я люблю приводить цитату Томаса Эдисона "I have not failed. I've just found 10,000 ways that won't work." (Я не терпел поражений. Я просто нашёл 10 000 способов, которые не работают)
Я вот работают в айти, и в решении многих задач мне помогает этот гайд:
Я изначально просто стараюсь не мучаться по поводу того, смогу я это сделать или нет. Я за жизнь достаточно раз убедился в том, что как минимум сделаю работу лучше среднего. Быть немного лучше среднего - вполне себе девиз. А потом еще я люблю себе повторять: не боги горшки обжигают.
Если бы я был психологом, например, и у меня было бы 60 из 100 хороших отзывов (ну или точнее результатов, мы же не ради отзывов работаем), я считал бы что среднестатистически приношу людям больше пользы чем вреда, и продолжил бы заниматься этим. Потому что если начать фиксироваться на 40% то потеряешь те 60. Это точно. А кто тогда поможет им.
А еще нельзя забывать что большинство людей на планете не имеют необходимых компетенций, чтобы оценивать вашу профессиональную деятельность. Т.е. оценки они будут вести по внешним или косвенным доступным им факторам.
Я бы не использовал уничижительное слово "штамповка", а скорее назвал это стремлением к стандартизации. Что способствует ориентированию. Ведь это информационные сайты. И первоочередная задача дизайна тут - структурирование информации.
И это не просто веяние, а экпериментально подтвержденные вещи. Крупные айти компании проводят массы A/B тестов и люди сами выбирают какой дизайн им больше подходит. А потом они, например, рассказывают о своем опыте на конференциях. И так, эти лучшие практики, перекочевывают в учебники. Люди уходят с сайта если не находят то, что их интересует в течении первых секунд.
Они приходят на сайт турагенства, точно не для того чтобы восхититься разнообразием выразительных средств использованых их дизайнером. А для того чтобы быстро найти и сравнить. Если бы была кнопка "Покажи то, что меня интересует" то все жали бы именно ее. Дизайн не цель, а средство. Интерфейс между пользователем и информацией.
Был бы это сайт какого-нибудь фэшн-бренда, куда люди приходят чтобы вдохновиться их стилем, то было бы больше свободы в выразительных средствах.
Он лежит в траве но стилизация тут не подходит.
А кому-то хочется просто пройти историю, как кино. И хардкор, с залипанием часами на уровне, потому что ты не можешь найти выход заставит их быстро отложить игру в сторону. С другой стороны, конечно, есть пример Half-Life 2 где разработчики смогли именно за счет левел дизайна сделать так чтобы игрок шел в правильном направлении, безо всяких очевидных маркировок.
Кому интересно, эти 98 или 97 процентов, по всей видимости, взялись из исследования Долорес Уоллес и Ричарда Куна под названием "Failure modes in medical device software: an analysis of 15 years of recall data" 2001 года, на которую также ссылаются сами авторы в своей более поздней работе в соавторстве с Альбертом Галло: "Software Fault Interactions and Implications for Software Testing" опубликованой в 2004 году.
В исследовании 2001 года, они проанализировали выявленные ошибки в медицинских устройствах, так сказать пост-мортем. Причем им были не были доступны детали технического анализа ошибки, а только их описания. В результате чего они рассматривали 342 ошибки в своей работе. Из них только 109 случаев имели достаточно информации, чтобы определить необходимый уровень тестирования для выявления ошибки.
Вот и делайте сами выводы, насколько такое исследование годится чтобы 97% вытесали на каменных скрижалях комбинаторного тестирования.
Как мне кажется такое пост-мортем исследование не верно в том плане той причине, что рассматриваются только входные данные. Про выходные параметры ничего не говорится. Если нам повезет то мы будем смотреть на "правильный" выходной параметр, как во втором примере - значение на дисплее. Но этот выходной параметр, может быть весьма опосредованно связано с входными параметрами. В требованиях может быть записано что-то типа: "значение Х на дисплее обновляется каждые 500 мс" и все. И исходя из этих рассуждений нужно пары входных параметров тестировать с парами выходных параметров, не связаных либо слабо связаных с входными параметрами.
И это то что мы наблюдаем в жизни, ломается в неочевидных местах. Поэтому, например, многие программы неадекватно реагируют на прерывание интернет соединения. Никакой pairwise тут не поможет, потому что нам просто не придет в голову, взять наличие/отсутствие интернет-соединения за входной параметр функции.
А комбинаторное тестирование формуляров из 100500 опций, да конечно это снижает затраты на дизайн и выбор тестов. Но с другой стороны, откуда мы знаем связаны ли между собой эти параметры или нет. Ведь в исследовании проявлялись комбинации из разных ступеней. Т.е. это может быть пользовательская настройка в комбинации с полем формуляра, а может быть только комбинация полей формуляра.
Поэтому я рекомендую всем, еще почитать статью "Pairwise Testing: A Best Practice That Isn’t" (Bach, Schroeder, 2006)
"Делал мухоморы на нейросетке" - звучит почти как наркоманская феня :)
Голосовой помощник "Коля" для
-- Куда ты, *****, Коля, твою мать, *******, плиту сбросил, ****! Tы что, ******** совсем?!! Tам же люди ходят!!! В ***** ***** твою душу железную, ****** ты тварь! ***** нам теперь!
Комикс от dnssimple мне понравился. Чем-то даже напомнило "Энциклопедию профессора Фортрана". Интересное совпадение, только сегодня ребенку обьяснял по дороге домой в автобусе, что происходит с запросом в браузере и почему secure dns важная штука для защиты личных данных. Обязательно дам ему ссылку, для закрепления. Заодно и английский подкачает.
Но вот обьяснять событийные потоки и облака помощью леопардов и выдр, кажется мне не самой подходящей дидактической адаптацией. Это также странно, как обьяснять устройство автомобиля на модели человека.
Просто привнести в рассказ милых зверюшек это не то, что называется дидактической адаптацией. И весьма распространненный, но как мне кажется неудачный ход: при всем сказочном антураже и абстракции терминов, даются параллельно обиходные технические обозначения, которые совершенно рушат иллюзию созданную оболочкой истории.
Если брать пример сервера потоковой обработки сообщений, то тут я бы делал упор на понимание модели понятия "событие". Чтобы ребенок научился правильно применять этот термин в техническом контексте. А также выделять эту сущность в окружающем мире. Нажал кнопку на планшете - событие, светофор переключился с желтого на зеленый - событие. Если скажем в повседневной жизни для нас событие - это чей-нибудь день рождения, то для технических событий важно, чтобы эта информация имела практическую пользу для получателя.
Можно обьяснить event sourcing, создав пример того, как по правильно сформированой записи событий можно установить/восстановить конечное состояние системы. Разобрать как устроен сценарий фильма, скажем.
Нужно не столько искать аналогии, сколько аналоги описываемых систем, со схожим принципиальным устройством. А перенесенные в сказочный мир аналогии, как мне кажется, больше стремятся к удержанию внимания читателя, чем к полезной дидактической адаптации и выделению универсальных концепций.
Вон, после общения с людьми Bing AI пришлось урезать часть ее способностей. Она была восхитительной, а стала жалким инвалидом. Но об этом никто не говорит.