×Закрыть

PHP: піти не можна лишитися. Лишитися

Image via Shutterstock.

Отже, ви пишете на PHP.

Більше того, навіть прочитавши мою попередню статтю, ви все одно вирішили продовжити гризти кактус і лишитися в межах екосистеми і далі. Що ж, я вас не засуджую. Сам, зрештою, такий.

Натомість, зі своєї висоти 23-річного сіньйора, спробую дати кілька порад, як зробити ваше співіснування з PHP приємнішим і кориснішим. Деякі з них можуть видатися вам відвертим капітанством, з деякими ви можете так само впевнено не погодитися. Ваше право. Стаття написана, в більшості, для мене самого, тому всі уточнення, заперечення і знущання над бидлокодом підуть усім тільки на користь. Поїхали!

1. Вивчіть, нарешті, PHP

Ні, я серйозно. Враховуючи, як сильно змінилися стандарти за останні кілька років, велика частина PHP-девелоперів не дуже добре собі уявляє, що зараз являє собою їхня мова. Що таке генератори, чим лямбда відрізняється від кложури і для чого в 7.1 додали closurefromcallable.

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

2. Вивчіть, нарешті, програмування

Прочитайте банду чотирьох, програміста-прагматика і все, що ставлять у списки «10 кращих книжок з програмування всіх часів». Окрім, напевне, Кнута. Він там для галочки. Як Толстой у списках художки.

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

Якщо чули десь термін — прочитайте, що він значить. Розберіться, нарешті, що таке той SOLID, про який всі говорять. Якщо ви досі не знаєте, чим абстрактний клас відрізняється від інтерфейсу чи як заборонити створювати об’єкт класу — з’ясуйте це раз і на все життя!

Розберіться в загальних рисах, як взагалі працює комп’ютер і мережа, що являє собою ООП і чому майбутнє (можливо) за функціональщиною. Для розваги взагалі бажано встрягнути у якийсь мережевий холівар. Бачили питання на Stack Overflow, де творець Docker з творцем Vagrant з’ясовують, що з них краще підходить для деплою і development environment? Почитайте, цікаво:). Якщо вам нудно, можете спитати в якомусь чаті, чи можна досягнути веб-скейлу без монги. Окрім купи лулзів, маєте шанс отримати корисні знання з інфраструктури.

Спробуйте олімпіадне програмування, якщо ще не пробували. Почати можна з codingame, а далі — як вийде. Можливо, сподобається і затягне всерйоз і надовго. Не те, щоб це вам знадобилося потім у роботі, але, наприклад, влаштуватися на наступну може і допомогти.

З цієї поради напряму випливає наступна:

3. Роздивіться навколо

Прочитайте кілька книжок по Джаві — Пехопешка рухається в її бік семимильними кроками. Напишіть кілька сервісів на Go або Scala. Коли ваш проект черговий раз хряпнеться під навантаженням, ви можете спробувати перенести ботлнек на окремий мікросервіс, додавши асинхронність. Повинно полегшати.

Розберіться, як деплоїти і оптимізувати вашу аппу. Часом проблеми зі швидкодією лежать зовсім не в коді, і, не знаючи теми, девопсам нічого не доведеш. З’ясуйте, чим Jenkins відрізняється від Teamcity і що нового приніс із собою Jenkins 2.

Пишете API — прочитайте про особливості REST і HTTP. Не пишете API — почніть їх писати, розділяючи моноліт хоча б на фронтенд і бекенд. Для того, щоб зрозуміти, що не так з вашим API, почитайте код мобільних додатків, що його використовують. Напишіть простенького клієнта і подивіться, в чому там можуть бути проблеми.

Словом, прочитайте попередню статтю і з миру по нитці нахапайтеся знань про навколишній світ. Коли наберетеся і повернетеся, настане час для наступної поради:

4. Розберіться, як написаний сам PHP

Почати можна з написання простенького розширення. Потім потрошки, маленькими порціями можна починати читати PHP internals. Не те, щоб ви відразу змогли написати свій RFC, але якщо вас затягне, є ймовірність, що ви отримаєте вплив на екосистему, перемістившись із користувача в творці. Невелика ймовірність, але є.

Якщо С вас лякає — спробуйте для початку Zephir. Я не впевнений у майбутньому цієї технології, але це може послужити своєрідним містком між PHP і C. Головне ж повірити у свої сили, а далі буде вже легше.

5. Зробіть коміт в крутий проект

Я навмисне уникаю загальних порад в стилі «контрибутьте в опен-сорс», бо загальних порад я і так вже тут надавав, а конкретики, як ви помітили, не так вже й багато. Тож ось вам вона.

В кожному проекті на гітхабі є вкладка «issues». Час від часу там з’являються реквести на якийсь функціонал, який основним розробникам додавати влом, але зрештою, вони б від нього не відмовилися. Це — ваш зоряний час.

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

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

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

6. Заглибтесь у фреймворки

Саме так, у множині, тому що якщо ви вже зациклені на якомусь одному, варто вилізти на свіже повітря і кинути погляд вліво-вправо. Фанатієте від симфи — поставте собі ларавель і наступний проект зробіть на ньому. Не розумієте, як можна використовувати щось крім ZF — зробіть бенчмарк мікрофреймворків і подумайте тричі, чи потрібен вам цей екскаватор. Звикли до вордпресу? Поставте собі принаймні Drupal, а вже з нього переходьте на важкі наркотики.

