Tag Archives: google

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 та влити туди свої правки 😎 Єдина поки що паршива вівця – це Twitter, який поки не підтримує другу версію, але благо перша там працює нормально.

OAuth2 server-side app flow
OAuth2 flow for server-side applications

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

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

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:

Google App Engine + Django

django-logo-negative

Powered by Google App Engine

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

По-перше, сама збірка Django. Я підбирав модулі частково експериментальним шляхом і щоб не прописувати все вручну постійно зробив собі простенький .bat-файл, який пакує в архів необхідну частину джанги:

"C:\Program Files\7-Zip\7z.exe" a django.zip
^ django\__init__.py
^ django\bin
^ django\core
^ django\conf
^ django\db
^ django\dispatch
^ django\forms
^ django\http
^ django\middleware
^ django\shortcuts
^ django\template
^ django\template\tags
^ 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

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

Google App Engine + Django

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

"C:\Program Files\7-Zip\7z.exe" a django.zip ^
django\__init__.py ^
django\bin ^
django\core ^
django\conf ^
django\db ^
django\dispatch ^
django\forms ^
django\http ^
django\middleware ^
django\shortcuts ^
django\template ^
django\templatetags ^
django\test ^
django\utils ^
django\views ^
django\contrib\__init__.py ^
django\contrib\contenttypes ^
django\contrib\localflavor ^
django\contrib\markup ^
django\contrib\sitemaps ^
django\contrib\humanize ^
django\contrib\formtools

Зібраний цим скриптом архівний файлик я підклав у корінь новоствореного GAE-проекту. Причому пакування в архів тут робиться не задля економії дискового простору. Просто у App Engine є обмеження на кількість файлів, а в проекті Django їх дуже багато. Тепер залишилась справа за малим: підмінити Django що йде у комплекті з GAE на нашу версію, яку ми завантажимо з архіву за допомогою фічі zipimport. Тут все досить просто (це мій поточний варіант скрипта, але думаю без якихось проблем має запрацювати і той, що виклдаений на офіційній сторінці інтеграції GAE та Django):

#!/usr/bin/env python
# main.py

import os, sys, logging
os.environ["DJANGO_SETTINGS_MODULE"] = "projectname.settings"

# Google App Engine imports.
from google.appengine.ext.webapp import util

# Uninstall Django 0.96.
for k in [k for k in sys.modules if k.startswith('django')]:
    del sys.modules[k]

# Add Django 1.0 archive to the path.
django_path = 'django.zip'
sys.path.insert(0, django_path)

# Force Django to reload its settings.
from django.conf import settings
settings._target = None

import django.core.handlers.wsgi
import django.core.signals
import django.db

def log_exception(*args, **kwds):
    logging.exception('Exception in request:')

# Log errors.
django.core.signals.got_request_exception.connect(log_exception)

# Unregister the rollback event handler.
django.core.signals.got_request_exception.disconnect(django.db._rollback_on_exception)

def main():
    # Create a Django application for WSGI.
    application = django.core.handlers.wsgi.WSGIHandler()

    # Run the WSGI CGI handler with that application.
    util.run_wsgi_app(application)

if __name__ == "__main__":
    main()

Але найцікавіша частина над якою я намучився найбільше – це налаштування файлу settings.py в самому Django. По-перше, треба повідключати модулі зав’язані на Django ORM, тобто видалити або закоментити Middleware-класи:

django.contrib.sessions.middleware.SessionMiddleware
django.middleware.csrf.CsrfViewMiddleware
django.contrib.auth.middleware.AuthenticationMiddleware
django.contrib.messages.middleware.MessageMiddleware

NOTE: SessionMiddleware варто замінити на той, що йде у комплекті з gaeutilities – тоді ви принаймні зможете скористатись портованим аналогом сессій.

Контекст-процесори:

django.contrib.auth.context_processors.auth
django.contrib.messages.context_processors.messages

Та додатки:

django.contrib.auth
django.contrib.sessions
django.contrib.sites
django.contrib.messages

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

USE_I18N = False

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

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

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-потік з додатками-картинками та відфільтрувати його по розмірам зображень, але про це я напишу вже іншим разом, ок? 🙂

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

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-потік з додатками-картинками та відфільтрувати його по розмірам зображень, але про це я напишу вже іншим разом, ок? :)

Українська перевірка правопису для 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.

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

Отже вам теж хочеться мати гарненьку перевірку правопису в Хромі? Нема нічого простіше: качаємо файл з даними для програми перевірки:

Download: Український орфографічний словник для Chrome  Український орфографічний словник для Chrome (1,5 MiB, 10 465 hits)

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

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

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

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

Теми в Gmail – що далі?

Сьогодні в GMail 2 з’явилася підтримка тем. Причому деякі теми змінюються в залежності від часу дня та погоди на вулиці, для чого при виборі нової теми пропонують вказати місцезнаходження. Це значно збільшить і так значну інтерактивність Гугловської пошти.

Ось, наприклад, як виглядає тема “Пляж” в той же час для Бостнону та Києва.

Read more »

Тепер і Яndex тебе знайде!

… Щоправда, тільки якщо ти поставиш собі на мобільний чи смартфон нову версію мобільної Яндекс.Карти.

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

Оновив недавно на смарті  Яндекс.Карту, а вона після завантаження першим ділом показала моє місцезнаходження. Загалом тестував в мережах Київстару, МТС та Білайну – працює коректно, точність визначення місцезнаходження в Києві – залежно від місця та мережі 100-5000 метрів. В Білайновській мережі в деяких місцях показує точніше, ніж гугловська (там, мабуть, база “зсунута” на одну вишку використовується – показує сусідню соту).

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

З українських доступні карти Києва, Дніпропетровська, Донецька, Запоріжжя, Львову, Одесси, Харкова та Криму.

Щоб і собі отримати таке чудо на телефон, перейдіть з мобільного за адресою m.ya.ru/ymm або по бар-коду справа. Модель телефону в більшості випадків визначається автоматично.