Додання нового клієнта

Насправді, додати нового клієнта не так вже й складно. Для цього необхідно

1. Додати логін і пароль бота до параметру buildslaves
2. Прив’язати до процесу збирання
3. Внести в розклад збирання

Слід не забути одну просту річ: якщо доступ до репозитарію віддалений, необхідно хоча б раз виконати вхід до
віддаленої системи вручну. Якщо цього не зробити, бот не зможе отримати джерельні коди проекту, оскільки буде наштовхуватись на дві помилки:

1. невідомий сертифікат (вирішується одноразовим входом з доданням сертифікату в довірені)
2. незареєстрований користувач (вирішується одноразовим входом з введенням та автоматичним збереженням реєстраційних даних клієнтом subversion).

Фільтрація по розширенню файлів

Можливі такі випадки, коли в репозитарії зберігаються не лише джерельні коди, а ще й супутня документація, файли опису, які не впливають на процес збирання. При цьому бот з базовим налаштуванням при оновленні подібних файлів буде все одно робити збірку. Щоб уникнути цього необхідно для початку створити об’єкт типу Callable (в простих варіантах функція підійде якнайкраще), який буде повертати істину у випадку, якщо збирання проекту необхідне. Так, для Java проекту, описаного в попередній статті, я використав:

1
2
3
4
5
6
7
8
9

import re
 
def checkIfBuildNeeded(change):
	regexp = re.compile('\.java$|\.idl$|\.jar$|build\.xml$',re.IGNORECASE)
 
	for name in change.files: 
		if regexp.search(name): 
			return True 
	return False

Тепер слід вказати дану функцію як перевірку в налаштуваннях об’єкта Sheduler:

11
12
13
14
15
16

from buildbot.scheduler import Scheduler
 
c['schedulers'] = []
c['schedulers'].append(Scheduler(name="basic",
	fileIsImportant=checkIfBuildNeeded, 
	builderNames=["quick"]))

Пересилання готових збірок

Уявімо, що бот в результаті процесу збирання генерує ще й готові до встановлення бінарні пакети, як, наприклад, .deb, .rpm, чи готує зрізи джерельних кодів, при цьому було б бажаним переслати файли з buildbot-клієнта на buildbot-сервер, де вони б знаходилися в загальнодоступній директорії. Можлива й зворотня ситуація: для перевірки деякого функціоналу необхідні сценарії, згенеровані іншим проектом. Для таких задач можна використати спеціальні кроки збирання FileUpload та FileDownload, що знаходяться в buildbot.steps.transfer. Ось невеличкий приклад використання одного з цих кроків:

from buildbot.steps.shell import ShellCommand
from buildbot.steps.transfer import FileUpload
 
f.addStep(ShellCommand(name="Package", command=["tar", "zxvf", "build.tar.gz", "build"]))
f.addStep(FileUpload(slavesrc="build.tar.gz",
    masterdest="~/public_html/build"+datetime.now().strftime("%Y%m%d-%H%M%S")+"tar.gz"))

Окрім того, що пакет буде надісланий на сервер, він ще й матиме унікальну назву,що вказуватиме на час його створення. Це можливо завдяки тому, що кожен об’єкт-крок виконується інтерпретатором в момент надсилання його клієнту, в даному випадку генеруючи їм’я файлу на сервері.

Залежні збірки

Уявімо, що зібраний на відповідному клієнті пакет повинен бути встановлений на окремій тестовій машині, де буде детально протестований автоматичними засобами. В такому випадку зручно використовувати залежні збірки. Вони дозволять не виконувати тестів у випадку неуспішного збирання пакету. Щоб скористатись даною можливістю, слід в кроки збирання додати об’єкт Trigger, який буде викликати відповідний процес збирання через об’єкт Sheduler.

from buildbot.steps.trigger import Trigger
     f.addStep(Trigger(schedulerNames=['package'],
                       waitForFinish=True,
                       updateSourceStamp=True))

Завдяки кроку Trigger також можна запускати процеси одночасно на кількох машинах.

Корисні посилання

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

Веб-сайт проекту: http://buildbot.net
Документація користувача: /usr/share/buildbot/buildbot.html в кожному Linux дистрибутиві зі встановленим Buildbot’ом.
Документація розробника: http://buildbot.sourceforge.net/API-0.7.5/

На цьому я завершую цикл статей про чудовий інструмент в автоматизації та неперервній інтеграції — Buildbot. Попереду ще багато інструментів, які не менш важливі для втілення ваших мрій у рядках коду. Не перемикайтесь!

Постановка задачі

Проект на Java(використовується система збирання Ant) в репозитарії Subversion знаходиться за адресою https://project.example.com/svn . Необхідно проводити аудит працездатності системи щоразу після внесення змін до нього. Результати збирання системи надсилаються автору змін у випадку успішного результату, або ж у список розсилки всього проекту, якщо процес пройшов невдало.

Вибір між CruiseControl, про який мені розповіли співробітники, та BuildBot, з яким я встиг познайомитись в якості розробника, був досить складний. Проект був вже тоді немаленький(на даний момент весь репозитарій складає 6Гб місця), після тестування його переносила на продуктивні сервери окрема людина. Enterprise, одним словом. І я, довірившись особистому знайомству, вибрав BuildBot. І не прогадав.

Встановлення

Оскільки BuildBot має клієнт-серверну архітектуру, його можна запустити в двох режимах:

• Master: визначає, що, коли, і як робити, реалізує всі системи сповіщення
• Slave: старанно виконує всі вказівки Master-а

Для спрощення комунікації, сервер був встановлений на машині, яка тримала репозитарій. Нехай шлях до репозитарію на сервері — /var/repos/project. DNS-ім’я сервера — example.com. Встановлення BuildBot’а в Debian проходить без жодних проблем:

# aptitude install buildbot 

Після чого BuildBot буде встановлений з усіма необхідними залежностями. Тепер слід створити сервер, який нестиме основне інформаційне навантаження та клієнт, який буде виконувати процес збирання. Для чистоти експерименту, обидва будуть працювати під власними користувачами:

# addgroup buildbot
# adduser --group buildbot buildmaster
# adduser --group buildbot buildslave

Тепер власне створення сервера:

# su - buildmaster
$ mkdir project
$ buildbot create-master project

Налаштування сервера

Після цього в директорії myproject створиться базовий набір файлів, а також деякі допоміжні сценарії для запуску сервера. Сам же конфігураційний файл зветься master.cfg. Хоча можна поправити та перейменувати вже створений master.cfg.sample, я залишу його для тренувань, натомість створимо власну конфігурацію:

1
2
3
4
5
6
7
8
9

# -*- python -*-
# ex: set syntax=python:
 
c = BuildmasterConfig = {}
 
# PROJECT IDENTITY
c['projectName'] = "Test project"
c['projectURL'] = "http://project.example.com/"
c['buildbotURL'] = "http://buildbot.example.com/"

