Недавно в Гугл Плей появилось приложение
BookFusion Voice
которое даёт возможность установить нейро-голоса Piper в качестве системных. Соответственно, они будут доступны в любых приложениях.
Русских голосов 4, но хорошего качества из них один- “Irina” (звучит заметно лучше, чем стандартные от Гугл).

Есть небольшая проблема- если установить несколько голосов, то могут быть проблемы с выбором конкретного (это зависит от приложения, которое использует синтез).

12 марта 20:00
>> Профессиональные модульные тесты в Android: как тесты улучшают код
^{Открытый вебинар курса «Android-разработчик. Продвинутый уровень»}
Урок о том, как писать в Android осмысленные модульные тесты для ViewModel, репозиториев и бизнес-логики, чтобы они не маскировали проблемы, а реально улучшали архитектуру и поддержку кода. Записаться на урок

18 марта 20:00
>> Пишем простой проигрыватель на SwiftUI
^{Открытый вебинар курса «IOS-разработчик»}
Соберете на SwiftUI простой медиапроигрыватель с интерактивным интерфейсом, освоите работу с локальными аудио- и видеофайлами в iOS и наметите путь к интеграции внешних сервисов. Записаться на урок

19 марта 20:00
>> Современная архитектура приложения и внедрение зависимостей
^{Открытый вебинар курса «Android-разработчик. Продвинутый уровень»}
Разберемся, как выстроить Android-приложение на основе чистой архитектуры, связать слои через MVVM и настроить внедрение зависимостей с помощью Koin без лишней магии. Записаться на урок

23 марта 20:00
>> Навигация Pro-уровня в SwiftUI: как строить масштабируемые iOS-приложения без хаоса в переходах
^{Открытый вебинар курса «IOS-разработчик. Продвинутый уровень»}
Как в SwiftUI проектировать навигацию без архитектурного хаоса: отделять переходы от интерфейса, управлять deep link и модальными экранами, строить масштабируемую структуру приложения. Записаться на урок

25 марта 20:00
>> Как писать Flutter-код так, чтобы ИИ правильно его дописывал
^{Открытый вебинар курса «Flutter-разработчик»}
Поймете, почему искусственный интеллект ошибается при генерации Flutter-кода, и освоите приёмы, которые улучшат подсказки, повысят читаемость проекта и ускорят дальнейшую разработку. Записаться на урок

Еще больше бесплатных уроков от преподавателей курсов по всем ИТ-направлениям можно посмотреть в календаре мероприятий.

• умеет полностью отключать доступ к интернету для выбранных приложений;

• допускает к сети только избранные приложение;

• запрещает фоновую интернет‑активность нежелательных приложений;

• при этом никаких VPN‑туннелей и Root‑прав не требуется — всё работает из коробки;

• бесплатно приложение на Kotlin доступно на GitHub, есть версия и в Google Play.

Когда в Android-проекте ≈800 модулей и 37 000 unit-тестов, полный прогон на CI легко превращается в полдня ожидания. У нас было ровно так: больше 3 часов на полный запуск  — и ощущение, что локально это вообще не вариант. А потом команда нашла настоящие причины тормозов и довела прогон до 12 минут.

В статье «37 000 unit-тестов против Gradle: как мы добились 12-минутного прогона» конкретная инженерная история без магии. Приглашаем к чтению Android-разработчиков, техлидов и тех, кто отвечает за CI/скорость поставки. Тут много идей, которые можно примерить на себя!

Делитесь вашими подходами к решению проблем производительности в комментах)

Статья про то, о чём не спрашивают на собесeдованиях и не рассказывают на курсах по Android-разработке — о неявной особенности Android, которая влияет на деградацию производительности и приводит к невоспроизводимым ANR в вашем приложении.

SharedPreferences часто используют «по привычке» — сохранить токен, флажок, пару строк. Но в какой-то момент это начинает тормозить интерфейс и даже приводить к ANR, особенно если запись/чтение происходит не там и не тогда, где вы ожидаете. Автор делится измерениями производительности, показывает, как деградация превращается в потерю кадров при переходах между экранами, а затем сравнивает варианты.

