Короче, мальчики и девочки, коллективная фаза отрицания прошла. Стадию гнева, по всей видимости или пропустили или если плакать в туалете, то не считается. Теперь это всё сменилась фазой торга.

Кучу известных людей подписалось под коллективным письмом, призывающим остановить разработку ИИ, чтобы не угнетать бедненьких кожаных мешков и их естественными желаниями работать джунами и миддлами. Естественно, никто из openai письмо не подписал, а вот всем остальным очень и очень страшно.

А помните те времена, когда в интернете искали всё с помощью Yahoo? Пришедший Гугл очень быстро вогнал последний гвоздь в крышку этого самого Яхуу без всяких сентиментов. Сейчас мы находимся где-то приблизительно в такой же ситуации, только ступенью выше.

https://futureoflife.org/open-letter/pause-giant-ai-experiments/

Короче, общаюсь я со своим напарником, пишем, значится, код вдвоём. Всё, вроде отлично. Пишем, исправляем друг друга, спорим по мелочам и смеёмся над шутками и вообще весело проводим время.

И вдруг — БАЦ! Мой собеседник перешёл на совершенно другую тему, начал что-то про джаваскрипт писать, виджеты генерировать и окна двигать. Оказывается, как потом признался мне мой визави, этот ответ предназначался совсем не мне, а кому-то другому. Как в том отзыве на али, хотел бы я посмотреть на того, кто заказывал пылесос, а ему пришло это.

​​Когда-то давным давно, лет тринадцать назад, учавствовал я, значится в одном проекте, который достался нам от индусов, нужно было прикрутить маааленькую фичу, ну то есть переписать всё. В общем, ничего необычного.

Но мы тогда в коде, в классе User обнаружили метод dr_smith?, который проверял айди пользователя на то, равен ли он 63 или не равен. Ну, вот так вот буквально.

def dr_smith?
  self.id == 63
end

Нам тогда это подняло настроение на добрых пол дня и мы такие ходили кругами и рассказывали какие же эти индусы недотёпы и как же они не умеют писать код.

А вот тут оказывается, что это не просто так надо, а ещё и так эффективно. Что фигачишь if просто в нужном месте и деплоишь поскорее в надежде, что этот кусочек не разростётся во что-то огромное и неповоротливое. Короче, пишем в коде authoriselon и гордимся.

Внезапное (нет) и ультимативное применение недочеловеческогол услужливого разума. Когда нужно поверхностно разобраться в отраслях и технологиях, где дупля не отбиваешь. Или когда отвечать на каверзные вопросы продавцов нужно, вроде «Вам комплектация UTR GEN7.1 или MGF-12V матрицей?». Попробуйте гуглом так вот ответ найти. Пару часов гугления и углубления в экспертные форумы обеспечено.

Только вот продавцы будут крайне странно смотреть, когда после каждого их вопроса по пять минут в телефон нужно будет втыкать.

А вот и экологи подтянулись. ИИ — это не только потеря рабочих мест, паника на биржах, новые фантастические романы и вот это вот всё, что мы любим, а ещё и потеря пресной воды. Исследователи внезапно (нет) обнародовали сенсационные данные, что обучение нейросетей оказывается потребляет не только энергию. Это всё и охлаждать надо или зачем там ещё вода нужна в датацентрах. Короче 700 тысяч литров пресной воды нужно, чтобы обучить GPT-3, а короткое общение пользователя с ИИ равносильно выливанию на землю бутылки пресной воды. Что с этим делать — непонятно. Просто how dare you, я так понимаю.

Интересно, есть ли исследование сколько воды выпивают сервера, которые индексируют страницы интернета гуглом.

https://arxiv.org/abs/2304.03271

Попробую публично апеллировать Вове Рожкову и его мысли, что названия фундаментальных штук, вроде микросервисов должны быть максимально понятными по содержанию и не нужно придумывать красивых новых слов для всего подряд. Вова называет такие названия «кринжовыми» и избегает их.