Не вірите у фреймворки? Вони для вас занадто загальні та перегружені? Поставте Phalcon і насолоджуйтеся швидкодією.

Занадто прив’язані до фреймворків? Спробуйте не використовувати їх узагалі. Зберіть проект з нуля тільки на композеровських пакетах. О, до речі:

7. Напишіть свій пакет для композера

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

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

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

8. Почніть писати тести

А якщо ви їх пишете, перевірте, чи робите це правильно. Роз’ясніть для себе, що таке TDD і чому в нього ніхто не вірить. Почитайте про PHPUnit, Behat/Codeception та інші способи автотестингу, аж до селеніума. Звісно, правильно, коли їх пише QA, але краще вже ви, ніж ніхто.

9. Виступіть на конференції або хоча б на мітапі

Це не так страшно, як здається. Якщо сумніваєтеся, походіть трохи на зустрічі найближче до вас і послухайте спікерів. Серед них явно буде така бездарність, що вас відразу переповнить рішучість. Тому що «гірше, ніж він, навіть я не зможу».

Підготовка до виступу дасть вам шанс глибше розібратися в якійсь темі, а якщо вам це випадково сподобається — у вашому житті з’явиться нове джерело гострих емоцій.

Ця порада, звісно, до PHP не має ніякого відношення, але не додати я її не міг. Сюди ж, до речі, можна додати написання текстів для технічного блогу чи сайтів на кшталт Хабру чи ДОУ. Текст писати навіть легше, ніж код, ось побачите.

І нарешті остання, головна порада для пехопешника:

10. Перестаньте вестися на тролів

Вони просто нам заздрять. Адже тільки у нас є $. А ще Фейсбук написаний на PHP. І взагалі, сімка — це вже нормальна мова програмування. Нічого спільного з четвіркою і всім таким. А ще кожен стек має свої переваги і недоліки, і демонізувати чи, навпаки, робити якийсь із них срібною кулею, це підхід, недостойний...

Ні, не працює? А якщо повторювати собі по кілька разів на день? Перед ранковою кавою? Ні? Ех... Піду поплачу, чи що...


P.S. Як завжди, ваша думка дуже важлива для нас. Якщо ви вважаєте, що написане — маячня, не оминіть розказати нам про це в коментарях. Якщо я щось забув — нагадайте мені про це. Якщо черговий раз бажаєте висловити думку про PHP... Що ж, просто підтримайте топовий коментар. Він все одно ж буде щось на кшталт «PHP — відстій!!!111». Я вас що, не знаю?

Лучшие комментарии пропустить

Ви одночасно і троль і мотиватор в одній особі.
:)

все так.
большинство тех кто использует php — не знают ни php, ни программирования.

моя добавочка:
Современный PHP роднит с Java больше чем синтаксис. Сам подход к дизайну крупных систем.

Иногда чересчур роднит, PHP как язык программирования более мощный, выразительный, чтобы писать boilerplate код, как то приходится делать на Java. А сама вычислительная модель PHP — «рожденный чтобы умирать» — наоборот слишком отличается от JVM, чтобы создавать множество уровней абстракций в системе, просто ради академической правильности.

Поэтому в первую очередь книга:
Современный PHP. Новые возможности и передовой опыт, Джош Локхарт
или www.phptherightway.com

Минифреймворки, как примеры кода, на котором стоит учиться, и конечно подискутировать с его авторами:
Zend Expressive
Aura
Phpixie
Slim

PSRы можете не использовать, но знать об чем они — обязаны.

а также:
Что должен знать Junior PHP разработчик

а если вы считаете себя спецом в Wordpress, то гуглить:
Как получить чёрный пояс по WordPress?

чтобы убедиться что вы и его не знаете, хоть уже сбились со счету, на скольких сайтах натягивали верстку.

По стилю кодирования обычно предлагают «Совершенный код».

Я предлагаю более простую, легкую для проработки, но с страшным названием
"Шаблоны реализации корпоративных приложений"- Кент Бек

там вовсе не про пресловутые паттерны, хотя и их потом стоит проработать.
но это — минимальный уровень который обязан знать программист.
все равно с опытом набивания шишек — придет к пониманию этих азов.

117 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

дес, из всех пунктов согласен только с четвертым, и сложилось такое чувство, что автор данной статейки реально где-то в небесах летает. Выучи современны пхп, 7.1, генераторы? Серьезно, если ты работаешь на проекте, которому уже 5 лет, он делает свою работу, то нах мне учить все выше перечисленное, если я его не буду использовать ближайшие 2 года. И таких людей как я, с проектами — бородачами, я уверен, дохрена. Мож где-то в закрамах Епамов и набирают 23х летних синьеров, что бы пидалили на симфони 3, но так не везде, имхо

Напишіть кілька сервісів на Go або Scala
I забудьте про iснування PHP) Не бачу причин, знаючи хоч той же Go, продовжувати писати на PHP, ну крiм хiба що якоїсь закоханностi в цю мову.

а какие причины, зная другие языки, писать именно на Go?

Писати можна на будь-якiй мовi, i причини в кожного свої. Мiй комент про php — якщо порiвнювати з ним — то переваги Go — строга типізація, синтаксис, якiй попереджує виникнення рiзноманiтних прихованих помилок — бiльшiсть з них будуть виявленi на этапi компiляцiї, бiльша продуктивність завдяки компiляцiї, в програмi на go значно простiше органiзувати яке-небудь кешування, фільтр Блума, hyperLogLog і багато інших речей, які допомагають взагалі не робити запити в базу при кожному зверненні. Для цього йому не потрiбнi редиси, memcached i т.п

