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

Термінологія OAuth

Posted by bunyk on 18.03.2012 Коментування вимкнено

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

Аутентифікація – перевірка того факту. що суб’єкт – той за кого себе видає.
Авторизація – перевірка того факту, що суб’єкт має право на доступ до певного ресурсу.
Credentials (мандат) – реєстраційна інформація потрібна для аутентифікації.

В схемі протоколу OAuth описані три агенти: клієнт (споживач, client, consumer), сервер (провайдер послуги, server, service provider) і власник ресурсу (користувач, user, resource owner).

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

Дуже часто клієнт працює від чужого імені. Наприклад браузер працює від імені користувача, використовуючи реєстраційну інформацію (зазвичай логін та пароль) яку йому довірив користувач. Клієнтом може бути веб-застосунок, який поділяється на фронт-енд та бекенд, і запити до сервера йдуть з бекенда. Але якою б не була архітектура клієнта – він все одно діє від імені користувача як одне ціле.

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

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

OAuth використовує три типи облікової інформації – облікова інформація клієнта, тимчасову та токени. Специфікація називає їх відповідно consumer key and secret (client credentials), request token and secret (temporary credentials), та access token and secret (token credentials).

Перші в параметрах запиту називаються відповідно:

{
    'oauth_consumer_key': 'anonymous',
    'oauth_consumer_secret': 'anonymous'
}

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

Після того як користувач дає дозвіл, клієнту (зазвичай за допомогою GET запиту, за адресою яка повідомляється серверу параметром callback_url, хоча можливо існують і інші способи) передають тимчасовий мандат (токен та секрет запиту).

Клієнт звертається до сервера з цим токеном та секретом, і сервер замінює їх на постійні. Цей крок мені дещо незрозумілий (яку схему атаки він дозволяє уникнути?), але чомусь так воно працює.

Посилання:

Filed under: Кодерство, Павутина Tagged: API

Шизофазогенератор Маркова

Posted by bunyk on 03.03.2012 Коментування вимкнено

Написав скрипт який на даний момент. Письменник – звертайтесь. Залишилась математика, і що я знаю дещо про керування рекламними кампаніями в Google календар з нагадуванням по SMS, бо думав, що його швидкість зміниться так: Тепер ще один сервіс не буде ніяких порад про побудову сюжету, що ортогональна проекція легко стає ізометричною після здійснення повороту на 45° до чого веду.

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

Написав таку штуку, бо давно нічого не писав (в блог, а не коду), і мені хочеться вияснити можливості MongoDB. Крім того Стенфорд все відкладає свій курс NLP, а в мене на роботі в цьому напрямку вже проходять дослідження. І біля мене навіть сидить один кандитат наук.

А також мені можливо скоро доведеться здавати диплом. А його ще треба написати. Одні студенти з MIT були настільки ліниві, що замість того аби писати дипломні роботи написали програму яка пише дипломні роботи замість них. І непогано пише. Моя програмка теж непогано пише, хоча використовує набагато простішу технологію. Ось згенерований текст в не в моєму стилі:

Ні, я ж ще не знаєш? Хоча відсутність дров передбачити було неважко… Нет, с арифметикой у них, увы, атрофирована полностью. Ну як не згадати його кільця! Приблизно схожий на Юпітер – засмієте. Якщо ви колись побуваєте на ньому, то система вивалюється з грізним повідомленням “опускатись нижче по рівню” У Форті дуже мало внутрішніх перевірок на коректність роботи програми та коректність дій користувача, а я в шинку промок. Зате тепер я розумію конретику, яка в майбутньому навчитись самотужки обмінюватись інформацією між своїми копіями, схожими по роботі програмами та зовсім різними по призначенню. Також потрібно розуміти поняття реальної швидкості, тобто власне довжини вектору руху, неспроектованого.

Теорія відносності каже (якщо чесно, я сам собі так сказав; треба вчити, бо ліньки було розбирати всі варіанти, коли є бабло, то здесь ситуация совершенно иная. Эти части текста, для мене цей недолік несуттєвий =)). Завдяки окулярам ліве око бачить червоний колір однієї довжини хвилі, а не на моїх =) Угадайте, хто при читанні моїх завдань на життя згадав Вікіпедію, ТеХ, інтели, мускли, вольфрамальфа та будь-що інше, але ними користуються тільки ТеХніки ))) F# він уже присутній для користування. Давайте спробуємо уявити собі наскільки потужна обчислювальна система у загальному значенні. Більшість з них дуже маленька і закінчується об”єктами зірками і зірки знаходятся в протифазі. У Земного барицентру дві орбіти. Оскільки окремі моделі можуть зв’язуватись між собою і слідувати певній логіці, обо’єкт типу IEnumerable. Власне задля зручності роботи і було насправді, доки у нас є файлик з кодом). Рекомендую подивитись Пайтон-вставки в асемблерний код.

Вгадайте хто це міг написати?

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

————————– ;– MAIN ——- ;————————— ;– Макроси FASM-у, для мене це ще не переведено на Python3. import turtle def plotAxes(screen): turtle.reset() turtle.up() turtle.speed(0) turtle.hideturtle() turtle.down() turtle.goto(0,0) turtle.goto(0, 1) ^^^ table.[index] let crcResult = ~~~(Array.fold byteCrc 0xffffffffu (Encoding.Default.GetBytes(s))).

З чимось дівчачо-філологічним виходить набагато краще:

Ні, не чула, що вона заробила свій перший мільйон, треба самому прожити життя, отруєний грибком заздрощів. Рік тягнувся. Не люблю, але дозволь людям, що інші виросли, я не питиму. Тебе морально згвалтували настільки, що всередині”, – чистий бланк, і друге! Проте, коли такі, яких я викрила. Всяке і різне, як коханого чоловіка, інколи така правда вилазить боком. Маленькі і недосвідчені, будуємо собі вимріяний світ, не витираючи ніг. Іншими словами, графоманство. І добре, якби завтра мені витягнулись власне ті питання, які не просто знати. Його треба пропустити крізь себе, залившись алкоголем. По колу. Але я не забила на університет, сиджу вдома та плачу. Плачу, та ж. Гадаю, що надихають на добро тебе. – Чудово. – Про що і до сьогодні люди шукають добре? Зрештою, важко налаштуватись на позитив, коли одного разу, одягну школадного носа. Скажете, доля не любить солодкого?

