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

Меня настолько заинтересовал вопрос о книгах, что я решил начать новую серию статей на своём сайте catonmat о моих топ-100 книгах о программировании, программном обеспечении, науке, физике, математике и компьютерах. В каждой статье я буду размещать по пять книг, ведь разбивать огромное задачи на маленькие подзадачи — это самый простой способ их решать (GTD — get things done).

Взгляните на мою книжную полку, чтобы убедиться, что я настоящий ботаник:

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

Кроме того, делегирование используется внутри одного MVC между View и Controller для их «слепого взаимодействия».

Дело в том, что Views — слишком обощенные (generic) стандартизованные строительные блоки, они не могут что-то знать ни о классе, ни о Controller, который их использует. Views не могут владеть своими собственными данными, данные принадлежат Controller. В действительности, данные могут находиться в Mодели, но Controller является ответственным за их предоставление. Тогда как же  View может общаться с Controller? С помощью делегирования.

Нужно выполнить 6 шагов, чтобы внедрить делегирование во взаимодействие View и Controller:

1. Создаем протокол делегирования (определяем то, о чем View хочет, чтобы Controller позаботился)
2. Создаем в View weak свойство delegate, типом которого будет протокол делегирования
3. Используем в View свойство delegate, чтобы получать данные/ делать вещи, которыми View  не может владеть или управлять
4. Controller объявляет, что он реализует протокол
5. Controller устанавливает self (самого себя) как делегата View путем установки свойства в пункте #2, приведенном выше
6. Реализуем протокол в Controller

Мы видим, что делегирование — не простой процесс.
Как в Swift, так и в Objective-C, процесс делегирования можно заменить использованием замыканий (блоков), принимая во внимание их способность захватывать любые переменные из окружающего контекста для внутреннего использования. Однако в Swift реализация этой идеи существенно упрощается и выглядит более лаконичной, так как  функции (замыкания) в Swift являются «гражданами первого сорта», то есть могут объявляться переменными и передаваться как параметры функций. Простота и абсолютная ясность кода в Swift позволят более широко использовать замыкания (closures), захватывающие контекст, для взаимодействия двух MVC или взаимодействия Controller и View без применения делегирования.

Я хочу показать использование захвата контекста замыканиями на двух примерах, взятых из стэнфордского курса 2015 «Developing iOS 8 Apps with Swift» (русский эквивалент находится на сайте «Разработка iOS+Swift+Objective-C приложений»).

Один пример будет касаться взаимодействия View  и Controller в пределах одного MVC, а другой — двух различных MVC. В обоих случаях  захват контекста замыканиями позволит нам заменить делегирование более простым и элегантным кодом, не требующим вспомогательных протоколов и делегатов.

Данная статья посвящена вопросу тестирования в рамках Objective-C используя Xcode 6. Рассматриваются стандартная библиотека для тестирования и сторонняя библиотека OCMock. Опытные разработчики, возможно, не найдут здесь слишком полезной информации, тем же, кто недавно встал на этот путь — статья откроет необходимые базовые знания по написанию unit-тестов на языке Objective-C.

Для основы тестирования просьба обратиться сюда.
Для основы unit-тестирования сюда.

А теперь мы начнем изучение unit-тестирования в рамках Objective-C.

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

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

А что-то про SEMAT тут никто еще не написал? Исправляем.

Предисловие

Знакомлюсь с SEMAT – Software Engineering Method and Theory. Показалось разумным. Размышляю о возможности применения в своих проектах. Анализирую риски. Хотелось бы привлечь Хабраразум.

Цель осталась прежней: получить минимально работающий почтовый сервер, используя только Postfix и Dovecot, с минимальным изменением настроек по умолчанию.
Вводная часть и настройка Dovecot.

Цель: получить минимально работающий почтовый сервер, используя только Postfix и Dovecot, с минимальным изменением настроек по умолчанию. Получить каркас системы, на основе которого можно, в дальнейшем, настраивать спам фильтры, работу с базами данных, LDAP…
Почтовая система должна:

1. Поддерживать любое количество доменов и пользователей.
2. Обслуживать пользователей, не привязанных к локальным учетным записям.
3. Обеспечивать доступ к почтовым ящикам по протоколам POP3, IMAP с поддержкой TLS.
4. Обеспечивать отправку и прием писем по протоколу SMTP с поддержкой TLS.

Настройка проводилась в CentOS 6. Postfix 2.6.6, Dovecot 2.0.9. Никакие особенности ОС не применялись.

Суффиксное дерево – мощная структура, позволяющая неожиданно эффективно решать мириады сложных поисковых задач на неструктурированных массивах данных. К сожалению, известные алгоритмы построения суффиксного дерева (главным образом алгоритм, предложенный Эско Укконеном (Esko Ukkonen)) достаточно сложны для понимания и трудоёмки в реализации. Лишь относительно недавно, в 2011 году, стараниями Дэни Бреслауэра (Dany Breslauer) и Джузеппе Италиано (Giuseppe Italiano) был придуман сравнительно несложный метод построения, который фактически является упрощённым вариантом алгоритма Питера Вейнера (Peter Weiner) – человека, придумавшего суффиксные деревья в 1973 году. Если вы не знаете, что такое суффиксное дерево или всегда его боялись, то это ваш шанс изучить его и заодно овладеть относительно простым способом построения.

Диздок упоминают в разговорах, о нём шепчутся на форумах, примеры его ищут и зелёные новички, и бывалые разработчики. Случается, что под тусклым светом уличного фонаря происходит сделка. Фигура в тёмном капюшоне украдкой передаёт ссылку на «Месть курочки Рябы». Конечно, таинственный гонец не имеет злого умысла, но деяние совершено…

Создавая объект за объектом, мы часто не обращаем внимания на такую «мелочь», как динамическое выделение памяти. Наравне с копированием и сериализацией, выделение памяти из кучи через new постепенно сводит на нет преимущества C++ в скорости. Чем интенсивнее мы пользуемся заветным new, тем сложнее становится приложению, поскольку память кончается, фрагментируется и всячески стремится утекать. Эта участь уже постигла удобные, но неявно опасные для производительности контейнеры STL: vector, string, deque, map. Особенно обидно терять скорость на выделении небольших объектов в больших количествах. Но есть способ обработать размещение памяти таких объектов на стеке, при этом скрывая детали реализации в специальный класс данных. В этом нам поможет механизм размещающего new — непревзойденный способ оптимизации приложения, полного частых и мелких выделений памяти из кучи.

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

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



У меня есть некоторые свои собственные соображения и наработки для решения этой проблемы в рамках своей специальности — способа изучения языка программирования C#, речь пойдёт о проекте www.videosharp.info

Когда результат SQL-запроса влечет бесконечные приведения типов ко всевозможным вариантам типов полей. Когда код заполнен малопонятной логикой с гигантским перебором перегрузок по типам boost::variant. Когда не знаешь, как принять аргумент произвольного типа по RPC-протоколу. Тогда требуется механизм эмуляции динамической типизации в C++. Расширяемый и удобный, создающий понятный API. Такой, что не требует предопределенного списка типов и не заставляет работать с указателями на базовый класс. Такой механизм есть — нам поможет двойная диспетчеризация!

Если вы не знаете, в каком направлении развивать проект, то он вряд ли выберет нужный путь самостоятельно.
Стив Макконнелл

Введение

В предыдущей статье «Обзор процесса разработки программного обеспечения» [1] я рассказал о самом «верхнем уровне» процесса разработки, сложившегося в моей практике на текущий момент. Во введении к «Обзору» я постарался сформулировать используемые термины и привёл примеры некоторых проектов, в которых использовался рассматриваемый процесс.

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

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

Для достижения поставленных целей заказчику и исполнителю совместно нужно решить ряд вполне определённых задач:

