Не, не совсем. Это как если бы Сергеевич взял налог на болванки, а потом эти болванки были бы доступны «на посмотреть» совершенно бесплатно, т.к. уже все потребители заплатили за свое право просмотра.
Вы об отличиях "-" и "+", а автор пишет о том, с какого перепугу вообще понадобились эти ±, потому что обычное объявление методов уже «занято» чистым C. Можно было, конечно, сделать вроде С++ и писать «void Class::Method(void) {}» или другие соглашения принять, но авторы выбрали такой подход.
Нормально, речь ведь идет о простых и интересных фактах а не о глубинных особенностях рантайма или синтаксическом сахаре, для этого лучше документация подходит.
Я, например, никогда не задумывался почему именно .m, или почему объявление методов начинается с "-" или "+". О соглашении насчет «get» тоже было интересно узнать.
Уверен, что именно так. Apple в лицензионном соглашении наверняка переводит все стрелки на разработчика. Это как с DMCA, если заметил что твое лого или торговую марку используют без разрешения, пиши cease and desist order на имя Apple, и Apple обязан уведомить разработчика. Если в отведенные сроки конфликт не улажен, Apple снимает приложение с продажи.
В коментах ниже сказано, что разработчик получил письмо только вчера ночью, т.е. отсчет времени только начался, а РЖД уже выкатило пресс-релиз, якобы все мыслимые и немыслимые сроки прошли, мы подаем в суд! Да и вообще, если РЖД считает что понесло финансовые потери, они могут потребовать компенсации от разработчика, с какого перепугу кидаться на Apple, не ясно.
Уж больно вся эта новость похожа на какой-то вброс, через пару дней, скорее всего, узнаем от РЖД что они ни в какой суд не подавали.
Вот то-то и оно. Раз письмо пришло только ночью, значит в нем предупреждение насчет сроков и все такое. И телега РЖД про «Apple не отвечает на наши запросы» — бред. РЖД бежит впереди паровоза чтобы себя пропиарить, или вообще вся новость про суд — утка.
Не понял, если честно. Вот у меня был момент, использовал торговую марку (trademark) в названии приложения, которая зарегистрирована во всем мире.
Владелец торговой марки нанял юристов, юристы написали Apple, Apple форварднуло письмо мне с просьбой предоставить какое-либо доказательство что конфликт улажен, иначе через 2 недели приложение уберут.
Я убрал все упоминания этой торговой марки, убрал приложение из AppStore пока не примут новую версию, отписался Apple и тем юристам. Юристы угрожали дополнительными санкциями и штрафами, вплоть до суда, если ничего не сделаю. К стастью не стали заморачиваться, я не заработал достаточно денег чтобы их сильно заинтересовало продолжение. Но в суд обещали подать на меня, не на Apple.
А РЖД вместо того, чтобы пойти судом против тов. Сироткина, решить вопрос простым запугиванием, решили во что бы то ни стало срубить бабла с Apple, при этом не понятно из новостей, прошли ли все положенные сроки положенные для удаления приложения. Может РЖД грамотно выбрало период рожденственских и новогодних каникул, чтобы Apple уж точно во время с ситуацией не разобралось :)
Мне кажется юристы Apple завернут эту «жалобу» по самое нехочу еще до начала каких-либо судебных разбирательств, а РЖД напишет что-то вроде «конфликт улажен по соглашению сторон. условия не разглашаются.» или переключатся на разработчика, но там, ясное дело, миллионами и не пахнет.
P.S. срочно выпускайте приложение с «Сироткин» в названии, бесплатный пиар в самом разгаре. Только бы потом разработчик Сироткин на вас в суд не подал.
Да, не подумал немного о том, что рандом может быть по-разному реализован, ну чисто в теории на разных ОС может по умолчанию использоваться разный алгоритм. Если все это дело кросс-платформенное, нужно убедиться что у всех одна и та же реализация, если где-то есть разница, найти подходящую библиотеку.
Так ведь указано, прямо в заголовке статьи: «iOS».
Из вашего списка остается только cocos2d-iphone или cocos2d-x (последнее — с натяжкой), но уж точно не Python.
Но все равно придется хранить все локально. На случай если нет интернета, нужно же хоть что-то показать пользователю, хотя бы данные на момент прошлого запуска. Другая проблема — если при попытке обновить лидерборд или ачивки ничего не получится, тогда часть прогресса игрока просто потеряется. Нужно добавлять механизм, вроде кеширования, если не отправились данные, сохранить их локально и попробовать отправить когда игра снова будет онлайн.
Даже если при генерации уровней используется random, все равно можно их синхронизировать. При начале игры один игрок генерирует seed и делится с другим. В результате получается такая себе квантовая запутанность, у обоих игроков random выдает одни и те же результаты, это, конечно, если количество и последовательность random одинакова у обоих клиентов и не зависит от каких-то дополнительных случайных факторов.
У меня, например, была колода карт и нужно ее случайным образом перемешать у всех игроков в мультиплеере, и чтобы был один и тот же результат. Выдал всем один seed, «посеял» его в srand и отпала необходимость передавать всю колоду от сервера клиентам.
Нехилое сравнение ) А сколько стоило создание Аватара и 3D полнометражек по сравнению с MLP?
Да и к тому же MLP можно назвать «казуальным» продуктом, а тот же Аватар или Monsters Inc. — по одной полнометражке на 3-4 года.
Так для всех онлайн курсов указан длинный список литературы для самостоятельного и более глубокого обучения.
Да и как-то вы запутали свой комент :) Сначала вы не видите чем курсы лучше просто книжки, потом вдруг сами же перечисляете плюсы онлайн курсов, а потом, внезапно, говорите об общении с преподавателем, хотя изначально речь шла о сравнении «онлайн курсы vs только книжка».
Пожалуй, в плюсы еще можно добавить видео лекции, многим так легче воспринимать материал.
Или, например, меня заинтересовала тема Machine Learning. Куда мне податься? Где найти материалы, какая из множества книжек самая лучшая для самостоятельного обучения? А тут coursera предлагает замечательный курс, где описываются практически все подходы к ML актуальные на сегодняшний день, более того, есть возможность выполнять реальные практические задания и т.д. Отличное место чтобы начать знакомство с темой.
Да не обязательно дизайн должен какую-то задачу решать. Math clock тоже пример дизайна, который не решает никакой практической задачи, также как и большая часть гиковских безделушек или даже произведений исскуства, раз на то пошло.
ade написал комент ради комента, чисто из занудства :) Ясен пень мало кто реально использует бумажный hex календарь по прямому назначению, просто картинка, висит себе, глаз раудет, привлекает внимание окружающих, создает атмосферу, и выполняет множество других непрактичных задач.
Достаточно специфический перевод «инсульт вашего интеллекта». Я так понял это прямая калька с «insult your intellect», и «insult» в данном контексте лучше перевести как «оскорблять» или хотя бы «недооценивать ваши умственные способности».
Это мы, похоже, о каких-то разных «версиях» говорим.
Скрипты обычно увеличивают или изменяют CFBundleVersion, по-крайней мере у меня такой был. Этот скрипт был в Build Phases и запускался по Cmd+R каждый раз, в результате на двух девайсах получались приложения несовместимые через Game Center из-за CFBundleVersion.
Попробуйте этот или любой другой подход в проекте, который использует мультиплеер через Game Center.
Если сначала собрать и установить на одном устройстве, потом на другом, номер билда будет разный на каждом устрйсте и протестировать мультиплеер через Game Center не получится, потому что версия приложения должна совпадать, вплоть до номера сборки. Так получается если запускать через Cmd+R каждый раз, пол умолчанию все скрипты из Build Phase запустятся.
Слабые места связанные со строковыми идентификаторами есть. Все верно по поводу observeValueForKeyPath:... и теми случаями, когда суперкласс зарегистрировался на тот же key path. Но, одно большое «но», даже много их…
«Слабость» этих мест определяется слабостью программиста. И это беда уже не Objective-C или конкретных API. На том же C неграмотный прогер наваяет такого, что просто ужас, одни только malloc или memcpy чего стоят, на embedded платформах это вообще опаснейшее «оружие». Приходилось сталкиваться бесчисленное множество раз, когда люди не могут по-человечески выделить и освободить кусок памяти, а то и копируют туда больше чем положено.
Судя по вашим комментам, приходится иметь дело с аутсорсом и недостаточно грамотными разработчиками. Это беда, но новое и более навороченное решение с использованием C++ и шаблонов, имхо, только увеличит вероятность ошибок. Если эти ребята порют бока с обычным KVO и NC, так ли легко им будет разобраться с вашим кодом?
И раз уж речь идет про аутсорс. Использование KVO и NC — гораздо более безопасный подход, хотя бы потому что им пользуются все, он хорошо документирован и т.д. Поставьте себя на место аутсорсера, которому достанется ваш код, по непонятным ему причинам весь сплошь из .mm файлов и с какой-то кастомной имплементацией observing-а.
Насчет низкой производительности KVO и NC, кстати, я по ссылкам ничего не нашел.
Как вывод, это хорошо, что есь более удобный и (возможно) более понятный способ сделать KVO и уведомления. Только по этой статье и по коментариям к ней я насчитал уже как минимум 3 реализации. Но, лично я не хотел бы видеть ни одной из них в следующем проекте, который мне придется поддерживать или принимать :) Пусть уж лучше будут KVO и NC со всеми их хорошо известными недостатками, чем каждый раз что-то новое и кто знает насколько хорошее.
так же идентификация событий идёт по строковому идентификатору, что не есть хорошо. Ну и производительность такого решения оставляет желать лучшего, как и API.
и
но API сводит все его прелести на нет
Хотя бы ссылками на обсуждение где-либо, какими-либо benchmark-ами, которые показывают плохую производительность и т.п. Другими словами, ваша статья начинается с удтверждения «Notification Center и KVO — плохо» и это подается как всем известный и неоспоримый факт. Почему строковый идентификатор это плохо? Насколько «медленно» работает Notification Center? Почему API у NC и KVO «плохой» и «сводит все прелести на нет»?
Без подробных обоснований создается впечатление что вы пытаетесь потянуть за собой то, что считается «usual way» для Observer-а в Flash только потому что вы к этому привыкли.
Я, например, никогда не задумывался почему именно .m, или почему объявление методов начинается с "-" или "+". О соглашении насчет «get» тоже было интересно узнать.
В коментах ниже сказано, что разработчик получил письмо только вчера ночью, т.е. отсчет времени только начался, а РЖД уже выкатило пресс-релиз, якобы все мыслимые и немыслимые сроки прошли, мы подаем в суд! Да и вообще, если РЖД считает что понесло финансовые потери, они могут потребовать компенсации от разработчика, с какого перепугу кидаться на Apple, не ясно.
Уж больно вся эта новость похожа на какой-то вброс, через пару дней, скорее всего, узнаем от РЖД что они ни в какой суд не подавали.
Владелец торговой марки нанял юристов, юристы написали Apple, Apple форварднуло письмо мне с просьбой предоставить какое-либо доказательство что конфликт улажен, иначе через 2 недели приложение уберут.
Я убрал все упоминания этой торговой марки, убрал приложение из AppStore пока не примут новую версию, отписался Apple и тем юристам. Юристы угрожали дополнительными санкциями и штрафами, вплоть до суда, если ничего не сделаю. К стастью не стали заморачиваться, я не заработал достаточно денег чтобы их сильно заинтересовало продолжение. Но в суд обещали подать на меня, не на Apple.
А РЖД вместо того, чтобы пойти судом против тов. Сироткина, решить вопрос простым запугиванием, решили во что бы то ни стало срубить бабла с Apple, при этом не понятно из новостей, прошли ли все положенные сроки положенные для удаления приложения. Может РЖД грамотно выбрало период рожденственских и новогодних каникул, чтобы Apple уж точно во время с ситуацией не разобралось :)
Мне кажется юристы Apple завернут эту «жалобу» по самое нехочу еще до начала каких-либо судебных разбирательств, а РЖД напишет что-то вроде «конфликт улажен по соглашению сторон. условия не разглашаются.» или переключатся на разработчика, но там, ясное дело, миллионами и не пахнет.
P.S. срочно выпускайте приложение с «Сироткин» в названии, бесплатный пиар в самом разгаре. Только бы потом разработчик Сироткин на вас в суд не подал.
Из вашего списка остается только cocos2d-iphone или cocos2d-x (последнее — с натяжкой), но уж точно не Python.
Но все равно придется хранить все локально. На случай если нет интернета, нужно же хоть что-то показать пользователю, хотя бы данные на момент прошлого запуска. Другая проблема — если при попытке обновить лидерборд или ачивки ничего не получится, тогда часть прогресса игрока просто потеряется. Нужно добавлять механизм, вроде кеширования, если не отправились данные, сохранить их локально и попробовать отправить когда игра снова будет онлайн.
У меня, например, была колода карт и нужно ее случайным образом перемешать у всех игроков в мультиплеере, и чтобы был один и тот же результат. Выдал всем один seed, «посеял» его в srand и отпала необходимость передавать всю колоду от сервера клиентам.
Да и к тому же MLP можно назвать «казуальным» продуктом, а тот же Аватар или Monsters Inc. — по одной полнометражке на 3-4 года.
Да и как-то вы запутали свой комент :) Сначала вы не видите чем курсы лучше просто книжки, потом вдруг сами же перечисляете плюсы онлайн курсов, а потом, внезапно, говорите об общении с преподавателем, хотя изначально речь шла о сравнении «онлайн курсы vs только книжка».
Пожалуй, в плюсы еще можно добавить видео лекции, многим так легче воспринимать материал.
Или, например, меня заинтересовала тема Machine Learning. Куда мне податься? Где найти материалы, какая из множества книжек самая лучшая для самостоятельного обучения? А тут coursera предлагает замечательный курс, где описываются практически все подходы к ML актуальные на сегодняшний день, более того, есть возможность выполнять реальные практические задания и т.д. Отличное место чтобы начать знакомство с темой.
Да, cocoapods уже чуть ли не стандарт для iOS разработки, по-крайней мере для меня точно.
А git и все-все-все для Mac OS есть в homebrew.
ade написал комент ради комента, чисто из занудства :) Ясен пень мало кто реально использует бумажный hex календарь по прямому назначению, просто картинка, висит себе, глаз раудет, привлекает внимание окружающих, создает атмосферу, и выполняет множество других непрактичных задач.
Скрипты обычно увеличивают или изменяют CFBundleVersion, по-крайней мере у меня такой был. Этот скрипт был в Build Phases и запускался по Cmd+R каждый раз, в результате на двух девайсах получались приложения несовместимые через Game Center из-за CFBundleVersion.
Если сначала собрать и установить на одном устройстве, потом на другом, номер билда будет разный на каждом устрйсте и протестировать мультиплеер через Game Center не получится, потому что версия приложения должна совпадать, вплоть до номера сборки. Так получается если запускать через Cmd+R каждый раз, пол умолчанию все скрипты из Build Phase запустятся.
«Слабость» этих мест определяется слабостью программиста. И это беда уже не Objective-C или конкретных API. На том же C неграмотный прогер наваяет такого, что просто ужас, одни только malloc или memcpy чего стоят, на embedded платформах это вообще опаснейшее «оружие». Приходилось сталкиваться бесчисленное множество раз, когда люди не могут по-человечески выделить и освободить кусок памяти, а то и копируют туда больше чем положено.
Судя по вашим комментам, приходится иметь дело с аутсорсом и недостаточно грамотными разработчиками. Это беда, но новое и более навороченное решение с использованием C++ и шаблонов, имхо, только увеличит вероятность ошибок. Если эти ребята порют бока с обычным KVO и NC, так ли легко им будет разобраться с вашим кодом?
И раз уж речь идет про аутсорс. Использование KVO и NC — гораздо более безопасный подход, хотя бы потому что им пользуются все, он хорошо документирован и т.д. Поставьте себя на место аутсорсера, которому достанется ваш код, по непонятным ему причинам весь сплошь из .mm файлов и с какой-то кастомной имплементацией observing-а.
Насчет низкой производительности KVO и NC, кстати, я по ссылкам ничего не нашел.
Как вывод, это хорошо, что есь более удобный и (возможно) более понятный способ сделать KVO и уведомления. Только по этой статье и по коментариям к ней я насчитал уже как минимум 3 реализации. Но, лично я не хотел бы видеть ни одной из них в следующем проекте, который мне придется поддерживать или принимать :) Пусть уж лучше будут KVO и NC со всеми их хорошо известными недостатками, чем каждый раз что-то новое и кто знает насколько хорошее.
и
Хотя бы ссылками на обсуждение где-либо, какими-либо benchmark-ами, которые показывают плохую производительность и т.п. Другими словами, ваша статья начинается с удтверждения «Notification Center и KVO — плохо» и это подается как всем известный и неоспоримый факт. Почему строковый идентификатор это плохо? Насколько «медленно» работает Notification Center? Почему API у NC и KVO «плохой» и «сводит все прелести на нет»?
Без подробных обоснований создается впечатление что вы пытаетесь потянуть за собой то, что считается «usual way» для Observer-а в Flash только потому что вы к этому привыкли.