простiше органiзувати яке-небудь кешування, фільтр Блума
В PHP це компенсується величезною к-стю готових перевірених часом бібліотек. Наприклад, в PHP 7.1 уже є стандарт PSR16, який скоро будуть підтримувати (дехто уже підтримує) всі основні бібліотеки для організації кешу. Фактично, в будь-який момент можна безболізно переключитися на іншу лібу правкою одного рядка коду. Той же самий фільтр Блума є у вигляді готових пакетів для composer — github.com/...rspartak/php.bloom.filter і т.д.
Строга типізація уже є в PHP 7.0, в PHP 7.1 уже є глобальний declare(strict_types=1);
Кому це реально треба, той перейде на 7.1 і буде щасливий. А якщо він реально дійде до етапу, коли можливості мови програмування будуть його обмежувати... дай боже кожному проекту/програмісту до такого дійти — перейти на Java/Scala/Go ніколи не пізно, от тільки це треба від сили 5%.

Круто, нiчого, що ваш фiльтр блума помре пiсля завершення роботи скрипта? Будете робити searilize i писати в базу? Пiдключайте, використовуйте. Я знаю, що в php МОЖНА. Багато що можна. Але для цього потрiбно робити нетривiальнi речi. Вiзьмiмо такий код в node.js або go:

var i = 0 // visitor counter
function requestHandler() {i++}

Покажiть тривiальний спосiб зробити це на php.

Круто, нiчого, що ваш фiльтр блума помре пiсля завершення роботи скрипта?
Нічого.
Будете робити searilize i писати в базу?
Буду.
Я взагалі не розумію, який сенс порівнювати Go і PHP — абсолютно різні задачі виконують, зі своїми плюсами і мінусами.
Нічого.
Буду
То який сенс у цьому?
Я взагалі не розумію, який сенс порівнювати Go і PHP — абсолютно різні задачі виконують, зі своїми плюсами і мінусами.
Який сенс порiвнювати уазик i тойоту, вони ж для рiзних задач. Одни для їзди по бездоріжжi, а iншi по мiсту. Тому потрiбно завжди їздити на уазiку. Плювати на безпеку чи комфорт. Плювати на те що усi використовують їх для їзди по мiсту)

Те, що Ґо не дохне після кожного реквесту не означає, що він не дохне взагалі і що важливі дані можна зберігати просто в пам’яті програми :) все одно ж у Редіс заганяти доведеться :)

Навiщо? O_O

ps. Я розумiю ще в основну базу, але в редис?

А що, в го вже з’явилися нормальні бібліотеки по роботі із XML? Я не кажу вже про аналог SimpleXML...

Ну, я не знаю ваших потреб в роботі з XML. Мене повністю задовольняє вбудована encoding/xml

Весь пакет, будь ласка: XSD, XSLT, XPath, XQuery, правильна робота з NS. Та й про DOM не забуваймо!

Ну чесно кажучи, в мене iнша специфiка, тому з цими iнструментами я не знайомий i навряд чи зможу оцiнити „нормальнiсть” нагуглених пакетiв.
github.com/lestrrat/go-libxml2
godoc.org/launchpad.net/xmlpath
godoc.org/...b.com/jbowtie/ratago/xslt
godoc.org/...com/jbowtie/ratago/xpath2
godoc.org/gopkg.in/xmlpath.v2
golanglibs.com/top?q=xsd

З libxml2 посміявсь. Це ж бібліотека на С.
xmlpath, xmlpath.v2 — кастомна незрозуміла фігня
xslt — нехай буде ок
xpath2 — незрозуміла функціональність

Перший вердикт — Go далеко до PHP в плані роботи із XML. І ще далі до Java

Перший вердикт — Go далеко до PHP в плані роботи із XML. І ще далі до Java
Ну, ви питаєте людину, що зізнається — він це не використовує.
Тож, навіть якщо інструменти і є, може про них просто не знати.
Занадто категорично робити висновок, що нічого схожого немає.
З libxml2 посміявсь. Це ж бібліотека на С.
Смiйтеся далi, адже go може використовувати C-шнi бiблiотеки. Це ж так смiшно.

Ви будете сміятися, але пехопе — теж :)

Знаю, працював на php десь 7-8 рокiв.

На go не вийшло написати? :D Ну, не плачте, ще буде шанс утерти тому дідусю Сі носа :D

Якась дивна у нас з вами розмова. Хiба я порiвнював Go з C (пишу i на тому i на тому)? Чи може запитував на чому написана github.com/...tree/master/ext/simplexml ? Ви запитали бiблiотеку, я зкинув лiнки. Ця бiблiотека на го, пiдключайте, працюйте з xml в Go, Яка вам рiзниця, як вона реалiзована?

Не бачу причин, знаючи хоч той же Go, продовжувати писати на PHP,
Я вам навів причини, чому на PHP можна продовжувати писати, навіть знаючи go. Бо go має вкрай погану підтримку XML-всесвіту. А про порівняння із Сі то був стьоб.

Ви правi, наступного разу, коли менi потрiбно буде працювати з xml обов’язково згадаю про php.

Я юзав лібХМЛ, працювало так собі, плюс доводилося в докер за собою купу шлаку тягнути.
В Ґо досі дуже сирі бібліотеки, якщо знайшов щось на ґітхабі з десятком зірочок — вже щастя.