1. На основе исходной идеи сформулировать цели и задачи будущего проекта.
2. Разработать некоторое исходное видение – концепцию проекта.
3. Провести анализ востребованности будущего продукта.
4. Провести предварительную оценку рисков будущего проекта.
5. На основе концепции и списка предварительных рисков подготовить предварительное техническое решение.
6. Выбрать методологию разработки и подготовить предварительный план работ.
7. Провести предварительную оценку трудозатрат и необходимых ресурсов.
8. Провести анализ реализуемости продукта.
9. Провести независимое рецензирование технического решения.
10. Принять решение о том, стоит ли продолжать работы.

Привет, Хабр! Недавно мы обновили приложение Почты Mail.Ru для iOS. Теперь оно поддерживает Apple Watch. Сегодня я хочу рассказать, с чем мы столкнулись при разработке приложения для еще не вышедших на тот момент часов, и поговорить о том, как справляться с минимализмом SDK и невозможностью протестировать приложение на «живом» девайсе.

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

В настоящее время департамент мобильной разработки Rambler&Co активно расширяется, в том числе и в плане iOS-разработчиков и UX дизайнеров. Большое количество людей и проектов, ведущихся ими, усложняет и без того непростой процесс передачи дизайна разработчикам. Всем, так или иначе связанным с мобильной разработкой, знакомы проблемы и разногласия, возникающие на стыке интересов программиста и дизайнера — начиная тем, в каких единицах измерять расстояния, и заканчивая тем, кто должен нарезать элементы экранов в различных разрешениях. Чтобы окончательно решить проблему в рамках нашей компании, мы решили подготовить подробные гайдлайны по этому взаимодействию.

Историями про вредоносное ПО для ОС Android никого уже сегодня не удивить, разве только про rootkit-технологии или про новые концепты, заточенные под новое runtime-окружение ART. C вредоносным ПО для iOS противоположная ситуация: о нем если кто и слышал, то, как правило, только в контексте jailbreak. В 2014 году был вообще бум таких программ (AdThief, Unflod, Mekie, AppBuyer, Xsser). Но в этой статье мы поговорим про вредоносное ПО и его возможности для iOS без jailbreak…

Сегодня стартовали официальные продажи Apple Watch. 90% умопомрачительных концептов приложений под них, которые можно найти в Сети, нереализуемы — тем, кто знаком с гайдлайнами Apple, это хорошо известно. О том, что реализовать на часах все же можно и как это лучше сделать с точки зрения разработки и дизайна — под хабракатом.

Уверен, что те, кто следят за изменениями в мире Android, заметили, что Toolbar начинает играть в приложениях всё более значимую роль. Например в последней версии Gmail клиента в Toolbar вынесен почти весь функционал по работе с почтой, а в новом Google Chrome Toolbar отвечает за работу с текстом страниц.

В данной статье я постараюсь рассказать о создании динамического Toolbar, который позволит пользователю работать с контентом четырьмя различными способами в рамках одного Activity. Мы рассмотрим весь процесс разработки Toolbar-a начиная с xml файлов стилей и заканчивая анимацией иконок, а в конце статьи я оставлю ссылку на GitHub репозиторий с примером полностью рабочего приложения.

Disposable паттерн (интерфейс IDisposable) предполагает возможность высвобождения некоторых ресурсов, занимаемых объектом, путём вызова метода Dispose, ещё до того момента, когда все ссылки на экземпляр будут утрачены и сборщик мусора утилизирует его (хотя для надёжности вызов Dispose часто дублируется в финализаторе).

Но существует также обратный Exposable паттерн, когда ссылка на объект становится доступной до момента его полной инициализации. То есть экземпляр уже присутствует в памяти, частично проинициализирован и другие объекты ссылаются на него, но, чтобы окончательно подготовить его к работе, нужно выполнить вызов метода Expose. Опять же данный вызов допустимо выполнять в конструкторе, что диаметрально вызову Dispose в финализаторе.

Само по себе наличие такой обратной симметрии выглядит красиво и естественно, но где это может пригодиться на практике постараемся раскрыть в этой статье.