Information
- Rating
- 1,436-th
- Registered
- Activity
Specialization
Marketing Analyst, PR-manager
Senior
From 3,000 $
Project management
Business process management
Business development
IT service management
Agile
Waterfall
Scrum
Kanban
Information Technology
Promotion of projects
Нет, GPT ещё не пишет за меня комментарии - только помогает тем, кто не умеет читать без сарказма. Но если есть что возразить по делу, а не по фантазиям - слушаю.
Текст держит форму. Не ностальгия, а вскрытие. Архитектор показан как утраченная структурная роль, не как личность. Причины названы — организационные, а не моральные. Это правильно. Проблема - в концовке. Как по мне, так сдулась. Вместо диагнозавсе равно что слайд из митапа. Обобщения без инженерной опоры. Видно, что автор местами щадит читателя. Не надо. Тема грязная и писать надо грязно.
Объемный текст о системном подходе в разработке. Затронуты темы технического долга, изоляции контекста, проектирования с прицелом на изменение. Примеры узнаваемы, подача последовательная. Местами перегружен по объему, но структура в целом выдержана.
Полезен как материал для обсуждения подходов к архитектуре в команде. Без привязки к конкретным технологиям, с акцентом на мышление и долгосрочные последствия решений.
Да, соглашусь. Грегг с его "BPF Performance Tools" или хотя бы "Systems Performance" гораздо ближе к практике, чем Таненбаум. Особенно если упор идёт не на архитектуру, а на реальные симптомы и инструменты анализа. Просто в статье акцент скорее на общую траекторию, а не на глубину. Но да, если собеседование - это не кружок по истории ОС, то Грегг куда уместнее.
Спасибо за замечание -действительно, формулировка может вводить в заблуждение. Фактическое значение доли 500-х снизилось до уровня ниже 0.01%, но на графике, из-за масштаба и сглаживания, линия визуально уходит за ноль. По проекту: микрофинансовая нагрузка диктовала повышенные требования к стабильности - отсюда и приоритет на MTTR и качество алертинга.
Забавно, но ваш комментарий - идеальная иллюстрация результатов теста: ирония (/s) → 83% участников приписали бы это человеку (и ошиблись бы - ИИ так тоже уже умеет).
Запрос на 'гения' → Но ИИ-Эйнштейн будет лишь стилизатором, а не первооткрывателем; как если бы ChatGPT написал «E=mc²» в 1904 году - это всё равно бы никто не понял.
Суть в чем: мы упиваемся спором 'имитация vs гениальность', но проблема глубже: если ИИ незаметно заменяет рутину (а тест это подтверждает) - мы проигрываем войну за доверие.
Ваш сарказм ценен ровно потому, что он нешаблонный. Но 92% корпоративных email/документов/ТЗ - шаблонны. И вот их ИИ съест первым.
P.S.: Мечтать об ИИ-Перельмане - это как ждать, что калькулятор напишет 'Цветы зла'. Не та компетенция.
Главный итог теста: ИИ победил не в креативе, а в мимикрии под среднего человека.
Ваши данные показывают: слабость ИИ это - яркие эмоции/исповеди (но их в рабочих текстах - 5%); сила ИИ: предсказуемая рутина (описание процессов, отчёты, документация) - здесь человек проигрывает.
Это меняет правила игры: технические тексты (документация, ТЗ, мануалы) будут массово генерироваться ИИ. их 'человечность' станет бессмысленной тратой ресурсов.
Экспертный контент выживет, только если автор:
а) добавляет личный опыт (не 'я', а 'я на проекте X столкнулся с Y');
б) делится ошибками (ИИ всё ещё избегает их как огня);
в) использует актуальные аналогии (не 'как в войну', а 'как в последнем апдейте Kubernetes').
P.S.: вариант стратегии для авторов: пишите так, как не способен ИИ - хаотично, дерзко, с профессиональной болью. Иначе вас спутают с ботом. Правда можно и наткнуться на 'альтернативно мыслящих' и вам карму уронят. Я из тех, кому уронили в угоду своих убеждений (как будто я не имею прав на свои. забавно).
Спасибо за тест! Заберу в копилку аргументов против 'нейросеть заменит писателей'.
Местами затянуто, но по делу. Нормально объясняется, когда действительно стоит лезть в архитектуру, а когда это просто зуд. Хорошо, что автор не носится с 'чистой архитектурой' как с реликвией - есть конкретика, кейсы, и главное: связь архитектуры с оргструктурой, а не только с кодом. Такое редко встречается. Особенно полезно тем, кто устал от рефакторинга ради рефакторинга и хочет сначала понять, зачем он вообще нужен.
статья собрала в кучу все способы, которыми люди испытывают чат-ботов на прочность - тут и спам, и ролевые игры с психиатрией. но, давайте без иллюзий:
это не исследование, а коллекция багов
все эти 'сломанные' ответы вовсе не признаки сознания, а глюки в предсказании следующего слова. когда бот 'зацикливается' или 'паникует' - это ровным счетом то же самое, как если бы калькулятор от '10 ÷ 0' выдавал 'ERROR' вместо дыма из корпуса.
люди не ищут 'пределы ИИ', а играют в бога
90% таких тестов - не попытка улучшить модель, а:
'смотрите, как я обманул алгоритм!' (радость читера)
'ха-ха, бот думает, что он человек!' (антропоморфный фетиш)
'запощу в твиттер, инсту, тредс (не важно) - пусть народ поржёт' (ради кликов)
проблема в истинной ипостаси - не боты, а пиар
когда СМИ пишут 'ИИ признался в любви пользователю!', они создают миф о 'чувствующих машинах'. а потом еще и удивляются, почему люди:
боятся 'восстания машин'
требуют 'прав для ИИ'
плачут над скринами, где бот 'боится быть выключенным'
вывод:
да, тестировать границы моделей полезно (так находят уязвимости). но называть это 'абьюзом' - всё равно что обвинять гонщиков в издевательстве над crash-тестами.
P.S. автору респект за подборку техник - возьму на заметку для следующего стресс-теста. но давайте без драмы: боты не плачут. пока.
пожалуй, один из немногих текстов на тему 'как стать инженером', который не скатывается в романтизацию терминала и советы уровня 'читай мануалы и ставь Arch'. без вот этой всей токсичной старой школы, где новичков принято унижать, потому что 'мы через это прошли'. здесь про то, что мозги важнее тулзов, а системность важнее количества выученных команд.
особенно приятно видеть, что не навязывается один путь - типа 'DevOps или ничто'. есть и про SRE, и про DevSecOps, и про AIOps (пусть пока и скользко). да, местами слишком прямолинейно (Red Hat, Таненбаум, снова Таненбаум), но это лучше, чем 'бери курс за 50$ и ты Linux-инженер'.
короче, по делу, без мессии и без магии. статья ө не инструкция, а маршрутная карта. остальное — на совести читающего.
плюсую. именно благодаря таким 'челленджам' рынок и забивается одноразовыми поделками, решающими не проблемы, а скуку их авторов. очередной to-do-лист на React с телеграм-ботом - уже гордо именуем 'продукт'. Условный гайд 'как заработать $10' - уже 'монетизация'.
понятие 'инди-хакер' отныне звучит как насмешка. ни хакерства, ни независимости, ни риска. зато есть GPT, App Store и иллюзия стартапа.
формат «1 проект в месяц» - это не методология, это перебор идей в лоб. без валидации, без анализа, без фидбека. на выходе - не MVP, а MVB: минимально валидная бессмыслица.
код за 2 недели, пост в Twitter - и 'запуск'. только вот без ретеншна, без юнит-экономики и без пользователей - это не запуск, а репетиция.
челленджи - не зло. зло - когда повсеместно под их видом плодят цифровой фастфуд. и гордо называют это бизнесом...
сразу видно, что вдохновлялись англоязычными индихакерскими блогами, но забыли проверить, где заканчивается реальность и начинается фанфик...поехали
'Мы начинаем с тщательного анализа рынка…'
что конкретно анализируете - похожие проекты в Chrome Store? если вся 'аналитика' сводится к поиску похожих тулз на Product Hunt и просмотру трендов в GPT - это не анализ, это его имитация.
'Создаём ценность, решая 1 проблему'
лтлично звучит, пока не дойдёт до реализации. загвоздка а в том, что вы не показываете ни одного внятного способа понять, нужна ли ваша 'ценность' кому-то ещё, кроме вас. где валидация? где кастдев? где деньги, Лебовски?
'Запуск за 1 месяц'
серьёзно? с нуля? с маркетингом, юридическим оформлением, каналами дистрибуции и хотя бы базовым CI/CD? или речь идёт о лендинге с формой 'подпишитесь и мы вам напишем'?
'Маркетинг: SEO, соцсети, реклама'
вы бы ещё NFT дописали. вот прям ощущение, что каждый пункт писался под диктовку с no-*code форума 2020 года. откуда трафик? какой бюджет? какие метрики? что такое 'активно работаем над маркетингом' на практике - 3 поста в Telegram-канал с 12 подписчиками?
'Вкладываем свои $200 в продукт'
прекрасно. А что можно сделать на $200, кроме очередного no-code MVP без пользовательской базы и без инфраструктуры? даже тестовая реклама в Google Ads съест это за полдня.
'Не взлетело - делай следующий'
отличный способ бесконечно крутить колесо бессмысленных запусков, не усвоив ни одного урока. без анализа провала, без фидбека, без попытки понять, почему не взлетело, - это не итеративная разработка, это круг почёта вокруг одного и того же места.
по итогу что имеем:
'недо' манифест, скорее компиляция модных фраз из старых англоязычных блогов. без кейсов, без конкретики, без ответственности. всё это уже публиковали - десять раз точно, и каждый раз в формате 'вот теперь точно взлетим'.
хотите уважения к индихакерам - начинайте с честных разборов, а не с лозунгов. пока - очередной бизнес-план на салфетке из кафе...
потому что после таких техлидов рефакторинг - это не улучшение, а триггер. ты не код читаешь - вспоминаешь, как за него прилюдно макали, как объясняли, что «и так сойдёт». и да, теперь каждый новый PR - как флешбек
когда ты - человек, чья задача создавать видимость стратегии, страдания неизбежны. особенно тяжело, когда приходится оправдывать своё существование рядом с теми, кто делает реальную работу.
В нашем случае позиция топовая, и парашютист думает, что выше только 'небесная канцелярия'...
2000 тенантов. Переход с Nginx на Envoy. Интересный путь, но как будто читаешь о борьбе с бумажным драконом. Всякий раз, когда в Kubernetes-кластере заводится публичный шлюз, сходу начинается танец с саблями: одни бьются с конфигами, другие с падениями от OOM, третьи - с тем, чтобы вообще понять, где тут чей трафик и кто под землей морковку марафетит.
~Схемы красивые, контроллеры героически держатся, пока не приходят первые 1000 Ingress-ов. А дальше уже 'небольшой даунтайм на обновлении', который превращается в мем. Выбор Higress выглядит логично, особенно с учётом совместимости по аннотациям - как способ выжить без переделки всего. Но забавно, что стабильность теперь такая редкость, что она воспринимается как фича.
Следующая часть будет про 20 000 доменов? Надеюсь, в ней Envoy не сдастся.
Иногда кажется, что схема — это попытка заморозить хаос.
Пока всё только строится — схема как якорь. Но стоит инфраструктуре ожить — и половина блоков уже неактуальна, стрелки ведут в никуда, а легенда превращается в артефакт старины.
У нас был случай: новую схему нарисовали, согласовали, красиво оформили. Через месяц пришли обновлять — а она уже конфликтует с живой логикой настолько, что проще было бы сделать комикс «как оно могло бы быть».
Так и живём: рисуем схемы, зная, что они устареют раньше, чем их распечатают.
да все потому что 'рефакторинг' теперь ассоциируется не с улучшением, а с тем, как два месяца заливали в уши. устали. тема выжжена. если даже чисто гипотетичсеки идея здравая - никто не хочет снова проходить через ту же воронку.
Особенно забавно, когда iSCSI начинают тянуть через всё подряд — лишь бы «дешевле». А потом сидят, гадают, почему метасторидж падает, как только в офисе кто-то запускает YouTube.
DWDM/OTN — да, must-have, если не хочется объяснять клиенту, куда делись его данные. Но и там зарыты тонны нюансов: от несовместимых мультивендорных линков до сюрпризов в оптическом бюджете, когда усилители ставить уже поздно.
Короче, норм гайд для тех, кто хочет выйти из мира «вроде работает» в сторону «работает всегда».
Пожалуй ничего. Она не для того, чтобы нравиться. Хотелось просто обозначить это ощущение - когда всё вокруг становится одинаковым. Если начать переделывать, получится как раз то, против чего и написано. Пусть остаётся такой. Живой.