Blog @funivan

Вебсайт за день? Пффф, ізі.

Tue, 17 Nov 2020 07:07:07 +0200

Є такий ресурс - Хабр. І на ньому розмістили статтю “Теперь я не могу сделать даже маленький сайт”
У більшій-мірі, я рознесу цю статтю й опишу як не стикатись із подібними проблемами. Короткий вступ. Колись чувак писав сайт, потім армія, а тепер знову захотів відновити свій пет-проджект. А технології розвиваються. Php, react, vue, docker. Йому підгоріло і понеслось …

Вибираємо мову програмування

Хм, не могу же я просто взять PHP и написать на нем несколько страничек вперемешку с HTML. Как я буду это поддерживать без ООП и вообще нормального разделения кода? К тому же, все говорят, что PHP уже не очень, да и сколько новых версий вышло! Наверно, мне нужно взять что-то более современное, Node.js или Python.

Ну ясно що не можеш взяти РНР бо ти не шариш :D. Чувак не розуміє які у нього критерії до вебсайту і вважає що йому треба брати щось складне або новомодне. Якщо ви у такій самій ситуації - задайте собі ряд запитань для того що б визначитись з мовою.

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

Тут все просто. Прийшов, побачив, написав. Пиши на на тій мові, яку знаєш. Немає сенсу брати технологію в якій не розбираєшся на першому етапі. Це при умові що ви бажаєте вирішити проблему.

Определившись, что я буду использовать или Python, или Node.js, я понял, что просто так отдавать целые странички с сервера нехорошо.

Звідки він це пойняв. І чому “не харашо”.

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

Не потрібно ускладнювати собі життя. Для розв’язання проблем вибирайте знайомі вам технології!

На фронтенде мне стоит подключить Axios, хотя теперь есть Fetch, но поддерживается ли он всеми браузерами? А может быть мне вообще использовать Svelte, чтобы заодно научиться чему-то новому?!

Ось тут і зарита собака. Є 2 шляхи. Ви хочете вивчити щось нове, чи вирішити задачу? Якщо і те й інше тоді беріть нові технології й не нийте. Але в такому випадку будьте готові що у вас може прогоріти все. Краще затягніть 1ну нову технологію і вивчайте її. Тоді малими кроками ви зможете добитись певних результатів.

Вам вчитись потрібно чи зробити сайт якісно і швидко? Задавайте собі це запитання перед тим як приступите до вибору технологій.

Tooling

Теперь стоит правильно настроить IDE, для того, чтобы соблюдать Code Styles

От нафіга? Кому треба цей кодстайл. Юзайте дефолтний, або заюзайте популярний стандарт. Кому яка різниця чи є у вас після дужки пробіл чи ні. Необхідно думати про проблеми які ви хочете вирішити, а не про кодстайл який взагалі нікому не цікавий.

Разобравшись, я понимаю, что мой код нужно где-то хранить. Так как я уже порядком устал, выберу популярнейший GitHub. Настроив Git и авторизацию через ssh на моем компьютере, я понимаю, что я не знаю, какую систему ветвления использовать. GitFlow слишком избыточна, пока я один, но не коммитить же все в мастер-ветку? Мало ли к проекту кто-то присоединится, или, если я покажу репозиторий на собеседовании, все будут смеяться. Остаётся и непраздный вопрос, что писать в описаниях коммитов и на каком языке, но оставим это на потом.

Ну без гіта нікуди. Тут +1. Але заради вашої цікавості зробіть заміри скільки часу іде на налаштування.

Крок 1. В GitHub створюємо репозиторій (ну максимум 2 хвилини якщо ви не знаєте де клацати)
Крок 2. Копіюєте команди типу git clone/git init і все. У вас є git і пушайте туди все що душа забажає.