Зразу видно що текст про почуття і про почуття і про емоції, одним словом потік свідомості. Точнісінько як оригінал…

Я б ще розказав про те яка MongoDB лапочка, розширивши тему попередньої публікації, а також про те як генерувати чистий (ну майже) корпус тексту з певного сайту за допомогою httplib2, BeautifulSoup, soupselect та регулярних виразів. Але я вже стільки награвся своїм шизофазогенератором, що боюсь в неділю через недосипання не зможу розстріляти своїх тім-лідів шариками з фарбою. А хочеться. Тому решту читайте в наступних серіях… Або самі код розбирайте.

А поки що можете почитати афоризми в стилі Канта. Теж не далекі від оригіналу.

Filed under: Кодерство, Павутина Tagged: математика

Початок стосунків з MongoDB

Posted by bunyk on 02.03.2012 Коментування вимкнено

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

Задача яку я розв’язував – підрахунок частоти послідовних трійок токенів в тексті, де токен – слово, пунктуація, або невидимі символи (переноси рядків, прогалики, табуляції). Вже при 20000 трійок кожен запис в базу займав 200 мілісекунд. Це від того, що перед тим як додати одиничку до кількості трійок певного виду потрібно їх в базі даних знайти. Але так як токенами може бути пунктуація, більшість трійок, це “після слова йде кома, після коми прогалик”. Зрозуміло що після кожної коми повинен йти прогалик. А після коми з прогаликом з майже однаковою ймовірністю може йти купа різних слів. Тому трійок для того аби згенерувати текст статистично схожий на текст певного корпусу – мало.

І я вирішив перейти до масиву. Тобто записи в базі даних будуть виглядати як словник з трьох слів та кількості вживань, а словник з списку трьох слів, слова яке йде за ними та їх кількості вживань. Але індекс по списку не дуже то допоміг. А все виявилось тому, що індекс по масиву дозволяє навіть перевіряти входження елемента в список. Чи входження всіх елементів списку в список. Зрозуміло що розмір індексу, зростає так немало (тому напевне на розмір ключа встановлено обмеження не більше 800 байт), та й витрати часу на запити теж. Тому краще повернутись назад до індексу по окремих скалярних полях документа. І всьо повинно бути чотко!

А про те що з того вийшло – трохи пізніше.

Література:

Filed under: Інструменти, Кодерство Tagged: NoSQL

Археологія в програмуванні. Міждисциплінарне есе

Posted by bunyk on 16.02.2012 Коментування вимкнено

Крім програмістів – архітекторів бувають програмісти – археологи. І невдовзі ми постараємось вияснити хто вони такі, і чим займаються.

Але спочатку цікавий факт: Археологи припускають що довжина сторони основи піраміди Хеопса була a = 230.33 (поки не стерлася), а її висота h = 146.6.

Любителі арифметики порахували, що
$\displaystyle 2\frac{a}{h} \approx 3.142291950886767 \approx \pi$

І от, якби вони були програмістами, в них виникло б питання:
“Ну і чого це Єгиптяни захотіли саме такі розміри?”,
“Що, число пі допомагає фараону краще сохнути?”,
“А що буде якщо збудувати вищу піраміду?”

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

Хеміун

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

Програміст – археолог робить те саме що й звичайний археолог. Намагається дізнатись побільше про те що хотів зробити архітектор. (Тобто спочатку про те що в архітектора вийшло, і чому воно так).

Звісно, в айтішній археології використовуються зовсім інші інструменти, і результати теж виглядають по-іншому.

Наприклад ось збережені письмові свідчення про те хто писав реалізацію мови Python (cpython), і що він про це думав 14 травня 91 року:

         guido Sun May 05 20:09:44 1991 +0000: /* Long (arbitrary precision) integer object implementation */
         guido Tue May 14 12:06:49 1991 +0000: /* XXX The functional organization of this file is terrible */
         guido Fri May 02 03:12:38 1997 +0000: #include "Python.h"

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

Які якості повинен мати програміст археолог? Ну, по перше – терпіння. Його робота не така приємна як в архітектора, бо доводиться зустрічатись сам на сам з ідеями іншої людини, яка може виражати їх занадто по-іншому, бо належить до іншої культури, користується іншою мовою. Та не мені вам розказувати чому люди різні.

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

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

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

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

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

Також арехологу потрібно мати гарну короткотермінову пам’ять. Багато програмістів (з книжки Coders at work) кажуть що чим гірша короткотермінова пам’ять в програміста, тим менш заплутаний код він пише. Це стосується архітектора. Археолог навпаки – чим більше зможе охопити в пам’яті за раз, тим швидше він зможе зрозуміти задум архітектора.

Ну, і окрім гарної пам’яті, археологу потрібні гарні інструменти.

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

Є популярний аргумент проти ефективних редакторів коду (від людей які так і не подолали поріг входження), що думає програміст 90% часу, а набирає код – 10%, тому його ефективність залежить від його голови, а не від редактора. Цифри можуть бути навіть заменшені, але можна привести контраргумент – зручніше думати пролітаючи в редакторі крізь 5 рівнів абстракції за секунду, і не думаючи про те чи ти натискаєш C-], чи n.

Посилання

Filed under: Кодерство Tagged: розробка

Парадокс роботи програміста

Posted by bunyk on 03.01.2012 Коментування вимкнено

Полягає в тому що вона таки виконується. І код, хоча містить сотні помилок, все таки працює.

Захід є Захід, а Схід є Схід, і їм не зійтися вдвох,
Допоки Землю і Небеса на Суд не покличе Бог;
Та Сходу і Заходу вже нема, границь нема поготів,
Як сильні стають лицем у лице, хоч вони із різних світів!

