Український IT-блог

Mercurial саторі. Частина 1

Скоро мені знадобиться знайомити одного майбутнього молодого розробника з таїнством користування системами контролю версій (надалі VCS, version control system) і тому щоб трохи систематизувати те, що я збирався розповісти, вирішив написати цей допис. Він розрахований на зовсім базовий рівень роботи і тому тут багато розжовувань, які більш досвідченим особам наврядчи будуть цікаві. Знайомство одразу буду проводити на прикладі сучасних розподілених систем, в нашому випадку Mercurial.

Навіщо воно треба?

Для людей які хоч трохи займались програмуванням відповідь має бути очевидною, але на всяк випадок нагадаю: під час роботи над чимось ви сто відсотків будете проходити якісь віхи розробки і контроль версій дозволить отримувати стан проекту на певний момент. Плюс можна створювати гілки розробки. Уявіть, що при побудові будинку ви вирішите добудувати якийсь незапланований поверх, але не впевнені чи все триматиметься як слід. Ви віртуально дублюєте поточний будинок, будуєте свій поверх, поки інші будівельники тим часом працюють по запланованому графіку. Потім ви вирішуєте, що результат вашої роботи вас влаштовує ви плеском в долоні вставляєте його у існуючий будинок. А може будівельники десь помилились при розрахунках і набудували якусь фігню, то вони можуть так само швидко відкотитись до місця коли щось пішло не так.
До речі, місце де зберігаютсья всі стани проекту в термінах VCS називаєтсья репозитарій, а місце в якому ви вносите правки – відповідно робоча копія. Процес відправки набору змін з робочої копії до репозиторію – це операція commit. Репозитарії часто зберігають десь подалі, не на робочих машинах, щоб у випаку коли у вас, наприклад, здохне комп, весь код можна буде повіністю відновити. У мене був гіркий досвід збереження єдиного екземпляру коду одного сайту на ноуті, який згодом сперли… З тих пір я не розлучний -з VCS та бекап-системами типу Dropbox і зберігаю всі важливі дані в інтернеті. Плюс зручно, що можна з легкістю отримувати точні копії на будь-яку машину.
І нарешті ще одна зручна штука в користуванні VCS, хоч і похідна від нього – це можливість робити code review – огляд змін які зробив розробник між версійми коду. Принципироботи code review-систем чудово накладаються на принципи роботи VCS і тому вони часто бувають нерозлучні, коли якість коду має велике значення.

Розподілені VCS

Як писалося вище, існують поняття репозитарію та робочої копії. У VCS, які були популярні донедавна було чітке розподілення обов’язків: репозитарій був один і центральний, часто на виділеному сервері. Кожний commit відправляв дані з робочої копії до репозиторію. В певному сенсі це було не завжди зручно у випадку, коли ви хочете закинути кілька змін різними commit’ами на сервер, що знаходиться в інтернеті. По перше, процес зазвичай досить повільний, по-друге, за відсутності зв’язку з інтернетом ви взагалі не зможете зробити commit.

Тому щоб побороти подібні недоліки прийшли розподілені системи контролю версій: Mercurial, Git, Bazaar, тощо… Суть їх проста: кожна копія проекту є одночасно і репозитарієм і робочою копією. Тобто вся робота по суті виконуєтсья локально, але існує механізм синхронізації між самотніми репозитаріями. За такої організації вищезгадані проблеми з відсутністю зв’язку з інтернетом нівелюються – ви можете робити весь спектр операцій з VCS локально. Але як я вже казав зберігати дані локально – небезпечно, тому зазвичай в інтернеті відкривають віддалені репозитарії, які слугують таким собі хабом між людьми які працюють з даними. Тобто синхроніхація репозитаріїв іде не кожен-з-кожним (хоча і такий принцип організації можливий), а всі синхронізуютсья лише з віддаленим (але навіть за його недоступності робота може продовжуватись).

Розподілених VCS є кілька. Найбільш популярні наразі Git та Mercurial. Вибір між ними справа релігійна, але якщо цікаво порівняти, то ось гарний аналіз від Google (англ).

Працюємо з Mercurial

Як я вже говорив, робоча копія Mercurial фактично є заодно і репозиторієм, але всі зрізи версій зберігаються в каталозі .hg з мета-інформацією репозиторія. Поза цією папкою власне робоча копія. Не видаляйте папку, бо втратите репозиторій!

Варіантів для отримання локального репозитарію проекту два:

якщо він існує на іншому комп’ютері чи сервері і тоді вам треба виконати команду clone:
```
$ hg clone http://path/to/your/repository
```
вона створить копію репозитарію з вказоного URL в поточному каталозі
якщо ви створюєте новий проект, то потрібно виконати команду init в папці з проектом:
```
$ hg init
```
потім додати всі потрібні файли командою add:
```
$ hg add
```
Увага! У вас в каталозі можуть бути файли, які не варто зберігати: наприклад, “.obj”-файли C++ чи Пітонівські “.pyc”.
для цього в кореневій папці (на одному рівні з папкою “.hg”) треба створити файл .hgignore з вмістом типу:
```
glob:*.bak
glob:*.obj
glob:Debug
glob:Release
```
і так далі… Можна також прописувати не лише файли, а і цілі каталоги (Debug та Release в прикладі вище).

Далі можна працювати з кодом. Якщо додавались нові файли – не забувати виконувати команду add. Коли потрібно залити зміни в репозитарій виконуємо команду commit:

$ hg commit

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

була деяка початкова ревізія №1, яку для подальшої роботи стягнули два розробники
обидва щось поправили і один був першим, хто закомітив зміни на сервер, і з’явилась ревізія №2
другий спробував закомітитись, але сервер відмовив, вказавши що не може залити зміни поверх версії №1. Тому другий розробник має забрати собі версію №2 з репозиторія та об’єднати (або як часто кажуть “змерджити” від англомовного терміну merge) докупи зміни з ревізії №2 та свої власні правки. Часто це проходить автоматично, але буває, що треба ручна правка, коли зміни торкаються однакових фрагментів коду. Потім об’єднаний код можна комітити в репозиторій і так з’явиться ревізія №3

Таким чином у централізованих системах є лише одна “головна” ревізія, а самі ревізії йдуть одна за одною. Ось так це виглядає схематично:

У розподілених систем нема центрального сервера, а всі коміти йдуть локально, тому типовий приклад роботи з ними наступний:

є центральний хаб з якого два розробники забирають єдину ревізію №1
обидва роблять правки та локальні коміти, таким чином і у першого, і у другого на комп’ютері з’являється по дві ревізії: загальна №1 і у кожного власна №2
вони обидва синхронізують свої копії зі спільним репозитарієм і в результаті на спільному репозиторії з’являється три ревізії: №1, №2 та №3. Таким чином утворилося дві “головні” ревізії №2 та №3.
один з розробників знову синхронізує репозиторій і у нього з’являєтясь копія спільного. Він може оновити локальну копію до однієї з головних ревізій і продовжити роботу в цій “підгілці”, а може об’єднати (змержити) зміни з №2 та №3 і закомітити їх як ревізію №4: таким чином граф ревізій утворить ромб.

Синхронізація в Mercurial однонаправлена: тобто за одну операцію можна або залити свої ревізії у віддалений репозиторій (операція push), або отримати звідти ревізії у свій локальний (операція pull).

$ hg pull http://path/to/your/repository
$ hg push http://path/to/your/repository

Поки що це вся теоретична частина. Якщо ви працюєте під ОС Windows, то життя собі можна значно полегшити, якщо поставити собі TortoiseHg – графічний фронт-енд для роботи з Меркуріал. Плюс роботу можна зробити зручнішою та розширити потужність системи поправивши конфігураційний файл Mercurial. Але це я залишу на наступний раз.

Google App Engine + Django

Powered by Google App Engine Яким би поганим не здався мені на перший погляд Datastore у Google App Engine, але тим не менш для багатьох проектів і його буде цілком достатньо (тим паче, що у roadmap його розвитку майорить довгоочікуваний повнотекстовий пошук). Тому для платформи одного з нових міні-проектів, які нещодавно спали мені на думку мну вибрав саме Google App Engine. Водночас мну дуже вже звик до фреймворку Django і мається на увазі не лише його ORM, тому вирішив підключити його останню версію (в комплекті з GAE йде 0.96, яка вже ну дууууже застаріла). Але не за допомогою костилів (цього чи ось цього) як минулого разу, а просто напряму і викинувши все зайве (тобто фактично все, що було зав’язано на ORM). І не дивлячись на те, що в Інеті було повно мануалів по підключенню Django помучитись в неочікуваних місцях трохи довелося.

