Напиши поздравление, как будто бы тебе не все равно. Поздравь от души всех участников канала. Пожелай успехов и процветания! Обязательно сделай акцент на том, что за ИИ будущее, но людей оно не заменит.
Тон должен быть добрый, но немного саркастичный.
Не пиши банально. Сделай креативно. В конце поставить смайлик не забудь 🍻

Жидкие мыслишки

Смотрю я на новый дизайн Telegram (и не только) и пытаюсь осознать это "жидкое стекло", принять весь ужас происходящих изменений. Уже пару дней перевариваю — вот несколько мыслей по этому поводу:

1. Интерфейс стал мусорным и нагромождённым.
2. Окно полезной информации визуально сократилось очень сильно. Не знаю насколько в процентах, но если я это заметил — значит, эффект ощутимый.
3. Все годы, потраченные на отработку моторной памяти, пошли лесом.
4. Акценты смещены с полезного контента на бесполезный шум: закрепы, действия, даты, табы и прочее.

И это всего лишь моё имхо. Уверен, профессиональные дизайнеры видят проблем гораздо больше.

Но есть вещи, которые волнуют меня сильнее, чем само неприятие изменений.

- Это явно (имхо) провальная концепция, но она с нами на некоторое количество лет. А значит, нас ждёт тонна занимательного чтива и видеоконтента, где будут объяснять, почему это революция и почему это "очень-очень круто".
- Насколько я понимаю, с февраля "жидкое стекло" становится обязательным требованием в App Store. Следовательно, куча приложений будет обязана затащить его в ближайших апдейтах.
- Эта балалайка неизбежно просочится в веб. Удивительно, что ещё нет. А значит, будет массовое помешательство на плавающих элементах и абсолютном/фиксированном позиционировании. Крайне интересно посмотреть, как это поломает отработанный годами адаптив.
- И вот когда до людей, принимающих решения и имеющих влияние, наконец дойдёт, что это какие-то грибы, начнётся эпичное переобувание в воздухе. Попкорн стоит закупать заранее — прогнозирую рост спроса.

Почему мне кажется, что я не ошибаюсь:

- Есть занятное чтиво: https://vintageapple.org/inside_r/pdf/Human_Interface_Guidelines_1992.pdf
- Именно на основе этого гайдлайна Apple сделали свои интерфейсы великими и до сих пор каким-то образом умудряются оставаться удобными — просто потому, что ещё не всё окончательно сломали.
- Этот гайдлайн вообще не про шейдеры и визуальные красотульки. Он в первую очередь про пользовательский опыт. Я хорошо помню старые ОС, где интерфейс ощущался как продолжение моих мыслей и потребностей, а не как заросли терновника, через которые нужно продираться.
- К своему стыду, я прочитал этот гайд только в этом году. Но почти уверен: огромное количество разработчиков, а к сожалению и дизайнеров, его даже не открывали. Отсюда и попытки изобретать велосипеды и самокаты там, где давно проложены надёжные рельсы.
- Кадровые перестановки, и в частности уход главного вредителя из Apple, дают надежду на частичный откат к заветам предков. Хотя, по-хорошему, здесь должны сработать обратная связь и здравый смысл. Но репутация не позволит включить заднюю с хрустом быстро. В итоге нас ждёт застой лет на 3–5 в этом ужасном состоянии. Но скриньте пост: нас ждут 100% "старые добрые инновации" и отказ от этого решения в будущем.

Общие мысли про юзабилити:

- С повсеместным внедрением ИИ-автоматизации и изменением общей концепции взаимодействия с информацией нам действительно, возможно, придётся переизобретать подходы к вводу данных и коммуникации с интерфейсами. Но базовые принципы никуда не денутся до тех пор, пока не случатся массовые драматические изменения вроде нейроинтерфейсов или чего-то за пределами стандартных органов чувств.
- Стремление к минимализму и упрощению гораздо более здравое и органичное для человека, чем его гиперболизация. Именно поэтому идеи скевоморфизма проиграли плоскому дизайну. При этом терминальные интерфейсы раз за разом набирают адептов. Куда уж проще? А ничего идеальнее чистого монотонного листа бумаги человечество так и не придумало. Есть, конечно, арт-картон, бланки с вензелями и виньетками, но это уже совсем другая история.


Что делать и как с этим бороться:

- Никак. Разве что читать толковые гайдлайны умных дядей из прошлого и учиться на их знаниях и ошибках.
- Делать собственные продукты не по веяниям моды, а по базовым ценностям и проверенным правилам.
- Смириться с тем, что каждому поколению нужны свои грабли. У нас, если что, тоже была Windows Vista.

"My priority is shipping fast, not learning."

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

1. Быстро ≠ вовремя. На короткой дистанции выигрывает тот, кто быстрее — с этим сложно спорить. Но тут уместно вспомнить парадокс Ахиллеса и черепахи. Если черепаха изначально впереди, Ахиллес может быть сколь угодно быстрым, но все время будет догонять, а не обгонять. В реальной жизни это отлично ложится на хайп-гонки. Проблема не в том, что кто-то бежит медленно. Проблема в том, что он стартует позже. Поэтому важно не быстро прыгать в хайп, а оказаться в нем до того, как по нему сойдут с ума все остальные. Есть и контр примеры. Но они "про тех, кто выжил" и не являются массовым явлением. Мой личный триггер — бесконечные переобувания между Next.js, Hono + Vite SPA, TanStack Start и прочими комбинациями. Это замкнутая экосистема контента: миграция ради миграции, каждый месяц новый "убийца", каждый квартал новые причины переписать все заново. При этом проблема почти никогда не в конкретном фреймворке. Она в том, что стек выбирается без понимания задачи и ее реальных ограничений. JS-фреймворки по своей природе компромиссны. Иногда этот компромисс оправдан, иногда — нет. Но вместо того чтобы признать ошибку на уровне подхода, люди продолжают чинить скорость поставки, прыгая из одного решения в другое и купируя симптомы до следующего круга. В это время те, кто вдумчиво и системно разбирается с фундаментом, выглядят как черепахи. Зато на длинной дистанции именно они оказываются впереди, и ахиллесам их уже не догнать.

2. Иллюзия скорости за счет незнания. Есть популярная идея, что на иностранном языке нужно начинать говорить с первого дня, забив на грамматику и правила. В бытовых сценариях это работает. Купить пиво в магазине, объясниться в аптеке — без проблем. А вот устроиться на работу и общаться с коллегами на одном уровне — уже нет. Там потолок достигается очень быстро. С технологиями та же история. Не всем нужно глубоко разбираться в базах данных или архитектуре систем. Кому-то достаточно шапочного понимания, как устроены таблички в SQLite, и этого действительно хватает. Проблема начинается тогда, когда при первом же усложнении требований следует прыжок на Postgres или что-нибудь еще с аргументом "нам нужно быстрее доставлять ценность". В большинстве таких случаев причина не в технологии, а в отсутствии базы на старте. Нормально спроектированный фундамент редко замедляет delivery, но почти всегда экономит время позже. Иллюзия скорости возникает ровно тогда, когда сложность просто откладывают.

3. Имитация навыка вместо навыка. С гитарой все совсем наглядно. За вечер можно научить человека зажимать аккорды и теребить струны. Скорее всего, в итоге он сыграет какого-нибудь Цоя на лавочке и даже впечатлит бабушку. Современных девочек, правда, вряд ли. Формально — он играет. По факту — нет. Навык появляется не от повторения движений, а от понимания, что и зачем ты делаешь. В разработке это работает ровно так же. Поверхностное освоение дает быстрый старт и ощущение прогресса, но не дает контроля над результатом. Пока все укладывается в шаблон — все ок. Как только возникает нетиповая ситуация, "shipping fast" заканчивается мгновенно. ⤵️

Проснулся сегодня поздно. Разбитый: пол-ночи что-то делал, кодил. Открываю ноут, а у меня поверх всех окон — вот эта штука.

Первая мысль — ну вот… вайбкод-вирусы подъехали. Вторая мысль — а как это они в режиме сна что-то сделать смогли? Третья мысль — стоп, это же, вроде бы, Loop — туловина моя для организации работы с окнами.

И тут меня как порвёт багет.

Худшее, просто самое ужасное, что может сделать софт, — это начать себя навязывать. Я как-нибудь сам разберусь, когда мне тебя обновить, когда тебя настроить, продлить подписку и так далее. Компьютер вообще без моего участия ничего делать сам не должен. Chrome в этом плане вообще пробил все возможные днища. Но это Google — там понятно, что отсутствие принципов и здравого смысла является частью корпоративной культуры. Но вы же маленькая софтинка, делающая идеально всего одно действие. Ну что это такое?

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

