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

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

Совсем недавно я побывал на мини-конференции местного разлива, где я размышлял на тему фриланса, с точки зрения веб-дизайнера. Даже подготовил для этого действа презентацию (на украинском). Здесь же попробую описать то, что хотел донести до слушателей Coffee Design Code.

(Статья доступна для оффлайн чтения: Markdown | PDF | PDF (print) | HTML)

Зачем?

Все вокруг постоянно говорят: «Хочешь научиться писать профессиональные программы? Посмотри, как это делают другие!». Вот и я решил последовать этому совету, тем более что моё обучение в университете как раз подходит к концу. Особенно интересно сравнить то как учили делать и то как делается в реальном мире. В качестве примера для подражания был выбран пакет GNU Coreutils. В нём есть всё:

1. Жёсткие требования к переносимости.
2. Большой жизненный цикл.
3. Огромная команда разработчиков.
4. Код различной сложности: от тривиального echo до супер-изощерённого sed, от чисто прикладного wc до более близкого к ОС mkdir.

Хотя метод был разработан и представлен в 2001 году Полом Виолой и Майклом Джонсом [1, 2], он до сих пор на момент написания моего поста является основополагающим для поиска объектов на изображении в реальном времени [2]. По следам топика хабраюзера Indalo о данном методе, я попытался сам написать программу, которая распознает эмоцию на моём лице, но, к сожалению, не увидел на Хабре недостающей теории и описания работы некоторых алгоритмов, кроме указания их названий. Я решил собрать всё воедино, в одном месте. Сразу скажу, что свою программу успешно написал по данным алгоритмам. Как получилось рассказать о них ниже, решать Вам, уважаемые Хабрачитатели!

Доброго всем дня!

Недавно я писал о кастомизации заголовка окна в Mac OS X и получил реквесты написать поподробнее о взаимодействии Qt и Cocoa. Думаю, тему можно немного развернуть и написать об интеграции приложений, написанных с помощью Qt, в среду Mac OS X. Оговорюсь, что используется в данном случае Qt for Cocoa, если возьмёте Qt for Carbon, то и работать придётся только с карбоном. Но он морально устарел, и использовать его стоит только в крайних случаях.

Обычная Qt-программа имеет ряд несостыковок с Apple HIG. Точнее, может иметь, так как не всем программам нужен дополнительный функционал. Например, не любой программе надо иметь бэдж поверх значка в доке, расширять меню дока или выносить/дублировать некоторые функции в маковское меню.

Но что делать, если такой функционал нужен? Если нужно отображать в доке количество уведомлений (а-ля скайп), обрабатывать клик по иконке в доке, добавлять свои пункты меню в док, да ещё и иметь нормальное меню, в общем, сделать так, чтобы программа смотрелась как родная в Mac OS? Что-то из этого можно сделать с помощью штатных или полудокументированных функций Qt, а что-то — только с использованием Cocoa и, соответственно, Objective-C… Что же делать?

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

Что отличает хорошего программиста от посредственного? И как самому стать хорошим программистом и заслужить среди друзей и коллег «почет и уважение»?

Введение

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

Обозначения

В прошлый раз я хотел обозначить морфизм/функцию буквой f, но она была занята для обозначения функтора/переменной типа f – никакой проблемы с точки зрения языка Haskell в этом нет, но при невнимательном прочтении это может вызвать путаницу, и я использовал для морфизма букву g. Пустяк, но всё же, я считаю, что полезно визуально разделять сущности, имеющие разную природу. Обычные типы я буду называть их обычными именами, а вот переменные типов я буду называть маленькими греческими буквами, причём простые (∗) – буквами из начала алфавита, а параметрические (∗ → ∗) – буквами из конца алфавита (θ не из конца, но она смотрится лучше, чем χ, которая слишком похожа на X). Итак, в терминологии категории Hask:

• Объекты: α, β, γ, δ ∷ ∗
• Функторы: θ, φ, ψ, ω ∷ ∗ → ∗
• Морфизмы: f, g, h ∷ α → β

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

Ещё одно замечание, касательно терминологии: как вы уже заметили, то, что я в прошлый раз называл словом “кайнд” (kind), я теперь называю словом “сорт” – это считается общепринятым переводом.

Категория с объектом Hask

Давайте рассмотрим категорию, в которой будет только один объект – сама категория Hask. Что же будет морфизмами в такой категории? Это должны быть какие-то отображения Hask → Hask, и мы уже знаем такой тип отображений – это эндофункторы категории Hask, то есть типы сорта ∗ → ∗, воплощения класса Functor. Теперь нужно продумать как устроены единичный морфизм и композиция в этой категории, так чтобы они удовлетворяли аксиомам.

Двухфакторная аутентификация — предоставления информации от двух различных типов аутентификации информации [»]

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



