😌💨

Научное исследование влияния каннабиса на способность программировать:

"Случайные свидетельства употребления каннабиса профессиональными программистами многочисленны. Недавние исследования показали, что некоторые профессионалы регулярно употребляют каннабис во время программирования, даже для решения рабочих задач.
Однако рассказы о влиянии каннабиса на программирование сильно различаются и часто противоречат друг другу. Например, некоторые программисты утверждают, что он снижает их способность генерировать правильные решения, в то время как другие утверждают, что он повышает креативность и концентрацию. Остается потребность в эмпирическом понимании истинного влияния каннабиса на программирование.

В данной работе представлено первое контролируемое обсервационное исследование влияния каннабиса на способность к программированию. На основе внутрисубъектного исследования с участием более 70 человек мы обнаружили, что в экологически обоснованных дозах каннабис значительно снижает эффективность программирования. Программы, выполненные под кайфом содержат больше ошибок и требуют больше времени для написания (𝑝 < 0,05) - эффект от малого до среднего (0,22 ≤ 𝑑 ≤ 0,44). Мы также не нашли никаких доказательств того, что укуренные программисты генерируют больше разнообразных решений"

Канал Cross Join. Подпишись

Написал статью про семантический поиск с помощью посгреса и OpenAI API.

Казалось бы, в посгресе и так есть неплохой полнотекстовый поиск (tsvector/tsquery), и вы из коробки можете проиндексировать ваши тексты, а потом поискать по ним. Но на самом деле это не совсем то, что нужно — такой поиск работает лишь по чётким совпадениям слов. Т.е. postgres не догадается, что "кошка гонится за мышью" — это довольно близко к "котёнок охотится на грызуна". Как же победить такую проблему?


TLDR:


1. Преобразовываем наши тексты в наборы чисел (векторы) при помощи API openAI.
2. Сохраняем векторы в базе с помощью pgvector.
3. Легко ищем близкие друг к другу векторы или ищем их по вектору-запросу.
4. Ускоряем индексами.

Как всегда, буду рад плюсикам на Хабре:

https://habr.com/ru/companies/karuna/articles/809305/

Канал Cross Join. Подпишись

Посмотрел исходники DOS. 85% на asm, 15% на Си

MS-DOS 4.0 опенсорснули под MIT 🌝

https://github.com/microsoft/MS-DOS/tree/main/v4.0

Из мира фронтенда. Я тут вышел из комы, и оказывается, уже во всех основных браузерах работает popover API (https://developer.mozilla.org/en-US/docs/Web/API/Popover_API )

Его можно использовать для менюшек, всплывашек, тостов, диалогов и тд.

Поповеры всегда наверху, независимо от z-index

Клик вне поповера или esc его закрывает.

И тд.

Т.е. на голом html и css можно делать интересные вещи.

Вот примеры:

https://mdn.github.io/dom-examples/popover-api/

Десяток (-другой) лет назад я много верстал, и недоумевал, почему с первой версии css не сделали ничего для "сетки" (все верстали на таблицах) и вот таких вот штук для всплывающих элементов / диалогов, зато постоянно пихали много всякой сомнительной нужности хрени.

Не реклама.

И Алексей Пименов, и Макс Фролов (автор канала shit books) - на мой взгляд, самые прошаренные люди в галактике во всём, что касается процессов работы организаций. Поэтому было забавно почитать рецензию одного на книгу другого про Кнабан-метод. А если мне занесут за рекламу, то еще и порекомендую эту книгу купить ))

Из твиттера. Похоже, чат жпт учился на стековерфлоу

Google Cloud случайно удалил всю информацию крупнейшего Австралийского пенсионного фонда UniSuper, включая резервные копии в разных регионах.

Это произошло из-за сбоя, в результате которого удалилась подписка - а из-за этого и вообще всё.

UniSuper повезло, что они делали бекап информации в другие облака, поэтому процесс восстановления идёт.

https://www.theregister.com/2024/05/09/unisuper_google_cloud_outage_caused/