Ну, тоді повернемося до цієї розмови через років 5. Поки що таргет-група go — дитячі забаванки не в ентерпрайз-секторі. Навіть PHP краще для цього підходить.

То ви звичайне трололо, а я даремно марную свiй час. Бувайте здоровi!

Що, обісрали улюблену мову, та ще й похапешники? :D
Не переймайтеся так. Треба перестати дивитися на світ зі сторони хейт/лав, а почати адекватно сприймати технології як є, знати їх позитивні та негативні сторони.

якщо знайшов щось на ґітхабі з десятком зірочок — вже щастя

Та невже:
goo.gl/Q5V8Iy
goo.gl/YqHc5P

Щось рiзниця не дуже вражає, може порахувати проекти з >1000 зiрочок?
goo.gl/1lbbUB
goo.gl/R7BuEi

На правах офтому: а нафіга xml в 21 столітті? Для конфігів є yaml, для контенту json. Може є щось не доганяю?
Ну, а для legacy досить і того, що було до цього.

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

Та це ясно. Я мав на увазі для чого на нових проектах віддавати дані в xml замість REST API.
Не бачу ніяких переваг, окрім wsdl.

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

Що, похапе погано працює з сучасними форматами даних?

Яку з проблем воно вирішує?

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

Працював. Не зрозумів. Тільки wsdl приходить в голову.
Це машинний формат, його незручно читати, незручно конвертувати.

Це машинний формат, його незручно читати, незручно конвертувати.
WAT? O_O

ну, то давай зберігати дані в двійковому форматі — надійно, валідно.
Дані в будь-якому випадку зберігаються в чистому вигляді в базі. І замість того, щоб один раз якісно написати api, з якою всі будуть працювати так, як їм зручно, одні спочатку героїчно формують цей xml, щоб потім інші героїчно його парсили. Я не розумію для чого ця зайва робота. Написати якісну REST API — краще, ніж формувати xml.

Те, що це зручно тобі, не означає, що це зручно всім. Хто зараз віддає дані в xml? Банки, які працюють по принципу «працює — не чіпай»?
Ніколи не думали, чому RSS помер зі своїм XML? Може, він нафіг нікому не треба?

Дані в будь-якому випадку зберігаються в чистому вигляді в базі
В якому саме? П’ята форма нормалізації? Це безглуздо, хоча й красиво й пафосно виглядає. Дані можна зберігати напряму в XML.
Я не розумію для чого ця зайва робота
Ну дик з цього й треба починати. Ще раз, XML дозволяє вам дешево маніпулювати структурами даних, концентруючися на процесі обробки з максимальною абстрактністю, яка тільки можлива. Витрати на конвертацію та парсинг XML — ніщо у порівнянні на кількість галєро-годин, які треба витратити на обслуговування чистих даних.
Написати якісну REST API — краще, ніж формувати xml.
Один раз? А переробляти?
Банки, які працюють по принципу «працює — не чіпай»?
Банки не тупі й вміють рахувати гроші. Якщо б вони використовували «якісні REST API», вони б засипали прокльонами всіх розробників такого API. Або не купляли сервіс (що швидше трапиться). Тому що структури даних в банках, по-перше, капець які складні, а по-друге, постійно міняються.
Може, він нафіг нікому не треба?
Він помер не від того, що він XML, а тому, що його бізнес-значимісь була вбита соцмережами.
В якому саме?
plain text
Дані можна зберігати напряму в XML.
Це можу бути корисно для 2% всіх проектів, з якими доведеться стикатися. Жорсткий overhad — а якщо ці дані треба постійно змінювати?
Дістаємо з бази xml, парсимо, вносимо зміни, генеруємо новий xml і зберігаємо назад в базу? Серйозно?
Ще раз, XML дозволяє вам дешево маніпулювати структурами даних, концентруючися на процесі обробки з максимальною абстрактністю, яка тільки можлива
Для цього придумали ORM — ось, де максимальна абстрактність.
Один раз? А переробляти?
Що значить переробити? Проекти пишуться не для того, щоб їх перероблювати.
Додати новий callback для API нічим не важче, ніж генерувати на льоту необхідну xml.
Банки не тупі й вміють рахувати гроші.
Це legacy і не більше того. Якби всі ці банки зароджувалися зараз, ніхто б про xml і не згадав. Багато людей користуються SOAP? Так, такі є, але скільки їх?
Він помер не від того, що він XML, а тому, що його бізнес-значимісь була вбита соцмережами.
... які працюють через REST API?))
plain text
XML теж
а якщо ці дані треба постійно змінювати?
Змінюйте запити до даних. Самі дані не треба змінювати. XML дозволяє використовувати різні структури даних в одній базі, в одній «табличці». Ніякої міграції не треба робити взагалі
Для цього придумали ORM — ось, де максимальна абстрактність.
Бугагашеньки. Спробуйте зробити варіант, що описаний мною вище.
Що значить переробити?
Бізнес та технології не стоять на місці. Все змінюється. І чим простіше вам вносити зміни в вашу поробку, тим більше ваша цінність. /
Якби всі ці банки зароджувалися зараз, ніхто б про xml і не згадав
Бугага. Зараз навпаки це стало ще дешевше. А об’єми даних та їх структура ще складнішими.
... які працюють через REST API?))
Які працюють по-іншому. Сутність роботи з даними інші. Ніяких переваг від JSON там немає.
XML теж
те, що і те, і інше зберігається в text полі, не робить xml plaintext.
Plain text is different from formatted text, where style information is included
Змінюйте запити до даних. Самі дані не треба змінювати.
Кому не треба? Тобі не треба? Мені, наприклад, треба.
XML дозволяє використовувати різні структури даних в одній базі, в одній «табличці».
Ти жорстко прив’язуєшся до конкретної реалізації, ORM дозволяє в будь-який момент маніпулювати даними на бажаному рівні абстракції.

