Author Archives: graywolf

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

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

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

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

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

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

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

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

[ui]
username = graywolf
merge = winmergeu

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

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

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

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

[tortoisehg]
vdiff = winmerge

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

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

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

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

$ hg push projectname

замість

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

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

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

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

extension = path_to_extension

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

TortoiseHG

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Працюємо з Mercurial

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

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

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

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

потім додати всі потрібні файли командою add:
```
$ hg add
```
Увага! У вас в каталозі можуть бути файли, які не варто зберігати: наприклад, “.obj”-файли C++ чи Пітонівські “.pyc”.
для цього в кореневій папці (на одному рівні з папкою “.hg”) треба створити файл .hgignore з вмістом типу:
```
glob:*.bak
glob:*.obj
glob:Debug
glob:Release
```
і так далі… Можна також прописувати не лише файли, а і цілі каталоги (Debug та Release в прикладі вище).

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

$ hg commit

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

була деяка початкова ревізія №1, яку для подальшої роботи стягнули два розробники
обидва щось поправили і один був першим, хто закомітив зміни на сервер, і з’явилась ревізія №2
другий спробував закомітитись, але сервер відмовив, вказавши що не може залити зміни поверх версії №1. Тому другий розробник має забрати собі версію №2 з репозиторія та об’єднати (або як часто кажуть “змерджити” від англомовного терміну merge) докупи зміни з ревізії №2 та свої власні правки. Часто це проходить автоматично, але буває, що треба ручна правка, коли зміни торкаються однакових фрагментів коду. Потім об’єднаний код можна комітити в репозиторій і так з’явиться ревізія №3

Таким чином у централізованих системах є лише одна “головна” ревізія, а самі ревізії йдуть одна за одною. Ось так це виглядає схематично:

У розподілених систем нема центрального сервера, а всі коміти йдуть локально, тому типовий приклад роботи з ними наступний:

є центральний хаб з якого два розробники забирають єдину ревізію №1
обидва роблять правки та локальні коміти, таким чином і у першого, і у другого на комп’ютері з’являється по дві ревізії: загальна №1 і у кожного власна №2
вони обидва синхронізують свої копії зі спільним репозитарієм і в результаті на спільному репозиторії з’являється три ревізії: №1, №2 та №3. Таким чином утворилося дві “головні” ревізії №2 та №3.
один з розробників знову синхронізує репозиторій і у нього з’являєтясь копія спільного. Він може оновити локальну копію до однієї з головних ревізій і продовжити роботу в цій “підгілці”, а може об’єднати (змержити) зміни з №2 та №3 і закомітити їх як ревізію №4: таким чином граф ревізій утворить ромб.

Синхронізація в Mercurial однонаправлена: тобто за одну операцію можна або залити свої ревізії у віддалений репозиторій (операція push), або отримати звідти ревізії у свій локальний (операція pull).

$ hg pull http://path/to/your/repository $ hg push http://path/to/your/repository

Поки що це вся теоретична частина. Якщо ви працюєте під ОС Windows, то життя собі можна значно полегшити, якщо поставити собі TortoiseHg – графічний фронт-енд для роботи з Меркуріал. Плюс роботу можна зробити зручнішою та розширити потужність системи поправивши конфігураційний файл Mercurial. Але це я залишу на наступний раз.

Google App Engine + Django

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

if __name__ == "__main__":
    main()

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

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

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

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

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

Та додатки:

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

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

USE_I18N = False

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

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

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

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

Posted by graywolf on 10.02.2009 Прокоментуй!

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

Posted by graywolf on 03.02.2009 1 коментар

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

Цікава новина від Brainbench

Posted by graywolf on 28.08.2008 Прокоментуй!

Щойно отримав листа від Brainbench в якому повідомляється про 85% знижку на річну підписку (annual subscription) на їх тести. Тобто рік фактично необмеженого (єдине, що не можна – це отримати від них друкований сертифікат) користування їх тестами коштуватиме лише 30$. Як на мене, то це майже халява Пропозиція діє до 15-го вересня і для обмеженої кількості країн: Латвія, Литва, Малайзія, Пакістан, Румунія, Росія, Україна, Узбекістан, В’єтнам. Більш детально можна дізнатись на їх сторінці присвяченій цій акції.

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

