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

Для людей які хоч трохи займались програмуванням відповідь має бути очевидною, але на всяк випадок нагадаю: під час роботи над чимось ви сто відсотків будете проходити якісь віхи розробки і контроль версій дозволить отримувати стан проекту на певний момент. Плюс можна створювати гілки розробки. Уявіть, що при побудові будинку ви вирішите добудувати якийсь незапланований поверх, але не впевнені чи все триматиметься як слід. Ви віртуально дублюєте поточний будинок, будуєте свій поверх, поки інші будівельники тим часом працюють по запланованому графіку. Потім ви вирішуєте, що результат вашої роботи вас влаштовує ви плеском в долоні вставляєте його у існуючий будинок. А може будівельники десь помилились при розрахунках і набудували якусь фігню, то вони можуть так само швидко відкотитись до місця коли щось пішло не так.
До речі, місце де зберігаютсья всі стани проекту в термінах 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. була деяка початкова ревізія №1, яку для подальшої роботи стягнули два розробники
2. обидва щось поправили і один був першим, хто закомітив зміни на сервер, і з’явилась ревізія №2
3. другий спробував закомітитись, але сервер відмовив, вказавши що не може залити зміни поверх версії №1. Тому другий розробник має забрати собі версію №2 з репозиторія та об’єднати (або як часто кажуть “змерджити” від англомовного терміну merge) докупи зміни з ревізії №2 та свої власні правки. Часто це проходить автоматично, але буває, що треба ручна правка, коли зміни торкаються однакових фрагментів коду. Потім об’єднаний код можна комітити в репозиторій і так з’явиться ревізія №3

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

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

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

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

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

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

"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

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

• Django on Google App Engine in 13 simple steps by Thomas Brox Røst
• Django приложение на Google App Engine by diadya_vova
• Using Django 1.0 on App Engine with Zipimport by Dan Sanderson

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

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

<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
  google.load("jquery", "1.3.2");
</script>

Фрагмент вище дозволяє завантажувати потрібну версію jQuery прямо з Гугла і при виході нової версії не потрібно щось перезаливати на свій сайт – лише змінити в шаблоні заголовку сторінки номер версії і все готово.

Звісно ж таким чином можна завантажувати не лише jQuery, а й декілька інших Javascript-фреймворків. На сторінці Google AJAX Libraries API можна знайти всі бібліотеки та їх версії, що наразі підтримуються.

Більше того, таким чином можна також завантажувати Javascript’ові сервіси Гугла, наприклад такі як Google Maps, але для того доведеться звісно ж при завантаженні JSAPI вказати API Key, який отримується тут під конкретний домен. Тобто загальний вигляд підключення Google Maps API виглядатиме так:

<script type="text/javascript" src="http://www.google.com/jsapi?key=ABCDEFG"></script>
<script type="text/javascript">
  google.load("maps", "2");
</script>

Детальніше про роботу з JSAPI можна знайти на сторінці Google AJAX API.

Ось така цікава штука цей wxWidgets. А тепер перейдемо власне до підготовчих кроків, які доведеться зробити перед тим як розпочати перший проект. Наразі я опишу процес для Win32, але згодом хочу спробувати і відповідно занотувати цю саму процедуру для Linux.

Перше, що нам знадобиться – це скачати вихідні коди фреймворку, щоб потім зібрати на вашій машині версію оптимізовану для вашого компілятора. До речі, цікава штука: воно також має працювати з Visual Studio 2008 Express, так що таким чином можна створювати ПЗ абсолютно легально. Далі одразу рекомендую обзавестись дизайнером форм, щоб економити час на рутині. Офіційного редактора від розробників немає, а є лише купа редакторів від сторонніх виробників. Я спробував декілька і для себе зупинився на wxFormBuilder. Якщо хтось знайде щось зручніше і потужніше – з радістю вислухаю.

Тож завантажуємо і встановлюємо відповідну версію wxWidgets. Там знаходимо в підкаталозі “builds/msw” того місця, куди ви встановили wxWidgets проект “wx.dsw”, відкриваємо його і при необхідності погоджуємося на пропозицію студії сконвертувати його в її рідну версію. Далі обираємо тип білда. Я поки що пробував лише звичайні Release та Debug – це звичайні версії для статичної лінковки. Робимо білд. До речі, порівняно з тим-таки Qt збирається wxWidgets просто миттєво. Тепер перевіримо чи все у нас гаразд. В каталозі “samples” відкриваємо проект “samples.dsw”. В ньому знаходимо підпроект minimal і збираємо лише його (причому в одній з конфігурацій, в яких збирали саму бібліотеку). Можна було б, звісно, і всі sample-проекти при бажанні скомпілити, але то марна трата часу. Якщо minimal нормально скомпілювався, злінкувався та запустився, значить все чудово. Тепер не забудьте прописати шляхи до хедерів та скомпільованиз бібліотек у Visual Studio: в Tools→Options→Projects and Solutions→VC++ Directories відповідно для “Include files” прописуємо шлях до хедерів, а в “Library files” – шлях до щойно зібраних бібліотек.

