Ось так приблизно виглядає плеєр в браузері:

Amazon Cloud Drive Sceenshot

А отак на мобільному телефоні:

Amazon Cloud Player for Android

Передісторія

Я подумав і вирішив, що задачка взагалі-то на кілька хвилин, але тому хотів піти складнішим шляхм і зробити її на LISP. У мене така жахлива хвороба – я не можу вчити нічого пов’язаного з IT поза контекстом хоч якогось прикладного застосування. Тому хоча мені хотілося б вивчити багато речей, але із-за того, що я не можу придумати собі прикладну задачу, в результаті не можу заставити підучити щось цікаве, але на перший погляд нетривіальне. Я трохи подумав як той Лісп розгортатити у вебі і зрештою вирішив не паритись, а підійти прагматичо (за останній рік мій “mindset” суттєво змінився і став орієнтований на кінцевий результат, а не на чергову “цікаву технологію”). Тому вирішив зробити віджет на Javascript, тим паче, що і тут у мене був маленький скелет у шафі – хотів попробувати написати плагін для jQuery, щоб коли наступного разу знову доведеться щось правити я в них вже розумівся трохи краще.

В результаті за пару годин придумав простенький алгоритм (перше, що прийшло в голову, тому приймаються будь-які суттєві пропозиції для вдосконалення), що працював на простому дереві для pattern matching (надалі просто “словник”) і побудував словник для ромаджі. На форумі uanime одразу ж почали постити баги а я нашвидкоруч поправляти словник, додаючи пропущені патерни. В той же час Мінус-один захопився ідеєю зробити словники для хірагани та катакани. Причому оновлював він їх для кани так швидко (і публікував прямо в форумні пости), що я вирішив залити скрипт в якусь систему версійного контролю, де можна було б на льоту правити та оцінювати зміни і не зловживати форумом. До речі, в цьому плані github виявився дуже крутим зі своїм on-site редагуванням файлів та автопублікацією у веб через github pages; bitbucket там близько не валявся. Варто зазнчаити, що більшу частину роботи тут зробив Мінус-один, бо словники з певних технічних міркувань містять все-таки багато повторень і я просто в шоці як йому вдалось так швидко і з мінімумом помилок наповнити дерево для двох алфавітів.

Результат

Вийшла ось така формочка, яка транслітерує японську (увага! на сайтах, де цей допис кроспоститься скрипт не працюватиме, тому перевірити можна лише тут):

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

Для мене ж профіт: вперше попрацював з git’ом та github’ом (з останнім я раніше лише пару раз скачував початкові коди якихось модулів та плагіни для redmine) та зробив свій перший екстеншн для jQuery.

Куточок лінгвістичного маньяка

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

Технічний куточок для підростаючого покоління

Алгоритм жадібний (матчить найдовший можливий патерн) і рекурсивний (найбільша глибина рекурсії дорівнює довжині вхідного рядка + 1; не дуже гарно, але для того застосування де планується – вистачить). Вхідний словник – дерево шаблонів побудованих наступним чином:

В js це кодується через вкладний Object:

var k2ua = {
...
    "し": {
        "~": "ші",
        "ゃ": "шя",
        "ゅ": "шю",
        "ょ": {
            "~": "шьо",
            "う": "шьоо",
        },
    },
...
};

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

І все-таки про LISP

Вже потім я знайшов, що в інеті повно інтерпретаторів LISP написаних на javascript, але:

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

Але оригінальна ідея не відкинута, а відкладена… на невідомий термін.

З давніх давен мене завжди харила необхідність реєстрації на сайтах. Чесно. Причому не з якихось там параноїдальних міркувань (мене це дуже мало бентежить), а банально: знову вводити ім’я користувача, придумувати пароль, тощо… І тому коли треба реєструватись на комусь сайті доводиться через стандартну логін/пароль/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

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

Мені отут подумалось, чи я єдиний кому цікаво було б якось прийняти участь у якомусь із названих у сабжі заходів? ^_^ Про Хакатон я знав раніше, але якось не склалося, а про два інших дізнався буквально нещодавно. Основна їх ідея – написати робочий додаток/стартап за дуже обмежену кількість часу (24-48 годин, причому не робочих, а саме календарних!). Я подивився на список того, що клепали під час проведення Garage48 – вражає.

Отож, з того, що проводиться в Україні я знайшов три: Garage48, Startup Mixer, DOU Hackaton. У першого основний приціл на практику і навчання саме створення і просування стартапів (на заходах присутні “наставники”, які допомагають правильно обрати цільову аудиторію, скерувати розробку в умовах обмеженого часу та “продаж” ідеї). Другий – наш український клон першого. Хакатон судячи з того, що я читав у відгуках менш бізнес-орієнтований і більше схоже на змагання “just for fun”: зібрались, попили пива, склепали прожку (хоча, що цікаво, судячи з відгуків продуктивність на Хакатонах була вищою ніж на проведеному на минулому тижні Startup Mixer).

Кароче, хацууууу! Схоже, що наступний захід – це Garage48 в травні 2012 в Києві. Треба придумати цікаву але компактну ідею і не провтикати дату як завжди.