Это как если бы на дверь поставили второй замок. Ключ к первому — обычный пароль. Ко второму — действующий в течение 30 секунд одноразовый код. Попасть за дверь можно только если оба ключа окажутся правильными, а не один, как было раньше.

С некоторых пор Google сделала доступной двухфакторную аутентификацию в своих сервисах. Теперь токен переехал в ваш мобильный телефон с Android'ом! iPhone и Blackberry тоже сгодятся в такой роли. Очень удобно. Опробовав на Gmail, мне захотелось такую же штуку сделать у себя, тут-то я внезапно и нашёл libpam-google-authenticator.

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

Всё что Вам нужно – это пара старых очков, нож для бумаги и растворитель для краски.

Timsort, в отличии от всяких там «пузырьков» и «вставок», штука относительно новая — изобретен был в 2002 году Тимом Петерсом (в честь него и назван). С тех пор он уже стал стандартным алгоритмом сортировки в Python, OpenJDK 7 и Android JDK 1.5. А чтобы понять почему — достаточно взглянуть на вот эту табличку из Википедии.



Среди, на первый взгляд, огромного выбора в таблице есть всего 7 адекватных алгоритмов (со сложностью O(n logn) в среднем и худшем случае), среди которых только 2 могут похвастаться стабильностью и сложностью O(n) в лучшем случае. Один из этих двух — это давно и хорошо всем известная «Сортировка с помощью двоичного дерева». А вот второй как-раз таки Timsort.

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

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

Однако, если мы хотим разработать полноценную игру, то нам нужно более серьезное решение – современная игровая индустрия предлагает гораздо более широкий выбор устройств ввода, чем одна только клавиатура, а список возможных действий и событий в игре не исчерпывается движением единственного игрового объекта.
В данном топике мы попробуем создать законченную, расширяемую, универсальную систему взаимодействия с устройствами ввода в игре при помощи программирования на Python 3.2 в Blender 2.6.

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

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

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

Данная статья является переводом очень хорошего топика с форума Stack Overflow. Так как английский язык не является для меня родным, то какие-либо непонятные мне места я просто пропускал, что бы не разгневать тех, кто его действительно знает. Статья содержит список советов и рекомендаций для начинающих разработчиков под Android.

В посте речь пойдет о моем опыте встраивания XML-RPC интерфейса в утилиту, написанную на C. Интерфейс должен предоставлять доступ к статитстике и результатам работы утилиты. Одно из требований к интерфейсу — поддержка ответов в формате gzip, в целях экономии трафика. Мне очень хотелось обойтись малой кровью и вот что из этого получилось.

Вступление

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

Не хотелось бы повторять перевод на эту тему, который уже был на хабре: Монады с точки зрения теории категорий, но для целостности статьи, я всё же буду давать основные определения. При этом, в отличие от той статьи, я не хочу делать основной упор на математику.

Эта статья во многом повторяет (в том числе заимствует иллюстрации) раздел из английской Haskell Wikibook, но тем не менее не является непосредственным переводом.

Что такое категория?

Примеры

Для наглядности рассмотрим сначала пару картинок изображающих простые категории. На них есть красные кружочки и стрелки:

Красные кружочки изображают «объекты», а стрелки – «морфизмы».

Я хочу привести один наглядный пример из реальной жизни, который даст какое-то интуитивное представление о природе объектов и морфизмов:

Можно считать города «объектами», а перемещения между городами – «морфизмами». Например, можно представить себе карту авиарейсов (как-то не нашёл я удачную картинку) или карту железных дорог – они будут похожи на картинки выше, только сложнее. Следует обратить внимание на два момента, которые кажутся в реальности само собой разумеющимися, но для дальнейшего имеют важное значение:

• Бывает, что из одного города в другой никак не попасть поездом или самолётом – между этими городами нет морфизмов.
• Если мы перемещаемся в пределах одного и того же города, то это тоже морфизм – мы как бы путешествуем из города в него же.
• Если из Санкт-Петербурга есть поезд до Москвы, а из Москвы есть авиарейс в Амстердам, то мы можем купить билет на поезд и билет на самолёт, “скомбинировать” их и таким образом попасть из Санкт-Петербурга в Амстердам – то есть можно на нашей карте нарисовать стрелку от Санкт-Петербурга до Амстердама изображающую этот скомбинированный морфизм.

Надеюсь, с этим примером всё понятно. А теперь немного формализма для чёткости.

Коллеги, добрый день!

Сегодня поговорим о причинах, побуждающих создавать и внедрять методики и инструменты обеспечения качества, заглянем в историю проблемы, осветим известные риски и постараемся «устаканить» в сознании выигрышную стратегию обеспечения достаточного качества веб-решения. В заключении я расскажу о новом инструменте в 11 версии платформы Битрикс — «Мониторе качества».

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

