Заглянуть гуглу под юбку...

Еще зимой возникла идея:
Есть гугл, у него есть своя сокращалка goo.gl, а значит есть вероятность, что сотрудники гугла для рабочих целей ее же и используют. И если так, то через нее наружу торчат те вещи, которые торчать туда не должны. Дальше все просто:


За 17 часов пробежался по 1 млн. сокращенных урлов (относительно свежих - февраль-март 2012), "развернув" их. Быстрее не получалось из-за банов + совсем не хотелось связываться с распределенным сбором. К сожалению, живых (у которых что-то есть за душой) оказалось не так много - 93к.


Из них вычленил домены, содержащие google, отсортировал по частоте и среди самых редких нашел следующий:
salus.prodmon.global.ls.google.com:3350


Приведя полный урл в читабельный вид, увидел следующее:

Параметры format подтвердили, что я попал на гугловскую девелоперскую машину. Причем похоже, что конкретный урл вел на dev-копию google buzz. "Вел", потому что домен дохлый, а сам гугл лишь говорит нам, что с данного урла ходили в документацию python с февраля 2009 по май 2010.

Заголовок "Live users connected to Oz" весьма интересен, но ничего нового не дал.

Вот, собственно и все, что удалось отыскать. Больше интересных урлов не нашлось :(

Главной целью было проверить гипотезу, которая, собственно, успешно подтвердилась - внутри гугла используют публичную сокращалку, что потенциально ведет к микро-утечкам.

Оставлю здесь архив с развернутыми ссылками, может пригодится кому.

Clck.ru for Safari

Пролог
Новый год начался с третьей попытки пересесть с Chrome на Safari (в 2 часа ночи 1 января). Естественным образом пошел за расширениями и, с печалью посмотрев на имеющиеся сокращалки урлов, решил повеселиться и написать свое.

Акт 1. Подготовка
Читал доки, смотрел видео с WWDC 2010 и 2011. Все осложнялось моими никудышными знаниями html + css + js, но от это только подогревало интерес.

Акт 2. Основа
Примерно за день накидал саму сокращалку - жмешь на кнопку, получаешь ссылку. Дел там на час максимум, но не все шло гладко. Да и за всякими примитивностями по части js лазил на Stackoverflow.
Когда внешний вид под Mac меня удовлетворил, я пошел посмотреть как все смотрится на винде и очень порадовался увиденному:

Занес верстку под винду в список багов и поехал дальше

Акт 3. Горячие клавиши
Быстро нашел способ имплементации (через встраиваемый в просматриваемые страницы код), но тут началось странное - никак не хотела работать пересылка сообщений из встраиваемого кода в general page. Час долбаний ни к чему не привел, я решил заняться этим потом, как вдруг на одной из страниц вылез дебажный алерт, говорящий, что сообщение дошло-таки.
Для надежности стал удалять/ставить расширение (простая перезагрузка не спасала), чтобы не было странностей с сообщениями. Помогло :)

Акт 4. История
Использовал html5 local storage для хранения. Поставил лимит на количество хранимых ссылок. Ничего интересного, но:
     1. Теперь не надо ждать при повторных сокращениях ссылок
     2. Готова почва для history UI

Финальная сцена. ToDo list.
     – Просмотр истории
     – Настройка комбинации клавиш
     – Очистка истории в настройках
     – Баг с версткой в винде
     – Баг с пиканьем комбинации клавиш
     – Улучшить внешний вид

Эпилог
Основная работа сделана. Живет все на Github. Результатом уже пользуюсь (большей частью на работе) - вот и обильное тестирование. Дальнейшие улучшения оставил для холодных одиноких зимних вечеров.

Самодовольство точки

Прочитал "Флатландию" Эдвина Эбботта. Был чудесный момент, когда квадрат и сфера обсуждали жизнь точки в ее Вселенной размерности ноль. Прекраснейшая сильная геометрическая аналогия:

"Эта Точка — существо, подобное нам, но обреченное на вечное пребывание в пучине Нулевой Размерности. Для нее в ней самой заключен свой мир, своя Вселенная. Она не в силах представить себе никого, кроме себя. Она не ведает ни длины, ни ширины, ни высоты, ибо эти понятия чужды всему, с чем ей когда‐либо приходилось сталкиваться. Эта Точка не имеет ни малейшего представления ни о числе два, ни о том, что такое «много». Она сама воплощает для себя. Единичное и Общее, будучи в действительности Ничем.
Извлеките же отсюда урок: быть самодовольным значит быть гнусным и невежественным, стремиться к возвышенной цели лучше, чем слепо и бессильно погрязнуть в невежестве."

Спасибо Шелдону Куперу за наводку на книгу.

Легализация, часть 2. Музыка

После длительного (месяца 3) рассмотрения различных альтернатив получения легальной музыки я остановил свой выбор на следующем наборе сервисов:

– iTunes. Завел новый аккаунт без карточки, с адресом во Флориде. Пошел на сервис itunesgiftcard.com. Там было слишком много хороших отзывов о работе сервиса, подумалось, что все это липа. Несмотря на сомнения, я купил там для пробы карточку на 10$ и не зря. Через 2 минуты код был получен и введен в iTunes. Песни успешно и довольно быстро качаются, заливаются на iPod. Все просто и красиво. Стоят все теги, каверы. Качество 256 кбит/с - приемлемо для меня. После этих успешных проб экспортировал список всех песен в медиатеке в текстовый файл и стер к чертям все пиратское добро. Подчистую. Взял карточку покрупнее и пошел затариваться новой музыкой) Так началась новая глава в моей музыкальной жизни.

– Juno Downloads, Beatport.  Тут все дороже, но много эксклюзива. Сюда буду ходить за самыми крутыми треками, которых не будет в iTunes (а таких, все-таки, не мало).

– HousePlanet. Здесь регулярно выкладывают бесплатные миксы и промо-треки, из которых зачастую можно выбрать отличные работы. Большой респект этому сайту.

– Яндекс.Музыка. Еще раз большое спасибо Яндексу за замечательный сервис. Им пользуюсь дома и слушаю все, что еще не купил (:

Бюджет не резиновый, но я не считаю, что это какая-то роскошь - покупать музыку. Поначалу много будет нехватать, но совсем скоро количество песен перейдет некий необходимый минимум, и со временем будет лишь расти.

Так должно быть, за все надо платить. Я считаю это правильным и буду поступать в соответствии со своими убеждениями.

p.s. В третьей части буду убивать пиратское видео в своей жизни (правда не могу оценить насколько скоро это произойдет)

 

Вскрытие retain/release, NSURL + unicode, NSTiffSplitter.

NSURL не любит Unicode
Выражается это тем, что при попытке инициализации NSURL строкой с кириллическими знаками:
NSURL *url = [NSURL URLWithString:@"http://server.com/dir/петя"]; возвращается nil. Xотя с адресами вроде "http://server.com/folder/peter" все проходит хорошо (обратное было бы весьма печально). Это ошибка самого NSURL, причем не только на iPhone, но и на Mac OS X. Проблему решает IFUnicodeURL - категория NSURL, написанная в IconFactory. Работает очень просто:

NSURL *url = [NSURL URLWithUnicodeString:@"http://server.com/dir/петя"];

Маленький совет с WWDC 2010
for (id key in dic) работает быстрее, чем for (NSString *key in dic), так как не выполняется операция приведения к типу. Вещь вполне очевидная, но может кто не задумывался.

Легкое вскрытие retain/release
Недавно отвечал на вопрос об утечке памяти при использовании строк, "впаянных" в код. К таким строкам можно обращаться как к объектам NSString*:

[@"string" substringToIndex:3];

При этом примечательно, что [@"str" retainCount] возвращает 2147483647 (NSIntegerMax). То же самое для [[@"str" release] retainCount]. Память под такие строки выделяется не в autorelease pool, а в constant pool, поэтому на них не действуют обычные правила с подсчетом ссылок. Тут же захотелось проверить:



Из всего этого извращения можно выделить некоторые особенности работы методов retain/release у NSObject:

• Нет проверки на переполнение счетчика
• Для retain нет проверки на значение retainCount (что вполне логично) 
• У обоих методов есть проверка на то, где хранится объект - в autorelease pool / constant pool.

Все эти (немного веселые) глупости были сделаны из тех же стремлений заглянуть туда, куда простому смертному не заглянуть (возвращаясь к разговору об отсутствующих ложках).

NSTiffSplitter
На работе появилась потребность в просмотре многостраничных TIFF файлов на iOS девайсах (хотя это не мой проект (outsource), и поэтому это не мое дело). Стандартный же UIImageView позволяет просматривать только первые страницы. Также видел несколько вопросов на Stackoverflow, где люди интересовались библиотеками, позволяющими полностью просматривать такие файлы. В итоге сел на выходных и за часов 10 написал. Я редко спускаюсь на уровень общения с байтами, поэтому данный момент был для меня весьма необычен. В итоге - очень весело, полезно и интересно. Надо выбрать себе подобную цель покрупнее)
Когда выложу проект (проектик) на Github, расскажу в отдельном посте об интересных моментах , встретившихся при его написании.

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

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