Безусловно, название должно отражать суть происходящего, это даже не обсуждается. А придумывать новые слова или новые значения нужно для тех штук, которым нет удобного слова или словосочетания. Например, был себе джаваскрипт такой, существовал, а потом у него появилась особого вида функция, которая асинхронно вызывает другую функцию. Ну есть же термин «функция высшего порядка» там, а у нас тут асинхронный вызов функций. Ну назови ты её «async higher-order function» и всё. Зачем же придумывать для неё отдельное слово «Promise»? Но вот придумали, потому что этот вот промис планировался, как особого вида функция и что это не просто «async higher-order function».

А дело в том, что так в человеческих языках и придумываются новые слова и новые значения. Для тех штук, которые долго объяснять по сути и длинно читать по составу люди находят красивые и лаконичные слова, чтобы быстро коммуницировать друг с другом. Конечно, важно не придумывать искусственный язык, чтобы заставлять на нём всех общаться, а идти на поводу у естесственного общения и придумывать названия для папочек и репозиториев такие, какими их называют люди между собой.

В одном проекте мы назвали сущность, которую пользователь через интерфейс запрашивал у менеджера и заполнял поля «Request». Вроде бы логично, пока не оказалось, что в фреймворке был баг и в некоторых случаях глобально доступная переменная внутри языка шаблонов «request» возвращала экземпляр http-запроса, а не нашу локальную переменную request = Request.find(params[:id]). Пришлось придумывать синоним Demand и менять внутреннюю терминологию. Для душнил уточню, что в интерфейсе для пользователя, конечно же, остался request 🙂 С тех пор я стараюсь избегать общих терминов и слов, которые можно было бы трактовать двояко.

В другом проекте было несколько ролей пользователя со своими интерфейсами. Ну, скажем, ORM-модели назывались стандартно User, Project и Company, а вот неймспейсы для каждого пользователя тогдашний архитектор назвал Egg, Chicken и Ranch, подразумевая, что в Ranch можно создать себе Chicken, а в курице — яйцо. Преимущество перед UserApp было огромным, потому как поиск файлов с префиксом egg прятал то, чего не хотелось видеть. Да и интуитивно понятно что из себя представляло каждое из приложений.

А третий пример про особого вида микросервисы в ещё одном проекте, где мы себе придумали такие микросервисы, которых и пристрелить было не жалко и запускать можно было бы когда угодно. Ну, умирали они часто, ну и хрен бы с ними. Там и другие микросервисы были разные, важные и ответственные, но вот эти вот были на особом счету и с особой структурой работы с ними. Назвали мы их сначала «быстродохнущими микросервисами», а потом кто-то назвал их «Леммингами» и оно прижилось так хорошо, что стало префиксом в названии каждого такого микросервиса. Ну, там «lemming_auto_subscription» или «lemming_story_history».

Короче, нельзя придумывать названия просто так. Этимология любого названия обязательно должна быть.

Есть очень хороший косвенный признак масштаба компании, с которой вы общаетесь. Ну вот приходит вам емейл с почтового ящика john@example.com. Сразу видно, что это — маленькая компания, скорее всего уровня стартапа, даже если содержимое письма говорит об обратном.

Дело в том, что при при определённом пороге красивые короткие имена заканчиваются и любое правило коротких имён перестаёт действовать. Я знаком с правилами выбора емейлов в компании по никнеймам, по первым буквам имени и фамилии, только по именам и вообще хаотические правила «какой емейл хочешь такой и заведём». Но все эти правила нарушаются при первом же дублировании. Можно, конечно, сопротивлятся до последнего и добавлять букву второго имени и придумывать новые псевдонимы, но рано или поздно емейлы приходят к универсальному стандарту имя.фамилия@exampe.com, а вон то старьё в виде никнеймов и аббревиатур становится алиасами, которыми лучше не пользоваться.