Начал работу сайт jpg.to, с помощью которого удобно на лету получать иллюстрации по ключевому слову. Указываете слово в URL на любом языке — и получаете нужную картинку. Картинки берутся с Google Image Search, в URL можно использовать кириллицу. Например, котята.jpg.to.

Это может пригодиться для быстрого постинга картинок в чате/почте, а также для автоматического иллюстрирования контента. Можно сделать скрипт, который будет подгружать картинки по контексту страницы или по тексту во время набора пользователем. Jpg.to — минималистическая альтернатива гугловским API, которые запланированы к закрытию.

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

• размер: keyword.jpg.to/large, keyword.jpg.to/medium
• цветовая гамма: keyword.jpg.to/red, keyword.jpg.to/green, keyword.jpg.to/white
• тип картинки фото/клипарт: keyword.jpg.to/photo, keyword.jpg.to/clipart
• выбор случайной картинки (keyword.jpg.to/random.jpg) или по номеру в результатах поиска (keyword.jpg.to/301.jpg)
• информация об авторе и возможность удаления картинки из выдачи по требованию автора

Данный текст является переводом документации Template Haskell, написанной Булатом Зиганшиным. Перевод всего текста разбит на несколько логических частей для облегчения восприятия. Далее курсив в тексте — примечания переводчика. Предыдущие части:

• Часть 1. Необходимый минимум
• Часть 2. Инструменты цитирования кода

Материализация

Материализация (reification) — это средство Template Haskell, позволяющее программисту получить информацию из таблицы символов компилятора. Монадическая функция reify ∷ Name → Q Info возвращает информацию о данном имени: если это глобальный идентификатор (функция, константа, конструктор) – вы получите его тип, если это тип или класс – вы получите его структуру. Определение типа Info можно найти в модуле Language.Haskell.TH.Syntax.
Материализация может быть использована для того, чтобы получить структуру типа, но таким образом нельзя получить тело функции. Если вам нужно материализовать тело функции, то определение функции нужно процитировать и дальше можно будет работать с этим определением с помощью другого шаблона. Например так:

$(optimize [d| fib = … |])

или так

fib = $(optimize [| … |])

На самом деле, в оригинальной статье больше ничего не говорится про материализацию. Не знаю, насколько это содержательная тема – необходимый минимум знаний о ней ограничивается функцией reify и типом Info, но есть некоторые тонкости, связанные например с тем, что можно получить информацию не о любом имени. Если эта тема интересна, я могу собрать какую-нибудь информацию и написать об этом отдельную заметку (или вклеить сюда).

Облегчённое цитирование имён

Чтобы получить имя (∷ Name), соответствующее интересующему идентификатору, можно использовать функцию mkName, но это не безопасное решение, потому что mkName возвращает не квалифицированное имя, которое может интерпретироваться по-разному в зависимости от контекста. А вот код VarE id ← [| foo |] безопасен в этом смысле, так как цитирование квалифицирует имена (получится что-то типа My.Own.Module.foo), но этот код слишком многословный и требует монадический контекст для использования. К счастью, Template Haskell, имеет другую простую форму цитирования имён: 'foo (одинарная кавычка перед foo) имеет тип Name и содержит квалифицированное имя, соответствующее идентификатору foo, так что код let id = 'foo эквивалентен по смыслу коду VarE id ← [| foo |]. Обратите внимание, что эта конструкция имеет простой тип Name (а не Q Exp или Q Name), так что она может быть использована там, где не возможно использование монад, например:

f ∷ Exp → Exp
f (App (Var m) e) |  m == 'map  =  …

Эта новая форма тем не менее является цитированием и подчиняется тем же правилам, что и цитирующие скобки [| … |]. Например, она не может быть использована внутри этих скобок (так нельзя: [| 'foo |]), но и вклеивание к ней не может быть применено (так тоже нельзя: $( 'foo )), потому что для вклейки нужен тип Q …. Более важно то, что эта форма определяется статически, возвращая полностью квалифицированное имя, с однозначной интерпретацией.
Haskell’евские пространства имён немного всё усложняют. Цитата [| P |] означает конструктор данных P, в то время как [t| P |] означает конструктор типа P. Поэтому для “облегчённого цитирования” необходим такой же способ разделения этих сущностей. Для контекста типов используется просто две одинарные кавычки:

• 'Foo означает “конструктор данных Foo в контексте выражения”
• 'foo означает “имя foo в контексте выражения”
• ''Foo означает “конструктор типа Foo в контексте типов”
• ''foo означает “переменная типа foo в контексте типов”

Облегчённая форма цитирования используется в примере генерации воплощений класса Show, который разбирается в конце.