В 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 уже изменен, поэтому если в обычном рабочем варианте переставить строки так:
то мы получим ту же ошибку.

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

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

DevelopBrief #1

Ниже представлена своего рода сводка по тем вопросам разработки (или около того), с которыми я сталкивался в последнее время.

Мертвые билды
Если нужно сэкономить место на диске, то загляните в папку, куда у вас билдятся все проекты (привет iSheez!). В XCode 4 адрес папки для билдов выставляется в Preferences... -> Locations -> Derived data, либо по дефолту – /Users/_Username_/Library/Developer/Xcode/DerivedData. Там лежат билды всех открывавшихся проектов, в том числе, давным-давно удаленных (очень интересно - зачем их там оставлять пылиться). У меня для ~15 проектов (из которых 4 - актуальны) эта папка занимала чуть меньше 1 Гб.
Можно также заглянуть на уровень выше и почистить неудачные снэпшоты (у меня один битый весил 1.2 Гб). Вот так просто и освободились 2 Гб из 60 доступных на ноуте.

Наглый парсер
Моя непредусмотрительность отняла у меня по меньшей мере 2 часа на поиск глупой ошибки. Суть ситуации проста: UI приложения висел в некоторых ситуациях, хотя с моей стороны нагрузок на основной поток не было. Для получения данных от твиттера я использую связку MGTwitterEngine (библиотека общения с твиттером) + YAJL Framework (парсер). После того, как я определил, что висит приложение между отправкой запроса и получением ответа (вроде бы ничего не делает в это время), стало ясно кто вешает основной поток (под 90% CPU time). А вешает его парсер, который перед тем как вызвать метод делегата и передать данные ответа мне, усиленно в главном потоке обрабатывает полученную информацию. Мне в голову не приходило, что такие длительные операции не выводят в фоновый поток (надо ж наглости набраться!). Мораль: будьте начеку и не наступайте на такие грабли!

Видео WWDC 2010
В связи с анонсом WWDC 2011 вспомнил о видео докладов с предыдущей конференции. Посмотрел те ролики, которые не видел до этого, в том числе "iPad and iPhone User Interface Design". Отличный доклад, с примерами на стандартных приложениях, iWork for iPad и других. Хорошая возможность загляунть одним глазком за ту завесу, за которой Apple творит свои дизайнерские чудеса. Рекомендую к просмотру. Искать в разделе "Application Frameworks", session 103.

