Иногда ложки действительно нет

Вы пытались ответить на весьма интересный вопрос: "А не является ли весь зримый (и незримый) мною мир - плодом моего же воображения, и при этом во Вселенной я один?" Вопрос, очевидно, не имеет ответа, хотя поиски его сильно повлияли не только на философию бытия, но и на культуру всего человечества. Можно обратиться за примерами к кинематографу: "Матрица", "Начало", "Шоу Трумана",.. Они подчерпнули часть своих идей именно в этом вопросе, сводя ответ на него его к поиску той модели "вселенной", маскирующей частью которой являлся мир, окружающий главных героев. Главной в этих поисках была не методологическая трудность, а "очевидность" отсутствия необходимости задаваться подобными вопросами. Проще говоря, какому человеку в здравом уме прийдет в голову мысль, что он живет виртуально? Шаг от неведения к постижению истины подобных масштабов - интеллектуальный шок для любого человека. Мне довелось ощутить миллиардную долю потрясения от открытия подобного факта.

В 2009 году я работал техником в единственном, по сути, официальном сервисном центре Nokia в России. Занимался непосредственно ремонтом телефонов. Процедура оформления ремонта требовала по окончанию работ над аппаратом снять с него специальный код (VID-код, если не изменяет память). Все просто - подключил телефон к компьютеру, нажал пару кнопок и увидел четырехзначное число, полученное с сервера Nokia. За день через тебя проходит 20-40 таких телефонов, быстро перестаешь обращать внимание на эти числа. Но в один прекрасный момент я понял, что числа выдаются не случайным образом. Два последовательно снятых кода оказывались очень близки. Дальше все было просто: благодаря кодам, я знал среднюю мировую активность техников в сервисах Nokia, мог оценить среднюю производительность одного техника-ремонтника (по нашему офису), отношение количества техников к количеству всего персонала нашего сервиса, после чего получал приблизительное число сотрудников сервисных центров Nokia в мире.

Интерес представляет не само число (по моим подсчетам получалось 100-120 тыс. сотрудников), а принципиальная возможность его вычислить, возможность понять, что ты - часть целого, оценить его размеры. Способность окинуть более общим взглядом систему, частью которой ты являешься, меня тогда очень поразила. А ведь поводом для таких выводов послужило лишь неприметное число. Не сомневаюсь, вокруг нас очень много подобных деталей, которые могут дать ответы на самые различные вопросы. Надо лишь стараться их увидеть.

DevelopBrief #2

Мания перетаскивания

Простой вопрос - как в приложении с TabBarController в XCode 4 изменить тип вкладки с UIViewController на UINavigationController? Никак (поправьте, если ошибаюсь). Панель Utilities этого сделать не позволяет (как это было в XCode 3.x). Через меню тем более не поменять. Единственный вариант - перетащить в Interface Builder иконку UINavigationController из Object Library на Tab Bar. Я, признаюсь, не догадался. Как-то не очень интуитивно. Впрочем, удивляться не следует. Новый XCode падок на "перетасканивания": связь кода с элементами интерфейса в IB (удобно), создание шаблонов кода (не очевидно). Думаю, что еще наткнусь на случаи применения такого подхода.


Когда уходят строки

Столкнулся с одной особенностью мехнизма изменения таблиц в iOS. Попытка удаления пользователем строки из таблицы обрабатывается сообщением с приблизительно следующим содержанием:

В текущем проекте необходимо сделать наброски интерфейса, чтобы продемонстрировать начальству работу приложения "вхолостую". Для простоты не стал использоваться dataSource, а просто указал количество строк в единственной секции и всегда возвращал одну и ту же ячейку. При попытке удаления строки получил прекрасное сообщение об ошибке:

Invalid update: invalid number of rows in section 0. The number of rows contained in an existing section after the update (5) must be equal to the number of rows contained in that section before the update (5), plus or minus the number of rows inserted or deleted from that section (0 inserted, 1 deleted)

Причина появления таких грязных ругательств в том, что при вызове deleteRowsAtIndexPaths: withRowAnimation: система перед тем как удалить строку проверяет выполнение равенства X + Y = Z, где X - конфигурация строк в каждой секции до изменения, Y - те, операции, которые подразумевает вызываемое сообщение (в данном случае - удаление 1 строки), Z - конечное состояние секций. Вызываемое сообщение подразумевает, что dataSource уже изменен, поэтому если в обычном рабочем варианте переставить строки так:
то мы получим ту же ошибку.

Введение счетчика удаленных/добавленных строк быстро разрешает конфуз (ключевое слово - "быстро").

Ничего особенного в этом наблюдении нет, но все же приятно заглянуть в устройство некоторой системы, смотря на нее лишь снаружи :)