А нужно ли знать программисту алгоритмы?

Реализовать систему для учета печати и продажи билетов в отдельно взятом кинотеатре. Правильная декомпозиция модели данных, CRUD, UI, работа с принтером, использование джойнов для построения отчетов, двойная бухгалтерская запись, исправление ошибок при сбоях печати, обработка различных ситуаций при продаже билетов — возврат, повреждение или брак бланка. Связано с программированием? Да. Делает ее программист? Да. Нужно знание алгоритмов? Нет.

Написать драйвер для конкретных грузовых весов на заводе. Весы передают данные по малопонятому протоколу, надо сделать драйвер, который будет передавать данные в программу, в которой работает оператор, в том формате, который эта программа понимает. Никакого CRUD-а нет, нужно знание ассемблера и умение разбираться в непонятных протоколах. Связано с программированием? Да. Делает ее программист? Да. Нужно знание алгоритмов? Нет.

А нужно ли знать программисту алгоритмы?

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

А нужно ли знать программисту алгоритмы?

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

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

Если задачи не связаны с алгоритмами, алгоритмы знать не надо. Тем не менее, это тоже программирование.

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

Если задачи, связанные с алгоритмами, появляются в работе постоянно, алгоритмы знать надо.

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

Универсальные многоразовые формы данных. Рецепты приготовления и сервировки

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

Со временем любой стиль становится привычным

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

Универсальные многоразовые формы данных. Рецепты приготовления и сервировки

Вот вам несколько примеров. Обратите внимание на порядок запросов, а также на возможность пагинации и фильтрации.

        function query($table, $indexBy = null, $where = null)
        {
            $query = (new Query())->from($table);
            if ($where) $query->where($where);
            if ($indexBy) $query->indexBy($indexBy);
            return $query->all();
        }

        function splitBy($array, $column)
        {
            $res = [];
            foreach ($array as $row) {
                $value = $row[$column];
                $res[$value][] = $row;
            }

            return $res;
        }

        include 'mpfunc.php';

        // --------

        // пример с rb()

        // SELECT * FROM models
        // также происходит индексация массива по marks_id
        // остается только последний элемент с таким ключом
        // аналог неправильного запроса SELECT id FROM models GROUP BY marks_id

        // SELECT * FROM marks WHERE `id` IN (1,2)
        // foreach () {
        //     SELECT * FROM models WHERE `marks_id`=$marks['id']
        // }
        $res = rb("models", "marks_id");
        foreach (rb("marks", "id", "id", $res) as $marks) {
            echo '<h1>' . $marks['name'] . '</h1>';

            foreach (rb("models", "marks_id", "id", $marks['id']) as $models) {
                echo '<div>' . $models['name'] . '</div>';
            }
        }

        // --------

        // аналог с использованием query builder с вынесением повторяющихся операций в функцию
        $models = query('models', 'marks_id');
        foreach (query('marks', 'id', ['in', 'id', array_keys($models)]) as $mark) {
            echo '<h1>' . $mark['name'] . '</h1>';

            foreach(query('models', 'id', ['marks_id' => $mark['id']]) as $model) {
                echo '<div>' . $model['name'] . '</div>';
            }
        }

        // --------

        // как надо сделать правильно
        // (можно через DISTINCT или через EXISTS, не суть)
        // SELECT * FROM `marks` WHERE `id` IN (SELECT DISTINCT `marks_id` FROM `models`)
        // SELECT * FROM `models` WHERE `marks_id` IN ($filteredIDs)
        // foreach () {
        //     [никаких запросов в цикле нет]
        // }

        $subQuery = (new Query())->select('marks_id')->distinct()->from('models');
        $marks = query('marks', 'id', ['in', 'id', $subQuery]);

        $filteredIDs = array_keys($marks);
        $models = query('models', 'id', ['in', 'marks_id', $filteredIDs]);
        $modelsByMark = splitBy($models, 'marks_id');

        foreach ($marks as $mark) {
            echo '<h1>' . $mark['name'] . '</h1>';

            foreach($modelsByMark[$mark['id']] as $model) {
                echo '<div>' . $model['name'] . '</div>';
            }
        }

        // --------

        // то же самое с использованием ActiveRecord
        $subQuery = Model::find()->select('marks_id')->distinct();
        $marksQuery = Mark::find()->where(['in', 'id', $subQuery]);
        $marksQuery->with('models');
        // [сюда можно добавить пагинацию и фильтрацию]
        $marks = $marksQuery->all();
        foreach ($marks as $mark) {
            echo '<h1>' . $mark->name . '</h1>';

            foreach($mark->models as $model) {
                echo '<div>' . $model['name'] . '</div>';
            }
        }

