Php создатель: почему он именно такой и что с ним будет

Содержание

почему он именно такой и что с ним будет — рассказывает создатель языка

О себе (00:00 — 02:20)

На сцене создатель PHP, Расмус Лердорф.

00:00 Короткое представление. Родился в 60-х в Гренландии. Несколько слайдов из семейного фотоархива.

01:25 Начало работы с компьютерами. Ретроспектива.

Начало пути (02:21 — 08:43)

02:21 Октябрь 1994. Выход браузера Mosaic, начало отсчёта.

02:54 API для C. С появлением графических браузеров встала проблема с реализацией CGI. HTML-код внедрялся напрямую в программы на C или Perl. Было желание это изменить и писать HTML со вставками кода, реализующими какую-то логику. Первый прототип предлагал вставлять в HTML «теги» — функции, написанные на C. Однако проблема оказалась в том, что никто не хотел писать функции на C.

06:53 Создание языка. Существовавшая система шаблонов была слишком примитивной. Она представляла собой машину состояний и не могла обрабатывать простейшие математические функции. В то же время именно простота системы делала её привлекательной.

Ключевые моменты развития PHP (08:44 — 16:26)

08:44 Четыре базиса эффективной системы. Работоспособность системы определяется взаимодействием четырёх компонентов: операционной системы, веб-сервера, языка скриптов и базы данных. Именно эти четыре элемента отражены в акрониме LAMP.

09:19 Интеграция PHP с Apache. Шаг, значительно увеличивший быстродействие системы. Хотя другие языки были значительно быстрее, проблема была в том, что они сами выступали в роли CGI. Впоследствии Apache получил встроенную поддержку Perl, но из-за нюансов работы модуля mod_perl было невозможно запускать его в качестве виртуального хоста на одной машине с другими виртуальными хостами. PHP позволял делать это.

11:48 Концепция песочницы. PHP создан таким образом, чтобы не оставлять ничего лишнего после выполнения кода. Состояние системы не сохраняется на сервере, и если разработчику требуется передать какие-то данные после выполнения кода, он должен прямо это указать. Лердорф считает это преимуществом языка.

12:17 Многопоточность. По мнению создателя PHP, многопоточность делает систему менее стабильной, ошибка в одном из потоков приводит к падению всего комплекса.

13:55 Базы данных. MSQL, предок MySQL, был идеален для небольших веб-приложений. Однако он не предусматривал ограничение на количество возвращаемых строк. Придумана директива LIMIT в SQL. ANSI SQL до сих пор не предусматривает ограничение на количество строк, но теперь есть в каждой СУБД. Были введены max_execution_time, memory_limit и safe mode ради большей привлекательности PHP для ISP-провайдеров.

Не баги, а фичи, или Почему я сделал именно так (16:27 — 26:43)

16:27 Игнорирование регистра в именах функций. Во время бурного развития HTML разработчики не могли определиться со стилем написания тегов, поэтому имена функций должны были подходить к любому стилю.

19:04 Переменная $Globals. Введена для того, чтобы избежать конфликтов имён глобальных переменных в разных модулях кода.

22:20 Директива register_globals. Упрощённая инициализация переменных делала веб-разработку более доступной.

23:22 magic_quotes. На самом деле автоматическое экранирование появилось для единоразового упрощения разработки. Лердорф ввёл его для собственного удобства и не ожидал, что его будут использовать другие.

24:24 Совместимость. В PHP реализована вертикальная совместимость. Этот метод был выбран, так как соответствует естественному способу развития кода, с постоянно появляющимися расширениями и надстройками. Горизонтальная совместимость потребовала бы гораздо больших усилий по структурированию языка и прогнозированию развития информационных технологий.

Статья по теме: Почему многие программисты считают PHP плохим языком? — отвечают эксперты

PHP 7.3 — что новенького (26:44 — 41:34)

26:44 Новые фичи в PHP 7.3. Heredoc стал более гибким, введено предупреждение о continue в switch, упрощённый синтаксис list теперь поддерживает ссылки, добавлена поддержка ведущей запятой в вызове функции. Добавлена новая функция Monotonic Timer, не привязанная к системным часам. Ещё одна новая функция, fpm_get_status(), пригодится для создания панели мониторинга вроде Apache Scoreboard. is_countable() позволит определить, является ли объект массивом или реализует Countable интерфейс. array_key_first и array_key_last возвращают первый и последний ключ массива.

31:20 Возможная несовместимость со старыми версиями PHP. PCRE 2 будет выдавать ошибку при обработке недопустимых символов. В отличие от PCRE 1, это прервёт выполнение кода. Ошибку легко отследить в логе.

34:02 DCE. В PHP 7.3 улучшена функция отслеживания и удаления ненужного кода. Оптимизатор научился работать с массивами и прослеживать возможные эффекты, выходящие за рамки обрабатываемой функции.

39:40 Сравнительный анализ быстродействия различных версий PHP на примере WordPress 4.9.8 показывает стабильный рост скорости. Анализ использования памяти на примере WordPress 4.3 отражает большую эффективность использования ОЗУ. С января 2018 осуществляется поддержка PHP версии от 7.1 и выше. Для более ранних версий не выпускаются даже обновления безопасности, и их использование довольно безответственно, особенно если проект работает с личными данными.

Дополнительные инструменты (41:35 — 50:05)

41:35 Статический анализ. ПО для статического анализа своего кода можно найти на github.com/phan/phan. Инструмент проводит огромное количество проверок, при этом фильтры ошибок настраиваются, чтобы можно было отделить критические от менее важных.

44:26 PHPSPY. Инструмент для мониторинга, который можно прикрепить к любому процессу. PHPSPY будет с определённой периодичностью формировать отчёт о текущем состоянии процесса. Можно проверить состояние памяти, отследить переменные и их изменения, при этом работа основного процесса не замедляется. Инструмент находится на стадии разработки, поучаствовать в которой приглашают всех желающих.

Планы на будущее (50:06 — 1:01:24)

50:06 Фичи PHP 7. 4. Типизированные свойства увеличат производительность системы. Введены стрелочные функции, позволяющие упростить код. Появилась возможность чёткого определения сериализации и десериализации классов. Вводится нулевой оператор слияния, появляются слабые ссылки. Предзагрузка OpCache позволяет несколько ускорить работу благодаря предварительной загрузке классов. Кроме того, появится интерфейс внешних функций, благодаря которому можно будет использовать код на С прямо в PHP-коде. Последние две технологии отлично сочетаются. FFI работает медленно, если осуществляет загрузку внешних функций по запросу, однако предзагрузка позволяет кэшировать данные и обеспечивает к ним быстрый доступ.

Почему я всё ещё в деле (1:01:25 — 1:11:49)

1:01:25 Не про PHP. Слайды из личного фотоархива, happy memories и т.д.

1:04:58 Цунами в Индийском океане в декабре 2004 года. Появление проекта Sahana. Хотя PHP постоянно подвергается критике за несовершенство и неочевидные решения, этот проект, созданный с помощью PHP и спасающий человеческие жизни, вдохновил Лердорфа на дальнейшее развитие языка.

1:07:56 Мотивационная речь.

Статья по теме: Хочу научиться программировать на PHP. С чего начать?

Расмус Лердорф, создатель PHP: «Я хочу делать вещи для реальных людей»

Человек, придумавший один из самых распространенных языков программирования — 44-летний Расмус Лердорф (Rasmus Lerdorf), — родился в Гренландии, а последние годы живет в США. Впрочем, «живет» — громко сказано: по словам самого Лердорфа, очень много времени он проводит в путешествиях по самым разным странам, встречаясь с людьми, использующими PHP в самых разных сферах жизни.

В начале октября Расмус Лердорф участвовал в конференции IDCEE’13 в Киеве, где я и смог пообщаться с ним и задать часть вопросов, предложенных читателями DOU на форуме.

— Как продвигается работа над PHP 5.6?

— Процесс идёт. Люди предлагают новые функции и возможности, сообщество голосует и обсуждает их, и если большинство «за» — они внедряются в проект. Потом в какой-то момент мы сделаем его «слепок», проверим, чтобы в нем было достаточно тестов и выпустим PHP 5.6. Думаю, это случится примерно в июне-июле 2014 года, но начинать работать нам нужно уже сейчас.

— В одном из предыдущих интервью вы говорили, что в команде разработчиков PHP нет структуры. Действительно ли это так, и как вообще выглядит процесс разработки?

— В отличие от многих других проектов с открытым исходным кодом, которыми занимается в первую очередь какая-нибудь компания с программистами на зарплате, разработкой PHP занимаются исключительно добровольцы. Можно сравнить, например, с MySQL: есть компания MySQL, и она платит программистам, которые обычно и делают большую часть работы. Или, скажем, Mongo — большая компания с хорошим финансированием, которая оплачивает труд разработчиков. Они могут строить планы, устанавливать дедлайны, даты релизов и диктовать разработчикам, чем им заниматься.

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

— Значит, добровольцы работают над чем хотят, а вы делаете всё остальное?

— Ну, не без того. Я делаю много вещей, которые не имеют отношения конкретно к коду — это связано с инфраструктурой, с работой Git-сервера, например, или почтовыми рассылками. Некоторые добровольцы берут на себя скучную работу — и это прекрасно; им, видимо, нравится скрупулезно и внимательно проверять мельчайшие детали, мониторить системы, писать тесты, настраивать Jenkins и всё такое. Всё это очень важно, но если у нас не будет добровольцев, многие задачи просто не будут выполнены. Иногда релиз не выходит вовремя, потому что программист, который работает над ключевой частью проекта, ушел в отпуск, или у него родился ребенок.

— Это анархия.

— Можно и так сказать. С другой стороны, если люди пишут код не за деньги, а просто потому, что им это интересно, то в итоге получается много интересных вещей. Часто бывает, что программисты имплементируют возможности, которые нужны им самим: скажем, они работают в компании, и для их продукта не хватает какой-то фичи в PHP. В общем, никакой структуры действительно нет, и из-за этого сложно отвечать на вопросы, касающиеся возможностей следующей версии языка или срока её запуска.

— А вы сами не думали о том, чтобы основать компанию вроде MySQL и структурировать разработку PHP?

— Нет.

— Вам не нравится, как компании разрабатывают языки?

— PHP — просто инструмент, с помощью которого можно сколотить классные штуки. И мне нравится именно это — то, что создано с помощью PHP. Я никогда не работал в компании, производящей инструменты; много лет я проработал в Yahoo, потом в WePay, сейчас — в Etsy. Это компании, которые работают для нормальных, обычных людей, и PHP — их неотъемлемая часть. Это инструмент, которым мы пользуемся, чтобы делать вещи для реальных людей.

А компании, которые делают инструменты, работают не для людей, а для программистов — как Mongo, как MySQL и т.п. Если выйти на улицу и спросить обычных людей, слышали ли они о Mongo или MySQL, никто не ответит утвердительно. И про PHP никто из них не слышал, и это хорошо.

С другой стороны, если выйти на улицу и спросить людей, слышали ли они о Facebook, что они ответят? Все скажут, что слышали. Меня интересуют именно такие продукты, я хочу делать вещи для реальных людей. Вы спрашиваете, почему я не хочу основать компанию для разработки PHP? Он не касается реальных людей, только придурков типа меня; к тому же делать что-то для программистов — очень раздражающее занятие.

— Означает ли это, что в какой-то момент вы забросите PHP или станете уделять ему меньше времени?

— Единственная причина существования PHP состоит в том, что это инструмент для создания продуктов для реальных людей. И мне нужен этот инструмент, без него я не могу этого делать; это же относится и ко многим компаниям. Мне нравится заниматься PHP, но мне нужно видеть эффект для реальных людей: если я его не вижу, мне нет смысла продолжать это делать.

Да, я целый день сижу за отладчиком и не имею дела с людьми напрямую, но я всего в шаге от них, и все изменения, которые я делаю, нужны реальным людям. Мне всё равно, когда какой-нибудь разработчик жалуется, что он бы хотел видеть что-то по-другому, или что порядок аргументов неправильный — меня это не волнует. Всё, что меня интересует, — это решение проблем в реальном мире. Так что PHP — это очень прагматичный инструмент для этого.

— Кстати, об инструментах. Многие разработчики на других языках часто смотрят на PHP свысока. Вы наверняка слышали мнения, что это язык для низкоквалифицированных программистов, что на PHP нельзя написать что-то серьезное и т.п. Что вы об этом думаете?

— Просто посмотрите на долю рынка, на то, на скольких серверах работает PHP-код. И это неправда, что на PHP нельзя написать что-то серьезное. Я видел исследование, согласно которому 72% из 1 млн наиболее посещаемых сайтов работают на PHP.

— Учитывая все последние скандалы с американскими спецслужбами, я не могу не задать этот вопрос: есть ли в PHP бэкдоры?

— Что прекрасно в проектах с открытым кодом, так это то, что я вообще никак не могу спрятать в нем бэкдор. Если вы загружаете скомпилированное приложение от Microsoft или Oracle, вы понятия не имеете, что там внутри. Конечно, большинство пользователей загружают PHP тоже в уже скомпилированном виде вместе с операционной системой — Ubuntu, или Debian, или RedHat… Но мы публикуем исходный код, а значит, что если появляется бэкдор, то его могли добавить только уже на уровне ОС. Если бы мы это сделали в исходниках… представляете, сколько людей их читают?

— Честно говоря, нет.

— Очень, очень, очень много людей из самых разных стран. Мы бы при всем желании не смогли встроить бэкдор, потому что это было бы настолько очевидно, что нам бы этого не спустили. Производители ОС могли бы сделать что-то такое, если бы очень захотели, но как только об этом стало бы известно, они бы потеряли всю репутацию и доверие. Риск слишком уж велик.

Впрочем, опасность всё равно есть, но на гораздо более низком уровне. NSA может иметь влияние на стандарты шифрования, на криптографические библиотеки, от которых многое зависит. Не только PHP, но практически всё, что можно представить, базируется на определенных криптографических алгоритмах; и если бы кто-то встроил бэкдор на этом уровне, то да, никто бы этого не увидел. Но в самом PHP — ни в коем случае.

Прошлое и настоящее

— Если бы вы могли изменить что-то из того, что сделали (или не сделали) за годы работы над PHP, что бы это было?

— В общем, всё, что я сделал, имело смысл с учётом того, как в то время выглядел веб и сколько людей использовало PHP. Но если бы 20 лет назад я знал, что PHP проживет так долго и им будут пользоваться миллионы людей, я бы убрал оттуда многое из того, что мы убрали позже.