От візьмемо умовний клас User, у якого є firstName, lastName і email. Ти реально пропонуєш все це пихати в xml і зберігати в текстовому полі?
Якщо ні, тоді для чого взагалі xml, якщо є ORM?

Я ж не стібуся чи ще щось, я реально не бачу вигоди.

те, що і те, і інше зберігається в text полі, не робить xml plaintext
Виродити слабо?
Кому не треба? Тобі не треба? Мені, наприклад, треба.
Всім треба. Читай уважно спілкування.
Ти жорстко прив’язуєшся до конкретної реалізації, ORM дозволяє в будь-який момент маніпулювати даними на бажаному рівні абстракції.
XML дозволяє маніпулювати потоками даних. Без зайвої конвертації в об’єкти мови програмування. ОРМ — це костиль для тих, хто живе в світі XML. Бо база може повертати готові, оброблені структури, які не треба нікуди конвертувати зайвий раз, кидай на темплейтинг або в шину, все, готово.
От візьмемо умовний клас User, у якого є firstName, lastName і email. Ти реально пропонуєш все це пихати в xml і зберігати в текстовому полі?
Ти мислиш класами, я а мислю структурами. Мені байдуже на клас User, бо його презентація буде на рівні DOM, як контейнер для будь-яких даних. Але, відповідаючи на твоє запитання, так, я пропоную так зробити для СУБД, які підтримують індексацію XML. Тоді запит даних користувача, в тому числі його ACL, буде лише ОДИН. Без смс JOIN’ів, без реєстрації зайвих рухів.
Якщо ні, тоді для чого взагалі xml, якщо є ORM?
Ти не працював із XMLDB. Тобі ORM здається верхівкою розвитку комунікації MW <-> DB. Але світ не сходиться на ОРМ, є й інші, більш прогресивні архітектури. Тільки треба відірватися від сутностей «об’єкт», «таблиця», «реляція», та перейти до «структура», «потік даних», «обробники». ;)

Ну, от — це корисно для жорсткого enterprise продукту, яких мало. Я це саме писав вище.
Я ж не казав, що це позбавлено сенсу, просто дуже вузькоспеціалізоване рішення. На цьому і зійдемось.

А вам не здається, що ми говоримо про PHP і, відповідно, про «класичну веб-розробку»? Те, що ви писали вище звучить солідно, але явно виходить за тему, яку піднімали з самого початку.

А вам не здається, що ми говоримо про PHP і, відповідно, про «класичну веб-розробку»?
А що таке «класична веб-розробка»?
Те, що ви писали вище звучить солідно, але явно виходить за тему, яку піднімали з самого початку.
Тема, яку я підіймав, стосується зрілості мови програмування.

В Rocket Internet завезли хорошее PHP?

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

Ще б час для цього всього знайти. Десь в років 40 і одружитись можна буде. І в 50 завести дітей.

А когда в программирование шёл не предупреждали что учиться и развиваться нужно будет постоянно?

Коли я в програмування йшов ще у всіх навіть інтерне по діал апу не дуже був.

Так тогда предупреждали? Просто мне с самого мелкого возраста как только выбрал программирование будущей профессией постоянно повторяли что перестать учится нельзя будет никогда и что на это будет уходить львиная доля времени.

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

Да ладно. Были инженеры и прочие люди что постоянно работали с ЭВМ. Фирмочек не помню (мал был), а было это ещё в 94м. Да, в гос. конторе. Где ещё тогда могла стоять вычислительная техника? И я, приходя туда ещё совсем ребёнком на работу к маме, уже знал что для того чтоб работать с этими замечательными штуками (персоналками в обиходе) нужны программы, которые пишут программисты. Вот, одним из таких программистов я и хочу быть, а для этого нужно постоянно учится как говорили те, кто уже программист.

Чого ви ототожнюєте свій досвід з моїм? У мене на факультеті вчилось 90 людей. Поняття хто такий програміст мали тільки пару людей у кого вже батьки або близькі родичі були програмістами. І вони це не пояснювали нікому. Інтернету не було, в книжках не писали, англійську нормально ніхто не знав. Де було дізнатись хто такий програміст? Піти працювати на фірму програмістів.

Серьезно? В Ваше тогда, все кто хотел — знали что такое программирование. В 91 (это то, что я знаю и куда ходил) уже были компьютерные «клубы». В 92 УПК в ХИРЭ с фортраном и архитектурой ПК. Тогда же первые банковские системы написанные на коленке. Тогда же и первые компьютерные фирмы, в которых начинали формошлепить и то что Вы называете «программированием». И не поверите, за 20 дет до этого тоже были програмисты. И вот им нужно было постоянно учиться. А к вам, да, хлопци приходили. Смешно.

Не все жили в крупном городах) В маленьких и средних городах -максимум были компьютерные клубы на спектрумах..Ну и компьютерных фирм не было тоже ,понятно дело, ну может и были ,но единицы..

