> этот код возвращает err в рантайме, а не ошибку компиляции:
Может я что-то не понимаю, но разве в каком-то языке возможно на подобное получать ошибку компиляции, а не ошибку в рантайме? Ведь мы же на этапе компиляции не знаем, что введёт пользователь и окажется ли введённая им строка целым числом.
В комментах ещё не упоминали такой стиль электронной музыки, как Liquid DnB. В последнее время мне нравится включать его фоном на небольшой громкости, когда пишу код. Такая музыка не отвлекает от работы, в то же время она достаточно энергичная и помогает таким образом не сбавлять рабочий темп.
Ну а ещё нравится во время работы слушать уже упомянутые здесь пост рок и транс, реже — тяжёлый рок и металл.
Ну тут, насколько я понимаю, проблема не столько в php-pm, сколько в приложениях, которые пытаются под ним запускать, но которые изначально создавались для другой («умирающей») модели выполнения.
Имеет ли Zend какие-либо преимущества по сравнению с Symfony для больших и Enterprise проектов? Просто кажется, что на этом поле как раз Symfony стал стандартом де-факто, а Zend как-то не виден и не слышен.
А причем тут 5.3.3 (с момента выхода которого, кстати, прошло 6 лет уже)?
А mod_php, которому уж точно сто лет в обед, на таком же принципе работает. Так что да, годами.
Ага, и постоянно таскается за собой в виде миллиона хаотично названных функций в глобальном пространстве имен
Это хоть как-то мешает?
(А еще там только только появилась нормальная поддержка Юникода)
Ээээ… это какая такая «нормальная поддержка Юникода» появилась в PHP «только только», не подскажите? Поддержки юникода в ядре PHP нет, не было и, похоже, не будет. Все задачи, связанные с юникодом, прекрасно решаются расширениями уже давным-давно.
А еще функциональные индексы крайне полезны для регистронезависимого поиска по строковому полю.
Делаем индекс на LOWER(название_поля), а в запросе пишем условие LOWER(искомая_строка) = LOWER(название_поля).
Если этого не делать, то, в отличии от MySQL, по умолчанию поиск будет регистро зависимым. И обычный индекс помочь не сможет.
Лично меня это новость радует, т.к. возможно для большинства моих задач станут не нужны vagrant+vbox, которые я сейчас активно использую. Можно будет обходиться «родными» средствами винды, которые, вероятно, будут работать пошустрее чем vagrant+vbox. А если там еще и docker полноценно будет работать, то вообще красота.
> этот код возвращает err в рантайме, а не ошибку компиляции:
Может я что-то не понимаю, но разве в каком-то языке возможно на подобное получать ошибку компиляции, а не ошибку в рантайме? Ведь мы же на этапе компиляции не знаем, что введёт пользователь и окажется ли введённая им строка целым числом.
Blazor — это вроде как WebAssembly. В JS он не превращается ни на каком этапе, насколько я понимаю.
По-моему полноценную поддержку ES-модулей в node.js пока ещё так и не завезли.
Ну а ещё нравится во время работы слушать уже упомянутые здесь пост рок и транс, реже — тяжёлый рок и металл.
Попробуйте DBeaver. Бесплатный, поддерживает разные СУБД.
этому комментарию
А mod_php, которому уж точно сто лет в обед, на таком же принципе работает. Так что да, годами.
Это хоть как-то мешает?
Ээээ… это какая такая «нормальная поддержка Юникода» появилась в PHP «только только», не подскажите? Поддержки юникода в ядре PHP нет, не было и, похоже, не будет. Все задачи, связанные с юникодом, прекрасно решаются расширениями уже давным-давно.
Делаем индекс на LOWER(название_поля), а в запросе пишем условие LOWER(искомая_строка) = LOWER(название_поля).
Если этого не делать, то, в отличии от MySQL, по умолчанию поиск будет регистро зависимым. И обычный индекс помочь не сможет.