Многие, вероятно, знают, что при работе с событиями изменения свойств с помощью key-value observing существует очень удобный механизм, предотвращающий появление в приложении «метрвых» объектов, которые представляют собой получателей вызовов. В действительности, первый же мертвый объект «валит» приложение, при поступлении ему события — это закономерно, так как объект уже не существует и никаких методов вызвать у него уже не получится.

Поиск таких объектов мог быть затруднен, если бы не замечательная в отладке вещь под названием NSKVODeallocateBreak, которая позволяет прервать выполнение приложения в момент, когда уничтожается объект, подписанный на события, чтобы отследить время его жизни и убрать проблему.

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

Данная статья рассчитана на разработчиков, имеющих опыт работы с платформой и знающих, каким образом определяется жизненный цикл объекта. Если у вас есть определенные пробелы в этой области (а я неоднократно встречал даже опытных разработчиков, которые не знают, каким образом работает счетчик ссылок и не представляющих, во что разворачивается @synthesize), то вы можете прочитать мою старую статью, посвященную исследованию данного вопроса. Остальных прошу к столу.

Событийно-ориентированная логика в Objective C держится на трех китах — протоколы, notification center и key-value observing. Традиционо протоколы используются для расширения функционала базовых классов без наследования, key-value observing – для взаимодействия между визуальной и логической частью приложения, а notification center — для обработкий событий пользователя.

Естественно, все это благообразие можно спокойно использовать для построения сложных приложений. Никакой реальной необходимости в изобретении собственных велосипедов, конечно же, нет. Однако мне, как человеку пришедшему в разработку Objective C приложений из мира .NET, показалось очень неприятным то, что notification center, который я планировал использовать для событий, разраывает стек приложения, записывая произошедшее событие в очередь в UI thread, а протоколы в классическом представлении не слишком удобны, посему для удобства я решил соорудить себе механизм, который был бы гораздо больше похож на то, чем мы привыкли обходиться в мире .NET. Так родился родилась идея реализации модели множественных подписантов через специальный класс, названный AWHandlersList.

Данная статья рассчитана на программистов, которые имеют определенный опыт в создании приложений на Objective C и уже писали подобные велосипеды, либо решали похожие задачи стандартными способами. Данный вариант не является silver bullet, но показал себя как удобный механизм, минимизирующий написание кода для обарботки множеств событий с разными интерфейсами и параметрами.

Полагаю, что многие пришедшие в славный мир .NET из славного мира С++ прекрасно помнят, как им приходилось буквально впиваться в стандарт, чтобы разобраться, почему язык ведет себя именно так, а не иначе. Многие вещи, которые казались им совершенно очевидны, при ближайшем рассмотрении оказались не то, что неочевидны — а просто-таки прямо противоположны здравому смыслу, на который мы все привыкли полагаться.

Впрочем, вероятнее всего, это проблема многих языков программирования. Многие, думаю, помнят известный ролик WAT, посвященный проблемам некоторых «очевидностей» языков JavaScript и Ruby. Логика привычного мира выходит покурить тогда, когда появляются пограничные области — те, в которые нормальные люди не лазят.

Впрочем, я предлагаю несколько отвлечься от этих высоких материй и взглянуть на язык C# несколько с другой, непривычной стороны. А именно посмотреть некоторые конструкции, которые, с одной стороны, совершенно понятны и легко описываются в терминах языка, а с другой — совершенно отказываются компилироваться.

Я даже не собираюсь спорить с тем, должны ли они компилироваться и работать. Я просто еще раз в очередной раз напомню, что все то, что для нас «логично и понятно» на самом деле может быть совершенно нелогично и непонятно.

И, да — я не буду в очередной раз ныть на тему того, что хотелось бы вернуть из функции тупл без использования громоздких структур и получить имя переменной с помощью простого оператора. Это не сюда — это к Майкрософту в фич-реквесты. У нас пятиминутка юмора. Итак, все то, что вы ежедневно хотите написать, но не пишете, потому что знаете — оно не скомпилируется. Поехали!

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

Именно поэтому я попытаюсь в простой и доступной форме объяснить массовому читателю обо всех основных заблуждениях относительно проблем авторского права, которые существуют в нашем мире. Ведь без понимания основ любой разговор на эту тему превращается в вялотекущий срач, просто в силу того, что стороны разговаривают на разном языке. Я опишу проблему не с точки зрения эмоционального потребителя или жадного производителя, а с точки зрения рыночной экономики и законодательства. Как обстоят дела в этом секторе, многие представляют себе достаточно туманно.

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

Прошу прощение за несколько фривольное вступление, далее все будет более формально и структурировано. Итак, краткое содержание для тех, кто хочет искоренить в себе ростки безграмотности и приобщиться к большому и светлому миру разбирающихся в данном вопросе.

1. Информация должна распространяться бесплатно!
2. Пиратство – это не воровство.
3. Я купил товар – диск (книгу, кассету) а значит, могу делать с ним все, что хочу.
4. Я физически могу скопировать информацию – значит, по закону, мне никто не может это запрещать.
5. Я лучше куплю то же самое у пиратов – они успешно конкурируют с правообладателями за счет более низких цен.
6. Кто сказал, что я принимаю условия лицензионного соглашения?
7. Почему это так дорого стоит? Я считаю, что оно должно стоить дешевле.
8. Я не желаю платить за некачественный товар.
9. Почему бы не перейти на систему пожертвований? У Radiohead же получилось!
10. Что же все-таки делать с засильем некачественного контента?
11. Я считаю, что распространяя контент бесплатно, я помогаю правообладателям увеличивать продажи. Все от этого только выигрывают.