Короче, если вы пишете какое-то приложеньице и думаете, а не сделать ли мне систему автообновлений, — НЕТ. Не делайте. Даже не вздумайте. Если пользователю будет надо — обновит сам. Всё. Точка.

Сел я тут бухтеть на тайм-трекинг. Написал увесистый пост. Потом решил — пусть ии покритикует. Кстати, хорошая практика.
Пока меня притягивали за слова и ловили на неточностях, внезапно оформились два тезиса. По сути, они и есть всё, что я хотел сказать.

Если организация не умеет в целеполагание, она всегда скатывается к суррогатным метрикам.

И второй:

Результат всегда нужен собственнику.

Для исполнителя результат — абстракция, если он:
• не влияет на деньги
• не влияет на автономию
• не влияет на статус

После этого писать отдельный пост про тайм-трекинг внезапно расхотелось.
Но возник вопрос.

В Германии тайм-трекинг теперь повсеместный. Закон теперь такой... Формально — защита от неоплаченных переработок. Логика понятна. Реализация — спорная. Но ок, приняли как есть.

А у вас как?
Кризис принёс трекинг? Или он был и раньше?
Как вообще к нему относитесь — как к защите, контролю или управленческому костылю?

Написал самого лучшего cli агента. Вот теперь все полетит как надо!

Dock

Сидел сегодня обновлял всякое и подумал – а зачем мне вообще нужен Dock? Ну т.е. он и так у меня скрыт по умолчанию всегда, но частенько вылезает когда по нижней части экрана мышкой елозишь. Я подумал и понял, что последний раз когда им пользовался – это было восстановление окна, которое свернул случайно и не смог вернуть обратно через шоткаты. Но это было так давно, что кейс один раз на миллион часов. А в остальном он просто мне глаза переодически мазолит.

Поискал хаки всякие и вот что нарыл.

defaults write com.apple.dock autohide-delay -float 10
defaults write com.apple.dock autohide-time-modifier -float 0
killall Dock

Это сделает открытие дока практически невозможным при наведении мышки на край экрана. Число 10 – это вроде как секунды, и вот за 10 секунд док у меня не вылазит уже случайно совсем. Можете поиграться с значением, 3-5 вполне себе делают возможным его появление, поэтому я поднял повыше, чтоб уж наверняка. Можно задрать и до 1000 и больше, но такие таймауты – это всегда черевато какими-нибудь утечками где-нибудь. 10 секунд не приведут ни к чему плохому.

Если что вернуть обратно так:

defaults delete com.apple.dock autohide-delay
defaults delete com.apple.dock autohide-time-modifier
killall Dock

Что делать если таки скрыл или свернул приложение в док? Через ⌘-Tab оно обратно не вернется уже. Но есть дефолтный шоткат Control + ↑ (там еще кнопка есть под него отдельная в Fn клавишах и жест, но я как-то по старинке привык уже к шоткату), в этом режиме (mission control вроде называется) док будет показан по умолчанию. Ну и часто можно просто через spotlight вернуть скрытый экран обратно, набрав название приложения (этим я и пользуюсь, если сверну случайно).

Итог: во время работы ничего не мельтишит, хуже не стало, функциональность сохранена. Красота, нраица!

Дженсен Хуанг давеча сказал: "Задача инженера — решать проблемы, а не кодить. Я хочу, чтобы программисты вообще не писали код".

В это же время Sonatype отчитались: "При анализе 576 000 образцов кода на Python и JavaScript было выявлено 205 474 уникальных примера галлюцинированных имён пакетов". А IndonesianFoods сгенерировала более 100 000 вредоносных npm-пакетов со скоростью один пакет каждые семь секунд для эксплуатации протокола вознаграждений блокчейна.

Кто не понял: собрал ты лендос с формой регистрации через LLM, но либа оказалась не оригинальная, а с галлюцинацией в нейминге пакета. При этом пакет существует — потому что фишинг. Пакет делает всё то же самое, что и оригинал, просто вдобавок содержит эксплойт. И вот все твои регистрационные данные утекают сквозь пальцы с самого начала.

