GrAndSE's blog

Погляд на MySQL proxy

grandse — Mon, 06 Jul 2009 21:43:41 -0700

Останнім часом я аж дві статті присвятив СУБД PosgreSQL. Як Ви могли помітити, мені дуже подобається ця СУБД. Хоча й MySQL моєю увагою в щоденній роботі необділена. А ось інформацією про неї я не ділився. Просто нічого цікавого, про що б не написали на кожному кроці на думку не спадало. І ось я мені випала можливість познайомитись з не дуже освітленими аспектами роботи з MySQL, а саме побудовою систем проксювання запитів для MySQL та утилітою MySQL proxy. Взагалі матеріалів з цього приводу доволі мало, не те що українською, а навіть і англійською мовою, тому з гордістю хочу розпочати написання невеличкої серії статей про те, як можна зменшити навантаження на СУБД MySQL, шляхом проксювання запитів через MySQL proxy.

Короткий огляд

MySQL proxy - невелика програма, що приймає конекти від кінцевих користувачів (програм) та в залежності від умов обирає бекенд MySQL-сервер (backend) та під'єднується до нього. В подальшому кожен запит (в тому числі і на авторизацію) передається спочатку до проксі-сервера, а вже він передає його одному з серверів-бекендів. Так само і результат проходить через проксі на шляху від серверу до програми, що з ним працює. Що можна досягнути таким чином? Коротко перелічу:

балансування навантаження між декількома серверами
аналіз запитів, збереження їх в лог
модифікація запитів перед виконанням (наприклад, з метою виправлення типових помилок, чи внаслідом зміни труктури БД)
обробка та модифікація результатів запитів
обробка помилок

І в усих цих випадках немає жодної необхідності модифікувати програмний код, для роботи через проксі. Достатньо лише сконфігурувати програму на конект до проксі, як до звичайного MySQL-серверу. Або у випадку, якщо навіть до файлів конфігурації доступу немає, за адресою де було попередньо встановлено БД, встановити та запустити MySQL proxy та використовуючи iptables перенаправити всі конекти з порту серверу MySQL (за замовчуванням 3306) на порт проксі (за замовчуванням 4040). Доволі зручно, особливо для підтримки систем, написаних кимось іншим. Зрозуміло, що така система вимагає опису правил роботи. Для цього використовується скриптова мова програмування Lua, про яку я вже писав раніше. Написанню скриптів для проксювання запитів я планую присвятити окрему статтю, а поки що розповім про встановлення та початкову конфігурацію.

Початок роботи з MySQL proxy

Як вже стало традиційним для мене, буду розповідати переважно на прикладі Linux (основаних на Debian дистрибутивах), однак впевнений, що проблем з встановленням не виникне. Можна обрати один з двох шляхів: скористатись бінарним пакетом, чи зібрати власноруч. Під Red Hat, SuSe, Windows бінарні пакети з останньою актуальною версією (на сьогодні це 0.7.2) можна з оф-сайту. Вихідні тексти можна отримати там чи на Launchpad.net, де можна отримати інформацію про всі зміни, нововведення та процес розробки. Однак якщо виникає бажання встановити все з репозиторіїв, то тут отримуємо проблему у застарілій версії пакету. Однак я з цим змирився:

sudo apt-get install mysql-proxy

Тепер настав час конфігурування mysql-proxy. Зазвичай в системі буде присутній файл для запуску програми, аналогічний наведеному тут. І запустити проксі можна однією командою:

sudo /etc/init.d/mysql-proxy start

Це добре, однак слід ознайомитись за параметрами виконання програми, так як таким чином можна легко проводити конфігурацію. Ключі для налаштувань перераховані нижче: --admin-address=host:port Адреса MySQL-proxy для адміністративних целій. За замовчуванням ":4041". --proxy-address=host:port Адреса MySQL-proxy для вхідних з'єднань. Саме цю адресу слід використовувати під час конфігурування клієнтів. По умолчанию значение ":4040" --proxy-read-only-backend-addresses=host:port Адреса MySQL серверу, що працює в режимі "тільки для читання". --proxy-backend-addresses=host:port Адреса MySQL севреру, якому будуть передаватись всі запити від клиенту. Може бути вказаний декілька разів, якщо необхідно мати підтримку декількох серверів. За замовчуванням "127.0.0.1:3306". --proxy-skip-profiling Вимикання профілювання запитів. За замовчуванням ввімкнене. --proxy-fix-bug-25371 Виправляє помилку #25371 для старих версій libmysql --proxy-lua-script=файл Вказує скрипт мовою lua, який використовується для тонкої конфігурації. --no-proxy Не запускати проксі-сервер --daemon MySQL-proxy в режимі демону (в фоновому режимі) --pid-file=файл Вказує місцезнаходження pid-файлу MySQL proxy. Якщо у Вас встановлено локально сервер MySQL, то достатньо буде виконати таку команду для запуску проксі:

mysql-proxy --proxy-address=ip:4040 --proxy-backend-addresses=ip:3306

, де замість ip буде ваша ip-адреса. Чому я рекомендую використовувати ip-адресу, а не 127.0.0.1 чи localhost? Тому що при зверненні до localhost створюється трошки нестандартний сокет, через який mysql буде працювати в будь-якому разі саме з сервером, а не з проксі, що не дозволить перевірити, як працює програма. Тепер можна скористатись будь-яким клієнтом для MySQL та приэднатись до MySQL-proxy, користуючись іменем користувача та паролем, що використовувались для доступу до БД. І все - можна працювати з базою данних через проксі.

Далі буде...

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

Вигадуючи велосипеди

grandse — Fri, 03 Jul 2009 22:30:07 -0700

Дуже давно в мене бажання написати відповідь на одну статтю з "Української блогосфери". Справа в тому, що моя позиція суттєво відрізняється від написаного у тій статті. Вимушений допустити, що це диктується моєю підсвідомістю, яка не хоче визнавати, що помилковим може бути обраний мною шлях роботи над власноруч написаною CMS, яка базується на знову ж таки власноруч написаному framework. Але мій розум, що цілком можливо потопає в самообмані, підказує ряд причин, чому я пішов саме таким шляхом. І нарешті я дозволю собі задовольнити це бажання і розповім, які ж причини того, що я так люблю писати все своїми руками.

Необ'єктивність

З самого початку ери комп'ютерних технологій частина програмістів з радістю займається не використанням вже написаного програмного коду, а пише ту чи іншу частину програмного код своїми руками, нехтуючи вже створеним функціоналом. І таке ось вигадування "колеса" продовжується і по сьогоднішній день, і я впевнений, буде продовжуватись до кінця ери людської. Та що ж казати: у всіх сферах людської діяльності є любителі йти незвичним шляхом. Якщо спитати кожного з них про причини такого підходу, отримаємо досить просту відповідь: "Навіщо мені користуватись тим оцим непотребом, якщо я можу зробити краще?" На цьому місці слід хапатись за голову, волати: "Як краще? Та куди тобі! Ви подивіться, яке зухвальство..." Так, так, я теж вхожу до списку тих людей які впевнені, що можуть переписати більшість програмного коду так, що він стане від того краще. Буде працювати швидше, буде мати більше функціоналу, займатиме менше пам'яті чи хоча б просто виглядатиме логічніше, зрозуміліше та приємніше. Почалось це тоді, коли ще в шкільні роки я вчився писати мовою Pascal. Виходило в мене досить непогано і цікавився я програмуванням дуже сильно. Читав різні статті, товстенькі книжки про алгоритми, вирішував купу різних олімпіадних задач, приймав участь о олімпіадах і т. п. Причому ще раз повторюсь, що виходило в мене досить непогано. Окрім того, що на олімпіадах вдавалось займати не останні місця, що зрозуміло дає підґрунтя для високої самооцінки, я натрапляв на цікаві матеріали що до оптимізації програмного коду, навіть знайомився з асемблером. І знову ж таки, на ниві мені вдавалось користуватись отриманими знаннями і головою на плечах, щоб побачити, що глибока оптимізації дозволяє переписати деякі функції зі стандартних бібліотек так, що вони працюють швидше. Куди ж тепер подіти впевненість у власних силах? Але тепер, коли дуже багато коду вже написано, проведено дуже велику кількість теоретичних досліджень, величезна спільнота працює над розробкою програмного забезпечення та стандартних бібліотек для розробки ПЗ та бібліотек (і тут кількість ітерацій може бути нескінченною :)), коли всі компілятори є оптимізуючими, коли написано стільки коду, чи має така впевненість у власній геніальності під собою основу?