Кроме того, я бы сделал изменения касательно чувствительности к регистру. В PHP функции нечувствительны к регистру, потому что HTML-тэги тоже были к нему нечувствительны. В то время часть людей писала тэги в нижнем регистре, часть — в верхнем. Это был большой холивар, и я не хотел в нем участвовать.

Изначально я представлял PHP как шаблонный язык, где можно было добавлять собственные специальные тэги; и тэги PHP были похожи на HTML, чтобы людям было проще его осваивать. Но в какой-то момент PHP стал чем-то большим, и чувствительность к регистрам стала иметь смысл. Я должен был ввести её прямо тогда, но я помню свои мысли: «PHP используется на 20 тысячах серверов, и всем этим людям придется править свой код!» Конечно, сейчас я понимаю, что лучше было сделать это с 20 тысячами серверов, чем с миллионами, как сейчас.

Есть ещё несколько подобных примеров. Если бы я знал, что язык проживет 20 лет и соберет миллионы пользователей, я бы принимал другие решения. Но в то время это был просто молоток, который я сделал для себя.

— То есть, планов покорить мир не было?

— Абсолютно. Это был просто инструмент, с которым я мог программировать быстрее и эффективнее и не писать один и тот же код много раз. Я просто упаковал его в библиотеку функций и опубликовал её. У меня была шаблонная система, и в итоге я мог разворачивать динамические веб-приложения очень быстро: там, где другим требовались две недели, я делал всё за день. Многие интересовались, как я делаю всё так быстро, и просили разрешения использовать этот «молоток». Я разрешал, без проблем.

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

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

Есть предложения сделать объектный механизм, с которым можно вызывать методы для строк. Но это сложно сделать правильно, к тому же мне не нравится, что это требует строгой типизации. Если, например, вы вызываете строчную функцию для целого числа, а она не работает, то это фигня, потому что веб не типизирован. Когда браузер отправляет информацию, вы получаете только строки; даже если речь идет о числе — скажем, возрасте, — то это всё равно строка. И нужно, чтобы можно было взять это число и работать с ним как со строкой без всяких сложностей.

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

Когда с одной стороны есть код на PHP, написанный начинающими программистами в качестве хобби, а с другой — компаниями вроде Wikipedia, Yahoo или Facebook, развитие языка усложняется на порядки. Продвинутые разработчики будут жаловаться на возможности, созданные для любителей, и наоборот; невозможно сделать всех счастливыми. Чтобы все были довольны, нужно было бы сосредоточиться только на одной группе, и мы могли бы это сделать, но ведь гораздо интереснее создавать язык, которым могут пользоваться все.

— Довольны ли вы тем, как развивается PHP?

— Из-за того, что все наши программисты — добровольцы, и занимаются тем, что им нравится, недостаточно людей работают над такими вещами, как надежность и защищённость, где нужно обрабатывать баг-репорты и находить редкие случаи, в которых без видимых причин выпадает segfault. Обычно это очень странные случаи, и разобраться в них очень непросто.

Главная причина сложности — то, что баг-репорты обычно написаны плохо. Они не объясняют поледовательность действий, там просто написано «Всё сломалось», и приходится долго задавать наводящие вопросы, чтобы понять, что же именно случилось. Это огромное количество работы, особенно когда на другом конце — человек, не очень хорошо объясняющий баги; а надо сказать, что, в общем, никто не объясняет баги хорошо. Одна такая задача может занять три дня.

Поскольку разработка новых возможностей движется довольно быстро — скажем, временной разрыв между PHP 5.4 и 5.5 был небольшим, плюс в PHP 5.6 тоже будет много новых фич, — я переживаю за надежность всех этих нововведений. Проверка всех «крайних случаев» с их использованием занимает некоторое время, и часто разработчики стремятся скорее двигаться дальше, к новым задачам.

— Вы действительно видите уменьшение надежности языка, или это только теория?

— Ядро языка надежно и защищено, и большинство людей никогда не выходят за пределы этого ядра, основных функций языка. Проблемы могут начаться только когда программисты выходят за эти рамки. Поэтому — нет, пока я ничего такого не видел. Это просто страх, который я испытываю, глядя на скорость разработки и на то, как разработчики хотят ускориться ещё больше. Я стараюсь их сдерживать и напоминать, что за нами стоят миллионы пользователей, и мы не можем жертвовать надежностью языка во имя скорости внедрения новых возможностей.

Лирическое отступление: поддержка Unicode

— Что сейчас происходит с нативной поддержкой Unicode? В чем заключается главная проблема?

— Собственно, приложения с поддержкой Unicode можно писать на PHP и сейчас, вопрос в том, как именно это делается. У нас есть расширение для библиотеки ICU от IBM, и эта библиотека может сделать всё что угодно. Любую проблему с Unicode сейчас можно решить. Но обычно людей интересует возможность делать это легко и не задумываться на эту тему; именно это мы и хотели сделать в PHP 6.

Главный вопрос с Unicode заключается в том, как упростить работу с ним и сделать её приятной. Сейчас уже можно решить любую проблему, связанную с Unicode, но это не выглядит красиво, Unicode — не умолчание. Нам в первую очередь мешает тот факт, что библиотека ICU основана на UTF-16; к тому же она большая и сложно организованная, и работа с ней раздражает. Что нам действительно нужно — да и не только нам, а, думаю, всему сообществу Open Source, — так это хорошая стандартная библиотека, основанная на UTF-8, которую будут использовать все. Но её нет, и это проблема.

Одной из серьезных сложностей в попытке создания PHP 6 было то, что нам нужно было работать с UTF-16 внутри, но при этом быть полностью совместимыми с UTF-8 снаружи. То есть каждый раз при вводе и выводе данных нужно было конвертировать их из UTF-16 в UTF-8 или наоборот.

Я надеюсь, что со временем всё в мире будет работать с UTF-8. Я жду, когда все поймут, что им нужно пользоваться UTF-8, и появится эта самая библиотека. Если бы она была, всё можно было бы сделать красиво и удобно. Вообще, в условиях такого бардака я впечатлен тем, как удачно некоторые проекты смогли организовать работу с UTF-8. Многим, впрочем, это не удалось: мне не нравится идея с ustring в Python, например, где нужно отдельно указывать Unicode-строки.

— И кто, по-вашему, должен и/или может написать такую библиотеку? Может ли в этом помочь PHP-сообщество?

— Библиотека ICU по объему примерно в 10 раз больше и сложнее, чем весь PHP. Соответственно, когда мы добавили поддержку ICU в PHP, это скорее было добавление маленького PHP к ICU. Она огромная.

В принципе, мы бы могли написать новую библиотеку, но тогда нам пришлось бы потратить на это следующие три года, в течение которых мы бы не притрагивались к PHP. Да и вообще я бы предпочел, чтобы этим заимались Unicode-гики. Может, и сама команда, которая занимается ICU, могла бы сделать следующее поколение библиотеки — меньше, быстрее, современнее. Текущей версии уже 15 лет, и это ощущается — она очень громоздкая. Было бы здорово, если бы IBM выделила 50 разработчиков на такую задачу.

— И какова вероятность того, что это случится?

— Понятия не имею.

Технические вопросы

— Какие изменения происходят в поддержке MySQL?

— Поддержка никуда не девается, но мы пытаемся упразднить само расширение MySQL, чтобы люди пользовались MySQLi или PDO_MYSQL. Это имеет смысл, потому что они — и особенно MySQLi с нативным драйвером Mysqlnd, — действительно лучше и удобнее. MySQLi использует менеджер памяти PHP, может сохранять копии и кучу всего другого, позволяет выполнять асинхронные запросы и т. п. Мы хотим, чтобы люди могли всем этим пользоваться, но это невозможно через старый API.

Можно ещё добавить, что есть MariaDB — очень интересное решение, но тут нет никаких сложностей и тонкостей. Она использует тот же протокол, и если вы используете её вместо MySQL, ваш выбор всё равно MySQLi или PDO.

— А что с поддержкой NoSQL?

— У нас есть поддержка для всех баз данных. Неплохая поддержка для MongoDB — кстати, несколько разработчиков PHP работают в Mongo, и ещё несколько — в Oracle; есть хорошая поддержка Redis, мы и сами используем его для некоторых вещей.

PHP дошел до стадии развития, когда мы уже не должны сами заниматься поддержкой таких вещей. Когда люди выпускают новый продукт, они понимают, что поддержка PHP может помочь им в поиске и удержании пользователей. В старые времена было наоборот: мне нужно было добавлять поддержку как можно большего числа продуктов в PHP, чтобы получить traction. Теперь он у меня есть.

— А что вы думаете о противостоянии SQL и NoSQL? И есть ли оно вообще?

— Гики могут спорить о чем угодно. Насколько я вижу, всё «противостояние» — это спор гиков, которым просто не о чем больше беспокоиться. Для SQL и NoSQL есть свои применения, хотя я иногда вижу, как люди внедряют нереляционную базу там, где явно нужна реляционная (и наоборот), а потом пытаются с этим жить, — это безумие.

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

— Какие запланированные возможности PHP вы считаете наиболее важными?

— В PHP 5.5 самым важным были генераторы, а насчет 5.6 я пока не уверен. У нас есть множество предложенных функций; одна из них, которая мне очень нравится, нужна для упрощения работы с шифрованием.

Скажем, в 5.5 мы ввели механизм хэширования паролей, который позволяет это делать просто, быстро и правильно. Все инструменты для этого были доступны и раньше, но всё равно время от времени можно было увидеть истории о сайтах, которые хранят пароли в незашифрованном виде, используют md5, алгоритм с плохой «солью» или без «соли» вообще. Это происходит, потому что разработчики иногда просто не знают или не понимают, как нужно делать те или иные вещи. Поэтому теперь у нас есть функция password_hash, которая делает всё что нужно.

Одно из предложений для PHP 5.6 — сделать то же самое для шифрования. При создании SSL-соединения нужно проверять сертификат второй стороны и то, что вы используете актуальную базу сертификатов. Это несложно сделать, но многие разработчики этим не заморачиваются. Потом они переиспользуют тот же самый код на других проектах, и оказывается, что они уязвимы к атакам типа «незаконный посредник» (man-in-the-middle). Так что в PHP 5.6 вся эта работа с шифрованием может быть встроена по умолчанию.

Есть ещё несколько предложений, но я не хочу их называть, потому что пока нельзя точно сказать, что именно войдет в 5. 6. Решение ещё не принято.

Анархия или демократия?

— А кто принимает окончательное решение? Вы?

— Нет. Решение принимаем мы все, я отказываюсь становиться узким местом в этом процессе.

— То есть, в PHP демократия?

— Да, мы голосуем за предложенные возможности. Иногда, правда, случается, что большинство голосует «за», но впоследствии оказывается, что внедрение невозможно по техническим причинам. Но 95% одобренных фич попадают в проект.

— Часто ли случается, что большинство одобряет идеи, которые не нравятся лично вам?

— Довольно часто.

— Вас это расстраивает?

— Нет, это нормально. Когда вы работаете с большим количеством программистов, важно понимать, что не бывает так, чтобы все они в чем-то согласились между собой. Посадите трех разработчиков в комнату — и получите три разных мнения о чем угодно. Посадите в комнату 200 разработчиков — и получите хаос. Поэтому есть правила, которые распространяются и на меня. Даже если я не согласен, я подчиняюсь большинству.

— Были ли случаи, что программисты переставали работать над PHP из-за того, что результаты голосования их не устраивали?

— Да, конечно. Но так уж устроен процесс: если ты не можешь работать с людьми, уступить большинству своих коллег в каком-то вопросе, тогда тебе действительно лучше уйти. Это, по-моему, вопрос взросления: когда твое предложение отклоняют, это происходит не по личным мотивам, нужно не обижаться и двигаться дальше.

— Есть ли другие языки программирования с аналогичным процессом разработки?

— Я думаю, в большинстве случаев всё же есть один человек, который принимает окончательные решения, и задача остальных — убедить этого человека. Так же происходит, например с Linux: если Линус Торвальдс говорит «нет», то это обжалованию не подлежит. Это тоже нормально, но для меня PHP — не основная работа, к тому же мне не нравится принимать решения такго уровня.

PHP — очень широкий проект с поддержкой самых разных вещей, и совершенно не факт, что я разбираюсь в них всех. Например, я не понимаю Sybase, я никогда им не пользовался, и когда один человек предлагает сделать что-то в этой области, а трое других говорят «нет», мы этого не делаем. Эти ребята разбираются в Sybase, а я не хочу вмешиваться, у меня нет необходимых знаний.

Я уверен, что у Линуса тоже случаются такие ситуации, но он действительно глубоко вникает во все вопросы, разбирается и старается принять правильное решение, что достойно уважения. Но это его основная работа, он получает деньги за то, чтобы заниматься именно этим. А для меня PHP никогда не был основной работой.

— Расскажите о своей основной работе, что вы сейчас делаете?

— Я работаю инженером в Etsy, в Нью-Йорке. Это онлайновая торговая площадка для хэндмейда с фокусом на конечных пользователях; как я уже говорил, я всегда работал именно в таких компаниях.

А занимаюсь я тем, что отслеживаю интересные задачи и решаю их. Последнее, что я сделал, — переписал систему развертывания новых версий сайта. Теперь это делается без перезагрузки сервера, быстро и просто. Мы это проделываем примерно 40 раз в день, так что это действительно важно. То, что я сделал, не относится непосредственно к PHP, но мне нужно было знать, как работают веб-верверы. В итоге я написал модуль для Apache и расширение для PHP; так что в общем и целом я — просто старый программист с бородой, который разбирается в технологиях. Компаниям очень полезно иметь в штате старых программистов с бородой, которые разбираются в технологиях.

— Сколько времени вы обычно тратите на PHP?

— Это практически невозможно посчитать. Например, если кто-то в Etsy нашел баг в PHP и я его исправляю, то в это время я работаю для Etsy. Если же его нашел кто-то другой, то вроде уже и нет, но ведь исправление этого бага может оказаться полезным и для Etsy. То же самое было, когда я семь лет работал в Yahoo; да, я много занимался PHP, но часто я делал это для Yahoo. Эта компания заплатила мне за многие вещи в PHP, которыми сейчас пользуются все.

— Хорошо, тогда зайдем с другой стороны: сколько времени вы вообще работаете?

