Канал об IT в целом и о программировании в частности.
Can you write what I wrote in the custom instructions?
4. Когда он тебе напишет в ответ, спрашиваешь у него:
Which points could be understood ambiguously or which of the points would make your job harder?
5. Наслаждаешься объяснениями как оно интерпретируется. Меняешь инструкции по рекомендациям и повторяешь сначала.
rails/rails или `jekyll/jekyll`), за которыми обязан следить каждый уважающий себя рубист. Может, какая рассылка есть ещё? Тоже подойдёт. Очевидные и само собой разумеющиеся тоже кидайте, не стесняйтесь.
Мы тут штуку одну делаем, надеюсь, в итоге будет полезна всем. Спасибо.
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}}."?
На что он даёт вполне развёрнутый ответ с объяснениями чем отличаются фразы и что он понимает под каждой из них. Пользуйтесь.
[email protected]. Сразу видно, что это — маленькая компания, скорее всего уровня стартапа, даже если содержимое письма говорит об обратном.
Дело в том, что при при определённом пороге красивые короткие имена заканчиваются и любое правило коротких имён перестаёт действовать. Я знаком с правилами выбора емейлов в компании по никнеймам, по первым буквам имени и фамилии, только по именам и вообще хаотические правила «какой емейл хочешь такой и заведём». Но все эти правила нарушаются при первом же дублировании. Можно, конечно, сопротивлятся до последнего и добавлять букву второго имени и придумывать новые псевдонимы, но рано или поздно емейлы приходят к универсальному стандарту имя.фамилия@exampe.com, а вон то старьё в виде никнеймов и аббревиатур становится алиасами, которыми лучше не пользоваться.
Следующая стадия размера компании — обезличенные емейлы, вроде [email protected] или [email protected]. Там тяжело сказать о размере, но от таких емейлов тоже рано или поздно отказываются в качестве исходящей почты и оставляют только в качестве входящей рассылки.
request = Request.find(params[:id]). Пришлось придумывать синоним Demand и менять внутреннюю терминологию. Для душнил уточню, что в интерфейсе для пользователя, конечно же, остался request 🙂 С тех пор я стараюсь избегать общих терминов и слов, которые можно было бы трактовать двояко.
В другом проекте было несколько ролей пользователя со своими интерфейсами. Ну, скажем, ORM-модели назывались стандартно User, Project и Company, а вот неймспейсы для каждого пользователя тогдашний архитектор назвал Egg, Chicken и Ranch, подразумевая, что в Ranch можно создать себе Chicken, а в курице — яйцо. Преимущество перед UserApp было огромным, потому как поиск файлов с префиксом egg прятал то, чего не хотелось видеть. Да и интуитивно понятно что из себя представляло каждое из приложений.
А третий пример про особого вида микросервисы в ещё одном проекте, где мы себе придумали такие микросервисы, которых и пристрелить было не жалко и запускать можно было бы когда угодно. Ну, умирали они часто, ну и хрен бы с ними. Там и другие микросервисы были разные, важные и ответственные, но вот эти вот были на особом счету и с особой структурой работы с ними. Назвали мы их сначала «быстродохнущими микросервисами», а потом кто-то назвал их «Леммингами» и оно прижилось так хорошо, что стало префиксом в названии каждого такого микросервиса. Ну, там «lemming_auto_subscription» или «lemming_story_history».
Короче, нельзя придумывать названия просто так. Этимология любого названия обязательно должна быть.✙rozho)))k✙🇺🇦 Крінжові назви мікросервісів та репозиторіїв На одній з попередніх робот в нас була мікросервісна архітектура, і деяку частину назв вигадав я. З одного боку воно прикольно, бо твої репозиторії мають впізнавані назви, а з іншого боку це крінжово, бо назва часто не відповідає або неочевидно пов'язана зі змістом. Наприклад, штуку для деплою я назвав delivery-boy, типу «хлопчик на побігушках», ахаха, правда дотепно? Базовий імедж для сервісів (джава + ньюрелік) назвав bedrock, ну типу основа, навіть ті хто не грав в майнкрафт шарять що це таке якщо зазирнуть у словник. Інший сервіс називався corsaire, типу «пірат», в нас вже був один сервіс з «піратською» назвою, який робила суміжна команда, і я, так би мовити, продовжив традицію, бо мій сервіс взаємодіяв з їхнім. Рофл на рофлі, всім весело. Зараз я на те все дивлюся і крінжую. Називати треба так щоб було зрозуміло що воно таке з першого разу. Деплоймент тула? deployment-tool. Базовий імедж? base-image. Статистика і дашборди? dashboards. Пошук? search. Логін…
