Мережі та ІТ

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

З давніх давен мене завжди харила необхідність реєстрації на сайтах. Чесно. Причому не з якихось там параноїдальних міркувань (мене це дуже мало бентежить), а банально: знову вводити ім’я користувача, придумувати пароль, тощо… І тому коли треба реєструватись на комусь сайті доводиться через стандартну логін/пароль/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 ще не затверджено остаточною. Існує кілька його драфтів і всі використовують свої власні інтерпретації. Але за рахунок його простоти складність правок під конкретну реалізацію зазвичай є справою перевизначення пари методів. Причому насправді відмінності дуже тупі. Вконтакт повертає JSON-відповідь із “зайвим” рівнем вкладеності, Гугл вимагає авторизувати токен через POST-запит, а Фейсбук повертає результат не в JSON, а в urlencoded query string

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

---

Garage48, Startup Mixer, DOU Hackaton і всі, всі, всі…

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

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

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

---

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

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

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

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

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

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

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

Read the rest of this entry »

---

Agile Eastern Europe. Season 3

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

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

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

Read the rest of this entry »

---

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

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

Read the rest of this entry »

---

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

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

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

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

Read the rest of this entry »

---

Google App Engine + Django

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

Read the rest of this entry »

---

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

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

Read the rest of this entry »

---

Google JS API

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

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

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

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

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

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

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

---

Пишем GUI з wxWidgets. Підготовка

Отож, як і обіцяв, вирішив почати потроху описувати свій досвід освоєння цього GUI-фреймворку. По-перше пара слів про сам wxWidgets. Це вже досить старий і тому стабільний і потужний фреймворк для розробки графічних інтерфейсів. Він кросплатформенний (є версії для Windows, Linux, MacOS та кількох інших, навіть для OS/2) і доступний у варіантах для декількох мов програмування (наприклад, C++, Python, Perl, C#, тощо). Як заявляють розробники прямо на головній сторінці сайту, основною особливістю їх фреймворку є те, що він повністю базується на “рідних” для того чи іншого середовища контролах, а не емулює їх, як робить більшість інших кросплатформенних GUI-бібліотек. За рахунок цього бінарний код виходить дуже компактним, а графіка виглядає природно для відповідної системи. Отака цікава штука. Трохи забігаючи наперед скажу, що, wxWidgets, звісно, не такі приємні в розробці як Qt (там взагалі просто сідаєш і пишеш – настільки логічно все побудовано, а кращої документації я ще не бачив ні до чого), але водночас після декількох днів роботи з ним він мені починає подобатись все більше і більше.

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

Read the rest of this entry »

---