— Это тоже сложный вопрос. Я провожу много времени в путешествиях — в самолетах, в залах ожидания. Три дня назад я был на конференции в Буэнос-Айресе, сегодня я в Киеве, через две недели я еду в Мехико. Так что в моей жизни много аэропортов и беготни. Я не знаю, сколько точно я работаю; думаю, столько же, сколько и большинство гиков — 12–14 часов в день. Не знаю, правда, какая часть этого времени действительно продуктивна; я всегда онлайн — пожалуй, больше, чем следовало бы.

— Ваши поездки обычно связаны с PHP?

— Да.

— Вам нравится путешествовать и общаться с разработчиками на мероприятиях в разных странах?

— Да. Я терпеть не могу летать, мне не очень нравятся переезды, но места, где я бываю, всегда интересны. Мне нравится узнавать, что нужно реальным пользователям, а не слушать жалобы разработчиков на всякую фигню снова и снова.

Я обожаю слушать пользователей, особенно на User Groups и конференциях. Они говорят о том, как PHP помог им решить какие-то задачи — или, наоборот, не смог помочь по каким-то определенным причинам. Иногда они рассказывают, как PHP изменил их жизнь, или как изменилась жизнь людей где-то в маленьком городке в Южной Америке благодаря написанному на этом языке проекту.

Бонусы: дополнительное видеоинтервью и доклад Расмуса Лердорфа на IDCEE 2013

Обговорюємо профспілку в Google, офіс Lyft у Києві, синдром самозванця і тренди 2021. Подкаст DOU #5

Создатель PHP Расмус Лердорф — об анархии и демократии в разработке языка, PHP 5.6 и жалующихся программистах

Несмотря на то, что прошло уже полтора месяца после IDCEE 2013, новые тексты о ней и по её мотивам всё ещё выходят. Сегодня, например, на DOU.ua опубликовали длинное и развесистое интервью с Расмусом Лердорфом, который создал PHP, но из принципиальных соображений не хочет заниматься им в качестве основной работы. Ниже — несколько интересных цитат и дополнительные видеоматериалы.

Вместо эпиграфа можно использвать парафраз Отто фон Бисмарка из внутриредакционного обсуждения текста: «Колбаса, политика и PHP: если хотите наслаждаться ими — не смотрите, как они делаются».

PHP — просто инструмент, с помощью которого можно сколотить классные штуки. И мне нравится именно это — то, что создано с помощью PHP. Я никогда не работал в компании, производящей инструменты; много лет я проработал в Yahoo, потом в WePay, сейчас — в Etsy. Это компании, которые работают для нормальных, обычных людей, и PHP — их неотъемлемая часть. Это инструмент, которым мы пользуемся, чтобы делать вещи для реальных людей.
А компании, которые делают инструменты, работают не для людей, а для программистов — как Mongo, как MySQL и т. п. Если выйти на улицу и спросить обычных людей, слышали ли они о Mongo или MySQL, никто не ответит утвердительно. И про PHP никто из них не слышал, и это хорошо.
С другой стороны, если выйти на улицу и спросить людей, слышали ли они о Facebook, что они ответят? Все скажут, что слышали. Меня интересуют именно такие продукты, я хочу делать вещи для реальных людей. Вы спрашиваете, почему я не хочу основать компанию для разработки PHP? Он не касается реальных людей, только придурков типа меня; к тому же делать что-то для программистов — очень раздражающее занятие.
— Означает ли это, что в какой-то момент вы забросите PHP или станете уделять ему меньше времени?
— Единственная причина существования PHP состоит в том, что это инструмент для создания продуктов для реальных людей. И мне нужен этот инструмент, без него я не могу этого делать; это же относится и ко многим компаниям. Мне нравится заниматься PHP, но мне нужно видеть эффект для реальных людей: если я его не вижу, мне нет смысла продолжать это делать.

— Из-за того, что все наши программисты — добровольцы, и занимаются тем, что им нравится, недостаточно людей работают над такими вещами, как надежность и защищённость, где нужно обрабатывать баг-репорты и находить редкие случаи, в которых без видимых причин выпадает segfault. Обычно это очень странные случаи, и разобраться в них очень непросто.
Главная причина сложности — то, что баг-репорты обычно написаны плохо. Они не объясняют поледовательность действий, там просто написано «Всё сломалось», и приходится долго задавать наводящие вопросы, чтобы понять, что же именно случилось. Это огромное количество работы, особенно когда на другом конце — человек, не очень хорошо объясняющий баги; а надо сказать, что, в общем, никто не объясняет баги хорошо. Одна такая задача может занять три дня.
Поскольку разработка новых возможностей движется довольно быстро — скажем, временной разрыв между PHP 5.4 и 5.5 был небольшим, плюс в PHP 5.6 тоже будет много новых фич, — я переживаю за надежность всех этих нововведений. Проверка всех «крайних случаев» с их использованием занимает некоторое время, и часто разработчики стремятся скорее двигаться дальше, к новым задачам.

Одно из предложений для PHP 5.6 — сделать то же самое для шифрования. При создании SSL-соединения нужно проверять сертификат второй стороны и то, что вы используете актуальную базу сертификатов. Это несложно сделать, но многие разработчики этим не заморачиваются. Потом они переиспользуют тот же самый код на других проектах, и оказывается, что они уязвимы к атакам типа «незаконный посредник» (man-in-the-middle). Так что в PHP 5.6 вся эта работа с шифрованием может быть встроена по умолчанию.

— А кто принимает окончательное решение [по нововведениям в PHP]? Вы?
— Нет. Решение принимаем мы все, я отказываюсь становиться узким местом в этом процессе.
— То есть, в PHP демократия?
— Да, мы голосуем за предложенные возможности. Иногда, правда, случается, что большинство голосует «за», но впоследствии оказывается, что внедрение невозможно по техническим причинам. Но 95% одобренных фич попадают в проект.
— Есть ли другие языки программирования с аналогичным процессом разработки?
— Я думаю, в большинстве случаев всё же есть один человек, который принимает окончательные решения, и задача остальных — убедить этого человека. Так же происходит, например с Linux: если Линус Торвальдс говорит «нет», то это обжалованию не подлежит. Это тоже нормально, но для меня PHP — не основная работа, к тому же мне не нравится принимать решения такго уровня.
PHP — очень широкий проект с поддержкой самых разных вещей, и совершенно не факт, что я разбираюсь в них всех. Например, я не понимаю Sybase, я никогда им не пользовался, и когда один человек предлагает сделать что-то в этой области, а трое других говорят «нет», мы этого не делаем. Эти ребята разбираются в Sybase, а я не хочу вмешиваться, у меня нет необходимых знаний.
Я уверен, что у Линуса тоже случаются такие ситуации, но он действительно глубоко вникает во все вопросы, разбирается и старается принять правильное решение, что достойно уважения. Но это его основная работа, он получает деньги за то, чтобы заниматься именно этим. А для меня PHP никогда не был основной работой.

— Я терпеть не могу летать, мне не очень нравятся переезды, но места, где я бываю, всегда интересны. Мне нравится узнавать, что нужно реальным пользователям, а не слушать жалобы разработчиков на всякую фигню снова и снова.
Я обожаю слушать пользователей, особенно на User Groups и конференциях. Они говорят о том, как PHP помог им решить какие-то задачи — или, наоборот, не смог помочь по каким-то определенным причинам. Иногда они рассказывают, как PHP изменил их жизнь, или как изменилась жизнь людей где-то в маленьком городке в Южной Америке благодаря написанному на этом языке проекту.

Дополнительные материалы

Небольшое видеоинтервью:

Доклад Расмуса Лердорфа о производительности и возможностях PHP 5. 4 и 5.5:

10 популярных языков программирования и их создатели

Перевод статьи
«10 Popular Programming Languages and their Creators».

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

1. Java

Джеймс Гослинг
By Peter Campbell — self-made, Nikon D80, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=3672205

Язык Java это один из самых популярных языков программирования. Он был создан Джеймсом Гослингом, авторитетным информатиком из Канады. Произошло это в 1994 году. Язык Java разрабатывался с целью использования в интерактивном телевидении, но оказался слишком продвинутым. Последняя версия этого языка – Java 11, релиз состоялся 25 сентября 2018 года.

2. Ruby

Юкихиро Мацумото
Автор: Cep21 — Yukihiro Matsumoto. Originally uploaded by Cep21 to English Wikipedia., Общественное достояние, https://commons.wikimedia.org/w/index.php?curid=2706367

Японский информатик Юкихиро Мацумото считается главным создателем языка программирования Ruby. Целью Мацумото было создание по-настоящему объектно-ориентированного языка. Первая версия Ruby была выпущена в 1995 году. Мацумото по сегодняшний день остается главным разработчиком эталонной реализации Ruby.

3. Python

Гвидо ван Россум
By Daniel Stroud — This file was derived from: Guido-portrait-2014.jpg:, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=73509470

Язык программирования Python был изобретен Гвидо ван Россумом – программистом из Нидерландов. До 2018 года Гвидо осуществлял общий контроль и принимал основные решения, касающиеся разработки Python. Вышел этот язык в 1991 году, хотя идея подобного языка программирования зародилась еще в 1989.

4. JavaScript

Брендан Эйх

By Darcy Padilla — https://web.archive.org/web/20140209081556/http://blog.mozilla.org/press/bios/brendan-eich/ https://web.archive.org/web/20131108073412/https://blog.mozilla.org/press/files/2012/04/Thumbnail-Full_Eich_04.jpg, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=31783773

Создателем языка программирования
JavaScript является успешный технолог Брендан
Эйх. JavaScript этот американец разработал
в середине 90-х годов прошлого века,
причем первую версию языка он создал
всего за 10 дней. Это язык применяется
при создании подавляющего большинства
веб-сайтов.

5. R

Росс Айхэка

By Kristina D.C. Hoeppner from Wellington, New Zealand — Ross Ihaka, CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=37005667

R это язык программирования, созданный
новозеландцем Россом Айхэкой и канадцем
Робертом Джентлменом. Само название
языка – первая буква имен его создателей.
Язык R можно назвать очень продвинутой
комбинацией языка S и лексической области
видимости, взятой из Scheme.

6. Pascal

Никлаус Вирт

By Tyomitch — Own work, Copyrighted free use, https://commons.wikimedia.org/w/index.php?curid=449735

Язык программирования Pascal был создан
Никлаусом Виртом, успешным швейцарским
ученым в области компьютерных наук.
Никлаус Вирт назвал созданный им язык
в честь великого французского математика
Блеза Паскаля. Изначально язык
разрабатывался с образовательными
целями, для упрощения концепций.

7. PHP

Расмус Лердорф

Автор: Ed — https://www.flickr.com/photos/wafer/365664702/, CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=9105719

Создателем языка PHP стал датский программист Расмус Лердорф (сейчас живет в Канаде). Он разработал этот язык еще в 1994 году, а первая версия PHP – Personal Home Page (PHP Tools) – вышла 8 июня 1995 года.

8. C

Деннис Ритчи

By Dennis_Ritchie_(right)_Receiving_Japan_Prize.jpeg: Denise Panyik-Dalederivative work: YMS — This file was derived from: Dennis Ritchie (right) Receiving Japan Prize.jpeg:, CC BY 2.0, https://commons.wikimedia.org/w/index.php?curid=20276654

Язык С изобрел успешный американский ученый Деннис Ритчи. Он разработал этот язык в период с 1959 по 1973 год. Язык С является самым широко используемым в мире языком программирования. Это компилируемый процедурный язык, позволяющий писать программы для разных платформ.

9. C++

Бьёрн Страуструп

Автор: Julia Kryuchkova — собственная работа, CC BY-SA 2.5, https://commons.wikimedia.org/w/index.php?curid=57084059

Создателем языка С++ является Бьёрн
Страуструп, информатик из Дании. Работу
над этим языком он начал еще в 1979 году.
Сегодня С++ это один из самых популярных
языков программирования.

10. Lisp

Lisp это один из старейших языков программирования. Он был создан в 1950-х годах американским информатиком Джоном Маккарти. Помимо создания языка, Джон также внес большой вклад в исследования искусственного интеллекта. Lisp разрабатывался в том числе и для создания других языков.

10 правил PHP-мастеров

От Автора:

PHP так широко распространен и общепринят, что уже стало слишком легко найти скрипт или фрагмент, выполняющий в точности то, что вам нужно. К несчастью, не существует фильтра, который определяет, что является “хорошей практикой”, а что, ну… не так уж хорошо при написании PHP-скрипта. Нам нужны заслуживающие доверия источники, которые доказали, что дают твердые знания о лучших практиках PHP.

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

1. Пользуйтесь PHP только тогда, когда это нужно – Расмус Лердорф (Rasmus Lerdorf)

Нет лучшего источника, чем сам создатель PHP, чтобы узнать, на что он способен. Расмус Лердорф создал PHP в 1995г. С тех пор язык распространился со сверхъестественной скоростью в сообществе разработчиков, попутно изменяя лицо Интернета. Однако Расмус создавал PHP не с этими намерениями. PHP создавался для потребностей веб-разработки.

Как и в случае со многими другими проектами с открытым исходным кодом, ставшими популярными, философия или даже самовлюбленность никогда не были движущей силой. Это был чистейший случай нужды в инструменте для решения глобальных проблем, связанных с Сетью. В 1994г., когда речь заходила об инструментах разработки Сети, выбор был весьма ограничен.

Бесплатный курс по PHP программированию

Освойте курс и узнайте, как создать динамичный сайт на PHP и MySQL с полного нуля, используя модель MVC

В курсе 39 уроков | 15 часов видео | исходники для каждого урока

Получить курс сейчас!

И все же вы не можете воспользоваться PHP для всего на свете. Лердорф первым отметил, что PHP в действительности просто еще один инструмент в арсенале разработчика, и даже у PHP есть ограничения.

Для работы пользуйтесь правильным инструментом. Я встречал компании, которые всецело уповали на PHP, употребляя его абсолютно везде, хотя он никогда не предназначался для того, чтобы быть языком общего назначения, подходящим для любой проблемы. Он наиболее приемлем как внешний скриптовый язык для Web.

Попытка использования PHP для чего угодно непродуктивна, и, несомненно, это не лучший способ использования вашего времени как веб-девелопера. Не бойтесь применять другие языки, если PHP для вашего проекта не подходит.

2. Используйте множество таблиц в PHP и mySQL для масштабируемости – Мэтт Малленвег (Matt Mullenweg)

Нет нужды сомневаться в компетентности Мэтта Малленвега в PHP. Он (вместе с сообществом пользователей) разработал самую популярную блоговую систему на свете: WordPress. После создания WordPress’а Мэтт и компания запустили звездный WordPress.com, бесплатный блоговый сайт, основанный на платфоме WordPress MU для нескольких блогов. В данный момент WordPress.com поддерживает более 4 миллионов блогов, а их пользователи сегодня написали более 140 000 постов.

