Transmission — один из самых популярных torrent клинтов в мире Unix-подобных операционных систем и, к примеру, является выбором по умолчанию в таких дистрибутивах как Ubuntu, Fedora и openSUSE. В своей работе Transmission потребляет заметно меньше системных ресурсов нежели другие torrent клиенты благодаря чему может и используется во многих встраиваемых ОС даже таких устройств как домашние WiFi роутеры/точки доступа или сетевых медиаплеерах. Кроме того, Transmission обладает встроенным web-интерфейсом и не требует для его работы ни Apache, ни Lighttpd, ни какого другого http сервера. Именно о установке и настройке новейшей версии этого замечательного torrent клиента я и хочу рассказать в этом посте.

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

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

В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого, зачастую, пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll-back) к предыдущей версии, в случае неудачи. Сам по себе план установки также должен пройти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя — это потеря репутации и большого количества средств, например: банки, финансовые компании или даже баннерные сети. Поэтому тестирование инсталляторов можно назвать одной из важнейших задач по обеспечению качества программного обеспечения.

Именно такой комплексный подход с написанием планов, пошаговой проверкой установки и отката инсталляции, полноправно можно назвать тестированием установки или Installation Testing.

Под катом много текста о том, что следует помнить при тестировании.

Сегодня я расскажу на абстрактном примере как правильно создать *.deb пакет для Ubuntu/Debian. Пакет мы будем делать бинарный. Пакеты, компилирующие бинарники из исходников здесь не рассматриваются: осилив изложенные ниже знания, в дальнейшем по готовым примерам можно понять суть и действовать по аналогии :)

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

В качестве бонуса в конце статьи будет пример быстрого создания собственного локального репозитория: установка пакетов из репозитория позволяет автоматически отслеживать зависимости, и конечно же! — устанавливать всё одной консольной командой на нескольких машинах :)

Для тех, кто не хочет вдаваться в мощную систему установки софта в Linux, рекомендую посетить сайт проги CheckInstall: она автоматически создаёт deb-пакет из команды «make install» ;) А мы вместе с любопытными —

Устанавливая Ubuntu или пользуясь LiveCD Ubuntu, встречались ли Вы хотя бы с одной из этих проблем:
 — необходимость каждый раз после установки ubuntu доустанавливать нужный софт, подключать дополнительные репозитории;
 — однообразная и длительная настройка внешнего вида gnome после установки;
 — Вам нравится openbox, lxde или любой другой desktop, на базе которого нет ни одного дистрибутива ubuntu;
 — Ваше оборудование требует дополнительной настройки и установки дополнительных драйверов после установки Ubuntu;
 — LiveCD не содержит необходимый для Вашей работы софт или Вы наоборот хотите облегчить его, удалив все ненужное.

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

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

• Атомарность пакета (представление продукта в виде одного файла);
• Наличие скриптов пред/пост установки/удаления ПО;
• Возможно указания зависимостей для ПО.

Кроме того, при развёртывании ПО на основе пакетов, а не на основе SVN, вы гарантировано защищены от проблем с .svn-папками.

Недавно на Хабре была опубликована статья под провокационным заголовком и призывом к прекращению изобретений велосипедов в API-строении. Поскольку тема мне интересна, то я просто не мог пройти мимо.
Увы, реальность за хабракатом меня сильно разочаровала — я увидел очередной велосипед, да еще и с квадратными колесами. (Коллеги, ничего личного, только техническое обсуждение.) Правда, авторы честно сказали, что увидели на нескольких сайтах модное слово REST и решили сделать по нему. Только вот поняли они этот «РЭСТ» по-своему, примерно как Дед Щукарь читал и понимал толковый словарь.
В этом топике я призываю по-настоящему покончить с велосипедами в API сайтов. Ведь получается какой анекдот: АПИ разрабатывается для упрощения доступа к сайту и легкости подключения внешних систем, а получается такой, что с ним еще сложнее, чем без него :)

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