Інтернет початку XXI сторіччя. Lifestreaming або соціальні агрегатори

Posted by graywolf on 14.08.2008 2 коментарі

Те, про що піде мова сьогодні, являється однією з найсмачніших інтернет-новинок, які принісли останні роки. Хоча, звісно, ці сервіси не з’явилися б не будь всих попередніх, які я вже згадував в рамках цього циклу статей: мікро- та звичайних блогів, соціальних мереж, соціальних новин, контент-хостерів, тощо. Зате вони ставлять зручність користування цим всим на інший рівень і відкривають деякі нові можливості. Ідея соціальних агрегаторів проста: вони збирають інформацію про вашу активність в мережі та подають її одним змішаним потоком. З’явилася вона порівняно недавно, коли у вжиток увійшло поняття “мережевої втоми” (“network fatigue”), одним з елементів якої вважається необхідність реєструватись на та відвідувати купу сайтів для того, щоб відстежувати, що роблять або чим цікавляться ваші “друзі” (в лапках, бо мається на увазі в мережевому сенсі) на різних сайтах та мережах. Тобто поясню на прикладі: ваш друг публікує фотки за допомогою Google Picasa, розшарює новини через Google Reader, пише щось в персональний блог, користується мікроблоггінгом і т.д., і т.п. Для того, щоб бути в курсі останніх змін вам треба або періодично заходити на всі ці сайти аби перевірити чи не з’явилось що новеньке (те ще збочення, погодьтесь), або підписатись на відповідну RSS (благо, всі сучасні сайти дозволяють це зробити). Фактично більшість соціальних агрегаторів типу Plaxo Pulse, Iminta та інших лише це і роблять — просто збирають інформацію докупи. Хоч і не завжди все через RSS — часто через API відповідних сервісів, які надають більше можливостей, завдяки чому ці сервіси все ж більш гнучкі й потужні, аніж просто купа RSS. Та все одно це занадто примітивно і… несоціально Якось по-дурному виходить: служба агрегації соціальних сайтів сама не є такою. Тому я цього разу відійду від попередньої практики опису декількох конкуруючих ресурсів і зупинюсь на тому, який вважаю безсумнівним лідером в цій сфері, який залишив інших далеко позаду. Мова піде про FriendFeed — стартап, який був розроблений не ким-небудь, а колишніми співробітниками компанії Google, що займали там далеко не останні позиції.

Отож, як писалось вище, основна робота ФрендФіду збирати докупи вашу активність в Мережі. Там є певний набір сервісів, що підтримуються на рівні API, а все інше можна при бажанні додати як підписку типу “Блог” (насправді це не обов’язкоко має бути блог – це скоріше звичайний RSS-агрегатор), вказавши відповідну RSS-стрічку. Таким чином ви реєструєте свою активність з різних сайтів у ФФ, а інші користувачі, кому цікава ваша персона, в свою чергу можуть підписатися на стрічку з нею. Величезна кількість підтримуваних сервісів (див. скріншот) вже зараз вирізняє його з-поміж конкурентів, але не лише цим він цікавий.

По-перше, там є можливість коментувати цю активність (буває такі розгортаються суперечки, що блоги відпочивають ) та додавати в “Улюблене”. І коментарі там — це не просто данина моді, а дуже зручна річ, коли вам хочеться прокоментувати активність на якомусь сервісі, де ви не зареєстровані. Для мейнстрімових речей є можливість “зворотного зв’язку”. Наприклад, коментарі до дописів в Twitter’і можна відправляти теж як твіти-відповіді (звісно, для цього вже треба бути зареєстрованим на відповідному сайті, але принаймні заходити на нього не треба та й виглядає обговорення зручніше). Щодо додавання у Favorites, то тут теж прикольно зроблено: з транзитивністю операції. Тобто, наприклад, користувач A читає користувача B, а B в свою чергу — C, але A нічого не знає про C, та коли користувач B додає в “Улюблене” щось зі стрічки C, то це попадає і в загальний потік користувача A, що останньому дуже і дуже зручно, бо в “Улюблене” зазвичай додають дійсно цікаві і варті уваги речі.

