Я в захваті, крутезний проект!
Дякую за статтю та класифікацію різних embedded напрямків, корисно!
А у якому напрямку більший шанс знайти роботу? Тобто кількість вакансій.
Виглядає що «3.Embedded Linux kernel engineer», так як це людина, яка є і embedded розробником, і software engineer якщо треба.
Однак це мабуть і найскладніша роль, за необхідним обʼємом знань.
Не помиляюсь?
Зі скріншотів не видно яка у вас версія android.room.compiler
Спробуйте версії які зназначені тут developer.android.com/build/migrate-to-ksp
Також можете спробувати глянути як реалізовані інші репозиторії, де використовується ksp.
Нариклад ось цей:
github.com/...7/AndroidNews/tree/master
Стаття до нього: vtsen.hashnode.dev/...sp-room-and-hilt-examples
Цікавезно, дякую!
Дякую за статтю!
Мав хобі досвід з Arduino та ESP, дізнався багато нового.
Можете порадити ідеї проектів для розвитку в embedded?
Можливо маєте власний план та могли б ним поділитись?
З цієї історії багато висновків можна зробити.
Насамперед про важливість комунікації, якість менеджменту, розуміння потреб бізнесу, сприйняття зворотного звʼязку.
Важливі речі в усі часи. Гадаю як 10 років назад, так і через 10 років будуть.
Гарне питання, теж часто над ним розмірковую.
На мою думку, наступне десятиліття — це час хардкору та математики.
Зараз дуже багато програмістів/тестувальників, навіть рівня senior, які здатні на те щоб просто зробити дану їм таску. Умовно: «Опишіть мені таску, я зроблю. Ні більше, ні менше».
Річ у тім, що таких «робочих рук» стає все більше і більше у наслідок популяризації IT.
Бути програмістом, це вже далеко не rocket science.
Відповідно конкуренція зростатиме, і для того щоб вирізнятись вже мало просто гарно робити свої таски.
Звісно «робочі руки» завжди будуть потрібні, але для того щоб мати гарне місце під сонцем, займатись цікавими задачами, потрібне щось ще.
Тому на мою думку, якщо ми говоримо про технічні ролі, то потрібні математичні знання і їх реалізація у напрямках Data Science, ML, Data Analysis і їм подібні. Або дуже глибокі хардкорні технічні скіли: системне програмування, embedded, security і т.д.
Стадартних фреймворків для розробки типових сайтів чи апок вже буде точно недостатньо.
І все більш важливим буде орієнтація тех спеціаліста на продукт. Розуміння бізнесу, можливість запропонувати краще рішення. Не просто зробити те, що сказали. Це було, і є важливим зараз. Однак на фоні все більшої кількості типових технічних спеціалістів, такі скіли будуть must have.
Якщо говорити про нетехнічні ролі (бізнес аналіз, менеджмент), то буде дуже важливий креатив та ініціативність. Бо згенерувати шаблонну роботу всі зможуть через AI.
Однак ці якості завжди були потібні, і не тільки нетехнічним спеціалістам. Тож не думаю що наступні 10 років в цьому сенсі будуть чимось особливим.
Дякую за розгорнуту відповідь!
Я так розумію, на edge devices ще зʼявляється питання security.
Унеможливити reverse engineering моделі із метою її викрадення.
Або як мінімум максимально ускладнити цей процес.
Крутезна стаття, дякую!
Було б цікаво ще дізнатись специфіку розгортання моделей на edge devices.
Чи там все на багато простіше?
Дуже фундаментальна робота, дякую!
Розвиток Flutter у напрямку покращення development experience та оптимізації дійсно вражає.
Однак часто чую про те, що Flutter дуже сирий для розробки Web сторінок.
Особливо проблеми із виділенням тексту, що впливає на пошукову оптимізацію та юзабельність сайту.
Адже весь UI (і текстові компоненти) малюється не через DOM структуру, а рендериться графічно.
Чи не наштовхувались на якісь покращення у Flutter щодо цього напрямку? Чи плануються вони взагалі?
Крута стаття, дякую!
Дуже цікаво було б дізнатись ще про продакшн хостинг моделей (переваги та недоліки існуючих інструментів, можливі челенджі і т.п.).
Пишіть ще 👍
Дуже цікаво, дякую!
Простими словами про складне, люблю таке.
Було б цікаво ще дізнатись як описана робота із текстом поєднується із робою над зображенням:
1. Розуміння зображення — генерація текстового опису завантаженого зображення.
2. Генерація зображення — перетворення тексту у образи.
Чи правильно я розумію, що натренований трансформер із етапу 1 «Pretraining — база для ChatGPT», перевикористовується для цих графічних задач?
Дякую за ваш досвід!
Також можу поділитись однією зі своїх практик: як тільки щось цифрове мене відволікає, я це виключаю.
Наприклад це стосується апок на телефоні та ноуті.
Одна рекламна нотифікашка, і апка більше не може показувати нотифікашки :)
Це ж стосується і дзвінків. Один дзвінок для збору фідбеку чи реклами коли мені було не зручно, номер потрапляє у чорний список.
Це ж і на пошті. Бачу рекламний мейл, чи з тематикою що мені не підходить, одразу шукаю unsubscribe. Якщо такої кнопки нема, то спам.
Резюмуючи, якщо щось хоч раз відволікло, то це станеться ще раз. Тому другої можливості краще не давати.
100% згоден
Дякую!
Дууже ілюстративно, дякую!
Як раз для таких випадків і задумувався StrictPro.
Раджу спробувати, завжди відкритий для зворотнього звʼязку.
Виглядає гарно, крута робота!
Якось працювали над поширенням, чи само собою на маркетах розійшлося?
Так-так, щось на кшталт дашбоарду фейків.
Було б дуже корисно для соціуму.
Круті технічні челенджі 👍
Із задоволенням почитав би більш хардкорну статтю, із більшими деталями про те, як вдалося реалізувати нетривіальні задачі.
Шкода що вільного доступу до системи ще немає.
Я би точно користувався, і був би готовий за це платити.
Прийняв, дякую!
А можливо можете ще якісь open source embedded проекти поради?
Для ознайомлення із тим, як варто робити, щоб «все по феншуй».
P.s. звісно завжди можна почитати код linux kernel і т.п. але хотілось би чогось більш адаптованого для початківця, але і не hello world, аля блимання діодами.
Дуже дякую за статтю, цікавий підхід!
Особливо гарне тут те, що це обкатано на реальному проекті.
Підкажіть, по таким питанням:
1. Чи розбивали ви компоненти на окремі модулі? Якщо так, чи гладко це пройшло?
2. Як бачите реалізацію навігації із таким підходом? На пряму в Compose отримувати navController і робити неявні залежності на інші фічі (викликаючі їх екрани для навігації)?
Чи робити окремий компонент для навігації?
3. Чи пробували ви робити на основі вашого компонентного підходу plugin based архітектуру?
Тобто, щоб застосунок можна було збирати без якихось компонентів, у різних варіаціях.
Чи підвантажувати компоненти у вже встановлений застосунок, через dynamic feature modules.
Дякую!