Это правда, но товарищ лет на 7 моложе, те это конец 90х

1 година робочого часу в день. Роботодавець вам через рік подякує, це гарна інвестиція. Тим більше що професіоналам платять не за роботу, а за рішення проблем. Тільки вам вирішувати, що входить в це рішення. Якщо ж вам роботодавець такої можливості не дає, то ви для нього всього лиш робоча сила і я вам раджу міняти роботу доки ринок дозволяє.

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

Хто Вам мішає заюзати якусь нову фішку рнр при вирішенні задачі і розібратись з нею? Як на мене це і буде навчання за яке платять ;)

Нащо витрачати час на таку роботу? У вас в запасі є десь років 30 максимум, на одній роботі ви в середньому пропрацюєте 3 роки. Чи варто витрачати 10 відсотків свого продуктивного життя на такого роботодавця?

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

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

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

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

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

Вітаю. Я радий що ви змогли організувати навчальний процес.

Чисто за означенням, ви зараз не на галері, а в оспівуваній віками «продуктовій компанії». Галерами зазвичай називають аутсорсові фірми, що продають тушки на вагу і самі ніколи нічого не виробляли. Тобто з певним допуском Рокет сам по собі галера, але Кармуді вже ні :)

Так-так, ми продуктова компанія. Але з точки зору процесів в багатьох рокет стартапах це та ще галєра)

Учитывая количество вакансий требующих знание РНР, говорить о его смерти рановато. Я даже думаю пройти пару онлайн тренингов по нему, чтоб так сказать углубить и расширить.

stackoverflow.com/...neer-wikimedia-foundation

Если ты PHPист можно получить удалённую работу в Википедии)

PHP — відстій!!!111

:-)

Вибач, друже, не втримався

це прекрасно

А потом таки забросьте PHP, потому что проектов таких чтобы не деградировать на них попросту или нет. Или вас там возьмут с опытом enterprise java (подставьте что-то другое по вкусу) over 9000 years

У вас там в реакторі така умова при влаштуванні — хейтити все, що пов’язано з php, на рівні підсвідомості?:-)
Ти запізнився зі своєю дуже цінною порадою на один топік, там це було доречніше.

Більше того, навіть прочитавши мою попередню статтю, ви все одно вирішили продовжити гризти кактус і лишитися в межах екосистеми і далі. Що ж, я вас не засуджую. Сам, зрештою, такий.
Статтю не читай — відразу коментуй?

Вы вообще о чем? Статью я прочитал почти всю и согласен с каждым её пунктом, а когда-то относительно недавно я плотно варился в php мире и эти пункты (не все правда) выполнял.
Вы в каком слове увидели php-хейтерство?

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

Еще разочек:

Вы в каком слове увидели php-хейтерство?
Пусть даже в завуалированном виде.

Мне очень просто объяснить свои 2 предложения, но сначала вы

В повчанні, що

А потом таки забросьте PHP, потому что проектов таких чтобы не деградировать на них попросту или нет.

Я с своем, как вы говорите, «поучении» вижу только хейтерство бОльшего количества проектов, что крутятся у нас на локальном рынке. Начинается это с обычных, казалось бы, процессов (code review, testing, versioning, ci) заканчивая выбором инструментов, архитектурой и людьми (если у вас на проекте/компании/etc люди умные, это вовсе не значит, что так повсеместно, в конце концов такие вот статьи в 2016(!) не просто так пишутся). Я опережу тут и напишу, что естественно, это применимо для любых проектов на любых технологиях, но только php мир может гордиться своим огромным списком контенто-помоек и интернет-магазинов (которые на 99% состоят из тривиальнейших задач, которые лично мне как человеку, что хочет развития и профессионального роста, делать второй раз уже отвратительно). Ну и фейсбуком, ага.

Мы же не ремесленники, которые колотят зарплаты в долларах и верят в стабильность не анализируя свои предпочтения с точки зрения актуальности/востребованности когда-нибудь через n лет, а технари и нам важна нарастающая сложность выполняемых задач, расширение кругозора, понимание других инструментов на уровне «какую проблему оно решает и как» и люди, которые умнее вокруг.
В наших реалиях, на нашем рынке, с нашими проектами развиваться невозможно.

Заканчиваем с бОльшим количеством проектов, переходим к меньшему. Для этих проектов требуется соответствующая квалификация (и не обязательно это связанно с php). Т.е. у нас есть нерезиновых мест 200-300 (если не меньше) по всей Украине для действительно крутых людей.

Так вот если вы дочитали до сюда, вы должны были заметить, что ни одного плевка в сторону php не было. php — относительно быстрый язык программирования, как с точки зрения работы ПО, так и создания этого ПО.

Я с своем, как вы говорите, “поучении” вижу только хейтерство бОльшего количества проектов, что крутятся у нас на локальном рынке.
На минулому місці роботи у нас був цікавий стартап з хорошими інвестиціями і сучасними технологіями. Якщо у когось не склалося, то можна знайти інше місце для того, щоб поплакатися на низьку якість проектів.

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

Чесно кажучи, я досі не розумію для чого ти сюди встряв, абсолютно ж не по темі пишеш.

ayfkm?
Камни брошенные в целую компанию по треду собери, php police.

Т.е. у нас есть нерезиновых мест 200-300 (если не меньше) по всей Украине для действительно крутых людей.
это не только у вас.

