По поводу дохода согласен, но я не в силах на это повлиять, и с чем связана такая практика в компании тоже сказать не могу.
Backend добавили специально. В целом кандидаты стали более релевантные.
Вся кодовая база у нас на TS, если вы конечно считаете его типизированным языком))
Глубокие знания JS, под этим я понимаю как минимум знание особенностей цепочки прототипов, event loop, современных функций типа groupBy, новых методов Set. Как максимум хотя бы базовое представление о внутреннем устройстве объекта в V8, всякие packed smi elements, holey elements, Shapes, Inline Caches и т.п. Таких готов оторвать с руками на индивидуальных условиях.
По этому я и написал, что за каждого стоящего кандидата буду договариваться индивидуально, как по окладу, так и по условиям работы.
Вакансия вообще из Питера, т.к там большой, просторный офис. Который загружен на половину. Если человек из Москвы, то там офис забит на 100% и сажать туда человека на фул тайм проблематично.
Вообще, это больше позиция руководства, чем моя. Я вообще из Мурома, и управление с частью команды в любом случае будет удалённо. Просто у нас в городе найти специалиста такого уровня практически невозможно. Все кто был либо уже работают, либо переехали.
По окладу, я как разработчик, примерно понимаю сколько может стоить программист с необходимыми знаниями. По этому 150 для этой вакансии даже не минимум. А максимум я всегда могу согласовать под конкретного кандидата.
Хотел бы рассказать свой опыт, как руководителя группы веб разработки, в поисках кандидата на должность middle+ JS/TS developer.
Вот уже больше месяца, безуспешно пытаемся найти мне в команду разработчика с богатым опытом и углублёнными знаниями именно нативного JS.
Я думал, что это не будет большой проблемой, но как же я ошибался...
Т.к компания не маленькая, и есть свой отдел HR, то от меня требовалось:
составить требования к вакансии
отправить вакансию на согласование
ждать резюме и выбрать тех, с кем мы готовы провести техническое собеседование
C первым пунктом проблем не возникло. Я описал основные технологии, с какими придётся иметь дело + добавил пару пунктов про знание особенностей языка, ООП, умение проектировать и т.д.
Со вторым пунктом также не было проблем, т.к компания заинтересована в расширение моей команды и к зарплатной вилке были готовы.
Перед публикацией вакансии со мной связалась HR и уточнила детали по вакансии и на что ей следует обращать внимание в резюме и ответах кандидата.
Т.к я также принимал участие в отборе кандидатов на вакансию frontend developer, и видел достаточно много резюме, то сразу объяснил HR, что хоть и знание React стоят у меня в вакансии в блоке "Будет плюсом", но обращать внимание надо на опыт проектирования и разработки проектов с нуля, выстраивание архитектуры и знание чистого JS.
В первую неделю после публикации, половину рабочего дня я тратил на анализ резюме и поиск интересных кандидатов. Типичный портрет кандидата получался следующий:
22-25 лет
мужчина
3-4 года работы в двух компаниях, одна во время/сразу после института, вторая по настоящее время
образование медицинское (да, таких было много)
курсы React в skillkox, нетология, яндекс практикум и т.д
В большинстве случаев, резюме состояло из одной страницы включая блок образования и информацию о себе.
Т.к бесконечный анализ резюме стал отнимать слишком много рабочего времени, было принято решение скорректировать требования к вакансии. Первым, очевидно, под нож пошёл блок "Будет плюсом" про знания React, GraphQL и т.п.
Также мы немного переписали требования, с целью заинтересовать node.js разработчиков. Я надеялся, что хоть они больше знают чистый JS.
На моё желание увеличить опыт с 4-5 до 8+ лет, HR сказала, что мы (как компания) не пройдём по зарплатным ожиданиям, чему я конечно же удивился, т.к сам перешагнул эту вилку около года назад, при гораздо большем опыте. Увеличение опыта, в моём понимание, было необходимо, чтобы отсеять бывших студентов и переключиться на категорию 30+.
После некоторого времени тишины, начали приходить интересные резюме. Типичный портрет кандидата поменялся кардинально. Теперь балом правили девушки 25+ лет с 5+ лет опыта node.js, техническим образованием и грамотно написанным резюме.
Начались технические собеседования, и хоть ответы на базовые вопросы по синтаксису и особенностям языка были правильно, но видимо в силу возраста и недостатка опыта углублённых знаний JS никто не показал.
HR перестала присылать новые резюме к середине сентября, а т.к человек всё-таки нужен, в попытках её активизировать, было выяснено, что часть кандидатов с необходимым опытом с кем она общалась, до меня до доходила, т.к либо просили больше, чем мы предлагаем, либо хотели гибрид/удалёнку, а не работу в офисе. Сколько интересных кандидатов мы упустили, сказать не могу, но я обозначил, что мне нужно присылать все резюме, а об условиях работы для каждого стоящего кандидата я буду договариваться индивидуально.
Ни M3 ни m1s gen 2 не подключается. В поддержке Яндекса говорят что Aqara не реализовали возможность подключения, типа используйте облачную интеграцию. Но если бы aqara не реализовали, то и в HomeKit нельзя бы было подключить по Matter коду. В общем Яндекс как обычно. Надеюсь добавят возможность в будущем, а так пока M3 для меня бесполезен, вернулся на m1s gen 2
Тоже очень удивлён. Вчера целый вечер потратил чтобы подключить aqara hub m1s gen 2 к алисе, в итоге так ничего и не вышло. В инете посмотрел ролик что надо сначала хаб пробросить по matter в apple home а потом там включить создание пары и взять оттуда код в яндекс, потому что иначе кнопки создания пары не будет, а стандартный код из приложения aqara не особо работает с яндексом.
В общем тоже вижу что в связанных экосистемах появляется "а 140", но подключение всегда завершается с ошибкой. Правда всегда с разной. Иногда проходит только первые пару пунктов, где поиск устройства и подключение к нему. А один раз я видел что дошло даже до передачи wifi и выдало ошибку на последнем только шаге. В общем от чего это зависит я так и не понял. Ещё в процессе добавления apple home пишет что добавился мост в дом, и я его потом вижу, правда название там цифровое, но всё равно не подключает.
@TimurRyabinin может подскажите, это вообще возможно? Или надо aqara hub m3
Есть правда минус проброса устройств aqara в apple home по matter. Там не синхронизируются ни названия, ни комнаты. Всё придётся настраивать заново. Ну и не все устройства переносятся.
Когда я пару лет назад хотел воспользоваться Вашим навигатором, мой город ещё был не отрисован. Сейчас зашёл и увидел что все дома есть, и навигация доступна. CarPlay, о чём ещё мечтать! Обрадовался и проложил маршрут до пары мест. Провёл через односторонку под кирпич, не надо так! Это хорошо я свой город знаю, но по сути мне и нужен навигатор, чтобы в других городах ориентироваться. Подожду пока карты дотянут до яндековских и буду пользоваться. Яндекс всё равно ещё долго до CarPlay не доберётся.
Похоже я всё-таки допёр что вы пытаетесь мне объяснить)
Да, эмуляция запроса у меня включена, и да, именно она и проверяет синтаксис и поля. По сути это такой тестовый запрос, только без данных и реальных действий. Если её отключить, то всё это будет проверяться уже при execute.
При execute да, данные просто эскейпятся, это никто и не отрицал.
По поводу плана, тоже всё верно. Его нельзя полностью построить т.к нет ещё значений, которые могут повлиять на выбор индекса.
Тут я ещё хотел написать, что ошибался, что execute делает заново разбор запроса и не учитывает результат prepare, но потом прочитал
http://php.net/manual/ru/pdo.prepared-statements.php
и понял, что по сути возможность компилить запросы и хранить их в БД зависит от самой БД.
В mySQL это http://dev.mysql.com/doc/refman/5.7/en/sql-syntax-prepared-statements.html
И почитайте как раз ссылку с php.net, там доступно рассказано то, что я уже так долго пытаюсь вам объяснить)
Ссылка моя, но я же не её автор. Вы скопировали кусок, который говорит что запросы «PDO::prepare() не может проверить правильность построенного запроса», я вам доказал что может, а вы снова доказываете что не может)
То есть для каждого value в IN(value1, ..., valueN) или заводить свой именованный параметр, или не использовать подготовленные выражения :)
Да, с IN вечная проблема, но вы опять всё переврали, т.к я это вы предлагали его использовать, а я объяснял почему он не удобен и не нужен в данном конкретном случае.
В разных местах обычно нужно выбрать разные данные, * выбирать не совсем правильно. :)
Во-первых, пример тестовый. Во-вторых, если бы вы внимательно прочитали, то поняли, что byId нужен только в рамках одной сущности, а одна сущность это одна таблица, а в ней для любой записи набор полей одинаковый. А когда сущность другая там и запрос будет уже select * from table2 а не select * from table1 и кеш будет уже для каждой таблицы. Т.е для каждой таблицы byId будет хранить кеш запроса, т.е одна компиляция на одну таблицу, что существенно меньше, чем одна компиляция на один запрос к одном таблице. Посчитайте на калькуляторе
Так, давайте разберёмся с PDO::prepare(), по моему вы что-то не поняли из документации или из моих объяснений. Я утверждаю что prepare компилит запрос, проверяя правильность синтаксиса и ждёт когда выполнится execute с параметрами. Соответственно для двух запросов, у которых разные только параметры нет смысла компилить запрос два раза, т.к sql код одинаковый (параметры не в счёт).
Да, логично что prepare не хранит компилированные запрос где-то у себя, он возвращает объект, который нужно сохранить в статическое свойство класса, а при повторном вызове похожего запроса просто взять уже скомпилированный запрос а не вызывать заново prepare, сделать это можно в пару строчек:
Теперь разберёмся с замечаниями, которые вы нашли по моей ссылке.
Либо я не правильно понимаю что это значит, либо вы, но я утверждаю что prepare именно разбирает запрос и проверяет в нём ВСЁ, за исключением значения параметров. Т.е если в запросе ошибка синтаксиса, или отсутствует поле, то это выявится именно на этапе prepare, и именно на это уходит время, и именно по этому при повторном запросе проще брать его из кеша. Я так понял что вы упёртый и мне не поверите, по этому я запустил запрос и протестировал, и сейчас вам докажу (вы что-то на пруфы не расщедрились):
Берём запрос:
select2 a.subject from `...` a
Получаем Exception:
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'select2 a.subject ....' at line 1
Надеюсь я вас убедил, если не верите, то запустите сами.
Теперь по поводу того, зачем выполнять один запрос несколько раз, если можно сделать column in. Объясняю:
Допустим у нас в ORM есть метод byId у которого есть запрос вида:
select * from `table` where `id`=:id
Далее в коде мы где-то хотим получить объём с id=1 и мы делаем Entity::byId(1). Далее мы с этим объектом работаем, и потом хотим получить объект с id=2 для каких-то других целей через 100500 строчек кода, и делаем Entity::byId(2). Так вот по-скольку эти строчки не идут друг за другом, и я не могу знать какие объекты мне будут нужны позднее, я использую параметаризированный запрос, который будет иметь один и тот же скомпилированный объект, а на этапе вызова заменять параметр :id на id нужного объекта, тем самым избегая затрат на парсинг и анализ этого запроса.
Подготавливает SQL запрос к базе данных к запуску посредством метода PDOStatement::execute(). Запрос может содержать именованные (:name) или неименованные (?) псевдопеременные, которые будут заменены реальными значениями во время запуска запроса на выполнение.
Вызов PDO::prepare() и PDOStatement::execute() для запросов, которые будут запускаться многократно с различными параметрами, повышает производительность приложения, так как позволяет драйверу кэшировать на клиенте и/или сервере план выполнения запроса и метаданные, а также помогает избежать SQL инъекций, так как нет необходимости экранировать передаваемые параметры.
Таким образом, это и подтверждает то, что я хотел сказать, а именно: для проекта, где один и тот же запрос может вызываться много раз с разными параметрами, то подготовка запросов будет выгоднее, т.к не будет постоянного парсинга запроса. По этому я и сказал, что оверхед при выполнение одного подготовленого запроса незначителен, а если этот запрос выполняется n раз, то лучше сократить издержки.
Согласитесь, что проще изучать общий синтаксис PDO а не API конкретного драйвера. Вся прелесть PDO, что переход на другой источник данных занимает меньшее время, а если ORM позволяет, то и вовсе подключаться к любой БД используя стандартные методы абстрактного класса.
И по поводу сравнение опций:
API поддерживает подготавливаемые запросы на стороне клиента: Нет(mysqli) Да(PDO)
Я считаю, что это важный пункт, оверхед на парсинг запроса конечно не так велик, но всё зависит от проекта. По крайней мере из таблицы я не смог увидеть минусов PDO.
Извините, но ваш код заставил меня страдать.
Пробежимся по главному:
1. Почитайте на досуге PSR-1 и PSR-2 http://www.php-fig.org/psr/. На русском есть тут.
2.
static public function setup(mysqli $dbi,$enc = "utf8"){
if (is_object($dbi)){
...
}else{
throw new Exception("Параметр $dbi не является объектом mysqli", 1);
return false;
}
}
Во-первых: mysqli морально устарел и мне кажется, что лучше использовать PDO.
Во-вторых: вы в интерфейсе функции чётко указали что хотите видеть в первом аргументе mysqli, и он не должен быть пустым. По этому PHP до версии 7 будет выдавать ошибку, а в 7й версии сам выкидывать TypeError если пришло то что не нужно. Если использовать функцию set_error_handler и преобразовывать стандартные ошибки в исключения, то можно существенно упростить код.
3.
SET NAMES '$enc'
$query .= " WHERE `$id` = ".self::escape($this->$id)." LIMIT 1";
private static function escape($string) {
return mysqli_real_escape_string(self::$db,$string);
}
Первый случай найдёте в стандартах, а для второго и третьего я бы порекомендовал использовать параметаризированные запросы из PDO
Являюсь обладателем Perfomance MX уже очень давно. До текущего обзора думал, что если сломается, то без вопросов куплю такую же. Сейчас весь в сомнениях. Хотелось бы узнать у владельцев MX Master пару вопросов по поводу настройки ПО:
1. Качание влево-вправо основного колёсика убрали видимо из-за наличия бокового. Я обычно ставил на эти кнопки уменьшение/увеличение громкости, и к этому уже безумно привык. Можно ли поставить громкость на боковое колесо?
2. Кнопки вперёд/назад выглядят очень кучно расположенными. На сколько удобно их использование (в обзоре про это есть, но я имею ввиду при длительном использовании)?
3. Не нашёл на скринах окна настройки кнопок для каждого конкретного приложения. Когда можно было например в MPC кнопки вперёд/назад настроить на перемотку +5/-5 сек.
4. В SetPoint была проблема, что не все кнопки можно было настроить для работы в конкретном приложении. Например нижняя и zoom программировались только глобально.
5. Является ли дополнительное колёсико кнопкой? На Perfomance была ещё кнопа zoom очень удобно расположенная рядом с большим пальцем, которую постоянно использовал как F5
И важный момент. Мне что нибудь должно было на почту придти после регистрации через соц сеть? Я ввёл email в ожидании пароля, который я смогу сменить чтоб потом заходить как везде, но ничего не пришло.
По поводу дохода согласен, но я не в силах на это повлиять, и с чем связана такая практика в компании тоже сказать не могу.
Backend добавили специально. В целом кандидаты стали более релевантные.
Вся кодовая база у нас на TS, если вы конечно считаете его типизированным языком))
Глубокие знания JS, под этим я понимаю как минимум знание особенностей цепочки прототипов, event loop, современных функций типа groupBy, новых методов Set. Как максимум хотя бы базовое представление о внутреннем устройстве объекта в V8, всякие packed smi elements, holey elements, Shapes, Inline Caches и т.п. Таких готов оторвать с руками на индивидуальных условиях.
скинул в личку
По этому я и написал, что за каждого стоящего кандидата буду договариваться индивидуально, как по окладу, так и по условиям работы.
Вакансия вообще из Питера, т.к там большой, просторный офис. Который загружен на половину. Если человек из Москвы, то там офис забит на 100% и сажать туда человека на фул тайм проблематично.
Вообще, это больше позиция руководства, чем моя. Я вообще из Мурома, и управление с частью команды в любом случае будет удалённо. Просто у нас в городе найти специалиста такого уровня практически невозможно. Все кто был либо уже работают, либо переехали.
По окладу, я как разработчик, примерно понимаю сколько может стоить программист с необходимыми знаниями. По этому 150 для этой вакансии даже не минимум. А максимум я всегда могу согласовать под конкретного кандидата.
Хотел бы рассказать свой опыт, как руководителя группы веб разработки, в поисках кандидата на должность middle+ JS/TS developer.
Вот уже больше месяца, безуспешно пытаемся найти мне в команду разработчика с богатым опытом и углублёнными знаниями именно нативного JS.
Я думал, что это не будет большой проблемой, но как же я ошибался...
Т.к компания не маленькая, и есть свой отдел HR, то от меня требовалось:
составить требования к вакансии
отправить вакансию на согласование
ждать резюме и выбрать тех, с кем мы готовы провести техническое собеседование
C первым пунктом проблем не возникло. Я описал основные технологии, с какими придётся иметь дело + добавил пару пунктов про знание особенностей языка, ООП, умение проектировать и т.д.
Со вторым пунктом также не было проблем, т.к компания заинтересована в расширение моей команды и к зарплатной вилке были готовы.
Перед публикацией вакансии со мной связалась HR и уточнила детали по вакансии и на что ей следует обращать внимание в резюме и ответах кандидата.
Т.к я также принимал участие в отборе кандидатов на вакансию frontend developer, и видел достаточно много резюме, то сразу объяснил HR, что хоть и знание React стоят у меня в вакансии в блоке "Будет плюсом", но обращать внимание надо на опыт проектирования и разработки проектов с нуля, выстраивание архитектуры и знание чистого JS.
В первую неделю после публикации, половину рабочего дня я тратил на анализ резюме и поиск интересных кандидатов. Типичный портрет кандидата получался следующий:
22-25 лет
мужчина
3-4 года работы в двух компаниях, одна во время/сразу после института, вторая по настоящее время
образование медицинское (да, таких было много)
курсы React в skillkox, нетология, яндекс практикум и т.д
В большинстве случаев, резюме состояло из одной страницы включая блок образования и информацию о себе.
Т.к бесконечный анализ резюме стал отнимать слишком много рабочего времени, было принято решение скорректировать требования к вакансии. Первым, очевидно, под нож пошёл блок "Будет плюсом" про знания React, GraphQL и т.п.
Также мы немного переписали требования, с целью заинтересовать node.js разработчиков. Я надеялся, что хоть они больше знают чистый JS.
На моё желание увеличить опыт с 4-5 до 8+ лет, HR сказала, что мы (как компания) не пройдём по зарплатным ожиданиям, чему я конечно же удивился, т.к сам перешагнул эту вилку около года назад, при гораздо большем опыте. Увеличение опыта, в моём понимание, было необходимо, чтобы отсеять бывших студентов и переключиться на категорию 30+.
После некоторого времени тишины, начали приходить интересные резюме. Типичный портрет кандидата поменялся кардинально. Теперь балом правили девушки 25+ лет с 5+ лет опыта node.js, техническим образованием и грамотно написанным резюме.
Начались технические собеседования, и хоть ответы на базовые вопросы по синтаксису и особенностям языка были правильно, но видимо в силу возраста и недостатка опыта углублённых знаний JS никто не показал.
HR перестала присылать новые резюме к середине сентября, а т.к человек всё-таки нужен, в попытках её активизировать, было выяснено, что часть кандидатов с необходимым опытом с кем она общалась, до меня до доходила, т.к либо просили больше, чем мы предлагаем, либо хотели гибрид/удалёнку, а не работу в офисе. Сколько интересных кандидатов мы упустили, сказать не могу, но я обозначил, что мне нужно присылать все резюме, а об условиях работы для каждого стоящего кандидата я буду договариваться индивидуально.
Ни M3 ни m1s gen 2 не подключается. В поддержке Яндекса говорят что Aqara не реализовали возможность подключения, типа используйте облачную интеграцию. Но если бы aqara не реализовали, то и в HomeKit нельзя бы было подключить по Matter коду. В общем Яндекс как обычно. Надеюсь добавят возможность в будущем, а так пока M3 для меня бесполезен, вернулся на m1s gen 2
Тоже очень удивлён. Вчера целый вечер потратил чтобы подключить aqara hub m1s gen 2 к алисе, в итоге так ничего и не вышло. В инете посмотрел ролик что надо сначала хаб пробросить по matter в apple home а потом там включить создание пары и взять оттуда код в яндекс, потому что иначе кнопки создания пары не будет, а стандартный код из приложения aqara не особо работает с яндексом.
В общем тоже вижу что в связанных экосистемах появляется "а 140", но подключение всегда завершается с ошибкой. Правда всегда с разной. Иногда проходит только первые пару пунктов, где поиск устройства и подключение к нему. А один раз я видел что дошло даже до передачи wifi и выдало ошибку на последнем только шаге. В общем от чего это зависит я так и не понял. Ещё в процессе добавления apple home пишет что добавился мост в дом, и я его потом вижу, правда название там цифровое, но всё равно не подключает.
@TimurRyabinin может подскажите, это вообще возможно? Или надо aqara hub m3
Есть правда минус проброса устройств aqara в apple home по matter. Там не синхронизируются ни названия, ни комнаты. Всё придётся настраивать заново. Ну и не все устройства переносятся.
мне тоже, пожалуйста
А так, спасибо за работу! Развивайтесь!
Хоть и перевод, но. Для того чтобы результат был не 40 а 96, как и в другом варианте, пример должен выглядеть:
Таким образом и первый вариант из статьи и второй даёт 96:
И почему-то мне кажется в этом и есть смысл, найти N-й член последовательности.
Да, эмуляция запроса у меня включена, и да, именно она и проверяет синтаксис и поля. По сути это такой тестовый запрос, только без данных и реальных действий. Если её отключить, то всё это будет проверяться уже при execute.
При execute да, данные просто эскейпятся, это никто и не отрицал.
По поводу плана, тоже всё верно. Его нельзя полностью построить т.к нет ещё значений, которые могут повлиять на выбор индекса.
Тут я ещё хотел написать, что ошибался, что execute делает заново разбор запроса и не учитывает результат prepare, но потом прочитал
http://php.net/manual/ru/pdo.prepared-statements.php
и понял, что по сути возможность компилить запросы и хранить их в БД зависит от самой БД.
В mySQL это http://dev.mysql.com/doc/refman/5.7/en/sql-syntax-prepared-statements.html
И почитайте как раз ссылку с php.net, там доступно рассказано то, что я уже так долго пытаюсь вам объяснить)
Ссылка моя, но я же не её автор. Вы скопировали кусок, который говорит что запросы «PDO::prepare() не может проверить правильность построенного запроса», я вам доказал что может, а вы снова доказываете что не может)
Да, с IN вечная проблема, но вы опять всё переврали, т.к я это вы предлагали его использовать, а я объяснял почему он не удобен и не нужен в данном конкретном случае.
Во-первых, пример тестовый. Во-вторых, если бы вы внимательно прочитали, то поняли, что byId нужен только в рамках одной сущности, а одна сущность это одна таблица, а в ней для любой записи набор полей одинаковый. А когда сущность другая там и запрос будет уже select * from table2 а не select * from table1 и кеш будет уже для каждой таблицы. Т.е для каждой таблицы byId будет хранить кеш запроса, т.е одна компиляция на одну таблицу, что существенно меньше, чем одна компиляция на один запрос к одном таблице. Посчитайте на калькуляторе
Да, логично что prepare не хранит компилированные запрос где-то у себя, он возвращает объект, который нужно сохранить в статическое свойство класса, а при повторном вызове похожего запроса просто взять уже скомпилированный запрос а не вызывать заново prepare, сделать это можно в пару строчек:
Накатал на коленке, надеюсь суть будет понятна.
Теперь разберёмся с замечаниями, которые вы нашли по моей ссылке.
Либо я не правильно понимаю что это значит, либо вы, но я утверждаю что prepare именно разбирает запрос и проверяет в нём ВСЁ, за исключением значения параметров. Т.е если в запросе ошибка синтаксиса, или отсутствует поле, то это выявится именно на этапе prepare, и именно на это уходит время, и именно по этому при повторном запросе проще брать его из кеша. Я так понял что вы упёртый и мне не поверите, по этому я запустил запрос и протестировал, и сейчас вам докажу (вы что-то на пруфы не расщедрились):
Берём запрос:
Получаем Exception:
и стеком:
Ещё один:
Получаем Exception:
и стеком:
Надеюсь я вас убедил, если не верите, то запустите сами.
Теперь по поводу того, зачем выполнять один запрос несколько раз, если можно сделать column in. Объясняю:
Допустим у нас в ORM есть метод byId у которого есть запрос вида:
Далее в коде мы где-то хотим получить объём с id=1 и мы делаем Entity::byId(1). Далее мы с этим объектом работаем, и потом хотим получить объект с id=2 для каких-то других целей через 100500 строчек кода, и делаем Entity::byId(2). Так вот по-скольку эти строчки не идут друг за другом, и я не могу знать какие объекты мне будут нужны позднее, я использую параметаризированный запрос, который будет иметь один и тот же скомпилированный объект, а на этапе вызова заменять параметр :id на id нужного объекта, тем самым избегая затрат на парсинг и анализ этого запроса.
Надеюсь понятно изложил.
Таким образом, это и подтверждает то, что я хотел сказать, а именно: для проекта, где один и тот же запрос может вызываться много раз с разными параметрами, то подготовка запросов будет выгоднее, т.к не будет постоянного парсинга запроса. По этому я и сказал, что оверхед при выполнение одного подготовленого запроса незначителен, а если этот запрос выполняется n раз, то лучше сократить издержки.
И по поводу сравнение опций:
API поддерживает подготавливаемые запросы на стороне клиента: Нет(mysqli) Да(PDO)
Я считаю, что это важный пункт, оверхед на парсинг запроса конечно не так велик, но всё зависит от проекта. По крайней мере из таблицы я не смог увидеть минусов PDO.
Пробежимся по главному:
1. Почитайте на досуге PSR-1 и PSR-2 http://www.php-fig.org/psr/. На русском есть тут.
2.
Во-первых: mysqli морально устарел и мне кажется, что лучше использовать PDO.
Во-вторых: вы в интерфейсе функции чётко указали что хотите видеть в первом аргументе mysqli, и он не должен быть пустым. По этому PHP до версии 7 будет выдавать ошибку, а в 7й версии сам выкидывать TypeError если пришло то что не нужно. Если использовать функцию set_error_handler и преобразовывать стандартные ошибки в исключения, то можно существенно упростить код.
3.
Первый случай найдёте в стандартах, а для второго и третьего я бы порекомендовал использовать параметаризированные запросы из PDO
4.
Тут лучше подойдёт sprintf
И в целом, как уже было сказано выше, для серьёзного проекта это вряд ли пригодится.
1. Качание влево-вправо основного колёсика убрали видимо из-за наличия бокового. Я обычно ставил на эти кнопки уменьшение/увеличение громкости, и к этому уже безумно привык. Можно ли поставить громкость на боковое колесо?
2. Кнопки вперёд/назад выглядят очень кучно расположенными. На сколько удобно их использование (в обзоре про это есть, но я имею ввиду при длительном использовании)?
3. Не нашёл на скринах окна настройки кнопок для каждого конкретного приложения. Когда можно было например в MPC кнопки вперёд/назад настроить на перемотку +5/-5 сек.
4. В SetPoint была проблема, что не все кнопки можно было настроить для работы в конкретном приложении. Например нижняя и zoom программировались только глобально.
5. Является ли дополнительное колёсико кнопкой? На Perfomance была ещё кнопа zoom очень удобно расположенная рядом с большим пальцем, которую постоянно использовал как F5