По-перше, сама збірка Django. Я підбирав модулі частково експериментальним шляхом і щоб не прописувати все вручну постійно зробив собі простенький .bat-файл, який пакує в архів необхідну частину джанги:

"C:\Program Files\7-Zip\7z.exe" a django.zip ^
django\__init__.py ^
django\bin ^
django\core ^
django\conf ^
django\db ^
django\dispatch ^
django\forms ^
django\http ^
django\middleware ^
django\shortcuts ^
django\template ^
django\templatetags ^
django\test ^
django\utils ^
django\views ^
django\contrib\__init__.py ^
django\contrib\contenttypes ^
django\contrib\localflavor ^
django\contrib\markup ^
django\contrib\sitemaps ^
django\contrib\humanize ^
django\contrib\formtools

Зібраний цим скриптом архівний файлик я підклав у корінь новоствореного gae-проекту. Причому пакування в архів тут робиться не задля економії дискового простору. Просто у App Engine є обмеження на кількість файлів, а в проекті Django їх дуже багато. Тепер залишилась справа за малим: підмінити Django що йде у комплекті з GAE на нашу версію, яку ми завантажимо з архіву за допомогою фічі zipimport. Тут все досить просто (це мій поточний варіант скрипта, але думаю без якихось проблем має запрацювати і той, що виклдаений на офіційній сторінці інтеграції GAE та Django):

main.py

#!/usr/bin/env python
# main.py

import os, sys, logging
os.environ["DJANGO_SETTINGS_MODULE"] = "projectname.settings"

# Google App Engine imports.
from google.appengine.ext.webapp import util

# Uninstall Django 0.96.
for k in [k for k in sys.modules if k.startswith('django')]:
    del sys.modules[k]

# Add Django 1.0 archive to the path.
django_path = 'django.zip'
sys.path.insert(0, django_path)

# Force Django to reload its settings.
from django.conf import settings
settings._target = None

import django.core.handlers.wsgi
import django.core.signals
import django.db

def log_exception(*args, **kwds):
    logging.exception('Exception in request:')

# Log errors.
django.core.signals.got_request_exception.connect(log_exception)

# Unregister the rollback event handler.
django.core.signals.got_request_exception.disconnect(django.db._rollback_on_exception)

def main():
    # Create a Django application for WSGI.
    application = django.core.handlers.wsgi.WSGIHandler()

    # Run the WSGI CGI handler with that application.
    util.run_wsgi_app(application)

if __name__ == "__main__":
    main()

Але найцікавіша частина над якою я намучився найбільше – це налаштування файлу settings.py в самому Django. По-перше, треба повідключати модулі зав’язані на Django ORM, тобто видалити або закоментити Middleware-класи:

django.contrib.sessions.middleware.SessionMiddleware django.middleware.csrf.CsrfViewMiddleware django.contrib.auth.middleware.AuthenticationMiddleware django.contrib.messages.middleware.MessageMiddleware

NOTE: SessionMiddleware варто замінити на той, що йде у комплекті з gaeutilities – тоді ви принаймні зможете скористатись портованим аналогом сессій.

Контекст-процесори:

django.contrib.auth.context_processors.auth django.contrib.messages.context_processors.messages

Та додатки:

django.contrib.auth django.contrib.sessions django.contrib.sites django.contrib.messages

Також, наскільки я зрозумів, портована версія Django має певні проблеми з підтримкою i18n, тому в конфігураційному файлі її варто відключити (але питання інтернаціоналізації для мене вельми актуальне, тому найближчим часом постараюсь цю проблему вирішити):

USE_I18N = False

Ну от в принципі і все. Мну черпав джерело натхнення з:

GitHub у поміч блогеру

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

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

Проте всі ці (і на разі не лише мої) забаганки можуть здійснитися, якщо використовувати GitHub, і, зокрема, сервіс Gist Читати далі »

Знайомі незнайомці: file, ln та lost+found

Досі мені ні разу не доводилося відновлювати файлову систему після краху або неправильних дій користувачів, проте одного дня я сам «прострелив собі ногу» в стилі UNIX: вилучив половину файлів двотерабайтного сховища на сервері. В цю особливо похмуру ніч я запустив перебудову файлової системи з метою знаходження старих невилучених файлів, і вже на ранок я отримав більш-менш відновлену файлову систему, а в її корені з’явилась вищеозначена директорія lost+found.

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

Utel Укртелеком’ович в гостях у Київстару

Utel Вслід за збоєм в роботі мобільних Utel в національному роумінгу в мережі Beeline з’явилось таке повідомлення:

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

