Цікавий пост про сі, дякую)
Але щодо кмп доволі поверхнева аргументація, на мою думку. Ну тобто відносно тайтлу статті я очікував тут набір реальних проблем з продуктом, якимись фічами, тестуванням, чи observability. Одним словом, хотілось конкретику з цим тайтлом.

А хто вів розробку андроід бекенду? Типу, це були контрибутори від виробників заліза? Чи комьюніті?

Софт з флетпака сильно не факт, що буде юзер френдлі для тач скрінів. Плюс у мобайла вже устояні UI/ux практики для застосунків, до котрих користувачі звикли. Користувачі вже бачили гарний і навіть крутий UI, тож не адаптованим софтом зараз людей не вразиш це точно. Поки не буде паритету в апках (кількість і якість) — юзеру це не сильно продаш. Потім питання далі: а в чому має бути виграш для виробників заліза? Скажімо, я би зрозумів, якби Гугл руки викручував і заважав дуже? Буде щось таке?

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

В свій час Windows mobile вийшла з ринку, бо не було достатньої кількості зручних застосунків. Тобто якщо не буде можливості сходу натурально й красиво запускати існуючі застосунки — без шансів, користувачам не буде потрібно.

Потім, я думаю, андроїд чи iOS вже відомі на ринку. Тож пересічному користувачу навіщо ризикувати грошима і брати щось інше? Відповідно, ризик для виробників пристроїв — ти вклав гроші в адаптацію цілком нової ос для свого заліза, додатковий час, а користувачі можуть не купити. Принаймні, з моєї точки зору маркетинг звучить складно, аби це добре продати.

Тож, на мою думку, малоймовірний сценарій. Принаймні не зараз

Приклади з random something завжди складні для розуміння. Я спробую дати відповідь спираючись на свій досвід із DI та тестами в java/kotlin. Варіант із інжектом через метод в принципі можливий, щось схоже є у фреймворку dagger для java.

На практиці куди більш розповсюджений варіант інжекта залежності через конструктор. Якщо в проді не будеш підміняти цю залежність і вона має створюватись самотужки, то я бачу такі варіанти: конструктор з дефолтним параметром для залежності random selector -> в тесті ти підмінеш залежність на мок, в проді буде дефолтне значення, або додати 2 конструктора -> 1 для прода, сам створить selector, другий для тестів, же ти мок передаш. Обирай під можливості твоєї мови, в java немає дефолтних аргументів.

Нарешті немає нічого поганого в тому, аби передавати залежність в конструктор, навіть якщо це суто для підміни в тесті, в цьому немає абсолютно нічого поганого.

Загалом, надай конкретний кейс, з рендомом дуже складно зрозуміти проблематику.

Був здивований, що співробітники не бачили до того грейдові системи. Всюди, де працював, були і є грейди. Знав про це ще з універу. Стаття по своєму цікава, подивитись, як компанія відноситься до грейдів і що цим вирішує.

Але насправді було би цікаво дізнатись про low code платформу більше, ніж про грейдування 🙂

Дякую дуже :)

Додамо)

О, не чув, дайте посилань)

Насправді ні. Лена наполягла, щоб Playboy використати «Lenna», аби мотивувати людей правильно вимовляти її ім’я та уникнути «Leena». Щодо того, як це буде коректніше українською я не певен. Але якщо модель хотіла уникнути того м’якого звучання, я вирішив на користь Лени