Tag Archives: Мережі та ІТ

Проблема з програмістами, що “вище середнього”

Liaoning School by kattebelletje

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

Примітка: тим хто читав або чув про чудову книжку “Pragmatic Thinking and Learning” деякі твердження можуть здатися протиріччям, але це не так. Поняття експерта там дещо ортогональне тому що описано тут, плюс там теж згадується про пастку “спочивання на лаврах”.

Оригінал: The Problem With ‘Above Average Programmers’
Автор: Dave Rodenbaugh

Швидко! Дайте відповідь на наступне питання не роздумуючи:

Як би ви оцінили ваші навички з програмування? (Нижче середнього, Середнє, Вище середнього)

Психологічні досліди проведені в різних групах показали, що більше 90% всіх програмістів вважають свої навички “Вище середнього”.

Як ви розумієте, так бути не може. Грубо кажучи, в групі зі 100 людей 50% вище середнього, а 50% — нижче. Цей ефект відомий в психології як “Ілюзія переваги”. Його спостерігали та задокументували у багатьох областях, і навіть знаючи про цей ефект ви ймовірно все одно дасте відповідь “Вище середнього”.

Сміху заради спробуйте спитати це у кожного знайомого вам програміста. Не питайте їх у групі, питайте один-на-один щоб отримати більш “чесну” відповідь. Ви отримаєте схожі результати навіть від людей, які не знають як запрограмувати щось дійсно нетривіальне (насправді це ефект Даннінга-Крюґера, але вони пов’язані). Це епідемія нашої професії.

А тепер уявіть на хвилинку, що ви і справді “вище середнього”. Просто мужик! Рок-зірка. Бог поміж смертних. Клави схиляються в реверансі, коли ви проходите поруч, а труби грають туш, коли ви комітите на Github.

Якщо ваші знання вище середнього, то ви експерт в тому що ви робите. Називати себе експертом дуже приємно — ви здобуваєте повагу, шану та престиж будучи ним.

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

Натомість, чому б не розглянути іншу можливість? Ви — середняк, або (боже збав!) нижче середнього. Окрім пораненої гідності, яку ви можливо будете переживати, подумайте про справжні переваги:

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

Можливо ви чули про “розум початківця”? Короткий його зміст сказаний майстром Дзену з типовою лаконічністю коану:

В голові початківця є багато можливостей, в голові експерта є лише кілька.

Пастка самоназви себе “експертом” в розробці софту означає, що ви запираєте себе у певну мову (Java, Ruby, PHP), певну сферу (медичні пристрої, соціальні мережі, ігри), певну спеціалізацію (embedded, enterprise, тощо). Коли ви напрацюєте цей досвід, вас буде переслідувати страх помилки, коли ви вийдете за свою зону комфорту. Зі своїм золотим молотом досвіду все навкруги здаватиметься цвяхом. Ви не будете думати про викрутки та інші адекватні інструменти оскільки ви про них не знаєте, або не вмієте користуватись.

Саме тому починаючи новий software-проект ви часто дивуєтесь чому “досвідчені програмісти” не можуть взяти X, ви ж вивчили X всього за кілька днів. X може бути чим завгодно: замикання, об’єктно-орієнтоване програмування, фреймворк Ruby on Rails, програмування на Haskell. Врешті-решт, це не має ніякого значення, голова експерта забита застарілими знаннями. Голова початківця відкрита та вільна від перепон.

Коли ви експерт, вчитися важче. Тому бути “досвідченим програмістом” небезпечно.

Тож яка ж першочергова річ, яку можуть зробити програмісти? Почати з того, аби вважати свій рівень нижчим середнього. Вийти за зону комфорту. Бути “найсереднішим”.

Маестро ніколи не перестає вчитись, і ви не переставайте також.

Must have для сучасних IDE та редакторів