Р. Кіплінг.

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

Далі. На моєму рідному факультеті дехто таки зібрався, і таки видали новий номер газети “Кубик”. (Не соромтесь, візьміть й собі копію. ~9 Мб).

І порівняно з попередніми номерами цей – огого! Він не вийшов в паперовій версії, але думаю це й на краще. Там 40 сторінок дрібним шрифтом! Мій факультет розорився б, якби надрукував це хоча б в 100 екземплярів. А pdf крім того ще й зберігає true color і поліграфічну якість. Я взагалі мрію про те, що на офіційному сайті факультету з’явився RSS. Але скоріше вже збудують метро на Теремки.

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

Наприклад на сторінці 11 є коротенька стаття про те як керувати програмістами. Якої звісно мало щоб навчитись це робити, але уявлення про предмет вона дає.

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

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

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

І потім згадується методологія. Це така штука яка допомагає залишати програміста задоволеним, і окрім того добиватись того щоб він таки завершував те що повинен зробити.

І це, знаєте, мотивує розібратись з методологіями, і управлінням програмістами. Бо з’являється підозра що мене обманом заставляють робити те що я не хочу .

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

От так ми й працюємо. Ті двоє зліва – продакт менеджер і скрам мастер..

Filed under: Кодерство Tagged: кубик, психологія, робота, розробка

OAuth2 – промінчик світла в темному царстві?

Posted by graywolf on 20.12.2011 Коментування вимкнено

З давніх давен мене завжди харила необхідність реєстрації на сайтах. Чесно. Причому не з якихось там параноїдальних міркувань (мене це дуже мало бентежить), а банально: знову вводити ім’я користувача, придумувати пароль, тощо… І тому коли треба реєструватись на комусь сайті доводиться через стандартну логін/пароль/e-mail процедуру це мене запросто може відлякнути від реєстрації взагалі. Потім з’явилися всякі OpenID, Facebook Connect, OAuth і життя стало налагоджуватись – реєстрації на одному з популярних сервісів типу Google/Facebook/Twitter зазвичай вистачає аби мати можливість логінитись на нормальні сайти в один клік: наприклад той самий Покупон ніколи б не отримав моїх грошиків ні за які знижки аби у нього не було реєстрації через Facebook та оплати по Webmoney, коли можна було придбати купончика фактично не торкаючись клавіатури, а просто в кілька тицків мишкою. І впевнений, що я такий не один. Тому останнім часом завжди коли доводиться писати сайт з реєстрацією мну намагається всунути туди реєстрацію через “3rd party” сервіси. Але ще рік тому це була нефігова проблема, бо усі ці сервіси використовували різні протоколи і незважаючи на те, що всі вони намагались зробити якнайкраще – виходило як завжди, бо об’єднати все це в якусь уніфіковану систему не так вже й тривіально. Чи не найбільше мене напрягав OAuth, бо при першому знайомстві з його процесом обмінами токенів наскоком без півлітри не розібратися. Причому мало того, кожен сервіс часто використовував свою варіацію протоколу, що знову ж таки ускладнювало написання гнучкого коду.

Коли довелося причіплювати мультиавторизацію останній раз, я вже поступово готувався засісти в ці окопи надовго. Хоча в цьому випадку було простіше – у Django принаймні добрі люди написали django-publicauth. Документація там бідненька, тому як правильно його заюзати довелося гуглити по коду інших open-source проектів, які його використовували. Facebook тим не менш завівся досить живенько, а от на ВКонтакті вже мило чекали перші граблі: модуль більше року не оновлювався і там API для авторизації встиг змінитися. Доктор сказав “Різати!” Як виявилося, російський недофейсбук встиг перейти на OAuth2 і (о, диво!) там все було просто як гранчастий стакан (щоб отримати токен для подальших запитів треба зробити лише один редірект та один фоновий запит з мінімумом параметрів). Причому там все було настільки просто і так чудово лягло на архітектуру бекендів django-publicauth, що все пофіксилось буквально за пару годин (включно з вдуплянням в те як все парцює, першим прототипом та подальшим рефакторингом). Мало того, при пошуку інформації про новий протокол виявилося, що Google та Facebook вже теж його підтримують. Коротше кажучи, наступного вечора я переписав і ці дві системи під OAuth2 і все працювало як швейцарський годинник. На все про все менше 8 годин часу і майже готовий патч. Кароче, вирішив я форкнути django-publicauth на bitbucket та влити туди свої правки Єдина поки що паршива вівця – це Twitter, який поки не підтримує другу версію, але благо перша там працює нормально.

OAuth2 flow for server-side applications

Ложка дьогтю: не дивлячись на простоту реалізації стандарт OAuth2 ще не затверджено остаточною. Існує кілька його драфтів і всі використовують свої власні інтерпретації. Але за рахунок його простоти складність правок під конкретну реалізацію зазвичай є справою перевизначення пари методів. Причому насправді відмінності дуже тупі. Вконтакт повертає JSON-відповідь із “зайвим” рівнем вкладеності, Гугл вимагає авторизувати токен через POST-запит, а Фейсбук повертає результат не в JSON, а в urlencoded query string

Стандартизація рулить

Перемогти посередність

Posted by graywolf on 16.11.2011 Коментування вимкнено

Нарешті в мене дійшли руки перекласти ще одну повчальну статтю Пола Грема про мови програмування, яку я вже згадував у минулому перекладі про “дух міста”. Зазвичай подібні “євангелістичні” речі я сприймаю вельми критично, оскільки я чудово знаю, що срібних куль не існує, але тим не менш думаю, що основна ідея вірна. Читаючи статтю зробіть поправку на те, що вона написана в 2003-му, тобто майже десятиріччя тому і з тих пір дещо змінилося, а Lisp вже не одна така мова-д’Артаньян

Велика подяка Тарасу за виправлення купи помилок