В повествовании будут рассмотрены следующие вопросы:

1. Базовые технологии: XML-RPC, REST, SOAP и краткое сравнение
2. Дао вебсервиса
3. Просветленные API
4. Как отличить сайтовое API от говна
5. Выводы

Добро пожаловать!

    В прошлый раз мы обсуждали, как можно писать свое PyQt4-приложение, опираясь на логику сгенерированного программкой pyuic4 файла. Как это часто бывает — после написания топик получил много интересных и, что самое главное, содержательных комментариев, объясняющих, почему в отдельных случаях я прав, а в других неправ.
    Самое любопытное состоит еще и в том, что обсуждение интересно как для питонистов, так и для приверженцев C++, ибо в данном случае разница невелика, в основном только незначительные вещи в синтаксисе. Все это потому, что PyQt4, по своей сути, является простой оберткой вокруг сишных Qt-классов, сохраняющей все названия и методы. Итак, вот вам чашечка чая или кофе, устраивайтесь поудобнее, давайте начнем нашу беседу.

Небольшое вступление

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

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

Речь пойдет об инструменте, который с сегодняшнего дня помогает мне тестировать пользовательский интерфейс. Простой, как угол дома, но экономит столько времени!

Уверен, что многие это знают, но для меня это стало просто откровением. Своего рода панацея. Даже решился записать свой первый видеокаст:



PS. Открыл топик для всех. Думаю людям с других платформ тоже любопытно, чем нас балуют инструменты для разработки.

PS2. Тема затрунула хабраразум. Ниже будут добавлять полезные ссылки по теме, подсказанные в комментариях.

GTM познал юнит-тесты для UI
Нативные инструменты из iPhone SDK (Unit Testing Applications)

Каждый раз, когда мне приходится делать резервную копию системы я искал незанятую USB флэшку, на которую заливал установочный образ ArchLinux и грузился в него. В этом способе был очень неприятный момент — мне приходилось искать незанятую USB флэшку размером >512 MiB, при том что под рукой всегда лежала SD карточка на 64 MB, которой для нужд бэкапа и восстановления вполне хватило бы. Но с SD карточкой была одна проблема — редкий дистрибутив мог загрузиться с нее на моем Eee PC 900. Перепробовав с дюжину различных мелких дистрибутивов, ни один из которых мне не подошел полностью, я решил сделать свою live систему.

Задача: создать пакет для Debian для выливки демона/сайта на сервер.
Я никогда ранее не работал с deb-пакетами — так что решение может быть не оптимальным. Но оно работает и достаточно просто в использовании.

Для начала — что такое WiX? Технология WiX (Windows Installer XML) представляет собой набор инструментов и спецификаций упрощающих процесс создания дистрибутивов на базе MSI (Microsoft Installer). Если объяснять проще то это обертка вокруг MSI с человеческим лицом.

На мой взгляд изучать проще всего на простых примерах. В данной статье я приведу пример простейшего инсталлятора.

Если вы не очень часто программируете на Java, то этот топик скорее всего будет для вас бесполезен. Не читайте его :)

Недавно понадобилось решить следующую задачу: определить класс, которым параметризован generic-класс.

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

public class AbstractEntityFactory<E extends Entity> {
  public Class getEntityClass() {
    return E.class;
  }
}

Увы, IDE либо компилятор сразу укажут вам на ошибку («cannot select from a type variable» в стандартном компиляторе): " E.class" — не является допустимой конструкцией. Дело в том, что в общем случае во время исполнения программы информации о реальных параметрах нашего generic-класса может уже и не быть. Поэтому такая конструкция в Java не может работать.

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

Надеюсь, что данный материал будет кому-нибудь полезен.