LightTable LogoНаразі у мене є два улюблених редактори для коду: Sublime Text та LightTablevim, хоч любові до гробу не склалося, оскільки я в чистій консолі не так часто працюю, але він теж гарний). Про перший зараз мабуть не знає лише лінивий. У нього багато всяких крутих можливостей для редагування, плюс він дуже круто розширюється завдяки масі доступних плагінів. Але! Все те, що зараз пропонує Саблайм — це необхідний мінімум, без якого я вже не уявляю комфортної роботи, тому на цьому питанні я зупинятись не буду. Набагато цікавіше жити днем завтрашнім і оцінити куди надалі розвиваються редактори. А для того, аби оцінити це, прошу переглянути відео “Inventing on a Principle” (“Винаходячи за принципом”). Його, я впевнений, багато хто вже бачив, тому перепрошую за повторення, можете одразу читати далі. Хто не бачив — обов’язково подивіться. Причому тут його показано не лише для програмування, а й інших сфер як-то радіоелектроніка, обробка відео, тощо. Дуже цікава штука, насолоджуйтесь (до речі, у кого проблеми з англійською — там є російські субтитри):



LightTable concept screenshot Але то все концепт… Гарна ідея, але (мабуть) не тривіальна в реалізації, і невідомо коли ми вже зможемо використати щось подібне в реальній роботі. Чи відомо? Насправді розробники вже можуть помацати перші реалізації цієї ідеї за допомогою LightTable. LightTable наразі єдина робоча реалізація про яку я знаю, тому якщо існують інші — скажіть, я хочу спробувати ;) Про цей редактор я дізнався суто випадково, коли копав більше інформації про Clojure (власне LT написаний на Clojure і це була перша мова яку він підтримував). Звісно, там все не настільки аж неймовірно як у відео вище, але все ж JavaScript’овий приклад, який зробили з виходом версії 0.4 уже вражає:

Згодом з’явилась ціла серія відео про використання ClojureScript в LightTable в аналогічному стилі. Перше відео тут, далі по списку в Related на Ютюбі.

Звісно, в реальному житті все не настільки райдужно: в LightTable поки нема багатьох можливостей, до яких я вже звик в Sublime Text, тому у більшості випадків я не можу повністю перейти на нього. Плюс справжня real-time розробка наразі є лише для JavaScript, ClojureScript та, в принципі, Clojure. Для останньої та для Python є підтримка трохи простішої, але теж корисної фічі inline evaluation: це REPL прямо у вікні редактора — кльова фіча, я постійно нею користуюсь. Хоча насправді подібна штука не нова і є навіть в Visual Studio 2010 — це інтерактивна консоль для F# (можна подивитись приклад роботи тут).

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

OAuth2 logo

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

OAuth2 server-side app flow

OAuth2 flow for server-side applications

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

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

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

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

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

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

meditation

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

TortoiseHG

Минулого разу я вже оглядово ознайомив вас із основними принципами роботи з 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.

TortoiseHG. Create repo

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

TortoiseHG. Create repo window

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

TortoiseHG. Initial commit

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

TortoiseHG. Ignore list

Там в лівому списку видно поточні рядки для ігнору, а справа – файли які проходять фільтрацію (тобто неігноровані). Ваша задача скласти список виразів для ігнорування, щоб в правому списку залишились лише корисні файли (але всі :) ). Фільтри можна задавати або як регулярні вирази (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. Shelve

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

TortoiseHG. Repository explorer

Просимулювати це можна дуже просто. У контекстному меню каталогу вибираєте 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 робиться виключно в робочій папці як активні зміни).

TortoiseHG. Merge

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

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

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

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

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

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

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

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

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