Если кто и знает, как масштабируются вебсайты, то это Мэтт Малленвег. В 2006г. Мэтт предоставил возможность немного рассмотреть внутреннюю структуру баз данных WordPress’а и объяснил, почему в WordPress MU для каждого блога используется отдельная таблица mySQL, вместо применения одной гигантской общей таблицы для всех блогов.

Мы тестировали такой подход для MU, и обнаружили, что масштабирование становится слишком дорогим, начиная с некоторого момента. С монолитными структурами вы упираетесь в стену, построенную из возможностей оборудования. В MU пользователи разграничены и могут быть легко разделены, например, на WordPress.com пользователи распределяются по 4096 базам данных, что позволяет очень легко и рационально масштабировать сотни тысяч и даже миллионы пользователей, обеспечивая экстремально высокий уровень трафика.

Возможность миграции таблиц позволяет коду и, в конечном итоге, блогам гораздо быстрее запускаться и проще масштабироваться. Совместив интенсивное кэширование и элегантное использование баз данных, Мэтт показал, что чрезвычайно популярные сайты вроде Facebook и WordPress.com могут работать только на PHP и обрабатывать невероятное количество трафика.

3. Никогда-никогда не доверяйте своим пользователям – Дейв Чайлд (Dave Child)

Дейв Чайлд – выдумщик (хи-хи!), стоящий за недавно переименованным Added Bytes (бывший ilovejackdaniels.com), вебсайтом, который содержал в себе великолепные шпаргалки Дейва для множества языков программирования. Дейв работал на многие компании-разработчики в Великобритании и упрочил свое положение авторитета в мире программирования.

Дейв предлагает мудрый совет по поводу написания безопасного кода в PHP: Не доверяйте своим пользователям. Они могут вас огорчить.

Так что важнейшее правило всей веб-разработки, и я не могу не сделать на нем ударения, это: Никогда не доверяйте своим пользователям. Подразумевайте, что любой отрывок данных, получаемых сайтом от пользователя, содержит злонамеренный код. Всегда. Включая данные, которые как вы считаете, вы проверили на клиентской стороне, используя, например, JavaScript. Если сможете это сделать, окажетесь на верном пути. Если безопасность PHP важна для вас, этот единственный пункт окажется самым важным для изучения.

Дейв продолжает давать особенные примеры осуществления безопасности на практике в частях один, два и три своей серии публикаций ‘Написание безопасного PHP’. А его окончательный вердикт звучит так:

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

4. Уделите внимание PHP-кэшированию – Бен Больбо (Ben Balbo)

Бен Больбо писал для Site Point, очень уважаемого сайта-учебника для нашего брата – разработчика и дизайнера. Он состоит в комиссии как Мельбурнской группы пользователей PHP, так и Клуба разработчиков проектов с открытым исходным кодом, так что он кое-что знает о языке. Не удивительно, что опираясь на свое прошлое как разработчика PHP и инструктора, он рекомендует уделить немного больше внимания и подготовки PHP-кэшированию.

Если у вас загруженный и преимущественно статический веб-сайт — такой как блог – которым заведует система управления контентом, кэширование, возможно, потребует небольших переделок, однако позволит получить значительное улучшение производительности, с небольшими затратами вашего времени. Организация кэширования для более сложного сайта, который формирует контент для каждого пользователя, такого как портал или электронный магазин, окажется немного сложнее и потребует времени, но выгода от него очевидна.

В PHP существует множество техник кэширования и Бен затрагивает в статье несколько самых крупных, таких как:

Кэширование вызовов функций

Установка заголовков expiry

Кэширование закачки файлов в IE (Internet Explorer)

Кэширование шаблонов

Cache_Lite

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

5. Ускоряйте разработку PHP при помощи IDE, шаблонов и фрагментов – Чед Киффер (Chad Kieffer)

Когда Чед Киффер не занят улучшением пользовательских интерфейсов и управлением базами данных, он дает советы эксперта в своем блоге 2 tablespoons. Из-за своих широких возможностей и профессионального опыта, Чед часто может видеть общую картину, которую другие программисты могут и не разглядеть, особенно когда дело касается целостного подхода, которым пользуется Чед в разработке вебсайтов. Он специалист во всех аспектах процесса разработки, так что любая способность проникать в суть, которой он делится, может оказаться полезной в процессе сборки проекта в одно целое.

Чед считает, что использование IDE вроде Eclipse PDT (пакета для разработки на PHP в Eclipse) со смесью шаблонов и фрагментов действительно может ускорить цикл разработки в проекте.

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

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

Используя IDE вроде Eclipse и пакет PDT, вы обнаружите, что время разработки определенно ускорится. IDE будет автоматически закрывать скобки, добавлять недостающие точки с запятыми, и даже позволит вам исправлять неполадки в текстовом редакторе, без необходимости выкладывания на сервер.

(У Чеда есть отличный учебник о начале работы с Eclipse PDT и преимуществах IDE в общем, если интересует.)

Бесплатный курс по PHP программированию

Освойте курс и узнайте, как создать динамичный сайт на PHP и MySQL с полного нуля, используя модель MVC

В курсе 39 уроков | 15 часов видео | исходники для каждого урока

Получить курс сейчас!

6. Улучшайте функции фильтрования PHP – Джоуи Сочеки(Joey Sochacki)

Так как Джоуи Сочеки, может быть, не такое великое имя, как Мэтт Малленвег (Matt Mullenweg) в сообществе PHP, он бывалый веб-разработчик и делится с нами советами, почерпнутыми на этом пути, в своем блоге Devolio.

Джоуи обнаружил, что хотя при написании кода PHP должна проводиться куча фильтрации, немногие программисты пользуются функциями фильтрации PHP.

Фильтрация данных. Нам всем приходится это делать. Большинство, если не все из нас, относятся к нему с презрением. Однако неведомыми большинству остаются функции фильтрации PHP, которые позволяют производить всякого рода фильтрацию и проверку правильности (validation). Пользуясь функциями PHP filter_*, можно проверять правильность и «стерилизовать» данные, URL’ы, адреса e-mail, IP-адреса, отсекать недопустимые символы и много другое, сравнительно легко.

Фильтрация может быть запутанной, но это руководство способно очень помочь. С помощью Джоуи вы узнаете, как установить фильтры и просеивать практически все, пользуясь преимуществами возможностей фильтрации предоставляемых PHP.

7. Пользуйтесь фреймворком PHP – Джош Шарп (Josh Sharp)

По поводу того, использовать ли фреймворк PHP типа Zend, CakePHP, Code Igniter, или любой другой, спорили всегда. В его использовании есть свои позитивные и негативные аспекты, и многие разработчики имеют собственное мнение о том, идти по этому пути или нет.

Джош Шарп – веб-разработчик, который зарабатывает себе на хлеб с маслом, создавая вебсайты для клиентов. Вот почему вы должны ему верить, когда он говорит, что использование фреймворка PHP — отличный способ сэкономить время и устранить ошибки во время программирования. Почему? Джош считает, оттого, что PHP очень легко выучить.

Но легкость использования PHP также ведет к краху. Из-за меньшего количества ограничений в структуре кода, гораздо легче написать плохой код. Но для этой проблемы есть решение: используйте фреймворк.

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

8. Не пользуйтесь фреймворком PHP – Расмус Лердорф (Rasmus Lerdorf)

В противоположность мнению Джоша о том, что нужно использовать фреймворк PHP, Расмус Лердорф, сам крестный отец PHP, считает, что фреймворки не так уж хороши. Почему? Потому что они выполняют операции гораздо медленнее, чем простой PHP.

Во время своей презентации на Drupalcon 2008 Расмус сравнил время ответа на PHP-страницу при помощи простого примера “Hello World”, с несколькими фреймворками PHP (слайды 24-32) и показал, что фреймворки PHP гораздо медленнее, чем прямой PHP.

Можете прослушать или просмотреть презентацию целиком, где Расмус демонстрирует потери производительности фреймворков PHP. Вкратце, Расмус показывает, что производительность серьезно страдает, когда вы пользуетесь фреймворком PHP, в противоположность использованию чистого PHP.

9. Используйте пакетную обработку данных – Джек Д. Херрингтон (Jack D. Herrington)

Джек Херрингтон знаком с PHP и сферой разработки. Вслед за написанием более 30 статей для престижного IBM developerWorks, Джек также опубликовал книги по программированию, такие как «PHP Hacks». Джек – подлинный знаток.

Херрингтон рекомендует использовать пакетную обработку данных и cron (прим. перев. – планировщик задач), для сложных задач, которые могут обрабатываться в фоновом режиме. Пользователи сети не желают долго ожидать завершения заданий через веб-интерфейс. Работа, которая занимает много времени, больше подходит для выполнения в фоновом режиме.

Естественно, в ряде случаев немного легче запустить вспомогательный поток для обработки небольших задач. Но легко заметить, что при использовании традиционных инструментов – cron, MySQL, стандартный объектно-ориентированный PHP и Pear::DB – пакетные задания в приложениях PHP просто создавать, легко развертывать и несложно сопровождать.

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

Я пробовал все и считаю, что крон имеет преимущество принципа “Keep It Simple, Stupid” (KISS) («Делай все просто, придурок»). Он делает фоновую обработку простой. Вместо многопоточного приложения обработки задач, которое выполняется постоянно и, таким образом, не должно иметь утечек памяти, у вас есть простой скрипт пакетной обработки данных, который запускает крон. Скрипт определяет, есть ли что-то, что нужно сделать, делает это и затем завершает работу. Не нужно волноваться об утечках памяти. Не нужно волноваться о «захлебывании» (stalling) потоков или возможности попадания в бесконечный цикл.

10. Немедленно включите оповещения об ошибках – Дэвид Каммингс (David Cummings)

Дэвид Каммингс управляет собственной софтовой компанией, которая специализируется на системах управления контентом и выиграла несколько премий. Если кто и знает, как рационально разработать приложение PHP, так это Дэйв.

Дэвид написал статью на SitePoint о двух хитростях PHP, которые он хотел бы знать в самом начале. Одна из них: Немедленно включите оповещения об ошибках. Это сэкономит большое количество времени за продолжительный период.

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

Преждевременное объявление переменной.

Обращение к переменной, недоступной в этом сегменте кода, или

Использование определения, которое не было установлено

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

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

Автор: Glen Stansberry

Перевод и редакция: Рог Виктор и Андрей Бернацкий. Команда webformyself.

Источник: //net.tutsplus.com

E-mail: [email protected]

Проект webformyself.com — Как создать свой сайт. Основы самостоятельного сайтостроения

P.S. Хотите опубликовать интересный тематический материал и заработать? Если ответ «Да», то жмите сюда.

Бесплатный курс по PHP программированию

Освойте курс и узнайте, как создать динамичный сайт на PHP и MySQL с полного нуля, используя модель MVC

В курсе 39 уроков | 15 часов видео | исходники для каждого урока

Получить курс сейчас!

Разработка веб-приложения на PHP

Создайте веб-приложение на PHP на примере приема платежей на сайте

Смотреть

Создатель GameOver Zeus занимался правительственным шпионажем

ФБР: Создатель GameOver Zeus занимался правительственным шпионажем

16:00 / 6 Августа, 20152015-08-06T17:00:13+03:00

Alexander Antipov

Похищение денежных средств оказалось не единой сферой применения ботнета GameOver Zeus.

Преступная группировка, использующая ботнет GameOver Zeus, с его помощью похитила у банков порядка $100 млн. Однако, как оказалось, ботнет использовался не только для хищения денежных средств – один из лидеров группировки применял его для шпионажа. Как сообщает издание Security Week, эту информацию сообщили представители ФБР и эксперты компаний Fox-IT и Crowdstrike на конференции Black Hat, проходящей в Лас-Вегасе.

Стоящая за GameOver Zeus группировка, известная среди «своих» как Business Club, состояла из 50 человек. Ее ядром были два лидера (в том числе создатель трояна GameOver Zeus Евгений Богачев), команда техподдержки и несколько избранных поставщиков. GameOver Zeus использовал когерентную сеть, однако в общей сложности существовало 27 ботнетов, за каждым из которых стоял отдельный человек или группа людей.

По словам исследователей, один из таких ботнетов использовался для шпионажа за Грузией, Украиной и Турцией. Руководил этим ботнетом Богачев. Троян был сконфигурирован таким образом, чтобы искать на зараженной системе документы с определенными словосочетаниями, например, «засекречено правительством».

Отметим, что правительство США объявило Богачева в розыск и предлагает за его поимку рекордное вознаграждение в размере $3 млн. По мнению экспертов, правоохранителям до сих пор не удалось задержать обвиняемого по причине того, что он работает на иностранную разведку.

«Опасное будущее» наступает очень быстро, поэтому мы решили еженедельно мониторить поток новостей. Cмотрите 3й обзор в нашем Youtube ролике.

Поделиться новостью:

История PHP — PHP: Основы

PHP: Основы

У PHP очень необычная история в сравнении с другими языками. PHP изначально не был языком программирования и не собирался им становиться. В 1995 году Расмус Лердорф создал набор скриптов на Perl (обрабатывающий шаблоны HTML-документов) для вывода и учёта посетителей его онлайн-резюме. Лердорф назвал набор Personal Home Page (Личная Домашняя Страница). Эти скрипты не были языком программирования: их единственной задачей было обработать шаблон и сформировать HTML страницу.

Затем текущей функциональности стало недостаточно и Расмус разработал следующую версию шаблонизатора, попутно переписав скрипты с Perl на Си. С этого момента PHP стал походить сам на себя. Его популярность росла, он начал использоваться на множестве сайтов в сети, а к проекту стали подключаться новые разработчики. PHP стал самым популярным языком для веб-разработки, оставив все остальные далеко позади. Вокруг языка выросло огромное количество готовых решений и бизнесов: например, более 30% всех сайтов в интернете сделано на CMS WordPress. Также WordPress доступен как SaaS-платформа.

Знать эту историю успеха важно, как минимум, по одной причине. Создание языков программирования — серьезное занятие, требующее определенной квалификации от тех, кто это делает. Расмус признавался сам, что он не понимал ничего в том, как создавать языки; более того, он и не пытался сделать язык. Все это оставило большой отпечаток на PHP:

Разнородное именование функций: они добавлялись по ходу дела в те времена, когда об этом никто не думал.
В целом именование внутри языка очень непоследовательное и часто прямо противоречит PSR (официальные рекомендации по оформлению и организации кода в PHP).
Путаница с передачей параметров: одни и те же по смыслу функции могут принимать на вход параметры по-разному: например, в обратном порядке. Поэтому в PHP сложнее запомнить сигнатуры функций.
Странная система ошибок и предупреждений (Fatal, Warning, Notice).
Хотя в PHP наконец-то добавили пространства имён, это не отменяет наличие механизма для прямой загрузки кода. В итоге получается что есть и пространства имён (которые можно не использовать), и отдельно прямой require.

Этот список можно продолжать и дальше, но в процессе работы вы и сами столкнетесь с неожиданностями. Сейчас языком занимаются серьезные компании и разработчики, и они пытаются исправлять эти ошибки там, где это возможно и причесывают язык. Кое-что им удается, но некоторые фундаментальные ошибки останутся в PHP навсегда.

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

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты.

Зарегистрироваться

или
войти в аккаунт

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

115 курсов, 2000+ часов теории
800 практических заданий в браузере
250 000 студентов

Наши выпускники работают в компаниях:

PHP: История PHP — Руководство

История PHP

Инструменты PHP, FI, Construction Kit и PHP / FI

PHP, как его сегодня называют, на самом деле является преемником
продукт под названием PHP / FI. Создано в 1994 году Расмусом Лердорфом,
самое первое воплощение PHP было простым набором
Бинарные файлы Common Gateway Interface (CGI), написанные на языке C
язык программирования. Первоначально использовался для отслеживания посещений
в своем онлайн-резюме он назвал набор скриптов «Персональный
Инструменты домашней страницы », чаще называемые« Инструменты PHP.»
Со временем захотелось большей функциональности, и Расмус переписал
Инструменты PHP, обеспечивающие более широкую и богатую реализацию.
Эта новая модель была способна взаимодействовать с базой данных и многое другое,
предоставление основы, на которой пользователи могут разрабатывать простые динамические
веб-приложения, такие как гостевые книги. В июне 1995 года Расмус
» вышел
общедоступный исходный код PHP Tools, что позволило
разработчикам использовать его по своему усмотрению. Это также разрешало —
и рекомендуется — пользователи должны предоставлять исправления ошибок в коде,
и в целом улучшить его.

В сентябре того же года Расмус расширил возможности PHP и — для
короткое время — фактически сбросил имя PHP. Теперь что касается
инструменты как FI (сокращение от Forms Interpreter), новая реализация
включены некоторые из основных функций PHP, как мы знаем
это сегодня. В нем были Perl-подобные переменные, автоматическая интерпретация
переменных формы и встроенного синтаксиса HTML. Сам синтаксис
был похож на Perl, но был гораздо более ограниченным, простым,
и несколько непоследовательно.Фактически, чтобы встроить код в
HTML-файл, разработчикам пришлось использовать HTML-комментарии. Хотя это
метод не был полностью принят, ФИ продолжал расти
и принятие в качестве инструмента CGI — но все же не совсем как язык.
Однако в следующем месяце это начало меняться; в октябре 1995 г.,
Расмус полностью переписал код. Возвращение
Имя PHP, теперь оно было (кратко) названо «Создание персональной домашней страницы
Kit «и был первым релизом, который мог похвастаться тем, что в то время
считается продвинутым скриптовым интерфейсом.Язык был
сознательно разработан, чтобы напоминать C по структуре, что делает его легким
принятие для разработчиков, знакомых с C, Perl и подобными языками.
До сих пор ограничиваясь UNIX и POSIX-совместимыми системами,
потенциал для реализации Windows NT изучается.

Код был полностью переработан, и в апреле 1996 года
объединив названия прошлых выпусков, Расмус представил PHP / FI.
Эта реализация второго поколения начала по-настоящему развивать PHP.
из набора инструментов в собственный язык программирования
верно.Включает встроенную поддержку DBM, mSQL и Postgres95.
базы данных, файлы cookie, поддержка пользовательских функций и многое другое.
В июне того же года PHP / FI получил статус версии 2.0. Интересный
Однако факт в том, что был только один полный
версия PHP 2.0. Когда он наконец вышел из бета-статуса
в ноябре 1997 года базовый механизм синтаксического анализа уже был
полностью переписан.

Несмотря на то, что он прожил короткую жизнь в развитии, он продолжал пользоваться
растущая популярность в еще молодом мире веб-разработки.В
В 1997 и 1998 годах у PHP / FI был культ в несколько тысяч пользователей.
мир. Опрос Netcraft, проведенный в мае 1998 г., показал, что
почти 60 000 доменов сообщили, что заголовки содержат
«PHP», что означает, что он действительно был установлен на главном сервере.
Это количество составляет примерно 1% всех доменов на
Интернет в то время. Несмотря на эти впечатляющие цифры, созревание
PHP / FI был обречен на ограничения; в то время как было несколько второстепенных
соавторов, он по-прежнему в первую очередь разрабатывался отдельным лицом.

Пример # 1 Пример кода PHP / FI

Эй, вы используете Netscape!

Извините, эта запись не существует

Добро пожаловать, !

В вашем аккаунте осталось кредитов.

PHP 3

PHP 3.0 был первой версией, которая очень похожа на PHP как
он существует сегодня. Поиск PHP / FI 2.0 по-прежнему неэффективен и
отсутствие функций, необходимых для работы приложения электронной коммерции
они разрабатывали университетский проект, Энди Гутманс и
Зеев Сураски из Тель-Авива, Израиль, начал еще одну полную
переписать базовый парсер в 1997 году. Приближаемся к Расмусу
в сети они обсудили различные аспекты текущего
реализация и их переделка на PHP.В попытке
улучшить движок и начать использовать существующие PHP / FI
пользовательская база, Энди, Расмус и Зеев решили сотрудничать в
разработка нового независимого языка программирования.
Этот совершенно новый язык был выпущен под новым названием, которое
удалили последствия ограниченного личного использования, что
Имя PHP / FI 2.0 удерживается. Он был переименован просто в «PHP» с
что означает превращение в рекурсивную аббревиатуру — PHP: гипертекстовый препроцессор.

Одна из самых сильных сторон PHP 3.0 было его сильным
возможности расширяемости. Помимо предоставления конечным пользователям
со зрелым интерфейсом для нескольких баз данных, протоколов,
и API, простота расширения самого языка привлекла
десятки разработчиков, представивших самые разные модули. Возможно,
это было ключом к огромному успеху PHP 3.0. Другой ключ
функции, представленные в PHP 3.0, включали объектно-ориентированное программирование
поддержка и гораздо более мощный и последовательный синтаксис языка.

В июне 1998 года со многими новыми разработчиками со всего мира.
объединив усилия, PHP 3.0 было объявлено новой разработкой PHP
Team как официальный преемник PHP / FI 2.0. Активное развитие
PHP / FI 2.0, который практически прекратил свое существование в ноябре
в прошлом году был официально закончен. Примерно через девять месяцев
открытого публичного тестирования, когда объявление официального
вышел релиз PHP 3.0, он уже был установлен более чем на 70 000
доменов по всему миру и больше не ограничивался
POSIX-совместимые операционные системы. Относительно небольшая доля
домены, сообщающие об установленном PHP, размещены на серверах
под управлением Windows 95, 98 и NT, а также Macintosh.На пике популярности PHP 3.0
был установлен примерно на 10% веб-серверов на
Интернет.

PHP 4

К зиме 1998 года, вскоре после того, как PHP 3.0 был официально
освобожден, Энди Гутманс и Зеев Сураски начали работать
о переписывании ядра PHP. Цели дизайна заключались в улучшении
производительность сложных приложений и улучшить
модульность кодовой базы PHP. Таких заявок было сделано
возможно благодаря новым функциям PHP 3.0 и поддержке широкого
множество сторонних баз данных и API, но PHP 3.0 было
не предназначен для эффективной обработки таких сложных приложений.

Новый движок, получивший название Zend Engine (состоящий из их
имена, Зеев и Энди), достигли этих целей дизайна
успешно, и впервые был представлен в середине 1999 года. PHP 4.0,
на базе этого двигателя и в сочетании с широким спектром
дополнительные новые функции, официально выпущенные в мае
2000 г., почти на два года позже своего предшественника. Кроме того
к значительно улучшенной производительности этой версии PHP 4.0
включены другие ключевые функции, такие как поддержка многих других
веб-серверы, HTTP-сеансы, буферизация вывода, более безопасный
способы обработки пользовательского ввода и несколько новых языковых конструкций.

PHP 5

PHP 5 был выпущен в июле 2004 года после долгой разработки и нескольких
предварительные релизы. В основном это движется его ядром,
Zend Engine 2.0 с
новая объектная модель и множество других новых функций.

В команду разработчиков PHP также входят десятки разработчиков.
как десятки других, работающих над связанными с PHP и поддерживающими проектами,
такие как PEAR, PECL и документация, а также базовая сеть
инфраструктура из более чем сотни отдельных веб-серверов
на шести из семи континентов мира.Хотя только
оценка основана на статистике прошлых лет, это безопасно
предположить, что PHP теперь установлен на десятках или даже сотнях
миллионов доменов по всему миру.

Создатель

PHP Расмус Лердорф делится уроками, извлеченными за последние 25 лет — новый стек

В этом году ежегодная итальянская конференция PHP phpDay в Вероне завершилась удивительно задумчивым докладом от первоначального создателя PHP.

В качестве заключительного докладчика 50-летний Расмус Лердорф оглянулся на последние 25 лет веб-бэкэнд-языка программирования и предложил некоторые уроки, извлеченные из эволюции скромного препроцессора гипертекста в крупного игрока в инфраструктуре Интернета.

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

Что все изменило

Lerdorf начал с того, что поделился некоторыми воспоминаниями из 1980-х годов. В какой-то момент он даже показал слайд своего домашнего компьютера Timex Sinclair 1000 и вспомнил времена коммутируемых модемов и использования старого протокола Gopher для поиска исследовательских работ в Интернете.«Это было так близко к сети, какое я когда-либо видел в университете».

Но это был первый веб-браузер Mosaic в 1994 году, который заставил его работать. «Это все изменило», — решительно сказал Лердорф аудитории. «И не только для меня, для всех… Все вокруг в то время, играли с этим, и имели адреса UUCP, и играли с Usenet и досками объявлений — было очень легко увидеть, что это изменит мир».

Хотя он описывает себя как «посредственный программист», который не особо любит программировать, Лердорф собрал вместе набор двоичных файлов C, которые сформировали полезный набор инструментов для упрощения некоторых основных функций для веб-мастеров, включая красиво отформатированный журнал доступа и возможность добавлять контент, созданный сервером, на веб-страницы.

Его окончательная идея заключалась в том, чтобы создать систему анализа шаблонов для тегов, которая соответствовала бы небольшим функциям C, которые пользователи могли бы писать сами. Он думал, что это окажется популярным, но «Я был совершенно неправ. Никто не хотел писать код на C ». Люди присылали ему электронные письма с просьбой добавить дополнительные теги, и он пытался продемонстрировать, как легко написать их самостоятельно. Он отправил им простой код C, который им понадобится: «И они скажут вам спасибо. А затем скажите: «Теперь нам нужен этот. Мы не можем понять, как это сделать.«И я бы сделал это.

«И они, по сути, обманом заставили меня создать свой сайт».

Один слайд озаглавлен «О чем он думал?» который Лердорф описывает как «некоторые вещи, о которых меня спрашивают на протяжении многих лет».

Первый? Почему PHP использует имена функций без учета регистра? «Сегодня это не имеет большого смысла, но при принятии всех этих решений вы должны учитывать контекст … Когда Интернет только появился, была огромная религиозная битва за то, должны ли теги HTML быть в верхнем или нижнем регистре. , или даже смешанный случай.Поскольку моя система шаблонов хотела вписаться в этот мир, я не хотел принимать чью-то сторону…

«Теперь, когда все наконец-то перешли на строчные буквы, мне, наверное, следовало его поменять. Но я помню, как подумал: «Это повлияет на сотни сайтов…» »

Затем он смеется и откровенно признается своей аудитории: «Оглядываясь назад, можно сказать:« Я должен был создать неудобств для пары сотен сайтов в то время ».

В мире без контейнеров

Спустя четверть века Лердорф до сих пор помнит, насколько невинным казалось это решение в то время.«Я понятия не имел … На каждом этапе пути я полагал, что в PHP осталось около шести месяцев жизни. Поскольку это примерно то количество времени, которое, как я думал, потребуется кому-то, чтобы написать что-то реальное, что могло бы заменить это, это тоже сработало бы для меня. И я все ждал … И ничего не вышло ».

Это то, что он повторяет позже в своем выступлении. «Я никогда не мог представить, что буду говорить об этом 25 лет спустя».

Он также помнит важную веху: когда веб-сервер Apache начал поставляться с PHP.Другие языки были на самом деле быстрее, чем PHP, но из-за накладных расходов на их запуск как отдельного процесса PHP казался быстрее по сравнению ». А Лердорф рассказывает историю, появившуюся только в 1990-х, о том дне, когда Perl наконец-то выпустил свой собственный дополнительный встраиваемый модуль для веб-серверов Apache — mod_perl . «Они сделали его слишком мощным… Если бы вы были на виртуальном хосте на сервере Apache и имели доступ mod_perl , вы могли бы украсть запросы с любого другого виртуального хоста, если бы захотели…» Из-за этой уязвимости Интернет-провайдеры не будут предлагать mod_perl вместе с другими клиентами в одном экземпляре Apache.

«Итак, если вы пришли к провайдеру и сказали:« Я бы хотел mod_perl », он бы сказал:« Хорошо, это будет 600 долларов в месяц », потому что тогда у нас также не было виртуальных машин, контейнеров, ничего подобного. Таким образом, для mod_perl вам понадобился отдельный физический ящик из чистого металла. В то время как на PHP вы можете разместить 3000 клиентов на одной машине по сравнению с одним клиентом mod_perl ».

Что я узнал во время стажировки

Лердорф также рассказывает увлекательную историю своих дней до PHP, описывая стажировку в Nortel Telecom в Торонто — и то, как она напрямую повлияла на то, как он разрабатывал PHP.Каждые пару месяцев система маршрутизации вызовов компании удаляла каждый звонок из очереди — ошибку, которую они так и не смогли исправить. «Они пытались найти это годами, но так и не увидели». Поэтому они попросили молодого Лердорфа разобраться в этом. Спустя десятилетия он считает свое задание — исправить эту неисправимую ошибку — своего рода шуткой. «Они не думали, что у меня что-нибудь получится. Они решили, что я смогу изучить систему, пытаясь ее отследить ».

