GrAndSE's blog

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

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

Першим на думка спадає мій огляд "Способи заробітку на стартапах". Оглядова стаття, доволі маленька, але чомусь мені подобається.

Ще одна оглядова та теоретична стаття "Думки про масштабованість". Ну дуже ж я люблю теми високого навантаження та оптимізації. Цей матеріал перекочував ще з минулого мого блога, бо щось меня дана тематика ну дуже ж вже подобається.

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

Стаття "Визначення позиції елементу за допомогою javascript" розповідає про підводні камені роботи з координатами елементів html-сторінки в рамках сторінки та екрану. Декілька разів ця техніка дуже мені допомагала, тому вирішив ще раз нагадати про неї.

Ну й останній матерал "Балада про php та електронну пошту" є досить непоганим мануалом для початківця в php про те, як відправляти електронну пошту за допомогою функції mail. Стаття потребує продовження, яке я ніяк не зберусь написати. Хоча матеріалів назбиралось достатньо.

Ну ось і весь список. Сподіваюсь, Вам подобається інформація, якою я ділюсь. Хотілось би, щоб не дивлячись на затримку естафету продовжили Андрій Поданенко, Ярослав Федорак та Ігор Виспянський. Ну і звичайно ж всі бажаючі. Залишайте в коментарях посилання на своє продовження флешмобу, яке я з радістю почитаю.

Дякую всім за увагу!

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

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

А сьогодні я хочу на прикладі розповісти про деякі тонкощі написання запитів для роботи з повнотекстовим пошуком.

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

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

Я людина доволі лінива і самому розбиратись мені довгий час було лінь. Завжди знаходилась купа термінових справ, непрочитаних статей, книжок, ненаписаного коду та бажання просто відпочивати. Ну все ж знайшов час і ще раз скажу, що отримую задоволення від роботи з цим інструментом. Хочу поділитись своїм досвідом про перший крок з Git. Для тих хто сумнівається, чи слід читати далі пропоную переглянути "промо" Why Git is Better Than X.

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

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

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

От же спробую щось з цією ситуацією вирішити. Рекомендації від жертв крадіжок і уважних сторонніх спостерігачів вже є. Так що буду діяти - вже написав листа власникові домену. Цікаво якою буде його відповідь. Якщо нічого адекватного не почую, буду рухатись далі. Подивимось, що ж вийде з усього цього ;)

Bug or feature? Числа в php

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

Переваги блочної верстки. Продовження

Минуло не мало часу з того моменту, як я писав про історію розвитку HTML та CSS, а також переваги блочного типу верстки веб-сторінок над табличним. Ну все там написане було теоретичними оцінками, себто моїми особистими думками, які можуть нікого ні в чому не переконати. Тому в кінці тієї замітки і написав, що хочу провести деякі практичні експерименти, щоб порівняти блочну та табличну верстку в умовах наближених до практики та підтвердити сказане мною раніше. Ну що ж. Думаю, час для цього настав.

Що ми будемо робити?

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

Повнотекстовий пошук в PostgreSQL

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

Звичайно можна вигадувати обхідні шляхи для подолання таких проблем "like-пошуку". Наприклад, обробляти рядок пошуку якимось алгоритмом стемінгу з метою виділення можливих коренів слів і використовувати для пошуку ці корені. А щоб пошукати за декількома словами додамо до пошукового запиту для кожного додаткового слова "AND like" і т.д.

Однак це не вихід.

Невдалий тест для Java

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

Замітка написана частково для того, щоб розвіяти міф про низьку швидкодію java, яким часто намагаються маніпулювати прихильники php (які на java жодного рядку програмного коду не писали і жодних замірів швидкодіє не проводили) і не тільки php в холіварах. Сподіваюсь, Вам буде цікаво.

Написанння тесту

Тест я вирішив для економії часу спростити. Оцінював лише час виконання без виклику методів, через виклик статичного метода звичайного метода, та метода, що звертається до статичних даних. Деякі тести для java написати не можливо (тут немає аналога $GLOBALS та функцій), а деякі повторювати було нецікаво.

Дослідженні швидкості виклику методу в php

Давно цікавило мене питання, якою є швидкість виклику методів класів та функцій в мові php. Насправді питання доволі важливе, так як може суттєво вплинути на проектування системи, в тому випадку коли важливою є швидкодія системи. Всі відомі мені сучасні системи CMS та framewrok'и об'єктно орієнтовані. Раніше не раз зустрічав інформацію, що виклик методу класу ресурсомістке завдання, навіть у порівнянні з викликом функції. Чи справді це так? Наскільки? Вирішив присвяти годину-дві вільного часу дослідженню цього питання.

Трошки морфології на php

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

Така приємна штука непокоїла мене давно, з часів мого знайомства з Ruby on Rails. Але все ж знаходилась маса приводів чому це мені не треба робити - економія часу на виклик функції, та і так же все працює, немає власного часу на те щоб посидіти за цією задачею. А тут вже вирішив, що з кодом треба попрацювати, так чому б не додати таку функцію? Тому поставив собі задачу розробити функцій якій б повертали множину та однину переданого параметра для англійської мови.