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

Вступление

Как оказалось тема алгоритмов интересна Хабра-сообществу. Поэтому я как и обещал, начну серию обзоров «классических» алгоритмов на графах.
Так как публика на Хабре разная, а тема интересна многим, я должен начать с нулевой части. В этой части я расскажу что такое граф, как он представлен в компьютере и зачем он используется. Заранее прошу прощения у тех кто это все уже прекрасно знает, но для того чтобы объяснять алгоритмы на графах, нужно сначала объяснить что такое граф. Без этого никак.

Этот перевод является продолжением серии статей про тестирование:

• Настройка IDE для автоматического запуска тестов
• Категории программных тестов

На очереди практические советы по построению тестопригодного кода и примеры применения изложенных знаний на реальных проектах.
P. S. Отдельное спасибо taxigy за корректуру русского перевода.


Я думаю, что баги можно разделить на три базовые категории:

1. Логические. Логические баги наиболее популярны и часто встречающиеся. Это ваши if'ы, циклы и другая подобная логика в коде. (Мысли: это работает неверно).
2. Баги взаимодействия. Баг взаимодействия — когда два разных объекта неправильно взаимодействуют между собой. Например, выход одного объекта является не тем, что ожидает следующий объект в цепочке. (Мысли: данные к месту назначения пришли испорченными).
3. Баги отображения. Баг отображения — когда вывод (обычно некоторый пользовательский интерфейс, UI) отображается некорректно. Ключевой момент — в том, что это человек определяет, что есть правильно, а что — нет. (Мысли: это «выглядит» неправильно)

Сегодня довольно мало информации о протоколе AMQP (Advanced Message Queueing Protocol) и его применении, особенно на русском языке. А вообще это — замечательный, уже достаточно широко поддерживаемый открытый протокол для передачи сообщений между компонентами системы с низкой задержкой и на высокой скорости. При этом семантика обмена сообщениями настраивается под нужды конкретного проекта. Такие решения существовали и ранее, но это первый стандарт, для которого существует большое количество свободных реализаций.

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

Сегодня тема доставки информации в реальном времени является крайне актуальной (достаточно вспомнить хотя бы Twitter, Google Wave). И здесь системы передачи сообщений могут служить внутренним механизмом обмена данными, который обеспечивает доставку данных (изменений данных) клиентам.

Я не ставлю своей целью сегодня рассказать о том, как писать приложения для AMQP. Хочу лишь немного рассказать о том, что это совсем не страшно, не очень сложно, и действительно работает, хотя стандарт находится еще в развитии, выходят новые версии протокола, брокеров и т.п. Но это уже вполне production-quality. Расскажу лишь базовые советы, чтобы помочь “въехать” в протокол.

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

Хочу представить свой перевод статьи «Your Code Sucks and I Hate You: The Social Dynamics of Code Reviews».

Я ненавижу тебя: твой код – хлам!
Взаимоотношения участников ревизий кода

Джонатан Лэндж (Jonathan Lange), 15.09.2008

Обзор

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

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

Теоретическая составляющая.

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

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

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

У меня возник вопрос насколько все может быть плохо. Кроме того, интересно было посмотреть как влияет длина данных.

Недавно на Хабре была статья, посвященная алгоритмам на графах. С позволения автора, мой первый хабратопик продолжит цикл.

Хотелось бы осветить вопросы применения некоторых алгоритмов, для решения задач программирования.
Достаточно жизненный пример, с которым сталкивался не один разработчик — это deadlock. По сути deadlock – это взаимоблокировка, в результате которой система, или какие-то отдельные процессы начинают конкурировать за один ресурс.
В жизни такие ситуации встречаются, например, когда два человека желают пропустить друг друга на входе, предположим, в аудиторию. Однако после 3-4 фраз «только после вас!», кто-нибудь всё же пройдет первым.
На уровне программного обеспечения всё сложнее, пока программы не способны думать, машинный аналог фразы «только после вас!» будет повторяться вплоть до перезагрузки.
Как исполняющая система может повлиять на этот процесс? Вот тут нам на помощь и приходят алгоритмы на графах.
Для начала определимся, что же будет элементами нашего графа, и как его составить.

Интро

Этой статьей я начинаю цикл статей об известных и не очень структурах данных а так же их применении на практике.

В своих статьях я буду приводить примеры кода сразу на двух языках: на Java и на Haskell. Благодаря этому можно будет сравнить императивный и функциональный стили программирования и увидить плюсы и минусы того и другого.

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

Пролог

В продолжение опубликованной на выходных статьи.

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

Первая статья цикла

Интро

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

Недавно меня на хабре спросили, как в Pulse Audio включить 5.1. Решил написать вместо ответа небольшой пост, может еще кому-то пригодится, так как сам долго искал, правда достаточно давно, может сейчас с информацией попроще.

А включить все достаточно легко – через настройки звука (в моем случае — System>Preferences>Sound) заставляем все программы использовать Pulse Audio по дефолту, после чего редактируем конфиг Pulse Audio – sudo gedit (или любым другим редактором) etc/pulse/daemon.conf, Находим строчку “default-sample-channels”, ее необходимо будет раскомментировать и выставить желаемое количество каналов. Т.е. для 5.1 это будет 6, для 7.1 соответственно 8. Сохраниться, перезагрузить систему и наслаждаться.