Природна лінь

З одного боку, лінь підштовхує користуватись тим, що вже є в наявності, зробити швидше та забути про роботу. А є ще інша лінь, яка каже: "Навіщо розбиратись з тією великою та складною бібліотекою? Це надто складно та довго. За той тиждень, що ти, Великий Хазяїн, будеш копирсатись в документації та гратися з написаним кимось кодом, тричі встигнеш написати свою власну бібліотеку..." Якби ж то так все солодко було, як підказує ця продажна дівчина, що ховається під іменем Лінь... Достатньо погодитись на її вмовляння, як вона починає співати зовсім іншу пісню солодко та ніжно: "Куди ти поспішаєш? Навіщо? Ти обов'язково встигнеш, та ще й купу інших справ у перерві зробиш. Сядь, відпочинь, розслабся, наберись сил перед такою важливою справою". А потім може заспівати ще одну пісеньку: "А навіщо ти це робиш, воно ж нікому не потрібно?" Так чи інакше, більшість справ, на меті яких було вдосконалення того чи іншого рішення, переробка на краще своїми силами переходять до класу справ, що ніколи не будуть завершені. Більшість велосипедів та коліс не будуть кращими чи зручнішими за ті, що вже існують та не виправлять їх недоліків. В кращому випадку вони будуть на рівні, чи просто іншими. Однак є й виключення з цієї більшості. І досить рідко на ці колеса буде витрачено прийнятний час. В більшості випадків, легше та швидше навчитись їздити на звичайному велосипеді ніж вигадувати аеромобіль, який може й кращий, але... може бути ніколи не створений..

Навчання та цікавість

Але особисто мені начхати на те, що те що я роблю може виявитись нікому непотрібним, може не стати кращим за аналоги. І не шукаю визнання. Можливо я навіть ніколи не поділюсь більшістю напрацювань, тому що буду вважати їх недостатньо гарними для цього, але буду продовжувати працювати над ними. Я працюю тому, що отримую задоволення від процесу. Мені приємно від того, що я за останній місяць виправив декілька дрібничок, додав декілька нових функцій та моє творіння стало кращим. Нехай воно і не досягає тих висот, на яких живуть старші брати моєї маленької іграшки. Більш того, мені цікаво розбиратись в тому, як же все працює. Подобається кидати виклик собі та іншим, в спробі вигадати щось краще, чи на власному досвіді впевнитись, що хтось до мене вигадав та втілив в життя таку класну штуку. Тільки таким шляхом я маю шанс ефективно розвиватись, вчити свій мозок працювати, отримувати нові знання. Я бачив десятки людей, що не створили нічого. Десятки програмістів, що після університету пішли працювати кудись і продовжують сидіти на одному місці, зупинивши свій розвиток в результаті того, що вони завжди йдуть "найлегшим шляхом", використовуючи вже готове, причому в більшості випадків для них є проблемою навіть пошук та оцінку готових рішень, не кажучи про вигадку нових. Не дарма під час навчання в школі та інших навчальних закладах, викладачі змушують доводити відомі всім теореми, перераховують величезну кількість здавалось би нікому непотрібної інформації. Хоча я й не згодний з сучасною системою викладання технічних дисциплін і вважаю її в деяких місцях недостатньо глибокою, а в інших обтяженою зайвою інформацією, але з необхідністю навчати мозок працювати не погодитись не можу. Тільки но вчора почув історію про одного вченого, що запізнившись на заняття під час навчання аспірантурі вирішив, що записане на дошці було домашнім завданням і таким чином вирішив дві проблеми, які до того математична статистика подолати не могла... А він міг би погодитись зі стандартним підходом та твердженням, що краще за інших він нічого не зможе зробити.

Втілені ідеї

Весь світ, що нас оточує зараз - результат втілення в життя таких от незвичних ідей, впевненості в тому, що можна зробити щось краще, замінити звичне рішення на нове чи просто вдосконалити старе. Так колись мова програмування php виникла як шаблонізатор для perl, а тепер практично повністю витіснила останнього з ринку розробки для web. Саме так виникли Linux, Ruby та десятки інших відомих на весь ІТ-світ речей. А подивіться просто на сучасні ПК: колись Біл Гейтс був впевнений, що 640 Кб оперативної пам'яті цілком вистачить для будь-яких задач. А що ж є тепер? Особисто я пишу своє тоді, коли мене просто дратує щось в готових рішеннях, коли воно щоденно мені дошкуляє або коли мені просто дуже кортить щось написати чи розібратись, як же працює старе. Не зажди я починаю з початку. Іноді я беру готове рішення, та виправляю в ньому ті помилки, які я знаходжу, додаю нові функції, яких мені не вистачає. Повертаючись до самого початку статті, скажу: так вже сталось, що той самий WordPress мені цілковито не подобається ні за програмною архітектурою ні за зручністю адмінки, що жодна інша CMS теж мене задовольняє цілком, особливо в плані додавання туди нового функціоналу (а спробував я і Joomla, і трошки Drupal, і DLE і більш дикі та специфічні іграшки). В процесі написання чогось свого власного, я неодноразово відкривав для себе нові властивості та функції готових рішень, відкривав шляхи зручного користування цими готовими інструментами. І було таке, що повертався зі власноруч написаного коду до стандартних рішень. Повертався без жодних проблем та невдоволення. Однак в випадку з CMS на php сумніваюсь, що повернусь до одного з тих рішень, що я пройшов на шляху до написання своєї власної - так вже сталось, що я невисоку оцінку даю більшості програмістів, що працюють на php та розробляють ці CMS та доповнення для них. Не завжди нове, краще за старе - воно може бути просто іншим, збирати своїх прихильників, дарувати людям задоволення від користування, а автору задоволення від процесу творіння. І головне: для чогось нового завжди буде залишатись достатньо місця. Так що я буду продовжувати вигадувати велосипеди, шукати нові шляхи подолання старих проблем, та просто отримувати задоволення від того чим займаюсь. Бо це мій шлях, яким мені приємно йти. На якому я дозволяю собі бути самим собою, кокетливо спілкуючись з Егоїзмом та Лінню. ;)

Крихітка Lua

grandse — Sun, 28 Jun 2009 01:35:35 -0700

Серед звичних та відомих всім у світі ІТ великих мов програмування можуть загубитись маленькі перлини. І мова йде не про perl, що з кожним роком стає за моїми спостереженнями все менш популярним, дарма що це одна з найпотужніших мов, яка обов'язково заслуговує на увагу до себе. Мова йде про ще більш "загублені" мови, які навіть ніколи не досягали популярності perl'а. Відверто кажучи я й сам особливо не звертав на такі мови програмування уваги, а от коли довелось познайомитись з мініатюрною скриптовою мовою Lua, я не пожалкував ні про один день з тих двох тижнів, що були проведені з цією крихіткою. Lua ([лу́а], порт. місяць) - "ще одна" інтерпретована мова програмування, що є вільно розповсюджуваною, має відкритий програмний код мовою С та широко відома у вузьких колах розробників... та на відміну від більшості інших подібних мов, про неї чули також і допитливі фанати комп'ютерних ігор. Чому? Та тому, що це скриптова мова, що використовується в популярних World of Warcraft, The Witcher, Warhammer Online, S.T.A.L.K.E.R. та ще десятки хітів. Думаю вже цього має вистачити для того, щоб зацікавитись мовою. Не дарма ж розробники стількох проектів її використовують?