Автор оригінальної статті каже що не можна комітити в мастер і треба думати про якісь там флов. У мене є 9 проектів (або більше :D) у яких я комічу в мастер. Коли туди залітає код - я просто кайфую, бо у мене +1 локейшин де знаходяться дані. І нічого, 5 років політ нормальний.

если я покажу репозиторий на собеседовании

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

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

Писати код це не лайки у Фейсбуці ставити, тут думати потрібно. Це тернистий шлях сповнений безліччю перепон. Памятайте про це. Не вішайте носа, вчіться, пишіть код і радійте кожному скомпільованому рядку.

Deployment

Стоит подумать, как это все дело развернуть на хостинге. Если бек на Python, то нужно создать виртуальное окружение и работать в нем. Почему-то на сервере сходу это не получается, что-то вечно падает. Кстати, нужно запускать приложение как сервис, чтобы всё перезапускалось после падения! Всё, теперь точно берём Ноду!

Кек. Ще кубернетіс туди затягни що б 3 сторінки віддати. Це класичний приклад оверінжінірінгу. Якщо вам потрібний прости сайт - купіть хостинг на якому все є: nginx, mysql, php. Залив код і все працює. Якщо, десь в якісь паралельній вселеній хтось дізнається про ваш сайт і у вас буде 2тисячі відвідувачів за день аж тоді ви зможете подумати про переїзд на якусь іншу інфраструктуру типу digital ocean, aws, google cloud … До цього моменту це не потрібно.

Оцініть проект тверезо. У вас є метрики які підтверджують великі навантаження, або складність алгоритмів які мають виконуватись? На основі цих даних ви зможете подумати що вам треба і продумати стратегію.

Pre end

Ещё я не подумал, конечно, о TS, ES6, SASS, PUG, GraphQL, ООП, функциональном программировании, иммутабельности и обо всём таком. И нужно будет сертификат HTTPS прикрутить обязательно! Может, мне позвать в команду пару друзей, чтобы сделать всё правильно вместе? Тогда без Scrum и Pull Requests не обойтись.

GraphQL саме те що треба. Є проста формула: чим більше технологій ви стараєтесь вивчити тим менше технологій ви освоїте.

На этой ноте я устал окончательно и подумал, что, может, мне стоит откопать старую книжку по PHP, и сделать всё, как в 2013 году, когда я ни о чём выше не имел представления, а половина технологий ещё не появилась? Похоже, я слишком много думаю наперёд. Решу всё это потом, сейчас посмотрю сериал и пойду спать, а завтра точно начну программировать.

Треба просто почати писати і не задумуватись дуже сильно. За цей час, поки роздумували про проблеми, можна було б уже запустити сайт на якійсь CMS (або фреймворку) і продумувати структуру таблиць на оснвоі наших даних.

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

The end. My story.

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

Записувати в екселі не фонтан, інтерфейс складний для простої задачки.
Хороших аплікух без реклами не було (це було досить давно, можливо зараз щось є).
У молодих батьків дуже, ну дууууже напружені перші тижні. І буває таке, що ти не знаєш взагалі чи спав сам, не кажучи про мале чадо. Інтерфейс мав буте супер простий.

