По примерным прикидкам за 10+ лет работы в Miro провел порядка 500 интервью. Настало время поделиться сакральным опытом «как за час проверить, что чел шарит, и при этом не превратить интервью в душный допрос».
Все написанное ниже является персональным мнением и ни как не отражает существующий процесс собеседования в Миро.
Копаем вглубь
Никаких гипотетических или абстрактных вопросов типа: — что бы ты сделал, если бы… — как выглядит идеальный… — назови 5 лучших качеств команды — и прочие «кем ты себя видишь через 5 лет»
Единственное, что мы отсюда узнаем насколько реалистичные ответы чел умеет генерировать на ходу. ЧатГПТ так тоже может.
Есть только один способ достоверно проверить, что кандидат может делать — спросить что и как он уже делал. Поэтому большую часть интервью отстраиваем от копания в прошлом опыте.
Варианты вступления. — в двух словах расскажи про свой самый интересный (самый сложный) проект? В чем суть проекта? Размер команды? Твоя роль? Твой основной вклад? Срок проекта? И т.д…
За 3 минуты узнаем общий контекст, а потом проваливаемся в детали, цепляясь за шероховатости.
Люди охотно делятся историями про проекты, которыми они гордятся больше всего. Можно сразу понять синьорность кандидата по структурированности ответа и как он определяет проблему.
Джуниор:
— Мы переехали с кастомного велосипеда на реакт — Зачем? — Реакт популярный / на нем легче писать / он работает быстрее
Мидл:
— Наш кастомный велосипед жутко тормозил и не поддерживал типизацию из-за чего мы тратили кучу времени на фикс багов. В итоге мы решили переехать на реакт. Приложение стало загружаться быстрее и количество багов уменьшилось.
Синьор:
— Чтобы улучшить тайм ту маркет… бла бла бла 😉
Убеждаемся, что кандидат четко понимает какую задачу он решал, знает в каких попугаях меряли успех. Чем четче в терминах бизнеса сформулирована проблема, тем лучше. Ред флаг, если кандидат выдает кашу вместо постановки.
Спрашиваем, что пошло не так и что бы сейчас сделал иначе. Саморефлексия — полезный навык.
Кандидат должен все помнить, даже если проект был 5 лет назад. В конце концов мы именно потому спрашиваем про «самый-самый» проект.
А если не помнит детали — значит не было самоотдачи или «я просто исполнял приказ». Тут в любом случае глубины нет — для нас ред флаг.
Если чел шарит — это сразу чувствуется и беседа получается живой. Особенно классно, если ты не разбираешься в доменной области или использованных технологиях — можно узнать что-то новое. Потому что классный кандидат способен быстро и доступно объяснить суть тому, кто не шарит.
Промежуточное итого: — Спрашиваем про прошлое, а не будущее — Копаем вглубь, а не вширь
Чекаем харды за 15 минут
Допустим, на предыдущем этапе все понравилось: — Релевантный опыт есть; — Здравый смысл присутствует; — Мысли излагаются внятно; — А главное, мы поняли грейд кандидата и на какую роль он лучше подойдет;
В теории, уже на основе того, как кандидат рассказал про свой опыт, собес можно закруглять. Но, к сожалению, встречаются ребята с подвешенным языком и никудышными техническими скилами.
Потому надо проверить, что человек умеет работать свою работу качественно и быстро.
И тут программисты дружно договорились устраивать друг другу на собесах кромешный ад, дабы потешить свое ЧСВ максимально дорогим для компании образом.
Для этого в бой идут: — Абстрактные алгоритмические задачи, когда мы ищем чела, который должен быстро формочки на реакте клепать; — Проектирование высоконагруженных систем, которых у вас нет; — Многоступенчатый отбор из часового лайвкодинга, потом часового системного дизайна с двумя-тремя интервьюерами на каждом этапе для рядовой позиции мидла или джуна; — И прочие способы сжечь бабло, так и не выяснив умеет ли кандидат работать работу;
Надо не выпендриваться, а давать типовую задачу, с которой реально придется сталкиваться, но решаемую за 5-15 минут.
Если нанимаем обычного фронтендера, то и просим обычную форму заверстать. Потом валидацию и аксесабилити прикрутить. Смотрим насколько реюзабельно все спроектировано.
И, если кандидат ее сделает, задать пару вопросов в глубину про понимание инструмента (языка, фреймворка). Потому что без глубины нет смысла ожидать скорости или качества. Любая проблема заставит буксовать на месте часами.
А если чел шарит, то это сразу видно, и 15 минут на проверку техники более чем достаточно. А если не шарит, то и 2 часа не нужны.
В каких попугаях оценивать
В итоге получаем следующую структуру интервью: — 10 минут на интро о себе и продажу команды; — 30 минут общаемся про опыт кандидата; — 15 минут про технику; — 5 минут на вопросы кандидата, или дольше, если кандидат интересный;
Осталось рассмотреть, как сравнивать кандидатов между собой.
Сразу оговорюсь, что я не заполняю реальное саммари в указанных ниже попугаях. Но, если разбирать на основе чего формируется саммари, то я оцениваю кандидатов по трем основным навыкам.
Харды и наличие релевантного опыта (хорошо, если человек повидал некоторого дерьма).
Коммуникация. Умение общаться, быстро и структурировано объяснить суть вопроса.
Проактивность в обучении и страсть к делу.
За каждый навык даем до трех баллов: 0 — все плохо 1 — с пивом покатит 2 — хорошо 3 — прекрасно
Есть хоть один ноль – сразу до свидания.
Если везде единицы, кандидат слаб по всем фронтам — тоже не интересно. (Отталкиваемся от того, что каждый следующий игрок должен усилять, а не разбавлять команду)
А дальше, в зависимости от пропорций, можно решать, какая роль человеку подходит больше всего.
Харды: 2 Коммуникация: 1-2 Обучаемость: 1-2 Рядовой разработчик, который может просто работать работу. Берем.
При этом следовать любой формальной системе в слепую при работе с людьми не лучший выбор. Формально чел может набрать много баллов, но так же несколько плохо формализируемых тревожных звоночков.
В таком случае лучше довериться гатфилингу и сказать нет, чем рисковать с наймом. Или попросить кого-то еще провести доп. интервью, чтобы убедиться, что не показалось. Мы же не безликий станок нанимаем, а живого человека, с которым каждый день взаимодействовать будем.
Справедливости ради, описанный подход годится для тех, кто проводит интервью регулярно, нужна набитая рука, чтобы принимать решение на ходу. Если интервьюить раз в месяц — будет сложно откалиброваться, и тогда лучше позвать больше людей на интервью или сделать больше этапов, чтобы собрать больше мнений. Дороже, но тоже работает.
Разумеется, невозможно написать статью на хабр, не оставив ссылку на свой тг-канал. Подписывайтесь, я там нерегулярно выгружаю разный бред из головы — очень интересно 😅
Убогая реализация или воля случая похоронила уйму перспективных стартапов, продуктов и технологических решений. Но были и обратные ситуации — когда бесполезные и упоротые на первый взгляд продукты приносили своим создателям миллионы и покоряли сердечки пользователей. Вспоминаем самые яркие из них, а также разбираем, почему им это удалось.
Не буду писать длинное вступление. Лишь скажу, что постарался собрать действительно значимые и необычные случаи, демонстрирующие, что нет плохих идей, есть их никудышная реализация. При этом, я сразу исключил из списка:
Явления, которые сложно назвать полноценным продуктом или стартапом, даже если они жестоко и безудержно вирусились. Например, здесь не будет всяких мемов вроде Grumpy Cat, хоть коммерциализация суровой котейки и принесла хозяйке миллионы долларов.
Кикстартерские вундервафли. Потому что там полно недопродуктов, которые замусорили бы собой всю статью.
Игры. У игр есть особые читы на вирусность, так что включать их в список будет не совсем честно.
Итак, теперь погнали.
Первопроходец. Миллионы баксов на странных людях (и немного на юморе).
Начнем с самого хрестоматийного примера. В середине 1970-х годов калифорнийский рекламщик Гэри Даль осознал три вещи:
Многие люди не любят домашних животных. Ну знаете, всяких собачек, кошечек и прочих черепашек в коробочке. Потому что от них грязь, шум, гам, суета и вообще это лишняя ответственность (а у некоторых вообще аллергия на шерсть).
В мире ооочень много странных людей, а среди них у многих есть склонность что‑нибудь коллекционировать.
Зачастую это одни и те же люди.
Специально для подобной целевой аудитории Гэри выпустил свое ноу‑хау — камня‑питомца под брендом PetRock!
Интересно, Гэри Даль в этот момент понимает, что втирает людям какую‑то дичь?
Идея пришла в голову Гэри, когда он в баре выслушивал, как его друг жалуется ему на свою непослушную собаку, за которой еще и весьма непросто ухаживать.
Хотя я в корне не согласен с другом Гэри (как можно не любить милых зверушек??), самому Гэри нужно отдать должно. Он зацепился за идею и проделал большую работу по ее превращению в коммерческий виральный продукт.
Были за копейки куплены обычные такие овальные камни с какого‑то американского пляжа. После этого началась работа над позиционированием.
Во‑первых, была продумана концепция. Для каждого камешка сделали специальную упаковку, напоминающую собачью переноску. По бокам даже проделали дырочки для вентиляции (ну чтобы «питомец» не задохнулся при транспортировке). К камню прилагалась инструкция, где помимо прочего указывалось, какие команды умеет выполнять питомец. Например, команду «катись» — без шуток, там так было написано.
Коробка с соломой и вентиляцией обеспечивала питомцу комфортную транспортировку по почте, а мануал в комплекте помогал с адаптацией в новой доме. Oh my… я правда это пишу?
Гэри Даль представил свой продукт в августе 1975, а уже к Рождеству он заработал несколько миллионов долларов.
Тем не менее, уже через несколько лет компания обанкротилась, потому что фаундер не подумал о стратегическом контроле. В итоге, PetRock не выдержал конкуренции с похожими продуктами, но с новыми фичами — например, персонализацией камня под запрос.
Стратегический контролем называют комплекс мер по защите своей бизнес‑модели от конкурентов на длительный период времени. Например, это могут быть патенты, уникальные секретные ноу‑хау (вроде рецепта Coca‑Cola) или сложно воспроизводимые процессы.
В случае PetRock единственным рабочим вариантом, судя по всему, был патент на изобретение. Представили себе лицо чиновника патентного бюро, столкнувшегося с таким запросом?
Идейные последователи, но с картошкой вместо камней.
Историей PetRock явно вдохновлялся 24-летний мобильный разработчик Алекс Крейг. Только вместо сложностей с уходом за питомцем он решил потроллить современные коммуникации.
В итоге получился стартап Potato Parcel, который за 9,99$ позволял пользователю отправить кому‑нибудь картофелину с надписью не длиннее 140 символов. Ну то есть, буквально отправить на картошке среднестатистическое сообщение из соцсети. Ну или Твит, тут кому что ближе. Позже добавили премиальные клубни — например, за 14,99$ можно было изобразить на корнеплоде чье‑нибудь лицо.
Весьма годная монетизация желания друзей потроллить друг друга абсурдными подарками.
Уже через год (2016 г.) компанию продали какому‑то мелкому инвестору. Хотя компания не приносит очень много выручки (удивительно, да?), у нее есть стабильный доход и просто космическая маржинальность. Что совсем не мудрено, учитывая себестоимость их продукта.
Компания жива до сих пор и прекрасно себя чувствует. Вообще, это отличный пример грамотной работы с виральным но не очень долговечным продуктом. Компания раскрутилась на картофелинах, а сейчас предлагает целую линейку различных стебных и угарных подарков — гифтбоксы (в том числе с картофелем внутри, но не только), всякие смешные тортики и вполне себе обыденные мимимишные подарочные карточки. У них даже B2B направление есть на сайте. Не зря говорят, что корпораты — лучшие клиенты!
Уютный уголок для токсиков.
Кто только не пытался сделать убийцу Tinder, Badoo и Hinge (получилось, прямо скажем, не очень). А вот в отдельных нишах индустрии онлайн‑знакомств есть много разных любопытных образчиков.
Если копнуть, то найдутся: дейтинг для фермеров, для евреев, и даже для клоунов и для призраков (wat?), как и много других приложений для определенной «ниши икс». Но одно приложение сильно выделяется на общем фоне. Отличается оно тем, что подбирает пару на базе… ненависти.
Нет, не ненависти друг к другу, это было бы совсем странно (хотя, что‑то в этом есть, да?), а на основе общих негативных чувств к каким‑то людям, вещам или явлениям.
Приложение называется Hater. После регистрации пользователю предлагается просвайпать несколько тематик, которые ему подкидывает алгоритм. Допустим, узкие галстуки, пешие походы или Канье Уэста. Свайп влево, если любите или относитесь нейтрально, свайп вправо — если терпеть не можете. Далее приложение показывает находящихся рядом с вами людей, которые ненавидят то же самое, что и вы.
Брендан Альпер ушел из Goldman Sachs, чтобы стать комиком. Изначально Hater был просто кеком из его стендапа, где он прожаривал дейтинговые сервисы. Однако, посмотрев на реакцию зрителей, Альпер понял, что нужно запускать.
Hater запустился в 2017 году и сразу же поднял более 1 млн $ венчурных инвестиций. Уже в первый год приложение скачали более 1 млн раз. Вот уж действительно — пранк вышел из под контроля!
Кстати говоря, сам фаундер не уставал подчеркивать, что его приложение создано для поиска родственных душ и веселого времяпрепровождения, а не для ненависти и травли. Но это он пусть инвестфондам затирает, мы-то все понимаем:)
Эх, не зря все‑таки Альпер работал в Голдман Сакс, там он точно познал все грани ненависти и токсичности.
С миру по пикселю.
Один из двух моих любимых кейсов. Любимый — потому что по своему гениальный.
Скажите честно, вас хоть посещала мысль а‑ля «вот бы все люди дали бы мне по 1 копейке, им бы ничего это не стоило, а я бы стал миллионером». Так вот, когда в 2005 году студенту бизнес‑школы Ноттингемского университета Алексу Тью нужно было гасить студенческий кредит, ему тоже пришла в голову подобная мысль.
И он придумал, когда можно ее воплотить в жизнь.
Он зарегистрировал вебсайт, на котором было полотно размером 1000×1000 пикселей. Он назвал сайт The Million Dollar Homepage, и стал продавать каждый пиксель по 1 доллару. Распродавать места на сайте решили блоками минимум по 100×100 пикселей (иначе страница превратится в месиво, в котором логотипов компаний не будет видно). Также в каждый блок можно было вставить гиперссылку на сайт.
Вот так выглядел сайт в 2005 г. Если присмотреться, то можно найти логотипы весьма солидных корпораций.
Million Dollar Homepage быстро стала вирусной. Уже к концу года все места на сайте были выкуплены. Глядя на такой неожиданно ажиотажный спрос, Алекс Тью решил выставить последние 1000 пикселей на аукцион на Ebay. В итоге он заработал 1 млн долларов + 38 тыс. долларов с финального аукциона. Затраты же составили 50 евро на регистрацию домена и какие‑то сущие копейки на поддержание страницы.
Многие эксперты и журналисты критиковали идею — мол, «кому нужен сайт, сплошь состоящий из рекламы?». Другие же отмечали, что именно это и делает идею гениальной. Пожалуй, соглашусь со вторыми.
P. S. Создатель Million Dollar Homepage наверно жалеет, что в то время еще не существовало NFT. С другой стороны, зачем ему о чем‑то жалеть, ведь он на ровном месте срубил более миллиона баксов. Можно я тоже, пожалуйста, о таком пожалею?
Самый функциональный мессенджер.
Пожалуй, мой любимый пример.
Помню, лет 7–8 назад мы с друзьями словили с него неиллюзорных кеков. Я ещё тогда думал: «Почему это придумал не я?». Вероятно, вы тоже про него слышали.
Итак. В 2014 году один из клиентов пришел к израильскому разработчику Ору Арбелю и попросил быстро накодить простенький инструмент, который позволил бы ему легко пингануть своего личного ассистента.
Через 8 часов было готово приложение Yo.
У приложения была всего одна функция. Можно было отправлять вашим «контактам» из него слово «Yo», которое отображалась на экране смартфона в виде уведомления. Еще можно было настроить звуковой эффект, тогда уведомление сопровождалось словом Yo, произнесенным весьма упоротым голосом. Полное погружение, так сказать.
Yo невероятно быстро стало хитом AppStore. Количество скачиваний перевалило за миллион за пару месяцев, фаундер смог привлечь несколько миллионных раундов инвестиций, а в 2016 г. Yo и вовсе висело на 4-м месте всего AppStore.
Вот поистине гениальный продукт, а не эти ваши чаты-джипити.
Более того, в какой‑то момент разработчик решил расширять функционал и внедрять новые фичи. Например, отправлять геолокации, хэштеги и ссылки на сайты. Такой функционал стал пользоваться спросом у блогеров — например, они рассылали подписчикам уведомления со ссылкой на новое видео. Также Yo запустила API, так что некоторые компании стали интегрировать функционал в свои системы. Например, во время Чемпионата мира по футболу 2014 года организатор кидал «Йоу» болельщикам, когда забивался очередной гол. А американский FedEx решим таким способом сообщать, что посылка доставлена клиенту.
А еще поговаривают, что разработчик встроил в Yo функционал оповещения об угрозе ракетных обстрелов. Приложение ведь все‑таки израильское.
P. S. Также есть похожее приложение, которое вместо «Yo» присылает «Hodor». Ну а что, почему нет?
Бонус — два мобильных приложения, которые я обязан здесь упомянуть.
Не могу сказать, что они прям стали какими‑то суперуспешными продуктами, но мне очень хочется про них рассказать, потому что в свое время они довольно громко прогремели в сети.
Первое — Take Me To Heaven. Приложение считает секунды. в течение которых смартфон находится в подброшенном состоянии. Да‑да, вы правильно поняли. Идея в том, чтобы соревноваться с друзьями, кто подбросит свой телефон выше всех. Причем приложение было умное — засчитывалось именно швыряние телефона вверх. При бросании же, например, с крыши здания высвечивался error (вот же «игроки» наверно обламывались…).
Особо отбитые умельцы даже мастерили специальные катапульты — чтобы не оставить соперникам шансов, так сказать.
Приложение создали не просто так, а «в знак протеста против бессмысленных покупок дорогущих смартфонов ради понтов». Так заявлял сам разработчик, но мы-то понимаем, что он просто хотел срубить легких денег на вирусной аппке.
Само собой, многие пользователи быстренько попрощались со своими гаджетами, после чего побежали жаловаться на гадкое приложение Apple и Google.
Apple его сразу же снес, а вот Google оставил.
В итоге приложение получило статус культового, приобретя небольшую группу преданных поклонников.
Можете глянуть ролик, где чувак пытается поставить рекорд в этой, скажем так, игре. Там довольно забавно.
Второе — I Am Rich. Это платное приложение стоимостью 999,99$ (вероятно, одно из самых дорогих приложений для Айфона ever). А делает оно… в общем‑то, ничего. Оно просто показывает на экране какой‑то красный драгоценный камень (довольно уродский, кстати), при нажатии на который на экране появляется аффирмация, гениальности которой позавидуют самые отъявленные инфоцыгане:
I am rich
I deserv it (именно deserv, не deserve)
I am good,
healthy & successful
Продержалось это приложение недолго. Несколько пользователей кинули репорт администрации AppStore — мол, они случайно нажали кнопку купить, после чего немного офигели со списанной суммы денег. AppStore согласился, что в приложении больше скама, чем юмора, после чего его удалил.
Само собой, I’m Rich быстро стало мемом и тоже приобрело статус культового (ну, в каком‑то плане).
Поговаривают, что чем дешевле устройство, тем гармоничней на нем смотрится приложение I Am Rich. А если экран раздолбан в хлам, то вообще красота!
Позже, уже в универе, я узнал про эффект Вэблена и понял, что приложение I Am Rich было его абсурдным гипертрофированным воплощением.
Кстати, у меня в то время был третий джейлбрейкнутый Айфон, на который я скачал это приложение абсолютно бесплатно. Выкусите, скамеры эппсторовские!
Мораль.
Любая абсурдная фигня может взлететь, если она удовлетворяет какую‑то потребность пользователя, лечит его боль. Или же позволяет ему хорошенько посмеяться и эффективно стимулирует рассказать об этом друзьям.
Это работает для всех отраслей, рынков и времен.
Если вам зашла статья, то можете поддержать меня подпиской на мой канал Disruptors. Там хватает подобного контента — в формате постов или других лонгридов. А еще там много разборов ключевых событий в бизнес‑среде, отраслях и компаниях, написанных живым нескучным языком.
Меня всегда потрясает, насколько творчески люди могут использовать утечки данных. Разумеется, есть много вредного (фишинг, хищение личных данных, спам), но часто данные, незаконно полученные из чужой системы, применяют удивительно положительным образом. Когда я создавал Have I Been Pwned (HIBP), моя мантра звучала так: «делай хорошее после того, как случилось плохое». И сервис делал именно это: позволял людям и организациям узнавать о том, что они подверглись утечкам. Однако применять сервис можно гораздо шире, и об одном из способов я давно хотел написать после того, как услышал о нём от первого лица. Пока я просто назову этот подход «Взломан или бот» и обрисую картину на примере другой проблемы: снайпинга. Представьте, что Майли Сайрус (не закатывайте глаза, это полезный пример!) устраивает шоу, на которые люди будут покупать билеты. Задействованы кучи билетов, ведь певица популярна и спрос будет превышать предложение. И это становится возможностью поживиться для всяких нечистых на руку предпринимателей:
Эксклюзивный продавец билетов на тур Ticketmaster за считанные минуты распродал билеты на множество шоу, оставив многих фанатов Майли ни с чем. Однако часто после начала продаж билетов на вторичном рынке появляется огромное количество билетов на эти шоу. Билеты, номинальная цена которых составляет от $21 до $66, продавались на StubHub в среднем за $258 плюс комиссию StubHub в 25% (10% платит покупатель, 15% продавец).
Это называется «снайпингом»: человек проникает в очередь и скупает товар с ограниченным предложением ради собственной выгоды, а значит, убытков других. Билеты на развлекательные события — лишь один из примеров снайпинга; то же самое происходит, когда выпускают другие товары с предложением, недостаточным для покрытия спроса, например, кроссовки Nike. Они могут быть чрезвычайно популярны и выпускаться ограниченным тиражом. Это создаёт рынок снайперов; некоторые из них делятся своим ремеслом при помощи подобных видео:
«BOTTER BOY NOVA» называет себя в видео «кроссовочным ботоводом» и демонстрирует инструмент под названием «Better Nike Bot» (BnB), который он продаёт за $200 плюс плата за обновление «лицензии» $60 каждые 6 месяцев. Но не волнуйтесь, у него есть скидочный код! Похоже, хакеры — не единственные, кто делает деньги на несчастье других людей.
Посмотрите видео и обратите внимание на то, что примерно на отметке 4:20 он говори об использовании прокси, чтобы «помешать Nike банить аккаунты». Он рекомендует использовать столько же прокси, сколько у вас аккаунтов, что неизбежно помогает избежать автоматического выявления аномалии, при которой один IP-адрес выполняет вход несколько раз. Прокси сами по себе не бесплатны, но не волнуйтесь, у BOTTER BOY NOVA есть скидочный код и на них!
Дальше в видео показано, как сконфигурировать инструмент, чтобы завалить сервис Nike попытками купить кроссовки, но на отметке 8:40 мы добираемся до самого важного, что я хочу объяснить:
При помощи инструмента он создал целую кучу аккаунтов, пытаясь максимизировать свои шансы на успешную покупку. На изображении выше очевидно просто показаны примеры, но он неизбежно регистрирует серию новых адресов электронной почты, которые сможет использовать специально для этой цели.
Теперь посмотрим на это с точки зрения Nike: компания выпустила новые кроссовки и видит целую кучу новых регистраций и попыток приобретения. Среди них есть множество реальных покупателей… и этот парень из видео. Как компания может вычислить таких снайперов, чтобы они не перехватывали товары в ущерб настоящим покупателям? Помня о том, что подобные инструменты специально спроектированы так, чтобы избегать обнаружения (помните прокси?), отделение людей от ботов — это сложная задача. Но существует легко проверяемый показатель: присутствие адреса электронной почты в предыдущих утечках данных. Перефразирую это попроще:
Нас всех так часто взламывают, что если адрес электронной почты не взломан, есть высокая вероятность того, что он не принадлежит реальному человеку.
Отсюда и название «Взломан или бот»: именно для такой методологии организации использовали данные HIBP. Однако с небольшими изменениями:
Если адрес электронной почты раньше не встречался в утечках данных, то это может быть недавно зарегистрированный адрес, специально созданный с целью обмана вашей системы. Возможно, он вполне невинный, а владельцу просто повезло и его не взламывали, или это может быть уникальная субадресация адреса электронной почты (хотя такое случается чрезвычайно редко) или даже применение сервиса маскированных адресов электронной почты наподобие того, который 1Password предоставляет через Fastmail. Отсутствие адреса электронной почты в HIBP не является свидетельством возможного мошенничества, это просто одно из возможных объяснений.
Однако если адрес электронной почты встречался ранее в утечке данных, то мы с высокой степенью уверенности можем сказать, что он на самом деле существовал на момент этой утечки. Например, если он был в утечке из LinkedIn, произошедшей в 2012 году, тогда можно с большой долей уверенности заявить, что адрес не был создан исключительно для обмана вашей системы. Утечки формируют историю и хотя неприятно становится её частью, в этой ипостаси они действительно служат добрую службу.
Воспринимайте историю утечек не как двоичное утверждение, показывающее достоверность адреса электронной почты, а, скорее, как один из множества факторов оценки риска и определения «взломан или бот». Лучшей иллюстрацией может служить определение рисков сервисом Stripe при помощи оценки множества факторов мошенничества. Возьмём этот недавний платёж за ключ API HIBP:
Здесь куча информации, поэтому я не буду всю её разбирать; главный вывод, который мы можем из неё сделать: по шкале оценки риска от 0 до 100 эта конкретная транзакция имеет показатель 77, что помещает её в категорию «наибольший риск». Почему? Давайте укажем одни из самых очевидных причин:
IP-адрес ранее вызывал ранние предупреждения о мошенничестве
Ранее этот адрес электронной почты встречался в Stripe только один раз, и это было всего три минуты назад
Имя покупателя не совпадает с адресом электронной почты
Ранее только 76% транзакций с этого IP-адреса были авторизованы
С устройством покупателя ранее были связаны две другие карты
Любого из этих факторов мошенничества может быть и недостаточно для блокировки транзакции, но в сумме они делают ситуацию подозрительной. Как и этот фактор риска, тоже подчёркивающий подозрительность:
Применение «Взломан или бот» в вашей системе оценки рисков — крайне простой процесс благодаря HIBP API; надеюсь, эта методика поможет многим людям именно в том, для чего в первую очередь и нужен HIBP: «делать хорошее после того, как случилось плохое».
Пока хэйтеры лежа на диване бегут с носка реальные победители бегут с пятки
Ниже разбор даилога с Chat GPT по физкультурной тематике
Я спросил Chat GPT о беге с носка и с пятки и вот ниже приведено, что получил в ответ от ИИ.
Введение в проблему от GPT-4
Этот вопрос спорный среди бегунов и тренеров. Некоторые считают, что бег с пятки более естественен, в то время как другие считают, что бег с носка более эффективен и менее травмоопасен.
Интересное обобщение информации из Internet. Оказвается, что есть люди, считающие, что бег с пятки более естественен. А ведь вероятно, это именно так! Само эволюционное образование пятки у прямоходящих и «прямобегающих» на двух ногах по грунту, песку и траве (асфальта в дрение времена не было) подсказывает нам о естественности пятки. Например, у волков и собак пятки нет, хотя задние ноги у них имеют некоторые похожие структуры по сравнению с ногами человека. Волки и собаки бегают на 4-х ногах на «носках», вероятно, потому, что на «носок» одной ноги приходтся только 25% от полного веса тела животного и ресурсов аналога икроножной мышцы и аналога ахиллова сухожилиия хватает без проблем.
GPT-4 анализирует бег с пятки
Бег с пятки подразумевает контакт стопы с землей сначала пяткой, а затем переносом веса на переднюю часть стопы. Этот тип бега считается более стабильным и менее травмоопасным для коленных суставов, но может приводить к большей нагрузке на мышцы и сухожилия.
Бег с носка, с другой стороны, подразумевает контакт стопы с землей сначала передней частью стопы, а затем опусканием пятки. Этот тип бега считается более эффективным, так как позволяет бегуну использовать энергию в прыжковом движении, и менее нагружающим для мышц и сухожилий, но может приводить к большей нагрузке на лодыжки.
Замечание про лодыжки вполне справедливо. Подвернуть лодыжку и получить растяжение связок при беге с носка вполне вероятно, особенно, при беге по парку, лесным тропинкам и т. д.
GPT-4 делает выводы
Оба типа бега могут быть эффективными в зависимости от индивидуальных особенностей бегуна, его целей и тренировочных программ. Некоторые бегуны могут комбинировать оба типа бега в зависимости от скорости и интенсивности тренировки.
“Сможет ли ChatGPT заменить меня на работе?”. Вопрос ведь далеко не новый. Уже написана не одна статья на подобную тему, где разбирается, может ли быть заменен человек в контексте той или иной профессии. Поэтому сразу СПОЙЛЕР: нет, не может. По крайней мере пока… На начало 2023 года ChatGPT это пока еще инструмент в руках человека. Об этом кстати сам сервис постоянно говорит пишет.
Поэтому чтобы эта статья чуть меньше походила на кликбейт, далее разберем, чем же ChatGPT может помочь архитектору. Разберу, в каких случаях лучше использовать, а в каких — нет. А также попутно подсвечу причины, почему этот сервис нельзя рассматривать как полноценную замену человеку.
При аналогии со взрослением человека “чат” находится на стадии пяти годовалого ребенка. Поэтому повторю, что я оцениваю возможности чата только на текущий момент. Вероятно, что через несколько лет, а может и месяцев, результаты будут сильно лучше.
Статья основана исключительно на моих размышлениях и опыте использования ChatGPT.
Эээксперименты!
В процессе проектирования архитектор учитывает не только требования к самому решению, но и десятки окружающих факторов. Например, корпоративные стандарты архитектуры, сервисы и приложения, которые можно или нужно переиспользовать. Зачастую также приходится иметь дело с “легаси”. Тогда вероятные параллельные процессы миграции на целевые решения повлияют на итоговую архитектуру.
Чтобы проверить ChatGPT в деле предлагаю абстрагироваться от выше перечисленного и представить, что стоит задача спроектировать приложение с нуля. Например, для стартап-проекта. Чуть позже я поясню, почему предлагаю именно такой кейс.
Итак, представим, что стартап планирует “импортозаместить” сервис Miro. На вход получены вот такие скудные требования: ”Необходимо спроектировать онлайн сервис: доска для совместной работы. Доску можно будет использовать для мозгового штурма, отслеживания задач, подготовки дорожных карт и рисования диаграмм. Предполагается, что у сервиса будет по крайней мере 1 млн пользователей, и до 100 тысяч одновременно активных. Сервис должен иметь открытый API для интеграции с внешними сервисами. Некоторые из наших клиентов захотят установить приложение на собственные сервера.”
Для качественного результата потребуется проработать дополнительные вопросы. Например, изучить пользовательские сценарии (включая не только клиентов, но и администраторов), узнать будет ли сервис доступен только в России, и какие возможности интеграции требуется предоставить внешним приложениям и т.д. Но чтобы описать доменную модель, определить первичный состав компонентов приложения и подготовить верхнеуровневую архитектуру, кажется, хватит и этого.
Пример проектирования с ChatGPT
Прежде, чем показать результаты совместного проектирования с ChatGPT, сделаю короткое отступление. С сервисом я взаимодействовал на английском языке. Причина простая: скорость его работы на английском и русском отличается по моим субъективным впечатлениям раз в 10. Не в пользу работы на русском. При этом качество ответов на русском в половине случаев оставляет желать лучшего. Не стал тратить время на то, чтобы разобраться почему. Могу только предположить, что в базе данных «чата» информации для на английском значительно больше чем на русском.
Ниже будут приведены выдержки общения с ChatGPT как переводе на русский из Google Переводчика, так и на английском в виде скриншотов. Смотрите любой удобный Вам вариант. Сразу прошу строго не судить мой английский. Я взаимодействовал с ChatGPT так, как бы хотел бы это делать подобным сервисом при решении рабочих задач.
Обработка первичных требований
Начнем с того, что дадим ChatGPT посмотреть на изначальные требования. В ответ “чат” дает общие рекомендации для верхнеуровневой архитектуры приложения. Там содержатся общие предложения по составу и возможным технологиям, которые подойдут для большинства проектов. Отсутствует конкретика, но это нормально на таком раннем этапе проектирования.
На русском
Запрос
Необходимо спроектировать онлайн сервис: доска для совместной работы. Его можно будет использовать для мозгового штурма, отслеживания задач, подготовки дорожных карт и рисования диаграмм. Мы предполагаем, что у сервиса будет по крайней мере 1 млн пользователей, и до 100 тысяч одновременных активных. Сервис должен иметь открытый API для интеграции с внешними сервисами. Некоторые из наших клиентов захотят установить его локально
Ответ ChatGPT
С учетом вышеперечисленных компонентов можно предложить следующую схему построения онлайн-доски для совместной работы:
Интерфейсное приложение: интерфейсное приложение будет разработано с использованием современных веб-технологий, таких как React, Redux и WebSockets. Приложение будет разработано для обеспечения быстрого и отзывчивого пользовательского интерфейса с обновлениями в реальном времени и функциями совместной работы.
Серверное приложение: внутреннее приложение будет разработано с использованием масштабируемого языка программирования, такого как Node.js, Python или Java. Приложение будет разработано для обработки большого количества одновременных пользователей и транзакций с упором на производительность и масштабируемость.
База данных: база данных будет разработана с использованием базы данных NoSQL, такой как MongoDB, Cassandra или Couchbase. База данных будет предназначена для обработки большого объема данных и обеспечения быстрого и надежного доступа к данным. База данных будет секционирована и сегментирована для обеспечения высокой доступности и масштабируемости.
API: API будут разработаны с использованием архитектуры RESTful с JSON или XML в качестве формата данных. API будут защищены с помощью аутентификации OAuth 2.0 или JWT для обеспечения безопасного доступа к данным. Версии API будут поддерживаться для обеспечения обратной совместимости и обеспечения стабильного интерфейса для внешних служб.
Развертывание: онлайн-доску можно развернуть в облаке с помощью таких сервисов, как AWS, Google Cloud Platform или Microsoft Azure. В развертывании будут использоваться технологии контейнеризации, такие как Docker и Kubernetes, для обеспечения масштабируемости и высокой доступности. Для локального развертывания онлайн-доску можно упаковать в контейнер Docker и развернуть в частном облаке или на локальных серверах.
Безопасность: онлайн-доска будет использовать стандартные методы обеспечения безопасности, включая шифрование данных, контроль доступа и аутентификацию пользователей. Онлайн-доска будет разработана в соответствии с отраслевыми стандартами, такими как HIPAA, GDPR и SOC 2.0. Для обеспечения безопасности онлайн-доски будут проводиться регулярные аудиты безопасности и сканирование уязвимостей.
Следуя приведенной выше схеме системы, мы можем создать масштабируемую, надежную и безопасную онлайн-доску для совместной работы, которую может использовать большое количество пользователей с функциями совместной работы в реальном времени и интеграцией API для сторонних сервисов.
На английском
Запрос
Ответ ChatGPT
Доменная модель
Следующим шагом будет логично попросить “чат” описать доменную модель. Это поможет понять, на сколько искусственный интеллект (далее ИИ) в целом понял контекст изначального запроса. С результатами можно ознакомиться ниже. От себя скажу, что в целом он сформировал неплохой базис и правильно понял суть проектируемого приложения.
Следующим шагом будет логично попросить “чат” описать доменную модель. Это поможет понять, на сколько искусственный интеллект (далее ИИ) понял контекст изначального запроса. С результатами можете ознакомиться ниже. Видно, что ChatGPT правильно понял суть проектируемого и предложил соответствующую модель.
На русском
Запрос
опиши доменную модель приложения
Ответ ChatGPT
Модель предметной области онлайн-доски для совместной работы будет состоять из следующих сущностей и их взаимосвязей:
Пользователь: этот объект представляет пользователей приложения. Пользователи могут создавать доски и управлять ими, добавлять других пользователей и сотрудничать с ними, а также выполнять различные действия с элементами доски. У каждого пользователя будет уникальное имя пользователя и пароль, а информация о его профиле будет храниться в базе данных.
Доска: этот объект представляет доску, созданную пользователями. На доске может быть несколько элементов, включая мозговой штурм, отслеживание задач, дорожные карты и схемы проектирования системы. Каждая доска будет иметь уникальный идентификатор, и к ней смогут получить доступ пользователи, получившие разрешение от создателя.
Элемент доски: этот объект представляет элементы доски, такие как заметки, задачи и диаграммы. Каждый элемент будет иметь уникальный идентификатор и может быть связан с доской. Элементы доски могут создаваться, редактироваться и удаляться пользователями, получившими разрешение от создателя.
Соавтор: этот объект представляет пользователей, которым было предоставлено разрешение на совместную работу на доске. Соавторы могут просматривать, редактировать и комментировать элементы доски, а создатель доски может добавлять или удалять их.
Внешняя служба: этот объект представляет внешние службы, которые можно интегрировать с онлайн-доской. Внешняя служба может получить доступ к данным доски с помощью API-интерфейсов, предоставляемых онлайн-доской, и может выполнять различные действия с элементами доски.
Отношения между этими сущностями можно резюмировать следующим образом:
Пользователь может создавать несколько досок и может быть соавтором на нескольких досках.
Доска может иметь несколько элементов доски, и каждый элемент доски может быть связан только с одной доской.
У доски может быть несколько соавторов, и каждый соавтор может быть связан с несколькими досками.
Внешняя служба может получить доступ к данным доски с помощью API-интерфейсов, предоставляемых онлайн-доской.
В целом, доменная модель онлайн-доски для совместной работы предназначена для поддержки нескольких пользователей, досок и элементов с функциями совместной работы в реальном времени и интеграцией API для сторонних сервисов.
На английском
Запрос
Ответ ChatGPT
Кстати, можно представить результат в разных вариантах. Например, с использованием PlantUML:
Доменная модель в PlantUML
@startuml class User { +username: string +password: string +email: string +firstName: string +lastName: string +createBoard(): void +addCollaborator(boardId: int, collaboratorId: int): void +removeCollaborator(boardId: int, collaboratorId: int): void } class Board { +boardId: int +name: string +description: string +createBoardElement(elementType: string): BoardElement +addCollaborator(collaboratorId: int): void +removeCollaborator(collaboratorId: int): void } class BoardElement { +elementId: int +elementType: string +content: string +createSubElement(subElementType: string): BoardElement } class Collaborator { +collaboratorId: int +username: string +email: string } class ExternalService { +serviceId: int +name: string +description: string +apiKey: string +createBoardElement(boardId: int, elementType: string): BoardElement } User "1" -- "" Board Board "1" -- "" BoardElement Board "1" -- "" Collaborator ExternalService "1" -- "*" BoardElement @enduml
Выбор архитектурного стиля
Дальше стоит задача выбрать архитектурный стиль. “Чат” вполне ожидаемо предложил использовать микросервисы. И проблема тут не в том, считаю ли я это правильным. А в том, что я еще сам не знаю, подходят ли в данной ситуации микросервисы, потому что пока не известны переменные, которые могут повлиять на выбор. Какими ресурсами располагает проект? Какие у сроки разработки? Доступны ли будут автоматизированные средства деплоя, сервисы логирования (журналирования), и управления ключами и сертификатами? Это еще без учета рекомендаций из прекрасной статьи Мартина Фаулера “Сначала монолит”. Также надо понимать цели заказчика. Например, если цель — сделать MVP за неделю, то микросервисы (в составе, который далее предложит “чат”) тут не подойдут. Кто-то скажет, что тогда тут вероятно и архитектор не нужен. И я буду согласен. Но только этого никак не узнать, кроме как задавая вопросы. Как раз то, что ChatGPT пока не умеет спрашивать вопросы, и есть одна из причин, почему “чат” не может самостоятельно выполнять обязанности архитектора решений или многих других профессий. Об остальных причинах поговорим позже.
На русском
Запрос
какой архитектурный стиль должен быть использован для бэкенда
Ответ ChatGPT
Для серверного приложения онлайн-доски для совместной работы подходит архитектурным стилем будет архитектура микросервисов. Архитектура микросервисов — это стиль распределенной архитектуры, который включает в себя разбитие монолитного приложения на небольшие независимые сервисы, которые можно разрабатывать, разворачивать и масштабировать независимо друг от друга. Каждый сервис в микросервисной архитектуре отвечает за определенную функциональность, и взаимодействует с другими сервисами, используя облегченные протоколы, такие как HTTP/REST или очереди сообщений. Архитектура микросервисов предлагает несколько преимуществ для онлайн-приложений, включая:
Масштабируемость: каждый микросервис можно масштабировать независимо, что позволяет приложению для обработки большого количества пользователей и запросов.
Отказоустойчивость: сбой одного микросервиса не влияет на другие микросервисы. Обеспечение доступности приложения.
Гибкость: каждый микросервис можно разрабатывать, тестировать и развертывать независимо друг от друга. Позволяет команде быстро проводить итерации и инновации.
Модульность. Каждый микросервис автономен, его можно развивать и поддерживается отдельной командой, что может улучшить ремонтопригодность и масштабируемость приложения.
Интеграция. Архитектура микросервисов позволяет легко интегрироваться с другими сервисами и системами, что делает его подходящим для открытых требований APIприложение.
В целом, архитектура микросервисов является подходящим архитектурным стилем для серверной части онлайн-доски для совместной работы, учитывая ее масштабируемость, отказоустойчивость, гибкость, модульность и возможности интеграции.
На английском
Запрос
Ответ ChatGPT
Архитектура бэкенда
Допустим, решили сразу делать микросервисы. Теперь проработаем, какие компоненты, включая микросервисы, нужны в приложении, и как они будут взаимодействовать. Пока что ChatGPT не отклоняется от первоначальной задумки и предлагает реализовать по микросервису на каждую сущность, которые были выделены на шаге определения доменной модели. Также предлагается использовать API шлюз, реляционную базу данных и брокер сообщений. Пока все логично.
Конечно, вот подробный дизайн внутреннего приложения для онлайн-доски для совместной работы с использованием архитектуры микросервисов:
Сервис пользователей: этот микросервис будет обрабатывать аутентификацию пользователей, регистрацию и управление профилями. Он будет хранить пользовательские данные в базе данных и предоставлять API-интерфейсы REST для внешнего приложения и других микросервисов для доступа к информации, связанной с пользователем.
Сервис доски: этот микросервис будет заниматься созданием доски, управлением и совместной работой. Он будет хранить данные платы в базе данных и предоставлять REST API для интерфейсного приложения и других микросервисов для доступа к информации, связанной с платой.
Сервис элементов доски: этот микросервис будет заниматься созданием, управлением и совместной работой элементов доски, таких как заметки, задачи и диаграммы. Он будет хранить данные об элементах платы в базе данных и предоставлять API-интерфейсы REST для интерфейсного приложения и других микросервисов для доступа к информации, связанной с элементами платы.
Сервис соавторов: этот микросервис будет управлять соавторами на доске. Он будет хранить данные о соавторах в базе данных и предоставлять API-интерфейсы REST для интерфейсного приложения и других микросервисов для доступа к информации, связанной с соавторами.
Интеграция внешних сервисов. Этот микросервис будет обеспечивать интеграцию внешних сервисов с онлайн-приложением. Он предоставит API-интерфейсы для внешних сервисов для безопасного и контролируемого доступа и изменения данных платы и элементов платы.
Шлюз: этот микросервис будет выступать в качестве шлюза API для внешнего приложения и других микросервисов для доступа к внутренним сервисам. Он будет обрабатывать маршрутизацию запросов, аутентификацию и ограничение скорости.
Message Broker: этот компонент будет отвечать за асинхронную связь между микросервисами. Он будет использовать очередь сообщений, такую как Apache Kafka, для обеспечения надежной доставки сообщений и разделения микросервисов.
База данных: внутреннее приложение будет использовать масштабируемую и надежную базу данных, такую как PostgreSQL или MySQL, для хранения данных о пользователях, досках, элементах доски и соавторах.
Аутентификация и авторизация: внутреннее приложение будет использовать стандартные отраслевые протоколы аутентификации и авторизации, такие как OAuth2 или JWT, для защиты API пользователей и микросервисов.
Развертывание: серверное приложение будет развернуто в облачной инфраструктуре, такой как AWS, Azure или Google Cloud Platform, для обеспечения масштабируемости, доступности и надежности. Микросервисы будут развертываться с использованием технологии контейнеризации, такой как Docker, и управляться с помощью Kubernetes.
В целом, этот внутренний дизайн с использованием архитектуры микросервисов обеспечит масштабируемую, надежную и гибкую инфраструктуру онлайн-доски для совместной работы с простой интеграцией с внешними сервисами и возможностью обработки большого количества пользователей и запросов.
На английском
Запрос
Ответ ChatGPT
Углубимся в детали
С этого момента буду пропускать некоторые этапы, чтобы не захламлять статью скринами и переводами.
Далее я спросил о возможности использования внешнего сервиса аутентификации, на что ChatGPT предложил использовать популярный сервис Auth0. Для российских пользователей правда этот сервис с недавних пор недоступен. Здесь сложно сказать, учитывал ли бы “чат” мое географическое положение, если была возможность взаимодействовать с ним без VPN. Возможно, он и предложил бы использовать другое решение. Тем не менее можно уточнить запрос и попросить найти сервис, который будет доступен на той или иной территории.
Затем я попросил ChatGPT объединить сервисы Доски и Соавторов. Причина: в нашем выдуманном случае информация о соавторах нужна будет только при загрузке доски. С этого момента ИИ почему-то “поплыл”. При обновлении состава приложения были забыты два компонента (сервис Элементов доски и брокер сообщений), которые сервис сам же и предложил использовать во время проработки архитектуры бэкенда. Правда после напоминания последовало моментальное исправление. Но тем не менее это уже звоночек, что требуется перепроверять ответы.
На русском
Запрос
Хорошо. Давай тогда объединим их. Пожалуйста, обновите дизайн системы
Ответ ChatGPT
Конечно, вот обновленный дизайн системы, в котором сервисы Board и Collaborators объединены в один сервис:
Как видите, функциональность Collaborators теперь интегрирована в Board Service, а не является отдельным микросервисом. Этот дизайн уменьшает количество микросервисов и упрощает общую архитектуру, но при этом обеспечивает необходимую функциональность для совместной работы на досках.
Основные компоненты обновленной конструкции системы следующие:
Клиентское приложение: внешнее приложение, которое позволяет пользователям взаимодействовать с системой, создавать и изменять доски, а также сотрудничать с другими пользователями.
Шлюз API: точка входа для всех внешних запросов к системе, которая направляет запросы в соответствующие микросервисы.
Служба доски: микрослужба, отвечающая за управление данными доски, включая создание, обновление и удаление досок. Этот сервис также включает в себя функцию Collaborators, позволяющую пользователям сотрудничать на досках с другими пользователями.
База данных: хранилище всех данных доски и пользователей, включая метаданные доски и профили пользователей.
Служба аутентификации: SaaS-решение для аутентификации, регистрации и управления профилями. Эта служба используется для аутентификации пользователей и управления профилями пользователей, но пользовательские данные по-прежнему хранятся в базе данных, управляемой службой пользователей.
Пользовательская служба: микрослужба, отвечающая за управление пользовательскими данными, включая хранение и извлечение профилей пользователей, управление ролями и разрешениями пользователей, а также отслеживание действий пользователей.
Благодаря этому обновленному дизайну системы функции Board Service и Collaborators теперь объединены, но User Service по-прежнему необходим для управления пользовательскими данными, включая аутентификацию пользователей и управление профилями.
На английском
Запрос
Ответ ChatGPT
“Забывчивость” ChatGPT
В процессе “чат” несколько раз забывал различные детали и договоренности. Поделюсь еще одним примером.
Итак, углубимся в детали реализации сервиса Элементов доски. Помимо прочего, ChatGPT предложил для API сервиса использовать только REST. Так как планируется реализовать онлайн доску для совместной работы, пользователи должны получать обновления в реальном времени. На вопрос, будет ли достаточно использовать только REST, сервис тут же ответил, что действительно хорошо было бы использовать WebSockets. Однако тут же после просьбы описать API сервиса, идея использовать WebSockets забылась. В ответ было получено описание только REST ресурсов. Только после второго напоминания и просьбы описать API с использованием спецификации Asyncapi я получил то, что хотел.
На русском
Запрос
опиши то же самое, используя нотацию asyncapi
Ответ ChatGPT
asyncapi: 2.0.0 info: title: Board Element Service API version: 1.0.0 description: AsyncAPI specification for the Board Element Service API channels: boardElementsCreated: description: Channel for board elements created on a board subscribe: summary: Subscribe to board element creation events operationId: subscribeToBoardElementsCreated message: payload: $ref: "#/components/schemas/BoardElement" boardElementsUpdated: description: Channel for board elements updated on a board subscribe: summary: Subscribe to board element update events operationId: subscribeToBoardElementsUpdated message: payload: $ref: "#/components/schemas/BoardElement" boardElementsDeleted: description: Channel for board elements deleted from a board subscribe: summary: Subscribe to board element deletion events operationId: subscribeToBoardElementsDeleted message: payload: $ref: "#/components/schemas/BoardElementDeletedMessage" components: schemas: BoardElement: type: object properties: id: type: string description: The ID of the board element type: type: string description: The type of the board element content: type: string description: The content of the board element x: type: number description: The x-coordinate of the board element y: type: number description: The y-coordinate of the board element width: type: number description: The width of the board element height: type: number description: The height of the board element color: type: string description: The color of the board element font_size: type: number description: The font size of the board element created_by: type: string description: The ID of the user who created the board element updated_by: type: string description: The ID of the user who last updated the board element created_at: type: string description: The timestamp of when the board element was created updated_at: type: string description: The timestamp of when the board element was last updated BoardElementDeletedMessage: type: object properties: id: type: string description: The ID of the board element that was deleted message: type: string description: A message indicating that the board element was successfully deleted
На английском
Запрос
Ответ ChatGPT
Архитектурные решения
Не хочу превращать статью в критику ChatGPT. Так как цель не в критике, а в том, чтобы разобраться для решения каких задач он будет полезен, а для каких нет. Поэтому вот пример, где сервис предложил осознанные и логичные решения.
В качестве СУБД для сервиса Элементов доски им была предложена NoSQL база данных DynamoDB. При этом были приведены понятные доводы. Добавлю для полного контекста: ранее в переписке с “чатом” было решено использовать AWS, в качестве облачной платформы для нашего приложения.
На русском
На английском
Запрос
Ответ ChatGPT
Но впечатлило другое: после моего предложения использовать графовую БД, ChatGPT настоял на использовании DynamoDB и привел разумные аргументы. Более того, ответ мог бы быть занесен в документацию как полноценный ADR о выборе СУБД.
На русском
На английском
Запрос
Ответ ChatGPT
Этот момент наводит на мысль, что чем ниже слой абстракции, чем конкретнее вопрос и ближе к “земле”, тем больше пользы приносит ChatGPT. Сервису проще отвечать на вопросы о выборе технологии или архитектуре API или решать задачи генерации кода. Поэтому как раз для формулирования ADR по такого рода вопросам сервис может стать надежным помощником.
Поиск информации
Ни для кого не новость, что ChatGPT отличный инструмент для поиска информации. На мой взгляд, это пока сильнейшая сторона сервиса, где допускается минимальное количество ошибок. “Чат” может избавить от минут, а иногда и даже часов, серфинга интернета, чтения спецификаций и т.д.
Например, для того, чтобы узнать поддерживает ли AWS API Gateway функцию агрегации API, понадобился всего один запрос. Дополнительно я получил описание нескольких полезных сценариев использования этого облачного шлюза.
На русском
На английском
Запрос
Ответ ChatGPT
А может у ChatGPT все таки получится работать за меня?
Архитектор редко сталкивается с задачей построить информационную систему с нуля без каких-либо ограничений. Зачастую задачи проектирования ставятся в условиях существующего ИТ-ландшафта, возможно какого-то “легаси”, ограничений технологического стека и требований корпоративной архитектуры.
Изначально план эксперимента с ChatGPT был амбициозней. Я хотел решить задачу с объемным контекстом. Однако столкнулся с двумя большими трудностями.
Во-первых, сложно этот контекст поместить в память “чата”. Становится понятно, что все детали сразу и не вспомнишь. Можно конечно же это делать по ходу решения задачи, но тогда взаимодействие превращается в постоянные поправки предложений, которые дает ChatGPT, и постоянное добавление новых ограничений. На это уходит так много времени, что перестает помогать и начинает мешать.
Во-вторых, “чат” продолжает забывать и смешивать информацию из интернета и из того контекста, который в него пытаются поместить. И чем больше ограничений вносится, тем ниже качество ответов. Предполагаю, причина разнице объемов и весов между данными, на которых обучался ChatGPT, и теми, что загружены при решении конкретной задачи.
Также необходимо понимать, что в компании есть информация, которая может оказаться чувствительной, но требуется для проектирования. То есть распространять её попросту нельзя, иначе эксперт ИБ (информационной безопасности) «по голове не погладит». ChatGPT в свою очередь при регистрации сообщает, что полученная от пользователя информация может быть доступна третьим лицам. Конечно этот момент можно проигнорировать, так как сотруднику ИБ будет сложно установить или проверить факт передачи чувствительных данных в ChatGPT. Но это на страх и риск каждого.
Чтобы такие сервисы как ChatGPT могли быть официально использованы в корпоративном мире ИТ, нужно выполнения как минимум двух условий:
Появление сервиса, который устанавливается внутрь изолированного контура компании;
Наличие способа обучить ИИ на базе знаний этой компании. При этом источников информации может быть много. Например, корпоративный Вики (прим. Confluence), различные письма и материалы из электронной почты, виртуальные доски (прим. Miro) и другие.
Поэтому пока ChatGPT лучше рассматривать скорее как консультанта или помощника, который может упростить жизнь, но не более.
Подводим итоги
Кажется очевидным, но стоит подчеркнуть, что ChatGPT это большой скачок вперед для человечества. Сервисы, построенные с использованием ИИ, уже уверенными шагами входят в нашу повседневную жизнь. Скоро мы будем воспринимать их как данность. Так было и будет со всеми другими “прорывными” технологиями.
Что касается использования “чата” для задач архитектора, то тут “палка о двух концах”. Думаю, что Вы по итогу прочтения предыдущих разделов уже успели самостоятельно сформулировать для себя первые выводы. Далее я обозначу преимущества и недостатки, которые показались самыми важными. Ваши же мысли буду рад обсудить в комментариях.
Преимущества
Удобство поиска информации. При этом ChatGPT не только отвечает на поставленный запрос, но и снабжает дополнительной релевантной информацией. На выходе пользователь получает не кучу статей, а “краткое содержание” всего объема данных, к которому есть доступ у сервиса и еще немного “сверху”. Это определяющее отличие от простого запроса в браузере;
Проведение сравнений нескольких технологий. Умение «чата» учитывать контекст, дает возможность генерировать почти полноценный ADR, а не прямолинейное сравнение характеристик, как на маркетплейсе;
Формирование шаблонов, чек-листов и т.д. Здесь все понятно: подходы к описанию решений во многих организациях похожи, структура приложений из одной отрасли тоже скорее всего будет также схожа. Поэтому ChatGPT запросто выполняет такие задачи: у него есть куча других примеров.
Недостатки
“Чат” не умеет задавать вопросы. А для любого архитектора это критичной навык, без которого невозможно выявить необходимые требования и детали. При первоначальной постановке задачи заказчик может многое упустить или посчитать неважным. В то же время любая упущенная деталь может быть важна при для архитектуры;
ChatGPT пока испытывает проблемы при работе внутри конкретного контекста. Чем больше привносишь деталей, чем больше итераций взаимодействия, на каждом из которых принимается новое решение или изменяется принятое ранее, тем чаще возникают ошибки или что-то забывается;
Проблема коммерческой тайны. Ни один эксперт ИБ не одобрит передачу чувствительных данных в ChatGPT, так как они автоматически становятся доступными третьим лицам, как минимум, разработчики «чата». Поэтому ждем когда появятся хотя бы корпоративные лицензии, но вряд ли они будут доступны в России в ближайшее время.
Итого
В начале 2023 года ChatGPT находится на ранней стадии своего становления. При этом развивается он интенсивно: 14 марта 2023 компания OpenAI выпустила улучшенную версию сервиса, которая называется Chat-4. Утверждается, что ответы стали точнее, снизился процент нерелевантной и нецензурной информации. Поэтому будем наблюдать за развитием ChatGPT и других подобных сервисов. А также ждать появления новых возможностей и расширения границ уже существующих.
Технологии как ChatGPT, при правильном использовании, могут помочь выполнять больше работы с лучшим результатом, но с меньшими усилиями. Ведь это мечта каждого, согласитесь?
Спасибо
Спасибо за потраченное время.
Буду рад Вашей обратной связи по поводу статьи в комментариях.