Может случиться и хуже: запилил сервис с парой-тройкой таких пакетов — и пригласил мамкиных хакеров во внутренний контур компании. И самое неприятное: даже если ты всё проверил в прямых зависимостях, зависимости зависимостей могут оказаться с такой "свиньёй". Или в свежем апдейте продукта, который вы себе установили, может быть допущена такая уязвимость. В случае с OSS, особенно непопулярным, это крайне вероятно. И вот какой-нибудь условный корпоративный опенсорсный чатик или система разбора логов уже приглашают вас на эшафот.

Я уж не знаю, какие проблемы будет решать инженер в NVIDIA в будущем, но с вероятностью больше 90% всем остальным в этом году стоит прокачивать скиллы в кибербезе и обеспечении безопасной разработки.

Начните с малого. Ограничьте ИИ в выборе технологий и не доверяйте ему выбор зависимостей. Управляйте стеком и валидируйте зависимости сами. Прикрутите к CI все возможные чекеры безопасности. Не обновляйте зависимости вслепую в день релиза. Звучит как то, что и так надо было делать. Но мы же знаем, что почти никто этого не делал — или делал спустя рукава.

Не торопитесь обновлять self-hosted-решения и внимательно следите за changelog’ами и закрытием уязвимостей. Настройте внешние сканеры. Закройте всё от внешнего мира по возможности и следите за логами и активностями в открытых системах.

Если пишете что-то критичное, подумайте, как реализовать это всё только в рамках стандартной библиотеки языка. Звучит как ересь, но такие практики были и раньше. Сейчас они просто обретают прагматичный смысл — чтобы не вляпаться на ровном месте. Думаю, GitHub, pip, npm и остальные, конечно, попытаются что-то с этим сделать, но это как пытаться ссать против ветра. Один хрен последствия будут. И лучше бы подумать о них заранее.

Хотя кого я обманываю: кэш пакетов и проверку их на безопасность сделают единицы, да и те для галочки, а остальные иконки на монитор приклеят в лучшем случае — и авось пронесёт.

Программист, который больше не программирует

Знакомая история: появляется бытовая задача — прикинуть бюджет, спланировать покупку, посчитать денежные потоки. Раньше — блокнот или максимум экселька. Теперь — LLM и через неё полноценное микро-приложение. С логикой, с интерфейсом.

Казалось бы — круто же? Продуктивность в разы выше. Но внутри какое-то странное ощущение. Как будто тебя немного наёбывают. Или ты сам себя наёбываешь.

Что не так с быстрым дофамином
Помнишь момент, когда только научился программировать? Появлялась задачка — и ты садился автоматизировать. Писал скриптик, пыхтел, ресёрчил, ломал голову. Даже если задача была мелкой — был процесс. Решение становилось лучше итерация за итерацией. Ты физически чувствовал, как прокачиваешься.
С LLM этого нет. Можно потратить пару дней на то, чтобы собрать архитектуру в голове — но само решение появляется почти из воздуха. Нет момента, когда оно работает всё лучше и лучше. Оно просто — работает. Сразу. И это ощущается как очень быстрый дофамин. Приятно, но пусто.

Смена роли, которую не замечаешь
А дело вот в чём. Ты незаметно для себя сменил роль. Перешёл из создателей — в заказчики.
Вспомни, как это выглядит со стороны бизнеса. Владельцу нужна программа. Он видит задачу, идёт к программисту, объясняет что нужно. Программист уходит, проходит N времени — появляется решение. Для владельца оно всегда было именно так: оно не "создавалось" — оно просто появилось. Просто работает.
Теперь ты сам стал этим владельцем. Приходишь к LLM с хотелкой, объясняешь задачу — раз, два, три действия — и получаешь готовый инструмент.

Три вещи, которые изменились

1. У тебя появились "программисты". Ты больше не единственный исполнитель. Есть кому делегировать — и ты автоматически сдвинулся в роль того, кто ставит задачи, а не решает их руками.

2. Эти "программисты" нечеловечески быстрые. Когда нанимаешь живого разработчика, между заказом и результатом проходят дни, недели. Успеваешь привыкнуть к ожиданию. А тут результат — через минуты. Мозг не успевает перестроиться, и это ощущается как читерство.
Когнитивное искажение от подмены понятий.