Тепер визначимо, скільки клієнтів в нас є, і скільки збірок вони можуть виконувати одночасно. Для сервера, на який покладено багато задач, не раджу ставити більше одного. Тим більше, що всі дії кладуться в чергу, а тому нічого не буде упущене.

10
11
12
13
14
15
16

# BUILDSLAVES
 
from buildbot.buildslave import BuildSlave
 
c['slaves'] = []
c['slaves'].append(BuildSlave("local-bot", "local-password",max_builds=1))
c['slavePortnum'] = 9989

Коли загальні відомості щодо проекту ми вказали, розберемося з тим, як бот дізнається про те, що в репозитарії було щось змінено. Сервер очікує встановлення зв’язку на вказаний нами порт. До цього порту можуть підключатись як клієнти, що виконують власне збирання системи(в даному варіанті маємо одного бота, який працює локально), так і спеціальні програми, що вказують на зміни в проекті. Для реалізації даної моделі додамо наступні рядки в налаштування:

17
18
19
20
21
22

# CHANGESOURCES
 
from buildbot.changes.pb import PBChangeSource
 
c['change_source'] = []
c['change_source'].append( PBChangeSource() )

Не завжди існує можливість отримати повідомлення про оновлення репозитарію. В таких випадках замість того, щоб очікувати підключення за вказаним портом можна власноруч періодично опитувати SVN репозитарій на наявність оновлень. Це можна зробити за допомогою об’єкту SVNPoller. Якщо ж ви отримуєте інформацію про оновлення репозитарію поштою, то Bildbot можна натравити на поштову скриньку (можливе використання як формату mbox, так і mdir), і таким чином сповіщувати систему.

Нарешті, визначаємо те, як буде проходити сам процес збирання проекту. Для цього запишемо:

23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

localsvnroot  = 'file:///var/repos/project/'
 
# BUILDERS
 
from buildbot.process import factory
from buildbot.steps.source import SVN
from buildbot.steps.shell import Compile
 
localFastSourceUpdate = SVN(svnurl=localsvnroot,mode="update")
 
antCleanup = Compile(command=["ant","cleanup"], name="Cleanup")
antCompile = Compile(command=["ant"])
 
quickBuildFactory = factory.BuildFactory([localFastSourceUpdate, antCleanup, antCompile])
 
quickBuild = {
	'name': "quick",
	'slavename': "local-bot",
	'builddir': "quick",
	'factory': quickBuildFactory }
 
c['builders'] = [quickBuild]

Вище вказаний код вимагає деяких пояснень. Очевидно, процес збирання програми руками, виглядає як

$ svn up
$ ant cleanup
$ ant

Рядки 40-50 визначають кроки, які необхідно виконати для збирання програми. Далі ці кроки збираються в єдиний об’єкт, який надалі буде управляти процесом збирання. В останніх рядках виконується прив’язка до конкретного імені та списку клієнтів, на яких необхідно проводити збирання. Останнім рядком додаємо наш об’єкт до налаштувань.

Наступним кроком буде прив’язка процесу збирання проекту до події оновлення репозитарію. Для цього використовується об’єкт Sheduler. Його різновидів достатньо для більшості задач: збирати за повідомленням ззовні, періодичне виконання, виконання за розкладом тощо.

45
46
47
48
49
50
51
52

# SCHEDULERS
 
from buildbot.scheduler import Scheduler
 
c['schedulers'] = []
c['schedulers'].append(Scheduler(name="dirty and quick",
	treeStableTimer=10*60,
	builderNames=["quick"]))

Параметр treeStableTimer визначає час в секундах(в даному випадку 10 хвилин), протягом якого в репозитарій не повинні бути внесені зміни для початку процесу збирання. У разі швидко виявленої помилки та своєчасних внесень змін до репозитарію, процес збирання буде виконаний лиш один раз. Це дозволить розробнику не привертати до себе зайвої уваги проблемами з процесом збирання проекту.

Наостанок, визначимо служби сповіщення. Для поставленої задачі достатньо налаштувати пошту, однак web-інтерфейс ніколи зайвим не був.

54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

# STATUS TARGETS
 
from buildbot.status import html
from buildbot.status import html, mail
 
c['status'] = []
c['status'].append(html.WebStatus(http_port=80))
 
# Send notification on build to committer
c['status'].append(mail.MailNotifier(fromaddr="buildbot@example.com",
	relayhost="localhost",
	lookup="example.com",
	mode="all",
	addLogs=True,
	builders=["quick"],
	sendToInterestedUsers=True))
 
# Send notification to the mailing list if fails
c['status'].append(mail.MailNotifier(fromaddr="buildbot@example.com",
	relayhost="localhost",
	mode="failing",
	builders=["quick"],
	extraRecipients=["robots@example.com"],
	sendToInterestedUsers=False))

Ну ось, налаштування для сервера готові. Кілька ремарок щодо web-інтерфейсу. Хоча ми і вказували URL бота і головну сторінку проекту в перших рядках налаштувань, сервер очікує, що 80й порт не зайнятий на жодному інтерфейсі, інакше процес запуску не відбудеться. В наступній статті я розповім, як здружити бота і Web-сервер на прикладі Apache2. Ну і не забудьте налаштувати MTA, щоб бот міг висилати пошту, або ж вкажіть інший SMTP сервер.

Налаштування клієнта

Встановлення клієнта для бота не вимагає надмірних зусиль. Для цього в більшості випадків достатньо виконати наступні команди:

# su - buildslave
$ mkdir project
$ buildbot create-slave project localhost:9989 local-bot local-password

Налаштування репозитарію

Оскільки ми очікуємо, що репозитарій має нас сповістити про оновлення, необхідно вказати наступні рядки у файлі
/var/repos/project/hooks/post-commit:

1
2
3

REPOS="$1"
REV="$2"
/usr/share/buildbot/contrib/svn_buildbot.py --repository "$REPOS" --revision "$REV" --bbserver localhost --bbport 9989

Відлагодження та автозапуск

Останнім штрихом буде запуск сервера і клієнта в інтерактивному режимі. Для цього правимо файл /etc/default/buildbot :

1
2
3
4
5
6
7
8
9
10
11
12

# buildbots to manage
# add a new set of variables for each buildbot to start
 
BB_NUMBER[0]=0
BB_NAME[0]="master"
BB_USER[0]="buildmaster"
BB_BASEDIR[0]="/home/buildmaster/project"
 
BB_NUMBER[1]=1
BB_NAME[1]="slave"
BB_USER[1]="buildslave"
BB_BASEDIR[1]="/home/buildslave/project"

Тепер все це щастя можна сміливо запускати:

# /etc/init.d/buildbot start

Для відлагодження бота в процесі роботи необхідно додати в налаштування сервера наступні рядки:

78
79
80

# DEBUG CREDENTIALS
 
c['debugPassword']="debugPassword"

А для початку відлагодження слід виконати

$ buildbot debugclient buildbot.example.com:9989 debugPassword

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

Заключне слово

