как вы думаете, почему проекты высокой нагрузки (фб, вк) написаны на рнр и не тормозят?

у нас недавно APC положил боевой сервер при апгрейде на 5.4. С какой-то НЛО-ошибкой типа «не могу передать параметр по ссылке» на каждый запрос. Происходило это только при нагрузке over 150 активных пользователей. Админ как-то починил (для чего ему оказалось проще сделать новую виртуалку, чем починить текущую), но деталей не знаю. На сервере последняя убунту, да.

Я в сях не силен конечно.. Но у них в PDO для всех СУБД эмуляция prepared statements используется чтоли?

https://github.com/php/php-src/blob/master/ext/pdo_pgsql/pgsql_driver.c#L238

в Идее можно refactor -> change signature, и указать дефолтное значение нового параметра null. Хотите заменить миллиона файлов? Next, Next, OK. well done :)

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

да и вообще метод с > 2х параметров уже страшен, я вот например winapi в таких случаях вспоминаю.

Вообще, конечно, венец инженерной мысли - это битрикс. По сравнению с его API - WinAPI просто образец лаконичности и строгого стиля.

[offtopic] В вакансиях реально пробегают предложения в виде «требуется bitrix-программист и jQuery-программист» Я все меньше и меньше хочу жить на этой планете :)

а еще можно так:

/**
@deprecated @see foo(x,y)
*/
int foo (x) {
    return foo(x,null);
}

int foo (x,y) {
   //something
}

Тогда и рефакторинга не надо.

Но в PHP так нельзя, потому что его создатели не асилили параметрический полиморфизм, потому что ad-hoc полиморфизм нужно делать по типу аргумента, а «очень динамическом» похапэ тайпхинтинг - это не типизация, никакого типа на самом деле там нету. Ну по крайней мере в старом похапэ, не знаю как там в самых новых версиях

а еще можно так:

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

- интерфейс с deprecated методам - которые потом не выкинешь из-за @Override

- интерфейс с ненужными методами (пример - коллекции java c их addAll & etc) - которые все будут боятся наследовать и родят:

- наследование реализаций _интерфейса_ от общего _абстрактного класса_ - которое фактически приведет нас от интерфейсов (с возможностью повесить их кучку на один класс) к наследованию логики костыльным паттернам типа адаптер\враппер и прочим макаронам

- и интерфейс в одну функцию превращается в лямбду (да будущее) и кошернее в виде анонимного класса

Потому лучше по возможности сделать над собой усилие и отрефакторить нормально.

реализаций _интерфейса_ от общего _абстрактного класса_

Пример AbstractCollection

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

Вообще, конечно, венец инженерной мысли - это битрикс.

эхх, хотел я на работе народ отучить от этой каки, но там «шаблоны интерфейса изкаробки» © и «админка простая» ©

к счастию с этим я не работаю

А хз, я не ковырял, что за HAVE_PQPREPARE. Там от него дофига зависит, хотя, предполагаю, что это «имеется поддержка системным драйвером (читай libpq) подготовленных выражений». Но для scrollable result sets один хрен эмулируется, причем это не отключить, лулзы сплошные.

«шаблоны интерфейса изкаробки» © и «админка простая» ©

Прямо нашу жумлу описал :)

а «ваша» чемто от той что на офсайте отличается?

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

1) Вызовы foo->getName() магически превращаются в foo->name
2) Вызовы foo->name магически пробуются на следующие варианты:
3) Если в классе Foo есть поле name, то берется его значение
4) Если нету, то в БД в схеме таблицы FOO ищется поле name. Если такое поле находится, то делается select name where id=foo->id, и используется результат.
5) Если и там нету, то в том же селекте выбирается поле Additional. В нем хранится JSON в виде блоба. Если в этом JSONе есть поле name, используется его значение.
6) Если в аннотации к полю foo->name сказано, что поле стопудов должно быть, а него нет ни в классе, ни в колонке таблицы, ни в JSONе, то по хитрому конвеншену оно пробует джойниться с соседними таблицами и поискать нужно поле там
7) Если и это не удается, то оно берет из аннотации дефолтное значение, «добавляет поле» - прописывает аргумент с таким названием в JSON, и возвращает его.
8) Есть еще пара способов где надо искать :)
9) Функции для работы с коллекциями, типа getFoos()->createView()->sortById()->desc(), учитывают все эти особенности и последовательно пробуют «стоупдов обязательные» поля из схемы, описанной в аннотациях (под аннотациями понимаются кооментарии в стиле Doctrine Annotations)