3. Это всё ещё ТЫ. Это всё ещё ТВОЙ код. Ты формулировал задачу, принимал архитектурные решения, ревьюил результат. Но руками не писал. И мозг программиста буксует — потому что раньше "сделал" значило "написал код", а теперь "сделал" значит что-то другое.

А теперь неприятная часть
Все, кто работал с живыми программистами, знают: бывает, нанимаешь человека — и он сжигает бюджет в никуда. Неделями. Месяцами. Годами. Пишет хреновый код, который становится легаси еще до запуска в продакшен, решает не ту задачу, уходит в архитектурные дебри, кормит завтраками и т.д.
С LLM — ровно та же история. Только вместо зарплат сгорают токены и лимиты. Скармливаешь контекст, гоняешь промпты, получаешь на выходе красивое, но бесполезное решение. Или правильное решение не той задачи.

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

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

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

Вчера была хрестоматийная ситуация. Вышел миллионный контекст для Opus, и, конечно, было интересно проверить, как он с ним работает. Появилась задача — как сформировать 1М контекста на вход модели так, чтобы от этого была польза? Я не придумал ничего умнее, чем собрать все файлы проекта в один промпт и скормить LLM на анализ под конкретное действие.

Да, можно отгрепать и склеить всё это дело в терминале, я понимаю. Но я задался вопросом — а есть ли готовый тул под эту задачу? И да, он есть. Называется Better Prompt, ссылки не будет — тул платный и бесполезный. Бесполезный потому, что бесплатный лимит стоит на 35k токенов сборки промпта из файлов. Платить $14 за то, что я могу через awk, grep, sed и пару шайтан-пайплайнов сделать сам — нет уж, увольте.

Но зато это была отличная площадка попробовать собрать себе такой тул. Я сел, написал задачу, приложил скриншоты и описание флоу, которое хочу получить, пояснил за стек — нативный macOS-апп, без всяких питонов, JS-ов и прочего. И запустил в плавание. Задача несложная, напоминаю. Но в ней есть ценность: она должна быть сделана не только для программистов, но и для людей, которые не умеют в терминал. Через буквально 10 минут у меня была аппка, которая решала все задачи — умела фильтровать, частично выделять, наглядно считать токенизацию и полностью закрывала мои потребности. Кайф? Кайф!

Я посмотрел на свой набор приложений, которыми пользуюсь и которые написал себе за последний год (и оставил в использовании), и понял — пора. Потратив ещё какое-то количество времени на написание базовых промптов и пояснений модели о великой глобальной цели, которую я себе придумал, я родил свой локальный инди-опенсорс из молоточков, которые можно спокойно нативно использовать. Сорсы все открыты — там буквально нечего было прятать итак, а LLM их все разгрызла за час вчера и полчаса сегодня. Вероятно я что-то по ходу дела буду фиксить, но возможность отказаться от Better Shot, CleanShot, Loop или ChatGPT для коррекции моего кривого английского — это звучит и выглядит просто восхитительно.

В итоге у меня в обойме следующие молоточки:
idler — штука, которая хакает корп-политики и не даёт ноуту засыпать или менять статус в корп-мессенджере на away, если я чешу голову в раздумьях дольше, чем разрешено.
AI Status Monitor — простейший топ-бар-апп, который показывает текущий статус инцидентов Anthropic и OpenAI. Удобно понимать, что пора пойти попить кофе или сходить в магазин, потому что началась деградация и мучить дальше LLM-ки смысла нет.
SWM (Simple Window Manager) — оставил только то, чем реально пользуюсь: шоткаты для перемещения окон по экрану так, как мне удобно. Плюс исправил досадный баг, который раздражал в Loop при перемещении окон между мониторами.
AI Rephrase — штука, которая раньше решалась через GPT или Claude, а теперь решается шоткатом и локально. Написал кусок текста на буржуйском, нужно подправить, чтоб читалось лучше — жмяк шоткат, пару секунд размышлений в Gemma, и готово. Можно юзать встроенный Apple Intelligence, но он тупой, фолзит и брыкается. Мне не понравилось. Ну и есть история этих перефразирований, так как мне полезно порой подтянуть язык или поискать, как было в оригнале мной написано.
Simple Shot — идея витала давно, но было лень. Маковская скриншотилка устраивает на все 100%. Но раз в год мне надо снять скриншот и подставить фон или пронумеровать что-то на скрине. И начинаются неудобства. Есть бесплатные и платные тулы, но в них слишком дохрена всего. Этот молоточек делает только то, что делает: берёт картинку из буфера обмена после стандартного скриншота, обрамляет её фоном и даёт возможность аннотировать. Идеально.


