Многие, вероятно, знают, что при работе с событиями изменения свойств с помощью 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% виденных мной статей классификация никакой научностью даже не пыталась страдать в лучшем случае оставаясь на уровне «тролль закомплексованный — тролль незакомплексованный», а в худшем — на уровне «тролль хороший — тролль плохой». Естественно, что на основе такой классификации разобраться с этим явлением практически невозможно.

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

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

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

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

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

Обыск у мужика — нарыли самогонный аппарат.
— Так-с! — говорит участковый. — Чудненько! Ща мы тебя за самогоноварение и того…
— Так я ж не гнал!
— Но аппарат же есть!
— Тогда и за изнасилование судите!!!
— А ты что, кого-то изнасиловал?!?
— Нет! Но аппарат же есть!

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

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

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

Прошу прощения за пространное вступление, перейдем непосредственно к сути под хабракатом.

В последнее время, все больше и больше в контексте обсуждения различных ситуаций в нашей стране и за рубежом, всплывает тема Оруэлла и его «1984», где Старший Брат следит за всеми, Министерство Правды занято переписыванием истории, а людей держат в фактическом рабстве. Тема всплывала и раньше, но все больше в контексте обсуждения СССР.

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

Под катом вас ждет небольшой комикс, в котором сравниваются идеи Оруэлла и Хаксли. Перевод был сделан мной, однако пара фраз немного убежала от моего понимания, поэтому я буду очень рад, если вы поможете мне с ними, отослав свой вариант через систему личных сообщений. Аналогично — по ошибкам в переводе.

Ссылка на изображение + полный вариант картинки (950х7500 px) под катом.

Предвидя логичный вопрос «зачем это на Хабре», не могу не заметить, что Интернет очень сильно способствует в деле создания информационного шума, и мы с вами в том числе тому вина. Может быть, стоит остановиться и не плодить очередной ненужный стартап?

Пробежался поиском по хабру и удивился тому, что об этой программе никто не упоминал, хотя про тот же Dropbox неоднократно писали.

Итак, встречайте — HFS. Программа, которая позволяет в два клика поднять собственный HTTP-файл сервер, расшарить файлы и выдать ссылку на скачку другу.

Чем хорош такой подход? Тем, что не надо ничего никуда заливать — файлы скачиваются прямо с вас. Тем же он, правда, и плох — работать будет только в случае, если компьютер включен и имеет доступ к сети (желательно, не через GPRS :)

Существует возможность настройки прав доступа как по IP, так и через учетные записи. Плюс — возможность заливки файлов (аналогично — файлы заливаются сразу к вам на компьютер).

Веб-интерфейс достаточно приятен глазу. Программа работает как под винду, так и под линукс через Wine.

Из минусов — вроде как требуется внешний IP (статика или динамика), однако я не проверял возможность работы без него. А так — штука дико удобная, особенно когда расшаренная папка содержит файлы, которые постоянно изменяются. Хотя, фанаты Dropbox не оценят.

Методика все та же — минимум объяснений, максимум рецептов. Для глубинного понимания происходящих процессов рекомендую обратиться к документации в MSDN — этот раздел уже даже перевели на русский язык.

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

К сожалению, нередко проблема наладить взаимодействие встает у тех разработчиков, которые слабо знакомы с подноготной технологии COM и возможностями .NET для обеспечения взаимодействия. Это нормально — нельзя знать все на свете. Потому я не буду здесь объяснять всю суть проблемы маршаллинга данных из unmanaged в managed и обратно, а просто дам несколько рабочих рецептов, которые помогут вам тогда, когда нужно срочно и завтра, и вы с тоской смотрите на английское издание книги Inside OLE и понимаете, что разобраться в этом за день нет никакой возможности.

Однако, для тех, кто неплохо в этом разбирается, в конце статьи есть небольшой бонус — способ организации out-process COM на .NET. Честно говоря, я добросовестно считал, что сделать out-process COM с помощью .NET невозможно, однако буквально вчера выяснилось, что все-таки нет, можно. В связи с этим, рассказывать про архитектуру .NET Pipe RPC я скорее всего не буду — она достаточно сложна, однако все предоставляемые ей возможности с легкостью заменяет out-process COM.

Managed код и .NET Framework – совершенно замечательная вещь с точки зрения программиста, которому надо кровь из носу выдавать максимально стабильно работающие программы. Использование .NET позволяет очень сильно сократить затраты на разработку, тестирование и сопровождение программных продуктов, особенно по сравнению с C++ или Delphi.

Однако, managed код имеет одну очень серьезную родовую травму, которая прямо проистекает из его достоинств – он изначально несовместим с unmanaged средой, в которой вынужден работать. Boxing, поля памяти, отсутствие прямой адресации и прочие ухищрения, призванные облегчить жизнь программисту, приводят к тому, что взаимодействие managed и unmanaged кода становится проблемой.

Однако нет такой проблемы, которую нельзя решить (пусть даже с помощью топора и лома). Сегодня у нас краткий обзор возможностей организации взаимодействия между managed и unmanaged кодом. Многие C# и особенно VB.NET программисты боятся этого, но на самом деле в этом нет ничего страшного. Начнем мы с самых примитивных методов, которые будут интересны разве что новичкам (поэтому матерые волки .NET могут с чистой совестью первую часть статьи пропустить), и закончим описанием того, что делать, если хочется написать программу на .NET, но сделать это невозможно (а такое тоже бывает). Естественно, к каждому случаю будут приведены конкретные примеры, быть может, хабрачеловеки расскажут мне о моей собственной велосипедности. Параллельно я скажу пару слов о подводных камнях при работе с VSTO и Windows Shell.

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

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