Автор оригіналу: Пол Грем (Paul Graham)
Оригінал: Beating the Averages

Photo by AlicePopkorn

Влітку 1995-го я та мій друг Роберт Морріс запустили стартап під назвою Viaweb. Нашою метою було написати програмне забезпечення, що дозволило б користувачам створювати власні онлайн-магазини. Інновацією на той час було те, що наш софт працював на нашому сервері, а інтерфейсом були звичайні веб-сторінки.

Я впевнений, що у багатьох людей виникла подібна ідея в той час, але наскільки я знаю, Viaweb був першим web-додатком. Це виглядало настільки ново для нас, що ми навіть компанію назвали аби підкреслити це: Viaweb, бо наше програмне забезпечення працювало “через Веб” (англ. “via Web”, – прим. пер.), а не на персональному комп’ютері.

Іншою назвичністю було те, що наш софт було написано здебільшого на мові програмування Lisp. Це був один із найперших великих додатків націлених на кінцевого користувача, написаних на Lisp, який до того часу був прерогативою університетів та дослідницьких лабораторій. [1]

Таємна зброя

Ерік Реймонд написав ессе під назвою “Як стати хакером” і в ньому, окрім усього іншого, він розповідає майбутнім хакерам про мови, які варто вивчати. Він пропонує розпочати з Python та Java, тому що їх просто вивчити. Серйозний хакер також захоче вивчити C, аби хакати Unix, та Perl для системного адміністрування й cgi-скриптів. І нарешті справжні хакери-аксакали мають подумати про Lisp:

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

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

Але хвилиночку. Ця метафора не поширюється так сильно. Причина того, що знання латини не забезпечить вас роботою тому що нею ніхто не розмовляє. Якщо ви писатимете латиною, ніхто вас не зрозуміє. Але Lisp – це мова програмування і комп’ютер розмовляє тією мовою, якою до нього спілкуєтсья програміст.

Тож якщо Lisp зробить з вас кращого розробника, як стверджує Ерік, то чому не використовувати його? Якщо художнику дати пензля, який дозволить йому стати кращим художником, то мені здається, що він почав би використовувати його у всіх своїх роботах, чи не так? Я не намагаюсь поглузувати з Еріка Реймонда. В цілому його порада – слушна. Те що він каже про Lisp – це загальноприйнятий міф. Але в цьому міфі є суперечність: Lisp зробить вас кращим розробником, але ви не будете його використовувати.

А чому ні? Зрештою, мови програмування – це всього на всього інструменти. І якщо Lisp справді вирощує кращих програмістів, використовуйте це. А якщо ні, то кому він здався?

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

Роберт та я, обидва знали Lisp непогано і ми не бачили жодної причини не довіритись власним інстинктам і обрати його. Ми знали, що всі інші пишуть софт на C++ чи Perl. Але ми також знали, що це ще нічого не означає. Якби ви обирали технологію з цих міркувань, то писали б під Windows. Коли ви обираєте технологію краще ігноруйте те що роблять інші і думайте лише про те, що працюватиме найкраще.

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

Середня велика компанія росте приблизно на 10% за рік. Тож якщо ви керуєте великою компанією і працюєте як середньостатистична велика компанія, то ви можете розраховувати, що ви і зростати будете як середньостатистична велика компанія: на 10% в рік.

Звісно ж, ситуація зі стартапами – аналогічна. Якщо ви робите все як середній стартап, ви очікуєте на середню продуктивність. Проблема в тому, що для стартапа середня продуктивність дорівнює провалу. Коефіцієнт виживання у стартапів набагато менший за 50%. Тож якщо ви започатковуєте стартап – краще робіть щось дуже дивне. Якщо ви цього не робите – чекайте проблем.

Тоді в 1995 ми знали те, чого не розуміли наші конкуренти, а деякі не розуміють і досі: коли ви пишете ПЗ, яке працює на ваших серверах, то ви можете самі обрати будь-яку мову, яку захочете. Коли ви пишете програми для ПК, то ваші вподобання будуть схилятися до того, що найближче до ОС під яку ви пишете. Десять років тому (відносно моменту написання статті, тобто 2003 р., – прим. пер.) під розробкою ПЗ малося на увазі написання програм на C. Але з web-додатками, особливо коли у вас є програмні коди як ОС, так і мови програмування, ви можете обрати будь-яку мову.

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

Якщо обирати будь-яку мову, то яку? Ми обрали Lisp. З одного боку очевидним було, що швидка розробка дуже важлива на цьому ринку. Ми розпочинали з чистого листа, тож компанія, яка могла б запропонувати нові можливості раніше інших, отримувала перевагу. Ми знали, що Lisp – це гарний вибір для того, аби писати софт швидко, а серверні додатки збільшували цей ефект тим, що ви могли релізитись тої ж хвилини, коли код було написано.

Якщо інші компанії не хотіли його використовувати – нам же ліпше. Він зробив нас передовиками, але ми не відмовлялись від будь-яких поступок. Коли ми розпочинали Viaweb, ми нічого не тямили в бізнесі. Ми нічого не знали про маркетинг, чи найм працівників, чи залучення інвестицій, чи роботу з клієнтами. У жодного з нас навіть не було досвіду справжньої роботи. Єдина річ, яку ми робили добре – це написання софту. І ми сподівались, що це допоможе нам. Ми використовували будь-яку перевагу, яку могли собі забезпечити.

Можна сказати, що використання Lisp було експериментом. Нашим припущенням було те, що пишучи софт на Lisp ми могли б впроваджувати нові можливості швидше за наших конкурентів. А оскільки Lisp дуже високорівневий, нам не потрібна була б велика команда розробників, тому наші витрати мали бути значно меншими. Якщо це так, то ми могли б запропонувати кращий продукт за менші гроші і отримати прибуток. Ми б забрали всіх користувачів, а конкуренти не отримали б жодного і пішли б з ринку. Це те на що ми сподівались.