Вот такой вот геттер.

Из профитов, человек может запихать нужное поле в кучу мест, куда в данный момент ему удобнее его пихать, а интерфейс доступа всегда один - foo->getName(). А еще можно изображать NoSQL поверх SQL-БД. Архитекторам показалось это жутко удобным.

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

Но рефакторингов пока действительно не понадобилось )))

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

а «ваша» чемто от той что на офсайте отличается?

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

В LDAP, DNS искать умеет? А по SLAP найти виноватого?

А вы начиная новый стартап, на чём бы писали? Не зная, как разовьётся ваш проект, будут ли найдены инвесторы и т.п.? Проще всего писать на PHP(из всех языков для Web - это самый популярный). Язык хорошо задокументирован, есть много кода, который вы можете унаследовать в своём проекте, много учебников и т.д. Да даже хостинг на первых порах можно заюзать самый дешёвый - shared-хостинг. Потом перейти на VDS, и только затем на облако(что весьма не дёшево, и на первых порах очень напрягает карман). А ведь новый сервис не сразу начнёт приносить прибыль.

В общем, кто-то за элитностью языков гонится, а кто-то просто работает. На том, на чём можно быстро пишет прототип приложения(пусть и кривой), и торопится опубликовать его в сети. Затем приложение обрастает кучей костылей, потом их рефакторят... По частям, не спеша... Объём кода растёт, и со временем переписывание его на другой ЯП становится не целесообразным... Слишком дорого переписывать, да и времени не будет(как только ваш проект «выстрелит», найдутся подражатели, и что-бы не сдавать позиций, вам нужно будет постоянно улучшать проект, вносить в него изменения, и добавлять новые фичи). В общем, иногда дешевле городить новые костыли, чем переписывать всё по новой... И использовать масштабирование, что-бы проект обслуживал больше клиентов дешевле, чем переписывать проект. Да и для больших проектов прирост производительности особый от перехода на Ruby/Python не будет, а переход на Java/C# замедлит процесс разработки, и проект загнётся. Проще для самых медленных участков кода модули на C/C++ к PHP написать, или специальные компиляторы для PHP использовать(как делает это Facebook).

Joomla - это хорошо. Но для сайтов-представительств да Web-порталов средней руки... Многие стартапы с самого начала пишут всё с нуля, или используют фреймворк вроде Yii, потому что их специфика проекта не укладывается в рамки стандартной CMS. Вы один из разработчиков этой замечательной CMS?

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

Но рефакторингов пока действительно не понадобилось )))

Я бы первым делом отрефакторил во все поля вот эту лабуду

Haters gonna hate.

Понятия не имею для чего нужно учитывать мнение упорков, считающих, что их православная Java || православный PHP || православный Python || православный Ruby «лучший на свете язык, а остальное всё говно».

/me программист на PHP, Ruby и немного Java.

Вы один из разработчиков этой замечательной CMS?

Нет, я один из, уверен, многих, кому, помимо основной работы, приходится иногда пилить этот страх и лютый ужас, чтоб исправить «вон тот бесплатный (может быть, взяла вот на этом форуме таргз) модуль почему-то не работает/работает не вот так, а вот эдак». Там и основной шаблон иногда кривой, и жабаскриптов каждый модуль понаподключает пачку, причем каждый разраб модуля/плагина для жумлы, видимо, соревнуется в том, сколько изощренных способов наподключать жабаскриптов самым наинесовместимейшим образом он найдет. Один раз даже по спец. заказу контент-плагин + модуль для жумлы костылить пришлось, я до сих пор проплеваться не могу. И все это на фоне того, что пых и мускль. Три в одном, мать его.

