Согласен, есть немного эмоциональной окраски.
Но Вы в качестве контраргументов используется тот же прием, только с негативным оттенком, поэтому мне кажется и получили пару минусов.
Вот здесь, например, автор явно не хотел ничего приукрасить, а наоборот указал о недостатке:
В Windows Phone SDK есть методы прокладки маршрутов внутри приложения.
Здесь имеется ввиду, что в контроле можно отобразить пошаговую навигацию?
Я это к тому, что просто прокладывать маршруты (отрисовка кривой с точки отправления до точки назначения) можно и в iOS.
Недостатком же можно считать достаточно длительный срок обработки платежей – примерно 5 банковских дней.
Может кто-нибудь знает, откуда берется такая большая временная задержка?
Как я понимаю денежный перевод — это полностью компьютеризированный процесс. Даже если предположить, что в день создается 10^5 — 10^6 переводов, то все равно непонятно, неужели это такие «тяжелые» операции, что сервера запаздывают на несколько дней?
Если не учитывать этот момент «20:00 Работа с электронной почтой» (неизвестно сколько времени на это уходит), то получается, что он работает менее 8 часов день:
2 дня в неделю: 17 (время ухода) — 8.75 (время прихода) — 0.5 (ланч) = 7.75 часов;
3 дня в неделю: 16 (время ухода) — 8.75 (время прихода) — 0.5 (ланч) = 6.75 часов.
А я то думал, что в Гугле работают по 10-12 часов в сутки.
Не совсем подходящий пример.
При продаже автомобилей производитель указывает расход топлива с учетом его массы. В моем случае даже было указано, что расход не учитывает вес пассажира и багажа.
Проблема ведь не в том, что часть памяти занято еще до использования девайса, а в том, что производитель видимо об этом умалчивает.
Вот, кстати, баг у Хабра: после статьи предлагает похожие публикации:
«Как мы делали кэшбэк-стартап в Кремниевой Долине 23 декабря в 08:59».
Это эта же статья, отправленная в черновики 3 дня назад, и теперь вышедшая под новым названием. В результате хабр отправляет по нерабочей ссылке.
Отличный сценарий для фильма «Социальная сеть 2».
Информативности ноль. Где технические детали? Где то, что указано в заголовке? Где хоть что-то, за что может зацепиться системно мыслящий читатель?
Я использовал два акааунта, один enterprise для подписи тестового приложения, второй аккаунт девелопера, которым подписывались приложение из app store, они никак между собой не связаны
Работает эта тема, только что проверил на своем приложении из AppStore:
В приложении из аппстора стоит bundle id com.becoast.gcar. На developer.apple.com в enterprise аккаунте создал wildcard bundle id: com.becoast.* (com.becoast.gcar — не позволяет создать, так как уже используется). Далее создал соответствующий provision профиль. В тестовом приложении указал bundle id: com.becoast.gcar и подписал его с provision для com.becoast.*. Залил на девайс, в результате приложение из аппстора перезаписано тестовым.
неважно откуда устанавливается приложение, bundle id для него создается на developer.apple.com. А там Вам не позволят использовать уже существующий bundle id.
Как написали выше, возможен вариант с использованием wildcard bundle id, но я не уверен, что приложение с wildcard bundle id (например, ru.habrahabr.*) перезапишет приложение с explicit bundle id (например, ru.habrahabr.habr). Думается мне, что они станут раздельно.
А что насчет Enterprise аккаунта?
Раньше Enterprise аккаунтам доступ в iTunesConnect не предоставлялся.
Появится ли такая возможность с учетов введения TestFlight?
Не знаю, написано ли там это. Я сделал такой вывод исходя из того, что Вы написали в статье.
Возможно я выразился слишком обобщенно. Нужно было сказать так:
«Исходя из информации в статье IB_DESIGNABLE компоненты нужно реализовать в коде, без использования xib, иначе будет выполняться двойное выделение памяти, что само по себе неправильно. Неважно 1 байт это или 1 мегабайт.»
По поводу #ifdef/#endif, не понял как это поможет решить проблему в runtime.
Все равно это мягко говоря «костыльно». По сути здесь наблюдается таже проблема, что и раньше: нельзя ложить в xib вью, которая реализована в другой xib.
Решалось это двумя способами:
1. Не использовать xib для вашей вью;
2. Добавлять вашу вью в коде, а не в xib.
IB_DESIGNABLE компоненты должны быть реализованы в коде, без использования xib.
Но Вы в качестве контраргументов используется тот же прием, только с негативным оттенком, поэтому мне кажется и получили пару минусов.
Вот здесь, например, автор явно не хотел ничего приукрасить, а наоборот указал о недостатке:
Здесь имеется ввиду, что в контроле можно отобразить пошаговую навигацию?
Я это к тому, что просто прокладывать маршруты (отрисовка кривой с точки отправления до точки назначения) можно и в iOS.
В статье идет речь об отличиях.
Отличие — не обязательно преимущество.
Может кто-нибудь знает, откуда берется такая большая временная задержка?
Как я понимаю денежный перевод — это полностью компьютеризированный процесс. Даже если предположить, что в день создается 10^5 — 10^6 переводов, то все равно непонятно, неужели это такие «тяжелые» операции, что сервера запаздывают на несколько дней?
2 дня в неделю: 17 (время ухода) — 8.75 (время прихода) — 0.5 (ланч) = 7.75 часов;
3 дня в неделю: 16 (время ухода) — 8.75 (время прихода) — 0.5 (ланч) = 6.75 часов.
А я то думал, что в Гугле работают по 10-12 часов в сутки.
При продаже автомобилей производитель указывает расход топлива с учетом его массы. В моем случае даже было указано, что расход не учитывает вес пассажира и багажа.
Проблема ведь не в том, что часть памяти занято еще до использования девайса, а в том, что производитель видимо об этом умалчивает.
1. Ссылка на оригинал;
2. Ссылка на Google Translate.
«Как мы делали кэшбэк-стартап в Кремниевой Долине 23 декабря в 08:59».
Это эта же статья, отправленная в черновики 3 дня назад, и теперь вышедшая под новым названием. В результате хабр отправляет по нерабочей ссылке.
Информативности ноль. Где технические детали? Где то, что указано в заголовке? Где хоть что-то, за что может зацепиться системно мыслящий читатель?
В приложении из аппстора стоит bundle id com.becoast.gcar. На developer.apple.com в enterprise аккаунте создал wildcard bundle id: com.becoast.* (com.becoast.gcar — не позволяет создать, так как уже используется). Далее создал соответствующий provision профиль. В тестовом приложении указал bundle id: com.becoast.gcar и подписал его с provision для com.becoast.*. Залил на девайс, в результате приложение из аппстора перезаписано тестовым.
Как написали выше, возможен вариант с использованием wildcard bundle id, но я не уверен, что приложение с wildcard bundle id (например, ru.habrahabr.*) перезапишет приложение с explicit bundle id (например, ru.habrahabr.habr). Думается мне, что они станут раздельно.
Раньше Enterprise аккаунтам доступ в iTunesConnect не предоставлялся.
Появится ли такая возможность с учетов введения TestFlight?
Возможно я выразился слишком обобщенно. Нужно было сказать так:
«Исходя из информации в статье IB_DESIGNABLE компоненты нужно реализовать в коде, без использования xib, иначе будет выполняться двойное выделение памяти, что само по себе неправильно. Неважно 1 байт это или 1 мегабайт.»
По поводу #ifdef/#endif, не понял как это поможет решить проблему в runtime.
Решалось это двумя способами:
1. Не использовать xib для вашей вью;
2. Добавлять вашу вью в коде, а не в xib.
IB_DESIGNABLE компоненты должны быть реализованы в коде, без использования xib.