Цікава стаття, дякую. Може, у когось був глибший досвід? Скажімо, CrowdIn має інтеграцію з фігмою та іншими дизайн тулами. Ідея в тому, що строчки будуть потрапляти до локалізаторів ще на етапі дизайну. Потунційно прикольно — стартуєш роботу над фічею, а тексти треба тільки забрати з крауда в один клік в IDE. Але є купа тезнічних питань до цього, тож цікаво, чи хтось подібні рішення пробував

support.crowdin.com/figma-plugin

Гарна стаття, дякую! Попрацювавши на кількох продуктах можу сказати, що саме такі інженери мають найбільший вплив і ріст в продуктових компаніях також. Універсальні поради, виходить, дали :)

Долучаюсь до інших: дякую за реальну картинку і позитивний підхід. Мені здається, що «не все і відразу» треба повторювати з усіх усюд і якомога гучніше. Принаймні, мені це корисно чути регулярно 😄

Я веду до того, що локально за умов такої собі ізоляції — так, логічно, що це буде працювати. Однак я вже вказував, що за умови доступності сервісів мені, як користувачу, простіше обрати між iPhone та android, бо там точно будуть всі потрібні і популярні застосунки. І це впливатиме на продажі пристроїв на цій ОС. Тобто я не розглядав китай у своєму коментарі

Ну да, це або весь продукт написати знову для Linux, або існуючу кроссплатформу білдити під лінукс. Звучить гладко тільки на папері, на мою думку

Ну до речі, incompatible with Android applications — це постріл в ногу. В свій час windows mobile загнулись через відсутність паритету по кількості апок. Типу, якщо у мене в країні є сервіси Гугл, навіщо мені купувати щось несумісне? Хто буде для нього софт писати?

Припускаю, що якби сьогодні на ринку існувала хоча би +1 додаткова ОС для мобільних пристроїв, то популярність кросплатформенних фреймворків була би вищою

Не те щоби камбек, але я хотів би побачити серйозні планшетні пк. І не оту шляпу, що виходила для вінди. Хочеться вірити, що колись можна буде поставити андроїд студію на ipad, пристігнути клавіатуру і мати майже кишеньковий ноут з ± потужністю непоганою і можливістю користувати це як зручний планшет: читати книжки, дивитись фільми в дорозі

Цікавий пост про сі, дякую)
Але щодо кмп доволі поверхнева аргументація, на мою думку. Ну тобто відносно тайтлу статті я очікував тут набір реальних проблем з продуктом, якимись фічами, тестуванням, чи 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». Щодо того, як це буде коректніше українською я не певен. Але якщо модель хотіла уникнути того м’якого звучання, я вирішив на користь Лени