Лердорф распечатал каждую строчку исходного кода и приклеил все это к стенам коридоров, отслеживая его поток и пытаясь отладить его вручную.«У меня был стул, на котором я мог встать, чтобы достичь высших вещей». Он помнит код как «неприятный», но сообщает то, что узнал.

«В конце концов, через три с половиной месяца, оказалось, что это коллизия глобальной переменной. Две отдельные части кода, совершенно не связанные друг с другом, имеют одинаковое имя для переменной. И это было глобально. Если его изменить в одном месте и в самый неподходящий момент, другой код сойдет с ума. И компилятор C в то время не мог сообщить нам, что это происходит… »

«Когда я начал добавлять переменные и область видимости в PHP, я вспомнил об этом.И не было никакого способа, чтобы в PHP я собирался потратить три с половиной месяца на отслеживание чего-то вроде этого … Итак, в PHP, если вы собираетесь наступить на глобальный, вы должны чертовски хорошо заявить об этом внутри метод или функция, на которые вы собираетесь наступить в глобальном… Так что вы не можете случайно наступить на глобальный в PHP ».

Попросив поднять руки, Лердорф был удивлен тем, сколько людей все еще используют PHP 5. «Ты убиваешь меня…», — сказал он со смехом. «Я ожидал, что может подняться одна или две руки.Но вся задняя часть комнаты осветилась! »

А потом терпеливо познакомил аудиторию со всеми улучшениями PHP 7.3. Например, версии 5.3 требовалось 140 МБ для обслуживания WordPress, а версии 7.3 — всего 15 МБ.

Вдумчивый взгляд назад

Но выступление Лердоффа закончилось вдохновляющим заключением. Он с любовью вспоминал визит в Шри-Ланку в 2005 году — и не только потому, что в этом году он встретил Артура Кларка. Это был год после сильного землетрясения и цунами, которые привели к проекту помощи при стихийных бедствиях под названием Сахана.«Я разговаривал с людьми там, когда был там, и рассказал о некоторых вещах, которые они могут делать с PHP…»

И, наконец, команда, которую он описывает как «парень из университета, а также парень, работающий на правительство», использовала PHP для создания того, что Лердорф называет «встроенной системой управления для оказания помощи при стихийных бедствиях». Он позволяет быстро распространять информацию о гуманитарной помощи или о статусе пропавших без вести. «Таких модулей семь, восемь, девять.И ценность в том, что это можно развернуть за три минуты … И сейчас он использовался в более чем 50 бедствиях по всему миру.

«Знание о том, что PHP буквально, возможно, спасло чью-то жизнь, делает все это горе онлайн совершенно неуместным…»

В то время как некоторые люди следуют этому прогрессу естественно, он считает, что другие делают это, «потому что они не чувствуют, что могут идти в ногу со временем … Это своего рода кодекс, они потеряли интерес. У них недостаточно мотивации, чтобы сидеть и читать по вечерам.«Но даже с учетом ограничений в семье, все равно должно быть время для страсти и мотивации, — считает Лердорф, — и если у вас этого не будет, вы сгорите».

Он приводит цитату национального министра обороны Филиппин: «Никакие инновации не имеют большего значения, чем те, которые спасают жизни».

«Мы не можем забыть, что мы здесь делаем и зачем мы программируем. Мы программируем, чтобы решить проблему. И, надеюсь, это действительно важная проблема.

«Так что работайте над тем, что для вас важно. Пожалуйста.»

Изображение функции: Расмус Лердорф, август 2014 г. (обрезано), Уильям Штадтвальд Демчик через Википедию.

Вопросы и ответы: Создатель PHP Расмус Лердорф

Расмус Лердорф был первым создателем PHP, который превратился из его проекта личной домашней страницы в язык сценариев с открытым исходным кодом, используемый во всем мире. Недавно Лердорф дала интервью по электронной почте управляющему редактору Computerworld онлайн Шэрон Махлис.

Вопрос: Что вы хотите, чтобы корпоративные ИТ-менеджеры знали о PHP?

A: PHP не является серьезным вложением, если они решат его использовать. Очевидно, что поскольку исходный код открыт, то лицензионные сборы не взимаются. Но что еще более важно, кривая обучения чрезвычайно мелкая и требует навыков, которыми, вероятно, уже обладает существующий ИТ-персонал. PHP — не новый и революционный язык. Он заимствует большую часть своего синтаксиса из таких языков, как C, Perl и Java.

Вопрос: Каковы основные преимущества PHP? В чем это лучше всего?

A: Это очень специализированный язык.Он фокусируется на веб-проблеме. Если вы прочтете отличную онлайн-документацию по PHP, вы увидите, что все нацелено на решение проблем, связанных с Интернетом. Он был написан веб-разработчиками для веб-разработчиков.

PHP идеально подходит для быстрого создания веб-интерфейса практически для любой серверной системы, которую вы можете себе представить. Как правило, серверной частью является база данных, но это также может быть сервер каталогов [Lightweight Directory Access Protocol] или управляемые устройства [Simple Network Management Protocol], и это лишь некоторые из них.PHP также хорош для создания динамического содержимого, отличного от HTML, для Интернета, такого как изображения, флэш-файлы или документы [Portable Document Format]. Например, возможность извлекать информацию о клиентах из базы данных и динамически создавать профессиональные счета в формате PDF — это то, что очень легко сделать на PHP.

Расмус Лердорф, изобретатель языка сценариев PHP

Q: В чем вы видите его недостатки? Для каких веб-задач, по вашему мнению, он менее подходит?

A: У веб-задач действительно нет никаких недостатков, но я думаю, это немного зависит от того, где вы проводите грань между веб-задачами и внутренними задачами, связанными с сетью.Сильной стороной PHP является интерфейсный веб-интерфейс. По мере того, как вы приближаетесь к серверной части, полезность PHP начинает уменьшаться. Например, вы никогда бы не написали на PHP полноценный серверный движок базы данных. Вы также не стали бы писать какую-либо систему среднего уровня для трехуровневой архитектуры на PHP.

PHP — это верхний уровень представления в трехуровневой архитектуре.

Q: Что интересного в работе над ближайшими разработками PHP?

A: Глубоко внутри PHP объектно-ориентированная программа [ООП] будет немного улучшена.PHP традиционно был процедурным языком, и с годами возможности ООП вкрались до такой степени, что PHP можно использовать как достойный язык ООП. Но есть некоторые вещи, которые можно улучшить в отношении этой поддержки ООП.

Пространства имен — еще одна функция, которая скоро появится.

На более высоком уровне, я думаю, вы можете ожидать, что PEAR [PHP Extension and Application Repository] станет намного более полезным. PEAR — это набор кода пользовательского пространства для решения многих связанных с Интернетом проблем, которые не входили в ядро самого языка.

Вы также увидите несколько хороших способов создания сервисов [Simple Object Access Protocol / Web Services Description Language] с помощью PHP. Вы можете сделать это сегодня, но я бы хотел, чтобы это стало более прозрачным, и я работаю над этим.

Вопрос: Есть ли у вас какие-либо мысли относительно того, почему кому-то следует предпочесть PHP Active Service Pages (ASP) Microsoft?

A: На этот вопрос сложно ответить, не вдаваясь в философские вопросы.Я постараюсь избежать этого и просто взгляну на это с практической точки зрения:

Это может быстро накапливаться. И вам, вероятно, потребуется добавить несколько лицензий на подключение к Интернету, возможно, лицензию на сервер Exchange, если вы занимаетесь обработкой электронной почты, и, возможно, сервер управления контентом, что составляет колоссальные 42 999 долларов на процессор.

Многие, конечно, будут спорить с этим, но я могу построить вам аналогичную установку, используя Linux, Apache + SSL, PHP, PostgreSQL и Squid. И я также могу добавить несколько хороших систем управления контентом с открытым исходным кодом.Не все они поставляются в упакованных в термоусадочную пленку коробках с красивой документацией, но единственное, что они, безусловно, делают — это работают.

Настройте красивую архитектуру с балансировкой нагрузки, используя Squid в качестве обратного прокси-сервера на передней панели для пары веб-серверов на задней стороне с отдельным сервером базы данных. Добавьте репликацию базы данных для балансировки нагрузки и надежности. Итак, возможно, пять машин с двумя процессорами в каждой. Одно только программное обеспечение может стоить вам более 300000 долларов по сравнению с 0 долларами. В этой экономике это важно.

Кроме того, в этом году управление сервером IIS [Microsoft Internet Information Server] стало настоящим кошмаром. Одна проблема безопасности за другой.

Это не означает, что альтернативы не вызывают то и дело проблем с безопасностью, но, по крайней мере, вы не платите кому-то 300 000 долларов вдобавок к необходимости следить за частыми исправлениями безопасности. За такие деньги вы должны рассчитывать на надежное корпоративное программное обеспечение, которое просто работает все время.Я не хочу обидеть толпу Microsoft, но до сих пор этого не было.

Если оставить в стороне споры о проприетарном программном обеспечении Microsoft и открытых исходных кодах, почему вы должны выбрать PHP вместо ASP? В конце концов, они в основном делают то же самое. Хотя некоторые считают, что среда разработки лучше для ASP, чем различные варианты для PHP, PHP имеет множество встроенных функций, которые необходимо передать в COM [Component Object Model], чтобы соответствовать ASP, поэтому с точки зрения разработки, вероятно, жеребьевка.

Если вы являетесь специализированным магазином Microsoft и у вас есть разработчики, которые уже знают VBScript и различные другие технологии Microsoft, вам, вероятно, следует выбрать ASP. Если вы только начинаете, вы должны ради себя и своих счетчиков bean-компонентов внимательно изучить PHP и все другие замечательные альтернативные инструменты с открытым исходным кодом.

Q: Я прочитал интересную дискуссию, когда кто-то спросил, следует ли им использовать Perl или PHP для разработки интерактивного / динамического веб-контента.Есть ли у вас какие-либо мысли о сильных сторонах Perl и PHP?

A: Perl — это язык сценариев общего назначения, тогда как, как я уже сказал, PHP — это язык сценариев, нацеленный на решение веб-проблем. Таким образом, в PHP есть несколько встроенных функций для выполнения обычных веб-задач, в которых в Perl вам нужно либо откатать свои собственные, либо пройти через [Comprehensive Perl Archive Network], чтобы найти чью-то реализацию.

Я лично использую комбинацию PHP и Perl для многих своих проектов: Perl в основном для внутренних задач, в то время как у меня PHP выполняет всю внешнюю работу.Конечно, вы можете сделать внешний интерфейс на Perl, но это потребует немного больше усилий.

В: Можете ли вы оценить, сколько сайтов используют PHP?

A: Php.net/usage.php имеет несколько номеров. По сути, более 20% доменов, отвечающих на порт 80, указывают, что на них установлен PHP. Трудно определить, действительно ли они используют PHP.

Очевидно, что большинство сайтов с открытым исходным кодом используют PHP. Я знаю, что он также в некоторой степени используется в MCI / Worldcom, Honda, Lycos и Amazon.В основном просто считайте, когда вы просматриваете. Каждый пятый клик, скорее всего, будет сайтом на PHP.

Q: Я знаю, что PHP был результатом некоторого кода, который вы написали для своей домашней страницы. Для чего были созданы эти оригинальные сценарии?

A: Это началось как библиотека кода C, которую я собрал из бесчисленных программ CGI, которые я написал на C. Я устал переписывать один и тот же код снова и снова, а также хотел отделить свою бизнес-логику от мой макет HTML.

Итак, я написал очень простой синтаксический анализатор тегов, который анализировал бы HTML-файл в поисках специальных тегов разметки и заменял эти специальные теги результатом моего кода бизнес-логики, написанного на C. Я собрал ряд универсальных инструментов, полезных для домашние страницы, которые использовали эту структуру.

Эти инструменты реализовали простую гостевую книгу, сделали анализ посещений, отслеживали количество посетителей и еще кое-что. Они были задуманы как примеры использования этой инфраструктуры, которую я построил, которая упростила добавление бизнес-логики, написанной на C, на веб-сервер и выполнение вызовов этой бизнес-логики из HTML-страницы.

Q: Что означает PHP?

A: Первый выпуск еще в 1995 году назывался Personal Home Page Tools. С годами PHP перерос представление о том, что это набор инструментов для домашних страниц, поэтому возникло ощущение, что нам нужно лучшее название. После долгих дебатов и голосования было выбрано довольно неубедительное название «PHP: Препроцессор гипертекста». Однако мы склонны просто говорить PHP, точно так же, как очень немногие люди расширяют аббревиатуру Perl.

Q: Были ли у вас какие-либо намерения превратить эти скрипты в проект с открытым исходным кодом? Если нет, то как это произошло?

A: Нет, у меня не было намерения создавать огромный проект с открытым исходным кодом или даже язык сценариев.Я написал начальные инструменты, потому что чувствовал, что мне нужно что-то подобное, и я не мог найти ничего, что подходило бы к проблеме Интернета так, как я хотел.

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

Q: Каково это — создать что-то, что станет языком международного веб-стандарта, когда вы видите свое творение на тысячах веб-сайтов по всему миру?

A: Эта часть давно стерлась.Что мне нравится, так это когда я выхожу перед группами пользователей в разных странах и встречаюсь лицом к лицу с реальными людьми, в которых PHP изменил их лично. Это особенно верно для некоторых из бедных стран мира, где не только PHP, но и все технологии с открытым исходным кодом позволили им участвовать в мировом сообществе наравне с остальным миром.

Почему отец PHP не любит программировать

Создатель

PHP Расмус Лердорф не намеревался создавать совершенно новый язык программирования.

Более 20 лет назад датский инженер-программист искал лучший способ исправить то, что он назвал «молодой проблемой». Проект PHP стартовал в 1995 году и в конечном итоге стал языком сценариев на стороне сервера и языком программирования общего назначения, используемым такими техническими гигантами, как Facebook, Yahoo и Etsy.

Лердофф, который участвует во многих проектах с открытым исходным кодом, более семи лет работал архитектором инфраструктуры в Yahoo и присоединился к Etsy в 2012 году.

В сеансе «Спроси меня о чем угодно» на конференции DevBeat разработчики задали Лердоффу ряд сложных вопросов о том, как он разработал язык и что ждет его в будущем.

Если бы вы могли изменить одну фундаментальную вещь в PHP, что бы это было?