Эта статья будет особенно интересна Android-разработчикам и тимлидам, которые уже сталкивались с мистическими ANR, просадками перформанса и фризами на слабых девайсах, а также тем, кто держит в приложении много сторонних SDK и хочет понимать, как неявные записи в SharedPreferences могут незаметно копить нагрузку.

Читайте статью «Ахиллесова пята SharedPreferences и стоит ли внедрять Datastore как альтернативу»

1. У Firefox есть много расширений, среди них нашёл подходящий режим чтения с перелистыванием. Однако оно работало плохо .

2. EinkBro. Его пришлось ставить из APK. Тоже глючил.

3. UC Browser. Обещают такую функцию. Из Гугл Плей его удалили, но в магазине Xiaomi он есть. Среди разрешений требует возможность изменять системные настройки. Поэтому решил не устанавливать.

4. Наконец нашёл Via Browser. Очень маленький, но с богатыми настройками, среди них можно назначить на "длительные нажатия" на стандартные элементы интерфейса( к примеру, на "вперёд") разные действия на выбор. Среди них есть и перелистывание.
Кроме того Via поддерживает скрипты и в режиме чтения очень хорошо сохраняет уже переформатированный текст( с крупным шрифтом) в PDF и MHT( даже сложные статьи с Хабра).

Как создать ключ:

• Убедитесь, что у вас последняя версия мессенджера (Android — 12.2.10; iOS — 12.2.3).

• Как и вход по почте, новую функцию нужно предварительно настроить. Для этого откройте Настройки › Конфиденциальность › Ключи доступа.

• Если пункт «Ключи доступа» отсутствует, то эта опция недоступна для вашего аккаунта. На текущий момент Passkeys доступны только для аккаунтов, к которым привязан российский номер.

• Нажмите «Добавить ключ доступа» и подтвердите его создание.

• Устройство может запросить код экрана блокировки или биометрию, чтобы разблокировать хранилище ключей.

• Созданный ключ появится в списке.

Как войти с помощью ключа:

• На актуальной версии Telegram для Android или iOS приложение автоматически предложит выбрать ключ доступа для входа.

• Если это не происходит, через несколько секунд под заголовком «Номер телефона» появится ссылка «используйте ключ доступа», на которую следует нажать.

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

• Ключ доступа выполняет функции как номера телефона, так и одноразового кода подтверждения одновременно.

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

P.S. Эта книга - одна из наших лучших находок в области англоязычного самиздата, однако нас в целом интересует тема разработки на Kotlin. Если у вас есть гитхаб с черновиками, либо вы прямо сейчас готовите рукопись - не стесняйтесь написать об этом Валентину Холмогорову @Holmogorov, Олегу Сивченко @OlegSivchenkoили просто в личные сообщения в этом блоге.

Спасибо вам за ваш интерес и Сергею Березину @sergbeза вышеупомянутую рецензию.

Всем привет! Меня зовут Владимир, я мобильный разработчик в «Финам». В одном из недавних проектов нужно было добавить в интерфейс Jetpack Compose визуальные эффекты поверх контента, например размытый хедер или движущуюся «лупу». 

Обычно такие приемы встречаются в играх, где весь экран — это фактически полотно для рисования OpenGL. В классической XML-разметке UI я с таким не сталкивался, поэтому пришлось довольно глубоко погрузиться во внутреннюю кухню Compose. Этот разбор может быть полезен тем, кто решает похожие задачи.

Сначала на Stack Overflow я нашел неплохой пример создания эффекта размытия на определенном участке экрана — к сожалению, это решение не было универсальным и зависело от верстки. Однако мое внимание привлекли два класса из фреймворка: RenderNode и GraphicsLayer. 

Если коротко, можно захватить часть экрана через GraphicsLayer, а в RenderNode записать контент. Но перед этим его можно обработать. После обработки метод drawWithContent() выводит результат в canvas. 