По-друге, можна відслідковувати активність людей не зареєстрованих на FriendFeed’і. Для цього є механізм “уявних друзів” (imaginary friend), коли ви додаєте чиюсь активність до ФФ по аналогії зі своєю власною, але використовуючи його логін чи то ідентифікатор при додаванні контенту, але ця активність не відмічається як “ваша”.

По-третє, зручний пошук. Здавалося б така дрібниця, але деякі агрегатори і цього не мають. До речі, я часто використовую FF для пошуку по прошарених дописах в Google Reader, бо він зберігає shared та starred записи лише впродовж одного місяця.

По-четверте, є тут така штука як “кімнати” (це одне останніх же нововведень), тобто своєрідні тематичні стрічки, в певному сенсі аналоги спільнот.

По-п’яте, в стрічка вашої активності може наповнюватись не лише автоматично із соціальних мереж, або RSS. Можна і просто залишити повідомлення, посилання на зовнішній ресурс чи картинки вручну — потрібно лише перетягти на панель відповідну “кнопку”.

Ну і ще багато всього. Його розробники подумали про багато приємних дрібниць. Припустимо, якщо ви довго не мали доступу до Інтернету, а “друзів” у вас багато, то у FF є спеціальний режим перегляду “найцікавіше за день/тиждень/місяць”, коли не потрібно буде перечитувати по декілька сторінок інформації, далеко не вся з якої може бути вам цікава, а так можна вже одразу відфільтрувати. Звісно, як і у кожного поважного стартапу у нього є API, завдяки чому було розроблено масу додатків. В тому числі з того чим я активно користуюсь: AIR-клієнт Alert Thingy (з підтримкою публікації не лише у FriendFeed, а також в Twitter та Flickr) та плагін-віджет для WordPress.

Мну особисто завдячує ФрендФіду як одному з джерел цікавої інформації за рахунок його системи обміну цікавинками, а з іншого – економією часу на відвідуванні інших сайтів (фактично останнім часом ранковий перегляд новин звівся до перегляду FF-стрічки, пари форумів та інколи Google Reader; останній рідко, бо досить багато часу витрачається). До речі, цікаво що активно викорситовувати я його став лише через кілька місяців після реєстрації. Тоді навіть знаючи про нього багато з того, що написано вище я не розумів навіщо його потрібно. А зараз це один з основних сайтів на які я заходжу. Отаке.

Мобілізуємо блог

Posted by graywolf on 07.08.2008 6 коментарів

Ні, не в армію ми його будемо мобілізувати, а всього-на-всього зробимо придатним для відображення на маленьких екранах мобільних телефонів за допомогою одного цікавого стартапу під назвою MoFuse. Про потужність і надійність сервісу говорить той факт, що його використовують такі не останні в Інтернеті сайти як ReadWriteWeb, ReadBurner, Mashable та багато інших. Завдяки ньому можна зробити гарну мобільну версію вашого блогу всього за кілька хвилин, що я зараз і постараюсь більш-менш детально описати. Тож запускайте секундомір і починемо.

Реєстрація

Звісно, без неї нікуди. Зробити це можна прямо з головної сторінки сайту. І я б не згадав про неї, якби не одне але: звертайте увагу на коректне заповнення поля Login (ним виступає e-mail адреса)! Справа в тому, що MoFuse не перевіряє її і тому там випадково можна ввести неправильну інформацію, що я вже і встиг зробити вранці, а потім ввечері довго не міг зайти — довелося порпатися в кеші Опери та шукати щось таке, що могло б наштовхнути на правильну адресу. Благо, таки знайшов — виявилось, що я пропустив літеру “L” при написанні домену gmail.com Так що будьте уважними.

