Entity “фреймворк” для PHP из одного класса

А вы хотите чтобы вам 10 человек одно и то же написали? Ну я, например, тоже не понял. У вас нет ничего нового ни в идее, ни в реализации. Генерировать SQL из ассоциативного массива это первая мысль, которая появляется при изучении работы с БД в PHP, а маппинг таблиц на сущности есть практически в любом фреймворке.

Yii: лучшие практики

Подозреваю, что у вас поле в БД тоже называется profile (а надо называть profile_id), и при обращении читается прямое значение атрибута, а не вызывается геттер для связи.

Обзор обзора минусов Битрикс, или чувак читает только первые 5 страниц

Слышал, что они вроде как собираются переписать с Битрикса. Не знаю, правда или нет.

Магия, сломанный калькулятор или просто «развод»?

Судя по JSON-ответам, у всех этих сайтов один и тот же движок, IP адреса тоже похожи. Значение обрезается до 2 цифр после запятой без правильного пересчета. Пользуйтесь другими обменниками. По-моему, статью писать не стоило.

Искусственный интеллект, сильный и не очень

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

Рекурсия на PHP — алгоритм, применение

1. Рекомендую вам освоить ООП и научиться пользоваться объектами. Все ваши глобальные функции и переменные вполне можно инкапсулировать в объект класса Tree.
   
   
2. Заполнение дерева вполне можно сделать без рекурсии. Вот пример для объектов, для массивов можно сделать аналогично, только надо вручную указывать доступ по ссылке.
   

   function getDocumentTree()
   {
       $documents = Document::find()->indexBy('id')->all();
   
       $topLevelDocuments = [];
       foreach ($documents as $document) {
           if ($document->parent_id) {
               $parentDocument = $documents[$document->parent_id];
   
               $document->parentDocument = $parentDocument;
               $parentDocument->childDocuments[$document->id] = $document;
           } else {
               $topLevelDocuments[$document->id] = $document;
           }
       }
   
       return $topLevelDocuments;
   }

   
   
   
3. Не очень понял ваши рассуждения про самозапуски, но рекурсия здесь тоже не нужна. Можно сделать что-то типа такого (псевдокод, в работе не проверял):
   

   foreach ($array as $uid => $row) {
       $node = $row;
       if ($node['access'] == 'allow') {
           // поднимаемся вверх по ветке, разрешаем просмотр для родительских узлов
   
           $pid = $row['pid'];
           while ($pid != null) {
               $node = $array[$pid];
               $node['view'] = 'show';
               $pid = $node['pid'];
           }
       }
   }

   
   

4. сравнивая level каждого документа нам пришлось бы обойти сотни строк, это несёт большие накладные расходы

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

Опасный ум, безопасный интеллект

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

Опасный ум, безопасный интеллект

Вы куда-то не в ту сторону рассуждаете) Причем здесь интеллектуалы, профессии, и тесты IQ? Биологический интеллект появился когда ничего этого не было. Или дикие звери, например, хищники — они умеют самостоятельно ориентироваться в лесу, выслеживать добычу по запаху. По вашему, у них нет биологического интеллекта?

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

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

Когда же ИИ станет «добывать» знания самостоятельно, мы не будем знать «о чем он думает».
Почему? Есть же отладчик, дамп памяти, виртуальная машина.

Невозможно проверить адрес e-mail на допустимость с помощью регулярных выражений

^(.+)@(.+)\.(.+)$
Все примеры из статьи проходят. Для задач валидации, когда вместо email написано имя или телефон, этого вполне достаточно.

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

На каком фреймворке вы будете писать PHP приложение в 2016 году?

А в каких задачах Yii вас сковывает?

На каком фреймворке вы будете писать PHP приложение в 2016 году?

Раз уж зашел разговор про сравнение фреймворков. Я пару раз начинал изучать laravel, но как говорится "ниасилил" (может потом как-нибудь еще поразбираюсь). То что не понравилось по сравнению с Yii:

Генератор HTML для форм надо ставить отдельно. На это есть свои причины, но неудобно.

Для работы с ассетами надо использовать elixir, для elixir надо ставить node.js, нода грузит кучу модулей, которые занимают много места, и к тому же делает слишком большую вложенность папок node_modules, на что Windows ругается при удалении.

Статические обращения через фасады. Например, в обучающем примере есть вызов Redirect::route().
Захочешь посмотреть, как этот класс Redirect устроен, какие функции в нем еще есть, или может в документации что-то не понял, ищешь по исходникам и находишь:

class Redirect extends Facade
{
    protected static function getFacadeAccessor()
    {
        return 'redirect';
    }
}

А класс на самом деле называется Redirector.
Из-за этого автокомплит в IDE не работает. Для автокомплита можно поставить отдельный пакет, но там просто заглушки, поэтому к месту реального объявления все равно не перейти.

Генератор модели по таблице и генератор CRUD в Yii тоже удобная штука, позволяет быстро создать минимальный рабочий код. Особенно если сделать свой генератор, который генерирует в верстке выпадающие списки на основе foreign keys. Для laravel вроде тоже есть какие-то пакеты, которые можно поставить отдельно, но я с ними не работал, поэтому ничего сказать не могу.

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

Стоит ли опасаться совершенствования искусственного интеллекта?

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

Стоит ли опасаться совершенствования искусственного интеллекта?

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

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