Я вирішив допомогти написавши просту веб-сторінку (зараз на це кажуть SPA на який можна було б це все робити. Технології:

javascript - не варто нічого компілювати, працює майже всюди. Не потребує бекенду.
dropbox - тут будуть зберігатись дані. Авторизація по OAuth, даєш доступ на створення збереження даних і все готово.
MaterializeCSS - простий css фреймворк який задовільняє мінімальні вимоги.
GitGub pages - мій хостинг. Нічого взагалі від мене не треба. Залив код - все працює. Назва домену не критична.

Тоді я написав javascript код який працював з Dropbox SDK. Працювало це все дуже просто. Заходиш на сторінку - авторизуєшся через dropbox auth. Дальше підтягуються дані з дропбоксу і показуються у вигляді таблиці. Різні типи записів - містили різні іконки. Коли жмеш на якусь кнопку виконується функція add

1
2
3
4
5
6
7


// Table - інстанс обєкту таблиці із DropboxSDK
var add = function (type) {
 table.insert({
 type: type,
 time: (new Date()).toString(),
 });
}

Це я тепер шарю що функція add impure і можна багато що удосконалити. Але це був 2015 рік і я тоді не був такий прошариний. Але код працював і вирішував проблеми. Що ще потрібно? На всю цю двіжуху я потратив декілька годин. Мені дуже подобалось що dropbox sdk, materialize можна було підтягнути з cdn. Ніяких npm install. Якщо у 2020 або дальше потрібно буде розв’язувати подібну проблему - я піду цим самим шляхом і навіть не буду роздумувати про всякі дрібниці типу code style (як мінімум до 100го коміту).

Суть історії в тому що ви можете швидко написати те що потрібно якщо у вас є вимоги та продумана стратегія.

Samsung vs Apple. NFC. Поле бою - Україна

Fri, 19 Jun 2020 10:48:01 +0300

Уявіть собі ситуацію. Є компанія Apple, яка не представлена офіційно в Україні. Наскільки мені відомо, AppleStore відсутній, служби підтримки також немає.

І є зовсім інша компанія Samsung. У якої це все є. Можна заїхати до них в магазин і купити собі телефон та іншу продукцію. Також є служба підтримки. Наскільки мені відомо у Samsung навіть є власний R&D центр в Україні.

Здається очевидно яка з компаній краща у даному двобої. Але є одне але…

Оплата годинником

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

Прогрес ~~іде~~ біжить, дуже швидко. І у 2020 році ви можете придбати смарт-годинник, у якого буде безліч кльових фішок. Одна з яких це оплата.

Ось тепер ми підходимо до раунду 2.

Питання: як компанія (Samsung), у якої все офіційно і є всі необхідні технічні можливості, не може надати користувачам можливість розплачуватись смарт-годинником. А от компанія у якої є просто технологія - змогла добитись успіху і зробити життя своїх користувачів неперевершеним.

У Samsung є своя система оплати Samsung Pay - вона не працює в Україні.

У Apple є своя система оплати Apple Pay - і вона працює в Україні.

Коротке відео від ПриватБанку як можна здійснювати оплату годинником.

https://www.youtube.com/watch?v=Hhy31gth87k

Ось вам вся історія яка мені просто виносить мозок. Як, як це взагалі можливо?

В чому прикол?

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

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

p.s. Стаття написана літом 2020, якщо ви читаєте її пізніше - можливо щось і зміниться.

Як я шукав php кодерів і що з цього вийшло

Mon, 30 Mar 2015 07:36:52 +0200

Одного разу мені доручили знайти чувака який буде шарити трохи в РНР. Це досить таки весела історія так як без жартів не обійшлось. Корисно буде для тих хто шукає або буде шукати роботу.

Отже, почалось все з того що потрібно було скласти список завдань. Вакансія junior php developer, але також я б назвав її php/web developer, так як треба було знати ще основи css/js це не було пріоритетом, але знати треба було.

Тобто junior має знати основи css js php. Має знати що таке клас і інтерфейс у php. В даній статті опишу як я проводив відбір кандидатів і які були кумедні випадки. Корисно буде як для досвідчених кодерів так і для тих хто шукає роботу у даній галузі.

Шукаємо девелоперів

Workflow

Я постарався піти по наступному принципу: відібрати резюме, назбирати 5-10 штук. Зідзвонитись з кандидатами. Протягом 2х днів провести всі співбесіди. Підібрати гідного кандидата і запропонувати йому випробний термін.

Пункт номер нуль. Відбір резюме.

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

Якщо немає ніяких технічних даних з чим працювала людина, я це резюме не розглядаю. Тобто якщо просто список технологій які знає програміст і більше нічого - я відсіюю його. Написати список зможе кожен, а от що ви насправді реалізовували на цих мовах/технологіях уже набагато складніше. Переважно списки новачки складають по технології ctrl+c -> ctrl+v. Чому? Та тому що вони думають що краще взяти здоровезний список і це буде зачот. Але для мене особисто це не показник.

Ідемо дальше. Наприклад, в резюме вказано з якими технологіями ви працювали і як - я його сканую за наступним правилом. А саме: наскільки ці технології корисні у компанії. Є такі кренделі які пишуть що шарять у фотошопі, ворді, екселі. Просунутий користувач ПК. Як на мене це смішно. Я раніше також був таким крендельом. Але це було багато років назад)) Дам пораду. Якщо ви створюєте резюме на посаду програміста - пишіть які саме ваші навички зв’язані з цією посадою. Ви ж не будете писати що вмієте малювати паркан, хоча ви дійсно це вмієте. Нікому це не цікаво. Хоча є 1% компаній які пишуть що їм треба гуру чувак який шарить у фотошопі, вміє верстати, шарить у ілюстраторі, розбирається у java, php, c++ і тд, але думаю це не для вас та і взагалі не для нормальних людей.

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

