Work & Beer Balance

В zed можно менять json файл темы и он сразу же применяется как только файл был сохранен - удобно. Накидал себе тему за 20 мин

Не делайте кнопку копирования как zed, делайте как vscode. Потому что вы почти наверняка накосячили с Clipboard API (все нормально, это встречается повсеместно) и ваша кнопка ничего не делает у части пользователей. Просто дайте им скопировать вручную этот чертов текст

Обнаружил интересный и стабильно работающий сценарий с которым агент справляется на отлично (по крайней мере пока) - добавить логи для дебага процесса или проверки теории, и потом - удалить логи добавленные ранее для дебага.

Второй прием - тестирование функций которые какие-то события оборачивают в промисы:

Раньше я писал так:

  itWithMock('test getFooFromEvents', async ({ ctx }) => {
    const { mock, api } = ctx;
    const getFooFromEventsSpy = vi.fn(getFooFromEvents);
    getFooFromEventsSpy(api);

    const eventPayload = {
      foo: 'bar',
    };
    mock.emit('event', eventPayload);
    
    await pause(100);
    
    expect(getFooFromEventsSpy).toHaveResolvedWith(eventPayload);
  });

И честно признаюсь мне никогда не нравилась часть с const getFooFromEventsSpy = vi.fn(getFooFromEvents);
потому что она ощущалась мусорным болиерплейтом, который даже в beforeEach вынесешь только хуже сделаешь (потому goToReferenece по тестируемой функции приведет на место оборачивания в vi.fn вместо сорс кода функции)

да и await pause(100); будем честны тоже грязновато.

Теперь я пишу так

  itWithMock('test getFooFromEvents', async ({ ctx }) => {
    const { mock, api } = ctx;

    const eventPayload = {
      foo: 'bar',
    };

    const assertion = expect(getFooFromEventsSpy(api)).resolves.toEqual(eventPayload);
    mock.emit('event', eventPayload);
    await assertion;
  });

Второй вариант мне кажется намного чище, а вам?

Пишу тут тесты на vitest и обнаружил для себя пару новых приемов:

1. beforeEach и afterEach более не актуальны
Раньше я писал так

type TestCtx = {
   mock: Mock
}