Следующая стадия размера компании — обезличенные емейлы, вроде hr@exampe.com или ceo@example.com. Там тяжело сказать о размере, но от таких емейлов тоже рано или поздно отказываются в качестве исходящей почты и оставляют только в качестве входящей рассылки.

«Навчайся за донат» — проєкт на підтримку ЗСУ від громадської організації Демократична Сокира! В межах ініціативи слухачі опановують професію DevOps-інженера в обмін на донати війську. 20 травня стартує навчання третього потоку онлайн-курсу, який викладає технічний директор і співзасновник Tucha Володимир Мельник.

Під час практичних занять учасники дізнаються, як працювати з Docker, Kubernetes, Helm, GitLab, Ansible та іншими додатковими сервісами, які можна розгортати в кластерах Kubernetes. Загалом курс передбачає не менше 15 вебінарів у Zoom, кожен з яких триває щонайменше 2 години.

Докладна програма та деталі проведення курсу — за посиланням.

За кожну лекцію слухачі переказують 30.00 USD на рахунок фонду, які йдуть на закупівлю амуніції, військової форми, техніки, засобів тактичної медицини та іншого необхідного приладдя. Наразі завдяки проведенню DevOps-курсів зокрема зібрано понад 1 200 000 грн на потреби війська: авто для підрозділу ППО, квадрокоптери, прилади нічного бачення, портативні зарядні станції, спальники, тактичні рукавиці, купа засобів тактичної медицини тощо.

Запрошуємо стати слухачами нового потоку всіх, хто бажає розвиватися у DevOps-галузі та зробити свій внесок у наближення перемоги! Щоб приєднатися, заповніть невеличку анкету.

#волонтерство на правах реклами.

Есть у меня манера такая, из-за которой я постоянно забочусь о будущем гипотетическом вертикальном масштабировании приложения ещё на этапе git init. Буквально везде переживаю, чтобы можно было расширить, засунуть и скейлить новую связь, сделать из отношений один-к-одному отношения многие-ко-многим, всунуть мультипрофили, переключение контекстов и всякое такое. Прям со старта, когда нужно просто добавить одну табличку в базу и модельку создать, у меня на ровном месте появляются company_id, author_id и вот это вот всё такое подобное. С точки зрения энтерпрайза это, наверное, неплохо, но вот в стартапном подходе это сильно мешает ускорится и сделать релиз уже к вечеру.

И что с этим делать и нужно ли вообще с этим что-то делать я совершенно не представляю. С одной стороны это сильно тормозит прототипирование. С другой — прототип легко и без дополнительных костылей разрастается в энтерпрайз. В общем, буриданова дилемма никак не иначе.

Один из самых показательных и любимых «усложнений» в коде — это минимизация вызова методов на классе. Нет, не вообще вызовов, а тех, которые возвращают данные. Например, вместо того, чтобы на уровне контроллера написать Project.find(params[:id]) у меня появляется конструкция current_user.available_projects.find(params[:id]), где available_projects будет методом в классе User с приблизительно следующей реализацией:

def available_projects
  Project.all
end

Технически это будет ровно тот же вызов, стоить он мне будет ноль целых одна сотая джоулей затрат, но потенциального профита через годик это может принести неоценимо много. Ведь теперь все последующие изменения будут опираться на то, что нужно знать текущего пользователя, чтобы найти проект. Поэтому какой-то отдельный сервисный класс нужно будет инициализировать в контексте пользователя. Кому доводилось менять код, в ебенях которого что-то там вызывается снаружи, прекрасно понимают о чём я.

Так, кажется, уже вообще все используют gpt не только, чтобы быстро узнать в каком возрасте Тарас Григорьевич «пас телята за селом», сгенерировать кусочек кода или узнать сколько лет длилась столетняя война.

Есть какие-нибудь удачные попытки использовать gpt на корпоративном уровне? Кто-то уже успел встроить его в бизнес-процессы? Не стесняйтесь, делитесь. Если уж сильно стесняетесь разболтать корпоративную тайну, разбалтывайте в личку мне.