В связи с этим решил я их все опубликовать и сделать нормально устанавливаемыми. Взять можно по ссылкам выше или посмотреть на все тут: malikov.tech.

А мораль простая. Прав был Сэм и остальные. Пока, конечно, это всё только про что-то маленькое (шароварное). Но есть у меня один проект в процессе приготовления, который печётся по той же модели, но заменяет полноценный огромный SaaS. Если выгорит и получится — расскажу. Но там, конечно, не за 10 минут результат достигается.

Как продолжение прошлого поста — решил попробовать сгенерировать не очередную игрушку, а что-то реально сложное. Полноценный секвенсор (DAW) под свои задачи. Не потому что мне нужен новый DAW или меня не устраивает текущий. Просто я никогда не работал со звуком и никогда не писал настолько сложный десктопный софт. А значит, это хороший тест: чужая предметная область, куча неизвестных, ноль нормальной насмотренности.

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

Под macOS, к счастью, можно сильно срезать углы. Системная аудиоподсистема позволяет свалить на неё большой кусок работы — микширование, плагины и прочее. Да, ценой того, что вместо VST остаётся AudioUnit. Но зато не нужно тащить C-биндинги и лезть в низкоуровневую грязь. Можно остаться в Swift и бить сразу в функциональность.

С виртуальными инструментами всё более-менее понятно. Но там почти сразу всплывает MIDI-редактор, а это уже отдельная чёрная дыра. Если делать его нормально, это сам по себе проект.
И это даже не самая большая проблема. Самая большая — понять, как вообще собирать очередь обработки и воспроизведения на таймлайне так, чтобы всё это не убивало производительность.

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

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

Сейчас у меня уже есть рабочая демка, вполне похожая на настоящий DAW. И это, пожалуй, самое интересное. Потому что появилась она буквально за считаные часы. Причём это не просто "записал дорожку — проиграл дорожку" , а уже редактор: MIDI, автоматизации, шины, микширование, минимальная гигиена — всё на месте.
Понятно, что любой коммерческий DAW лучше и по UX, и по визуалу, и по производительности. Но тут и сравнение смешное: Logic, Reaper, Bitwig, Cubase делались годами, пережили кучу версий, за ними стоят большие команды и миллионы вложений. А тут — несколько часов и чистый эксперимент.

Теперь главный вопрос — не "можно ли это сделать", а "когда можно будет этим пользоваться" и сколько времени уйдёт на то, чтобы привести UX в человеческий вид. Потому что сейчас это, конечно, ещё набор голых фич.

Но для меня гипотеза уже доказана. Даже без ТЗ, без опыта в звуке и без понимания, как такие штуки "правильно" строятся, секвенсор можно собрать — и он будет работать.

🚨 Товарищи! Нужно ваше посильное содействие.

Мы с женой запускаем небольшой проект — мобильное приложение для изучения немецких слов. Позже напишу пост, как так вышло, зачем и почему. Но по новым правилам Google нужно минимум 12 пользователей в закрытом тестировании, которые в течение двух недель будут регулярно пользоваться приложением. Достаточно раз в день открыть на 1–2 минуты и просто потыкаться по нему. Ну или реально попользоваться — это на ваше усмотрение.

Пока это касается исключительно Android-пользователей. Думаю, с iOS будет сильно проще, но к этому мы придём вторым этапом.

Для тех, кто заинтересовался или хочет помочь — я постарался подготовить гайд и максимально упростить процесс вхождения в тестирование.

Коротко суть такая:
1. Заполняете форму тут: https://wortkessel.com/beta/#signup
2. Я добавляю вас в лист тестирования
3. Вам приходит письмо с подтверждением
4. Скачиваете приложение: https://play.google.com/apps/testing/com.whitehappypony.wortkessel
5. Создаёте аккаунт
6. Пользуетесь
7. По желанию даёте обратную связь в другой форме: https://wortkessel.com/beta/#feedback-form

Буду признателен и благодарен! 🫶

С меня, как всё запустится, большой лонгрид, какая попаболь эта мобильная разработка 😵‍💫