Нарешті в мене дійшли руки перекласти ще одну повчальну статтю Пола Грема про мови програмування, яку я вже згадував у минулому перекладі про “дух міста”. Зазвичай подібні “євангелістичні” речі я сприймаю вельми критично, оскільки я чудово знаю, що срібних куль не існує, але тим не менш думаю, що основна ідея вірна. Читаючи статтю зробіть поправку на те, що вона написана в 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] В результаті порівняння мов програмування або приймає вид релігійних воєн, або книжок для школярів показово нейтральних, як взірець гуманізму. Люди, що знаю ціну своєму часу та душевний спокій оминають цю тему. Але це питання релігійне лише наполовину; його варто вивчати, особливо якщо ви хочете винайти нову мову.

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

Мінусів було не так багато. Найбільший – вартість заходу. 300 ойро я сам особисто навряд заплатив би навіть за таку чудову конференцію (тому дякую MD за надану можливість ^_^). Ще один момент з яким навряд можна щось зробити – це те, що деякі цікаві (і навпаки нудні) доповіді були паралельно і доводилося мучитись вибором між двома. В результаті я не потрапив на дуже цікаву судячи по слайдах “Programmers Anarchy”

Ну а тепер трохи про найбільш цікаві доповіді та ідеї…

“Effective Software Development in the 21st Century: The New Face Of Software Engineering” by Dr. Alistair Cockburn

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

Інша цікава частина – про ефективні комунікації, яка спонукала якомога частіше використовувати засоби до візуалізації, які значно покращують сприйняття інформації. Наприклад, для географічно розподілених команд – замість документу/електронного листа одна з опцій була використовувати відеозаписи, а замість звичайного телефонного спілкування – відеодзвінок, на якому було б ще видно whiteboard.

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

Коротше кажучи, одна з найбільш заслужених доповідей серед “keynote” (ключових).

Keynote by Dr. Alistair Cockburn at AGILEEE 2011 from AGILEEE on Vimeo.

“Challenging requirements” by Gojko Adzic

Непогана лекція про те, що ніколи не варто сприймати вимоги до ПЗ в тому вигляді, в якому вони приходять від замовника, а завжди докопуватись до самої сутності їх потреб – навіщо воно їм треба. Просто багато цікавих прикладів, причому не лише у сфері розробки ПЗ: найцікавішим був приклад про те, що F-15 Eagle, один з найуспішніших в історії винищувів, свого часу виграв тендер незважаючи на той факт, що він не виконав основну технічну вимогу – швидкість більшу за 2.6 махи. Інженери виявили основну причину цієї вимоги – радянські ракети літали зі швидкістю 2.6, тому більша потрібна була, аби мати можливість втекти від них – і замість того щоб робити як було написано у документі – зробили літак неймовірно маневреним. В результаті – виграний тендер і (судячи з Вікіпедії) жодного програшу в понад 100 повітряних дуелей. Отаке.

“Overcoming Self-organization Blocks” by Andrea Provaglio

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

Одна фраза, яка сподобалася багатьом присутнім: “In school if you copy you steal (you’re a bad guy). Is software if you copy you collaborate.” Говорилося це в контексті того, що поточна система освіти робить фокус на персональній, а не колективної роботі, обмежуючи останню і відкладаючи отримання одного з найважливіших практичних навичок у реальному житті на потім.

Andrea Provaglio “Overcoming Self-organization Blocks” from Agile Eastern Europe on Vimeo.

“Motivation 3.0 and Agile” by Danny (Danko) Kovatch

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

“Inside Iteration Zero: simple steps to make great products” by Nikita Filippov and Askhat Urazbaev

Ідея з story-mapping’ом та backbone (хребтом) проекту – це круто. Сама ідея з backbone витала в повітрі з самого початку, але я не знав навіть, що у неї є назва і більше того: є певні інструменти як її реалізувати.

Сама доповідь була подана так собі (ІМХО), та після неї я поліз в Інет шукати інфу про story-mapping і знайшов іншу, більш детальну і практичну презентацію від Паттона:

“Programmer Anarchy” by Antonio Terreno

На цій доповіді я не був, але проглянув презентацію – вельми цікаво. Дуже багато чого перекликається з модним нині Kanban і в певній мірі це мрія кожного манагера – вибудувати команду, яка буде настільки самоорганізованою, що він стає непотрібен Деякі речі звідси насправді з перемінним успіхом намагається прищепити нам наш department manager, але не всі ще розуміють чому це кльово і навіщо це потрібно. Шкода, що багато чого реалізувати в такому ключі не вийде із-за специфіки наших продуктів.

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

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

Під ОС Windows він знаходиться в домашній папці вашого користувача:

Для 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. Можливо мене якось проб’є зробити скрінкаст для наглядності, але це точно буде нескоро

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

Для людей які хоч трохи займались програмуванням відповідь має бути очевидною, але на всяк випадок нагадаю: під час роботи над чимось ви сто відсотків будете проходити якісь віхи розробки і контроль версій дозволить отримувати стан проекту на певний момент. Плюс можна створювати гілки розробки. Уявіть, що при побудові будинку ви вирішите добудувати якийсь незапланований поверх, але не впевнені чи все триматиметься як слід. Ви віртуально дублюєте поточний будинок, будуєте свій поверх, поки інші будівельники тим часом працюють по запланованому графіку. Потім ви вирішуєте, що результат вашої роботи вас влаштовує ви плеском в долоні вставляєте його у існуючий будинок. А може будівельники десь помилились при розрахунках і набудували якусь фігню, то вони можуть так само швидко відкотитись до місця коли щось пішло не так.
До речі, місце де зберігаютсья всі стани проекту в термінах 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-потік з додатками-картинками та відфільтрувати його по розмірам зображень, але про це я напишу вже іншим разом, ок?