Совершенно правильно видите! В серединке там mobile + сиськи, пониже все серьезнее — XXX + сиськи… Веселое было собрание! Как минимум, для одной половины участвующих)) Жаль, этих «стиков» на футболке нет… Футболка вообще странная, надпись «я мужик» и аж три мужских имени рядом… Странный мужик… Стики были бы логичнее!
Прикалываюсь, да. Это невозможно пропустить! А мероприятие полезное) Почему бы и нет.
Наверное, я немного не так выразился по поводу синхронизации. Я понимаю, что каждый сэмпл маркируется некой меткой времени, я о другом: как часто пишутся сэмплы, чтобы достичь хорошего качества позиционирования, но при этом не разрядить в ноль батарею и не забить до отказа свободное пространство на «диске»? Каждую секунду, каждые 10 секунд? И насколько длинными вы решили делать сэмплы, чтобы получалось с высокой точностью выполнять позиционирование, не расходуя тонну мегабайт свободного места? Допустим, если я от пользователя получаю 100 сэмплов с метками времени, и от другого ту же сотню, то потом я отброшу все сэмплы, не совпадающие по серверному времени, и проанализирую только те, что засинхронены. Верно же? А вот интервал какой между записью?
Любопытный метод, я только не уловил один момент: каким образом вы анализируете «похожесть» двух сэмплов, если два устройства могут записать звук с неким рассинхроном по времени? Одно устройство может начать запись в момент N, а второе (в силу разных причин — поздно нажали кнопку, или устройство подвисло, или еще что, и получается момент N + k). Как их засинхронить для сравнения? Также, правильно ли я понимаю, что понять дистанцию друг от друга при таком методе позиционирования — довольно проблематичная задача?
Мне он вообще нравится. Это дело вкуса, кому как. Кто-то тащится, кто-то ненавидит. Всегда так было, по всем элементам дизайна, не только с вырезом (вспомните скругленные грани, потом расположение антенн, ну, и так далее). Всегда работает принцип «всем не угодишь».
Существует множество вариаций MVC, например, MVVM и MVP. О них стоит почитать, но принцип их работы схож с MVC
Не совсем. MVC — архитектурный паттерн, два других, которые вы назвали, — это не вариации, а два других архитектурных паттерна. Лучше бы написать как-то так: «существуют и другие архитектурные шаблоны проектирования, такие, как MVP, MVVM, VIPER, но их рассмотрение выходит за рамки данной статьи». Принципы у них ни разу не схожи.
пользователь пользователю может послать денежку реальную, но только как подарок
Не понял. Вы планируете в веселой ферме передавать между игроками реальную валюту? Я бы поостерегся от такой «веселой фермы».
деньги должны проходить как IAP и при этом от такого платежа разработчик не имеет права от этого перевода откусить себе немного денежек
В смысле? Вы пробовали реализовывать IAP? «Откусывает» себе Apple в виде 30% от любой сделки, остальные деньги поступают разработчику, а не наоборот.
можно эксплойтить — будут эксплойтить
Ну, пока что-то не особо активности за много-много лет. А с дополнительными ограничениями денежных потоков будет еще сложнее мухлевать. И это правильно.
что мешает встроить в веселую ферму вычислитель бинарных опционов
Модераторы на пре-модерации вам помешают. Приложение попросту не пройдет в магазин. А если в исключительных случаях вам повезет, и его пропустят, то либо позже забанят сами Apple, либо на вас накатают жалобу пользователи, и результат будет тот же.
Имхо, это выглядит более, чем корректно. Приложения, размещенные в App Store на их площадке, должны торговать внутренними покупками только через In-App Purchase API. Это было прописано и раньше, только, видимо, многие стали делать «в обход системы» через собственные серверы, чтобы не платить Apple за площадку и их API, и модераторы эппла перевели это в отдельный пункт в виде жесткого ограничения. Я лично считаю, что правильно сделали. Раз уж я использую лицензионное размещение на торговой площадке, то я должен подчиняться правилам этой площадки, а не изыскивать средства сэкономить и как-то надуть систему. Любая покупка должна проходить через IAP, это правильно. О налогах и сборах разработчики предупреждены заранее, не хотите — не размещайтесь)) А по поводу запрета передачи денег от игрока к игроку — это банальная защита от накруток и продажи денег «мимо кассы», как уже верно написали. Потому что тогда у одного могут быть средства, второй хочет их купить, переводит ему реальные деньги, а получает внутриигровые — очень распространенная практика среди компьютерных MMO-игр. Так что с точки зрения Apple все очень даже правильно. И я это поддерживаю, меньше махинаций.
Masonry не смотрели? Я применяю его сам и часто встречаю его в компаниях, где приходилось работать. Полностью устраивает в том, что касается autolayout. Можете сравнить вашу разработку в том числе и с ним? Для понимания. С остальными движками из вашего примера я не работал, думаю, что у них более широкие возможности, но все же полезно было бы узнать об их преимуществах относительно Masonry (он же SnapKit).
Необъективное тестирование будет. Будет сильно съедаться заряд батареи, очень сильно понизится производительность (за счет записи экрана), не говоря о том, что даже при согласии человека на такое тестирование в микрофон может проскочить то, что он не захочет отправлять (может, он дома находится, или еще где, что уже относится к частной жизни). Да и далеко не каждый комментирует процесс тестирования вслух, это как раз исключение из общего правила (ну либо когда приложение настолько плохое, что без матов тестить не получается, но это тоже скорее исключение). Имхо, очень сомнительный вариант. Сбор обратной связи в виде просто вручную отправленных тестерами ошибок — этого более, чем достаточно, особенно если система обратной связи встроена прямо в приложение («потрясите телефон, чтобы отправить баг», и им подобные).
Да вот конкретно на моем опыте как-то ни разу не получалось этой самой «долгосрочной перспективы» достаточной длительности, чтобы все сопутствующие разработке проблемы (в основном — потери времени на сборку, подлагивания, частые краши и отвал подсветки — на обжсях да, я изредка ее ловил, но это крайне редко) перекрылись плюсами от свифта. Это не говоря о переходе на новые версии, о потенциальных проблемах с поиском зависимостей, и так далее. Ну и размер, конечно, с загрузкой аппа и пересборкой никто не отменял, тоже верно. Особенно бесит адово долгая архивация приложения, когда приходилось делать проекты в CI — застрелиться можно. По скорости исполнения — вот имхо, на обжси написать приложение, работающее быстро, не составляет никаких проблем, были бы навыки. Да, в свифте, конечно, есть приятные конструкции, упрощающие (хотя иногда и нехило увеличивающие, не будем скромничать, пламенный привет составным генерикам в экстеншенах) код, но потери времени на все вышеперечисленное в моей практике обычно перекрывают экономию в скорости написания кода. Хотя соглашусь с вами, что каждый человек и каждая команда вольны выбирать то, что им больше нравится.
я и представить себе не мог, сколько проблем нам в итоге доставит Swift
А сколько еще доставит в будущем… Жаль, что ни одна компания, которая решает насильно внедрить Swift в продакшн-разработку, никогда не прислушивается к доводам «не надо, рано еще, подождите, проблем будет больше, чем пользы, остановитесь...». На моей памяти так. Кого ни убеждал — всегда не соглашаются. И лишь собственные грабли, на которые, такое ощущение, каждая компания должна наступить в обязательном порядке при iOS-разработке, «открывает глаза», да и то не всегда, к сожалению. Язык неплох, но рано ему в продакшн для серьезных проектов. Рано. Я сам разрабатываю для iOS еще с 4 ее версии, видел и кодил на всех версиях Swift, и пока еще ничего особо хорошего в нем не увидел, что перекрыло бы сопутствующие минусы.
Смотреть-то я смотрел, поэтому и вопрос задал. Там указано, где проводились тесты, это да, но на странице с этими тестами я нигде не нашел подтверждения, что конкретно ваша библиотека и алгоритм работают именно с такой точностью. Поймите правильно, в заголовке указана вполне конкретная точность — а конкретные цифры требуют конкретного подтверждения, иначе это похоже на цифру, взятую с потолка.
От некоторых вариантов исполнения, особенно «сине-красных», аж на пару секунд менялось цветовосприятие, настолько они вырвиглазные. Дизайнерским изыском их сложно назвать) Но в целом примеры приятные, почитать интересно. За статью спасибо!
Прикалываюсь, да. Это невозможно пропустить! А мероприятие полезное) Почему бы и нет.
private. У этого короткого кода есть вполне конкретный смысл. Почитайте про модификаторы.Не совсем. MVC — архитектурный паттерн, два других, которые вы назвали, — это не вариации, а два других архитектурных паттерна. Лучше бы написать как-то так: «существуют и другие архитектурные шаблоны проектирования, такие, как MVP, MVVM, VIPER, но их рассмотрение выходит за рамки данной статьи». Принципы у них ни разу не схожи.
Не понял. Вы планируете в веселой ферме передавать между игроками реальную валюту? Я бы поостерегся от такой «веселой фермы».
В смысле? Вы пробовали реализовывать IAP? «Откусывает» себе Apple в виде 30% от любой сделки, остальные деньги поступают разработчику, а не наоборот.
Ну, пока что-то не особо активности за много-много лет. А с дополнительными ограничениями денежных потоков будет еще сложнее мухлевать. И это правильно.
Модераторы на пре-модерации вам помешают. Приложение попросту не пройдет в магазин. А если в исключительных случаях вам повезет, и его пропустят, то либо позже забанят сами Apple, либо на вас накатают жалобу пользователи, и результат будет тот же.
А сколько еще доставит в будущем… Жаль, что ни одна компания, которая решает насильно внедрить Swift в продакшн-разработку, никогда не прислушивается к доводам «не надо, рано еще, подождите, проблем будет больше, чем пользы, остановитесь...». На моей памяти так. Кого ни убеждал — всегда не соглашаются. И лишь собственные грабли, на которые, такое ощущение, каждая компания должна наступить в обязательном порядке при iOS-разработке, «открывает глаза», да и то не всегда, к сожалению. Язык неплох, но рано ему в продакшн для серьезных проектов. Рано. Я сам разрабатываю для iOS еще с 4 ее версии, видел и кодил на всех версиях Swift, и пока еще ничего особо хорошего в нем не увидел, что перекрыло бы сопутствующие минусы.
Пардон, вопрос, а кто оценку точности проводил?..