Category Archives: Блоги

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

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

GitHub у поміч блогеру

Posted by Jolly Roger on 08.03.2010 3 коментарі

Частенько блогеру, пов’язаному з IT-сферою, доводиться писати коротенькі сценарії, або ж операції, необхідні для досягнення бажаного результату. Зазвичай для подібних речей блогер ставить плагін для підсвітки синтаксису і самотужки вставляє шматки коду між спеціальними тегами. Однак щойно наш робочий скрипт змінився, чи з’їхала нумерація, як тут же всі вставки коду в статті доводиться переробляти наново.

Проте хочеться, щоб це виглядало максимально зручно для кінцевого читача. Однак і робити щоразу дурну роботу ліньки. Або ж хочеться описати деякі важливі моменти, а в кінці статті дати посилання на повністю готовий код. Або, описуючи власні дії покроково, дати користувачеві можливість просто-таки повністю скопіювати всі рядки разом, а не кожен окремо. Мало чого може залізти в голову блогеру.

Проте всі ці (і на разі не лише мої) забаганки можуть здійснитися, якщо використовувати GitHub, і, зокрема, сервіс Gist Read more »

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

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

Оновлення WordPress

Posted by Jolly Roger on 07.10.2009 Прокоментуй!

Шановні читачі!

Через проблеми зі старою WordPress, купу встановлених, але непотрібних плагінів, та кривих рук, що на льоту правили помилки, що вилазили, було вирішено перевстановити блог начисто. Сподіваюсь, вже сьогодні до кінця дня весь попередній функціонал буде відновлено. Тим не менше, ця не особливо приємна ситуація дозволить зробити користування блогом зручніше як для читачів, так і для авторів. А це означає лиш одне – рух вперед і невідворотні зміни на краще.

Залишайтеся з нами!

Opera Unite

Posted by minus-one on 16.06.2009 Прокоментуй!

Сьогодні Опера обіцяла перевинайти Веб, і те, що вона зробила, дуже схоже на це. Opera Unite крута штука. Шарити файли між Операми – дуже крута ідея (усі інші сервіси теж класні (Media Player мій улюблений – моя музичка на роботі, до речі…)). Про те, що таке Юнайт і все супутнє, ви можете прочитати/спробувати самі (з офіційних джерел).

Та я хотів би просто і ясно висловити, що власне зробила Опера: вона створила безкоштовний тунель через operaunite.com.

Якщо хто не знає, що таке тунель, я поясню в простих словах: уявіть, ви змінюєте роботу (а для мене це якраз актуально :( ), приходите на нове місце, а там файервол і аська не працює — взагалі, паше тільки html, все інше заблоковано. Що з цим зазвичай роблять? Користуються обхідним шляхом, який називається тунелюванням (для чого існує спеціальний софт):

десь в “кошерному” місці (де інет чистий — напр. вдома) встановлюється тунель-сервер;
на роботі встановлюється клієнт
аська (і все що треба) пускається через нього

Коротше кажучи, весь трафік аськи іде через 80 порт як текст, а тунель-сервер розшифровує його назад в аську і власне здійснює зв’язок з сервером icq.

Таким чином, у вас все працює “за стіною” :) . Очевидним недоліком тунелювання є той факт, що весь ваш трафік, власне, дублюється: адже ви пересилаєте дані на тунель-сервер, а він точно ті же дані пересилає вже за призначенням.

Те, що зробила Опера зі своїм Юнайтом – по суті те саме. Прийшовши на будь-яке місце (чит. за будь-який файервол) і запустивши Оперу (яка виступає тут в ролі тунель-клієнта), ви можете шарити свої файли зі світом.

Що залишається за лаштунками, так це operaunite.com (вірніше той факт, що він є тунель-сервером). Тобто весь ваш трафік дублюється через нього (адже тільки так це диво “децентралізації” можливе…).

А отже, для того, щоб децентралізувати інтернет (“позбутися посередників”, словами офіційних протоколів), Опера по суті хоче створити єдиний глобальний тунель.

І тепер два питання:

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

І мої відповіді на обидва питання: НІ.

(
п.с.: сама ідея просто назвичайно чудова, але повинний бути вільний спосіб створювати свої тунель-сервери, незалежні від Опера.

п.п.с.: уточнення – насправді Опера спочатку намагається встановити прямий конект, і лише потім, якщо “відчуває” файервол, обходить його тунелем.
)

смарт.фм

Posted by minus-one on 06.04.2009 Прокоментуй!

Ні, не все, ще дещо:

…а по-третє, є такий крутий сервіс з дурацькою назвою smart.fm. Колись він називався iKnow , та вони чогось переіменувалися. Неважливо. Так от, це абсолютно геніальна річ для всякого, хто вчить японську! Серйозно. Там є така прога iKnow (так, назва лишилася, як у старого сайту) — так от вона дуже допомагає зі словарним запасом ;) .

Спочатку ви вибираєте т.зв. лист для вивчення; це просто випадковий тематичний текст, який ви хочете прочитати, але канджі/слів з нього не знаєте. Здається, тупик? Чи довгі безконтекстні тикання по словниках? На поміч приходить iKnow — запускаєте прогу і вчите в контексті всі слова цього тексту з промовою і написанням. Кожен день прога підкидає вам порцію нових слів плюс повтор, нівелюючи тим самим затухання пам’яті (забування нового).

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

А ще там є диктант і брейн-штурм. А ще цей сервіс розроблений японцями, тому там багато японського матеріалу. Наприклад, текстів з аніме ;) (я собі усі листи по Сен то Чіхіро зібрав, тепер вчу лексику (щоб потім подивитися без перекладу…)). Коротше, дійсно працючий варіант ;) .

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

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

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