Тут є дві новини:

По-перше, мене радує те, що, нарешті, в селі, де я іноді буваю, будуть працювати обидва мої номери – і київстаровський, і утеловський.

В Києві пробував, при ручному виборі мережі працює роумінг як в Білайні, так і в Київстарі. Автоматично теж переходить. В Київстарі, правда, без передачі даних – тільки дзвінки та СМС, але обіцяють, що має з’явитись.

По-друге, фраза “абоненти мобільного зв’язку «Укртелеком»” в офіційному пресс-релізі та на сайті Utel явно вказує на те, що “Укртелеком” таки відмовляється від торгової марки “Utel”. До цього офіційних повідомлень на цю тему я не бачив.

Скрінсейвер з гарними фотками для ледачих

Google Photos Screensaver Багатьом людям рано чи пізно стандартний майкрософтівський прапорець набридає і вони шукають якоїсь гарненької заміни. Одним хочеться оживити “відпочиваючий” комп’ютер усякими там анімованими пейзажами чи акваріумними рибками (ненав’язлива реклама ), а іншим типу мене обожнює дивитись на всякі там гарні фотки. Скрінсейверів, що просто показують фотографії з певних каталогів на диску нині дофіга, але всам факт завантажування фоток такого ледащо і гіка як я вельми дратує – ну не сучасно це, і кому ті зайві рухи потрібні? От як би то його зробити, щоб воно саме… Та сучасні технології не стоять на місці і вже мабуть навіть останній найледачіший користувач інтернету знає про інсування стрічок RSS – найзручнішого засобу отримувати свіжу інформацію без нагальної необхідності лазити по сайтах (найбільш адекватні з них ще й користуються єдино вірною RSS-читалкою – Google Reader, але зрештою донесення цієї істини до варварів не є темою цього допису і залишаєтсья на самоопрацювання). Так от, одне з чудес RSS полягає в тому, що воно дозволяє додавати в стрічку не лише звичайні статті (з текстом, відео та картинками), а і долучати до нього медіа-дані (як аттачменти у електронній пошті). Ті самі відео та картинки, але не як елемент статті, а як окрему сутність (в термінах RSS воно називається enclosure). Це важливо, бо комп’ютери все-таки тупі і виділити потрібну картинку з-поміж тексту їм не так легко як людині. Думаю ви розумієте до чого я веду: картининки можна автоматично отримувати з відповідних RSS і не треба нічого самотужки качати – розумні програми зроблять все за вас. Єдина умова – щоб ці картинки були оформлені у стрічці як enclosue (на жаль, не всі фото-сайти настільки просунуті, щоб видавати стрічки картинок з картинками не у вигляді вмісту новини, а саме як додаток).

Вибір самих RSS з фотографіями чи картинками та скрінсейвера з підтримкою їх завантаження з чих стрічок – справа смаку, але особисто мну для цих цілей рекомендує дві речі: фотки краще всього діставати з найкращого сайту по фотографії – Flickr, а в якості самого скрінсейвера Google Photos Screensaver. З останнім, щоправда, Гугль зробив невелику підлість – раніше це був окремий продукт, а зараз він іде виключно як складова Google Picasa, яка мені в повному обсязі нафіг не треба, бо я замість Пікаси все одно більш полюбляю Adobe Lightroom (бета версія якого ще нещодавно була безкоштовною, але як зараз – не знаю). Але повертаючись до нашого барану… Нижче показано як виглядає його налаштування за замовчуванням (дефолтна стрічка вже декілька місяців, на жаль, не працює, а там були непогані фото). При додаванні нової RSS-стрічки він перевіряє її на наявність додатків-фотографій і якщо таких не буде, то скаже, що вона не підходить.

Чим крутий Флікр? По-перше, тим, що це зараз мабуть найбільший і найкращий сайт де можна знайти справді гарні фотки практично всього що завгодно. Плюс саме завдяки ньому я частково відучився від поганої практики завантаження фоток на локальну машину. Навіщо? Щоб вона потім згубилась в нетрях диску? Краще вподобану вами на Флікрі фотографію додати собі у “favorites” – вона буде там присутня поки власнк не надумає її видалити (що буває вкрай рідко), плюс автор фото дізнається, що вона вам сподобалась і йому буде приємно. По-друге, цей сайт багато в чому передовий і там підтримується згадана вище RSS з фото-додатками майже для всього що тільки можна! Хочете отримати фотки, у яких в тегах прописано “кіт” – будь-ласка, з певної групи – ніяких проблем, власні вподобання – та залюбки…