Запускаємо мобільний сайт

Увійшовши до MoFuse в панелі керування вибираємо “Launch a mobile site”. Там вам необхідно буде заповнити декілька полів типу назви сайту, вибрати його майбутню адресу (у вигляді <ваша назва>.mofuse.mobi), а також вказати RSS-джерело для наповнення сайту. Їх може бути декілька, при створенні вказується основне, а можна взагалі пропустити цей пункт поставивши відповідну галочку — це якщо ви збираєтесь зробити статичний сайт, або плануєте додати джерела пізніше. Але так як ми домовились мобілізовувати блог, то RSS нам прописати просто необхідно. Власники standalone-блогів, думаю, знають адреси своїх RSS-стрічок. Користувачі LiveJournal мають прописати туди щось типу: “http://<нікнейм>.livejournal.com/data/rss“, а користувачі Blogger відповідно: “http://<нікнейм>.blogspot.com/feeds/posts/default“.

Професійним блоггерам варто звернути увагу на галочку “You’ve read and agree to our Revenue Sharing Policy”. Мова тут йде про те, що у сайту є фіча монетизації мобільного сайту шляхом додавання туди реклами Google AdSence або AdMob, але прибуток від реклами ділитиметься між вами та MoFuse 50/50.

Ну і все. Натискаєте “Launch Your Mobile Site” і вуа-ля: ви маєте свій блог в мобільному Інтернеті, доступним за адресою, яку вказали в полі “Site ID (URL)”. Якщо ви перейдете по тій лінці в звичайному браузері, то побачите емулятор вікна звичайного мобільного телефону, або Apple iPhone, в якому можна оцінити як виглядатиме ваш сайт на мобільному телефоні.

Прикрашання та контент

Але залишати сайт в такому вигляді нецікаво, адже MoFuse має ще багато цікавих можливостей гнучкого налаштування. Наприклад, власники свого доменного імені можуть зробити мобільний сайт його піддоменом (є неформальна практика робити мобільний домен у вигляді m.>назва основгого сайту<, тобто щось типу m.graywolf.org.ua). Також можна налаштувати кольорову гаму сайту та завантажити власний логотип.

Далі можна додати якийсь текст на стартовій сторінці сайту, додати нові джерела для RSS, статичні сторінки, зовнішні посилання та віджет для коментарів, але з цим ви вже можете поекспериментувати самостійно

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

Інтеграція та просування

Але і це ще не все. Погодьтесь, потенційним користувачам не зручно пам’ятати адреси вашого і мобільного блогу, і повноформатного. Для того, щоб уникнути цього можна скористатись пунктом “Automatic redirect”. Там знаходиться шматок PHP-коду, який потрібно вставити в код вашого сайту і який здійснюватиме перенаправлення на мобільну версію, якщо ви заходитимете з мобільного телефону. На жаль цією фічею зможуть скористатись лише власники standalone-блогів. Наприклад, користувачі WordPress можуть вставити цей код на початку файлу теми, що відповідає за заголовок. Тим же хто користується блогхостингами типу Blogger та LiveJournal можна скористатись пунктами “Mobi Badge” та “QR Code”. В першому ви можете вибрати симпатичну картинку з посиланням на ваш мобільний блог та вставити її код потім в профілі чи ще де. Другий генерує картинку з QR-кодом для швидкого зчитування лінки в мобільним телефоном (якщо ви досі не знаєте, що таке QR-коди, то гарний лікбез є тут).

Післямова

Ну от і все. Просто, правда ж? Насправді зараз здається, що нікому зараз мобільні сайти не потрібні, але, ІМХО, варто призвичаїтись до світових тенденцій якомога раніше. В багатьох передових країнах мобільний Інтернет майже не поступається по популярності, а в деяких (наприклад, в Японії) навіть перевищує “стаціонарний”. Та й на Заході з появою iPhone‘ів та в очікуванні виходу пристроїв з Google Android на борту, йде справжній бум мобільного Інтернету і, впевнений, що не так вже багато часу займе поки ці хвилі дійдуть і до нас.