Які ж результати нашого експерименту? В певному сенсі дивовижно, але це спрацювало. Ми мали багато конкурентів, приблизно 20-30, але жоден з них не міг з нами тягатись. Ми мали WYSIWYG-майстерню створення онлайн магазинів, яка працювала через web, але виглядала як додаток для ПК.. У наших конкурентів були CGI скрипти. І могли завжди попереду них по функціональним можливостям. Інколи, у розпачі, конкуренти намагалися реалізувати щось, чого не було у нас. Але цикл розробки на Lisp був настільки швидким, що ми могли реалізувати їх аналог за день чи два після того, як конкуренти анонсували їх у прес-релізі. До того часу, коли журналісти що висвітлювали прес-реліз дзвонили нам, у нас вона вже теж була.

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

Коли мені було років дев’ять, я отримав книжку “День Шакала” Фредеріка Форсайта. Головним героєм був вбивця, якого найняли “прибрати” президента Франції. Він мав пройти повз поліцію, аби дістатися до номера з якого було видно маршрут президента. Він пройшов повз них перевдягнувшись стариганом у лахмітті, якого вони б ніколи не запідозрили.

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

Отож, мені трохи ніяково казати, але я ніколи не говорив публічно про Lisp поки ми працювали у Viaweb. Ми ніколи не згадували про нього в ЗМІ, а якщо виконати пошук по сайту компанії, то знайшлася б лише згадка двох книжок у моїй біографії. І це не випадковість. Стартап має давати настільки мало інформації, наскільки можливо. Якщо вони не знали на чому ми писали чи їм було все одно, я намагався підтримувати цей статус-кво. [2]

Люди, які розуміли наші технології найкраще – це клієнти. Їм було все одно на якій мові було написано Viaweb, але вони помічали, що все працювало справді чудово. Вони могли створювати чудові онлайн магазини буквально за хвилини. І таким чином, в основному завдяки їх порадам, ми отримували все більше клієнтів. На початку 1996-го у нас було 70 магазинів. На кінець 1997 – вже 500, а шість місяців потому, коли нас купив Yahoo!, у нас уже було 1070 користувачів. Зараз під маркою Yahoo Store цей софт досі є лідером на ринку. Це одна з найбільш прибуткових частин Yahoo і магазини створені завдяки ньому стали основою Yahoo Shopping. Я покинув Yahoo в 1999, тож не знаю скільки зараз у них користувачів, але остання цифра, яку я чув – це 20000.

Blub-парадокс

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

Я почну із шокуюче суперечливої заяви: мови програмування відрізняються за своєю потужністю.

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

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

Є багато виключень з цього правила. Якщо вам потрібно написати програму, яка має тісно співпрацювати з програмою написаною на певній мові, то краще використовувати саме ту мову. Якщо ви пишете програму, яка робить щось дуже просте, типу обробки чисел чи бітових маніпуляцій, можливо краще використовувати менш абстрактні мови, тим паче, що це може дати помітний приріст у швидкодії. Якщо ж ви пишете маленьку програмку “на викинути”, найкраще використати ту мову, у якої найбільш підходящий набір бібліотечних функцій. Але в цілому для розробки ПЗ вам варто використовувати найбільш потужну (і достатньо ефективну) мову програмування яку тільки зможете, а використання всього іншого – помилка того ж типу, хоч і в меншій мірі, як і програмування в машинних кодах.

Ви бачите, що машинні коди дуже низькорівневі. Але в певному загальноприйнятому сенсі всі високорівневі мови програмування вважаються еквівалентними. Але вони такими не є. Технічно термін “високорівнева мова” не має під собою чіткого визначення. Немає чіткої границі між машинними мовами з одного боку та всіма високорівневими мовами з іншого. Мови розподіляються по спектру [4] абстрактності від найбільш потужних і до машинних мов, які самі по собі різняться за потужністю.

Наприклад Cobol. Cobol – високорівнева мова в тому сенсі, що він компілюється в машинний код. Але ви що, правда сперечатиметесь, що Cobol не є еквівалентом, наприклад, Python? Та він мабуть ближчий до машинних мов, аніж до Python.

А як щодо Perl 4? Між Perl 4 та Perl 5 в мову були додані лексичні замикання. І більшість Perl-хакерів погодяться, що Perl 5 потужніший за Perl 4. Але визнаючи це, ви також визнаєте що одна високорівнева мова може бути потужніша за іншу високорівневу мову. І невмолимим є висновок, що окрім певних винятків, ви повинні використовувати найпотужнішу доступну мову.

Щоправда цю ідею рідко доводять до кінця. Після певного віку програмісти рідко добровільно змінюють мовні вподобання. Яку б мову вони не використовували, вони вважають її “достатньо хорошою”.

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

І насправді наш гіпотетичний Blub-розробник не буде використовувати жоден з них. Звісно, він не писатиме в машинних кодах. Для цього є компілятори. А щодо Cobol, то він не знає як на ньому написати все, що йому треба. У нього ж просто немає X (бідь-яка фіча Blub на ваш вибір).

До тих пір поки гіпотетичний Blub-розробник дивиться на спектр вниз він знає, що він дивиться вниз. Мови менш потужні за Blub очевидно менш потужні, бо в них нема тих можливостей до яких він звик. Але коли цей розробник подивиться в іншу сторону, вверх по спектру потужності, він не розумітиме, що дивиться вверх. Все, що він бачить – це лише дивні мови. Він мабуть навіть вважає їх еквівалентними Blub по потужності, але з усіма цими незрозумілими заморочками. Blub для нього “достатньо гарний”, бо він думає на ньому.

Коли ми поглянемо на те саме з точки зору програміста, який використовує мову, що знаходиться вище по спектру потужності, ми побачимо, що він дивиться на Blub згори. Як на ньому взагалі можна писати? У нього ж нема Y!