Мечтаем выкосить до конца праздников JSON, но очень сложно. Для начала, надо написать какую-то утилиту, которая сможет «двигать» поля из JSON и всех других мест, превращая их в поля БД (генерить alter table'ы) и соответствующий маппинг в ORM. А потом вдумчиво, последовательно написать для каждой из пары десятков базовых сущностей алгоритм, который будет для каждого распределения данных придумывать передвижку, не теряющую данные. и не придумывающую новые данные, а если терять и придумывать - то как-то с умом. И разрешени конфликтов, и приоритеты...

Когда коту делать нечего, он, как известно...

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

Да ладно, не всё там так плохо... Со скриптами, правда, намудрили. В Wordpress подключение скриптов куда как красивей сделали, даже с учётом зависимостей(что-бы не грузить кучу версий jQuery, и плагинов к нему). Нужно скрипту из поставки плагина jQuery - один вариант всем скриптам. И подключение скриптов можно делать только по кодексу, а то не примут плагин в каталог подключаемых модулей на их сайте. В общем, сообществу Joomla просто нужно написать свой кодекс, что-бы все понимали, что есть только один стандартный путь подключения скриптов. Шаблон можно поправить. А вот пых и мускуль - это разве недостатки? Это самая распространённая связка ЯП+БД в мире Web.

Это самая распространённая связка ЯП+БД в мире Web.

И самая кривая. Выше уже я описывал. Хотя, какое там «prepared statements», их разве в этих всяких CMS вообще кто-нибудь парится делать? Ну и мускль... к этой поделке отвращение стойкое. Не может ни во что.

Эх, честно говоря, не встречал prepared statements в коде нескольких популярных CMS, которые я ковырял. А ведь по идее, код использующий prepared statements использовать удобно, и в PHP есть все средства для работы с ним. Код на C++ и Java видел, а на PHP почему-то данный функционал игнорируют. Может это дело привычки? Я вообще мечтал что-бы что-то подобное SQLAlchemy под PHP стали использовать. Для многих CMS вменяемая ORM - это путь к освобождению продукта от безальтернативной зависимости в лице MySQL. Но сообщество PHP идеи подобных ORM не жалует. Может, со временем ситуация изменится.

Эх, честно говоря, не встречал prepared statements в коде нескольких популярных CMS, которые я ковырял. А ведь по идее, код использующий prepared statements использовать удобно, и в PHP есть все средства для работы с ним. Код на C++ и Java видел, а на PHP почему-то данный функционал игнорируют. Может это дело привычки? Я вообще мечтал что-бы что-то подобное SQLAlchemy под PHP стали использовать. Для многих CMS вменяемая ORM - это путь к освобождению продукта от безальтернативной зависимости в лице MySQL. Но сообщество PHP идеи подобных ORM не жалует. Может, со временем ситуация изменится.

Это ты какие-то недоприложения используешь типа жумлы. Любой более-менее вменяемый фреймворк: Yii, Zend, Kohana, Symfony использует ORM либо свою, либо Doctrine, Propel и др. Они не привязаны к БД, юзают PDO или уже MysqlND.

Надеюсь правильный ответ уже прозвучал?

Потому что есть nginx, haproxy и туева туча дешевых серверов. Программисты с ЗП выше 2х юнитового нормального сервера не нужны, когда рядом есть дешевый как две копейки пхп-шник.

И вообще, какая разница на чем написано приложение если планируется пускать его на 20+ серверах ? Пиши на элитном языке (ява) - рано или поздно придется ставить новые сервера, пиши хоть VBS - рано или поздно придется ставить новые сервера. Когда приходит момент ставить новые сервера обычно о смене языка, его плюсах и минусах задумаются в последнюю очередь.

Любой более-менее вменяемый фреймворк

Фреймворк != CMS. Это раз.

Kohana

Вот только не рассказывай мне, я на этом говне пару-тройку хоумпагоподобных шняг запиливал, одну в итоге на GWT переписали (и продолжаем писать, там свои косяки, но я как разработчик доволен). В том числе и по причине никакой работы с базами. Ну и где-то в кохана тикет сторе читал, что «we only supoprt mysql officially», и с этим объяснением push-request с драйвером постгреса отклонили.

PS. ЧСХ: в кохане нет prepared statements, их чудной ORM тупо строки запросов конструирует и выполняет as is.

Вот только не рассказывай мне, я на этом говне пару-тройку хоумпагоподобных шняг запиливал, одну в итоге на GWT переписали (и продолжаем писать, там свои косяки, но я как разработчик доволен). В том числе и по причине никакой работы с базами. Ну и где-то в кохана тикет сторе читал, что «we only supoprt mysql officially», и с этим объяснением push-request с драйвером постгреса отклонили.

Это из серии «я не умею готовить»

Я не просто так указывал ORM'ы:
https://github.com/Samnan/Kohana-Propel

Я с коханой работал, когда она была в версиях 3.0.Х и даже тогда почти все использовали sprig, который работает с PDO и умеет то что тебе нужно.

По ссылке не коханий реп. Так и говори: «штатно кохана говно, но с помощью костылей и подпорок можно сделать из нее франкенштейна, приделать к жопе водосток, к голове каттетер, сделать еще кое-какую косметику и будет зашибись». Только не кохана это уже будет. Штатный ORM там говно, возражения есть?

По ссылке не коханий реп. Так и говори: «штатно кохана говно, но с помощью костылей и подпорок можно сделать из нее франкенштейна, приделать к жопе водосток, к голове каттетер, сделать еще кое-какую косметику и будет зашибись». Только не кохана это уже будет. Штатный ORM там говно, возражения есть?

Штатный ORM там никто не использует, минимум Sprig, а в нем все более менее уже.

Знаю, что фреймворки юзают ORM. Они написаны гораздо лучше, чем CMS. Жаль что популярные CMS не пишут на основе нормального фреймворка. А велосипедят, и при этом каждый изобретает ни с чем не сравнимый велосипед, кто с квадратными колёсами, кто ещё какой... Но мне лично приходится иметь дело именно с CMS(Joomla, WP, Prestahop), и пока это без вариантов. Разрабатывать интересные решения на хорошем фреймворке мне(надеюсь только пока) моя квалификация не позволяет. Вот и занимаюсь тем, что мне по зубам. Изменение/создание тем, модулей и плагинов для постоянного заказчика, у которого проекты уже на данных CMS работают.

Знаю, что фреймворки юзают ORM. Они написаны гораздо лучше, чем CMS. Жаль что популярные CMS не пишут на основе нормального фреймворка. А велосипедят, и при этом каждый изобретает ни с чем не сравнимый велосипед, кто с квадратными колёсами, кто ещё какой... Но мне лично приходится иметь дело именно с CMS(Joomla, WP, Prestahop), и пока это без вариантов. Разрабатывать интересные решения на хорошем фреймворке мне(надеюсь только пока) моя квалификация не позволяет. Вот и занимаюсь тем, что мне по зубам. Изменение/создание тем, модулей и плагинов для постоянного заказчика, у которого проекты уже на данных CMS работают.

Это вы просто уперлись в 2 калеки на первой стратице гугла из-за старых нубов, пишущик книжки про жумлы.

2 CMS системы от MonoRay (тоже Yii, причем есть комьюнити и про варианты)
http://monoray.ru/products

Alchemy на Yii:
http://www.alkodesign.ru/rus/alchemy_yii/

Yupe (Yii)
http://yupe.ru/

Diem на Symfony:
http://diem-project.org/

Надо же, сколько новых CMS появилось! А я про них и не слышал. Спасибо большое, установлю их на свой тестовый полигон(виртуалку в KVM, и рассмотрю внимательно). Если они впишутся в требования к новым проектам, буду их использовать.