Сначала я попытался модифицировать эффект размытия из ответа на Stack Overflow, затем сделал размытие в форме круга, который движется вслед за пальцем, и постепенно пришел к окончательному варианту с движущейся прозрачной линзой. Код для отрисовки эффекта я показал в статье.

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

Какие выводу я могу сделать:

• в Compose можно делать крутые визуальные эффекты, если покопаться в RenderNode;

• это неочевидный, но мощный инструмент, он дает простор для кастомизации.

Мой пример не самый изобретательный, но способ, который я показал, открывает почти безграничные возможности для реализации визуальных эффектов в Android-разработке, чем мы в «Финам» и пользуемся очень активно в наших финтех-проектах. Итоговый результат оформил в GitHub-репозитории — берите и пробуйте в своих проектах.

Открываем новый набор на обучение по разным IT-направлениям в рамках образовательной программы Альфа-Будущее Кампус: 

• QA

• Android-разработка

• Бизнес-анализ

• Системный анализ

Сроки программ — от 3 месяцев до полугода, за которые вы научитесь создавать современные цифровые продукты под руководством ведущих экспертов Альфа-Банка в разработке, системной аналитике, QA и бизнес-аналитике.

Выбирайте курс, переходите по ссылке, изучайте программу и подавайте заявку. Успейте присоединиться до 27 октября! ❤️

Обучение бесплатно.

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

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

В статье «Почему моё Android-приложение крашится?» — понятные пошаговые разборы, примеры реальных трейс-лодов, ссылки на исходный код Android и даже инсайты, почему приложение лучше сразу завершить, чем пытаться спасти после критической ошибки.

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

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

Общее решение: Изменить процесс наема так чтобы он помогал нанять специалиста для решения задач бизнеса.

Конкретные варианты решения:

1. Использовать зарекомендовавшие себя решения в других воронках\процессах получения чего-либо. Например сарафанное радио и нетворкинг, кумовщину и рефералки, при этом отказаться от существующих фильтров в пользу доверия на старте.

2. Устранить причину мешающую текущему процессу наема. Например сократить цепочку ЛПР-ов на пути соискателя до оптимума.

   (Сейчас это авто-скрипт, эйчар(или ряд эйчаров), собеседующий специалист(или ряд специалистов), представитель команды(или ряд представителей), опционально тут еще какие-то посредники, и вот тут уже можно выйти на работу и работать 😁. Причем на каждом этапе у лже-ЛПР-ов есть цель отсеять человека на основании формального фильтра. Тогда как лучшие работники обычно "неформалы" ибо они про работу работать как Стив Возняк, а не про продукт(себя) продавать как Стив Джобс. Очевидно что не каждая птица долетит даже до середины.. 😢)

   Оптимум - это ван ту ван, один ЛПР-соискатель на одного ЛПР-нанимателя. Собеседовать можно сколько угодно, но в конце один ответственный человек собирает всю информацию в кучу (и это не оценки и выжимки специалистов, а прям сесть и посмотреть портфолио, видео собеседования, пересказ нейронки прочитать как минимум по этому видео, переписку, на свою текущую ситуацию по задачам и срокам посмотреть и т.д.) и на основе всех имеющихся данных принять полноценное решение.

   ЛПР - это тот кто принимает решение что считает лучшим на этот момент, а не тот который работает по прописанному скрипту (иначе это не ЛПР, а человек которого настоящий ЛПР назначил отрабатывать строго по скрипту 😜).

3. Устранить еще одну причину мешающую процессу наема. Например монолитность условий для прохождения собеседования. Можно искать пол жизни рыцаря на белом коне, до момента когда ни конь ни рыцарь уже будут не нужны, а можно взять то что само приползло и докрутить его под свои хотелки уже здесь и сейчас (то что само приползло должно быть согласно на докрутку, чтобы ни одно живое существо не пострадало в процессе наема 😁).

