Insight IT

KDE 4 увидел свет

Иван Блинков — Fri, 11 Jan 2008 21:37:00 +0300

Наконец-то наступил тот самый день, которого так долго ждали многие пользователи различных дистрибутивов Linux и многих других unix-like операционных систем. Да-да, сегодня вышла новая major-версия знаменитого K Desktop Environment под номером 4.0!

Вкратце перескажу оффициальный пресс-релиз: - Набор библиотек, лежащих в основе KDE, был кардинальным образом переделан, изменения произошли в каждой из них. Появилось два новых framework'а: один мультимедийный.- Phonon, а второй - Solid - для интеграции интерфейса для работы с используемым оборудованием в рабочее окружение. - Рабочий стол KDE приобрел новую оболочку под названием Plasma, которая поддерживает огромное количество widget'ов, эффектов и прочих украшательств. - Все программное обеспечение, входящее в его состав также не осталось без изменений (немного от себя: лично мне больше всего понравились изменения в Kopete - единственный icq клиент под *nix, в котором появилась возможность использования x-status, которой сильно не хватало, успел заценить его еще некоторое время назад в beta-версии KDE 4). Помимо Konqueror появился новый файловый менеджер под названием Dolphin и просмотрщик документов Okular (основанный на KPDF, но поддерживающий существенно большее количество форматов документов). - Тема рабочего окружения, используемая по-умолчанию также изменилась и называется она теперь Oxygen, на вкус и цвет конечно, но я думаю найдется много людей, которым она прийдется по душе.

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

На личном опыте новый релиз я опробовать еще не успел, но планирую этим делом заняться в ближайшем будующим, наверное сразу же как появятся ebuild'ы для Gentoo. После чего несомненно поделюсь с Вами впечатлениями.

Unix way

Иван Блинков — Sun, 06 Jan 2008 19:30:00 +0300

На эту тему в Сети можно найти несметное количество статей и обсуждений, не удивлюсь если Вам уже доводилось читать что-либо подобное в прошлом или может быть работать в одной из множества операционных систем, разработанных с использованием этой идеологии. За этим словосочетанием скрывается целая философия разработки программного обеспечения, начавшая свое развитие в середине 90-х годов прошлого века и воплощенная в огромном количестве операционных систем и в еще большем количестве opensource проектов. В этом тексте я хочу поведать Вам свой взгляд на эту философию с двух точек зрения: программиста и пользователя.

Наиболее точно охарактеризовать то, о чем пойдет речь можно лишь процитировав одного из основателей традиций Unix и разработчика технологии под названием "Unix pipes" - Douglas'а Mcllroy'а:

"This is the Unix philosophy: - Write programs that do one thing and do it well. - Write programs to work together. - Write programs to handle text streams, because that is a universal interface."

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

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

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

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

Взгляд с точки зрения программиста

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

Как же это выглядит?

Одна задача - одна программа

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

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

Unix pipes

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

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

Взгляд с точки зрения пользователя

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

У каждой элементарной программы, соответствующей этой идеологии, должен быть входной и выходной стандартные текстовые потоки - stdin и stdout соответственно. Механизм unix pipes позволяет перенаправлять эти потоки любой программы произвольным образом с помощью трех простых операторов: |, > и <. Первый из них - | перенаправляет stdout команды слева от него в stdin команды справа, а > и < предназначены для перенаправление потоков в/из файлы по схожему принципу.

Предлагаю рассмотреть этот механизм на примерах. Возьмем несколько базовых утилит, имеющихся на практически любой unix-like системе:

cat - вывод содержимого указанного первым параметром файла в stdout (по умолчанию stdout в большинстве программ направляется в консоль)
less - постраничный вывод текста, полученного в stdin в stdout (переключение страниц и некоторые другие функции производятся с клавиатуры, возможны и другие варианты использования, но они нам не нужны)
grep - построчная фильтрация текста, полученного в stdin, вывод только строк, содержащих текст, указанный первым аргументом, и вывод результата в stdout.

Начнем с примера, позволяющего прочитать постранично любой файл:

cat readme.txt | less

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

cat readme.txt | grep unix > readme.txt

Этот пример должен был бы удалить из файла все строки, где нет слова "unix". Маленькое замечание: при использовании такого перенаправления, перед началом передачи данных файл обнуляется. В этом и заключается ошибка данного примера: файл очищается до того, как поток данных успел пройти через фильтрацию grep, что приводит к просто очистке файла. Если же Вам все же нужен отфильтрованный список строк - стоит разместить в другом файле (которым можно было бы подменить исходный при необходимости), просто поменяв его название:

cat readme.txt | grep unix > meread.txt

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

cat readme.txt | grep unix >> readme.txt

В unix-like системах есть еще одна интересная особенность, косвенно связанная с этим механизмом: все устройства являются файлами и соответственно, прикреплены к файловой системе, для них выделена отдельная директория, по традиции называемая /dev. Работа с ними также ведется на тех же правах что и с обычными файлами, например набрав в консоли:

cat readme.txt > /dev/dsp

в ответ от компьютера Вы услышите некоторый звук, издаваемый из колонок или наушников.

Подводим итоги

С точки зрения простого пользователя использование opensource решений, построенных на базе философии unix, является как минимум нетривиальной задачей - ведь от него требуется как минимум понимание насколько мощная и гибкая система попала ему/ей в руки. Отсутствие единственного верного способа решения той или иной задачи ставит большинство людей попросту в тупик, у них начинают разбегаться глаза от десятков тысяч программ, доступа к которым есть у всех пользователей unix-like операционных систем, с помощью набора простой волшебной команды в консоли, состоящей не более чем из трех-четырех слов.

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