Начнем с грустного. 95% населения земли составляют люди, в принципе не способные к более-менее позитивному созиданию. Однако, эта прослойка необходима для обеспечения существования остальных 5% в условиях рыночной экономики, ибо достаточно широко известен тот факт, что чем выше интеллектуальный уровень человека и его креативные способности — тем хуже он играет роль потребителя в рыночной системе. То есть, грубо говоря, чем больше человек способен создать — тем меньше он будет потреблять. И наоборот. Доказательства этой позиции можно найти в Сети самостоятельно, кто с ней не согласен — ваше право, гуманитарные науки допускают плюрализм мнений.

Теперь, небольшое вступление.

Очень многие люди, с которыми я так или иначе беседовал, в разговоре о копирайте и роли лейблов в развитии музыкальной индустрии допускают одну большую ошибку. Они считают, что роль лейблов заключается только в зарабатывании денег на исполнителях путем тиражирования и продажи дисков (которые, как известно всем жадным детям, должны продаваться за копейки, так как цена тиражирования составляет те самые копейки) и весь мир стал бы только счастлив, если бы они все вдруг сели в ракету и улетели на Марс. При этом, в пример постоянно приводится группа Radiohead как показатель коммерчески успешного «свободного» проекта.

В принципе, говорить с такими людьми о копирайте в музыкальной индустрии — все равно, что беседовать с выпускником 3-го класса о релятивистской физике («ну, я же когда выключателем щелкаю — свет сразу загорается, значит свет распространяется мгновенно»). Если учесть, что 95% населения в принципе не способны не только к созиданию, но и к постижению — становится совсем грустно, ибо понятно, что ты никогда не объяснишь человеку своей позиции, если он в принципе не способен ее понять, а если даже и способен — не хочет принимать. Это как женская логика — любой довод может быть не только опровергнут, но и отвергнут, даже если логически безупречен («этого не может быть, потому что я в это не верю»). Поэтому, статья пишется для интеллектуального меньшинства, с которым возможна позитивная дискуссия. Любителям кричать «цопирайт должен умереть» просьба удалиться в соседний топик и воздавать хвалу Радиохеду.

Я не поклонних хабрасуицида, а потому ВКонтакте является лишь катализатором данного мыслеизлияния, а описываемые методы могут быть применены совершенно к любой социальной сети, форуму и прочим местам, где так или иначе производится регистрация пользователя. Оно будет касаться именно системы распределения ников, и связанной с ними проблемы «кто первый встал — того и тапки».

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

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

Почему «неэкономической»? Об этом далее.

— Папа, я бежал за троллейбусом и сэкономил пять копеек!
— Сынок, бежал бы за такси — сэкономил бы пять рублей!


Сегодня я хочу рассказать вам, как сэкономить 10 тысяч долларов. А заодно, что гораздо менее интересно – научить перехватывать вызовы Win32 API функций, и не только. Хотя, в первую очередь – конечно, именно их.

Устав от обилия «аналитических» статей, посвященных такому социальному явлению, как троллинг, я, честно говоря, в очередной раз составил портрет среднестатистического обитателя сети и призадумался — а насколько вообще возможна классификация этого явления? Естественно, что в 99% виденных мной статей классификация никакой научностью даже не пыталась страдать в лучшем случае оставаясь на уровне «тролль закомплексованный — тролль незакомплексованный», а в худшем — на уровне «тролль хороший — тролль плохой». Естественно, что на основе такой классификации разобраться с этим явлением практически невозможно.

Кроме того, я считаю, что данная статья будет полезна всем, кто так или иначе пытается подходить к вопросу классификации с научной точки зрения. Опираясь на нее, можно составить представление о том, как следует заниматься классификацией, и она будет полезна вам даже в том случае, если вы в гробу видали всех этих троллей и нетроллей. Можете считать, что это статья на тему научной классификации явления на примере явления «троллинг».

Топик находится в блоге «учитесь работать» просто потому, что научитесь уже, блин, составлять классификации!

На написание данного опуса меня сподвиг данный хабратопик, в котором я оставил несколько, мягко говоря, некорректных комментария, и в результате вынужден был подробно разжевывать собственную позицию. Я прекрасно понимаю, что она в принципе никому не интересна, потому что в священных войнах правильных позиций просто не бывает, однако, я думаю, что кому-то может быть любопытно посмотреть, что там еще люди думают, а потому — именно таким людям и предназначен этот пост.

Сразу предупрежу — я не против Линукса, Б-же упаси. Я ни разу не возражаю против свободного софта, свободных операционных систем и свободных лицензий и не считаю линуксоидов красноглазым школием. И против Мак Ос я ничего не имею, наоборот — я всецело за, Линукс настраиваемый, клевый и быстрый, Мак Ос удобный и красивый.

Проблема в том, что пользователю это не нужно.