Там дело не в самом сторе, а именно в том что вокруг него (те самые проценты в том числе). Гуглоплей это не только листинг приложений (амазон и самнунг тоже имеют магазины), это ещё и тонна подвязок на IAP, всякие варнинги от ОС при установке из других приложений и прочее, не говоря уж о том что гуглоплей стоит "по умолчанию" и без него (вернее без play services) система начинает работать как корявое шапито.
Как раз интернетик листать она скорее всего и перегреется, а торренты норм. Попробуйте на rpi запустить какую графану крутить мониторинги на экране - перегреется только в путь, а графана это далеко не худший случай интернета
С одной стороны вы правы. Но посмотрите на это под другим углом: вы живёте в небольшом городе где есть только супермаркеты магнит и пятёрка; вы построили птицефабрику, выращиваете курей, решили помимо мелкого магазина на фабрике продавать кур через сети. Приходите в магнит, вам говорят комиссия 30%. И пятёрка аналогично. Да, безусловно они в своём праве, у них кассиры, помещение и прочее, не нравится - продавайте через свой магазин возле фабрики. Но вам не кажется что отдавать за это треть своих доходов (именно доходов, не прибыли, куры жрать не перестали) это немного перебор? Дикий капитализм это нифига не весело
Я часто ловлю себя на том, что переусердствую с проектированием, когда нахожусь в «потоке»
Потому что проектированием нужно заниматься до этого. Я когда нахожусь "в потоке" - просто механически пишу код как робот по заранее придуманной модели, а когда нужно проектировать и вообще думать мозгом - ни о каком "потоке" и речи быть не может.
Про быстродействие не согласен, пользователю будет лучше ждать в два, а то и в три раза меньше загрузки ответа, например, от сервера
Вот это крайне спорная тема. Для вебни есть тысячи других вещей которые могут тормознуть запрос, самые простые - отсутствие cdn и большое расстояние, ну и просто хреновое соединение. Плюс всякие облачные базы тоже докинут тормозов уже на бэке. Вполне обычная ситуация когда на крестах нужно будет 10мс машинного времени, на пистоне 100мс, а пинг от юзера до бэка 500мс
Я может фигню скажу, но кмк намного лучше себя показывают специализированные сопроцессоры под конкретные задачи. Тот же gpu например, всякие сопроцы для шифрования и прочее. Вместо массива однородных процессоров которые делают все но средне сделать разные которые умеют делать что-то одно но хорошо
самой популярной страной среди российских специалистов стала Франция
Странно. Франция это мягко говоря не it-центр мира. В Дублин или Цюрих/Базель - да, в Польшу тоже едут, ну или там в Испанию чисто греться. Но Франция это странный выбор
Я джунам именно про цикл рассказывал, туда очень органично легли всякие sleep(0), опасность блокировки цикла cpu-bound задачами, очереди, порядок выполнения и прочее. Но я питонист, в питоне судя по другим комментам проще чем в котлине, по умолчанию loop только один.
Тогда не проще ли думать/объяснять корутины именно в контексте этих циклов? Ну, условно что join выходит из контекста задачи обратно у цикл, и задача не пойдёт в выполнение (будет пропущена в цикле) до тех пор пока не завершится ожидание помеченной join корутины. И ради иллюстраций взять обычную ladder diagram.
Кмк это намного проще для понимания чем "измерения" или "некоторое время на запуск"
Я не андроид-разработчик, но разве корутины в котлине не следуют обычному cooperative multitasking, когда грубо говоря есть системный цикл который по очереди проходит по всем scheduled задачам (корутинам) и выполняет их насколько это возможно (если нет io, если прошёл delay, если завершилась отрисовка и т.д.)? Ну и соответственно пока не произойдёт переключение контекста (выход из контекста текущей задачи в системный цикл) - корутина не запустится.
QA должны проверять что критерии проверки сформулированы и проверка проведена-реализуема
Кмк это зависит от того как построен процесс. По моему опыту, гораздо лучше когда QA сам придумывает сценарии и обсуждает их с разработкой (что можно автоматизировать, что нельзя, что опасно и т.д.). По большей части это связано с тем что во время работы над задачей мыслительный процесс разработчика, опять же по моим наблюдениям, сильно отличается от QA: разработчик больше думает со стороны создания, а QA - со стороны возможных косяков. Понятно что разработчик должен и про косяки думать, но в общем случае у QA это получается лучше чисто ввиду разделения труда. Это особенно заметно если бэк и фронт разделены (не full stack), некоторые кейсы могут казаться ппц важными разработчику но для QA это будет откровенно corner case и наоборот.
не полагайтесь на то, что специалисты QA выявят все баги
Более того, QA не резиновые, если их пытаться заставить на каждый чих перепроверять всю систему - очень быстро произойдёт bottleneck в части тестирования, и виноват в нем будет не qa, а разработчик
Доступы, например. Если у меня есть скажем онлайн-магаз или есть какие-то платные действия в приложении - часть информации о платежах вполне может лежать отдельно чисто для разделения доступа к ней.
Статья для новичка кмк хорошая, но как минимум нет фабрик, а это очень нужная вещь. Иначе джуны начинают плодить методы с передачей всего подряд в качестве аргумента либо просто копипастить код "потому что нужно больше одного объекта"
Там дело не в самом сторе, а именно в том что вокруг него (те самые проценты в том числе). Гуглоплей это не только листинг приложений (амазон и самнунг тоже имеют магазины), это ещё и тонна подвязок на IAP, всякие варнинги от ОС при установке из других приложений и прочее, не говоря уж о том что гуглоплей стоит "по умолчанию" и без него (вернее без play services) система начинает работать как корявое шапито.
Как раз интернетик листать она скорее всего и перегреется, а торренты норм. Попробуйте на rpi запустить какую графану крутить мониторинги на экране - перегреется только в путь, а графана это далеко не худший случай интернета
С одной стороны вы правы. Но посмотрите на это под другим углом: вы живёте в небольшом городе где есть только супермаркеты магнит и пятёрка; вы построили птицефабрику, выращиваете курей, решили помимо мелкого магазина на фабрике продавать кур через сети. Приходите в магнит, вам говорят комиссия 30%. И пятёрка аналогично. Да, безусловно они в своём праве, у них кассиры, помещение и прочее, не нравится - продавайте через свой магазин возле фабрики. Но вам не кажется что отдавать за это треть своих доходов (именно доходов, не прибыли, куры жрать не перестали) это немного перебор? Дикий капитализм это нифига не весело
Потому что проектированием нужно заниматься до этого. Я когда нахожусь "в потоке" - просто механически пишу код как робот по заранее придуманной модели, а когда нужно проектировать и вообще думать мозгом - ни о каком "потоке" и речи быть не может.
Вот это крайне спорная тема. Для вебни есть тысячи других вещей которые могут тормознуть запрос, самые простые - отсутствие cdn и большое расстояние, ну и просто хреновое соединение. Плюс всякие облачные базы тоже докинут тормозов уже на бэке. Вполне обычная ситуация когда на крестах нужно будет 10мс машинного времени, на пистоне 100мс, а пинг от юзера до бэка 500мс
Я может фигню скажу, но кмк намного лучше себя показывают специализированные сопроцессоры под конкретные задачи. Тот же gpu например, всякие сопроцы для шифрования и прочее. Вместо массива однородных процессоров которые делают все но средне сделать разные которые умеют делать что-то одно но хорошо
Странно. Франция это мягко говоря не it-центр мира. В Дублин или Цюрих/Базель - да, в Польшу тоже едут, ну или там в Испанию чисто греться. Но Франция это странный выбор
И свой цикл есть у каждого потока и пул задач между ними общий?
Я джунам именно про цикл рассказывал, туда очень органично легли всякие sleep(0), опасность блокировки цикла cpu-bound задачами, очереди, порядок выполнения и прочее. Но я питонист, в питоне судя по другим комментам проще чем в котлине, по умолчанию loop только один.
Тогда не проще ли думать/объяснять корутины именно в контексте этих циклов? Ну, условно что join выходит из контекста задачи обратно у цикл, и задача не пойдёт в выполнение (будет пропущена в цикле) до тех пор пока не завершится ожидание помеченной join корутины. И ради иллюстраций взять обычную ladder diagram.
Кмк это намного проще для понимания чем "измерения" или "некоторое время на запуск"
Я не андроид-разработчик, но разве корутины в котлине не следуют обычному cooperative multitasking, когда грубо говоря есть системный цикл который по очереди проходит по всем scheduled задачам (корутинам) и выполняет их насколько это возможно (если нет io, если прошёл delay, если завершилась отрисовка и т.д.)? Ну и соответственно пока не произойдёт переключение контекста (выход из контекста текущей задачи в системный цикл) - корутина не запустится.
Кмк это зависит от того как построен процесс. По моему опыту, гораздо лучше когда QA сам придумывает сценарии и обсуждает их с разработкой (что можно автоматизировать, что нельзя, что опасно и т.д.). По большей части это связано с тем что во время работы над задачей мыслительный процесс разработчика, опять же по моим наблюдениям, сильно отличается от QA: разработчик больше думает со стороны создания, а QA - со стороны возможных косяков. Понятно что разработчик должен и про косяки думать, но в общем случае у QA это получается лучше чисто ввиду разделения труда. Это особенно заметно если бэк и фронт разделены (не full stack), некоторые кейсы могут казаться ппц важными разработчику но для QA это будет откровенно corner case и наоборот.
Так вот зачем это дурацкое расположение зарядного порта, чтоб наклонять удобно было, никогда б не подумал
/sarcasm
Более того, QA не резиновые, если их пытаться заставить на каждый чих перепроверять всю систему - очень быстро произойдёт bottleneck в части тестирования, и виноват в нем будет не qa, а разработчик
Доступы, например. Если у меня есть скажем онлайн-магаз или есть какие-то платные действия в приложении - часть информации о платежах вполне может лежать отдельно чисто для разделения доступа к ней.
Статья для новичка кмк хорошая, но как минимум нет фабрик, а это очень нужная вещь. Иначе джуны начинают плодить методы с передачей всего подряд в качестве аргумента либо просто копипастить код "потому что нужно больше одного объекта"
Для разработчиков, тянущих в проект зависимости на каждый чих, есть отдельный котёл в аду. Стоит рядом с котлом для админов, гоняющих
curl | sudo bash