Інтернет початку XXI сторіччя. Сервіси закладок та новин

Posted by graywolf on 06.08.2008 2 коментарі

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

І все-таки спочатку ми проговоримо про власне служби закладок. Типовими представниками яких є Delicious та Opera Link.

Соціальні закладки

Opera Link. Цей сервіс – елемент порталу My Opera і відповідно доступний лише користувачам веб-браузера Opera починаючи з версії 9.5 і призначений суто для віддаленого збереження посилань, що дозволяє синхронізувати закладки між різними екземплярами браузера встановленими, наприклад, на домашньому та робочому комп’ютері. Хоча соціальним його назвати складно, адже створені вами закладки, на жаль (а може і на щастя) доступні лише вам.

Google Bookmarks. Практично в усьому це аналог Лінку, але з підтримкою бразуерів Firefox та Internet Explorer за допомогою Google Toolbar. І хоча я особисто цією службою не користувався, але знаю деяких людей, які це роблять. Ніби задоволені

Delicious (колись відомий як del.icio.us). От це вже цікавіше. Як і Гугл Букмаркс, Делішес повністю інтегрується із закладками в браузерах Firefox та Internet Explorer за допомогою відповідних плагінів (наприклад, для Вогнелиса його можна знайти тут). Але на відміну від двох попередніх закладки відкриті (тобто їх можуть продивитись інші), плюс він дозволяє ставити на закладки мітки (теги), що набагато гнучкіше традиційного ієрархічного підходу до сортування та підраховує кількість посилань на одну й ту саму адресу від різних користувачів. Найбільш популярні посилання з’являються на головній сторінці.

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

Соціальні новини

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

Digg. З цього стартапу, мабуть, і почався бум сайтів соціальних новин. Дігг – це взірець всього описаного вище: як переваг так і недоліків. Його назва навіть увіковічена в новому терміні під назвою “digg-ефект” – це короткочасне, але дуже значне підвищення відвідуваність сайту на який посилається новина, щопопала в топ новин на Digg. Дуже часто цей ефект – справжнє випробування для хостингу, бо кількість відвідувачів може збільшитись не на один порядок.

Note: як мене вже виправили, насправді вперше це поняття з’явилось як slashdot-ефект і характеризувало інший сайт новин – Slashdot, про який я в цьому дописі не згадую. Він в певному сенсі аналогічний описуваним, але не має вираженої соціальної складової, оскільки лінки на новини, які попадають в топ відбирає спеціальний склад редакторів слешдоту, а не самі користувачі.

Yahoo! Buzz. Лаври Digg багатьом не давали спокою, в тому числі і компанії Yahoo!, яка вирішила не відставати і випустити свій аналог. Тим паче, що в них було чим звабити користувачів: новини, які попадають в топ Базза потрапляють і в новини на основній сторінці порталу Yahoo!. А це не багато, не мало найпопулярніший в Інтернеті сайт.

StumbleUpon. Ще один Digg-клон, але з цікавою родзинкою, яка полягає в можливості помічати не лише лінки, а й окремі картинки, або відео з сайтів типу YouTube.

Серед інших відомих варто згадати Reddit, Mixx, Furl та ще декілька, але я ними ще не користувався, тому сказати щось гарне чи погане не можу…

Якщо говорити про щось більш приземлене до наших реалій, тобто сайти з україно- та російськомовними новинами, то про перші можна прочитати тут, а серед других єдиний відомий мені, але очевидний лідер – news2.ru. Щоправда основна їх біда – це мала відвідуваність. Особливо це стосується україномовних аналогів, де важко знайти “популярні” новини з більш ніж 5 голосами в той час як для буржуйських рахунок йде на сотні, а для російських хоча б на десятки.

Ну от ніби і все. Гарних вам новин

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

Про IT – українською