Когда прет - больше кода напишешь. Когда не прет - попьешь чайку и восстановишь нервы

Это не столь важно, важно что ты сам можешь решить, когда прерывать свое состояние потока

с этим согласен

но я всегда читаю такие рассуждения именно как "можно же сделать больше работы"

ака больше кода написать

значит я был не прав

ты очень правильно подметил "...я всегда читаю..."

Это не значит, что все всегда именно это и подразумевают :)

ну теперь не буду)

👍

значит не зря написал)

Я понимаю что моя манера общения выглядит как посыл я тут дарьян. Но это не так. Я всегда интересуюсь другим мнением)

Надеюсь все прочли и запомнили это сообщение.

Я вообще надеюсь что за эти годы общего знакомства все это и так поняли)

Я, к слову, вечно забываю. Но уверен, что все помнят, что меня читать надо как человека любящего иронию :)

Я помню как следует читать всех кто регулярно пишет)

Если оно будет поставляться как икскод «нажал инстал и поехали» то да, просто настройка кастомной системы может занять время и нервы....и в отличие от ожидания компиляции которое «вынужденное» и нервы не так сильно напрягает (если не зависло :) ), то что в кастомной системе что-то не работает и хз как это чинить и почему об этом надо думать вместо того чтобы думать о коде....
....писал я код в состоянии потока, там кажется «запустить» только в конце дня нажал...состояние потока оно требует создавать а не проверять...а если будешь перезапускать 10 раз чтобы понять почему метод апи себя не так ведёт, то поток прерывается....ну это мой опыт
Собственно в цифрах же дело, 5 разработчиков и 50 это совсем разные вещи (команда из 50 разработчиков с одним лидом??)
И 20 минут против 4 это конечно да.....но на практике скорее всего 1 минута против 1.5
Более быстрая билд система это хорошо, бесспорно, но надо честно обозначать «есть такие плюсы, есть такие минусы, а если у вас команда <= 5 разработчиков то вообще не стоит с этим возиться»
Моя мысль не то чтобы совсем критики, серьёзно хотелось цифры узнать, и из них узнать «стоит ли мне конкретно этим заморачиваться»....ведь эппл может что то взять и поменять/отключить, и как быстро все составляющие кастомной системы выпустят апдейты ? (Быстро), а когда доставят анти-бажные патчи.....это просто дефолтные мысли о любом «шаг вправо шаг влево от эппл»....просто линукс в одночасье так одна компания не поменяет как эппл может поменять osX или Xcode tools.....а волновать это начинает потому что легко может зайти:
- а давайте у нас делать как в фейсбуке!
- ну, у нас команда 4 человека, и мы не можем даже одного выделить на тулзы, а там целый отдел для этого
- ты хочешь сказать что нам что-то не по силам ? Что мы тупые ?

И система внедрится просто ради челенджа «а мы тоже как в ФБ сделали!»

Да, когда заказчик perfect-pixel, а у тебя x=10.5 то раздражает что моментально не обрисовываются результаты манипуляций, но это не часто

То есть....мне нравиться АЭС, но стоит ли для нашей радио модели его конструировать, может проще аккумуляторы хорошие купить

Ну мы, собственно, в выпуске, кажется, проговорили, что, например, если у вас модулей не так много или вы только начинаете проект - то вообще не надо городить огород, берете свою стандартную билд-систему (gradle, xcode, etc) и горя не знаете. А вот когда все становится сложно и, например, модулей становится сильно больше (сотни, например) - то это уже повод задумываться. Но как правило, если столько модулей - значит и команда большая, а у больших проблем своих нюансов хватает

Ну, да, я не спорю, скорее о том почему возникают все эти скептические настроения.....ну и кто то может впрок начать делать «сейчас 5 модулей, но у нас же великое будущее где 500» :)
Так то, само по себе наличия альтернатив эппл в процессе разработке это хорошо, оно даже само эпл может подстегнуть делать лучше....им вероятно есть профит что пишут на икскод используя OS X, используя macbook