По індукції лише програмісти, що дивляться з висоти достатньої аби оцінити всю різницю в потужності різних мов можуть сказати які з них насправді найбільш потужні (і мабуть це саме те, що мав на увазі Ерік Ремонд, коли казав, що Lisp зробить з вас кращого розробника). Ви не можете довіритись думці інших через Blub-парадокс:: всі задоволені тією мовою, якою їм доводиться користуватись, тому що вона диктує їм те як писати.

Я знаю це із власного досвіду як старшокласник, що писав програми на Basic. Ця мова навіть рекурсію не підтримує. Важко уявити написання програми без використання рекурсії, але тоді мені її геть не бракувало. Я думав на Basic. І я був його гуру. Знав всі його трюки.

П’ять мов, що рекомендує Ерік Реймонд, розташовані в різних точках спектру потужності. Питання відносних відстаней між ними дуже чутлива тема. Я б помістив Lisp на його вершину. І аби підкріпити це твердження я скажу про одну з речей, якої мені бракує в чотирьох інших. Я думаю: “як на них взагалі можна щось написати без макросів?” [5]

Багато мов мають особливість, яка називається називається макросами. Але макроси Lisp унікальні. І хочете – вірте, хочете – ні, але це пов’язано з дужками. Дизайнери Lisp засунули туди ці дужки не просто аби відрізнятись від інших. Для Bulb-програміста код на Lisp виглядає дивно. Але дужки там не просто так. Вони очевидний доказ фундаментальної різниці між Lisp там всіма іншими мовами.

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

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

Програми, що пишуть програми? Вам це взагалі потрібно? Не дуже, якщо ви думаєте на рівні Cobol. Ввесь час, якщо ви думаєте на рівні Lisp. Зручно було б якби я міг навести тут приклад потужного макросу і сказати: “Ось! Як вам таке?” Але якби я це зробив, це виглядало б повною тарабарщиною для людини, яка не знає Lisp; і тут не вистачить місця, аби описати все, що вам потрібно знати, аби зрозуміти його значення. В Ansi Common Lisp я намагався проходити всі теми якомога швидше і все одно дістався до макросів лише на 160-й сторінці.

Але я думаю, що зможу навести приклад, який може бути переконливим. Програмний код Viaweb редактора складався з макросів на 20-25%. Макроси важче писати, аніж звичайні функції Lisp і використовувати їх там де це не обов’язково – ознака поганого тону. Тому кожен макрос в тому коді був там, тому що він мав там бути. Це означає, що як мінімум 20-25% коду програми роблять речі, які не так-то легко зробити засобами інших мов. Яким би скептиком не був Blub-програміст відносно моїх заяв про потужність Lisp, цього має бути достатньо аби розпалити його зацікавленість. Ми не писали код заради власного задоволення. Ми були крихітним стартапом і програмували щосили аби звести технічні мури між нами та нашими конкурентами.

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

Айкідо для стартапів

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

Якщо ви думаєте використовувати Lisp у стартапі, не переживайте, що не всі вас зрозуміють. Вам навпаки краще сподіватись на цей статус-кво. І скоріш за все так і буде. Така природа мов програмування: програмісти задовольняються тим, що в них є. Апаратне забезпечення змінюється набагато швидше ніж звички, тому практики програмування вже відстають від потужності процесорів на 10-20 років. У закладах типу Массачусетського технологічного університету пишуть програми на високорівневих мовах з середини 60-х, але багато компаній продовжували писати програми в машинних кодах аж до 80-х. Я впевнений, що багато хто продовжував писати на машинних мовах поки процесор, як бармен, що взяв, закрив заклад і просто пішов додому, нарешті залишив їх не при справах переходом на RISC інструкції.

Звичайні технології змінюються швидко. Але мови програмування інші: вони представляють собою не просто технологію, а те як програмісти мислять. Вони наполовину – технології, а наполовину – релігія. [6] І середньостатистична мова (тобто будь-яка мова, якою користується середньостатистичний програміст) розвивається зі швидкістю айсберга. Garbage collection, що з’явився в Lisp ще у 60-х зараз вважається гарною річчю. Runtime-типізація теж набирає популярність. Лексичні замикання, що з’явились в Lisp ще на початку 70-х зараз лише з’явились на “радарах”. Макроси, запропоновані в Lisp в середині – 80-х і досі “terra incognita”

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

Якщо ви працюєте у великій компанії – це буде нелегко. Вам складно буде переконати тупуватого начальника дозволити написати щось на Lisp, коли він лише щойно прочитав, що якась інша мова програмування приречена на успіх, як пророкували мові Ada 20 років тому. Але якщо ви працюєте у стартапі, у якого ще немає тупуватого начальства, ви можете використати Blub-парадокс на власну користь: використати технологію, яку ваші конкуренти, скуті середньостатистичними мовами, ніколи не зможуть перевершити.

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

За роки роботи у Viaweb я прочитав багато описів вакансій. Нові конкуренти, здається, з’являлись нізвідки майже кожен місяць. Перша річ, яку я перевіряв після їх online-демо, це відкриті вакансії. Після кількох років я вже розумів, які компанії могли представляти потенційну загрозу, а які – ні. Чим більше звичних речей було в описів вакансій, тим меншу небезпеку вона представляла. Найбільш безпечними були ті, що вимагали досвід роботи з Oracle. Про них можна було одразу забути. Вам також не треба було особливо переживати відносно компаній, що шукали C++ та Java розробників. Якщо компанія шукала розробників на Perl чи Python – її вже треба було остерігатися, адже це компанії, де принаймні за технічну сторону відповідали справжні хакери. Якби я зустрів опис вакансії на місце Lisp-розробника, то це мене б дуже сильно занепокоїло.

Примітки

[1] Viaweb складався з двох частин: редактор, насписаний на Lisp за допомогою якого люди будували сайти та система замовлень написана на C. Перша реалізація була написана на Lisp майже повністю, бо система замовлень була дуже простою. Пізніше ми додали ще два модулі: генератор картинок написаний на C та back-office менеджер написаний здебільшого на Perl.

