Я сам немного подрабатываю наставником на курсах PHP уровень 1/2, о которых вы пишите.
Не могу не согласиться с вашими замечаниями, с одной стороны. Сам требую в обязательном порядке использовать prepared statement или явное приведение к int в случае `$id = (int) $_GET['id'];` и подобных.
С другой стороны, на курсе "Уровень 2" (громко названным "Архитектура сложных веб-приложений", а фактически знакомящего студентов с основами использования фреймворка Yii2, эти проблемы уже исчезают по большей части.
Задача курса, на мой взгляд, познакомить студентов с основными принципами написания кода вообще, многие из них не имеют в целом алгоритмического мышления, какой-то базы, чтобы просто понять какие действия нужно совершить, чтобы из А получить Б, грузить их дополнительно принципами безопасности при построении веб-приложения на учебном проекте, имхо, не нужно. Это как в школе, достаточно сказать "нельзя делить на 0", а уже потом спустя пару лет объяснить почему и когда на самом деле можно и что из этого получится (предел или неопределенность и т.п.)
Легко заметить насколько отличается качество кода даже в учебном проекте от студента к студенту, у разных наставников разный подход, разные студенты думают по разному и т.п.
Различные тонкости они быстро узнают после пары-тройки код-ревью от старшего разработчика после того, как устроятся стажером-junior'ом в какой-нибудь аутсорс-компании, или в той же HTML Academy пройдут все ступени обучения (уровень 1, 2, 3, а ещё желательно акселлератор), или самостоятельно, при наличии наставника в будущем.
Разумеется, что они ставятся в очередь, а не теряются. Точнее даже «ждут своей очереди». Здесь больше идет речь про то что при помощи алгоритма проверяется «можем ли мы в данный момент отправить сообщение». Если нет, то ждём следующую итерацию, в противном случае — отправляем.
Мы вот сейчас переводим сервис на поддержку GDPR, ибо много клиентов из ЕС, которые платят нам много денег. Если возникнут проблемы с работой сервиса на территории ЕС нам будет очень плохо.
Если вы работаете только на территории своей страны (не в ЕС) и ваши пользователи тоже только из вашей страны, то разумеется никакой GDPR вы исполнять не обязаны. Но если вы хотите работать на территории ЕС, с пользователями ЕС, то необходимо выполнять законы ЕС.
Ну, прям регулярно-регулярно ничего не обещаю, делалось за 2 вечера с перерывом в неделю. Как правило, жду более менее свободных выходных, но делать что-нибудь более-менее часто :)
Графическое изображение волны уже делали на php https://github.com/afreiday/php-waveform-png
Хочется сделать, во-первых, без использования lame для пережатия, да. А во-вторых, более человеко-понятно.
Когда я реализовывал плеер потипу как на soundcloud вот тут http://serebniti.ru/airs/2016-03-15/ ( анимация у меня не на канвасе, а css) я решил отказаться от волны на png в сторону json файла из png, получаемом на лету, по нескольким причинам.
В целом да, интересный вариант, можно подумать в эту сторону, спасибо.
Как уже писал выше, это пока самый минимальный работающий функционал. Несомненно, по мере доработок придется переписывать многое. В идеале, хотелось бы получить некоторый формат перевода обычной нотной записи в, например, строку, и её парсинг и «компиляцию» в wav-файл.
Простым делением тут работать не будет, т.к. изменение частоты между нотами растет экспоненциально. То есть, условно, между A4 и A3 разность будет 220, а между A3 и A2, уже 110. Ну и как бы зачем вводить функцию для вычисления, если захардкодить реально проще?
В дальнейшем, возможно, сделаю именно динамический расчет, для более точного соответствия реальным звукам.
Если бы было сопоставимо по возможностям хотя бы с MySQL Workbench, было бы круто. То есть с возможностью применения миграций на основе текущей и удаленной таблицы.
Совсем мечта — в PhpStorm'е интеграция с фреймворками типа Yii и отображение структуры БД на основе моделей ActiveRecord… Но этой я совем розовые очки надел =)
Если я правильно понял, вы о CakePHP? Тогда целиком поддерживаю, ибо он просто из багов состоит, удивительно, что приведенный автором пример — не из него)
Честно говоря, о данном решении узнали совсем недавно, буквально пару недель назад, но нам не особо понравилось, во всяком случае их демо. То есть, например, я так и не разобрался как можно именно послать разные параметры запроса. Да и к дизайну Boostrrap'овскому уже привыкли
А какая разница? Порядок обработки select-case не определен, если в обоих каналах есть данные
Я сам немного подрабатываю наставником на курсах PHP уровень 1/2, о которых вы пишите.
Не могу не согласиться с вашими замечаниями, с одной стороны. Сам требую в обязательном порядке использовать prepared statement или явное приведение к int в случае `$id = (int) $_GET['id'];` и подобных.
С другой стороны, на курсе "Уровень 2" (громко названным "Архитектура сложных веб-приложений", а фактически знакомящего студентов с основами использования фреймворка Yii2, эти проблемы уже исчезают по большей части.
Задача курса, на мой взгляд, познакомить студентов с основными принципами написания кода вообще, многие из них не имеют в целом алгоритмического мышления, какой-то базы, чтобы просто понять какие действия нужно совершить, чтобы из А получить Б, грузить их дополнительно принципами безопасности при построении веб-приложения на учебном проекте, имхо, не нужно. Это как в школе, достаточно сказать "нельзя делить на 0", а уже потом спустя пару лет объяснить почему и когда на самом деле можно и что из этого получится (предел или неопределенность и т.п.)
Легко заметить насколько отличается качество кода даже в учебном проекте от студента к студенту, у разных наставников разный подход, разные студенты думают по разному и т.п.
Различные тонкости они быстро узнают после пары-тройки код-ревью от старшего разработчика после того, как устроятся стажером-junior'ом в какой-нибудь аутсорс-компании, или в той же HTML Academy пройдут все ступени обучения (уровень 1, 2, 3, а ещё желательно акселлератор), или самостоятельно, при наличии наставника в будущем.
В принципе, аналогичные законы есть и в РФ.
Неверно, там всё таки примеры не с segfault в классическом его понимании, а банальная бесконечная рекурсия, таких примеров можно миллион сделать.
То есть?
Вернет 5? Или данный код некорректен?
Хочется сделать, во-первых, без использования lame для пережатия, да. А во-вторых, более человеко-понятно.
В целом да, интересный вариант, можно подумать в эту сторону, спасибо.
В дальнейшем, возможно, сделаю именно динамический расчет, для более точного соответствия реальным звукам.
Совсем мечта — в PhpStorm'е интеграция с фреймворками типа Yii и отображение структуры БД на основе моделей ActiveRecord… Но этой я совем розовые очки надел =)
Спасибо за разъяснения