Разберем создание интерфейса на pygtk на примере самого примитивного калькулятора. Много картинок, немного кода.
gtkbuilder наиболее прогрессивный формат описания gtk интерфейса в xml,
если вы ранее использовали libglade, вы можете сконфертировать .glade файл в новый формат командой libglade-convert

Почитать описание других паттернов.

Проблема

Минимизировать зависимость подсистем некоторой сложной системы и обмен информацией между ними.

Описание

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

Таким образом, минимизация зависимости подсистем, а также снижение объема передаваемой между ними информации — одна из основных задач проектирования.

Один из способов решения данной задачи — использование паттерна «Фасад».

Продолжим знакомство с технологией OpenMP и рассмотрим некоторые функции и новые директивы.

Почитать описание других паттернов.

Проблема

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

Описание

Для более детального понимания проблемы, рассмотрим конкретную ситуацию. Пусть имеется некоторый объект — «кнопка», принадлежащий классу объектов «Кнопка», на который понадобилось возложить дополнительные обязанности. Под обязанностями, в данном контексте, понимаются какие-либо особенности поведения объекта. В случае с кнопкой, можно рассмотреть поведение объекта при его отображении на экране. При этом, будем считать, дополнительными обязанностями — отображение рамки кнопки, надписи, иконки. Важно понимать, что все эти обязанности должны иметь возможность быть наложенными как одновременно, так и по отдельности. Очевидно, первое, что приходит на ум — порождение классов (механизм наследования). Для данной задачи возможно это и выход — расширить класс «Кнопка» семью (2³-1 = 7) различными классами, сочетающими в себе всевозможные комбинации обязанностей. Это классы: «Кнопка_С_Надписью», «Кнопка_С_Рамкой», «Кнопка_С_Иконкой», «Кнопка_С_Надписью_И_Иконкой», «Кнопка_С Рамкой_И_Иконкой», «Кнопка_С_Надписью_И_Рамкой», «Кнопка_С_Надписью_И_Рамкой_И_Иконкой». А если таких обязанностей будет не три, а хотя бы десять, не говоря уже про неудобство работы с подобной структурой. Безусловно, порождение классов в таком случае — заведомо проигрышный вариант. Однако, из этой ситуации есть выход — паттерн «Декоратор».

Продолжаю маленькими порциями выдавать то, что знаю про скрытые резервы каждого человека.

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

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

Как правило, из-за неумения банально управлять своими связками и глоткой (гусары!) Есть 2 типичные ошибки:

1. Стараясь сказать громко, чтобы все услышали, человек сильно напрягает связки. А что такое связки? Правильно, мышцы, которые буквально сжимают горло! Чтож мы имеем? Сильное напряжение легких, глотки, рта и… сдавленный, визгливый голос. Красиво, правда?

2. Человек старается говорить громко, но все равно посылает звук себе под нос! Как будто надо оглушить какого-то рядомсидящего слушателя. И всем как-то неловко.

Что же с этим можно сделать?

.NET и работа с неуправляемым кодом. Часть 1

.NET и работа с неуправляемым кодом

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

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

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