WWDC 2011
Судя по слогану на эмблеме WWDC, не видать нам превью iOS 5 до 6 июня. Отсюда сразу же следует, что iPhone 5 не выйдет в привычные нам сроки, так как разработчикам должны дать время на "обуздание" новых возможностей ОС (как это обычно делает Apple). Или же ждать iPhone 5 без iOS 5? Утешением может служить надежда на то, что отсрочка релиза вызвана желанием выпустить продукт (как с софтверной, так и с аппаратной точки зрения), который будет больше, чем просто эволюционное развитие iPhone 4. Ждем.

p.s. Как всегда - эмблема сделана на загляденье!
p.p.s. Hell! 1200 €

Objective-C в Твиттере

Из любопытства решил поискать в твиттере признаки Objective-C кода, в результате чего обнаружил немало примечательных твитов:

– Видео о подтачивании NSLog под себя;

– Напоминалка о структуре NSURL;

– О работе сообщения removeFromSuperView класса UIView;

– Из того же блога статья про создание git repo для существующего проекта в XCode 4;

– Заметка с говорящим названием "Parsing sucks";

Много полезного по тегам #iosdev и #iphonedev:
– Сворачиваемая секция таблицы;
– Возможно, пригодится утилита App Scanner для проверки приложения на использование private API;

Можно не только черпать знания, но и просто случайно натыкаться на весьма забавные твиты:

Эмо-кодер:

Многих до сих пор не отпускает "Начало":

    

Также посоветовал бы обратить внимание на аккаунты: 24z, CocoaGeek.

Не стоит забывать о могучих возможностях твиттера и его пользе для нас ;)

Легализация, часть 1. ПО и книги

ПО
Смещение моих взглядов в анти-пиратскую сторону началось с покупки iPod Touch год назад (оттуда же берет свое начало мой путь в ряды маководов). Наигравшись с джейлбрейками, наглядевшись на мучительные ожидания знакомых и друзей очередного анлока, я пришел к выводу, что необходимость из кожи вон лезть, но только бы избавиться от "оков Apple", не так уж очевидна. И одним летним днем я попробовал влиться в экосистему iTunes и App Store. Не понадобилось много времени, чтобы понять насколько эта система удобна, что затраты на проживание в ней невелики. А главное - совесть была чиста. Негоже разработчику "тырить" софт у коллег.
С плеера эта идея перетекла и на компы, где теперь властвует Mac OS X со своим отдельным магазином. Осталась лишь пара приложений, появления которых я жду в нем, чтобы легализовать ПО на своих машинах на 100%.
Примечание: Одним из них является Parallels Desktop 6. На днях я получил грустное известие о том, что пока его появления в Mac App Store не предвидится, поэтому буду покупать программу через интернет традиционным способом.

Книги
На примере не только российского менталитета вцелом, но, также общаясь с близкими людьми, с неприятным удивлением обнаружил, что многие уперто считают, будто не должны платить за электронную книгу. По всей видимости, для них ценность книги не в ее содержимом, а лишь в носителе. Люди не видят (и, похоже, не представляют) тех трудов, которые стоят за созданием мало-мальски приличного произведения. С такими взглядами довольно очевидно, что покупать электронные книги в магазинах - полнейший абсурд. "Ведь носитель у меня уже есть, за интернет я заплатил(а), значит можно качать и спокойно читать". Надо таким людям напоминать с каким трудом из них вылазили сочинения на свободную тему в 10 классе, чтобы они хотя бы прикинули объем работ при написании книги. Я глубоко возмущен таким положением дел и намерен бороться с "темнотой" среди своих близких. Сам же я сейчас предпочитаю книги в традиционном, бумажно-механическом виде, что приводит к регулярным в последнее время визитам в "Библио-глобус". Неспеша рассматриваю альтернативные пути получения книг, в том числе в электронном виде.

В ближайшие дни опишу мучения при становлении российского гражданина на путь прослушивания лицензионной музыки, а также просмотра фильмов и сериалов.