Siege – это утилита для нагрузочного тестирования веб-серверов. Она была создана для того чтоб дать разработчикам возможность проверить ресурсоёмкость своего кода в условиях, максимально приближенных к реальным. Так же Siege может имитировать обращения к сайту сразу нескольких пользователей. Это позволяет держать сервер как бы «под осадой» долгое время. Количество запросов, произведённых при «осаде», рассчитывается из общего количества пользователей и количества их обращений к серверу. Например 20 пользователей, обратившись по 50 раз, создают в общей сложности 1000 запросов. Результат, выводимый программой после тестирования, включает в себя время затраченное на проверку, общее количество переданной информации ( включая заголовки ), среднее время ответа сервера, его пропускную способность и число запросов на которые пришёл ответ с кодом 200. Эти данные формируются и выдаются при каждой проверке. Подробно они описываются ниже. Siege имеет 3 основных модели работы – режим регрессионного тестирования, режим имитации Интернета и режим грубой силы. Программа считывает порцию ссылок из конфигурационного файла и обращается к ним по очереди ( режим регрессионного тестирования ) или случайно ( имитация интернета ). Или же пользователь может указать один единственный адрес к которому будут производиться все обращения – режим грубой силы.

UPD: спасибо за плюсы, перенес в тематический блог.

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

Qt можно считать наиболее распространенной кроссплатформенной библиотекой для разработки пользовательских интерфейсов. Carbon (С++) и Cocoa (Objective-C), в свою очередь, являются основными фреймворками, используемыми Apple, что означает гармоничный внешний вид и наилучшую интеграцию с системой при их использовании. Несмотря на попытки создания свободных клонов, в полном объеме они реализованы только в MacOS.

Уверен, что вопросом связи Qt и Cocoa задавались многие, но в условиях отсутствия внятной информации в интернете вряд-ли достигли значимых успехов.

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

Наверняка многие знают о существовании в mySQL функции FOUND_ROWS(). Её чаще всего используют для подсчета общего числа строк в таблице, удовлетворяющих заданным условиям. Используют её обычно совместно с директивой SQL_CALC_FOUND_ROWS следующим образом:

Mysql> SELECT SQL_CALC_FOUND_ROWS * FROM table WHERE column > 1 LIMIT 0, 50;
Mysql> SELECT FOUND_ROWS();

Результатом второго запроса будет общее количество строк в таблице «table», удовлетворяющих условию «column > 1» (а не только тех, что были возвращены первым запросом).
Следует учитывать некоторые особенности этой функции, когда используете её без директивы SQL_CALC_FOUND_ROWS, о чём добросовестно предупреждает документация mySQL: в этом случае она вернёт общее количество обработанных строк (не возвращённых!). Например:

Mysql> SELECT * FROM table LIMIT 0, 50;
Mysql> SELECT FOUND_ROWS();

Результатом, как и ожидается, будет «50». Но следующие запросы вернут не слишком ожидаемый результат:

Mysql> SELECT * FROM table WHERE column > 1 LIMIT 50, 50;
Mysql> SELECT FOUND_ROWS();

Несмотря на то, что первый запрос вернёт 50 строк, результатом будет «100», т.к. mySQL пришлось просмотреть именно 100 строк.

Административная зона любого веб-приложения давно стала излюбленной мишенью для хакеров и её безопасность чрезвычайно заботит разработчиков. Это касается и WordPress — при сустановке нового блога система создает аккаунт администратора с уникальным случайно сгенерированным в реальном времени паролем, чем блокирует всеобщий доступ к настройкам системы, контролируя его c помощью страницы авторизации.

Эта статья сфокусирована на вопросах усиления безопасности WordPress — как административной панели, так и настроек блога, подразумевая все содержимое папки «wp-admin», которое отображается только после авторизации. Мы сознательно выделили фразу "после авторизации" — вы должны четко осознавать, что только один простой запрос отделяет «злого хакера» и админку всего вашего блога или сайта! А последняя защищена настолько сильно, насколько мощный пароль вы выбрали.



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