Обновление 8.0 Insomnia полуилось просто сокрушительным. Сокрушительным как с точки зрения юзабилити, так и с точки зрения репутационных потерь.

Что произошло? Внезапно для пользователей после обновления оказался потерянным доступ к трудовым потом накопленным коллекциям. Также появилось обязательность логинится в аккаунт приложения. Последнее принудительно переводило юзеров в облачнуюю insomnia. Не было никаких предупреждений, не было возможности экспортнуть куда-то свои коллекции.

Я этой участи избежала, потому что я очень не люблю обновляться. И логиниться тоже не люблю. Моя лень оказалась моим спасением.

Для интересующихся: начальный тикет

Как вы можете догадаться после этого пошли дизлайки и отписки (от платных аккаунтов).
Баг превратился в обсуждение. Где-то к концу дня выкатили уже insomnia 8.1 с фиксами проблем экспорта коллекций. И объяснения, что это вообще было.
Long story short меняли архитектуру для интеграций (я это так поняла вот отсюда). Наверно, еще от легаси избавились 🥲

С версии 8.0 вместо возможности держать локально n разных проектов, внутри которых может быть m разных коллекций запросов, появляется scratch pad - local only mode. Судя по скрину, если говорить в старых терминах, остается только 1 коллекция для локального хранения.
You can easily create an Insomnia account for free and then import their Scratch Pad collection into a regular project - подойдет ли этот вариант для меня лично? Нужно пробовать и смотреть (но я ленивый скептик).

Что дальше?
С одной стороны, необновленый клиент меня устраивает и переходить на, допустим, postman я все еще не готова. Ладно, я вообще не готова возвращаться на постман. С другой стороны, возможно, что это время для поиска альтернативного клиента для отправки api запросов, который бы также удовлетворял меня по своим фичам.

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

Я снова про Insomnia.
За прошедшее время (4 дня что ли) уже появился форк билда 2023.5.8, последнего до выхода 8.0. Называется это все Insomnium. Билд немного подчистили, убрали авторизацию.
I still think Insomnia is a nice product in general, but I have to disagree with the direction it is going.
Мне кажется, что это выражение недовольства здорового человека.

А уже сегодня, менее часа назад, появилось объявление о новом билде 8.3. В объявлении немного извиняются, а потом обещают добавить Local Vault - пока что это выглядит как полный аналог того, что было в 2023.5.8. Но использование потребует регистрации.
I am not going to lie: this introduces a large amount of complexity in the application that we wanted to remove (which was one of the motivators to only support E2EE cloud projects moving forward, getting rid of all of that codebase), but we will make it work by allocating more resources to it.

Еще я не очень поняла, откуда в тексте внезапно появляется упоминание версии 9.х, в которой обещают простую конвертацию локальных проектов в Local Vault
You will be able to update to Insomnia 9.x and convert the projects you would like to use locally by right-clicking on them and "Convert project to Local Vault"
Но может быть это опечатка.

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

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

И конечно тебе надо уметь объяснить другим людям, что и зачем мы делаем (по крайней мере в европейских компаниях, в США читала, что можно меньше объяснять). И как мы собрались это делать, если плохо владеем основным языком коммуникации. Вопрос.

Не, вообще я согласна. И добавить нечего.
Остается только ныть, что отбирают у меня профессию. Хнык.
Слава богам, что большая часть программистов по разным причинам действуют по принципу «хуяк-хуяк».

Про тестирование и разрабов (это музыка будет вечной)
На неделе про юнит-тесты я писал, что само по себе разделение ролей и провоцирует вопросы про то, кто пишет тесты.
И вот аналогичное мнение:
“Наличие выделенных SDET (ака Software Development Engineer in Test) сделало для разработчиков доступной заманчивую возможность передать написание модульных тестов на аутсорсинг. Без команды SDET вопрос о том, кто пишет модульные тесты, не стал бы предметом обсуждения: нам, разработчикам, пришлось бы их писать”... “Формально команда состояла из 6 SDE (ака Software Development Engineer) и 3 SDET. На самом деле нас было 9 SDE, благодаря инженерному менеджеру и руководителю тестирования, которые незаметно решили, что нет смысла выделять специальную роль тестировщика, когда мы каждый день выпускаем новые функции.”

И тут другой инсайт: релизный процесс (его частота, вид продукта: SaaS с деплоями раз в минуту или коробка наружу обмазанная сертификацией) тоже драйвит убирать узкие горлышки, мешающие скорости разработки не теряя при этом в качестве, с учетом тестовой стратегии, где скорость отката сбойнувшего изменения важнее “отполированного” ручными тестировщиками продукта.
Картинка там тоже интересная (закинул в комменты, про соотношение типов тестов в зависимости от того, кто их пишет).
Ну и чтобы вы не думали, что такое мнение редкость, вот уважаемый мной Алан Пейдж
“Мне говорят, что «у разработчиков нет времени на тестирование» или что лучше потратить время на разработку программного обеспечения, чтобы его могли тестировать эксперты. (😂 мне тоже так постоянно все говорят)
Странно.
...Тестирование не является отдельной деятельностью от разработки — тестирование является частью разработки. Сказать, что у разработчиков нет «времени» на тестирование, — это все равно, что шеф-повар говорит, что у него нет времени пробовать свои творения. Его также часто называют безработным поваром."