Универсальные многоразовые формы данных. Рецепты приготовления и сервировки

Ну вот, например, пример из документации PDO (который, как я понял, вы используете для работы с БД):

$sql = 'SELECT name, color, calories FROM fruit ORDER BY name';
foreach ($conn->query($sql) as $row) {
    print $row['name'] . "\t";
    print $row['color'] . "\t";
    print $row['calories'] . "\n";
}

Возвращает он такой же ассоциативный массив, как у вас. Неужели вся универсальность вашего подхода заключается в том, что вы запихнули инкапсулировали запрос в функцию rb() и передаете название таблицы и условие для WHERE в параметрах? Ну так это первое, что приходит в голову любому, кто начинает изучать PHP и запросы к базе данных. Поэтому действительно, ничего особенного здесь нет.

Универсальные многоразовые формы данных. Рецепты приготовления и сервировки

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

Универсальные многоразовые формы данных. Рецепты приготовления и сервировки

А чем отличается ваш подход от других, скажем так, "форм" хранения и отображения данных?

Правильная работа с датой и временем

Я понял, что такое "ваш UTC". Я хотел узнать, чем ваше решение от него отличается. Начало отсчета unix time ведь находится в UTC, соответственно и сама метка тоже является временем в UTC.

Правильная работа с датой и временем

Извините, я не очень понял. Как хранение времени в формате unix timestamp избавляет от отображения этого времени по-разному для разных временных зон? И чем он отличается от того, что вы называете "ваш UTC"?

Асинхронное параллельное исполнение в PHP

Делал как-то тестовое задание, надо было реализовать параллельное вычисление числа pi методом Монте-Карло. Тоже сделал через proc_open(). Одним из условий была работоспособность на любой ОС, поэтому коммуникацию сделал через файлы. Результат можно посмотреть тут, может кому пригодится.

Хеди Ламарр. И в кино обнаженной сняться, и во врага торпедой пульнуть

Может тогда надо было вместо статьи на русском техническом ресурсе просто оставить ссылку на патент на английском?

Хеди Ламарр. И в кино обнаженной сняться, и во врага торпедой пульнуть

Хм, меня удивляет количество минусов, если честно) Аргументы какие-нибудь будут? Про синхроимпульсы с передающей станции в статье ни слова, а также я плохо представляю, как выглядит валик механического пианино, потому и спросил.

Хеди Ламарр. И в кино обнаженной сняться, и во врага торпедой пульнуть

Ok, thanks

Хеди Ламарр. И в кино обнаженной сняться, и во врага торпедой пульнуть

они разработали следующий алгоритм: необходимо использовать на передатчике случайный код

Какой сложный алгоритм, однако)

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

Угу, если противнику алгоритм смены неизвестен. Security through obscurity, тоже полезно конечно, но не гарантия.

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

А вообще интересно, спасибо.

Почему умер Хабр. Что делать и куда бежать

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

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

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

Сделай сам: SQL JOIN на Java

Ну вам же не всю таблицу надо держать, а только ФИО в данном случае. Допустим, у нас миллион клиентов. Длина полного имени примерно 30-40 символов. То есть такой кеш будет занимать примерно 60-80 Мб для двухбайтовой кодировки, плюс 4 Мб на интовый ключ. После запроса делаем пост-обработку, где идем по строкам, дергаем кеш и добавляем к результату поле full_name. Никакой сложной архитектуры, один дополнительный цикл, зато минус 1 джойн из всех запросов с ФИО и связанные с ним чтения с диска и передача через сеть.

Сделай сам: SQL JOIN на Java

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

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

Сделай сам: SQL JOIN на Java

Что мне мешает запустить EXPLAIN, увидеть там nested loops, пойти в документацию и прочитать там, что это значит, какие могут быть варианты, и как на это влиять через синтаксис и настройки?

Сделай сам: SQL JOIN на Java

Для каждого заказа и запрашивать. Только не из базы, а из кеша в оперативной памяти. Из этого же кеша смогут запрашивать и другие списки или отчеты. Уж что-что, а ФИО клиента не меняется практически никогда.