Здравствуйте!

В свое время я не без удовольствия прочитал замечательную статью «Гитаризм для линуксоида — why not?». И решил написать небольшое продолжение этой статьи и рассказать о некоторых вещах более практического плана, а именно создать небольшое руководство для тех, кто, скажем, неожиданно решил увековечить свое творчество путем записи относительно непростого гитарного произведения. :)
Итак, поехали.

Эта статья посвящена программированию GUI на базе фреймворка Qt от Nokia. Мы рассмотрим способы разработки интерфейсов для нативного отображения на платформах Windows, Linux и Mac OS X.

Презентацию^[1] вёл Йенс Бач-Вииг (Jens Bache-Wiig) — разработчик Qt (с 2005 года), занимающийся интерфейсами (look and feel).

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

Итак, приступим. Каждое графическое окружение имеет свой свод правил (User Interface Guidelines, UIG) по созданию интерфейсов, предназначенных для этих окружений. Из основных можно отметить такие руководства как Windows User Experience Interaction Guideline, Apple Human Interface Guideline, KDE User Interface Guideline и GNOME HID. Каждое из этих руководств «определяет положение кнопочек и рюшечек» конкретного окружения. Фреймворк Qt, в свою очередь, осуществляет поддержку всех этих руководств, предоставляя разработчику возможность создавать программы с использованием виджетов, «подстраивающихся» под окружение.

Многим музыкантам известно, что недавно Arobas Music выпустила новую версию редактора табулатур Guitar Pro 6. Также, компания обещала выход linux-версии. В общем, они выполнили свое обещание, но она доступна лишь для x86 систем в виде deb пакета. На x64 системе программу запустить пока не удавалось или вообще не было таких попыток.
Мне удалось заставить работать ее на x64 системе.

Заключительная глава третьей части серии руководств Linux для новичков. Основы конфигурирования рабочей оболочки, настройка переменных окружения, а также подведение итогов всей третьей части.

Навигация по основам Linux от основателя Gentoo:

Часть I:

1. BASH, основы навигации
2. Управление файлами и директориями
3. Ссылки, а также удаление файлов и директорий
4. Glob-подстановки

Для меня красота C++ заключается, в первую очередь, во вседозволенности и ужасающей мощи языка. Мы можем работать с памятью так же плотно, как и в C, и в то же время имеем такие средства абстракции, как шаблоны и STL, где параметризовать можно что угодно и чем угодно.
Плата за это соответствующая — не всегда вразумительные ошибки компилятора (попробуйте забыть поставить точку с запятой после определения класса), очень большой срок подготовки и обучения программистов, но самое главное — некоторые баги становятся заметными только во время исполнения программы.
Мы хотим больше полезных ворнингов до запуска наших программ. Одно из средств получения желаемого — статический анализ кода. Статический — значит, не запуская программу. Интересны не только вероятные ошибки, случаи undefined behaviour, утечки памяти, но и вещи вроде недоступности/неиспользуемости кода, рекомендации по повышению интуитивности стиля программирования.

VIM содержит сотни команд, выучить их все невозможно, да и по правде говоря «зазубривание» — дело неблагодарное. Читая различные факи и туториалы я взял за правило заносить новые для меня команды в отдельный файл, сопровождая их кратким описанием. В процессе работы с редактором я часто заглядываю в этот файл и с течением времени многие команды из него пополняют мой стандартный набор. Своим файлом-шпаргалкой я и хочу с вами поделиться.

Привет. С вами олимпиадное хобби. Здесь мы выбираем себе олимпиадную задачу по программированию, разбираем ее, вырабатываем возможные пути решения и реализовываем задуманное, после чего отправляем на суд. Нам потребуется знание одного из языков программирования: c, c++, java, pascal, терпение, ловкость и базовые знания английского языка, чтобы понимать условие задачи, хотя последний пункт необязателен, ведь я вольно перескажу условие на русском языке.

Вы не забыли размяться? Если забыли, то быстренько разминайтесь, и возвращайтесь к нам.

Напоминаю, что я беру задачи с сайта http://uva.onlinejudge.org, и сегодня случайный выбор пал на задачку под номером 154 — задачу об утилизации отходов.

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

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

Задачи я буду брать с сайта http://uva.onlinejudge.org/, где располагается достаточно большая коллекция задач на любой вкус, и там же можно проверить свое решение. Выбирать буду случайным образом и всегда доводить начатое до финального решения, которое ознаменуется оценкой «Accepted» (Принято). Для решения этих задач нам потребуется знание одного из языков программирования: c, c++, java, pascal, а также терпение, логика и базовое знание английского языка, т.к. условия задач мы получаем на английском языке.

Итак, начнем мы с простой задачки из набора «Для новичков» для разминки, чтобы проверить свои способности.

Проектируя архитектуру одного проекта, остановился на паттерне MVP — подкупила возможность легко менять ui, а также простота покрытия тестами. Все примеры реализации MVP, что я нашёл в сети, были на C#. При реализации на Qt возникла пара неочевидных моментов, решение которых было успешно найдено. Собранная информация ниже.

Привет всему хабросообществу.

Время не стоит на месте. После публикации моего справочника по Postgresql очень многое успело поменяться, а точнее добавиться в эту отличную СУБД. После выхода PostgreSQL 9 версии я понял, что потребуется добавить информацию о нововведениях для этой версии. Тем более, что 9 версия знаменуется выходом репликации из коробки.

Много слов сказано о том, как правильно писать юнит-тесты, и вообще о пользе TDD. Потом ещё и какое-то BDD замаячило на горизонте. Приходится разбираться, что из них лучше и между ними какая разница. Может, это и есть причина, почему большинство разработчиков решили не заморачиваться и до сих пор не используют ни того, ни другого?