Три основных компонента парадигмы объектно-ориентированного программирования

Иван Блинков — Sat, 05 Jan 2008 22:28:00 +0300

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

Вы спросите у меня: как это все может быть связано с темой этой записи? - об этом я и собираюсь Вам поведать.

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

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

наследование
инкапсуляция
полиморфизм

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

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

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

class Human
{
  public int height; // рост
  public int age; // возраст
  public String gender; // пол
  public String eyesColor; // цвет глаз
  public String hairColor; // цвет волос
}

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

class Human
{
  public int height; // рост
  public int age; // возраст
  public String gender; // пол
  public String eyesColor; // цвет глаз
  public String hairColor; // цвет волос
  public void walk()
  {
    System.out.println("Я иду!");
  }
  public void work()
  {
    System.out.println("Я работаю в большом офисном здании");
  }
}

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

Наследование

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

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

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

class Director
{
  public int height; // рост
  public int age; // возраст
  public String gender; // пол
  public String eyesColor; // цвет глаз
  public String hairColor; // цвет глаз
  public void walk()
  {
    System.out.println("Я иду!");
  }
  public void work()
  {
    System.out.println("Я работаю в большом офисном здании");
  }
  public void idle()
  {
    System.out.println("Я ничего не делаю!");
  }
}

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

class Director extends Human
{
  public void idle()
  {
    System.out.println("Я ничего не делаю!");
  }
}

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

Полиморфизм

Это слово пришло к нам из греческого языка, понимания этого термина легко достичь, просто переведя его на русский язык: πολύμορφος - многоформенность. То есть в наиболее простом случае подразумевается использование одной и той же переменной (или массива) для хранения информации об объектах, описываемых разными классами. Представим, что нам необходим стандартизованный способ узнать кем же работает тот или иной человек, естественно для этого необходимо описание соответствующего метода для выполнения этой функции в каждом классе, причем он должен одинаково называться в каждом из них. Для реализации этого примера на языке Java нет необходимости использовать дополнительных ключевых слов (в отличие от, например, C#, где необходимо использование слова virtual в заголовке метода в базовом классе и override - в производных). Продолжая приводить примеры на Java имеем три производных класса (для упрощения опустим дополнительные методы, которые могли бы присутствовать):

class Director extends Human
{
  public void work()
  {
    System.out.println("Я работаю директором!");
  }
}

class Programmer extends Human
{
  public void work()
  {
    System.out.println("Я работаю программистом!");
  }
}

class Manager extends Human
{
  public void work()
  {
    System.out.println("Я работаю менеджером!");
  }
}

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

class AskHuman
{
  public static void main(String[] args)
  {
    public Human person;
    person = new Director();
    person.work();
    person = new Manager();
    person.work();
    person = new Programmer();
    person.work();
}

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

Я работаю директором! Я работаю менеджером! Я работаю программистом!

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

Также имеет смысл упомянуть, что в некоторых языках программирования существует такое понятие как интерфейс, предназначенное именно для стандартизации механизма полиморфизма. Смысл интерфейса состоит в том, что он предоставляет классу список методов, которые класс обязан реализовать (ключевое слово в Java - implements), при этом сам интерфейс не содержит какой-либо реализации и может быть только определен. Выглядит примерно следующим образом:

interface Worker
{
  public void work();
}

class Director extends Human implements Worker
{
  public void work()
  {
    System.out.println("Я работаю директором!");
  }
}

class Programmer extends Human implements Worker
{
  public void work()
  {
    System.out.println("Я работаю программистом!");
  }
}

class Manager extends Human implements Worker
{
  public void work()
  {
    System.out.println("Я работаю менеджером!");
  }
}

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

Инкапсуляция

Наверняка Вы уже задавались вопросом о том, что же значит слово public во всех предыдущих примерах. Это ключевое слово является частью реализации механизма инкапсуляции в языке Java, суть его состоит в том, чтобы дать возможность определить область видимости для составных частей класса, это очень актуально при написании ПО, использующего библиотеки, plug-in'ы или при написании программы группой людей. Ведь если Ваш класс подразумевает какие-либо ограничения для переменных или методов (например - возраст не может быть отрицательным), то их легко обойти воспользовавшись прямым доступом к ним из-за пределов класса или просто выполнив наследование.

Для предотвращения этого используется система параметров, назначаемых переменным и методам внутри класса для присвоения им "уровней доступа" (на примере опять же Java, но в большинстве известных мне высокоуровневых языков используется та же система):

public - назначается по-умолчанию - полностью свободный доступ
private - доступ предоставляется только другим компонентам класса
protected - доступ предоставляется остальным компонентам класса, а также всем наследникам данного класса

Данный механизм является незаменимым помощником разработчиков любых более-менее крупных проектов, следующих принципам ООП.

Вместо заключения

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

Объектно-ориентированное программирование: а что же это?

Иван Блинков — Fri, 04 Jan 2008 21:39:00 +0300

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

Сама концепция этого подхода к программированию достаточно проста для понимания, и заключается она в...

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

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

Для начала напомню тот факт, что в языках высокого уровня простейшими элементами, доступными программисту, являются:

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

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

Класс

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

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

Объект

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

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

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