describe<TestCtx>("Test", (ctx) => {
  beforeEach(async (ctx) => {
    const mock = await createMock();
    ctx.mock = mock;
    return async () => {
      await mock.destroy();
    }
  });

  it<TestCtx>("uses mock", async ({ mock }) => {
    mock.doSmth()
    expect(mock.getState).toBe(expectedState);
  });
 }

Теперь можно (а согласно документации даже нужно) вот так

const itWithCtx = test.extend({
  mock: async ({}, use) => {
    const mock = await createMock();
    // Все что до use - это beforeEach
    await use(mock);
    // Все что до после use - это afterEach
    await mock.destroy();
  }
})

itWithCtx("uses mock", async ({ mock }) => {
  mock.doSmth()
  expect(mock.getState).toBe(expectedState);
});

Интересный лайфхак - чтобы пошарить что-то всем iframe на любом уровне вложенности можно создать в корневом документе пустой iframe и добавлять все что нужно в него.

Целый день сегодня пытаюсь задебажить почему в моей fedora падают некоторые тесты.
Докопался до того что падает вот эта апи -
https://w3c.github.io/webdriver/#switch-to-frame

Она позволяет перейти в контекст iframe с родительской страницы.
Кто не в теме работает это так -

x = $('iframe') // аналог querySelector у webdriver
browser.switchToFrame(x)

В этот момент вэбдрайвер делает POST запрос к своему внутреннему серверу /session/{session_id}/frame с JSON который содержит какую-то айди которая очень похожа на поинтер.
а тот отвечает что такого нету с 400 ошибкой.

Сначала я думал это как то связано с wayland, но переключение на xorg ничего не изменило
Так как в CI тоже линух, теперь думаю а не из-за SELinux ли это

Статья про LLM компиляторы это прикольно, но насколько надо быть уверенным в своих тестах. Да, можно покрыть код на 100% тестами, но даже в этом случае мы знаем лишь то что наша программа корректна в известных нам кейсах (при условии что мы все тесты написали без ошибок). Эта ситуация потревожила мои воспоминания о лямбда кубе и AGDA.

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

Но чтобы решать на них практические задачи надо быть этаким одаренным математиком. А вот LLM возможно справилась бы с задачей выражения того что мы хотим сделать в форме математики. И на основе выводов компилятора который проверит все формулы - дать обратную связь о чем надо бы еще подумать.

ntfy.sh

Прилага показывает пуш уведомление, которое можно тригерить по http.

Применение придумайте сами.
(То что надо для моего esp32 проекта!)

Intel Arc Pro B50 16GB за $299 это вкусно

Intel Arc Pro B60 24GB за $500 это интересно

Project Battlematrix 192GB - за $5000 - сомнительно, но если вам очень надо запустить 70b модель локально, то это вариант.

Больше деталей тут

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

Вот только недавно IBM анонсировала что их новая модель Granite 4.0 tiny выдает хороший результат при весьма скромных запросах (целятся на то чтобы быть вашим домашним LLM для автокомплита), как сегодня я обнаруживаю что даже продавец лопат не смог пройти мимо.

Nvidia, та самая которая просьбы выложить драйвера или хотябы CUDA полностью в опенсорс игнорирует (так что у нас теперь есть целый зоопарк альтернатив - ZLUDA, SYCL, ROCm) взяла и опубликовала набор из трех OCR (Open Code Reasoning) Nemotron - 32, 14 и 7b (instructed вариант)

Пишут что делают упор именно на "instruction-following, reasoning, and multi-step code problem solving", для чего был собран специальный датасет. Здесь уже явно целятся на то чтобы быть аишкой под агенты.

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

Хватит боятся LLM

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

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

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

Я понимаю, что LLM может сделать меня эффективнее в общем. Да, где-то я могу просесть - по качеству или по менталочке 🙂 Но для конечного заказчика моей работы я раза в два полезнее при использовании LLM на максимуме.

Самое главное, АИшка пришла к нам в дружелюбном представлении чата и кому-то она может показаться живой или кто-то может ассоциировать такие свойства с ней, но это не так! Это просто инструмент - и это очень важно понимать.

Я вижу что так же как TypeScript лет 7 назад многие не хотели "покупать" потому что он не дает настоящую типобезопасность в рантайме, так же и сейчас не доверяют АИшке потому что она может подложить свинью там где ты этого не ждешь.
Но, я вас уверяю, с LLM можно достичь правила Парето и повысить свою эффективность.

По своему результату это просто очень быстрый, но очень тупой джун. Умение пользоваться АИшкой не сделает этого джуна умнее, в лучшем случае вы сможете получить как бы больше таких джунов (распараллелить работу). Но да, результат надо постоянно перепроверять.

При этом, если кто-то делает код или любой другой контент АИшкой и не перепроверяет его - это нормально! Это то же самое что отдать работу на аутсорс и не проверить результат - бывает. Все зависит от того каких целей вы хотите достичь - закрыть таску или закрыть ее хорошо. Зависит от контекста продукта, конечно.

Я это все к чему. Многие тригернулись на то что я признался (а мог бы не признаваться) что написал статью с АИ. Это необъективная предвзятость меня очень тревожит. Меня вообще тревожит не объективность 🙂 Никто не поинтересовался а с чем именно, в каком соотношении, мне помогла LLM. И это не правильно.
Статья хорошая вышла, я старался. Да, потратил раз в пять меньше времени на нее, чем если бы писал полностью сам, но это не о качестве статьи говорит, а о моих способностях. Да и не было бы никакой статьи без АИшки, а так есть, и лично я этому рад.

Redis 8 снова станет опенсорс.
Из интервью с СЕО редиса (Rowan Trollope) подчерпнул пару интересных моментов:

Роуэн говорит по сути о том что такие гиганты как Google Amazon и Microsoft перепродавали Redis (с модификациями?) как сервис за деньги, причем под своими брендами.
Т.е. нигде даже не упоминалось что это сделано на базе Redis. (так же упоминает что аналогичная проблема была у Elastic Search)

В результате перехода на другую лицензию удалось собрать денег с Microsoft, а Google и Amazon перешли на форк - valkey

Однако вместе с этим появились проблемы с тем чтобы найти новых клиентов, убедить их что "SSPL это тоже самое что Open Source" не получилось

And I was: ‘This isn’t working. Like, oh shit, what do we do now?’”

В итоге они перешли обратно на открытую лицензию, но на AGPL, который обязывает выкладывать весь код запускаемый на сервере в котором будет использоваться redis, потому что это лицензия "копилефт" (т.е. по сути распространяется на весь код в котором используется код редиса).
И они знают - в бигтехе есть внутренне правило избегать ПО с такими лицензиями

Всю суть происходящего лучше всего описывает вот эта фраза

“We really thought it through and said, ‘Actually, this makes sense.’ Because Amazon and Google have made their bed, we could adopt the AGPL license."

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

P.S. Интересно, как скоро Microsoft который купил лицуху на редис всего год назад, а теперь должен выложить весь серверный код ради того чтобы обновиться, перейдет на valkey

Зацените дизайн сайта Билла Гейтса. Одна только анимация погрузки изображений чего стоит
https://www.gatesnotes.com/home/home-page-topic/reader/microsoft-original-source-code

знаете че такое GDPR? Это когда вас мучают распросами про печенье, да? А что такое TCF и CMP?

Давайте быстренько расскажу а потом будет история из практики.

TCF (Transparency and Consent Framework) - это такой стандарт функции управления согласием XD. Короче, спека как спрашивать про куки и что хранить.
Этот стандарт касается только европы, а так то их много разных (IAB CCPA CF, Google CM, Adobe EPCM, DAA Adchoices, CNIL, ISO/IEC 29184:2020 и тп. кто во что гаразд)

CMP - Consent Management Platform. Это программная обертка вокруг стандарта. Ну чтобы можно было просто дергать методы а оно там само все по стандарту оформлялось и хранилось.
Причем одна CMP может внутри реализовать n TCF. Таких оберток естессно тоже на целый зоопарк.

Все это приправлено драконовскими законами со штрафами до 20 миллионов евро, или 4% годовой прибыли например.

И просто взять и написать свой CMP нельзя - его надо написать по спеке, пройти регистрацию, получить айди. Что-то вроде лицензирования.

Теперь когда вы в курсе че как, ситуация - в мобильном приложении мобильный CMP, внутри него есть вебвью где открывается спа (предназначенная так же и для открытия просто в вэбе) где тоже есть свой CMP.
Разработчики мобилки решили что это тупо два раза спрашивать пользователя и не грузят в вэбвью Js-овский CMP, а одна из SDK пытается его найти в window.
Как я понимаю у них там какая-то жесткая изоляция вэбвью так что они мне только через урл могут пробросить TCF (список того на что согласен юзер), а мне надо притворится CMP для SDK и ответить согласно этой строке, т.е. реализовать один метод.

Но так нельзя, помните я говорил про то что надо лицензию получить на своё CMP решение? Вот такая засада

Загадка:

Есть вот такой вот тест

import { beforeEach, describe, expect, test, vi } from 'vitest';

interface TestCTX {
  storage: MockStore;
}

class MockStore {
  kv = new Map();

  async writeKVPair(key: string, value: string) {
    this.kv.set(key, value);
  }

  async readValue(key: string) {
    return this.kv.get(key);
  }

  dump(): Record<string, string> {
    return Object.fromEntries(this.kv);
  }
}

describe('Check command "update"', { sequential: true, concurrent: false }, () => {
  beforeEach<TestCTX>(async (ctx) => {
    const storage = new MockStore();
    vi.doMock('./storage', () => ({ storage }));
    ctx.storage = storage;
  });

  test<TestCTX>('Report saved', async (ctx) => {
    const { updateCommand } = await import('./update');
    await updateCommand('foo');
    const result = ctx.storage.dump();
    expect(Object.keys(result).length).toEqual(1);
  });

  test<TestCTX>('Report save value', async (ctx) => {
    const { updateCommand } = await import('./update');
    await updateCommand('bar');
    const result = ctx.storage.dump();
    const firstValue = Object.values(result)[0];
    expect(firstValue).toEqual('bar');
  });
});

Запускаешь только первый или только второй тест он проходит, а сразу два - всегда падаeт второй тест - он получает result === undefined
Почему?



Ответ:
Если вы замокали модуль в beforeEach это еще не значит что ваш код будет в эти моки ходить. И ESM и CommonJs не грузят модуль каждый раз когда он импортирован, инстанцируют его один раз, а потом кладут в кэш.
Поэтому не смотря на то что модуль мокается перед каждым тестом - все тесты будут использовать только первый мок.

Чтобы этого избежать - нужно вызвать vi.resetModules() перед каждым vi.doMock()

В Zed можно запускать тесты вот такой кнопулчекой напротив его названия.
Однако по умолчанию zed попытается запустить их с помощью встроенного jest-a

Вот только jest остался лишь в моих кошмарных снах, я давно уже на vitest, и как же мне заставить zed использовать его.

Достаточно просто если знать что делать:
1) F1 -> zed: open project tasks (иди без project если вы хотите сделать таску глобальной)

2) добавьте в json массив следующее

{
    "label": "Run Vitest",
    "command": "npx vitest run",
    "tags": [
      "ts-test",
      "js-test",
      "tsx-test"
    ],
    "args": [
      "\"$ZED_RELATIVE_FILE\" -t=\"$ZED_SYMBOL\""
    ],
    "shell": "system"
  }

3. Перезапустите zed

Это необходимый минимум чтобы vitest заработал.

А вообще там много чего можно настроить, полный файл конфига таски с комментариями ищите в первом сообщении под этим постом