Працюємо з Mercurial

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

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

  • якщо він існує на іншому комп’ютері чи сервері і тоді вам треба виконати команду clone:
    $ hg clone http://path/to/your/repository

    вона створить копію репозитарію з вказоного URL в поточному каталозі

  • якщо ви створюєте новий проект, то потрібно виконати команду init в папці з проектом:
    $ hg init

    потім додати всі потрібні файли командою add:

    $ hg add

    Увага! У вас в каталозі можуть бути файли, які не варто зберігати: наприклад, “.obj”-файли C++ чи Пітонівські “.pyc”.
    для цього в кореневій папці (на одному рівні з папкою “.hg”) треба створити файл .hgignore з вмістом типу:

    glob:*.bak
    glob:*.obj
    glob:Debug
    glob:Release

    і так далі… Можна також прописувати не лише файли, а і цілі каталоги (Debug та Release в прикладі вище).

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

$ hg commit

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

  1. була деяка початкова ревізія №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. Але це я залишу на наступний раз.

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

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

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

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

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

Бекап і онлайн-синхронізація даних. Dropbox

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

Отже, Dropbox. Це проект випускників Массачусетського Технологічного Інституту, основна мета якого – забезпечити швидку і прозору синхронізацію даних між кількома комп’ютерами та резервне копіювання даних. При цьому значна увага приділяється мінімізації об’єму даних, що пересилається через Інтернет. Після встановлення клієнтського додатку Dropbox (до речі, він існує для як для Windows і Mac так і для Linux) один з каталогів на вашому HDD починає синхронізуватись з серверною частиною. Для цього у MS Windows в “Моїх Документах” автоматично створюється відповідна папка “My Dropbox” і способу змінити це розташування я не знайшов примітка. Як з цим справи в інших ОС – не знаю. Файли починають синхронізуватись практично одразу після того як ви там щось створите чи скопіюєте. При першому завантаженні, звісно, пересилається повна його версія, але при наступних його модифікаціях у гру вступає механізм “binary diff”, який робить порівняння поточної і серверної версії файлів і потім на сервер відправляється лише цей diff-файл, завдяки чому оптимізується використання вашого інтернет-каналу. Якщо я правильно розумію то їх копії серверних файлів для порівняння лежать у відповідному каталозі в Application Data, тому зважте, що при використанні Dropbox папка синхронізації фактично займатиме подвійний об’єм нам диску. Після того як ви внесете зміни у файл і ці зміни відправляться на сервер, той у свою чергу повідомить інші клієнти (звісно, якщо у вас декілька комп’ютерів включеним Дропбоксом) і ті негайно оновлять свої копії, що дуже зручно. Дані на сервер передаються безпечно (по SSL протоколу) і зберігаються у зашифрованому по алгоритму AES-256 вигляді.

От і все, що стосується фіч клієнтської частини. Що ж пропонує нам саме сховище? На сервері всі ваші файли в свою чергу підлягають контролю версій в чомусь подібному тому, який використовуються у програмуванні. Але для тих, хто далекий від цього поясню: наприклад, ви створили якийсь документ і він попав на сервер. Відповідно це і є версія (або інколи ще кажуть ревізія) “1″ цього файлу. Потім ви зробили в ньому якісь зміни і він знову попав на сервер. З одного боку це той самий документ, але з іншого його вміст відрізняється від попереднього. Таким чином це буде той же файл з версією “2″. І так далі… Суть будь-якої системи контролю версій в тому, що ви в будь-який момент можете отримати файл в практично будь-якому з його збережених проміжних станів і якщо ви внесете якусь помилку, то можна буде потім відкатитися до того його стану, коли її ще не було. Завантажені папки можна розшарювати і таким чином декілька користувачів Dropbox можуть мати спільну синхронізовану папку. Крім того, за допомогою Dropbox можна легко організовувати онлайн-фотоальбоми типу ось такого, який я завдяки Дропбоксу створив за 5-10 секунд :) Правда, враховуючи обмеження в 2GB я б все-таки не став його використовувати саме з цією метою ;) Через веб-інтерфейс можна також робити операції з файлами (додавання/переміщення/переіменування/видалення), але не дуже зручно.

Ну і найголовніше: скільки це щастя коштує? А ніскільки. Щоправда в безкоштовній версії Дропбоксу вам у розпорядження дається всього 2GB простору (що все-таки немало), але за 9.99$ в місяць, або 99$ в рік об’єм можна збільшити до 50GB.

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

