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, пишут примерно с той же скоростью.

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

Точняк

Человеки
Бич любой более или менее большой корпоративной системы – канцелярщина. По звонку люди перевоплощаются в должности. В роботов с бейджиками «специальный специалист». И всё: коммуникация в этот момент превращается в полосу препятствий.

Робот с регламентом за пазухой запрограммирован на то, чтобы всё на свете знать и не ударить в грязь лицом. И ладно, если специальный специалист, помимо апломба обладает релевантными для решения вопроса компетенциями, с этим можно жить. Но часто это не так:

Специалист по всему говорит абстракциями, многословен и витиеват: он скрывает свою бестолковость. Ситуация критическая. Всем срочно нужна инъекция человечности.

Однажды, мне в команду упала задача с невнятным описанием. Заказчик оказался как раз таким энтерпрайзным (и ненужным) винтиком. Мы обсуждали и обсуждали, много часов. Столько текста. Столько слов было сказано и всё ради того, чтобы выяснить, что никто ничего не понимает и не знает, а заказчик вообще не автор, а просто рупор чужого потока сознания. Не тот, с кем надо говорить, просто он мастерски это скрывал. Это бессмысленная трата времени, так же известная под кодовым названием «работа».

Не знаешь – не знаешь. Не можешь – не можешь. Хватит казаться, достаточно просто быть, желательно быть человеком.

Чувака бомбит от того, как Uncle Bob в книге "Чистый код" рефачит программы. Боб взял несложную чистую функцию и раздербанил это на огромный класс, с мутированием полей и запутанными названиями.

Было:

private void printGuessStatistics(char candidate, int count) {
    String number;
    String verb;
    String pluralModifier;
    if (count == 0) {
        number = "no";
        verb = "are";
        pluralModifier = "s";
    } else if (count == 1) {
        number = "1";
        verb = "is";
        pluralModifier = "";
    } else {
        number = Integer.toString(count);
        verb = "are";
        pluralModifier = "s";
    }
    String guessMessage = String.format(
        "There %s %s %s%s", verb, number, candidate, pluralModifier
    );
    print(guessMessage);
}

стало:

public class GuessStatisticsMessage {
    private String number;
    private String verb;
    private String pluralModifier;
 
    public String make(char candidate, int count) {
        createPluralDependentMessageParts(count);
        return String.format(
            "There %s %s %s%s", 
            verb, number, candidate, pluralModifier );
    }
 
    private void createPluralDependentMessageParts(int count) {
        if (count == 0) {
            thereAreNoLetters();
        } else if (count == 1) {
            thereIsOneLetter();
        } else {
           thereAreManyLetters(count);
        }
    }
 
    private void thereAreManyLetters(int count) {
        number = Integer.toString(count);
        verb = "are";
        pluralModifier = "s";
    }
 
    private void thereIsOneLetter() {
        number = "1";
        verb = "is";
        pluralModifier = "";
    }
 
    private void thereAreNoLetters() {
        number = "no";
        verb = "are";
        pluralModifier = "s";
    }
}

Понятное дело, что если фанатично упарываться по какой-то идеологии, то попадёшь в ад.

https://theaxolot.wordpress.com/2024/05/08/dont-refactor-like-uncle-bob-please/

Пишете ли вы комментарии в коде?

Когда-то (100 лет назад) я писал много комментариев, пока не прочитал, что нужно просто писать нормальный код, а не объяснять его сбоку. А комментарии всё равно устареют.

Окей.

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

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

Беда лишь в том, что задачи не всегда нормально это объясняют.

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

Было бы круто, чтобы можно было писать такие специальные коменты, чтобы при каждом коммите приходилось явно подтверждать их актуальность (если код рядом с ними менялся). Вот тогда бы было идеально)