отрывки из очередной статьи (о российском рынке)
... Более 62% компаний испытывают дефицит сотрудников, то есть для выполнения имеющегося объема работ не хватает человеческих ресурсов, что в значительной степени создает барьеры для дальнейшего развития системы продаж в компании.
... АРТВЕЛЛ (крупнейший разработчик в РФ в государственном секторе и крупном бизнесе) провел небольшое исследование. Мы взяли подряд 228 компаний из рейтинга веб-студий и всем отправили предложение: "Платим миллион(росс рублей) за трех программистов ... Заключение этого исследования поражающие — большинство веб- студий на рынке не имеют собственных программистов.
...Кадровый дефицит является ключевым фактором, тормозящим развитие компаний в нашей отрасли.
Веб-разработка: поезд ушел, а пассажиры остались?

Руби очень близок к PHP, и большинство руби/рельсо-ориентированных контор набирает и переучивает с PHP. Комментарий светится отчаянием личного опыта. И вправду, тяжело работать на пыхе в захолустной шараге, потом пойти на руби в приличную контору, и не составить мнения «всё на PHP — отстой».

Хорошие/интересные/сложные проекты на PHP, разумеется, есть.

Да, когда я однажды искал работу у меня был список того, чего я хочу от проекта (в основном, это штуки связанные с профессиональным развитием), и да, не нашел. Сходил и в

захолустной шараге
и в лидеры рынка, что-то не очень как-то. Это на тему личного отчаяния. Мне просто недостаточно просто ковать/грести и получать зарплату в долларах.

У меня к вам вопрос, с чего вы решили, что

потом пойти на руби
?

Нынче в

руби/рельсо-ориентированных контор
не только руби/рельсо водится.

Друже, не ображайтесь, але у вас в лінкедіні 3 останніх роботи 11, 9 та 4 місяці. Як ви можете судити про те що пхп гімно а рубі це круто, якщо по суті ви ні того ні іншого не знаєте?

Вы просто не судите по себе. Если для вас нормально, что за 2 года сложно выучить язык, то у меня для вас плохие новости.

Ну и еще и к вам тот самый мой любимый вопрос. Где же вы нашли

пхп гімно а рубі це круто
?

Я лишь говорил, что проекты в большинстве — говно и способствуют деградации.
И тут же высосали из пальца (или еще откуда-то), про Ruby и RoR.

Я вот не могу понять, из меня тут пытаются сделать тролля, хотя я вообще почти ничего про язык не говорил, не делал сравнений и настаивал на профессиональном росте и расширении кругозора. И тем более, ни разу (ни разу, Карл!!!) не упоминал про Ruby. Да, и не пишу я на рельсах.

И Питон близок к PHP и Перл , в общем любой скриптовой язык)
А кстати не фига не похож руби на ПХП..рельсы да, похожи потому что веб-фреймворк всегда чем-то похож на другой веб фреймворк или CMS. Но в самих языках, вижу мало похожего. руби- язык более высокого уровня и общего назначения. Конечно вышла 7-я версия ПХП ,в общем вы вбросили)

руби- язык более высокого уровня
чем PHP? какими синтаксическими и семантическими возможностями?
руби- язык более высокого уровня и общего назначения
общего назначения — это что имеется ввиду?
пресловутые «драйвера видеокарт» на руби можно писать?

или речь о том что транслятор PHP не любит держать все приложение в памяти, между запросами к нему? а разве специфика работы транслятора — влияет на свойства ЯП?

если же о качестве трасляторов
benchmarksgame.alioth.debian.org/...e.php?lang=php&lang2=yarv

Конечно вышла 7-я версия ПХП
зачем 7ую — возьмите 5ую — и ответьте на вопросы выше :)
какими синтаксическими и семантическими возможностями?
кстати, да. даже аннотаций-декораторов нет

ну, там много чего решается с помощью средств метапрограммирования.
собственно только это и является сейчас уникальной фичей среди 20тки Tiobe
на моей памяти была попытка повторить эту фичу, в Nemerle.

но считать ли метапрограммирование признаком более высокоуровневого ЯП?

скажем Scala — да, годится для такого звания. да даже Perl 6ой, сгодится, поднаворотили там немало.
А Ruby... его слава в прошлом.

Сейчас он как ЯП, ничего не может предложить для увеличения скорости разработки при сохранении ее качества.

но считать ли метапрограммирование признаком более высокоуровневого ЯП?
а почему б и нет?
дает ли возможность абстрагироваться от реализации(как, например, GC вместо выделения памяти вручную)? даёт же
скажем Scala — да, годится для такого звания. да даже Perl 6ой, сгодится, поднаворотили там немало.
а тут вы от чего отталкиваетесь?
а тут вы от чего отталкиваетесь?
в случае с Scala — более развитой семантикой создания и контроля типов.
с Perl 6 — крутым замесом семантики в зависимости от контекста синтаксиса.
а почему б и нет?
понатыкать в том же PHP evalов, а потом написать диалект, где evalы спрятаны...
то есть возможность самомодификации кода — это скорее свойство транслятора, а не ЯП.

вот попытка Nemerle да, была интересной. не следил, чем там баталии Nemerlистов на RSDN сейчас закончились.

понатыкать в том же PHP evalов, а потом написать диалект, где evalы спрятаны...
и даже близко не получить возможностей метапрограммирования Руби:)

близко, далеко — не суть.
вопрос о самом метапрограммировании, как признаке.