Історія та ідеї

Історія мови розпочалась в 1993 р. Команда розробників Tecgraf з католицького університету Ріо-де-Жанейро невелика — Роберто Єрусалимський (Roberto Ierusalimschy), Вольдемар Целес (Waldemar Celes) і Луіс Енріке (Luiz Henrique), почали роботу над описовою мовою, що мала використовуватись для зручності формування великих масивів даних для розв'язання завдань обчислювального експерименту і машинного моделювання. Але в процесі розвитку мова набула значних змін та архітектурних модифікацій, ставши повноцінною скриптовою мовою з солідним набором можливостей. Lua - мова з динамічною типізацією, і змінна може приймати значення будь-якого з восьми типів:

nil (невизначений)
boolean (логічний)
number (числовий)
string (рядковий)
function (функцыя)
userdata (даны користувача)
thread (потік)
table (таблиця)

Тип nil використовується для позначення відсутності значення (що є звичним для людей знайомих з Pascal).Boolean може приймати два значення true (істинне) та false (хибне), причому nil відповідає false, а будь-яке інше значення - true. Number - дійсні змінні з подвійною точністю. String - незмінювані масиви 8-бітних символів, тобто для кожного нового значення змінної буде виділятись новий рядок. Все вищеописане є простим та звичним. А ось далі починається найбільш цікаве. Таблиці (table) є базовим елементом для створення масивів, списків, структур та множин. Кожна таблиці - набір пар (ключ, значення), де ключ може приймати значення значення будь-якого типу даних, окрім nil. Також можна помітити, що в мові функції можуть бути значеннями змінних і як можна легко здогадатись ця мова підтримує замикання. Дозвольте мені повернутись до цього пізніше і перед практичною частиною перерахувати ще декілька речей, які роблять Lua популярним. Так само як і JavaScript ця маленька мова підтримує для об'єктів механізм прототипів, роблячи це легко та елегантно. Метатаблиці дозволяють організувати повноцінну підтримку ООП включаючи множинне успадкування, перевантаження операції і т.д. Також не останню роль грає легкість вбудовування в інші проекти (як саме вбудовування інтерпретатора в програму так і додавання нових функцій написаних мовами C чи C++ для можливого виклику цих функцій з Lua). Ось так буде виглядати мінімально-функціональний інтерпретатор Lua з використанням мови C:

#include #include #include #include int main (void) { char buff[256]; int error; lua_State *L = lua_open(); /* відкиває Lua */ luaopen_base(L); /* відкриває основну бібліотеку */ luaopen_table(L); /* відкриває бібліотеку table */ luaopen_io(L); /* відкриває бібліотеку I/O */ luaopen_string(L); /* відкриває бібліотеку string */ luaopen_math(L); /* відкриває бібліотеку math */ while (fgets(buff, sizeof(buff), stdin) != NULL) { error = luaL_loadbuffer(L, buff, strlen(buff), "line") || lua_pcall(L, 0, 0, 0); if (error) { fprintf(stderr, "%s", lua_tostring(L, -1)); lua_pop(L, 1); /* повідомлення про помилку зі стеку */ } } lua_close(L); return 0; }

І остання особливість мови: досить висока швидкодія як для скриптової мови та наявність JIT (just in time) компілятора LuaJIT (плюс компілятор llvm-lua для віртуальної машини LLVM). Що при наявності можливостей для легкого імпорту функцій з C дозволяє розробляти проекти з високими вимогами до оперативності.

Трошки практики

Не можна розповідати про мову програмування не показавши її в дії. Почну з традиційного "Hello, world!":

print("Hello, world!")

Оскільки Lua -інтерпретатор, то думаю, що особливих проблем з викликом коду не буде. Потрібно лише встановити інтерпретатор, а потім можна скористуватись командним рядком. Для Debain-based дистрибутивів процедура встановлення матиме вигляд:

# apt-get install lua50

Для Windows можна скористатись пакетом Lua for Windows, що включає в себе окрім самого інтерпретатора набір бібліотек, документацію для цих бібліотек, близько 250 готових скриптів-прикладів та навіть текстовий редактор, для написання програмного коду. Після "Hello, world" слід переходити до більш серйозних та інформативний прикладів. Змінні в цій мові можуть бути глобальними та локальними:

a = 1 -- глобальна змінна local b = 2 -- локальна змінна

Останні доступні лише в межах блоків, що в межах термінології Lua називаються порціями коду (chunk):

do -- тіло блоку end

Області видимості вкладаються, тобто дочірній блок матиме доступ до всіх локальних змінних батьківського блоку. Блоки використовуються як і у інших мовах програмування разом з операторами. Найпростіший оператор if:

a = 1 b = 2 if a ~= b then print("not equals") end

Як Ви могли помітити, ніде в наведеному коді немає традиційних для багатьох мов ";". Можу Вас заспокоїти, використання "крапки з комою" можливе, як для розділу окремих рядків коду так і для розділу одного рядка на окремі операції. Звичайно ж, якщо Вам це зручно. Мені особисто не дуже, тому в прикладах я пишу без їх використання. Повертаючись до мови Lua розповім про ще декілька приємних нюансів роботи зі змінними. Як і Python тут є можливість виконувати паралельне присвоювання:

x, y = y, x

В результаті виконання наведеного вище коду, змінні x та y обміняються значеннями. Оскільки Lua має динамічну типізацію, то зведення типів є доволі легкою справою. Ось так наприклад буде виглядати конкатенація:

local a = "one" local b = 2 print(a..", "..b)

Однак поряд з динамічним зведенням типів в ряді випадків необхідно скористатись функціями зведення типів, такими як tonumber, tostring і т.д. Зазвичай це корисно для роботи з даними користувача чи для роботи зі складними структурами. Ще однією приємної дрібницею в роботі зі змінними є можливість виконання присвоєння у випадку, коли змінна не була проініціалізована раніше:

var = var or 0

Уявити мову без циклів більшості сучасних програмістів є завданням непростим і звичайно ж Lua має цілий набір операторів циклів:

while вираз_умова do тіло_блоку end repeat тело_блоку until вираз_умова for змінна=початкове_значення, кінцеве_значення, крок do тіло_блоку end for змінна_циклу, додаткова_змінна in інтекактивний_вираз do тело_блока end

Наприклад:

a = 1 b = 5 c = 2 while a < b and c < b do c = a+1 a = c+1 end

Нічого змістовного тут не робиться, однак має працювати :) Хочу також навести приклад використання останнього типу циклу. Однак для цього також треба розібратись з синтаксисом роботи з таблицями. Створити просту таблицю можна так:

t1 = {} t1[1] = "one" t1[2] = 2 t1["3"] = true

, або так:

t2 = {[1] = "one", [2] = 2, ["3"] = true}

Обидва приклади створюють ідентичні зі індексами та відповідними значеннями таблиці. Доступ до елементів таблиці виконується за ключем:

print(t1[1]..", "..t2["3"])

Тепер можна роздрукувати значення елементів таблиці за допомогою циклу:

for key, value in pairs(t1) do print(key.." -- "..value) end

Також можна піти іншим шляхом, для виконання ітеративних операцій з таблицями:

table.foreach(t2, print) table.foreachi(t2, print)

Пакети в Lua також є таблицями і глобальна змінна table містить набір ітераторів для работи з таблицями. Функція foreach виконує ітерацію за всією таблицєю, а функція foreachi виконує ітераціє за ключами таблиці, що є цілими числами. Дуже потужним інструментом для цієї скриптової мови є функції. Так для прикладу напишемо функцію для розрахунку факторіалу:

function fact (n) if n == 0 then return 1 else return n * fact(n-1) end end print("enter a number:") a = io.read("*number") print(fact(a))

Виконавши цей код отримаємо:

$ lua factorial.lua enter a number: 10 3628800

Як і обіцяв скажу ще декілька слів про механізм замикання. Краще це показати на прикладі:

function make_func(x) return function(y) return x + y end end plus_func = make_func(2) print(plus_func(5))

В прикладі функція make_func повертає в результаті свого виконання анонімну функцію. Під час створення цієї функції Lua знаходить змінну, що знаходиться поза областю цієї функції, тому створює замикання використовуючи значення параметру функції-генератора (в нашому прикладі make_func). В результаті виконання цього прикладу отримаємо надруковане в терміналі значення 7. Коли я розповідав про ідеї і можливості Lua, я згадав також його потужні можливості для роботи з прототипами. Настав час показати невеликий приклад, для демонатрції цих можливостей:

human = { type = "Humam" } function human:say_hello() print("Hello from "..self.type.." "..self.name) end human.name = "Jack" human:say_hello() human.say_hello(human) human["say_hello"](human)

Цей код створюэ таблицю human, що містить елемент type, якому одразу встановлюється значення human. Потім до цієї таблиці додається як елемент функція say_hello, що завдяки оператору ":" отримує доступ до параметру self, таким чином реалізуючи інкапсуляцію. Після цього встановлюється значення поля name та тричі різним способов виконується виклик "методу об'єкту human". В результаті виконання отримаємо тричі надруковане "Hello from Human Jack".

І це не все...

Звичайно, що мій огляд не претендує на повноцінний та всеосяжний мануал, який дозволяє написати будь-яку програму мовою Lua. Підозрюю, що й на звання повного огляду всіх особливостей та функцій моя писанина теж претендувати не може. Це лише мої замітки, отримані в результаті двох тижнів, проведених в роботі з цією мовою в рамках прикладної задачі. Хоча сам той факт, що мені після двох тижнів роботи захотілось поділитись зі світом враженнями та те що з цією мовою я добре почувався вже на першому тижні знайомства розуміючи написаний код і без особливих проблем та дуже частих зазирань у всесвітню мережу вже писав свій власний, впевнений має змусити звернути когось хоча б невелику увагу на цю мову. Хоча б тому, що багато часу це не займе. Зі святом Всіх! Дякую за увагу!

Компанії та люди

grandse — Tue, 23 Jun 2009 01:24:30 -0700

Останні два роки я не працював у великих колективах - заробляв собі на життя то фрілансом, то роботою в невеличкій команді. Хоча починав свій робочий шлях я ще в роки навчання в університеті в рамках лабораторії дистанційного навчання того ж самого університету. І ось тепер вже третій місяць працюю у досить великій компанії, де наш дивізіон хоча й не може боротися за звання найбільшого, однак все ж таки за чисельністю практично досягає кількості в півтори сотні співробітників. При цьому обслуговує більше 50 тис. абонентів. І знову ж скажу, що це не найбільший за чисельністю та абонентською базою дивізіон. Навіть тих трьох місяців, що я працюю в цій компанії мені вистачає для порівняння з тими двома роками, що я провів в межах університетської лабораторії. І що не дивно, я знайшов стільки спільних рис. Ось наприклад анкетування співробітників, з метою оцінки їх ступеня лояльності компанії, настроїв, побажань і т.д. Перше ж питання в цій анкеті викликало в мене посмішку своєю шаблонністю для подібних структур. Виглядає воно приблизно так: "Чи дає Вам компанія А можливості для професійного розвитку та самореалізації?" Ось відповідь на це питання я й вирішив написати.

Що ж таке велика компанія?

Розмір компанії, на мою думку, характеризується не стількі кількістю штатних одиниць, клієнтською базою та щомісячними доходами/бюджетами. В першу чергу, це ідеологія системи управління. Кожна велика компанія складається з декількох відділів, між якими в переважній більшості випадків встановлено досить нетривіальні зв'язки. З першого погляду, ці підрозділи є автономними та виконують кожен свої завдання. Якщо ж зануритись трошки глибше, то стає очевидним, що підрозділи залежать один від одного, а в деяких випадках дублюють одні й ті ж функції. Прикладом може слугувати бугалтерія: управління всіма грошовими потоками виконується саме тут, однак в кожної функціональної одиниці є свої органи (хоча іноді й тимчасові - виникають з одного або декількох представників відділу на той період часу, коли необхідно проводити роботу з грошовими потоками) для планування витрат та оцінки прибутків від діяльності. Ось так ми перейшли до такого важливого аспекту великих компаній, як планування. Без нього тут нікуди не подітись. Всі витрати, заходи, прибутки мають бути пропрацьовані раніше. І нічого серйозного, що йде поза планом бути не може. Зрозуміло, що такий підхід - не побажання, а вимога для нормального існування компанії. Якщо цій великій структурі не буде надано достатнього імпульс та буде відстуній єдиний вектор руху, то якщо не одразу ж, то під час зустрічі з першою ж перешкодою частини структури будуть відпадати, йти іншим шляхом та в іншому напрямку. Без геніального керівника-координатора на таку компанію очікує крах. Знову ж таки, згадав ще один аспект роботи в великих структурах - керівників-координаторів, тобто менеджерів. Не менеджерів з продаж чи по роботі з клієнтами, як іноді гордо називають продавців в невеликих крамницях :), а саме менеджерів, як головних адептів культу структури керування підприємством. У кожному підрозділі є свій верівник, або декілька керівників, що відповідають за виконання тих чи інших функцій та підпорядковуються керівнику відділу (чи заступнику директора, відповідному менеджеру, це вже як називати цю посаду - суть завжди однакова). Всі працівники відділу в першу чергу підпорядковуються своєму прямому керівнику та керівнику підрозділу, але й перед іншими менеджерами носа задирати не можуть, оскільки для того щоб підкинути працівнику роботи достатньо навіть усного побажання від достатньо вагомої фігури. Хоча за регламентом будь який наказ, не від прямого началника, має йти в письмовій формі, та ще бажано через офіціну переписку за згодою керівника. А з великими задачами нехтувати цим правилом глибоко заборонено. Якщо не заборонено правилами в компанії, то слід зробити заборону для самого себе виконання великих за обсягом робіт лише за усним побажанням непрямого керівника і нехтувати цим правилом тільки тоді, коли хочете нажити собі проблем та пригод. Чому так жорстко? Тому що структура зв'язків завжди є нетривіальною. Кожному підрозділу та відповідно його менеджерам, притаманний власний погляд на ту чи іншу проблему, одні й ті ж самі завдання для них мають різний пріорітет та виконані мають бути по різному. І що головне, кожний керівник не хоче бути крайнім та втратити своє тепле місце. Тому для будь-якої великої компанії характерною рисою є, велика кількість наказів, службової переписки та наявність каналів зв'язку для цієї переписки. Я не можу уявити, скільки ресурсів витрачалось для бумажної переписки до появи електронної пошти, якщо мені на корпоративну скриньку щоденно приходить не меньше десятка листів, а під час вирішення тих чи інших питань кількість листів маоже збільшуватись в декілька разів. Це не повний перелік рис, характерних для компаній такого масштабу. Думаю, що нічого нового я не написав та не відкрив, однак вважаю, що й нагадати всім про них зайвим не буде.

Компанії та люди