P.S. Все 3 варианта решения на самом деле про одно и то же, только заход с разных сторон: убрать не то что мешает обрабатывать заявки на чиле, в пол уха, левой пяткой, а убрать то что действительно мешает нанять сотрудника для решения конкретных задач. (Да стало много спама, ну и что? Разве то что много спама говорит о том что среди спама нет специалистов способных делать работу? Нет. Как раз таки в этом и заключается задача\работа нанимателя - нанять сотрудника в этих конкретных условиях. Ну да, придется поработать. Соискатель, наниматель и работодатель в одной лодке как ни крути, если кто-то не хочет грести, то далеко ли уплывет такая лодка?🛶)

Хорошего дня, наема и трудоустройства!

Обнял 🤗

Дело в том хочет человек тебя нанять или нет

Т.е. проходишь ты дальше или нет основывается не на твоих желаниях и знаниях, а на желаниях и знаниях собеседующего

Так что не парься, будь счастлив 😁

Воспринимай собеседования не как путь именно к этой работе, а как путь к чему-то вообще :)

В любом случае этот шаг делает тебя на шаг ближе к цели

Если ты не прошел собес, то выбор простой: сражайся с этим или наслаждайся этим, и даже если сражаешься, то насладись сражением 😁

P.S. И так во всём..

Эйчары не понимают бизнес.

Бизнес не понимает эйчаров.

Эйчары не понимают технарей.

Технари не понимают эйчаров.

Бизнес не понимает технарей.

Технари не понимают бизнес.

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

Делегирование делегированием, а эффективность эффективностью.

Еще:

Бизнес конкурирует с бизнесом.

Эйчары конкурируют с эйчарами.

Технари конкурируют с технарями.

И все конкурируют со всеми.

Как следствие - на технических собесах технари с обеих сторон стремятся доминировать друг над другом. Так как решение о наеме принимает собеседующая сторона, то она имеет преимущество над соискателем и ему приходится подстраиваться.

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

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

Выводы:

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

Бизнес который делегирует наем рано или поздно оказывается в положении "свой среди чужих, чужой среди своих", фактически самым ценным ресурсом компании - людьми - теперь владеет не Бизнес, а Технарь и HR.

Такие дела.

Вот еще интересные мысли о наеме, с которых все началось:

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

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

Понимают ли они то что происходит во всей полноте? Похоже что нет, иначе процесс был бы устроен другим образом.

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

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

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

А теперь вернись к началу, вероятно теперь станет понятно откуда взялись такие тезисы :)

P.S. Похоже всё это не является проблемой только потому, что получается микро-коммунизм в наеме. Одна компания обучает соискателей для другой, и та в свою очередь делает так же. По сути работает не система наема в компании, а побочные эффекты от нескольких систем наема разных компаний.

Откуда такие мысли:

Я уже 12 лет как в теме, и устраивался на работу сам, и искал людей на свои проекты, и собеседовал как технарь(в Android разработке) на проекты бизнеса. В общем я пощупал этого слона с разных сторон, и теперь когда я снова в активном поиске - это сложилось в объемную картину.

Совершенно случайно наткнулся на интересное:

У меня дома стриггерился алерт: мой домашний сервачок (он же роутер) помимо всего прочего отслеживает количество уникальных от-forward'енных $src_ip + $dst_ip + $dst_port – и алертит, когда их количество превышает некоторый порог.

И вот за последние сутки с моего телефона + телефона жены 2560 + 4082 уникальных пар $dst_ip + $dst_port (где 602x22 ниже – это соединения на 22 порт на 602 разных IP-адреса):