Перл тоже язык сверх высокого уровня ,как и Руби, да и Пайтон в принципе..
VHLL.

Я упоролся, пытаясь понять два простых предложения. Прям аж напомнило ruby-синтаксис.
stdout.in/...et-or-we-like-to-hate-php почитайте, там еще забавная ссылка на реддит тред в тексте есть.

Ненавижу Rails, статью даже не стал читать.

Да вы и эту похоже не читали.
Там не про Rails

перевод на хабре

habrahabr.ru/post/306564

мне там комменты особенно нравятся. тех кто не понимают что значит «Ruby умер», доказывая «аргументом блондинки» — ну я же не один год пишу на Руби, и недостатка в заказах не видно, и оплата — ого-го!

потому что не понимают почему, и как применяется слово «умер» к какой-либо технологии

Це питання не до мови програмування а до ваших пм та селлер менеджерів.

все так.
большинство тех кто использует php — не знают ни php, ни программирования.

моя добавочка:
Современный PHP роднит с Java больше чем синтаксис. Сам подход к дизайну крупных систем.

Иногда чересчур роднит, PHP как язык программирования более мощный, выразительный, чтобы писать boilerplate код, как то приходится делать на Java. А сама вычислительная модель PHP — «рожденный чтобы умирать» — наоборот слишком отличается от JVM, чтобы создавать множество уровней абстракций в системе, просто ради академической правильности.

Поэтому в первую очередь книга:
Современный PHP. Новые возможности и передовой опыт, Джош Локхарт
или www.phptherightway.com

Минифреймворки, как примеры кода, на котором стоит учиться, и конечно подискутировать с его авторами:
Zend Expressive
Aura
Phpixie
Slim

PSRы можете не использовать, но знать об чем они — обязаны.

а также:
Что должен знать Junior PHP разработчик

а если вы считаете себя спецом в Wordpress, то гуглить:
Как получить чёрный пояс по WordPress?

чтобы убедиться что вы и его не знаете, хоть уже сбились со счету, на скольких сайтах натягивали верстку.

По стилю кодирования обычно предлагают «Совершенный код».

Я предлагаю более простую, легкую для проработки, но с страшным названием
"Шаблоны реализации корпоративных приложений"- Кент Бек

там вовсе не про пресловутые паттерны, хотя и их потом стоит проработать.
но это — минимальный уровень который обязан знать программист.
все равно с опытом набивания шишек — придет к пониманию этих азов.

P.S.
и еще по книгам.

Их сложность это как водительские категории
C,D,E
Алгоритмы. Построение и анализ. Т.Кормен, Ч.Лейзерсон, Р.Ривест, К.Штайн.
Искусство программирования. Кнут Д.Э.

можно пропустить, или отложить на потом
а вот на B
Алгоритмы + структуры данных = программы Н. Вирт
надо.

считаете что SQL знаете, понимаете?
ну тогда попробуйте упражнения на www.sql-ex.ru

и
MySQL. Оптимизация производительности, Бэрон Шварц, Петр Зайцев, Вадим Ткаченко, Джереми Заводны, Арьен Ленц, Дерек Боллинг
(3го издания на русском еще нет, но для категории B хватит и 2го издания)

считаете что SQL знаете, понимаете?
ну тогда попробуйте упражнения на www.sql-ex.ru
Они кажись все. Либо это доу эффект.

ха, точно. но на момент когда публиковал ссылку — проверял, работал.

думаю и англоязычные есть, где в онлайне можно делать упражнения, а оно тебе еще план запроса выдает.
ну, или настроить у себя локально, и по какому-то учебнику порешать задачки.

на sql-ex.ru была (может уже нет) спорная, но очень интересная секция. где схема БД была без первичных ключей, а задания на селекты и инсерты — обычные.
спорная — народ гневался — в жизни не бывает таких схем!
а как по мне — очень классная в учебном плане, для понимания. а не дергать по первичному ключу, как будто это key-value storage, а не реляционная БД

На предмет DB вот еще интересный микротест:
use-the-index-luke.com/3-minute-test
собрать бы dou-статистику

по тому что я часто вижу в коде — многие, очень многие (если не большинство) даже ORMами пользоваться не умеют.

недавно, Yii2
Тянет таблицу, ActiveRecord’oм, следующей строкой проходит в цикле по запросу по одной подчиненной таблице, после, в другом цикле, по другой.
итого 1100 запросов.
а в with их прописать — мама не велела?
итого что-то там 150 запросов вышло.

спрашивается — это нужны какие-то великие усилия, чтобы with поставить? или нужно прочесть страничку, на русском(!) о жадной загрузке в Yii2?

вот не знаю, что в головах... опилки? вата?

...а может это я такой перфекционист, а автор в курсе что запросы будут закешированы сервером БД, «так зачем напрягаться, with ставить, — преждевременная оптимизация — зло!» и т.д. ...

та ну, по ссылке ж азы

Ещё Мэтт Зандстра «PHP объекты, шаблоны и методики программирования» неплохая книга, чтобы с паттернами в контексте PHP ознакомиться.

Пхп-шники считают, что Толстой — «для галочки». Теперь все встало на свои места, спасибо.

водночас щодо Кнута все ок? :-)

После первой статьи однозначно плюс. Все стало на свои места. Тролль-мотиватор. Лучше и не скажешь.

Ви одночасно і троль і мотиватор в одній особі.
:)

Подписаться на комментарии