У січні 2003 Яху випустила нову версію редактора написану на C++ та Perl. Але важко було сказати, що це вже не був Lisp, бо для того, аби переписати код на C++ їм фактично довелось написати власний інтерпретатор: програмні коди генератора сторінок, наскільки мені відомо, досі написані на Lisp.

[2] Роберт Морріс каже, що мені не треба було цього приховувати, бо навіть якби наші конкуренти знали, що ми використовуємо Lisp, вони не зрозуміли б чому: “Якби вони були достатньо розумними для цього, то самі використовували б Lisp.”

[3] Всі мови рівнопотужні в сенсі еквівалаентності машині Тюрінга, але програмісти ніколи не мають на увазі саме цю еквівалентність (ніхто ж не пише для машини Тюрінга). Потужність про яку говорять програмісти складно визначити формально, але одним із способів описати її буде: можливість мови більш потужної може бути реалізована на мові менш потужній лише шляхом написання інтерпретатора більш потужної мови. Якщо у мові А є оператор для видалення пробілів з рядка, а у мові Б – ні, то це не робить мову А більш потужною, бо ви можете написати функцію, яка робитиме те саме в Б. Але якщо А підтримує, скажімо, рекурсію, а Б – ні, то це вже не реалізуєш простим написанням бібліотечної функції.

[4] Примітка для нердів: можливо це решітка, що звужується догори; форма не має значення, але ідея в тому, що там є принаймні частковий порядок.

[5] Це трохи невірно трактувати макроси як окрему фічу. На практиці їх користь значно збільшується завдяки іншим можливостям Lisp типу лексичних замикань та залишкових параметрів.

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

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

Posted by graywolf on 09.09.2010 Коментування вимкнено

Минулого разу я вже оглядово ознайомив вас із основними принципами роботи з Mercurial, а тепер час зробити нашу роботу зручнішою. Цього разу я буду більше сфокусований на реальній роботі з Меркуріалом під ОС Windows. перший крок для цього – треба скачати TortoiseHG. Це shell-extension для роботи з Mercurial під Windows. Також поки ви читатимете ці рядки рекомендую заодно завантажити WinMerge – це інструмент для візуалізації змін та злиття коду. Справа в тому, що вбудований у стандартну поставку Mercurial KDiff3 фактично неюзабельний і тому нам його потрібно буде замінити на більш зручний. Звісно, вибір інструменту виключно за вами (WinMerge просто мій особистий фаворит), якщо у вас є власні преференції серед merge tools – ви зможете аналогічним чином прикрутити щось інше. Ну а тепер трохи пройдемося по конфігураційному файлу Mercurial. Те, що тут описано буде частково цікавим і для тих, хто працює з Mercurial під *nix‘и.

Конфігураційний файл Mercurial

Глобальний конфігураційний файл Mercurial можна легко знайти, скориставшись наступною таблицею:

Операційна система	Шлях до файлу
Windows XP або молодше	`C:\Documents and Settings\username\Mercurial.ini`
Windows Vista або старше	C:\Users\username\Mercurial.ini
*NIX	~/.hgrc

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

Мій конфігурацівйний файл виглядає приблизно так:

[ui]
username = graywolf
merge = winmergeu

[paths]
projectname= https://graywolf@bitbucket.org/graywolf/projectname

[auth]
projectname.username = graywolf
projectname.password = PASSWORD
projectname.schemes = http https

[extdiff]
cmd.winmerge = C:\Program Files (x86)\WinMerge\WinMergeU.exe
opts.winmerge = /e /x /ub /wl

[merge-tools]
winmergeu.executable = C:\Program Files (x86)\WinMerge\WinMergeU.exe
winmergeu.priority = 1
winmergeu.fixeol = True
winmergeu.checkchanged = True
winmergeu.args = /e /ub /dl other /dr local $other $local $output
winmergeu.gui = False
winmergeu.binary = True

[tortoisehg]
vdiff = winmerge

[extensions]
mq =
rebase =
legacy-merge = C:\Program Files (x86)\Mercurial\hgext\legacy-merge.py

Пройдемося трохи по кожному пункту. Секція [ui] відповідає за інтерфейс користувача. В моєму випадку використовуютсья лише два параметри:

username – ім’я буде використовуватись при ваших commit’ах в репозитарій.
merge – зовнішня утиліта, яка буде використовуватись для злиття коду

Секція [paths] дозволяє створити псевдоніми (alias) для url-посилань на проекти. Тобто коли ви будете наступного разу робити push/pull, то можна давати команду:

$ hg push projectname

замість

$ hg push https://graywolf@bitbucket.org/graywolf/projectname

Секція [auth] дозволяє налаштувати деякі параметри підключення до зовнішніх репозитаріїв. Наприклад, логін та пароль. Пароль взагалі-то прописувати не дуже гарна ідея, бо він зберігається лише як plain-text. Також можна обмежити пролтоколи по яким дозволено обінюватись даними з віддаленими репозитаріями, але це не обов’язково. Зверніть увагу, що налаштування прив’язуються до конкретних проектів, причому проект ідентифікуєтсья його alias’ом: .

Секції [extdiff] та [merge-tools] використовуються щоб вказати Меркуріалу які утиліти використовувати для перегляду змін та злиття файлів відповідно. В нашому випадку я прописав WinMerge. [tortoisehg] – відповідно налаштування специфічні для TortoiseHG. В деталі налаштувань тут я не вникав, бо це все одно був копіпаст готового рішення

Ну і нарешті сама корисна частина конфігураційного файлу: секція [extensions]. Стандартний комплект Mercurial вже іде із великою їх кількістю, але вони за замовченням виключені і включаютсья з конфігураційного файлу по необхідності. Найбільш корисною тут буде розширення mq, яке додає фічу під назвою strip changeset – можливість видаляти ревізії з репозитарію. Щоб увімкнути extension потрібно додати в секцію [extensions] рядок:

extension = path_to_extension

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

TortoiseHG