kate-mobile.lan (4082 IP+port pairs): 3117 TCP (1534x443, 602x22, 261x80, 237x554, 220x53, 29x23, 28x983, 21x553, 20x179, 12x1443, 9x5222, 6x5228, 4x4460, 4x21, 2x571, 2x9243, 2x240, 2x383, 2x185, 2x260, 2x299, 2x237, 2x336, 2x131, 2x512, 1x464, 1x734, 1x4416, 1x371, 1x10, 1x863, 1x895, 1x759, 1x815, 1x178, 1x830, 1x271, 1x838, 1x707, 1x629, 1x174, 1x1003, 1x894, 1x3237, 1x887, 1x962, 1x603, 1x855, 1x241, 1x494, 1x540, 1x181, 1x352, 1x454, 1x373, 1x654, 1x56, 1x646, 1x175, 1x876, 1x810, 1x556, 1x395, 1x483, 1x697, 1x212, 1x34, 1x588, 1x348, 1x605, 1x680, 1x460, 1x401, 1x224, 1x143, 1x161, 1x104, 1x655, 1x872, 1x521, 1x459, 1x911, 1x705, 1x317, 1x377, 1x807, 1x323, 1x893, 1x866, 1x142, 1x1001, 1x170, 1x920, 1x843, 1x209, 1x463, 1x156, 1x569, 1x952, 1x701, 1x184, 1x597, 1x389, 1x647, 1x8543, 1x487, 1x624, 1x537, 1x814, 1x259, 1x578, 1x26, 1x904, 1x751, 1x652, 1x795, 1x234, 1x671, 1x45, 1x4477, 1x307, 1x635, 1x651, 1x227, 1x806, 1x752, 1x203, 1x220, 1x582, 1x568, 1x153, 1x844, 1x402), 965 UDP (379x443, 278x53, 116x554, 83x123, 38x22, 22x23, 7x2002, 6x983, 4x179, 2x4123, 2x512, 2x21, 2x553, 1x363, 1x652, 1x654, 1x1003, 1x299, 1x307, 1x377, 1x680, 1x807, 1x804, 1x966, 1x685, 1x240, 1x463, 1x655, 1x806, 1x45, 1x383, 1x336, 1x153, 1x260, 1x28, 1x241, 1x603)
mobile.lan (2560 IP+port pairs): 1899 TCP (814x443, 405x22, 171x554, 168x80, 160x53, 23x983, 18x179, 18x1443, 15x23, 10x553, 9x5222, 6x21, 5x7275, 3x5228, 2x19302, 1x759, 1x37, 1x629, 1x685, 1x581, 1x582, 1x10000, 1x142, 1x250, 1x846, 1x125, 1x872, 1x657, 1x8543, 1x604, 1x90, 1x727, 1x567, 1x911, 1x739, 1x810, 1x4477, 1x866, 1x26, 1x491, 1x10, 1x156, 1x626, 1x178, 1x422, 1x977, 1x155, 1x12, 1x402, 1x683, 1x21007, 1x306, 1x595, 1x184, 1x4416, 1x472, 1x14, 1x904, 1x166, 1x165, 1x753, 1x988, 1x4434, 1x11, 1x28, 1x317, 1x622, 1x535, 1x718, 1x686, 1x637, 1x207, 1x244, 1x153, 1x7000, 1x8443, 1x966, 1x383, 1x5223, 1x985, 1x161, 1x994, 1x395, 1x898, 1x39, 1x592, 1x6447), 661 UDP (307x443, 168x53, 81x554, 36x123, 24x22, 10x23, 6x983, 6x179, 4x19302, 3x553, 3x21, 1x153, 1x685, 1x626, 1x155, 1x592, 1x19000, 1x491, 1x306, 1x472, 1x125, 1x8443, 1x28, 1x966)

Поставил себе PCAPdroid на телефон, и выяснилось, что WhatsApp (я им совсем не пользуюсь – установлен по необходимости):

• За последний месяц съел 23 MB Wi-Fi трафика.

• За сегодняшний день съел 92 MB Wi-Fi трафика.

• Постоянно открывает соединения на разные IP и всякие мутные порты (ssh, ntp, ftp).

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

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

P.S.: Большая просьба не воспринимать это как очередную рекламу в пользу всем известного мессенджера, который сейчас активно продвигается – все совпадения случайны.