З вищесказаного стає зрозумілим, як компанія буде ставитись до індивідуального розвитку її працівників. Якщо розвиток працівника не суперечить цілям компанії та не йде в розріз зі стабільним існуванням її структури, то компанія цьому розвитку заважати не буде. Однак і сприяти йому теж не буде. Не дарма ж популярним висловлюванням є висловлювання про старого коня, який нічого не зіпсує. Ви бачили влеикі, які б прагнули кардинальних змін та нововведень? Я особисто ні. Кожне нове впровадження має йти через ланцюжок керівників, має бути затверджене на кожному рівні, і жодним чином не суперечити структурі та цілям компанії. Фактично головним фільтром для нововведень є небажання керівників втрачати свої місця, відхилятись від наміченого курсу розвитку, затвердженого в місячних, квартальних та річних планах, брати на себе відповідальність. І не тільки керівництва, а й рядових виконавців. Чому так? Тому що, компанія як структура, чхати хотіла на добробут кожного окремого працівника, новітні технології, розвиток науки, гуманізм, морально-етичні цінності. Точнісінько так само, цій структурі несуттєвим є комфорт та потреби клієнтів. Клієнти - ресурс, що використовується для отримання всього необхідного для збереження, зміцнення та росту внутрішньої структури компанії. Співробітники - інструмент для обробки клієнтів та матеріал для побудови структури. Не більше. Всі заходи для утримання клієнтів та працівників - рефлекторні відповіді організму на зовнішні подразнення, в основі яких лежить інстинкти самозбереження та накопичення маси. Тому ідеальною складовою частиною такого механізму є елемент, якого не цікавлять власні потреби та потреби компанії. Він взагалі не має потреби думати та вирішувати, а має тільки виконувати вказівки отримані від керівництва, що в рамках даної метафори є нервовою системою. І повірте мені, завжди буде велика кількість таких виконавців. Вони з головою занурюють в рутинну роботу, без задоволення, зацікавлення, отримуючи від цього дискомфорт, однак ніколи добровільно не змінять своє робоче місце. Реакції невдоволення керівництвом, бажання нововведень та покращення умов праці є контрольовани з боку керівництва компанії. Тобто це лише надані керівництвом віртуальні права, що дозволяють людині не вратити розум, відчути своє значення в рамках системи. Однак жодне з цих коливань не може призвести до кардинальних змін та відходу від наміченого раніше плану і тим паче не вплине на основні цілі компанії. Організму вигідно, щоб його клітини працювали синхронно та злагоджено. Тому дозволяються контакти між працівниками, деяка неформальність на робочому місці, корпоративи. Тим же цілям слугує й можливість обміну невдоволенням політикою компанії та керівництвом. Все це робить колектив сплоченим в рамках робочих задач. І не кажіть, що я перебільшую - все саме так і є. Як Ви думаєте, чи добре це саме для Вас?

Навіщо ж тоді працвати в таких компаніях?

Попри всі перешкоди, що можуть стати на заваді для самореалізації працівників в рамках великих компаній, працювати в них можна. Не лише й можна, а від цього можна отримати користь. Як? По-перше, тут можуть з'являтись дуже цікаві задачі за специфікою та масштабом. Наприклад, за декілька років фрілансу та роботи невеликими командами, я не бачив і десятої частини того устаткування, з яким доводиться працювати тепер. Тепер же з наступного місяця буду дуже тісно працювати з БД SyBase, що буде встановлено на сервері Hewlett Packard з двома процесорами Xeon (сумарно 8 ядер) та 18 Гб оперативної пам'яті. До цього, я такої машини взагалі не бачив, не те щоб працювати з нею. Та й про SyBase тільки чути міг. Та й взагалі тепер всі задачі обертаються навколо систем з високим рівнем навантаження. Тут і робота з реплікаціями БД, проксюванням і багатьма іншими завданнями з якими я не стикався і міг би ніколои не зіткнутись. Корисно це меня в професійному плані? Звичайно. Цікаво? Не завжди, оскільки поряд з цікавими чи новими для мене завданнями є маса рутинних справ, однак відсоток цікавого для мене відносно всієї роботи значно зріс. По-друге, ціна великих компаній в Вашому резюме є більшою, ніж маленьких та нікому невідомих. Частково й тому, що перелік професійних навичок в багатьох випадках зростає. Частково тому, що компанія має певне ім'я. Частково тому, що Ви отримуєте навички роботи в колективі. По-третє, ті самі навчики роботи в колективі. Так вже сталось, що в багатьох випадках один в полі не воїн, тому такі навички стануть корисними. Якщо Вас цікавить створення власної компанії в перспективі, і Ви впевнені, що більше не будете працювати як співробітник компанії, то у Вас є можливість подивитись з середини, як працює організаційна структура компанії, відчути на собі переваги та недоліки методів управління, якими користується компанія. В-четверте, великі компанії залишають простір для кар'єрного росту. Для багатьох, це значна перевага. Їм це приємно та цікаво. Та й взагалі, більшість великих компаній в результаті планування є стабільнішими в плані утримання працівників, своєчасних виплат зарплатні, дотримання законодавчо затверджених норм. Та й ресурсів для роботи зазвичай вистачає. Отже з цього боку проблем зазвичай не виникає. Якщо ж Ваші цілі не будуть суперечити курсу розвитку компанії, то у Вас є всі шанси для того, щоб працювати комфортно, отримувати підвищення як зарплатні так і нові посади. Так що лякатись роботи в великих компаніях та колективах не слід. Скажу навіть більше - деякий досвід роботи в масштабних підприємствах, проектах є корисним чи навіть необхідним, більшості людей. Слід просто розуміти, що від Вас очікують, розуміти, навіщо це потрібно, яку користь Ви можете з цього отримати та коли необхідно змінити місце роботи, якщо це буде необхідно.

Google Chrome в Linux

grandse — Tue, 16 Jun 2009 09:44:15 -0700

Майже рік минув з того часу, як корпорація Google випустила власний браузер Chrome, що зайняв доволі значні позиції на ринку браузерів за короткий термін часу. Нажаль, випущено було лише версію для Windows. Це можнор джосить легко пояснимти: компанія не вважає доцільним працювати над паралельною розробкою нового продукту для декількох платформ одночасно. В Google епообіцяли, що коли версія для Windows стане стабільною, отримає весь необхідний на думку компанії функціонал, встане на ноги, тоді буде зроблено версії також і для інших ОС. Зрозуміло, що у тому випадку, коли браузер не займе серйозну нішу в рамках найбільш розповсюдженої серед користувачів платформи, то сенсу витрачати додаткові ресурси на розробку. Та й розумно написаний програмний код легше переносити на іншу платформу, ніж писати паралельно під декілька платформ. Ну зрозуміло, що community не дуже зраділо такій політиці компанії, та створило порт opensource-проекту Chromium для інших ОС - Crossover Chromium. Свого часу спробував я його власними руками. Добре, що він існує і став для мене вікном через яке я подивився на Chrome, та до основного продукту він не дотягує: значно поступається за швидкодією та стабільністю. Та що ж взагалі просити від wine? Ось тепер і на вулиці прихильників Linux з'явився браузер від Google. Тепер будь-хто може спробувати рідну версію Chrome для цієї ОС. Спробував і я, та вирішив поділитись враженнями від побаченого. Враження.. Навіщо Вам мої враження, самі спробуйте :) Жартую, оскільки враженями я таки вирішив поділитись. Працює стабільно - жодного підвисання чи вильоту за декілька днів тестування. Швидкодія приємно вразила - куди там Firefox та Opera. Особливо з широким каналом Internet. Частина успіху криється в двигунці WebKit, який себе добре показав і на прикладі Konqueror. А тут ще й додали швиденьку обробку javascript. Не натрапив на жодну сторінку, яка б некоректно працювала чи гальмувала. Мені це дуже сподобалось. На жаль, теми та розрширення, які нещодавно з'явились в Chrome для Linux версії мені встановити не вдалось - всі що я знайшов у вигляді *.dll, що зрозуміло меня не підходить. Тай взагалі додатків дуже мало. Тут Firefox абсолютний лідер. Однак дещо можна знайти на ресурсі "Мой Google Chrome". А як ця іграшка для web-розробки? По-перше, WebKit в усіх своїх інкарнаціях працює однаково, тобто верстка під Safari, Chrome, Konqueror та ряд інших браузерів "йде комплектом", та й взагалі особливих проблем не викликає. Є навіть ряд можливостей з CSS. 3, реалізація яких щоправда відрізняється від реалізації в Firefox (маю на увазі заокруглені кути елементів). По-друге, швидкість обробки javascrip та html дає змогу уникнути легкого дискомфорту притаманного білшості інших браузерів, я саме довогої обробки сторінки. По-третє, в меню "Control current page" є підменю для девелоперів. Ось тат саме цікаве. Можна переглядати код сторінок (Ctrl+U), причому з підсвіткою синтаксису. Одразу ж руки тягнуться його редагувати, однак такої приємної функції тут немає. А от javascript консоль - просто шедевр. Мабуть всі, хто користувався Windows-версією її оцінили. Тут і виконання команд, як у справжній консолі, і перегляд та редагування стилів так само як у Firebug для Firefox і діаграма завантаження ресурсів, і виділенян помлок в html-коді. Особисто мені дуже сподобалось. Помітив я і декілька недоліків. По-перше, комбінації клавіш орієнтовані на анлгійські символи при зміні розкладки клавіатури не працюють. По-друге, я так і не побачив Task Manager - він не запустивсія. По-третє, я вже казав про ситуацію з додатками. По-четверте, не всі налаштування працюють. По-п'яте, є свої нюанси верстки під WebKit і іноді звичні для мене прийоим мене зраджують (ось сиджу та не знаю, що ж робити з CSS-спрайтом, щоб він нормально виглядав). В усьому іншому браузер мені дуже сподобався. Складається враження практично завершеного продукту. Поки що від Firefox + Firebug я не відмовлюсь, оскільки для мене так працювати зручніше і звичніше. Однак не виключаю, що з часмо можу почати корситуватись ним, як основним браузером, і впевнений що вже зараз багато розробників перейшли на Chrome як основний робочий браузер. Ну ось і все. Дякую за увагу!