Не реклама, от всей души хочу порекомендовать онлайн конфу Podlodka Go Crew. А заодно я вымутил для вас промокод на скидку 500 рублей: Cross_Join_Crew

Если ты — golang-разработчик и страдаешь от недостатка профильных конференций, у нас для тебя клевая новость. Уже 13 мая стартует новый сезон Podlodka Go Crew с темой базы данных. Мы в Podlodka организовываем онлайн-конференции по разным секциям разработки, так что тебе не придётся куда-то ехать. Все знания получишь прямо у экрана своего монитора.
Научимся сравнивать библиотеки и ORM вместе с Арсеном Абдусаламовым из Авито. Познакомимся с решениями как можно подключаться к базам данных и узнаем про «Go way» способ.
Попрактикуемся обращаться с распределённым MySQL с помощью Vitess вместе с Ильёй Ушаковым. Ведь одного инстанса MySQL в какой-то момент может начать не хватать. Что же делать, если переходить на NoSQL совсем неохота? Vitess — ответ на этот вопрос, золотая середина между NoSQL distributed базами данных и проверенным опытом MySQL.
Узнаем всё о продвинутых структурах данных в Redis вместе с Олегом Арутюновым из Контура. Углубимся в преимущества и недостатки подхода, разберёмся с миграциями данных и оптимизацией базы.
Мокать или предзаполнять базы данных? На этот вопрос ответят спикеры из Ozon Fintech. И это будет не просто доклад, а баттл: не на жизнь, а на смерть. Разберёмся, когда какой подход выбрать и стоит ли ограничиваться только одним.

Бонус: публичный собес по работе с PostgreSQL. И это, естественно, не все сессии сезона. Залетай за билетом, чтобы не пропустить специализированную конференцию для Golang-разработчиков: https://podlodka.io/gocrew

Как вы наверно знаете, компания Open AI вчера выпустила новую модель GTP-4o (o - от слова omni)
https://openai.com/index/hello-gpt-4o/

Она умеет в режиме реального времени обрабатывать видео, звук и текст, отвечая с минимальной задержкой, сходной с человеческой.

Пока сложно сказать, что это нам даст, но выглядит впечатляюще, посмотрите видос, кто еще не. Просто говоришь как с живым человеком по видеосвязи, и он понимает то, что видит в камере. Ну и слышит. Плюс, сделаны более менее человеческие интонации, а не просто монотонное бормотание.

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

Да и вообще, пора уже это приделать к роботам из Boston Dynamics, и пусть уже делают дома уборку, гладят там, готовят, следят за детьми.

В принципе, можно и в магазин за пивом посылать.

Интересно, почему угасают популярные пакеты в Go?
Довольно популярный когда-то пакет для работы с посгресом lib/pq давно сдох и перешел в режим багфиксов. В  readme советуют переходить на pgx, и все так и сделали, но блин!

pgx находится в репозитории какого-то Джека Кристенсена. Т.е. ноунейм из интернета владеет популярнейшей либой. Ждём, когда ему надоест.

Дальше squirrel - тоже популярнейшее решение (query builder), тоже с тыщами звёзд, оказывается, разместило у себя, что больше развиваться не будет.

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

Возможно надо сделать модель как у spotify. За пользование гитхабом платишь в месяц какие-то небольшие деньги, а гитхаб распределял бы по авторам реп, в зависимости от популярности.

Исследование Cisco показало, что 57% времени разработчики тратят на решение проблем с приложением и кризисные совещания вместо пиления новых фич.

https://developer.cisco.com/articles/from-frustration-to-innovation/from-frustration-to-innovation

Удержать нельзя отпустить

Мне часто попадается мнение о том, что уходящих сотрудников удерживать нельзя ни в коем случае. Понимаю эту логику, но честно говоря, считаю эту формулу вредной.

Почему считается, что удерживать не нужно? Почти все рассуждения примерно такие: дескать, человек, получивший оффер, уже мысленно уволился, “изменил”, “укусил”, поэтому остается только пристрелить. Даже если удержишь - все равно ненадолго, человек все равно уйдет.

