⚡️ Экономим $200+ и делаем дроп D-U-N-S номера через Apple

Мало кто знает, что Google Play закручивает гайки. Если вы планируете релизить приложения в категориях Финансы, Здоровье (Health apps) и еще парочка категорий, Google официально требует регистрировать аккаунт Организации, а не личный.
А если у вас просто новый личный аккаунт – добро пожаловать в "песочницу": ищите 20 тестировщиков, которые будут тыкать ваше приложение 14 дней.

Чтобы пропустить эти круги ада, нужен статус Организации.

И тут вы упираетесь в стену: нужен 🔠🔠🔠🔠 номер.

🏢 Что это такое и зачем нужно Гуглу?
По сути, это уникальный ID вашей компании в глобальном реестре. Гуглу нужно удостовериться, что ваша компания ("Рога и Копыта") реально существует, а вы не просто придумали название.
Нюанс: Для получения номера часто требуют, чтобы у компании уже был живой веб-сайт с контактами. Без сайта заявку могут развернуть.

🐢 Официальный (и долгий) путь Вы идете на официальный сайт Dun & Bradstreet, заполняете анкеты и видите два стула:

1. Пики точенные Бесплатно: Ждете рассмотрения заявки от 30 до 45 дней. (В реальности может быть и дольше).

2. Что-то моченное Платно: Платите сервисный сбор ~$229, и вам делают номер за 5 рабочих дней.

Деньги лишними не бывают, а ждать месяц – это смерть для стартапа.

🍎 Хак через Apple (бесплатно и быстро)
У Apple с D&B свои "особые отношения". Чтобы сэкономить $200+ и время, мы идем регистрировать аккаунт разработчика в... App Store.

1. Начинаем энроллмент в Apple Developer Program как Company / Organization.

2. Доходим до шага проверки компании и ищем кнопку "Look up your D-U-N-S Number".

3. Вводим данные. Если номера нет – отправляем запрос на создание прямо через форму Apple.

В чем фишка: Такие заявки обрабатываются в приоритете за те же 3-5 рабочих дней, но бесплатно. Платить Apple за сам аккаунт при этом не нужно. Как только вам на почту придет заветный номер – берете его и идете регистрироваться в Google Play.

PROFIT❗️

#GooglePlay #AndroidDev #IndieDev #Лайфхак #DUNS

Бесит, когда вместо `push` получается `згыр`? 🤬

Если вы быстро печатаете на Mac, вы точно знаете эту боль.
Жмешь переключение, продолжаешь печатать, а система «проглатывает» первые буквы и оставляет их в старой раскладке. 🤬

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

Решение: Отключить визуальный индикатор через Терминал. Это уберет худ, вернет старое уведомление и сделает переключение мгновенным.

Вводим команду:

defaults write kCFPreferencesAnyApplication TSMLanguageIndicatorEnabled 0

После ввода нужно перезагрузить комп (или подождите немного и система сама перейдет на старый способ отображения).

Done ✅

P.S. Чтобы вернуть всё назад, замените 0 на 1 в конце команды.

🍕 «Достаю из широких штанин»: Как зарождался и устроен процесс разработки дизайн-системы в Додо. 🎨

Я волком бы выгрыз бюрократизм.
К мандатам почтения нету.
К любым чертям с матерями катись
любая бумажка. Но эту…

Это был хук, не лишенный смысла, ниже поймете 👇

Где-то год назад в компании созрел запрос на снижение временных затрат на разработку.

Одним из решений было создать свою дизайн-систему.

Я занимался дизайн-системами в Мегафоне и в Магните, поэтому вписался в эту тему со стороны Android, а чуть позже взял лидерство на себя в зоне Android.

Вместе со мной в эту тему впрягся мой хороший товарищ с iOS, который покинул пост и отправился за «золотыми яблочками» (я не могу это осуждать, хотя… 😁). Вот ссылочка на его канал: @technolexa

Первое, что нам предстояло решить, – это как мы будем развивать ДС с ограниченным ресурсом: два разработчика (по одному на платформе) и один дизайнер и все это не отказываясь от бизнес-задач.

Мы со стороны разработки построили флоу (прикрепил скринчик), когда вместо «завода», выпускающего по тонне компонентов, у нас будет система, при которой каждый разработчик будет вовлечен в процесс.

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

Это позволяет распределить разработку ДС на всех разработчиков и одновременно познакомить их с тем, как это работает изнутри. При этом никто не запрещает брать разработку компонентов вне фичи.

Чтобы разработчик мог взять компонент в разработку должны сойтись звезды быть выполнены несколько условий:

1. у компонента должен быть паспорт (спецификация в которой описано поведение компонента и его состояния). Без этого документа разработчик не может приступить к разработке.
2. разработчик ознакомлен с требованиями к компоненту ДС.
3. у разработчика должно быть желание и время кодить компонент.

«Складно стелишь, Серега» – можете возразить вы 😏 Откуда у разработчика должна появиться дополнительная мотивация делать что-то вне прямых обязанностей?

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

Ладно, разумеется, есть еще техлид команды, через которого можно повысить приоритет у задачи 😈

Так что же делать, когда все первоочередные условия выполнены?

Разрабатывать! 👨‍💻
– либо весь компонент полностью;
– либо необходимые состояния для фичи.

Если времени на реализацию крупного компонента нет, то мы договариваемся, что разработчик добьет его в техспринт, либо ответственные за ДС добьют сами и катнут в прод.

Цельный флоу выглядит так:

1. Дизайнеры находят паттерн. Когда в макетах фичи появляется повторяющийся элемент, дизайнеры и разработчики, ответственные за ДС, решают: «Пора в систему».

2. Паспорт компонента. Лид ДС готовит спецификацию.

3. Разработка через практику. Когда фича падает разработчику, он берёт паспорт компонента и сам внедряет его в ДС параллельно с фичей.

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

Спасибо тем кто дочитал до конца 🧡