От. Щодо мене, то хоч я і знайшов деякі інші аналогічні і в чомусь кращі служби онлайн-бекапу (про які я розповім якось пізніше), але для синхроніхації файлів на різних машинах я продовжуватиму використовувати Dropbox, бо я до нього вже звик і саме з початком його використання мну фактично перестав носити флешки на роботу, адже щось важке (>100MB) я тягаю досить рідко, а все, що менше я просто кидав в синхронізовану папку і приходячи додому без зайвих рухів вже мав цей файл на домашньому комп’ютері і навпаки.


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

Українська перевірка правопису для Google Chrome

Увага! Ви можете зробити перевірку орфографії у Хромі доступнішою, якщо поставите зірочку навпроти відповідного тікета у багтрекері Хрому. Якщо назбирається достатньо велика кількість голосів, то ми зможемо переконати Google додати рідну підтримку української в браузер і таким чином вирішиться проблема перевірки орфографії обох мов.

Історія створення

Нещодавно мені набридло користуватись глючними Google Docs‘ами лише для наявної там перевірки орфографії і я помітив, що Chrome в полях вводу сам підсвічує неправильно написані англійською слова. Я подумав: “Якого дідька англійською? Включу українську і не матиму клопоту.” Зайшов у “Параметри” > “Маленькі підказки” > “Змінити налаштування шрифту та мови” > “Мови” і там в полі “Мова програми перевірки правопису” не знайшов української. WTF? Що за дискримінація? Але фіг з ним, завжди можна скачати словники і замінити одну з наявних мов… і тут-то мене чекало друге розчарування: Хром хоч і використовує словники від hunspell (це юнікодовий нащадок myspell), але вони там не у первозданному вигляді, а в сконвертованому у власний бінарний формат, що має розширення bdic. Ну, що робити? Доведеться, думаю, шукати конвертер (він називається convert_dict.exe). Бінарів на мій превеликий подив не було абсолютно ніде, але сорс досить швидко знайшовся в самому SVN-репозиторії Хрому. Мну зрадів та сходу злив лише сорс самої тулзи, але щастя тривало недовго… У цього крихітного конвертера виявилося стільки залежностей, що через годину підтягування їх по черзі я зрозумів, що це процес нескінченний і мені доведеться зливати весь Хром. Поставив качатись весь trunk (ще й інет був у мене в той вечір звіздєц який хєровий і качалось все дуууже повільно) і вирішив все-таки посьорфитись трохи на предмет існуючої збірки. І мої старання були винагороджені: zedlik з Білорусі буквально за три дні до мене зіткнувся з тією ж самою проблемою створюючи перевірку орфографії для білоруської і вже пройшов всі ті етапи збирання, які чекали не мене. “Ура!”, подумав я і недовго думаючи попросив поділитись бінарем, а він в свою чергу не відмовив. Далі вже все справа техніки. Остання перепона на шляху до мети полягала в тому, що convert_dict ну ніяк не бажав конвертувати скачані з офсайту hunspell словники української у кодуванні KOI8-U, але швидкоруч написаний менш ніж 10-рядковий скрипт на пітоні чудово сконвертував його в UTF-8, який вже схавав той нещасний convert_dict.

Інструкція по експлуатації

Отже вам теж хочеться мати гарненьку перевірку правопису в Хромі? Нема нічого простіше: качаємо файл з даними для програми перевірки:
Note: There is a file embedded within this post, please visit this post to download the file.

На назву файлу не звертайте уваги – це українська, а не російська орфографія – я залишив її такою для зручності встановлення. Копіюємо його в папку:

C:\Documents and Settings\<username>\Local Settings\Application Data\Google\Chrome\Application\Dictionaries

замінивши при необхідності існуючий ru-RU-1-1.bdic (до речі, можете його і збекапити на всяк випадок) та в налаштуваннях виставити російську перевірку орфографії. Все :)