Якщо хто хоче подивитись як описане вище виглядають вживу, можу запропонувати оцей англомовний скрінкаст (єдина відмінність – там шляхи до хедерів та бібліотек прописуються через vsprops-файл):

Ну і на всяк випадок лінки на рекомендації по встановленню під різні версії студії:

• wxWidgets на MS Visual Studio.NET (8.0)
• wxWidgets на MS Visual Studio 2008 (9.0)

Ну і поки що все. Наступного разу створимо свою в міру простеньку форму і запустимо її

latitude2brightkite – це сервіс, на якому можна підконектитись до ваших аккаунтів на Brightkite (через OAuth, що цілком безпечно, бо не вимагає від вас зберігати паролі на сайті) та Google Latitude (тут треба буде вручну скопіпастити ваш Латітьюдівський ідентифікатор, бо, на жаль, поки що в мене не вийшло автоматизувати його отримання). Ну і далі сервіс використовуючи ці дані періодично отримує гео-інформацію з Латітьюд і постить її у Брайткайт. От і все. Там є ще пара дрібних багів, але я їх на цьому тижні пофікшу.

До речі, з OAuth я промучився добряче. Мануали які я знайшов – всі з купою води і ніфіга не зрозуміло, тому довелося дізнаватись подробиці того як працює ця кухня просто взявши робочий приклад для Google App Engine і дивлячись що і як там зроблено. Так що я може навіть переборю лінощі і трохи згодом напишу свій стислий мануал.

Епопея з моїм омобілюванням почалася досить таки давно, здається наприкінці минулого року, коли завдяки Феру мну став власником чудового 3G-пакету U’Family 5 від Utel з інетом по 5 коп./МБ (навіть в GSM-роумінгу) всього за ~26 з копійками гривень в місяць абонплати. Але телефон у мене був звичайний і тому я весь час сидів виключно у білайнівському роумінгу. Після вимушеної покупки нового ноутбуку мну помітив, що у нього потенційно є вбудована можливість роботи з HSDPA модемами (навіть слот для сім-карти під акумулятором був), але такими фічами комплектуються лише збірки ноутів для США та Нової Зеландії. Я зацікавився можливістю встановлення такого обладнання у нас, та в сервісному центрі “Улісс” мені сказали, що зробити вони теоретично таке можуть, але модеми, що приходять від Dell залочені під AT&T і у них був випадок, коли модем не запрацював з нашими картками і тому вони мені порадили просто взяти модем у форматі Express-Card і забути про які б то не було проблеми. На тому мій запал тимчасово пропав, адже ціна, яку просив за модеми Utel кусаєтьcя вельми боляче: від найпростішого USB-модему 749 до Wi-Fi роутеру за 1699 грн. Але ж є така чудова річ як eBay! Час від часу я заходив туди цікавлячись поточними цінами на модем Huawei E800. Аналогічний девайс можна було придбати у Utel за 899 грн., що, погодьтесь, дещо забагато як для модему. І ось трапилося диво: десь на третій чи то четвертий захід я знайшов лот, де продавався новенький розлочений E800. Ціна на той час становила трохи більше 20$ і торги закінчувалась за 10 хвилин. І біддер був лише один. Накинувши в останні секунди розіграшу пару баксів я на диво з легкістю виграв лот. Загальна вартість разом з доставкою була в районі 45$, але в перерахунку на гривні навіть по курсу 8 (в той час як на момент покупки він був у районі 7.6-7.7), це було у 2.5 рази дешевше, аніж брати у того таки Utel. І от сьогодні, через кілька тижнів очікування, нарешті девайсик опинився у мене. Але це все приказка. Казка буде далі