Есть некоторые нюансы – на моей системе стерео тоже стало раскладываться на пять каналов, причем не просто стерео спереди и сзади, а как-то хитро, наподобие CMSS-3d (у меня Audigy). Как запретить раскладывать стерео я не искал, меня вполне устраивает, но кому-то может не понравиться. Второй нюанс – программный регулятор громкости, по крайней мере, у меня, повредился умом, и на полной громкости колонки стали шипеть и скрипеть. Я его просто поставил на 50% от максимального и все стало нормально, наверняка есть и более красивое решение, но я пока не искал.

Напоследок хотелось бы задать встречный вопрос – использовал ли кто-нибудь pulse c двумя звуковыми картами? От недефолтной требуется всего лишь играть музыку с помощью любого мало-мальски удобного проигрывателя. У меня пока никак не получается настроить, только с помощью каких-то жутких костылей – либо через винамп в вайне (sic!), либо через audacious используя oss output, что некрасиво и тормозит (используя pulse output plugin на вторую вывести никак не выходит).

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

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

В предыдущих (1, 2, 3) частях мы видели как разные пропорции использовались в геометрии, античном искусстве и современном промышленном дизайне. У нас осталась нераскрытой тема золотого сечения и еще одного корня — √5. Начнем же.

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

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

Мистификации и приписки из самых благих намерений встречаются в истории постоянно. Например, переписчики классического труда «Церковная история народа Англов» Беды Достопочтенного приделывали к тексту куски, дабы определенные церковные вопросы выглядели более благоприятно. А 25-28 главы VI книги «Записок о галльской войне» Цезаря по всей видимости не такие уж и Цезаря.

Так же и в символике. Надо чтобы люди чувствовали ее глубинный смысл, а сама форма не так важна. Возьми любую картинку, в ней обязательно да что-нибудь отыщется. Чем древнее, тем лучше. Самый древний у нас Египет, поупражняемся на нем.

Вот схема барельефа из гробницы Петосириса, найденной в 1919 году.



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



Выглядит достаточно круто, поэтому нет причин не заявить, что Египтяне знали о золотом сечении и специально все так сделали.

Мистифицировать геометрию легко и просто. Сейчас я покажу вам пару приемов. Загляните под кат.

После моего поста-туториала об установке и запуске Squeak, мне сообщили об ошибках возникших в процессе. Ошибки следующие:

• Зависание при установке FreeType Plus (в Pharo поддержка встроена, поэтому в нем проблемы нет).
• Не открывается SqueakMap в образе squeak-dev и squeak-webdev

Поэтому я решил разместить решение этих двух проблем.

Некоторое время назад на хабре проскакивал топик про «континуации» от ХабраЮзера qmax. Он был весьма впечатлен идеей, а вот подробно рассказать не вышло. И вот недавно один из разработчиков Seaside, Джулиан Фитзелл написал потрясающую по своей доходчивости статью. С его разрешения я сделал ее перевод и хотел бы поделиться с хабрасообществом.

Сразу хотелось бы сказать о терминологии. В качестве перевода слова continuation я использую наиболее близкое по смыслу «продолжение». Общая же терминология статьи для неискушенного в Smalltalk разработчика может показаться непривычной. Так, вместо стека вызовов используется «цепь контекстов», а вместо потока — «процесс». Если у вас останутся вопросы после прочтения — смело задавайте их в комментариях. Спасибо.

С выходом на большую арену Ruby и с появлением фреймворка Seaside, все чаще упоминается Smalltalk. Однако, среди молодого поколения (разработчики до 30 лет) бытует мнение, что это мертвый язык, разработанный на заре появления ПК и тогда же похороненный. Упоминание о Smalltalk на лекциях по ЯП, недалеко от COBOL, делает его еще более архаичным.

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

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

Смолток до сих пор остаётся любимой игрушкой многих программистов. Он просто прекрасен!
Вот взять хотя бы Method Finder: пишешь что есть и что надо получить — смолток находит методы, которыми это можно сделать

Все мы прекрасно знаем о том, как разрабатывается ПО. Подумали 10 минут и сразу пошли кодить. Цикл создания программного обеспечения состоит из многих ключевых моментов. Это такие моменты как планирование, создания архитектуры, создание SRS, создание дизайна и тд и тп.

Как получить приглашение на торрент-трекер what.cd? What.cd — закрытый трекер с кучей музыки в хорошем качестве. Выпрашивать инвайт в форумах и популярных блогах в топиках «Инвайты на what.cd» с тысячей комментариев мне не по душе.

Есть простой официальный способ. Для этого надо знать английский язык, уметь пользоваться IRC и иметь представление об аудио-форматах и кодеках. Ну, и как пользоваться торрентами, конечно.

Кратко: чтобы получить инвайт надо подключиться к IRC-каналу #what.cd-invites на сервере irc.what.cd и пройти несложное собеседование.

Далее в деталях.