Lerdoff: Чувствительность к регистру в PHP — вопрос, должен ли он быть нижним или верхним регистром. Тогда [когда я начал PHP] были серьезные споры, и я не хотел принимать чью-либо сторону в этом религиозном споре.Вносить изменения сейчас больнее, поскольку люди критикуют части PHP. Однако в то время для этого были полуинтеллектуальные причины.

Вы продолжаете кодировать?

Lerdoff: Я трачу больше времени на инфраструктуру и поддержание проекта на плаву. Иногда я пишу код. У меня действительно есть несколько коммитов на Github время от времени; как правило, отслеживание ошибок. Мое время обычно лучше потратить на то, чтобы мотивировать других писать код. Раньше я кодировал 20 часов в день.

Собираетесь ли вы создать новый язык программирования?

Lerdoff: PHP не был написан, потому что я хотел написать язык. Это было решить проблему. Еще никто не придумал нужных инструментов. Честно говоря, я увлечен решением проблем — я не люблю программировать. Это утомительно. Я инженер, который будет использовать любые имеющиеся у меня инструменты [и], если у меня нет инструмента, я сделаю новый. Нет миссии писать на другом языке.

Какой ваш любимый язык программирования?

Лердофф: C.Я больше программист на C, чем на PHP.

Почему Facebook так много вложил в PHP?

Lerdoff: Предполагалось, что PHP будет тонким слоем поверх кучи кода C ++, что я и сделал в Yahoo. Facebook развернул все на PHP вместо того, чтобы переводить это на C ++. Просто они быстрее пишут Gits для PHP — интересно, какой будет следующий движок? Google проделал некоторую работу в этом направлении. Может быть, через несколько лет у нас будет соревнование по Git.

Я новичок в PHP, но могу писать код на Python.Будет ли сложно учиться?

Lerdoff: Просто погрузитесь и скачайте код. Начните решать проблемы с помощью PHP. Я часто шучу, что могу научить умеренно умную обезьяну писать PHP за день. Кривая обучения действительно неглубокая, поэтому вы быстро освоитесь и начнете работать.

Статьи по теме

VentureBeat

Миссия VentureBeat — стать цифровой городской площадью, где лица, принимающие технические решения, могут получить знания о трансформирующих технологиях и транзакциях.На нашем сайте представлена важная информация о технологиях и стратегиях обработки данных, которая поможет вам руководить своей организацией. Мы приглашаем вас стать членом нашего сообщества, чтобы получить доступ:

актуальная информация по интересующим вас вопросам
наши информационные бюллетени
закрытый контент для лидеров мнений и доступ со скидкой к нашим ценным мероприятиям, таким как Transform
сетевые функции и многое другое

Стать участником

Расмус Лердорф: проницательный программист и создатель PHP

История языка программирования PHP повествует о программисте, который предпочитает быть инженером, чем программистом.Потому что, по словам этого инженера, главное — это конечный продукт, а не путь к нему. Что ж, похоже, что его разум работает больше как функция термодинамического состояния, а не как параметр, зависящий от пути, не так ли?

Этот замечательно отличный инженер
не кто иной, как всемирно известный программист Расмус Лердорф. На одном из
В своих интервью Лердорф сказал, что программирование довольно скучно и утомительно,
что несущественно контрастирует с тем, кем он является и чем он занимается. Так,
давайте узнаем больше об этом большом парне и его «пути» к
успех.

Ранняя жизнь

Источник изображения: staticflickr.com

Расмус Лердорф родился 22 ноября 1968 года в семье с острова Диско в Гренландии. Он переехал в Данию в возрасте трех лет. В возрасте пятнадцати лет Лердорф и его семья переехали в Кинг-Сити, Онтарио. В 1988 году Лердорф окончил среднюю школу Кинг-Сити и продолжил учебу в Университете Ватерлоо. Он окончил университет в 1993 году со степенью бакалавра прикладных наук в области системного проектирования.

После окончания учебы Лердорф сделал
значительный вклад в управление реляционной базой данных
такие системы, как Oracle Rdb.

Работа с языками программирования

Когда в середине 90-х программисты и технически подкованные работали над тем, чтобы сделать Интернет более эффективным и быстрым, ему помешали такие языки, как C и Perl. По словам Расмуса Лердорфа, создание веб-сайтов на этих языках занимало слишком много времени и требовало создания нового.

Лердорф, вместе с некоторыми техническими писателями, собрал свои идеи вместе и разместил их в Интернете в виде HTML-страницы. Он хотел сделать шаг вперед, только когда некоторые компании запросили эти документы или расширили идею и внедрили ее в практический мир.

Создание PHP

Начал работать в CGI (общий
интерфейс шлюза), разработал несколько библиотек, написал несколько программ на
C и, наконец, разработал PHP, совершенно новый язык. Лердорф
создан PHP (личная домашняя страница, теперь известная как препроцессор гипертекста)
в 1994 году, и до сих пор многие модифицированные версии языка
был выпущен.

В общем, PHP — это
язык программирования, который был разработан для веб-разработки и может быть
используется почти во всех операционных системах. Самая последняя версия PHP
— PHP 7.3, выпущенный 6 декабря 2018 года.

После того, как PHP стал очень известным и полезным языком для крупных компаний, Расмус Лердорф объяснил, что никогда не намеревался создавать язык программирования, так как он понятия не имел, как его создать. Он делал логические реализации для создания чего-то более простого, чем Perl, и одно вело к другому.Наконец, после формирования технической группы, которая помогала ему с технической документацией, которая последовала за бета-тестированием, в ноябре 1997 года был выпущен PHP / FI 2.

Успех

Сегодня PHP — это широко используемый язык программирования, который используется такими веб-сайтами, как Etsy, Wikipedia, Tumblr, Yahoo, Flickr, Facebook и многими другими.

За прошедшие годы многие функции
был включен в PHP, но Лердорф продолжает говорить одну вещь
каждому начинающему инженеру, что для программиста это очень
важно очень хорошо понимать C.Хотя он принимает это как
по сравнению с такими языками, как Python или C ++, пользователю нужно поставить
сравнительно больше усилий при использовании C, но это основная единица
обучение для любого программиста.

После выпуска PHP работал с
различных крупных технологических компаний, и в настоящее время он работает с Etsy.

Карьера Лердорфа

В январе 2000 года Расмус Лердорф присоединился к Linuxcare Inc. в качестве старшего инженера-исследователя и проработал там год. В сентябре 2002 года он присоединился к Yahoo! где он проработал семь лет в качестве инженера по архитектуре инфраструктуры.Лердорф сказал, что в конце концов он устал и немного деморализовал работу в ориентированной на рекламу веб-компании, поскольку это связано с обманом ваших клиентов.

Он присоединился к Комнате 77 в качестве советника в
2010 год, а затем все о WePay и Etsy. Было одиннадцать
лет, что он работал в Etsy, сначала консультантом, и
потом как выдающийся инженер.

Lerdorf, как и любой другой энтузиаст
программист очень интересуется открытым исходным кодом, и он посещает
конференции с открытым исходным кодом в качестве докладчика по всему миру.

Аннаша Дей — студентка NIT, которая не только изучает инженерное дело, но и пишет материалы. Она также увлекается фотографией, писательством, чтением романов и путешествиями. Она гурман, любит общаться и гулять со своими друзьями. Она также обученная танцовщица катхака и большой энтузиаст моды. Дей также любит смотреть сериалы, в том числе F.R.I.E.N.D.S. и Теория большого взрыва. Чтобы писать лучше, она предпочитает читать дальше

PHP создатель: Расмус Лердоф — TechRepublic

Builder Australia недавно встретился с новатором PHP Расмусом Лердорфом, чтобы поговорить об успехе PHP, движении за открытый исходный код и о том, что мы можем ожидать от PHP 5.

Builder Australia недавно встретился с новатором PHP Расмусом Лердорфом, чтобы узнать об успехе PHP, движении за открытый исходный код во всем мире, других языках сценариев и о том, что мы можем ожидать увидеть в следующем поколении языка динамических сценариев.

Q: PHP сейчас используется более чем 10 миллионами доменов по всему миру.Как это заставляет вас чувствовать себя создателем PHP?

Это не я, это целая группа людей. PHP создал все сообщество, а не я. Я действительно чувствую себя крутым, начиная сообщество [PHP], я действительно думаю, что мы проделали хорошую работу. Мы создали его таким образом, чтобы он был полезен множеству людей, и изменил то, как люди видят Интернет, используют Интернет, и сделал его более доступным.

Сейчас вы работаете в Yahoo, какова ваша там роль?

У Yahoo много разных технологий, поэтому я пытаюсь сосредоточиться на нескольких ключевых технологиях, а не на множестве разных.Они выбрали PHP, и это [реализация], которую я помогаю делать.

Во время выступления на конференции «Введение в PHP» на Linux.conf.au вы сказали, что ненавидите программирование. Что ты предпочитаешь делать?

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

Что вы думаете об открытом исходном коде в правительстве и образовании?

Здравый смысл подсказывает, что им не следует полагаться на закрытый исходный код, потому что они не знают точно, как это работает. Microsoft объявила, что выпускает исходный код [Windows], но на это будут накладываться всевозможные ограничения.Я к этому отношусь скептически. С помощью материалов с открытым исходным кодом они могут нанимать людей для чтения и аудита кода, и им не нужно подписывать действительно неприятные соглашения о неразглашении.

Что касается образования, то им следует использовать программное обеспечение с открытым исходным кодом. Нет смысла строить образовательную систему на программном обеспечении собственности. Все, что вы делаете, — это создаете новых клиентов для компании, а не создаете людей, которые могут стать следующей Microsoft. Например, если у вас есть курс по базам данных, используйте базу данных с открытым исходным кодом и покажите им, как работает база данных.Не все будут копаться в этой штуке, но в каждом классе будут двое или трое детей, которые будут, и из того, что они узнают, они смогут построить следующую замечательную базу данных. Это безумие, когда образовательные системы не идут с открытым исходным кодом и идут полностью на Microsoft. Вот где правительства действительно должны подталкивать университеты.

Делаете мастера .NET? Вот это шутка. Правительствам на национальном уровне следует подтолкнуть университеты к использованию систем с открытым исходным кодом, несмотря на откаты, которые они могут получить [выбрав проприетарные системы].В конечном итоге это поможет больше, чем навредит. Я встречал много людей из MCSE, некоторые из них великолепны, некоторые ничего не знают. Некоторые люди отлично проходят тесты, они не могли бы думать самостоятельно, если бы это их убило.

Есть опрос разработчиков открытого исходного кода, который Бостонская консалтинговая группа провела в прошлом году. Примечательно, что не хватало разработчиков из Индии и Китая. Что вы думаете о распространении проектов с открытым исходным кодом в этих странах?

Я был в Индии несколько раз, давая лекции, это огромно.Правительства некоторых штатов Индии продвигают Linux и разработку с открытым исходным кодом в своих программах по информатике. Есть много разработчиков, которые говорят по-английски и читают по-английски, поэтому они могут легко ускользнуть и работать продуктивно. Я думаю, что как только у нас появится больше возможностей подключения к Интернету, что является большим «если» для Индии, все остальные в мире смогут уйти [и позволить Индии] поддерживать все развитие. У них так много людей, так много хороших разработчиков, это потрясающе.

Китайское правительство по очевидным причинам настроено весьма антиамерикански и не обязательно хочет, чтобы американские корпоративные продукты распространялись по всему Китаю.Южная Америка, Аргентина, Бразилия, Уругвай, Колумбия и другие места, в которых я был, очень заинтересованы в создании собственной индустрии программного обеспечения на основе открытого исходного кода.

Как PEAR впишется в схему работы с PHP?

Я считаю это жизненно важным. Нам нужен лучший способ установки приложений. На этом этапе необходим установщик PEAR, так как сложно загрузить любое приложение PHP и просто заставить его работать. Если бы мы могли получить единый унифицированный установщик, чтобы вы могли видеть PEAR и просто заставить его работать, это было бы здорово.

Какие ключевые функции могут ожидать разработчики от PHP 5?

Будет много улучшений в ориентации объекта и в том, как с ней обращаться. Теперь объекты будут передаваться по ссылке. Это немного больше похоже на то, как вы это делаете на Java и других языках, поэтому люди, которые увлекаются объектно-ориентированной архитектурой, будут довольны таким подходом. Тут и там будут уборки. Лично я работаю над системой фильтрации ввода, где вы можете определить политику безопасности для своего сайта.Это сделано для того, чтобы избавиться от взломов кросс-сторонних сценариев. Материал для фильтрации ввода, над которым я работаю, по умолчанию удаляет весь JavaScript и весь HTML, или вы можете установить для него любой вид фильтрации ввода, который вы хотите.

Как вы оцениваете документацию с открытым исходным кодом?

Я думаю, что в целом это довольно плохо. Слишком много примеров открытого исходного кода с проприетарной документацией. Это немного раздражает. Если вы действительно хотите им пользоваться, вам нужно купить книгу.Стало лучше. Но в целом это не очень хорошо, потому что людей сложно мотивировать писать действительно хорошую документацию. Часто разработчики либо ненавидят это делать, либо действительно плохо это делают, поэтому вам нужны другие люди, которые действительно хороши в техническом плане, которые будут сидеть и тратить время на написание документации. Мы неплохо справились с PHP. Мы относимся к людям, занимающимся документацией, как к разработчикам, у них такой же высокий статус. Каким-то образом мы привлекли много людей, интересующихся документацией.

Что вы думаете об Apache 2.0 прямо сейчас?

Я сейчас не большой поклонник 2.0. Он работает как автономный сервер, обслуживающий статические страницы, но многопоточная модель [которая работает] в UNIX во многих случаях отсутствует. Отдельные приложения, которые не полагаются на большое количество различных сторонних библиотек, могут быть написаны так, чтобы быть поточно-ориентированными, очень красивыми и очень быстрыми. Но вещи общего назначения, такие как PHP и PERL, которые связаны с очень большим количеством разных библиотек [вызывают больше беспокойства, потому что] мы не знаем, безопасны ли эти библиотеки или нет.Меня сейчас беспокоит PHP и Apache 2.0, потому что если мы перейдем на Apache 2 с многопоточным MPM, многие вещи сломаются. Я не думаю, что есть веская причина для перехода на Apache 2.0 на данном этапе, в этом нет никакой убийственной функции. Apache 1.3 справляется со своей задачей. В конвейере есть несколько потрясающих функций, когда они будут завершены, и когда они заработают, мы заставим все это работать под Apache 2.0, но сейчас это большая работа с очень небольшой пользой.Пройдет еще пара лет, прежде чем Apache 2.0 и PHP заработают нормально.