Коротко: BDD — это дальнейшее развитие идей TDD, стало быть, его и надо использовать. А разницу между TDD и BDD я попробую объяснить на простом примере.

Рассмотрим 3 ревизии одного юнит-теста, который я нашёл в одном реальном проекте.

Попытка номер №1

Первая версия этого юнит-теста была такой:

Руководство по установке инструментов для разработки и инсталляции разработанного приложения на целевую систему. Основной ПК работает под управлением Debian, а целевой машиной – mini2440 на основе процессора 400 MHz Samsung S3C2440A ARM920T.

В руководстве рассматриваются работа с эмулятором QVFB, компиляция на рабочей машине для целевого устройства, компиляция и установка драйвера tslib, установка библиотек на целевую машину.

Хочу признаться сразу, что я вас отчасти обманул, ибо драйвер, если верить википедии — это компьютерная программа, с помощью которой другая программа (обычно операционная система) получает доступ к аппаратному обеспечению некоторого устройства. А сегодня мы создадим некую заготовку для драйвера, т.к. на самом деле ни с каким железом мы работать не будем. Эту полезную функциональность вы сможете добавить сами, если пожелаете.

То, что мы сегодня создадим, корректнее будет назвать LKM (Linux Kernel Module или загрузочный модуль ядра). Стоит сказать, что драйвер – это одна из разновидностей LKM.

Писать модуль мы будем под ядра линейки 2.6. LKM для 2.6 отличается от 2.4. Я не буду останавливаться на различиях, ибо это не входит в рамки поста.

Мы создадим символьное устройство /dev/test, которое будет обрабатываться нашим модулем. Хочу сразу оговориться, что размещать символьное устройство не обязательно в каталоге /dev, просто это является частью «древнего магического ритуала».

В этом отрывке вы узнаете про множество интересных и полезных команд по работе с текстовыми данными в Linux. Также даны основы работы с потоками ввода-вывода в bash.

Навигация по основам Linux от основателя Gentoo:

Часть I

1. BASH: основы навигации (вступление)
2. Управление файлами и директориями
3. Ссылки, а также удаление файлов и директорий
4. Glob-подстановки (итоги и ссылки)

Часть II

1. Регулярные выражения (вступление)
2. Назначения папок, поиск файлов
3. Управление процессами
4. Обработка текста и перенаправления
5. Модули ядра (итоги и ссылки)

Есть один замечательный сайт, посвящённый алгоритмам — наверняка многие из Вас о нём слышали и выкачивали его содержимое Teleport’ом или чем-нибудь подобным. Но совсем недавно Максим (автор сайта) создал очень удобную pdf-книжку из всех статей, что присутствовали на сайте. Я знаю, что ему будет приятно узнать, что его труды пригодились IT-сообществу, поэтому я и решил написать тут о электронной книге с алгоритмами.

Пару месяцев назад нами (2Товарища и Антон Исайкин) была обнаружена уязвимость, присущая в основном большим интернет-проектам (вроде Рамблера, Мейла, Яндекса, Оперы и пр.). Удалось получить доступ к файловым структурам известнейших сайтов (в общей сложности 3320 сайтов) и в ряде случаев их полные исходные коды.

Итак, сегодня День Знаний, любимая многими дата (хотя большинством всё же не очень). Однако именно сегодня мне почему-то захотелось выпустить обновлённую версию русскоязычного руководства по переходу на Ubuntu 10.04 «Lucid Lynx». С момента последнего выпуска было исправлено огромное количество ошибок, плюс добавилось немного весьма полезного материала.

Без сомнения осень — отличное время для изучения современных компьютерных технологий, а Ubuntu — идеальный дистрибутив для первоначального знакомства с богатейшим миром Linux. Надеюсь эта книжка поможет вам легко перейти на использование мощной современной полностью бесплатной операционной системы и забыть о проблемах и неудобстве в работе с компьютером. Руководство ориентировано на новичков и описывает установку, настройку и основы работы в Ubuntu Desktop с прицелом на Ubuntu 10.04 «Lucid Lynx».

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

Правило прозрачности: проектируйте ПО сразу с учетом отладочных инструментов

Было время, когда я ничего не знал про VCS, ни что это такое, ни тем более зачем это мне. И верхом своих достижений считал папочку с архивами версий. К моменту осознания необходимости системы контроля версий я уже набил шишек и прочувствовал необходимость такого инструмента. Но борландовский аналог CVS меня не впечатлил. У каждого файла свой номер версии. Как мне получить срез определенного релиза я так и не разобрался. А в это время SVN победоносно шла сквозь умы разработчиков. Черт, это было то, чего мне так не хватало. Прочитав доку и начав работать я просто влюбился в нее. Да, были трудности и определенные неудобства, но куда без них.
Так я и работал бы в SVN, но ничего не стоит на месте. В интернете уже потекли тонкие ручейки новостей про Git. Я не кидаюсь за каждой новой технологией, и прошло уже достаточно много времени, пока мне не прожужжали этим Git’ом все мозги. Мне стало любопытно, я вначале присматривался, примерялся, а потом плюнул и начал новый проект на Git. Мучался с ребятами 2 недели, накачал литературы, написал шпаргалку… ничего, привыкли, … а потом меня поперло.

Теперь меня регулярно просят рассказать про Git и что в нем такого. Уже надоело, поэтому этот пост для тех, кто еще сомневается.

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

Правило пятое: добавляйте сложность лишь там, где она действительно необходима (Design for simplicity; add complexity only where you must.)