Посилання на github або на зроблені проекти. Звісно на github це кльово. Так як можна побачити код який чувак писав (скоріш за все писав). Дуже багато користувачів мають 1-2 дні контрібушина якраз за 1-2 тижні до відбору на роботу. Наскільки я можу вловити їхню логіку - треба щось запостити що б побачили що я крутий перець. Посилання на готові проекти або на ті у яких брали участь дають тільки представлення про те у якій канторі працював програміст. Фактично по них нічого реального оцінити по цьому пункту не можна.

хвилинка гумору Одне кумедне резюме це коли чувак замість symfony написав symphony. Можливо автозаміна або вручну виправив))

Друге кумедне резюме це 4 сторінки А4 13 шрифтом. Читати не перечитати. Для чого аж стільки тексту? Там по пів сторінки було розписано що чувак робив у проекті. І так про все)

Резюме у яких тіпи пишуть “просунутий користувач пк” особисто для мене це смішно. Ще один тіпок скинув посилання на zip архів з його кодом. Звісно це краще ніж нічого але краще вже на github =)

Підведу підсумок першого пункту:

Складайте хороші резюме.
Складайте лаконічні резюме (1-2 сторінки А4 норм). Пишіть тільки те що стосується вакансії + можливо ваші хобі або щось у тому роді.
Посилання на ваш код на github є плюсом, але тільки тоді якщо там дійсно код викладається протягом якогось періоду а не просто що б був.
Уникайте граматичних помилок особливо в назвах технологій.
Фото не обов’язкове
Вказуйте контактні дані.
Пишіть те що знаєте, так як вас можуть перевірити.

Пункт номер один. Загальне враження.

Коли приходить людина на співбесіду я починав з одного і того ж запитання. Над чим цікавим працюєте в даний момент? Це допомагає особисто мені побачити як людина спілкується. Що дійсно вона цікавого зараз робить. Були юзери які казали: ну цікаве, не знаю… зараз роблю те і те. Норм? Норм. Були юзери які казали нічого. Були що взагалі не знають що сказати)

Наступне я питав у якій ide вони працюють. Для тих хто не знає що це таке я питав у якій програмі вони пишуть код. Якщо юзер каже що ось такий то редактор а раніше був такий, це звісно плюс. Ті хто каже що пишуть у phpstorm, netbeans або якомусь подібному це також галочка. Також питаю чи знають що таке система контролю версій.

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

хвилинка гумору

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

У мене все сплановано. Якщо я кажу на 11:00 співбесіда тоді коли приходите на 10:55 норм, на 11:15 норм. Але був чувак який пришов на 20 хвилин раніше. Особисто для мене краще на вулиці 15 хв покрутитись аніж створювати незручності для тих хто вас приймає.

Підсумок:

Якщо ідеш на кодера спробуй щось перше покодь. Не просто стандартний hello world а якийсь міні проект. Цей же скорочувач урлів, або якийсь простий нотатник.
Чітко висловлюй свої думки. Вимова і ще раз вимова. Якщо хочеш дома потренеруйся перед дзеркалом.
Думай а потім говори: краще на 20 секунд задумайся а потім все скажи за один раз аніж розривай свою думку по середині на довгі паузи.
Важлива фішка - приходить за 5 хвилин до співбесіди. Віддихайтесь і будьте спокійні. Плануйте свій час.

Пункт номер два. Знання мови РНР та інших технологій

Можливо хтось скаже що це смішно, але багато людей дійсно не знають основ. Я задавав наступні запитання. Що таке клас? Абстрактний клас? Інтерфейс? Чим відрізняється інтерфейс від абстрактного класу.

Складно? Ну я хз але це проста теорія. Я не питаю у вас якісь специфічні рнр функції у яких ви можете без проблем переплутати послідовність параметрів або назву. Це можна все почитати в документації. Про класи і інтерфейси також, але вважаю що прогер має знати основні конструкції.

Прості задачки на sql ін’єкції, на знання css (media queries, спрайти)

Зробив задачу про рнр яка була складною. Навіть дуже. Але хотілось побачити як думають люди. Є кусок коду і потрібно розказати що він робить його переваги і недоліки. Замудрено все тим що в операторі if зустрічаються і && i and i || i or =)

В загальному оцінював як людина орієнтується у нових тенденціях, чи знає основу, як старається вирішити задачі.

хвилинка гумору

Були юзери яких я зловив на гарячому. Для прикладу один чувак у резюме написав що шарить в jquery я дав йому приклад і запитав що він робить. Чувак каже: не знаю. Я кажу ви ж писали що добре знаєте jquery. Які функції ви використовували у jquery бібліотеці - чувак мовчить. Ось така історія. Ця сама схема працює з усім. Якщо хтось написав що шарить і крутий тіпок у php а простого не знає то відповідно і жирний мінус не за те що не знає, а за те що старається обманути.

Підсумок:

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

Final

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

Знання грають роль, але є дуже багато факторів є які впливають на вибір кандидати. Ви можете все знати але буде заплітатись язик і ви провалитесь. Ви зможете знати мову рнр але в інших областях будете обманювати - вас також можуть не взяти на дану посаду.

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

Wget - огляд цікавих фіч і глюків

Fri, 18 Apr 2014 17:05:52 +0300

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

У цій статті я зроблю короткий огляд функціоналу який використовую + фікс одного цікавого глюку.

Як завантажити файли зі списку за допомогою wget

Якщо виконати команду wget -h ми побачимо безліч опцій. Ось опис нашої команди:

-i, --input-file=FILE download URLs found in local or external FILE.

У перекладі на українську це значить: завантажити УРЛки із локального або зовнішнього файлу.

Для прикладу у вас є файл serial_season_1.txt у якому знаходяться посилання на всі серії першого сезону. Що б їх викачати собі на комп’ютер достатньо запустити ось таку команду:

wget --input-file=serial_season_1.txt

Залишилось чекати, в залежності від швидкості вашого Інтернету. Ще однією з переваг такої штуки це те, що wget завантажує файли у такому порядку, у якому вони були вказані у файлі. Тобто перші серії прилетять до вас самими першими =)

Дозавантаження файлів

wget розумна тулза і шарить дозавантаження файлів. Для того що б кожного разу не починати завантаження з 0 необхідно використовувати опцію --continue.

 -c, --continue resume getting a partially-downloaded file.

Наша нова команда буде мати вигляд:

wget --continue --input-file=serial_season_1.txt

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

Глюк з кирилицею

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

Cannot write to &lsquo;01_Я+\321%82ак+\321%85о\321%87\321%83.mp3&rsquo;
(Invalid argument).