Ребят, да, есть такой шанс, но вообще это ерунда. Любой мало-мальски талантливый сотрудник, особенно в начале карьеры, постоянно в сомнениях и соблазнах, и нет вообще ничего страшного, если вдруг на него “накатило”, и он собрался увольняться. Есть миллион ситуаций, в которых люди не нашли в себе сил поговорить о карьере до момента, когда на руках уже оффер. Либо не было создано для этого условий. Короче, вины “компании” в этой ситуации может быть не меньше, чем сотрудника. Это я не говорю о таких случаях, когда принести оффер в другую контору - это вообще единственный вариант заявить о своих целях и получить повышение (таких компаний становится меньше, но их до сир пор полно, уверен, что каждый из вас уж одну-две такие компании точно вспомнит).

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

Лично знаю очень много примеров, когда бизнес рос очень быстро, у всех была куча дел, и люди просто в какой-то момент банально “задалбывались”, были готовы уйти в никуда из-за усталости, переработок, несовершенства процессов. Их удерживали и старались что-то изменить, и если получалось, то они ещё долго-долго успешно работали. Если бы их всех марали “предателями” - ещё неизвестно, насколько успешно бы развивалась компания. В крутых успешных компаниях люди работают долго. И почти каждый такой “долгожитель” - скорее всего когда-то хотел уволиться, но был удержан.

Короче, хороших людей, приносящих пользу - обязательно нужно удерживать. Только так можно построить по-настоящему крутую культуру. Каждый уход - это челлендж для вас: получше узнать и про человека, и про компанию. И дать шанс человеку, и вашим отношениям, и может быть это сигнал что-то поменять в компании. Да, есть шанс, что сотрудник зазвездился, загордился, преисполнился совершенно неадекватных ожиданий, и оставлять его нет смысла. Каждый ли сотрудник, кто собрался увольняться, такой? Нет. Дайте ему и вам шанс.

Исследование показало, что 52 процента ответов ChatGPT на вопросы по программированию неверны

Исследователи просмотрели более 517 вопросов в Stack Overflow и проанализировали попытки ChatGPT ответить на них.

«Мы обнаружили, что 52 процента ответов ChatGPT содержат дезинформацию, 77 процентов ответов более многословны, чем человеческие ответы, а 78 процентов ответов страдают от различной степени несоответствия человеческим ответам», — написали они.

Команда также провела лингвистический анализ 2000 случайно выбранных ответов ChatGPT и обнаружила, что они были «более формальными и аналитическими», но при этом отражали «менее негативные настроения» — тот мягкий и веселый тон, который обычно производит ИИ.

Исследователи Purdue опросили 12 программистов (по общему признанию, это небольшой размер выборки) и обнаружили, что они не обнаруживают ошибок, сгенерированных ИИ, в 39 процентах случаев.

Почему это происходит? Возможно, ChatGPT более вежлив, чем люди в сети.

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

Думаю, у каждого есть такой приятель-пиздабол, который с видом умудрённого опытом знатока дружелюбным голосом несёт ахинею

Тут надо понимать, что обычный программист тоже не ответил бы 100% правильно на все вопросы stackoverflow. Если посмотреть ответы, там иногда такая дичь попадается, что диву даёшься.

Stackoverflow выруливает потому, что много людей вычитывают код. Т.е. бажный код + код ревью = правильный ответ (и то не всегда, мягко говоря)

В этом плане сгенеренный чатом код может даже и получше будет в среднем, чем код рандомного человека. Если его проверять, конечно, а не тупо копипастить.

Написал статью на Хабр

https://habr.com/ru/companies/karuna/articles/816677/

Новость не новая, но интересная.

Любопытное заявление сделал гугл. Они утверждают, что на Rust писать код в 2 раза быстрее, чем на C++

А команды, перешедшие с Go на Rust, пишут примерно с той же скоростью.

В последнее трудновато поверить, честно говоря

Точняк