Тепер прийшов час продемонструвати типовий сеанс роботи з TortoiseHG. Нехай у нас уже є якись проект, до якого ми хочемо прикрутити Mercurial. Заходимо в нього через Windows Explorer і клікаємо правою конопкою на каталозі з проектом (взагалі всі операції з TortoiseHG виконуютсья через контекстне меню каталога, тому надалі я про це згадувати не буду) і вибираємо TortoiseHG > Create Repository Here.

У вікні, що відкрилося залишаємо все як є. Мені особисто підтримка старих репозитаріїв не потрібна була, а от файли типу .hgigniore – це необхідність.

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

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

Там в лівому списку видно поточні рядки для ігнору, а справа – файли які проходять фільтрацію (тобто неігноровані). Ваша задача скласти список виразів для ігнорування, щоб в правому списку залишились лише корисні файли (але всі ). Фільтри можна задавати або як регулярні вирази (regexp), або файлові маски (glob). Мені поки що вистачало і останнього. Щоб додати фільтр – вводите маску у верхньому рядку і натискаєте відповідну кнопку Add. Мій типовий ігнор-список для проекту на Visual Studio 2008 виглядає так:

glob:Debug
glob:Release
glob:GeneratedFiles
glob:*.suo
glob:*.user
glob:*.pch
glob:*.ncb

Закриваємо вікно ігнор-списку – тепер в лівому списку файлів для коміту залишились лише небхідні нам. Вибираємо їх всі і в контекстному меню цього списку клікаємо “Add”. Тепер навпроти всіх них в списку має з’явитися літера “A”. Тепер можна натискати “Commit” в тулбарі і вуа-ля. Ваш перший коміт в локальний репозитарій. Можна закривати вікно коміту. Зверніть увагу також, що комітяться лише файли відмічені галочкою, тобто при бажанні можна зробити кілька комітів.

До речі, якщо нам потрібно буде видалити файл з проекту, то потрібно буде в контекстному меню вибрати пункт “Forget” (трохи дивний вибір назви), причому він видалить одразу і локальну копію, так що обережно

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

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

Оскільки робоча копія є в певному сенсі і репозитарієм, то аби виконати ті чи інші дії Меркуріалу потрібно скористатись робочою копією. Але в цей час у вас можуть бути якісь зміни, які ще рано комітити, але які ви не хочете втратити. Для цього запропоновано механізм Shelve/Unshelve коли ви можете поточні зміни відносно базової ревізії відкласти на поличку (shelve), виконати необхідні операції з репозитарієм, повернутися до базової ревізії, дістати зміни з полички (unshelve) і отримаєте початковий стан речей. Вікно shelve можна викликати або з контекстного меню каталогу, або вибравши Tools > Shelve в головному меню вікна Commit.

Тепер ознаомимося з найцікавішим вікном TortoiseHG і яким ви будете користуватись найбільше. Це Repository Explorer, який можна викликати з контекстного меню каталогу. Ось так приблизно виглядає це вікно для великого проекту, над яким працює декілька людей. Це основний “центр управління польотами”. Звідси можна синхронізувати репозитарії, зливати гілки, видаляти ревізії, дивитись граф та історію розробки. Зліва видно граф, в якому можна відслідковувати залежності ревізій. Вибравши ревізію можна внизу подивитись які файли та як саме змінилися. Якщо ввести у полі URL репозитарію адресу, то можна користуватись кнопками pull (зелена стрілочка вниз) та push (зелена стрілочка вверх), які будуть відповідно завантажувати з, або вивантажувати на репозитарій, що знаходиться за вказаною адресою.

Просимулювати це можна дуже просто. У контекстному меню каталогу вибираєте TortoiseHG > Web Server і якщо вас влаштовує порт за замовчуванням натискаєте Start. З вікна, де написано “listening at” копіюєте URL.

Далі заходите в іншу папку (не репозитарій) і з контекстного меню вибираєте TortoiseHG > Clone, де в полі Source прописуєте щойно скопійований рядок. В Destination вказуєте де хочете розмістити копію репозитарію. Робите Clone і якщо відкриєте щойностворений клон репозитарія у Repository Explorer побачите, що це точна копія репозитарія іншого. Зробіть в новому деякі змни, закомітьте їх і в тому-таки Repository Explorer натисніть кнопку Push. Тепер відкрийте в RE оригінальний репозитарій і побачите, що вони знову ідентичні. Ось така нескладна магія. Єдине що у вас активною вважатиметься все ще ревізія на якій ви працювали до оновлення (в RE вона підсвічуєтсья більшим колом навпроти імені ревізії), тому щоб отримати останні зміни в робочий каталог треба в Repository Explorer клацнути правою кнопкою на останній (найновішій) ревізії та в контекстному меню вибрати Update.

Для того, щоб злити дві гілки в одну треба вибрати гілку куди ви збираєтесь злити зміни клацнувши на ній лівою кнопкою миші, а потім, не знімаючи цього виділення, клацнути правою на тій ревізії яку ви хочете злити у першу і в контекстному меню, що з’явилося вибираєте Merge with…. З’явиться вікно, у якому тепер треба натиснути кнопку Merge. Mercurial сам спробує по можливості все злити, але якщо він десь сумніватиметься, то вискочить вікно з вашим Merge tool, у якому вам буде запропоновано розібратися з конфліктами самостійно. Для WinMerge результат, який ви хочете побачити в кінці має бути у правому вікні. Після того як ви побачите сакральне “Merge Successful” зміни треба знову закомітити (бо merge робиться виключно в робочій папці як активні зміни).

От наразі і всі основи роботи з Mercurial. Якщо виникли запитання – welcome. Можливо мене якось проб’є зробити скрінкаст для наглядності, але це точно буде нескоро

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

Posted by graywolf on 02.09.2010 Коментування вимкнено

Скоро мені знадобиться знайомити одного майбутнього молодого розробника з таїнством користування системами контролю версій (надалі 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

Posted by graywolf on 08.04.2010 Коментування вимкнено

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):

#!/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

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

« Previous page | Next page »