Естафета. П'ять найкращих статей в блогах

grandse — Fri, 12 Jun 2009 23:48:38 -0700

Пан Tod в рамках естафети навів п'ять найкращих своїх статей в блогах. Причому з причини великої кількості його блогів і великої кількості матеріалів в них, Він вирішив зробити огляд п'яти статей з кожного свого проекту. Вийшов доволі великий матеріал. А на прикінці запропонував всім бажаючим прийняти естафету. Чомусь мені захотілось зазирнути в минуле та подивитись, що ж цікавого я написав. Не буду далеко ходити та просто нагадаю собі та іншим про що я тут писав до перерви. Першим на думка спадає мій огляд "Способи заробітку на стартапах". Оглядова стаття, доволі маленька, але чомусь мені подобається. Ще одна оглядова та теоретична стаття "Думки про масштабованість". Ну дуже ж я люблю теми високого навантаження та оптимізації. Цей матеріал перекочував ще з минулого мого блога, бо щось меня дана тематика ну дуже ж вже подобається. Ну більше за оглядові статті я полюбляю практичні. В статті "Перевірка імені та прізвища користувача регулярним виразом в php" я розповів про свій сумний досвід пошуку регулярного виразу який би впорався з перевіркою імені користувача написаного латиницею чи кирилицею з урахуванням особливостей української мови. Стаття "Визначення позиції елементу за допомогою javascript" розповідає про підводні камені роботи з координатами елементів html-сторінки в рамках сторінки та екрану. Декілька разів ця техніка дуже мені допомагала, тому вирішив ще раз нагадати про неї. Ну й останній матерал "Балада про php та електронну пошту" є досить непоганим мануалом для початківця в php про те, як відправляти електронну пошту за допомогою функції mail. Стаття потребує продовження, яке я ніяк не зберусь написати. Хоча матеріалів назбиралось достатньо. Ну ось і весь список. Сподіваюсь, Вам подобається інформація, якою я ділюсь. Хотілось би, щоб не дивлячись на затримку естафету продовжили Андрій Поданенко, Ярослав Федорак та Ігор Виспянський. Ну і звичайно ж всі бажаючі. Залишайте в коментарях посилання на своє продовження флешмобу, яке я з радістю почитаю. Дякую всім за увагу!

Оптимізація запитів для повнотекстового пошуку в PostgreSQL

grandse — Wed, 10 Jun 2009 10:31:04 -0700

Нещодавно я вже писав про реалізацію повнотекстового пошуку в PostgreSQL. На мій погляд стаття непогана, хоча мені на пошту прийшов коментар від читача, який сказав, що я дещо помиляюсь і деякі операції є зайвими. Я трішки не зрозумів в чому саме я виконую зайві операції, однак цілком можливо, оскільки я вперше зіштовхнувся з реалізацією повнотекстового пошука в PostgreSQL 7.x, а з того часу бугато речей було спрощено і деякі мої маніпуляції вже могли потрапити в статус deprecated. Як би там не було, з радістю та увагою спробую сприйняти будь-яку критику в свій бік. Особливо з огляду на те, що проблему з коментарями я виправив. А сьогодні я хочу на прикладі розповісти про деякі тонкощі написання запитів для роботи з повнотекстовим пошуком.

На чому ми зупинились

Будемо вважати, що вже є розгорнуто базу з попередньої статті. Сенсу повторювати весь шлях я не бачу, тільки скажу, що вибірка робиться трішки модифікованим запитом з попереднього матеріалу:

SELECT id, title, ts_headline(body, q) AS head FROM index, to_tsquery('ukrainian', 'робота') AS q WHERE (idxfti @@ q) ORDER BY ts_rank(idxfti, q) DESC OFFSET 10 LIMIT 10

Тут додано обмеження в кількості отримуваних результатів та деякий зсув, а також змінено рядок за яким буде вестись пошук з метою збільшення кількості релевантних результатів. Така собі емуляція посторінкової навігації для великої вибірки. Для кількості сторінок в індексі, що перевищує 2000 елементів, коли обсяг таблиці приблизно 20 МГб виконання цього запиту займає близкь 0,75-0,8 сек. Це доволі багатенько, оскільки сучані пошукові системи працюють майже міттєво. Одразу ж скажу, що перше виконання запиту займає на майже 2 сек більше часу, тоді як повторне виконання подібного запиту зі зміною ключових слів вже працює саме з такими витратами часу. Цю проблему легко вирішити, організувався постійні конекти до БД. Гадати на кавовій гущі, чому ж так не буду, бо в інтернеті нічого розумного знайти не вдалось. Можливо хтось в коментарях пояснить в чому справа. З чого ж складаються ці 0,75 сек? Одразу ж на думку спадає, що багато часу займає сортування. Легко перевірити:

SELECT id, title, ts_headline(body, q) AS head FROM index, to_tsquery('ukrainian', 'робота') AS q WHERE (idxfti @@ q) OFFSET 10 LIMIT 10

І покащення швидкодії дуже незначне - не більше 50 мс. Так в чому ж справа? Поглянуши на EXPLAIN для запиту, я зрозумів, що практично нічого тут не розумію, і здається все працює так як і має працювати:

Limit (cost=105.73..105.73 rows=1 width=180) -> Sort (cost=105.73..105.73 rows=2 width=180) Sort Key: (ts_rank(index.idxfti, q.q)) -> Nested Loop (cost=0.00..105.72 rows=2 width=180) Join Filter: (index.idxfti @@ q.q)" -> Function Scan on q (cost=0.00..0.01 rows=1 width=32) -> Seq Scan on index (cost=0.00..80.31 rows=2031 width=148)

Тому почав копати крок за кроком. Почав з малого:

SELECT to_tsquery('ukrainian', 'робота')

Цей клиптик коду відпраьовує практично миттєво 10-20 мс. Вирішив додати запит данних, однак без додаткової обробки:

SELECT id, title, body FROM index, to_tsquery('ukrainian', 'робота') AS q WHERE (idxfti @@ q) OFFSET 10 LIMIT 10