Ну ось, система працює, однак вона ще далека від ідеалу: часто необхідно збирати один і той же продукт на різних платформах, централізовано викладувати т.з. нічні (Nightly) збірки, до того ж, поточна конфігурація не враховує можливих змін в структурі репозитарію, надлишковості збирань. Але це тема наступної статті.

У колективі, кожен член якого працює над окремою незалежною частиною, стадія інтеграції є заключною. Саме в ній виявляються проблеми сумісності всіх компонентів системи, через це кінцева дата випуску може бути відсунута на невизначений термін. Саме на зменшення часових та трудових витрат на процес інтеграції за рахунок раннього виявлення проблем та усунення помилок та протиріч спрямовані системи неперервної інтеграції.

Серед таких систем найбільш популярними рішеннями з відкритим кодом є CruiseControl та Buildbot. Перший має значно розвиненішу структуру, в той час як другий є легким та простим у налаштуванні. Для початку ж проведемо невеличкий огляд можливостей, переваг та недоліків. Порівняння буде дещо незвичним: воно вестиметься в режимі “перехресного вогню”: кожна зі сторін аргументує власні переваги над конкурентом. Це є найкращий варіант для порівняння досить різних за будовою і реалізацією систем, оскільки в більшості випадків характеристики систем між собою не перетинаються.Після такого собі бліц-опитування ми підведемо підсумки у вигляді списку, для більшої наочності.

На лінії вогню

Остання версія	2.7.3 / 16 Липня 2008
Мова	Java
Сайт	http://cruisecontrol.sourceforge.net/
Ліцензія	Модифікована ліцензія BSD

Остання версія	0.7.8 / 24 Липня 2008
Мова	Python
Сайт	http://buildbot.net/
Ліцензія	GPL

Вже виходячи з мови, на якій написаний CruiseControl, ясно, що система в основному “заточена” для використання в проектах на Java. Це підтверджується і готовими обгортками для таких систем збирання ПЗ, як Ant, Maven, NAnt тощо. Тим не менше, існує можливість роботи з іншими системами через узагальнену обгортку exec. Buildbot же в свою чергу має кілька специфічних для пітонівських проектів можливостей, як наприклад, збирання яйця (Python eggs), генерація документації EPYDoc, проведення базового аналізу коду за допомогою PyFlakes. Окремим пунктом можна зазначити можливість проведення модульних тестів Perl. Зважаючи на переважне використання систем збирання, базованих на make-файлах, а також активне розповсюдження SCons(повноцінна система збирання ПЗ на Python), BuildBot містить готові обгортки для більшості таких систем. Як і у випадку з CruiseControl, можливо запустити на виконання будь-що за допомогою обгортки ShellCommand.

BuildBot побудований на архітектурі клієнт-сервер, що дозволяє проводити тестування на різних машинах з однією центральною інформаційною системою, а також розміщувати машини, на яких проводиться збирання, за NAT.

CruiseControl має розвинену систему сповіщення та чудовий графічний web-інтерфейс. BuildBot же, хоч і має не менш розвинені можливості для сповіщення, значно програє в інтерфейсі.

Інформаційна система CruiseControl побудована на JSP, що дозволяє інтегрувати її в будь-який Java Application Server, як Tomcat або ж інший більш легкий. Звичайно, за гнучкість треба платити, і ціною за використання Java і JSP є значне спочивання ресурсів і в багатьох великих проектах призводить до виділення окремого сервера під потреби CriuseControl. Легкий, простий, та досить примітивний web-інтерфейс у BuildBot дозволяє йому значно знизити навантаження на сервер. Використання Twisted в якості базової бібліотеки ж вимагає виділення окремого порту на всіх мережевих інтерфейсах системи, що є небажаним. Інтеграцію з Apache можливо виконати, використовуючи http_proxy модуль Apache та кілька правил файрвола для закриття портів системи назовні.

В наступній статті циклу я детально опишу реальний приклад використання систем неперервної інтеграції на прикладі BuildBot.

В світі, що рухається неймовірними обертами, не можна даремно витрачати час. Вся рутина повинна бути автоматизована, і крапка. Якщо ви з цим не згодні, перечитайте перший абзац. Людина мусить спрямовувати розум на подолання нових проблем, а не на одноманітну купу операцій. Порахуйте, скільки процесів, які ви щодня виконуєте, можна автоматизувати, і зрозумійте, скільки часу ви витрачаєте марно.

Способи організації проектів, їх документації, юніт-тестів, тестів продуктивності, вражають своєю кількістю. Зазвичай кожен другий виробник більш-менш серйозного IDE, пакету програм для розробки, пропонує свій спосіб збереження файлів всередині проекту, організації процесу збирання, написання чи то генерація документації. Проблема постає у виборі інструментів, які допоможуть підвищити ефективність роботи та знизити часові витрати на її виконання. Сьогодні ми говоримо про системи збирання проектів.

В світі UNIX історично склалось, що більшість програм можна зібрати трьома командами:

$ ./configure
$ make
$ sudo make install

Цьому способу збирання та установки програм ми завдячуємо утиліті make. І хоча вона вже стара, як світ, однак досі популярна завдяки певній інертності розробників в виборі власних інструментів. Утиліта make оброблює т.з. Makefile - файл, що несе всі особливості процесу збирання. Однак вже тоді було зрозуміло, що писати їх вручну для великих проектів - досить марудна справа. І було винайдено autotools. Свого часу вони на порядок спростили визначення залежностей, встановлення додаткових параметрів компіляції, збирання та встановлення версій бібліотекам тощо. Таким чином, autotools на разі є найбільш відомою і популярною системою збирання програм під *NIX системи.

Та час ішов, і autotools стали здаватись дедалі більш заплутаними та складними. Проявились деякі недоліки: незважаючи на зручність в порівнянні зі збиранням вручну, написання навіть простих сценаріїв для генерації Makefile-у вимагали багато зайвої писанини. І ось вже нове покоління систем збирання з’являється на обрії. Одні з них слідують шляхом autotools, генеруючи сценарії для перевіреної часом make(QMake, CMake), інші ж розвиваються в напрямку власних сценаріїв збирання(SCons, Ant, Maven та ін.).

В цей же час проекти під сімейство ОС Windows зазвичай закріплені за проектами тих середовищ розробки, в яких вони були створені. При цьому неможливо зібрати проект не маючи відповідного середовища. З іншого боку, використання специфічних для кожного середовища файлів проектів покращує інтеграцію та інтерактивність при розробці. Ефективним способом виходу з цієї ситуації є взаємна інтеграція систем збирання та систем розробки. Так, на разі де факто стандартами для розробки Java проектів є використання Ant та Maven, управління якими інтегроване в більшість популярних середовищ розробки Java програм. Іншим способом вирішення проблеми є генерація файлів проектів для популярних середовищ розробки, що базуються на сценаріях збирання програм. Так, CMake дозволяє генерувати файли проектів для KDevelop, MS Visual Studio, звичайні Makefile, що дозволяє отримати готове до роботи середовище з найменшими витратами часу.

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

