Бесшовно у вас переезжают только те приложения, у которых требования к безопасности около нуля. Есть ключи шифрования, есть всякие сохраненные данные в keyChain, которые тоже шифруются. Вы правда хотите, чтобы тот, кто получит доступ к вашему iCloud получил вообще всё? Второй фактор, конечно же, спасает в большинстве случаев, но это не панацея. Разработчики под iOS, macOS и прочие iPadOS не игнорируют этот функционал, а осознанно не реализуют его.
Понравилась статья, спасибо, но вот вам комментатор выше написал вполне аргументированную критику по вашей статье, а вы обижаетесь. Действительно, в контексте описания того, как работают финансовые продукты мне тоже кажется не совсем уместным использование художественных приёмов. Мне из вашего ответа ещё больше становится заметным, что вы лично в восторге от Apple Card, а это может влиять на объективность всего остального в статье.
Ну и портфель из 7 млн. держателей не обязательно же о чём-то говорит со знаком плюс, разве нет? Разве не может произойти коллапс, когда все эти люди ухудшат свой кредитный рейтинг?
Раньше в UI/API тестах я иногда использовал градацию по критичности тестов и в Allure для Java это было довольно удобно сделано. Тут не совсем ясно, как это затащить. Можете подсказать? Возможно, я упустил этот момент из статьи.
А вообще спасибо большое за статью, на нынешнем iOS проекте как раз на подходе UI тесты и я всё думал, получится ли прикрутить Allure = )
Если мы говорим о юридически значимом документе, то никаких предположений и догадок быть не может, потому что это допускает вольную трактовку. Нигде тут не написано, на что заказчик согласен и что он допускает. Соответственно, это можно использовать как памятку, которая болтается где-то среди пачки остальных соглашений, диаграмм и прочего, но лично я бы такое не подписал, не смотря на то, что с большинством пунктов согласен.
Я правильно понимаю, что данные об орбите, массе и размере планеты получают из данных о том, насколько звезда яркая, насколько большая и о том, как сильно и часто меняется её светимость из-за наличия предполагаемой планеты?
Согласен со статьёй.
У меня такое наблюдение: весь прошлый год особо не занимался физкультурой. Всего пару раз прокатился на велосипеде и съездил покататься на сноуборде в ноябре. Состояние было постоянно вялое. Спал плохо, если верить браслету mi band. К концу года к общему спаду активности начал прирастать живот.
Начал ходить в бассейн раз в неделю. Плаваю обычно минут 40 — 60 в максимально возможном темпе. Так я теперь и спать лучше стал, и хватать на сон стало 7 часов, вместо 9. В течение дня энергии полно. Хватает и на работу и на домашние дела и на изучение Английского. Скинул 6 кг, сосредоточиться получается гораздо лучше и работы за день больше делаю. Так что двигаться точно надо.
А зачем вообще его проектировали, если не дали в итоге?
Это звучит примерно так: «А зачем вы заказчику проект делали, если он в итоге не заплатил вам?». Я расшифрую: делали, потому что думали, что дадут, но в итоге не дали. Так бывает.
Двухбитный контур классического компьютера может находиться в одном из четырёх состояний (0,0; 0,1; 1,0; 1,1). Пара кубитов может быть комбинацией их всех.
Если я правильно понял, то тут имеется в виду, что классический компьютер в конкретный момент времени может принимать одно из состояний, в то время как квантовый может принимать их все одновременно.
Помню, во времена первого пентиума была у меня игра — «долгая ночь». Не силён в жанрах, так что пусть будет квест. Совсем не помню сюжет, но помню, что она была невероятно атмосферная и для меня тога довольно сложная. Почему-то никак не могу её найти ни в закромах на CD, ни на просторах интернета. Может кто-нибудь тоже играл и помнит оригинальное название?
В таком виде, на мой взгляд, было бы круто сделать беззеркалку с функциями смартфона. Насколько я помню, у беззеркалок были довольно плоские объективы. Это конечно будет здоровенный аппарат, но и смена объективов тебе и выкладка в инстаграм и прочие прелести. Я бы купил.
С Canon 60D + 70-200mm + 14mm + вспышка неудобно например на борде кататься. А так можно обойтись плоским блином-объективом и в небольшом жестком кофре ещё что-то типа телевика таскать.
Правда, для этого вам придётся обзавестись штативом и как-то приспособить на него смартфон.
Всё просто. Штатив нужен, да, а вот присобачить на него смартфон можно с помощью крепежа от селфи-палки. У меня он идеально вкручивается на контактную площадку штатива (у крепежа для палки отверстие такое же, как на зеркалках для крепления к штативу).
Если я правильно понимаю, то вы готовите конкретные данные и переводите их в тесты.
Но вот тут вопрос возникает — почему бы не описать правила и на основе этих правил создавать полный набор данных?
Например, есть таблица, в которой есть поля с типами NVARCHAR2 и NUMBER. Есть ещё какой-нибудь foreign key, primary key и т.д. Ещё поля с Nullable = true/false. Короче, есть спецификация данных. Мы можем на каждое из правил придумать проверки: не уникальное значение, отсутствие соответствующего значения для внешнего ключа и т.д.
Всё, на основе этого мы можем просто подсунуть системе генерации схему данных в БД и сгенерировать наборы данных.
И тогда нам остаётся только поддерживать схему данных в актуальном состоянии.
Думали о таком подходе? Это вообще реально сделать за адекватное время? Или этот подход не взлетит потому что…?
Бесшовно у вас переезжают только те приложения, у которых требования к безопасности около нуля. Есть ключи шифрования, есть всякие сохраненные данные в keyChain, которые тоже шифруются. Вы правда хотите, чтобы тот, кто получит доступ к вашему iCloud получил вообще всё? Второй фактор, конечно же, спасает в большинстве случаев, но это не панацея. Разработчики под iOS, macOS и прочие iPadOS не игнорируют этот функционал, а осознанно не реализуют его.
Понравилась статья, спасибо, но вот вам комментатор выше написал вполне аргументированную критику по вашей статье, а вы обижаетесь. Действительно, в контексте описания того, как работают финансовые продукты мне тоже кажется не совсем уместным использование художественных приёмов. Мне из вашего ответа ещё больше становится заметным, что вы лично в восторге от Apple Card, а это может влиять на объективность всего остального в статье.
Ну и портфель из 7 млн. держателей не обязательно же о чём-то говорит со знаком плюс, разве нет? Разве не может произойти коллапс, когда все эти люди ухудшат свой кредитный рейтинг?
Раньше в UI/API тестах я иногда использовал градацию по критичности тестов и в Allure для Java это было довольно удобно сделано. Тут не совсем ясно, как это затащить. Можете подсказать? Возможно, я упустил этот момент из статьи.
А вообще спасибо большое за статью, на нынешнем iOS проекте как раз на подходе UI тесты и я всё думал, получится ли прикрутить Allure = )
Учитывая количество совершенно разных обучающих платформ, "попасть в струю" можно за полгода - год. Было бы желание.
Если мы говорим о юридически значимом документе, то никаких предположений и догадок быть не может, потому что это допускает вольную трактовку. Нигде тут не написано, на что заказчик согласен и что он допускает. Соответственно, это можно использовать как памятку, которая болтается где-то среди пачки остальных соглашений, диаграмм и прочего, но лично я бы такое не подписал, не смотря на то, что с большинством пунктов согласен.
У меня такое наблюдение: весь прошлый год особо не занимался физкультурой. Всего пару раз прокатился на велосипеде и съездил покататься на сноуборде в ноябре. Состояние было постоянно вялое. Спал плохо, если верить браслету mi band. К концу года к общему спаду активности начал прирастать живот.
Начал ходить в бассейн раз в неделю. Плаваю обычно минут 40 — 60 в максимально возможном темпе. Так я теперь и спать лучше стал, и хватать на сон стало 7 часов, вместо 9. В течение дня энергии полно. Хватает и на работу и на домашние дела и на изучение Английского. Скинул 6 кг, сосредоточиться получается гораздо лучше и работы за день больше делаю. Так что двигаться точно надо.
Это звучит примерно так: «А зачем вы заказчику проект делали, если он в итоге не заплатил вам?». Я расшифрую: делали, потому что думали, что дадут, но в итоге не дали. Так бывает.
Если я правильно понял, то тут имеется в виду, что классический компьютер в конкретный момент времени может принимать одно из состояний, в то время как квантовый может принимать их все одновременно.
Ещё «Oddworld: Abe's Oddysee» тоже крутой была.
С Canon 60D + 70-200mm + 14mm + вспышка неудобно например на борде кататься. А так можно обойтись плоским блином-объективом и в небольшом жестком кофре ещё что-то типа телевика таскать.
Всё просто. Штатив нужен, да, а вот присобачить на него смартфон можно с помощью крепежа от селфи-палки. У меня он идеально вкручивается на контактную площадку штатива (у крепежа для палки отверстие такое же, как на зеркалках для крепления к штативу).
Но вот тут вопрос возникает — почему бы не описать правила и на основе этих правил создавать полный набор данных?
Например, есть таблица, в которой есть поля с типами NVARCHAR2 и NUMBER. Есть ещё какой-нибудь foreign key, primary key и т.д. Ещё поля с Nullable = true/false. Короче, есть спецификация данных. Мы можем на каждое из правил придумать проверки: не уникальное значение, отсутствие соответствующего значения для внешнего ключа и т.д.
Всё, на основе этого мы можем просто подсунуть системе генерации схему данных в БД и сгенерировать наборы данных.
И тогда нам остаётся только поддерживать схему данных в актуальном состоянии.
Думали о таком подходе? Это вообще реально сделать за адекватное время? Или этот подход не взлетит потому что…?
Пардон, а разве не скандинавская мифология?
Ещё раз извините, но разве не из комиксов?
Вполне вероятно, что выходной у моего чувства юмора наступил раньше, чем у меня.
</занудство>