І реузльтат, який я отримав дав мені відповідь, в чому ж таки проблема. Цей запит виконується за 250-300 мс, що значно прийнятніше в плані швидкодії.Гльмом виявилась ts_headline, яка повертає місце, де було знайдено шукане ключове слово. Однак відкинути корисну інформацію не гарною ідеєю.

Що ж робити?

В усіх мануалах про оптимізацію запитів пишуть, про те що треба зменшувати кількість данних, що обирається, тобто виймати з бази тільки те, що потрібно. Якщо ще зменшити, кількість того, що виймається запитом, то отримаємо ще кращий результат:

SELECT id FROM index, to_tsquery('ukrainian', 'робота') AS q WHERE (idxfti @@ q) ORDER BY ts_rank(idxfti, q) DESC LIMIT 10 OFFSET 0

Виграли ще 50 мілісекунд. А що, якщо зменшити кількість даних, які вимушена обробляти функція ts_headline? Зробити це можна через вкладений запит, та синтаксичну конструкцію IN:

SELECT title, ts_headline(body, q) AS head FROM index, to_tsquery('ukrainian', 'робота') AS q WHERE id IN ( SELECT id FROM index, to_tsquery('ukrainian', 'робота') AS q WHERE (idxfti @@ q) OFFSET 10 LIMIT 10 );

В даному запиті спочатку обираються тілкі id елементів, що відповідають заданим умовам пошуку, а потім вже виконується вибір даних, для елементів id яких знаходится в списку обраних. Це працює і отримуємо час виконання запиту в рамках 450-500 мс. І сортування за ранком жодним чином не є проблемою, оскільки виконується всередині вкладеного запиту:

SELECT title, ts_headline(body, q) AS head, url FROM index, to_tsquery('ukrainian', 'робота') AS q WHERE id IN ( SELECT id FROM index, to_tsquery('ukrainian', 'робота') AS q WHERE (idxfti @@ q) ORDER BY ts_rank(idxfti, q) DESC OFFSET 10 LIMIT 10 );

В таком вигляді запит працює вс з тією ж швидкодією. Ніяких помітних втрат. Ну що ж, зменшення затрат помітне: в 1,5 рази і ще й невеличкий запас залишився. А тепер спробуємо в умовах, ближчих до реальних. 85+ тисяч проіндексованих документів, обсяг БД 900+ МГб. Як Вам? Мені подобається. Час виконання запиту з якого ми почали від 11 до 13 сек, тоді як його оптимізований брат вписується в 5 секунд. Як бачите, чим більший об'єм БД тим більший приріст отримуємо. І не кажіть мені після цього, що оптимізація є марними витратами часу.

Індексація та інші цікавості

Ще деякий час можна виграти створивши gin індекс. Детальніше можна почитати в документаціїї, а для БД з якою ми працювали SQL для генерації індексу матиме вигляд:

CREATE INDEX fti ON "index" USING gin (idxfti);

База розростається (так для таблиці в 900 МГб індекс в мене займає додаткових 300 МГб з гаком), однак час виконання запиту зменшується десь в 1,5 рази. Тобто ще десь 1,5 секунди для БД з 82 тис. записів. Думаю, що реузльтат непоганий. Також правильне налаштування БД може суттєво вплинути на швидкодію. Однак це не до мене - на радість завжди поряд опиняється людина, що знає що й до чого, тому особливих рекомендацій що до тюнингу PostgreSQL я не зможу дати. Всі мої рекомендації можна знайти з легкістю на першій же сторінки пошуку в Google. :) Взагалі то методи оптимізації, які я показав в цьому матеріалі можна перенести на ряд інших випадків. Так, я доволі часто використовую IN. Та й про індексацію полів у БД кажуть на кожному кроці. Просто треба бути уважним і не лінуватись поміркувати, а як можна зробити краще та швидше. Зазвичай, оптимізація роботи з БД найдешевший спосіб прискорити роботу багатьох проектів, пов'язаниз з базами даних. Так що бажаю успіхів і сподіваюсь стане внагоді. Дякую за увагу!

Перший крок в Git

grandse — Thu, 04 Jun 2009 22:24:07 -0700

Практично рік вже минув з того моменту, як я писав про git. Тоді я ще користувався svn і лише цікавився тим, що ж таке створив Лінус Торвальдс. А тепер ось спробував попрацювати з git і отримую задоволення від роботи з ним. Та що там казати, в мене практично ейфорія від того, як швидко він працює, як все просто робити, наскільки менше проблем виникає порівняно з тим самим svn. І ось думаю, а що ж мені заважало розібратись з git раніше? Відповідь тривіальна: не знайшов нормального мануала. Серія статей чудово розповідає про внутрішню кухню в git, про те там відсутнє головне: як почати працювати. Я людина доволі лінива і самому розбиратись мені довгий час було лінь. Завжди знаходилась купа термінових справ, непрочитаних статей, книжок, ненаписаного коду та бажання просто відпочивати. Ну все ж знайшов час і ще раз скажу, що отримую задоволення від роботи з цим інструментом. Хочу поділитись своїм досвідом про перший крок з Git. Для тих хто сумнівається, чи слід читати далі пропоную переглянути "промо" Why Git is Better Than X.

Крок перший

Git - розподілена система контроля версій. Тобто для початку роботи, немає жодної необхідності налаштовувати якийсь сервер, достатньо лише git, встановленого на клієнтській машині. Зараз відстуні проблеми встановленням git (в усякому разі під будь-якою *nix-системою). Наприклад, в будь-якій Debian-based системі можна виконати команду:

apt-get install git

Тепер достатньо перейти в директорыю з файлами проекту та ініціалізувати git-репозиторій:

git init

Маємо отримати повідомлення про те, що новий пустий репозиторій git було створено. Теперь можна додати всі файли проекту до репозиторія:

git add -Av .

Тут зупинюсь трошки детальніше. Опція -A змушує додати чи оновити всі файли в тому, числі які вже були додані чи могли бути проігноровані. Ну а опція -v звична для всіх *nix команд і вмикає розширений вивід. Таким чином ми побачимо всі дії виконані з файлами. Ну а параметр . вказує який файл слід додавати в репозиторій. Оскільки в прикладі це директорія, то всі файли будуть додані. Припустимо необхідно додати лише один файл, тоді команда матиме вигляд:

git add some_file_name

Ну що ж, файли додано, тепер можемо зробити перший комміт.

git commit -am "First commit for project"

В реузльтаті отримаємо отримаємо щось на зразок:

2 files changed, 172 insertions(+), 0 deletions(-) create mode 100644 some_file_name create mode 100644 another_file

Опція -a вказує на те що необхідно автоматично додати зміни для всіх змінених чи виделених файлів. Слід врахувати, що нові файли, що не були додані до проекту за допомогою git add не будуть враховані. Опція -m дозволяє до комміту додати коментар. Вважаю, що досить розумно додавати коментарі з короткими поясненнями, які зміни відбулись. На цьому перший крок можна вважати завершеним.

Крок другий

