Насправді це гарна і грунтовна стаття. Яка має майже 100% влучання.
Ніякі бізнес моделі тобі не замінять time to market на 30-40% швидший ніж у твоїх competitors.
Реальних game changers бізнесів один на пʼять років (for ex: ChatGPT), але коли всі інші роблять свої клони game changers за 3 місяці це сильно бʼє по ринковій частині, бо можно демпінгувати ціною.
Швидкість і низька ціна тесту гіпотез або змін це те що відрізняє think and do smart від компаній які сьогодні є, а завтра немає (for ex: IBM)

Коротка інструкція:
— старайтеся ніколи не робити будь-які робочі коменти токсичними і завжди слідкуйте за tone of voice як у pull-requests так і у просто професійному спілкуванні (не допускайте оціночних суджень типу «твій код лайно» ітд)
— розділяйте фідбек по формулам, наприклад проблема — наслідки — як фіксити — приклади з інших проектів (гарно працюють історії публічних проблем, наприклад CPU time planner на linux core)
— автоматизуйте максимум можливого у ваших ПР, автокоррект стайлу, лінтери, юніт тести, попередження через code coverage і errors на absent unit tests, etc
— якщо у вас немає загальної доки про процес (code style, code guide, PRs style, review approach, etc), створіть її зсилаючись на best practices from opensource projects
— завжди апелюйте на загальноприйняті best practices як DRY, SOLID, FIRST
— якщо зовсім тяжко зідзвонюйтесь і розповідайте чому і як (тут залежить від рівня ваших колег, це все ж не дитсадок і не богодєльня)
— не бійтеся прощатися з токсичними але кваліфікованими членами команди
— старайтеся ніколи не бути токсичним, бо ви втратите авторитет у команді в будь якому випадку, навіть якщо ви 10 разів праві

Коротка відповідь: так, входить.

Довга відповідь:
Кожен менеджер будь то TL, PO, PM, CEO, etc має команду. Щоб створити гарну атмосферу роботи і досягати цілей з командою потрібно мати налагоджені стосунки. Тобто працювати через кооперацію (щось, як, ти мені — я тобі). Якщо менеджер грає у «роадмаппєра» або «політика» такі команди ніколи довго не живуть, це породжує токсичність і постійну зміну складу команди (тєкучка).
Із обовʼязків — робоче навантаження повинно бути реалістичним, контроль овертаймів, скоупи і дедлайни повинні базуватися на обʼєктивних речах а не «томушо лєва нога твого боса сказала повинно бути готове через квартал». Плюс «неофіційна» частина щоб слідкувати що ніхто не випадає, але тут дуже багато софскілів треба. Бо кожна людина унікальна і продукує унікальні ситуації.
Приклад «неофіційної» частини — зібрати всіх по пиву в вечір пʼятниці в Red Door або DAF, щоб потеревенити, пошуткувати і випустити робочий пар. В загалі це тягне на окрему статтю.

Бонусне питання яке рекомендую задати собі «чи входжу я в справжню команду свого менеджера?», бо буває так що у людей взагалі окремі цілі, наприклад створити якусь сіру структуру у компанії де кожен «кум, брат, сват», або наприклад виїхати на командних досягненнях через вичавлення колег до форми вигорання іті.

Присоединяйтесь к iOS Open Engineering Guild Ukraine в телеграмме
t.me/ios_guild_ukraine

Рекомендую еще на медиуме, топ 50 iOS вопросов и ответов, и там около 5 частей,
все актуальны

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

Я бы переименовал заголовок на «Почему стоит использовать SwiftUI и, иногда, совсем немножко UIKit» :)

Можно поспорить, потому что, по своей природе императивный подход он однопоточный, а реактивный многопоточный (так как строиться на предположении что все events приходят в обработчики в одно время). С такой точки зрения меньше порог входа у того подхода, где используется более простой механизм.

Имел ввиду, что вы не можете использовать Concrete Types которые не class,
а не в смысле что вы можете использовать протоколы или generics внутри wrappers.

Да, не скомпилируется потому что для Wrapper скорее всего нужен Concrete Type

Можно развернутый пример что хочется сделать и что не получится. Вариант в скобках изображает простой пример class-only протокола для наглядности.

давайте мб зарепортаем/зассумоним сапорт dou?

Сейчас мы рассматриваем диджитал — есть программы, которые позволяют делать то же самое с выводом на стену проектором.

Используем kendis.io сейчас, вроде как всем нравится

Хорошая статья, хотелось бы еще увидеть аналитику по user experience, потому что разработка может быть дешевле/быстрее, но вопрос в удовлетворенности пользователей не раскрыт.

btw, skype хороший пример того, почему не нативная кросс-платформа это плохо

Мыщьх сам собой разбросался, как бы черным юмором это не было.

А мы вот с двух студийных сессий собрали блюзца

itunes.apple.com/...​one-tone-below/1394344657
yourinnergod.bandcamp.com

>больше 10 шагов
>быстро

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

Вы очень крутая женщина.
Что думаете на счет того, что через 10-15 лет допустим основные знания области сконцентрируются в таких коммерческих местах как курсы компаний, в которые будут брать после школы, и, допустим, за 2 года, будут давать необходимый практическо-теоретический минимум. С контрактом работы на эту компанию (допустим на 3-5 лет, или платой за обучение)

>here was an ironic link to Metallica