Я трохи погуглив, і зрозумів в чому прикол. Так як я php програміст і у мене встановлено php на усіх машинах, я і заюзав можливості цієї мови. Ось рішення моєї проблеми:

download-from-file-list(){
cat $1| while read line ; do
input=$(echo $line | php -r "echo trim(urldecode(file_get_contents('php://stdin')));")
output=$(basename "$input");
echo $output;
wget --continue "$input" -O "$output";
done
}

Використовуємо дуже просто:

download-from-file-list serial_season_1.txt

Ось фактично і все. Реальні потужності wget наздвичайно великі, це тільки початок.

Парсер сайтів на Xpath. Урок 1

Fri, 20 Jul 2012 11:11:52 +0200

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

XPath - XML Path Language. Для того що б не передруковувати вікіпедію напишу що XPath - це шлях до елементу. Тобто для того що б нам витягнути певний елемент з документу XML чи HTML нам треба знати де він знаходиться. Деякі факти про XPath

XPath - вираз який визначає частини документу XML
XPath - використовує опис шляху для навігації в XML документі
XPath - бібліотека яка включає стандартні функції
XPath - основний елемент в XSLT
XPath - стандартизований W3C

Ви не повірите, але перша версія XPath появилась в 1999 році. WAT???. На даний час затверджено XPath версії 2.0 Інші дані про XPath ви зможете знайти на вікіпедії а також на сайті W3C.

Перейдемо до прикладів і чому XPath краще в деяких випадках ніж регулярні вирази, на мою думку.

Для прикладу нам необхідно отримати всі посилання на сторінці.

Вираз буде наступний.

//a

а - означає імя тегу. Всі ми знаємо що а - це посилання :)

// - два слеші з початку означають що ми шукаємо посилання на будь-якому рівні документу.

В XPath ми працюємо з семантикою документа. Отже, є відносні й абсолютні шляхи.

Деякі прості приклади:

Отримуємо всі посилання які розміщені в параграфі:

//p/a

Отримуємо перший параграф

//p[1]

Отримуємо останній параграф

//p[last()]

Отримуємо всі елементи

//*

Як на мене за допомогою простого виразу XPath можна легко маніпулювати документом. Тобто Вам не потрібно писати багато РНР коду для того що б отримати останнє посилання в абзаці.

Як дізнатись шлях до елементу? Це дуже просто :) У всіх нормальних бравзерах є панель розробника там все написано. В самому низу і вказано шлях до елементу. Звісно писати повний шлях це маразм, а от вказати 2-3 параметра цілком логічно. Все залежить від структури документу.

Ось фактично основи XPath. Давайте тепер розглянемо як нам реально працювати з даними.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


$doc = new DOMDocument();
# завантажуємо нашу сторінку
$doc->loadHTMLFile('http://funivan.com/');
$xpath = new DOMXpath($doc);
# отримуємо всі ноди які є в документі
$elements = $xpath->query("*");
foreach ($elements as $element) {
 # Виводимо назву тегу
 echo $element->nodeName . '/<br>';
}

Ще декілька прикладів

xpath	опис
`/*`	Вибираємо всі елементи першого рівня
`//*[name() != 'a']`	Вибираємо всі елементи крім посилань
`//div[@class='text']//a"`	Вибираємо всі посилання у divi з класом text
`//[]"`	Вибираємо всі елементи у яких є хоча б 1н дочірній елемент
`//[not()]"`	Вибираємо всі елементи у яких немає дочірніх елементів

Для початку достатньо, не буду Вас сильно навантажувати. В інтернеті багато інформації про Xpath. Якщо щось не зрозуміло або просто є запитання та побажання пишіть коментарі =)

Наступний урок буде про функції в xpath. (Урок 2)

Ще через один покажу свій клас для xpath і опишу як в 3 рядки можна отримати все що хочеш із сторінки. (Урок 3)

Дякую за увагу. Погнали кодити ;)