Ну що ж. Перший крок зроблено. Настав час рухатись далі і попрацювати з гілками. Що таке гілки? Це рвідгалудження від основної лінії розробки. В рамках головна гілка називається master. Які переваги це дає? Наприклад, в стабільному напрямі проекту, тобто master, відбувається пуступове накопичення функцій, додання нового функціоналу, що не чіпляє старий код. Тут все йде лінійно та за планом. Так зазвичай працюють з svn. Однак, якщо в процессі розробки виникає ситуація, коли до раніше написаного коду потрібно внести досить великі зміни чи додати одну експерементальну функцію не припиняючи внесення змін до основною гілки? Зупинити весь проект, дочекатись поки не будуть завершені зміни до раніше написаного коду? Неефективно, тому-що вносити зміни в старий код в ряді випадків може тільки одна людина, тоді всі інші мають чекати. Робити одночасно зміни в старому коді та додавати нові функції? Може статись так, що замість тільки що доданий функціонал буде несумісним з тими змінами, що відбулись в попередньо написаному коді. Все можна зробити простіше: для змін створюється окрема гілка. Туди вносять всі необхідні зміни. Тим часом паралельно йде робота в іншій гілці де додається новий функціонал. Коли зміни завершено, тоді виконується злиття гілки з master попередньо позбавляючись конфліктів. Здавлося б в subversion такі можливості теж є. Однак, наскільки мені відомо всі, хто користуються цією системою контроля версій уникають використання гілок. Причиною тому є складність у роботі з гілками та ще необхідність постійно звертатись до серверу, що значно сповільноє роботу системи (навіть у локальній мережі час передачі файлів та виконання операцій порівняння займає багаточасу порівняно з операціями на локульній файловій системі). Особисто я лише раз зіштовхнувся з гілками та svn з моменту свого знайомства з ним (а це відбулось майже три роки тому, восени 2006). І враження залишились у мене далеко не найкращі. Давайте створимо гілку для нашого проекту:

git branch new-feature

Перейдемо до нової гілки:

git checkout new-feature

Тепер створимо новий файл в гілці new-feature з іменем test, додамо його в гілку та зробимо комміт:

git add test git commit -am "Add new feature"

Тепер порівняємо зміст гілки з основною.

git diff master

На даному етапі ми мали б зробити попереднє подолання конфліктів, однак оскільки таких намеє то можна перейти до основної гілки та зробити злиття гілок:

git checkout master git merge new-feature

Ну тепер можна подивитись лог змін:

git log --color

Так ми отримаэмо лог змін з кольоровою підсвіткою.

Крок третій

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

man git-command

Успіхів у використанні Git. Сподіваюсь він Вам сподобається не менше ніж мені. Та звичайно ж дякую всім за увагу!

Крадений контент, як ознака якості блога

grandse — Wed, 03 Jun 2009 21:55:36 -0700

Вау.. Вчора ввечері дружина знайшла російськомовний клон цього блога. Знайти його можна за адресою deve.org.ua. Нарешті й мене наздогнали любителі чужого контенту з чим я себе вітаю. Щиро вітаю, тому що крадіжку контенту можна вважати показником того, що за оцінкою власника того ресурсу я пишу матеріали, що можуть стати комусь цікавими. Так що тепер і я можу приєднатись до Ярослава Федорака з Українською блогосферою, ELECTRIC'а, Конспіратора та ще багатьох. Вибачте, якщо когось не включив до цього списку чи навпаки включив помилково :) Як Ви могли помітити, все це дійство мене страшенно забавляє. По-перше, оскільки мережею користуюсь вже не один рік, тому копіпастинг, крадіжки контенту, переклад без вказівок на джерело стали для мене справами звичними, які я можу побачити на кожному кроці. Так що жодного роздратування в мене не виникло. Я знав і був впевнений, що мої матеріали раніше чи пізніше з великою ймовірністю опиниться на чиємусь сателіті (не між же я вважати свою писанину настільки поганою, що ніхто її читати та красти не буде :)). По-друге, мені цікаво, як же цю ситуацію можна "розрулити". Ось вчора знайомий закінчив експеримент з фотоапаратом, маркування якого вказує на його належність до американської серії, і з гордістю сказав, що сервісні центри в Україні за нього не беруться. Ось і мені цікаво те весело опинитись в такій ситуації. От же спробую щось з цією ситуацією вирішити. Рекомендації від жертв крадіжок і уважних сторонніх спостерігачів вже є. Так що буду діяти - вже написав листа власникові домену. Цікаво якою буде його відповідь. Якщо нічого адекватного не почую, буду рухатись далі. Подивимось, що ж вийде з усього цього ;)

Bug or feature? Числа в php

grandse — Sun, 31 May 2009 00:30:57 -0700

Хочу поділитись двома своїми спостереженнями про роботу з числами в мові php, які змусили мене коли я вперше зіштовхнувся з таким проблемами витратити купу часу та сил на їх подолання. Купу в межах кількості коду та часу, які б я мав витратити у нормальній мові програмування на подолання таких труднощів. Це мені дало ще більше підстав недолюблювати цю мову програмування, та називати її нелогічною. Справа в тому, що тут мова піде про таку здавалось би звичну для всіх річ, як робота з числовими даними, робота з якими мала б бути дуже простою та не викликати жодних проблем. Мала б бути. Однак php і тут підкинув проблему.

А що є числом?

Всі добре знають, як добре php може впоратись з приведенням будь-яких чисел до рядку - достатньо лише конкатенувати числову змінну до рядка і жодних проблем. Та й навпаки перетворити рядок на число здавалося б проблем не викликає. В таких обставинах перевірка чи значення змінної є числом має бути справою п'яти хвилин, тому що є ж функції is_int() та is_float. Про це можна тільки мріяти, окільки ці функції працюють тільки з тими змінними, що були встановлені як числа кодом php без жодних виключень. Тобто, якщо:

1 + "10 Small Pigs";

поверне значення 11, то

is_int("10");

поверне false. Все б нічого, однак всі данні введені користувачем представлені у вигляді рядків, тобто для них is_int() та is_float() не працюють. Частково рятує is_numeric(), яка так враховує можливість того, що рядок може містити число, однак перевірити чи ціле число так неможливо. Тому доводиться писати:

preg_match("/^[\d]+$/", $param); // Лише цілі числа preg_match("/^([\d]+)(\.([\d]*))?$/", $param) || preg_match("/^([\d]+)(,([\d]*))?$/", $param); // Дійсні числа

Особисто я витратив більше години колись на вирішення проблеми, чому код який виглядає цілком логічно не працює. А проблема була саме в is_int() та is_float(). Хоча з дійсними числами ще далеко не все.

А чи знали ви, що числа прив'язані до локалі?

Зверніть увагу на другий вираз для перевірки даних. Зрозуміло, що на практиці для країн східної Європи той формат чисел, що за замовчуванням використовується наприклад в MySQL не є звичним: ми звикли до такої форми запису десяткових дробів, коли ціла та дрібна частини розділені комою, а в програмах та мовах програмування використовується запис через крапку. Розумник php має розуміти обидві форми запису з переданих даних. І він здавалось би чудово це робить. Однак вискочила неприємна фішка мови: коли дійсне число конвертується в рядок, то враховується локаль встановлена в php. Коли ми організовуємо виведення даних це просто чудова та корисна функція, бо всі числа будуть в звичному вигляді. Однак, що буде коли спробувати передати дані в MySQL? Оскільки запит є рядком, то під час збирання цього рядка php конвертує числові дані в неприйнятний для MySQL формат. І не завжди є можливість змінити локаль для MySQL. Наприклад, для багатомовних ресурсів. Тоді знову ж доводиться вигадувати граблі:

$param = (float) preg_replace("/,/", '.', $param); /* Деякі дії з даними */ preg_replace("/,/", '.', (string)$param);

Таким ось костилем число примусово конвертується в форму характерну для буржуйських локалей (тобто гарантовано буде розпізнане мовою php), потім перетворюється примусово на float, з яким можна працювати, чи в 0 якщо рядок мав не числовий формат. А вже перед додаванням до рядка запиту число необхідно знову конвертувати в рядок, знову ж таки перевівши його в звичний для MySQL формат.

Чистий та прозорий код мовою php?

З такими перетвореннями про чистоту коду, його прозорість та швидкодію мова йти не може. Не вірю я в те, що в 6ій версії мови всі ці проблеми буде вирішено. Вирішити їх можна на рівні мови? Звісно й доволі просто - додати деякі функції, які б дозволяли конвертувати дані з додатковими налаштуваннями. Сподіваюсь на те, що наведені методи допоможуть Вам уникнути ряду проблем і зберегти час та нерви.