Что вы думаете об ASP.NET и ColdFusion MX и как они соотносятся с PHP?

Я считаю, что ColdFusion мертв, а ASP.NET очень ориентирован на окна. Coldfusion я нахожу слишком острым, кликабельным, «графическим интерфейсом», чтобы быть полезным для чего-либо. ASP — это круто, вы можете делать то же самое. Мне просто не нравится, что меня ограничивают одной платформой.Мне не нравится, насколько он проприетарный, мне не нравится, насколько он закрыт. Я предпочитаю открытую среду. Я предпочитаю иметь возможность менять свои инструменты и разговаривать с разработчиками. Кто написал ASP? Microsoft? Нет, это сделал какой-то парень из Microsoft. Я не люблю, когда меня прячут от инструментов, важных для моего бизнеса.

4 причины, почему все PHP-фреймворки — отстой?

Содержание

PHP-фреймворки День

Почему все PHP-фреймворки — отстой

1. Фреймворки без необходимости многократно выполняют один и тот же код

2.Для фреймворков требуется слишком много взаимозависимых классов

3. Излишне сложные решения

4. Дублирование функциональности веб-сервера

Другие вопросы

Отказ от APC в пользу Zend Opcode Cache

Компиляция PHP в двоичный код

$ Dollar Sign in PHP переменные

Node.js и неблокирующий ввод-вывод

Unicode и JIT в PHP 7

Заключение

День фреймворков PHP

День фреймворков PHP — событие, которое произошло в Киеве, Украина, в октябре прошлого года.Это мероприятие с разговорами о разных фреймворках.

Я узнал об этом только сейчас, благодаря потоку новостей PHP Quick Fix, который собирает Крис Корнутт (известный также как enygma) из известного PHPDeveloper.org. Спасибо, Крис.

Почему все PHP-фреймворки — отстой

Расмус Лердорф, создатель PHP, был приглашен выступить с докладом на конференции PHP Frameworks Day. В основном он говорил о последних разработках PHP, но для меня самым интересным был раздел вопросов и ответов.

Среди прочего, кто-то спросил Расмуса о его мнении о фреймворках PHP.Это был столь же прямой вопрос о его мнении, поэтому Расмус дал прямой ответ (около 31 м 47 с): «Они (фреймворки PHP) Все отстой!»

Может показаться странным, что приглашенный докладчик приходит на конференцию по PHP-фреймворкам, говоря, что все они отстой. Однако публике, похоже, понравился ответ. Во всяком случае, Расмус более подробно остановился на том, что он имел в виду.

1. Фреймворки многократно без необходимости выполняют один и тот же код

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

Более конкретная жалоба заключалась в том, что решения, предлагаемые фреймворками, приводят к многократному выполнению ненужного PHP-кода в каждом HTTP-запросе. Пример, который привел Расмус, заключается в том, что в каждой структуре запросов проверяется тип базы данных, которую приложение использует для загрузки соответствующего класса доступа к базе данных. Поскольку тип базы данных не меняется после развертывания приложения, он считает это пустой тратой.

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

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

Часто фреймворки читают конфигурацию из файлов INI. PHP имеет встроенные функции для загрузки и анализа файлов INI. Несмотря на то, что вы можете сделать все это с помощью одной функции, чтение и анализ INI-файла занимает некоторое время, которое обычно намного больше, чем проверка проанализированных значений конфигурации.

Если ваш фреймворк считывает и анализирует значения конфигурации из файлов в других форматах, которые PHP не имеет встроенной поддержки, например, YAML или XML, ситуация ухудшается, поскольку фреймворки должны выполнять синтаксический анализ в чистом коде PHP.Это намного медленнее, чем код C механизма PHP, анализирующего файлы INI.

Лучшей альтернативой является определение значений конфигурации в файлах сценария PHP. Просто поместите значения конфигурации в сценарии PHP, которые присваивают значения переменным.

При использовании расширения кэширования PHP скрипты PHP компилируются только один раз. При втором запуске скрипты PHP, скомпилированные в коды операций, загружаются из ОЗУ. Это намного быстрее, чем загрузка конфигурации из файлов.

2. Фреймворки требуют слишком много взаимозависимых классов

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

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

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

Расмус предлагает использовать фреймворки, оптимизированные для конкретных целей, чтобы избежать этой проблемы. Он рекомендует использовать, например, WordPress или Drupal, если вы просто хотите опубликовать блог.

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

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

Например, многие фреймворки полагаются на ORM во время выполнения (реляционное отображение объектов). Это компоненты, которые позволяют разработчикам определять, как запрашивать базы данных, обрабатывая информацию как объекты, а не таблицы записей.

Ориентация на объекты хороша для абстрагирования проблем и инкапсуляции решений в классы объектов, но способ работы некоторых ORM добавляет слишком много ненужных накладных расходов.

Разработчик должен написать код для динамического определения переменных класса (полей таблиц), условий, отношений между объектами (объединения таблиц) и т. Д… для составления фактического запроса во время выполнения. Это добавляет много накладных расходов, потому что запросы, которые выполняются для каждого запроса, одинаковы, за исключением некоторых значений параметров, которые могут отличаться.

Есть лучшее решение, позволяющее избежать этих накладных расходов. Вместо того, чтобы динамически составлять запросы во время выполнения, просто используйте отдельный инструмент, который генерирует PHP-код для классов ORM. Сгенерированные классы уже имеют скомпилированные SQL-запросы для выполнения без дополнительных накладных расходов во время выполнения.

Я использую этот подход с 2002 года, когда разработал инструмент ORM под названием Metastorage.Это именно то, что я описал выше. Я определяю в файле проекта объекты, переменные, отношения и функции, которые мне нужно применить к объектам.

Metastorage обрабатывает определения моих объектов и генерирует классы ORM, которые выполняют необходимые запросы во время выполнения, просто вызывая функции классов. Во время выполнения не выполняется построение запросов.

3. Излишне сложные решения

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

Так происходит в случае миграции версий приложения. Некоторые фреймворки скопировали концепцию миграции из Ruby On Rails. Это означает, что вам нужно написать код для изменения схемы базы данных между разными версиями приложения.

Это еще одна вещь, которую Metastorage решает более эффективным и менее болезненным способом для разработчиков. Metastorage генерирует определения схемы таблицы базы данных в отдельном файле от моих определений объектов. Он создает класс установки, который устанавливает таблицы базы данных в первый раз.

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

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

4.Дублирование функциональности веб-сервера

Другой аспект, о котором Расмус не упомянул напрямую, связан с аспектами, которые иногда требуют от фреймворков, чтобы код PHP повторял работу, которую уже сделал веб-сервер.

Например, маршрутизация — это процессы назначения некоторого кода (контроллера) для обработки запросов с разными шаблонами URL. Многие фреймворки подталкивают приложения к использованию шаблона переднего контроллера. Фронт-контроллер анализирует URL-адрес запроса и загружает конкретный контроллер для фактической обработки запроса.

Дело в том, что это уже делает веб-сервер. Он может сопоставить URL-адрес запроса с конфигурацией (например, mod_rewrite или аналогичный) и выполнить соответствующий сценарий PHP.

Когда вы заставляете PHP обрабатывать процесс маршрутизации, вы добавляете ненужные накладные расходы для выполнения задачи, которая одинакова для каждого запроса с одним и тем же шаблоном URL. Это относится к жалобе Расмуса на фреймворки, которые многократно выполняют один и тот же код для достижения одного и того же результата.

Кажется, это еще одно плохое влияние, которое фреймворки PHP получили от Ruby On Rails и Java.С этими языками веб-сервер перенаправляет запрос на сервер приложений.

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

Другие вопросы

На той же конференции Расмус ответил и на другие интересные вопросы, которые, я думаю, стоит прокомментировать.

Отказ от APC в пользу Zend Opcode Cache

Это тема, которую мы несколько раз обсуждали в подкасте Lately in PHP.Расмус объяснил, что PHP необходимо принять один кэш опкодов, который будет следовать последним разработкам PHP в каждой новой версии.

Есть несколько кешей опкодов. Расмус решил отказаться от APC в пользу решения Zend, потому что оно более зрелое и быстрое. Это потребовало от Zend сделать свое решение с открытым исходным кодом.

Любопытно, что мейнтейнером теперь официального кеша опкодов PHP является Дмитрий Стогов. Он был первым разработчиком Turck MMCache, которого Zend нанял для работы над расширением кеша несколько лет назад.

Все хорошо, когда хорошо кончается. Жаль, что PHP потребовалось все это время, чтобы получить официальное расширение для кеширования. Отсутствие официального расширения привело к тому, что PHP плохо выглядел во многих тестах, которые в прошлом предпочитали другие языки.

Компиляция PHP в двоичный код

Кто-то спросил, будет ли у PHP решение для защиты кода путем его компиляции в какую-либо форму двоичного кода.

Расмус заявил, что в PHP никогда не будет встроенных решений такого рода. Он оправдывается тем, что Zend (и другие компании) предоставляют решения для этого, но их относительно легко сломать.Поэтому он предпочел бы не участвовать в этой игре.

Хотя это правда, Расмус просто рассматривает решения, которые просто компилируют PHP в коды операций и шифруют результат. Это решение, которое действительно не так сложно взломать хакерам.

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

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

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

Для таких случаев в настоящее время разработчики могут минимизировать эту проблему, создав архивы PHAR. Это двоичные архивы, содержащие один или несколько сценариев PHP. Хотя архивы PHAR на самом деле не являются решением для защиты от копирования, по крайней мере, они усложнили бы задачу клиентам, которые хотят тыкать в код разработчиков.

Знак доллара в переменных PHP

Когда его спросили о том, почему переменные начинаются со знака $, он объяснил, что это предназначалось для возможности вставки переменных внутри буквальных строковых значений, поэтому для различения того, что является переменная от остальной части строки.

Так как он хотел, чтобы переменные выглядели одинаково внутри и снаружи строки, он выбрал знак $ для начала переменных, вдохновленный решением, которое также принял Perl.

Node.js и неблокирующий ввод-вывод

На вопрос, поддерживает ли PHP неблокирующее программирование ввода-вывода, Расмус объяснил, что вы можете сделать это уже с помощью расширения libevent. Но для такого рода программирования Расмус предпочел бы писать код на языке Go.

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

Вложенный код в обратные вызовы приводит к очень неприятным проблемам, таким как, например, невозможность выйти из цикла while, когда вы находитесь внутри функции обратного вызова. Это тема, которую мы обсуждали несколько раз в подкасте Lately in JavaScript.

Unicode и JIT в PHP 7

Когда его спросили о планах на будущие версии PHP, Расмус сказал, что из-за отказа поддержки Unicode в PHP 6 он понял, что это была слишком амбициозная цель.Поэтому он ожидает, что PHP будет развиваться меньшими шагами.

Php создатель: почему он именно такой и что с ним будет — рассказывает создатель языка

почему он именно такой и что с ним будет — рассказывает создатель языка

О себе (00:00 — 02:20)

Начало пути (02:21 — 08:43)

Ключевые моменты развития PHP (08:44 — 16:26)

Не баги, а фичи, или Почему я сделал именно так (16:27 — 26:43)

PHP 7.3 — что новенького (26:44 — 41:34)

Дополнительные инструменты (41:35 — 50:05)

Планы на будущее (50:06 — 1:01:24)

Почему я всё ещё в деле (1:01:25 — 1:11:49)

Расмус Лердорф, создатель PHP: «Я хочу делать вещи для реальных людей»

Прошлое и настоящее

Лирическое отступление: поддержка Unicode

Технические вопросы

Анархия или демократия?

Создатель PHP Расмус Лердорф — об анархии и демократии в разработке языка, PHP 5.6 и жалующихся программистах

Дополнительные материалы

10 популярных языков программирования и их создатели

1. Java

2. Ruby

3. Python

4. JavaScript

5. R

6. Pascal

7. PHP

8. C

9. C++

10. Lisp

10 правил PHP-мастеров

1. Пользуйтесь PHP только тогда, когда это нужно – Расмус Лердорф (Rasmus Lerdorf)

2. Используйте множество таблиц в PHP и mySQL для масштабируемости – Мэтт Малленвег (Matt Mullenweg)

3. Никогда-никогда не доверяйте своим пользователям – Дейв Чайлд (Dave Child)

4. Уделите внимание PHP-кэшированию – Бен Больбо (Ben Balbo)

5. Ускоряйте разработку PHP при помощи IDE, шаблонов и фрагментов – Чед Киффер (Chad Kieffer)

6. Улучшайте функции фильтрования PHP – Джоуи Сочеки(Joey Sochacki)

7. Пользуйтесь фреймворком PHP – Джош Шарп (Josh Sharp)

8. Не пользуйтесь фреймворком PHP – Расмус Лердорф (Rasmus Lerdorf)

9. Используйте пакетную обработку данных – Джек Д. Херрингтон (Jack D. Herrington)

10. Немедленно включите оповещения об ошибках – Дэвид Каммингс (David Cummings)

Разработка веб-приложения на PHP

Создатель GameOver Zeus занимался правительственным шпионажем

История PHP — PHP: Основы

Остались вопросы? Задайте их в разделе «Обсуждение»

Зарегистрироваться

PHP: История PHP — Руководство

История PHP

Инструменты PHP, FI, Construction Kit и PHP / FI

PHP 3

PHP 4

PHP 5

PHP Расмус Лердорф делится уроками, извлеченными за последние 25 лет — новый стек

Что все изменило

В мире без контейнеров

Что я узнал во время стажировки

Вдумчивый взгляд назад

Вопросы и ответы: Создатель PHP Расмус Лердорф

Почему отец PHP не любит программировать

Статьи по теме

VentureBeat

Расмус Лердорф: проницательный программист и создатель PHP

Ранняя жизнь

Работа с языками программирования

Создание PHP

Успех

Карьера Лердорфа

PHP создатель: Расмус Лердоф — TechRepublic

4 причины, почему все PHP-фреймворки — отстой?

Содержание

PHP-фреймворки День

Почему все PHP-фреймворки — отстой

1. Фреймворки без необходимости многократно выполняют один и тот же код

2.Для фреймворков требуется слишком много взаимозависимых классов

3. Излишне сложные решения

4. Дублирование функциональности веб-сервера

Другие вопросы

Отказ от APC в пользу Zend Opcode Cache

Компиляция PHP в двоичный код

$ Dollar Sign in PHP переменные

Node.js и неблокирующий ввод-вывод

Unicode и JIT в PHP 7