Єдиний мінус Флікра – це жлобство деяких професійних (і не дуже) фотографів В тому сенсі, що вони викладають лише зменшені копії своїх фотографій і тому при показі скрінсейвера воно виглядє убого. Я довго мучився з цим, поки одного осіннього ранку, чи то вечора на мене не зійшло осяяння під назвою Yahoo Pipes. Це така кльова штука, яка дозволяє збирати та модифікувати дані з різних джерел та видавати у потрібному вигляді, але при цьому не вимагає від вас ніяких навичок програмування В нашому випадку задача проста як двері: взяти RSS-потік з додатками-картинками та відфільтрувати його по розмірам зображень, але про це я напишу вже іншим разом, ок?

Сам собі супроводжувач репозиторію Debian: автоматичне оновлення віддалених репозиторіїв

Як виявилося, шановний читачу, я досить рано закрив тему власного реозиторію, а тому цією короткою розповіддю хочу важливі моменти з точки зору супроводжувача репозиторію, з чим вас і вітаю. Підтримувати власний репозиторій виключно для однієї вітки дистрибутиву як мінімум нелогічно. Справа в тому, що цим ви обмежуєте використання продуктів вашої праці лише обраною для цього віткою — використання такого репозиторію для оновлення інших віток є надто небажаним в силу того, що можна запросто зламати систему залежностей пакета, що повертає нас до початкового тезису. Саме тому збирати пакети необхідно у відповідному середовищі(наприклад, chroot відмінно підходить для таких задач), і лиш потім завантажувати до відповідної вітки. В свою чергу, репозиторій повинен мати всі використовувані вітки. Ну а самому репозиторію, звісно, місце на сервері. Ця стаття присвячена таким важливим задачам, як віддалене завантаження нових пакетів в репозиторій та подальше його автоматичне оновлення, організація сумісного репозиторію для різних версій дистрибутиву та дещо інше. Читати далі »

Сам собі супроводжувач репозиторію Debian

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

Існує далеко не один спосіб створення власного репозиторію: деякі пропонують варіант «взяти всі файли, покласти в одну купу, і згенерувати відповідні індексні файли Release та Packages», при використанні деяких утиліт, наприклад apt-build, остання сама створює собі репозиторій. Проте для поширення власних оригінальних або переконфігурованих пакетів такий спосіб навряд чи дасть виграш в довготривалій перспективі. «Правильний» репозиторій повинен мати власний пул, підписані індексні та релізні файли та власне пакети, можливість автоматичної обробки нових та оновлених пакетів та підтримку механізму apt-pinning. Саме такий репозиторій можна просто організувати, використовуючи утиліту reprepro. Читати далі »

Сам собі супроводжувач пакетів Debian: збираємо Nginx

В попередній статті ми зробили корисну справу і зібрали собі urxvt з підтримкою 256 кольорів. Тепер нарешті можна вмикати нормальну кольорову схему одного з найпотужніших редакторів — vim, а саме desert256. Однак розробники все ще сидять незадоволені і очікують, коли ми їм нарешті поставимо найсвіжіший Nginx зі скомпільованим стороннім модулем Nginx HTTP Push Module, або просто NHPM. Що ж, не будемо змушувати їх чекати ще. Читати далі »

Сам собі супроводжувач пакетів Debian: rxvt-unicode і 256 кольорівt

Debian GNU/Linux Доброго дня, шановний читачу. В житті операційної системи поруч з резервним копіюванням важливе місце займає її оновлення. Так звані «виробничі» сервери першими пунктами в списку пріоритетів мають безпеку та стабільність роботи, тому їхні оновлення проводяться виключно з метою підвищення даних параметрів. З іншого боку, експериментальні сервери та сервери розробки вимагають найсвіжішого програмного забезпечення, зібраного з необхідними параметрами, рівнем оптимізації та відлагоджувальною інформацією. Проте очікувати виходу офіційного оновлення пакету Debian часом доводиться дуже довго, а встановлена програма необхідна зараз. Звичайно, можна становити програму власноруч, зібравши її з джерельних кодів, проте в результаті система все далі й далі буде походити на смітник. Саме для таких випадків є красиве і правильне вирішення проблеми – створення власного репозиторію. Читати далі »

Старі записи