Есть у меня манера такая, из-за которой я постоянно забочусь о будущем гипотетическом вертикальном масштабировании приложения ещё на этапе 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

Обожаю такие вещи. Когда есть что-то сложное, что в среде экспертов объясняется формулами, терминами и концепциями, но можно показать вот такую картинку и спросить «Теперь тебе понятно что такое "нормальное распределение"?»

#реклама

👩‍💻 🧑🏻‍💻 Привіт, спільното!

Львівський ІТ Кластер реалізовує надважливий для ІТ-індустрії дослідницький проєкт IT Research Ukraine, який аналізує динаміку стану ІТ-галузі України. Потрібна ваша допомога.

📌 Вже понад 6000 ваших колег з ІТ долучились до дослідження. Ми продовжуємо збір даних, щоб досягнути цілі опитати 10 000 фахівців.

👉 Візьміть участь у загальноукраїнському опитуванні ІТ-фахівців та поділіться в анонімній анкеті, що змінилось у вашій роботі у 2023 році. Кожен індивідуальний досвід важливий для формування повної картини ІТ-галузі України та її областей.

В подяку за ваш час отримуйте промокоди на знижки від партнерів IT Club Loyalty після заповнення. Заповнюйте анонімну анкету за посиланням.

🤝 Проєкт IT Research Ukraine реалізовує Львівський ІТ Кластер в партнерстві з Міністерством цифрової трансформації України за підтримки Програми USAID “Конкурентоспроможна економіка України”.
📂 Чекайте на публічний звіт у грудні 2023 року на сайті Львівського ІТ Кластера.