Итого: пока (надо еще поварить это в голове) я согласен с выделением "нагрузочников" в отдельную роль, но "автоматизаторы" - это рудимент. Автоматизировать проверки должны разработчики.

#unit_testing #test_automation #testing

С одной стороны, я немного шокирована, когда вижу такие вещи от продакта приложения.
С другой стороны, % людей, которые любят \ верят в таро, предсказания, гороскопы Очень Большой. Так что логично, что там есть продакты \ фаундеры \ продюссеры. Логично что кто-то из них захочет сделать про это все приложение. И логично, что если апку сделать хорошо, то оно взлетит.

Но легче мне от этого не становится.

- добрый день, вы знаете что-нибудь про верстку под мобайл?
- нет
- отлично, вы нам подходите!


На скрине дропдаун меню, которое раскрыто по умолчанию и элементы его не активны

Ура! Advent of Code начался!
Для меня это не про занять перво место, а про попробовать новые штуки, посмотреть стала ли я лучше за прошедший год.
Пока начну на питончике, но мб стоит для разнообразия потом взять котлин или го 🤔

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

https://ex-lensa.team/

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

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

uncommon: добавляем агенду или хотя бы краткое описание.
Внезапная встреча 1-on-1 с лидом принесет человеку достаточно много стресса. Если в описании будет указано "обсуждение развития в следующем году", то стресса будет меньше, коллега сразу узнает, что это не митинг про то, как плохо он работает, и что его сократят.

rare: новая встреча не должна накладываться на другие миты участников (и на вашими тоже).

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

legendary: не ставьте встречи вплотную. Еще лучше сделать зазор в минут 10, если расписание позволяет. Люди скорее всего будут меньше опаздывать к началу. Небольшой гэп, не только даст время на смену контекста, но и позволит покурить, сделать чай \ кофе, сходить в туалет, в конце концов.

Вот это я щас сгорела. С другой стороны я подгораю от каждого чиха.

Тем временем тема где хранить автоматизацию, как ее делать (фреймворк в отдельной репе или тесты и фрреймворк в одной) - это хороший вопрос обсудить на собесе. И не можешь ты сказать, вот так делать надо всегда и в любом случае. Т.к. это заявзано на достаточно много вещей: как на проекте устроен ci\cd, какая архитектура, сколько у вас людей занимается автоматизацией и кто это.

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

Best Practices по ходу такие, какой уровень в индустрии.

Напишу себе, чтобы не забывать:
pytest умеет переименовывать названия параметризованных тестов не только через проставление фиксированных названий в параметр ids.

@pytest.mark.parametrize("param", [1, 2, 3], ids=["first", "second", "third"]
def test(param):
    pass

Но и использовать входные данные, если структура сложная.

def idfn(val):
    return val["value"]

@pytest.mark.parametrize("param", [{"value": "first"}, {"value": "second"}, {"value": "third"}], ids=idfn)

Читать документацию, когда она есть, это вещь полезная!

В рамках самообучения попробовала сегодня написать два текста на английском по такой схеме:
- сначала в граммарли (чтобы бесплатно проверить на фигню)
- загнать с запросом в чатГПТ (чтобы сформировать более native фразы да и просто менее канцелярские)
- смержить два текста в один.

Очень интересно и увлекательно. Правда, не ясно остается ли что-то у меня в голове.

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

Long story short: выбор языка дело простое, быстрое, но там куча связных параметров.

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

Типа если вы хотите реализовывать GUI web автоматизацию и вы хотите кроссбраузерность, не стоит брать фреймфорк, который из коробки работает только в chrome. А потом пытаться натягивать сову на глобус.

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

Может оказаться, что если автоматизация нужна вчера в обед хоть в каком-то виде, то подойдет и фреймворк с накликиванием. А потом будет время, чтоб переделывать нормально.

Я видела когда язык автоматизацией был языком фронтенда, бекенда, третьей интересной опцией. Как фреймворки и языки тестов менялись буквально за год.

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

AirSerbia, у вас там все в порядке???

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

Что еще раз подтверждает тезис: AI максимальную пользу приносят "синьорам".

И еще вот что думаю: нейронка обучается на актуальном коде, качество кода стало ниже (по определенным критериям), качество предложений нейронки тоже будет ухудшаться.

https://twitter.com/milan_milanovic/status/1756952644642300282?t=1gbiqpt8dGvf9MPve4vyYg&s=19

Сохранила для реальных тестовых данных. Вдруг пригодится когда-нибудь. Можно увидеть, что на скрине слева полное ФИО не влезает в строку.

А то у меня пока только есть в таких двойное имя: Лина-Александра

Дополнение у твита достаточно грустное, если что.

Я щас с ума сойду просто. Что это за магия вуду.
Спасибо, конечно, за то, что видно, что денег за это не спишут.

Каким-то сложными путями дошла до linear.app - это новый модный таск трекер для проектов с кучей интеграций (github, gitlab, figma, slack, discord, zendesk), AI (куда без него), синхронизацией с другими аналогичными вещами (jira, asana, github projects).
Обещают быстро - модно - молодежно.
Попробую потыкать в общем. Мб это мне пригодится.

С одной стороны, очень симпатично и удобно. С другой стороны, из моего микро проекта на гитхабе туда подтянулась 1 открытая issue из 3. Из проекта для репозитория подтянулось только название 🥲