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

Безусловно, название должно отражать суть происходящего, это даже не обсуждается. А придумывать новые слова или новые значения нужно для тех штук, которым нет удобного слова или словосочетания. Например, был себе джаваскрипт такой, существовал, а потом у него появилась особого вида функция, которая асинхронно вызывает другую функцию. Ну есть же термин «функция высшего порядка» там, а у нас тут асинхронный вызов функций. Ну назови ты её «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 на корпоративном уровне? Кто-то уже успел встроить его в бизнес-процессы? Не стесняйтесь, делитесь. Если уж сильно стесняетесь разболтать корпоративную тайну, разбалтывайте в личку мне.

«Кобзар» із віршем «мені сімнадцятий минало, я пас телята за селом» була опублікована, коли Тарасу Григоровичу було 23 роки. Столітня війна тривала 116 років. У «Пташиному молоці» немає молока птахів, а у крабових паличках немає мʼяса крабів.

На такі чи подібні цим питання не можливо відповісти без двох властивостей ШІ: контексту та додаткових знань. Шо ви як маленькі, їй-богу.

Читая ваши варианты использования ИИ в работе, вспоминается классика.

«Пап, а если ИИ будет делать за тебя половину работы, значит ты будешь работать в два раза меньше? Да, пап? Почему ты плачешь, папа?»

Опишу штуку, от которой я сильно прусь и которая была нами реализована.

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

Потом началось протекание абстракций. Сначала захотелось рекурсивного обновления. Чтобы у таблицы-дедушки обновлялось поле, если внук создаётся. Такой вот рекурсивный touch: true, который вообще-то так и работает. Во-вторых, промежуточные (torugh) таблицы игнорируются фреймворком. Ну вот есть у тебя companies, projects, comments и ты создаёшь companies.comments.create и хотелось бы, чтобы и у соответствующего и проекта и компании updated_at обновлялся, но нет. Ещё каждое обновление updatedat в каждой таблице — это отдельный запрос. В общем, фигня, как всегда.

И мы тогда добавили две вещи.

1. Значение по-умолчанию в таблице `createdat поставили в CURRENT_TIMESTAMP
2. Триггер таблицам, которые по всем foreignkey проходятся и там UPDATE updated_at делают соовтетсвующим записям в соседних таблицах.

Получилась красота неимоверная. Теперь никаких touch: true, а все записи в базе всегда в актуальных состояниях даже когда данные прямым sql-запросом обновляются.

Делюсь мудростью общения с GPT. Мне нужно составить такой промпт, чтобы тот, через апи запрашивал у модели нужные мне данные в нужном формате. Естесственно, вариантов составления куча, нюансов тоже.

После того, как я пишу приблизительный такой промпт, я иду к самой GPT и предлагаю ей улучшить сам запрос. Мол, вот тебе запросик составил, как сделать его эффективнее и лучше, а?

Here is my prompt to the GPT3.5 which should generate a structured data in the response. Can you improve that?

{{{PROMPT_HERE}}}

Запросы становятся куда лучше и данные правильнее. И да, в начале «Гопота» мне прям переписывал запросы как бы с нуля, а сейчас вот выдаёт вот такое:

Your prompt is already detailed and clear, but there's always room for some improvement. Here's a refined version:

{{{RESPONSE}}}

Но самое интересное начинается вот только тут. Чтобы понять что же он улучшил и почему, например, мой вариант «Strive to summarize» хуже его чем «Summarize effectively» нужно опять же спросить.

Why the sentence from your prompt "{{part _of_the_prompt}}." is better than my option "{{part _of_the_prompt}}."?

На что он даёт вполне развёрнутый ответ с объяснениями чем отличаются фразы и что он понимает под каждой из них. Пользуйтесь.

Главная ошибка в разговорах о повышении зарплаты — это расхваливание своих бывших заслуг. Логика работодателя вполне простая: сотрудник делает своё дело, в конце месяца получает за это деньги. И так каждый месяц. Договорённость о зарплате — это обещание заплатить столько-то денег, когда сотрудник сделает столько-то вот такой вот работы. Это не делёж награбленного на приратском судне, где сильные и авторитетные пираты получат больше, это не признание в любви к сотруднику, где покупают бриллианты «если ты меня любишь». Это всего лишь договорённость об обмене труда на деньги.

Из этого естественным образом вытекает очень простое следствие.

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

Скажем, зарплата абстрактного сотрудника $100 и он хочет 10% повышения. Работодатель знает, что найти замену можно за месяц и еще месяц уйдет, чтобы ввести в курс дела нового сотрудника. Получается, уволить того, кто есть, будет стоить $200, а повысить ему зарплату будет стоить $120 в год. Руководству, выгоднее повысить зарплату, чем лишиться имеющегося сотрудника.

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

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

Хлопці передають нам вітання ❤️. Дякую усім, хто зі мною допомагає цим бравим козакам. А хто ще не допомагає, але дуже хоче, то у опису до каналу є посилання на банку.

Слава Україні.

Господа рубисты и рельсовики-зайтейники. А накидайте-ка мне, пожалуйста, в комментарии или в личные сообщения блоги, которые вы читаете по теме. И ещё репозитории (вроде rails/rails или `jekyll/jekyll`), за которыми обязан следить каждый уважающий себя рубист. Может, какая рассылка есть ещё? Тоже подойдёт. Очевидные и само собой разумеющиеся тоже кидайте, не стесняйтесь.

Мы тут штуку одну делаем, надеюсь, в итоге будет полезна всем. Спасибо.

Оказывается, абсурдность идеи, что у ИИ нет души и он не может писать проповеди не для всех верующих очевидна. И в Германии в протестанской церкви провернули такую штуку, как ИИ-службу.

Хотя мне почему-то кажется, что пастор просто решил схалявить и не писать лонгридов.

Не уверен, что хочу разбираться что тут происходит, но это React 19 вместе с Typescript 6.

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

Просят ещё. Не хватает приблизительно тыщ 70. Спасибо за помощь.

https://send.monobank.ua/jar/8zAeCbuMw1