На моє велике здивування бандерольку з модемом пошта кинула прямо в поштову скриньку А що: упаковка радше нагадувала коробку з-під DVD (ну може на 2-3 мм товща) аніж якийсь електронний товар. Посміявшись з сусідом трохи з дещо дивного нашій людині імені відправника Hu LongHui, мну відкрив коробку і поставив девайс у відповідний слот свого ноутбука Dell Latitude E6500 (модель ноута важлива для цієї оповіді). Windows радо помітила новий пристрій попросила дрова. Я поглянув на коробку, але помітив, що ними там і не пахло. “Ну і грець з ними”, – подумав я, – “інет же поруч!” Але це виявилось не так-то просто. Перші дрова, які я знайшов були на новозеландському сайті Vodafone І хоч я їх теж на всяк випадок скачав, але ставити не став. Потім я таки ледь знайшов їх на офіційному сайті Huawei (руки повідривав би за таке юзабіліті). Скачав. Перший архів виявився лише прошивкою, але наступний вже мав ISO-образ диску з дровами та необхідним софтом. Після встановлення модем розпізнався системою, але софт, що йшов у комплекті ніяк не хотів його бачити. Перезавантаження системи не допомогли. В бій знову пішов Гугл. Тут я довідався, що виявляється диску з дровами немає в комплекті, бо дрова і софт є на самій картці(!!!), яка має розпізнаватись також як CD-диск. Подумки вже почав прикидати ціну чи варто буде відсилати модем назад і просити обмін. Витягнув картку зі свого ноута і пішов смикати Растіка, що трохи прихворів і так доречно був вдома, щоб спробувати на його ноуті Lenovo. На моє полегшення все запрацювало: картка розпізналась як диск, софт і дрова встановилися, Mobile Partner розпізнав пристрій і мну успішно з’єднався з мережею. Ура! Отже картка робоча, але були якісь приколи саме з Dell‘ом. Гугл вивів на форум Vodafone, де подібна проблема визнавалась (правда з моделлю Huawei E870) і рекомендувалось оновити її прошивку. Я знову взяв картку і на Растіковій машині спробував оновити до прошивки, що я скачав з оф. сайту виробника раніше, але тут виявилося, що це і є моя версія firmware, а нічого новішого на сайті Huawei нема. Новіша прошивка знайшлась лише на сайті Vodafone, але були підозри, що після неї мій розлочений модем знову стане досить таки залоченим, що мене не влаштовувало. І ось нарешті на ще одному новозеландському форумі я побачив посилання на сайт грецього оператора “Wind” (з музикою “Каті Перової” (с) у фоні ), де таки була новіша версія firmware для E800. Я подумав, що навряд там версія з якимось локом, адже інакше вона б не запрацювала у новозеландців. На свій страх таки перепрошив і, о диво(!), мій ноут побачив картку як диск, зміг нормально поставити софт і дрова, а Mobile Partner успішно законектився до мережі Utel. Отакі от у мене сьогодні були пригоди…

Щойно вирішив також заміряти швидкість роботи мережі. Статистика ось:

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

For my english-speaking visitors: the ultimate guide to make your Huawei E800 card working on Dell, Fujitsu-Siemens and some other notebooks Download the new firmware for Huawei E800/E800A from this site and follow the installation instructions there to upload it onto your card. The notebook used to upload should be the one correctly working with this card (e.g. not Dell notebook or so). After that everything should work just fine.

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

Перший – для скорочення URL за допомогою сервісу bit.ly (перед використанням там треба зареєструватись, щоб отримати API key):

import urllib, urllib2
import json # є лише Python 2.6 і старше

bitly_login = "your bitly login"
bitly_apikey = "your API key"

def ShortenURL(url):
  try:
    request = urllib2.urlopen("http://api.bit.ly/shorten?version=2.0.1&longUrl=%s&login=%s&apiKey=%s" % (url, bitly_login, bitly_apikey))
    result = json.loads(request.read())
    return result["results"][url]["shortUrl"]
  except:
    return None

Другий – для публікації повідомлення в Twitter (тут використовується несек’юрна Basic HTTP Authorization, бо з oAuth це було б набагато складніше, а мені вночі було ліньки возитись).

import urllib, urllib2
import base64

login = "your twitter login"
passwd = "your twitter password"

secret = base64.encodestring("%s:%s" % (login, passwd))[:-1]

def Post(message):
  request = urllib2.Request("http://twitter.com/statuses/update.xml", urllib.urlencode({"status": message}), {"Authorization": "Basic " + secret})

  try:
    urllib2.urlopen(request)
    return message # returning message if it was successfully sent
  except:
    return None

Обожнюю python