Тим не менше, не одними програмами живуть системи збирання. SCons знайшла собі застосування в генерації PostScript та PDF з LaTeX-документів, що свідчить про неабияку гнучкість. Воно й зрозуміло, адже SCons фактично використовує Python-подібні сценарії для налаштування процесу збирання.

Таким чином, важливими вимогами до систем збирання є:

• простота в налаштуванні як простих, так і складних проектів
• висока гнучкість у налаштуванні при можливості використовувати параметри за замовчуванням
• інтеграція з популярними середовищами розробки
• кросплатформенність

В результаті вони

• надають можливість незалежного налаштування середовища розробки при незмінному принципі збирання
• дозволяють збирати програми та відслідковувати залежності незважаючи на відсутність IDE
• спрощують процес збирання проекту в цілому та окремих його частин
• зменшують часові затрати на перевірку та збирання проекту
• сприяють автоматизації процесу розробки

Ви ще не знаєте, навіщо системи збирання проектів? Тоді ми йдемо до вас!

Однак, перед тим, як продовжити, слід усвідомити наступне:

Цей приклад описаний виключно в навчальних цілях! Використовуйте його лиш у випадках крайньої необхідності!

Якщо Ви хочете поширювати власну програму для Linux — використовуйте стандартні способи поширення програмного забезпечення у відповідних дистрибутивах. Користувачі будуть Вам дуже вдячні.

Інсталятор зсередини

Важливо зрозуміти, яким чином працює більшість інсталяторів. Типова програма для встановлення певного програмного забезпечення складається з основних двох частин: архіву з файлами цього програмного забезпечення та сценаріїв установки та видалення. Відповідно, і процес установки теж складається з двох етапів — встановлення відповідних файлів та налаштування робочого середовища. Процес видалення програмного забезпечення виконується в зворотньому порядку. Для реалізації цих підходів необхідно розробити певну структуру каталогів, наприклад, як на малюнку:

Структура директорій пакету

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

Після того, як програма-інсталятор розпакувала свій вміст в задану директорію, вона запускає ініціалізаційний сценарій, який в нашому випадку зватиметься package/install.sh (тут і надалі всі імена файлів вказуватимуться відповідно до кореневої директорії встановленого проекту). В ході роботи встановлена нами програма може змінювати змінні середовища, створювати додаткові файли тощо. Всіма цими клопотами має займатись сценарій видалення package/uninstall.sh. А для того, щоб він знав, які файли були встановлені, на етапі установки буде створений список файлів package/list. Ось такий собі невеличкий огляд циклу життя програми: від установки і до видалення.

Перевівши погляд на інсталятори, які складаються з всього лиш одного сценарію командної оболонки, завжди дивуєшся, як можна покласти архів, який по суті є бінарним форматом, всередину текстового, яким є наш інсталятор. Все виявилося досить простим: достатньо використати base64- або UU-перетворення, і ось, наш архів записаний самими лише цифро-буквеними символами, або ж з доданням спеціальних символів. Не можна забувати і про зворотній бік цього перетворення - збільшення розміру файлу, так що пошук оптимального варіанту перетворення ще не закритий.

Від теорії до практики

Тепер, коли цілі і методи нам відомі, пора б зайнятись власне інсталятором. Перекодуванням файлів в base64, як і в UU-code, займається утиліта uuencode. ЇЇ аналог для зворотнього перетворення — uudecode. Отже, для того, щоб отримати перекодований варіант архіву, створеного з поточної директорії, достатньо виконати команду:

 $ tar -c . | bzip2 -z | uuencode - > decoded_archive

Тепер, коли ми знаємо, як записати архів всередині текстового файлу, достатньо обрамити його відповідними керуючими структурами, щоб отримати готовий інсталятор. Слід зауважити одну цікаву технічну особливість. Як відомо, в тій самій перекодованій формі base64 або UU-code пересилаються поштою файли в двійковому форматі. Коли декодер uudecode читає файл, він відкидає все, що не стосується закодованих даних. Отже, ми просто згодуємо весь наш інсталятор декодеру, уникнувши при цьому попереднє повне завантаження архіву в оперативну пам’ять. Але генерувати подібні сценарії “вручну” — справа не з приємних. Тому в якості подарунку тут буде запропонований варіант генератора подібних інсталяторів. Він здатен:

1. Працювати в інтерактивному режимі
2. Генерувати типові інсталяційні та деінсталяційні скрипти, або використовувати вже готові, якщо такі існують.

Отже, почнемо його розбір. Як і кожен сценарій, наш починається з визначення інтерпретатора, або так званого “sha-bang” рядка та невеличкої документації щодо використання самого скрипта:

1
2
3
4
5
6
7
8
9
10
11
12
13

#!/bin/bash
#
# package.sh - tool for creating self-extracting and self-installing packages.
#
# SYNOPSIS
#
# package.sh DIR [NAME]
#       creates a package from directory DIR with name NAME
# 
# package.sh uses tar, uuencode and gzip to generate a package. It generates 
# installing and uninstalling scripts in DIR/package directory to provide
# additional flexibility for users. These files (install.sh and uninstall.sh)
# are not generated if exist.

Для зручності кожна окрема дія буде виділена в функцію. Оскільки всі службові сценарії лежатимуть в наперед відомій директорії package, то з них і почнемо:

14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

generate_install_script() {
cat < < EOF
#!/bin/bash
# This is a simple installer script generated by package.sh - simple self-extracting
# and self-installing package creator
 
if [ ! -d "\$PWD/package" ]; then
        echo "This script must be run from the directory where package is installed"
        exit 1
fi
 
# TODO: Write your installation operations here.
 
EOF
}

Сценарій видалення є дещо цікавішим. Оскільки список встановлених файлів знаходиться в package/list, то необхідно пройти весь список, вилучаючи вказані файли з системи. Щоб мати можливість вилучити не лише файли, а й директорії, при цьому залишаючи ті, які містять файли, що не входять до пакету, слід пройти цей список знизу вверх, використовуючи команду rmdir для директорій.

29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

generate_uninstall_script() {
cat < < EOF
#!/bin/bash
# This is a simple uninstaller script generated by package.sh - simple self-extracting
# and self-installing package creator
 
if [ ! -d "\$PWD/package" ]; then
        echo "This script must be run from the directory where package is installed"
        exit 1
fi
 
tac package/list | while read FILE
        do
        if [ -d "\$FILE" ] ; then
                rmdir \$FILE 2>/dev/null
        else
                rm \$FILE
        fi
        done
 
rmdir package
 
exit 0;
EOF
}

Тепер черга за основним скриптом інсталятора. Саме на нього покладається основна задача видобування файлів з архіву, генерації списку файлів та первинної ініціалізації нашого пакету, через це його будова містить додаткові перевірки вхідних аргументів, виведення помилок в роботі до stderr тощо. окрім того, в разі відсутності будь-яких вхідних аргументів сценарій дозволяє в інтерактивному режимі вказати цільову директорію. Нижче наведений код для тіла інсталятора:

54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108

package_installer() {
cat < < EOF
#!/bin/bash
#
# Package installation script. 
if [ -n "\$1" ]
then 
        if [ -d "\$1" ]
        then
                TARGETDIR="\$1"
        else
                echo "Directory does not exist" > /dev/stderr
                exit 1;
        fi
else
        echo -n "Please, specify target directory[default is \$PWD]: "
        read TARGETDIR
 
        if [ -n "." ]
        then 
                TARGETDIR="."
        else
                while [ ! -d "\$TARGETDR" ]
                do
                        echo "Directory does not exist." > /dev/stderr
                        echo -n "Please, specify target directory"
                        read TARGETDIR 
                done
        fi
fi
 
FILELIST=\`mktemp\`
echo -n "Extracting archive contents. This may take a while.."
cat \$0 | uudecode | bzip2 -dc | tar -xvkC \$TARGETDIR > \$FILELIST
 
echo "\$TARGETDIR/package/list" > \$TARGETDIR/package/list 
cat \$FILELIST >> \$TARGETDIR/package/list
rm \$FILELIST
 
echo -ne "Done.\\nRunning installation script.."
cd \$TARGETDIR
package/install.sh
 
echo -ne "Done.\nDo you want to remove the installer?(y/N) "
read ANSWER
 
if [ "\$ANSWER" == "y" ]; then 
        rm \$0;
fi
 
echo "Done. Enjoy!"
exit 0;
 
EOF
}

Ну ось, базові три частини, необхідні для інсталяційного пакета, готові. Тепер черга за генератором. Він в свою чергу повинен створити інсталяційні та деінсталяційні скрипти, якщо необхідно, заархівувати цільову директорію разом зі службовими скриптами і об’єднати код інсталятора з закодованим тілом архіву. При цьому слід передбачити необхідні дії у випадку виключних ситуацій, як, наприклад створення файлу пакету з вже існуючим іменем. В результаті тіло генератора матиме вигляд:

109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201

# Generator main part begins here
DIR=$PWD
 
if [ -n "$1" ]
then 
        if [ -d "$1" ]
        then
                TARGETDIR="$1"
        else
                echo "Directory does not exist" > /dev/stderr
                exit 1;
        fi
else
        echo -n "Please, specify target directory[default is $PWD]: "
        read TARGETDIR
 
        if [ ! -n "$TARGETDIR" ]
        then 
                TARGETDIR="."
        else
                while [ ! -d "$TARGETDR" ]
                do
                        echo "Directory does not exist." > /dev/stderr
                        echo -n "Please, specify target directory"
                        read TARGETDIR 
                done
        fi
fi
 
# Creating scripts directory if not exist
if [ ! -d "$TARGETDIR/package" ]; then
        mkdir $TARGETDIR/package
fi
 
 
# Generating installation script if not specified by user.
INSTALLSCRIPT="$TARGETDIR/package/install.sh"
if [ ! -f "$TARGETDIR/package/install.sh" ]; then
        echo -n "Generating installer script.."
        generate_install_script > $INSTALLSCRIPT
        chmod a+x $INSTALLSCRIPT
        echo "Done."
fi
 
 
# Generating uninstallation script if not specified by user.
UNINSTALLSCRIPT="$TARGETDIR/package/uninstall.sh"
if [ ! -f "$UNINSTALLSCRIPT" ]; then
        echo -n "Generating uninstaller script.."
        generate_uninstall_script > $UNINSTALLSCRIPT
        chmod a+x $UNINSTALLSCRIPT
        echo "Done."
fi
 
echo -n "Compressing data. This may take a while.."
DATA=`mktemp`
cd $TARGETDIR
tar -cf -  . | bzip2 -9z | uuencode - > $DATA
cd $DIR
 
#Generating the final package and naming it as user desires.
echo -ne "Done.\nGenerating package.."
PACKAGE=`mktemp -p . package.sh.XXXXXXX`
package_installer > $PACKAGE
cat $DATA >> $PACKAGE
 
echo -ne "Done.\nRemoving temporary files.."
rm $DATA
 
PACKAGENAME=""
# Setting up the package name
if [ -n "$2" ]; then
        PACKAGENAME=$2
else
        PACKAGENAME="`basename $TARGETDIR`.sh"
fi
 
# If the same file is aready exist - ask user
if [ -f "$PACKAGENAME" ]; then
        echo -ne "\nFile $PACKAGENAME already exists. Overwrite?(y/N) "
        read ANSWER
        if [ "$ANSWER" != "y" ]; then
                exit 1;
        fi
else
        mv "$PACKAGE" "$PACKAGENAME"
        PACKAGE=$PACKAGENAME
fi
 
chmod a+x $PACKAGE
 
echo -e "Done.\nEnjoy!"
exit 0;

Ось генератор і готовий. І хоча він досить примітивний, однак на живому прикладі дозволяє побачити деякі з можливостей всім відомого командного інтерпретатора. Наостанок лиш хочу всіх поздоровити з минулими святами, і нехай цей рік принесе радість пізнання невідомого та успіх!

Ось, наприклад, як виглядає тема “Пляж” в той же час для Бостнону та Києва.

Тема GMail Beach для Бостону

Тема GMail Beach для Києва

В темі “Дерево”, наприклад, для Бостону йшов проливний дощ.

Що ж буде наступним?

Обираємо систему управління проектами

За інформацією для роздумів гугл нас привів на сторінку з вікіпедії. Як бачимо, вибір у нас досить великий. Вибрати з них що-небудь по собі з виконанням більшості критеріїв досить нескладно. Однак підтримку Git має в своїй реалізації лиш один проект — Trac, про який і йтиме мова далі.

Чому Trac

Як вже було сказано, лише в нього я знайшов підтримку Git репозиторіїв. До того ж Trac має неабияку гнучкість: окрім базового набору, якого зазвичай не вистачає, купа функціоналу реалізована у вигляді плагінів, яких тут можна знайти на будь-який смак. Простий та зрозумілий з першого погляду інтерфейс, відсутність зайвих “свистілок” не може не порадувати людей, які від продукту очікують ефективну реалізацію функціоналу. Можливість адаптувати середовище на власний смак та за потребами проекту, будь то розробка програмного забезпечення, адміністрування, чи організація господарських робіт у себе на городі. Хоча незважаючи на можливість вести будь-які проекти в цій системі, все ж вона тісно інтегрована з ситемами контролю версій(Svn, Bazaar, Mercurial, Git), підсвіткою синтаксису “на льоту”(використовуються SilverLight, Enscript, а з версії 0.11 — ще й Pygments), розробкою документації (Doxygen, PyDoc, PerlDoc), і навіть системою управління тестами. Підтримка RSS-стрічок, wiki(до якої є теж купа розширень), і навіть ведення блогу додають практично всі необхідні інструменти для ведення сучасного проекту. Довершує все це добро документація по Trac, яка є в кожному новоствореному проекті на стоірнках wiki.

Установка та адміністрування

Ставити ми його будемо, звичайно ж, на Debian GNU/Linux, для якого поточною стабільною віткою вважається 0.10. Сподіваюсь, ви вже маєте налаштований Git репозиторій, інакше раджу взяти низький старт з цієї сторінки. Виконавши aptitude install apache2 libapache2-mod-python trac-core trac-git pcycopg2 та встановивши залежності й додаткові пакети за бажанням переходимо власне до конфігурації.

Першим кроком буде створення нового проекту. Де тримати проекти — справа кожного, хоча мені більше імпонує покласти їх до /var/trac/. Для промислового розгортання буде доцільним розгортати подібні середовища в домашніх директоріях користувачів. Отже, почнемо.

# mkdir /var/trac
# cd /var/trac
# trac-admin myproject initenv

В процесі установки система необхідно ввести деякі базові настройки, вибрати БД, з якою працюватимете, та вказати шлях до репозиторію. Якщо в якості репозиторію ви вказали Git, то система в кінці видасть попередження про відсутність його підтримки, однак все це можна сміливо ігнорувати, бо все це ми виправимо в подальших кроках.

Саме з цього моменту починають проявлятись особливості роботи з Trac: адміністрування проекту проводиться за допомогою консольної утиліти trac-admin. Отже, якщо ви не маєте доступу через SSH до свого сервера, годі й мріяти про установку цієї системи. І хоча деякі операції можливо перекласти на веб-морду, однак початкову ініціалізацію — зась. Якщо ж ви все ще з нами і вже готові до наступного кроку, то не гаймо часу.

Всі налаштування проекта знаходяться в одному файлі conf/trac.ini в директорії проекту. Зараз можна підправити загальні параметри проекту, однак я раджу відкласти цей крок на момент після тестового запуску проекту. Справа в тому, що будь-який згенерований проект з самого початку містить wiki-документацію, яка доступною мовою опише можливості та особливості налаштування системи. Знову повертаючись до Git, на сторінці GitPlugin ви зможете прочитати вичерпні пояснення щодо того, яким чином організувати співпрацю Trac та Git.

Для успішного старту проекту необхідно отримати можливість запускати Python-івські скрипти на запит веб-сервера. Це можна реалізувати через механізм CGI, FastCGI, або ж використовуючи mod_python, що ми, власне, і зробимо:

<Location/projects>
  SetHandler mod_python
  PythonInterpreter main_interpreter
  PythonHandler trac.web.modpython_frontend
  PythonOption TracEnvParentDir /var/trac
  PythonOption TracUriRoot /projects
</Location>

Вище представлений шматок конфігураційного файлу веб-сервера, який дозволить вести нам безліч проектів, що лежатимуть в /var/trac Наступні рядки ж дозволять мати один обліковий запис для всіх проектів. Даний тип автентифікації приведений лише для прикладу. Автентифікація користувачів через систему LDAP буде описана в наступних статтях.

<LocationMatch"/projects/[^/]+/login">
  AuthType Basic
  AuthName "Trac"
  AuthUserFile /var/trac/.htpasswd
  Require valid-user
</LocationMatch>

Якщо всі кроки виконані успішно, ви мусите побачити вже працюючий проект за адресою:http://localhost/projects/myproject/

Додаткові плагіни

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

GraphvizPlugin

Трохи помучитись змусив мене плагін, що реалізовує inline-вставку графічного представлення інформації за допомогою graphviz. Для тих, хто все ще не може отримати зображення, підкажу основні вимоги:

• директорія, в якій знаходиться кеш graphviz повинна бути доступна для запису користувачем www-data, під яким запущено веб-сервер. Крім того, якщо ви використовуєте tmpfs, то не робіть директорію для кешу в /tmp, оскільки для роботи graphviz необхідне існування директорії, а при наступному ж перезавантаженні вона просто зникне.
• необхідні пакети: graphviz та librsvg2-bin

WebAdmin

Для того, щоб не мати клопоту при роботі з цим плагіном, необхідно, щоб файли проекту в /var/trac/myproject були доступними користувачеві www-data для запису. Загалом же, плагін встановлюється та підключається без зайвих зусиль.

Trac та PostgreSQL 8.3

Якщо ви використовуєте Trac 0.10 зі стандартних пакетів Debian, то матимете клопіт з неможливістю перегляду звітів про помилки (tickets). При цьому ще й при додаванні такого звіту система може видавати помилки. Для того, щоб усунути цю помилку, необхідно змінити у файлі /usr/share/python-support/trac/trac/ticket/model.py рядок 296 з:

"ORDER BY time", (self.id, str(self.id), self.id))

на

"ORDER BY time", (self.id, str(self.id), str(self.id)))

Сподіваюсь, що за кілька днів після випуску даної статті ця порада стане непотрібною

Висновки

Закінчуючи статтю, хочеться підбити підсумки щодо системи в цілому. Особисто я вже використовую Trac для власних проектів, тому що ця система:

• проста, зручна, та ефективна
• має підтримку сучасних репозитаріїв, баз данних та прикладного програмного забезпечення
• дуже гнучка
• знаходиться в активній розробці

Хочете переконатися в цьому самостійно? Тоді ласкаво просимо до http://www.hosted-projects.com/trac/TracDemo/Demo , де ви зможете попрацювати з Trac без зайвого клопоту.

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

Реєстрація

Запускаємо мобільний сайт

Прикрашання та контент

Інтеграція та просування

Післямова

Для більшості користувачів віконний менеджер починається і закінчується кількістю кнопочок в заголовку вікна. Ну, максимум - з системного меню вікна. Далеко не кожен з нас задавався питанням: а що ж таке цей менеджер вікон? Судячи з назви, він має керувати та організовувати зручну роботу в середовищі користувача. В типових віконних менеджерах маємо купу вікон, в багатьох випадках вікна перекривають одне одного, і бувають ситуації, коли знайти необхідне вікно виявляється дуже складно. Через це еволюція віконних менеджерів породила віртуальні робочі столи. Так, це рішення ефктивне і зручне, але носить лиш суто екстенсивний хараткер. Так довго продовжуватись не могло.

Мозаїчні віконні менеджери підійшли до розв’язку задачі з іншого боку - змусити вікна не перетинати одне одного. Основний їх підхід - максимально збільшити ефективність використання простору робочого столу за рахунок поділу його на окремі частини “мозаїкою”. При цьому жоден піксель екрану не пропадає даремно, і всі вікна займають максимально можливий простір.

Для бажаючих лишитись зі своїм старим добрим робочим середовищем, будь то KDE, GNOME чи XFCE, і спробувати це диво софтобудівництва не змінюючи кардинально власних вподобань, існують відповідні матеріали .

Базові можливості xmonad можна почерпнути з відповідної сторінки manpage: man xmonad. Головне, чого я не знайшов там була відповідь на запитання: “А що ж то за клавіша така: mod?”, — на що вам зразу й дам відповідь: за замовчуванням модифікатором (все тим же mod-key) є клавіша Alt. До речі, всі операції можна виконувати за допомогою клавіатури, що значно підвищує швидкість роботи з вікнами, хоча миша також може маніпулювати розміщенням вікон.

Оскільки xmonad фактично не є десктоп середовищем, для підвищення ефективності роботи з ним додатково використовують окремі панелі dzen та xmodbar і динамічне X11 меню dmenu (яке, на жаль, не підтримує UTF-8, зате з задачами запуску чого-попало справляється на ура).

Якщо я ще не переконав читача спробувати xmonad, то цей невеличкий ролик неабияк може цьому посприяти:

Соціальні закладки

Соціальні новини

Централізація і деблогізація коментарів

Плюси

1. Розгалужені (threaded) коментарі — можливість відповідати на чийсь коментар, не тільки на основний пост
2. Відео-коментарі(!) — можливість залишати у відповідь своє відео, яке можна записати прямо тут же по місцю (вам знадобиться seesmic-акаунт)
3. Єдині профілі — наскрізна ідентифікація, де б ви що не постили (з можливістю заявити права (claim) на свої старі коментарі, які ви постили, ще не зареєструвавшись на disqus!)
4. Система рейтингів коментарів і юзерів (і можливість відповідно відсортувати гілку) — безглузді коментарі швидко опиняються “внизу”
5. Можливість навівши мишу на аватар коментатора побачити його останні коментарі (і не тільки на вашому блозі — по всьому вебу(!) (і можливість підписатися на ці його коментарі ))
6. Форум на сервері disqus, що дублює усю дискусію — коментарі можна лишати і там і тут, вони будуть відображені скрізь
7. Інтеграцію у френдфід: де б ви що не коментували — усе буде проходити у вашому потоці
8. Підтримка OpenID, граватарів (увага! тільки при реєстрації з сайту — по місцю коментування поки що не працює! (треба спочатку піти на сайт)) і трекбеків…

Контроверсійні моменти

1. замінити вордпресівські коментарі на всіх постах — обережно! старі коментарі не будуть більше відображатися!
2. замінити усі пости без коментарів (включно з майбутніми) — я зробив би саме так
3. замінити коментарі тільки на постах, закритих для коментування — (нафіга?)

This version is out of date. We recommend using 1.04 until a new version of the API plugin is released

Yes. Set the following JavaScript parameter. var disqus_container_id = “your-custom-id”;

Раніше я вже писав про подібний функціонал в мобільній версії GoogleMaps. Правда, з картою Києва там поки що напряг - тільки супутникові знімки та карта основних автошляхів України.

Оновив недавно на смарті  Яндекс.Карту, а вона після завантаження першим ділом показала моє місцезнаходження. Загалом тестував в мережах Київстару, МТС та Білайну - працює коректно, точність визначення місцезнаходження в Києві - залежно від місця та мережі 100-5000 метрів. В Білайновській мережі в деяких місцях показує точніше, ніж гугловська (там, мабуть, база “зсунута” на одну вишку використовується - показує сусідню соту).

Фукцією Пробки 2.0 активно не користувався, але в цілому ідея сподобалась - при наявності модуля GPS та ввімкненому режимі “Сообщать о пробках” (параноїки, увага! режим за замовчанням ввімкнений :)) дані про місцезнаходження та швидкість пересування автоматично передається на сервер Яндексу, де інформація від багатьох “волонтерів” збирається та наноситься на карту. Можна також вручну ввести дані про пробку.

З українських доступні карти Києва, Дніпропетровська, Донецька, Запоріжжя, Львову, Одесси, Харкова та Криму.

Щоб і собі отримати таке чудо на телефон, перейдіть з мобільного за адресою m.ya.ru/ymm або по бар-коду справа. Модель телефону в більшості випадків визначається автоматично.

Коли новенький ZSH стартував як мій дефолтний шелл, я ще дуже довго не міг зрозуміти, чим же він настільки хороший. Це якраз той варіант, коли баш виглядав краще, оскільки був дефолтним і мав вже деякі настройки хоча б того ж запиту на ввід ($PROMPT, $PS[1-4]), а тут споглядання картини

localhost%

ніяк не радувало. Так моє перше знайомство і закінчилося б, якби мені не було ліньки поставити баш назад (думка “дай ще потестю, мож ще що цікаве вилізе” промайнула у мене в мізках і вирішила хід подій). З часом я звик до цього шелла, його невеликих особливостей, і нарешті почав бачити різницю в швидкості роботи (порівнюючи роботу bash і zsh на різних користувачах).

А поки час ішов, я ще не раз бачив деякі “розфарбовані” екземпляри все того ж ZSH, і мені кортіло нарешті й собі таку цяцьку. І ось нарешті моя мрія здійснилась, і я з вами всім цим щастям поділюсь .

А почнемо ми знову ж з запиту на ввід. Купа мануалів та записів в блогах пропонує його в наступному вигляді:

[user@hostname:directory]#

На додачу до цього, ми ще й годинник прикрутимо справа;) Відкриваємо ~/.zshrc і вписуємо наступне:


export PROMPT='[%n@%m:%1~]%# ‘
export RPROMPT=’[%*]‘
alias ls=’ls –color’
alias grep=’grep –color’


Тут перший рядок відповідає за відображення запиту на ввід(в даному випадку дуже схожий на типовий в RedHat Linux), другий - за годинник, все інше знайомо до болю ще з часів bash-а. Ну а тепер можна цей самий запит і розфарбувати. Після додавання інформації про колір, частина нашого .zshrc виглядає наступним чином:


alias ls='ls --color'
alias grep='grep --color'
autoload colors
colors
PROMPT="[%{${fg[green]}%}%n%{${reset_color}%}@%{${fg[blue]}%}%m%{${reset_color}%}:%{${fg[red]}%}%1~%{${reset_color}%}]%# ”
RPROMPT=”[%{${fg[cyan]}%}%*%{${reset_color}%}]”
fpath=(~/myfns $fpath)
autoload -U promptinit
promptinit


Думаю, і так все зрозуміло написано навіть без коментарів. Результат наших з вами налаштувань виглядатиме десь так:

prompt elite

І на додачу вам кілька посилань на ресурси, присвячені цьому шеллу:
http://wiki.archlinux.org/index.php/Zsh
http://rayninfo.co.uk/tips/zshtips.html

P.S. До речі, зверніть увагу на рядок з фільрацією по User-Agent. Його не варто видаляти - пересвідчився на власному досвіді - я першим ділом його “прооптимізував”. Але без нього Feedburner при опитванні фіду з вашого сайту редіректиться сам на себе, а не читає оригінал і виходить, звісно, дурня.

Відео хостинг

Почну, мабуть, з найбільш затребуваного та відомого широкому загалу користувачів типу контенту - відео.

YouTube. Складно знайти інтернетичика, який не знає що таке “Ютюб”. Впевнений, для багатьох він навіть став певним синонімом відео в інтернеті. На “Ютюбі” можна викладати відео у форматах .WMV, .AVI, .MOV та .MPG. Після завантаження воно автоматично коніертуєтсья сервером у формат FLV (FLash Video). Плюсом цього формату є те, що для програвання вам потрібен лише встановлений флеш-плеєр, а також те, що сконвертоване у FLV відео має невеликий розмір (зручно для людей з необмеженим, але вузьким каналом, а також для тих, хто досі платить за трафік). Хостинг також накладає обмеження на розмір завантажуваних файлів: об’єм не більше за 1 ГБ, довжина не більше 10 хвилин. З мінусів можна назвати вельми посередню якість результуючих відеофайлів (хоча останнім часом Google, який є власником YouTube, ввів у користування нову фічу, яка дозволяє переглядати відео в кращій якості, якщо така наявна). Успіх Ютюбу надихнув багатьох людей на створення його клонів. Типовим прикладлм є, наприклад, російскьий RuTube. Крім того, YouTube нещодавно став не просто хостингом, а цілою відеохостинговою платформою, тобто ви можете створбвати свої власні аналогічні сайти використовуючи потужність YouTube.

megavideo.com. Найбільший прямий конкурент “труби”, але в той же час, на жаль, не дуже популярний. Чим саме він кращий можна дізнатись з цього відео, а для тих, кому ліньки дивитись, чи не знає англійського я зупинюсь на найцікавших моментах: більш якісне відео, відсутність обмеження на довжину ролику (хоча є оббмеження на розмір: 500 MB для безкоштовного та 5 GB для платного рахунку), доступність до завантаження оригіналу відео (лише для платних аккаунтів ), локалізація інтерфесу багатьма мовами та можливість докачки при аплоаді відео (за допомогою спеціального софту).
З очевидних мінусів - менша поширеність (менше шансів знайти щсоь цікаве) та досить нав’язлива реклама: справа в тому, що вона поміщається прямо у вікно програвача і в ньому ж по центру знаходиться кнопка “Play”. Так от якщо нажати на цій кнопці у вікні відео, то відкривається реклама. Тому потрібно користуватись лише кнопкою “Play” в лівому нижньому кутку панелі програвача.

veoh.com. Якщо ж навіть якість megavideo вас не влаштовує, то варто звернути погляд на сервіс veoh. Він пропонує потокове відео не лише у форматі FLV, а також у DivX, Quick Time та WMV, але для цього вже одним флеш-плеєром не обійтися і потрібно буде дозавантажувати інші програвачі. Ну і, звісно, трафік воно жере теж непогано, але якщо у вас є можливість дивтись відео звідси, то рекомендую veoh набільше з усього. На відміну від Труби він заточений більше на професійне відео - різноманітного виду шоу: серіали, аніме, телепередачі, тощо… із-за чого його називають навіть службою Інтернет-телебачення. Але, звісно, ніхто не забороняє вам викладати там і любительське відео. Більше того, власникам HDTV-камер взагалі несолідно було б викладати своє відео на чомусь гіршому, аніж veoh.
Ну і нарешті ще один цікавий момент: “Вео” б’є “Ютюб” не лише по якості Відео, але і по сумарному часу, який проводять користувачі на сайті: в березні сумарно було прглянуто 46 мільйноів годин відео, що в два рази більше аналогічного показника у найвідвідуванішого сайту.

video.google.com. Після придбання Гуглом Ютюба цей сайт фактично перетворився більше в пошуковик відео, аніж хостинг (хоча можливість завантажувати файли там досі присутня), але тим не менш я вирішив згадати його тут - пошук в будь-якому випадку може знадобитись, оскільки він шкає по багатьох сайтах, в тому числі і не згаданих тут.

Аудіо хостинг

muxtape.com. Я дізнався про цей сервіс лише нещодавно. Він до чортиків зручний. У нього до непристойного простий дизайн: ваша сторінка представляє собою просто список пісень (наприклад, моя), клацнувши на котру можна прослухати її, а основна сторіка має три основних посилання: завантажити пісню, редагувати списиок пісень (по дефолту воно береться з тегів, але його можна виправити) та налаштування. Але найголовніше - слухати можна без реєстрації. З мінусів - кількість завантажуваних композицій обмежена 12-ма і крім того завантажувати можна лише mp3 розміром не більше 10 MB.

imeem.com. Занести цей сайт до списку музичних хостингів було з мого боку дещо неправильно, але вперше я познайомився з ним саме в музичному сенсі, коли качав один трек, який ніде не міг знайти. По-перше, цей сервіс все ж варто було згадати, коли я писав про соціальні мережі, але тоді я про нього ще не знав. По-друге, це не лише аудіо, а і відео- та фотохостинг. Найвизначніша його риса - це у ньому все крутиться навколо плейлистів. Тобто не окремих файлів, а їх наборів. Це може бути і альбом якогось гурту, і просто список улюблених пісень (це якщо говорити про його аудіоскладову, але плейлисти можна скаладати і до інших видів контенту, що підтримуютсья сервісом). Основний мінус - це те, що незареєстрованим користувачам для прослуховування доступні лише 30-секундні семпли, для того, щоб прослухати поністю - треба вже реєструватись. Щоправда для деякиз речей, зазвичай концертних записів, повна версія доступна без реєстрації. Обмеження на завантаження не дивився.

Фотохостинг

flickr.com. Мова про Флікр як соцмережу вже йшла в одному з моїх попрередніх дописів, але не згадати ще раз цей сервіс (один з моїх найулюбленіших) я не можу. До речі, нещодавно Флікр до всього того став ще й хостером відео.

Щодо інших, то, на жаль, тут я поки лише їх перерахувати найвідоміші з невеличкими коментарями, оскільки перевірити всі в мене наразі бракує часу.
photobucket.com та webshots.com разом з Флікром утворюють трійку найпопулярніших фотосервісів. Причому якщо Фотобакет мені чомусь не дуже подобається (по-перше, дизайном, а по-друге, там навіть не стільки фото-хостинг, скільки хостинг картинок), то Вебшотс справив вельми приємні враження (і обмеження на завантаження: 1000 фоток одразу і +100 фото кожен місяць після реєстрації).

Ну і, звісно, не можна не згадати про Google Picasa. Щодо зручності користування, то Пікаса тут поза конкуренцією. Качаєте собі однойменний клієнт-менеджер картинок, розбиваєте все у себе на компу на альбоми, тощо, а потім пофотоково чи цілими альбомами ллєте на Пікасу у вебі. В результаті без зайвих рухів отримуєте фотоальбом в мережі. ще один плюс - я не чув про які б то не було обмеження на розміри та кількість картинок, а це вельми суттєва перевага порівняно з тим же Флікром, наприклад.

Хостинг PDF-документів

Тут не хочеться повторюватись, адже все вже описано до мене: і навіщо воно треба (впевнений, це найперше питання для багатьох), і які сайти пропонують подібний сервіс. Так що раджу прочитати відповідний допис Мінус-одного про “Issuu, Scribd і Share”.