«Полный аналог» означает, что в некоторой ситуации ИИ будет поступать так же, как поступил бы человек, будет анализировать данные по таким же принципам, как это делает человек, неважно эффективнее или нет. Это не математический алгоритм, который ищет корреляции в наборе чисел.

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

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

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

А для кого ты Habrahabr

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

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

Заглянем в будущее: на пути к цифровому коммунизму

Тогда мне непонятен смысл вашего предыдущего коммента, в частности "Почему нельзя международному сообществу скинуться и разработать один раз бесплатный офис", если бесплатный офис уже разработан. Платным пользуются, очевидно, те, кого не устраивают возможности бесплатного. Ну и вопрос про постоянную поддержку остается открытым. Ведь тогда нужно скидываться постоянно, либо платить один раз наперед некоторую сумму побольше. Например, те же 30$.

Заглянем в будущее: на пути к цифровому коммунизму

Ну вот допустим, лет 20 назад сообщество скинулось и разработало один раз какую-нибудь операционную систему наподобие FreeDOS. Берите да пользуйтесь. Для него даже текстовые процессоры есть. Не хотите? А почему? Наверно, вам нужны возможности — оперативной памяти больше 1 МБ, поддержка нового оборудования. И вот уже "один раз" превращается в постоянную поддержку.

Ладно, DOS нам не нужен, у него мало возможностей. Вот есть Ubuntu и OpenOffice. Их разработало сообщество, и они бесплатные. Чем они вас не устраивают?

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

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

Так ведь steps это вторая переменная. Получается, это требование нарушено?

MongoDB хранение деревьев

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

public function getCommentsTree($post_id)
{
    $comments = Comment::find()->where(['post_id' => $post_id])->indexBy('id')->all();

    $topLevelComments = [];
    foreach ($comments as $comment) {
        if ($comment->parent_id) {
            $parentComment = $comments[$comment->parent_id];

            $comment->parentComment = $parentComment;
            $parentComment->childComments[$comment->id] = $comment;
        } else {
            $topLevelComments[$comment->id] = $comment;
        }
    }

    return $topLevelComments;
}

class Comment
{
    public $id;
    public $parent_id;
    public $post_id;
    // ...

    // заполняется снаружи при загрузке из базы
    public $parentComment = null;
    public $childComments = [];
}

Прекрати злоупотреблять массивами в PHP

Вот я не то чтобы сторонник массивов, ООП это конечно правильно, но аргументы у вас как-то не очень способствуют пониманию преимуществ.

// Что такое 100, что такое "2013-10-04 12:16:47"?
// Понятно, что IDE помогает, но когда такие билдеры на пол-экрана,
// как-то надоедает мышкой по переменным водить, чтобы понять что тут происходит.
$pond->addStockData(new StockData("Bream", 100, "2013-10-04 12:16:47"));

// Вот если массивом объявить, то сразу понятно, что 100 - это количество. Да и выглядит компактнее.
$pond = [
    'name' => 'Breakspear',
    'amenities' => ['shop'],
    'fishBreeds' => [
        ['name' => 'Bream', 'number' => 100, 'stocked' => '2013-10-04 12:16:47'],
        ['name' => 'Perch', 'number' => 50, 'stocked' => '2012-02-02 05:23:32'],
        ['name' => 'Common Carp', 'number' => 10, 'stocked' => '2011-01-23 14:42:59'],
    ],
];
$ponds[] = $pond;

К тому же для объектов надо билдеры писать, а массив объявил и все. А если из базы грузим, то и объявлять не надо.

Намного меньше кода для получения того же результата.

Код будет такой же, только в функцию getNamed() добавится аргумент $ponds, а в getTotalStocked() аргумент $pond.

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

А как вы без вложенных циклов посчитаете $stockedFish? Код будет аналогичный, один цикл по $ponds, второй в getTotalStocked($pond).

$ponds = new PondsCollection(); $ponds->add(...);

Зачем мне создавать коллекцию для методов типа add(), если я могу просто сделать $ponds[] = $pond? А если индексировать массив не числами, а первичными ключами сущности pond, то и получение или удаление можно сделать без всяких циклов, просто unset($ponds[$pond->id]).

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

Заглянем в будущее: на пути к цифровому коммунизму

С помощью формул сопромата вы можете рассчитать, какую нагрузку выдержит мост конкретной конструкции, сделанный из конкретных материалов. Допустим, мост выдерживает несколько грузовиков массой 10 тонн. У него хорошая архитектура? А надежность у него какая? Это так же зависит от целей. Если по нему будут ходить пешеходы, то нормально, если будут ездить грузовики с соседнего карьера, то маловато. Но рассчитав нагрузку, вы можете забыть учесть резонанс с ветром, несмотря на то, что формулы у вас есть. И если вы сами об этом не подумаете, подсказать вам сможет только более опытный архитектор.

Определение надежности ИС в плане нагрузки немного проще. Потому что можно запустить тесты и проверить, справляется ли система с требуемой нагрузкой. А можно и заранее рассчитать, для этого используется оценка сложности алгоритмов. Также есть, например, математический аппарат теории БД, который формально доказывает, что именно будет происходить при различных операциях с таблицами. Но в целом есть много аспектов и нюансов, по которым полное формальное доказательство хорошей архитектуры невозможно, трудоемко, или имеет большую вероятность отклонения. И нельзя придумать волшебную палочку, которая будет все решать за вас.