А теперь ложку дегтя:
Когда завезут нормальную поддержку Blade шаблонов? Этот вопрос висит уже много лет и нет никакого развития в эту сторону. Скорее наоборот — с каждой версией IDE становится всё хуже. Самая боль — подсказка имен переменных работает только в редких случаях. Например, если в шаблоне через phpdoc указать входящие переменные, то в Blade директивах нет подсказки имен к ним, но после того как полностью введено имя переменной, IDE его кое-как сопоставляет с тем что определено в PHPdoc (через Ctrl видно тип и даже начинает работать подсказка свойств объекта если переменная — объект), но как бы это уже не особо полезно. Аналогичная проблема с блоками @php и <?php ?> — они вообще живут в разных областях видимости даже относительно остальных Blade директив. Хотелось бы чтобы поддержка Blade шаблонов была более адекватной, чтобы не приходилось варить кашу из костылей типа такого:
Определенную в PHPdoc переменную $array не видно в Blade директивах, соответственно никаких подсказок имени в @foreach или в других блоках
В блоке @php() не видно переменную $value настолько что IDE выдает там ошибку 'Undefined variable $value' если не прописать /** var array $value */
В блоке @php() при прописанном /** var array $value */ ошибки нет, но есть предупреждение 'Expresion result is not used anywhere' хотя на следующей строке переменная используется
в строке {{ $varname }} IDE не знает о переменной $varname, т.е. и тут нет подсказки имени
в строке <?php echo ?> IDE видит $array, но $value и $varname подсвечивает с ошибками 'Undefined variable $value' и 'Undefined variable $varname'
Как видите — пользоваться такой реализацией совершенно не удобно. Это сплошная борьба с IDE вместо того чтобы заниматься чем-то полезным. В целом эффективность написания Blade шаблона в блокноте не сильно ниже чем в PHPStorm. Надеюсь Вас это заденет.
На все эти косяки есть Issue в багтрекере, которые игнорируются годами. Ну тут ничего нового — в JetBrains это уже стало традицией =( Как и то что я к каждому релизу на что-то жалуюсь на Хабре =)
Далекие времена PostgreSQL 9.1. Я тогда настройки делал по инструкциям. Магии как с настройками MySQL не припомню. Тем не менее около 2х лет проект работал без нареканий на БД. Что было после — не знаю.
Сейчас настройкой занимается специально обученный человек, так что не совсем в курсе насколько всё изменилось.
Мне казалось наибольшей сложностью перехода с MySQL на PostgreSQL для большинства было незнание стандартного SQL и привычка использовать нестандартные фишки MySQL. В добавок более строгая типизация не позволяла делать всякую фигню как в MySQL без явного приведения типов. А еще в PG foreign key уже тогда нормально работали в отличие от MySQL. Это как из песочницы вылезти в реальный мир.
А еще в PG нет вечного выбора между MyISAM и InnoDB.
Для меня наоборот после перехода на PG всё встало на свои места т.к. в универе был весьма толковый курс по стандартному SQL.
Как я Вас понимаю =) Я лет 10 назад после очередного марафона по оптимизации настроек и запросов в MySQL обнаружил что это недоразумение отказывается использовать выделенные ему 16 гигов оперативки и использует HDD (скажем спасибо TEXT типу колонок). В итоге психанул и перевел проект на PostgreSQL с минимальными изменениями в структуре и типах полей. В итоге мало того что все проблемы с нагрузкой испарились, так я еще и не настраивал в PG ничего кроме разрешенного объема памяти. Тогда еще были проблемы с производительностью COUNT(*), но проект все-равно работал намного быстрее чем MySQL. А потом я начал вспоминать универ и стандарт SQL со всеми его возможностями, которыми в MySQL и не пахло. В общем с того момента я зарекся использовать MySQL в проектах более чем сайт-каталог с небольшим количеством данных.
На сколько я понял — проблема с непопулярностью PostgreSQL в те времена была в основном потому что мало кто знал о нем и мало кто был способен адекватно использовать его возможности. Я вот, например, кайфовал от количества типов колонок и строгости типизации данных в сравнении с MySQL. А многие считают это проблемой или не понимают как это правильно использовать.
А еще больше меня удивляет скудность поддержки PostgreSQL в фреймворках и ORM даже сейчас.
Присоединяйтесь к моему крестовому походу =) Я в этом году на каждый релиз с кучей фич выкатываю несколько багов на которые забили. И, кстати, большинству из них несколько лет и не то чтобы они прямо такие безобидные. Пишу именно на хабре т.к. тут есть хоть какая-то адекватная реакция. Меня задолбал подход JetBrains к разработке IDE в виде "пофиг на баги, даешь 100500 новых фич", которые зачастую тоже багнутые… За год ничего не поменялось к сожалению, но хотя бы часть упомянутых багов исправляют. Правда, в этот раз я словил "Won't fix" на проблеме удобства когда сообщение о проблеме не соответствует реальной проблеме (WEB-20352 'closing tags matches nothing'). И ладно бы сказали что может когда-то поправят, так нет же — написали отмазку и закрыли… Печально это всё =(
Либо они злобные пираты и не палятся в багтрекере =)
Я как бы тоже не использую кириллицу в консольных командах, но в БД у меня всё на русском и часто нужно знать с каким объектом идет работа (все ID не запомнишь) — пока отлаживаю приходится абракадабру видеть что никак не ускоряет процесс разработки. Порой из терминала запускаю. В общем этот run anything капитально так недоделан и, судя по всему, в JetBrains на него забили. Как в том мультике — "и так сойдет!" =(
По кодировке в Run anything — сколько бы там мало голосов ни было, а косяк весьма значительный. Вероятно для большинства это не критично и они не жалуются и не голосуют. Но это не повод забивать на проблему, которой небыло в удобном и отлично работающем command line, выпиленном в пользу Run anything. Я еще долго буду припоминать Вам это решение =) Как минимум пока Run anything не доведете до ума.
Здравствуйте. И это снова я! И опять про то же самое что и в прошлый раз =(
Релиз хороший, наверно лучший за этот год. Но, увы, как обычно забили на работу над ошибками.
В Run вкладке уже минимум год не поддерживается кириллица.
Вот расшифруйте мне это:
Так я и не говорил про production версию =) В любом случае нужно будет обновлять код если найдутся несовместимости, а это тоже время. Пока оттестируешь, как раз выйдет пара обновлений.
Беда с переходом на PHP 8 началась с того что некоторые расширения не обновлены. Я столкнулся с 2мя:
imagick — вообще нет релиза с поддержкой php 8, в issue на github конкретики не наблюдается, хотя кому-то удалось собрать последний RC под Linux из исходников.
redis — нет dll для windows, но в changelog есть упоминание поддержки PHP 8.
Видимо придется какое-то время подождать =(
csrf-token — это токен защиты от подделки запросов (Wikipedia)
Он создается на сервере и вживляется в форму. Т.е. по факту его можно получить только если скачать страницу с формой и достать его из html. Это если говорить про web. Как оно работает в мобильных приложениях я не знаю. Не сталкивался.
Глянул сейчас форму авторизации хабра в web-версии — там нет csrf токена, но есть какой-то скрытый state. Скорее всего это и есть csrf токен. Либо токен как-то передается в AJAX запросы напрямую или через cookies. В общем тут тупиковый вариант скорее всего.
Без официального API вероятно не получится нормально реализовать авторизацию. Да и потом — после авторизации нужно будет узнать какие запросы и куда отправлять чтобы получить нужные данные.
И они тоже. Правда в моем случае я если что-то и заплатил, то совсем немного. Несколько лет назад брал, когда еще не ввели лимиты на посылки. Сейчас стало сложнее с этим.
Для 1080p 8-14 Mb/s. 8 — проигрывается сносно. При 12-14 уже куда более ощутимые просадки. А с SVP 4 на 60fps и 8 Mb/s с ощутимыми просадками проигрывается.
Задержка видна по движению курсора мыши. Движется плавно, но с ощутимой задержкой. Поверх фильма вообще иногда дико тормозит. Я еще пробовал переключать на 720p, но просадки все-равно были заметны, хотя и не так часто.
Хромкаст не пробовал. Вообще, похоже что беспроводная передача видеопотока высокого качества пока невозможна (даже с хорошим роутером). Я пытался разобраться в чем может быть проблема и в целом сложилось ощущение что просадки при 1080p вообще у всех, кто пользуется беспроводной передачей видеопотока и решение этой проблемы сейчас не существует. Я предполагаю что, возможно, найдут способ как-то оптимальнее кодировать видео, либо использовать не wi-fi, а что-то пошутсрее. Может к следующей смене проектора что-то изменится в лучшую сторону.
Бери Epson — я своим очень доволен (Home Cinema 2045, сейчас есть поновее модели, но с минимальными отличиями). До этого был BenQ 720p относительно дешевый. Разница по качеству изображения огроменная. Если хочется сэкономить — можно посмотреть в США в BestBuy с пересылкой через местный склад. Я сэкономил где-то 35% включая пересылку. В таком варианте две проблемы — пандемия и wi-fi. Прикол в том что американские версии проекторов отличаются названием (у нас всякие TW-*, а у них Home Cinema XXXX) и из-за этого на них не действуют сертификаты, оформленные для российских версий. На таможне такой проектор могут не пропустить из-за этого. Компания, которая пересылкой занималась порекомендовала слать более долгим путем через Германию т.к. там можно в декларации написать только «Пректор Epson» не указывая модель. Приехало без проблем.
Теперь про wi-fi — он не тянет 1080p. Это выражается в задержке (2-5 секунд) и просадках битрейта. Я плюнул и провел HDMI. Некрасиво, зато можно хоть 40-гиговый фильм запустить и никаких тебе тормозов не будет. А если хочется кайфануть по-полной — поставь программу SVP 4. Бесплатная версия так себе, а вот платная может 120fps выдавать без проблем. Плавность видео прямо потрясающее. Главное чтобы проц тянул.
WI-51861 определенно странный баг, скорее всего как-то связанный с моей системой или с Laravel (есть подозрение что фреймворк тут тоже играет роль). Я пока не могу проверить на рабочем компьютере из-за удаленки. Попозже дополню, если он присутствует и там. Но он определенно постоянный у меня и не зависит от настроек IDE.
Новые фичи нужны, никто не спорит. И делать их куда интереснее, по себе знаю. Тем не менее баги имеют свойство размножаться и накапливаться. А потом сожрут разработчиков =)))
Довольно толковый релиз получился. Молодцы.
А теперь ложку дегтя:
Когда завезут нормальную поддержку Blade шаблонов? Этот вопрос висит уже много лет и нет никакого развития в эту сторону. Скорее наоборот — с каждой версией IDE становится всё хуже. Самая боль — подсказка имен переменных работает только в редких случаях. Например, если в шаблоне через phpdoc указать входящие переменные, то в Blade директивах нет подсказки имен к ним, но после того как полностью введено имя переменной, IDE его кое-как сопоставляет с тем что определено в PHPdoc (через Ctrl видно тип и даже начинает работать подсказка свойств объекта если переменная — объект), но как бы это уже не особо полезно. Аналогичная проблема с блоками
@phpи<?php ?>— они вообще живут в разных областях видимости даже относительно остальных Blade директив. Хотелось бы чтобы поддержка Blade шаблонов была более адекватной, чтобы не приходилось варить кашу из костылей типа такого:Тут проблема чуть ли не в каждой строке:
$arrayне видно в Blade директивах, соответственно никаких подсказок имени в@foreachили в других блоках@php()не видно переменную$valueнастолько что IDE выдает там ошибку 'Undefined variable $value' если не прописать/** var array $value */@php()при прописанном/** var array $value */ошибки нет, но есть предупреждение 'Expresion result is not used anywhere' хотя на следующей строке переменная используется{{ $varname }}IDE не знает о переменной$varname, т.е. и тут нет подсказки имени<?php echo ?>IDE видит$array, но$valueи$varnameподсвечивает с ошибками 'Undefined variable $value' и 'Undefined variable $varname'Как видите — пользоваться такой реализацией совершенно не удобно. Это сплошная борьба с IDE вместо того чтобы заниматься чем-то полезным. В целом эффективность написания Blade шаблона в блокноте не сильно ниже чем в PHPStorm. Надеюсь Вас это заденет.
На все эти косяки есть Issue в багтрекере, которые игнорируются годами. Ну тут ничего нового — в JetBrains это уже стало традицией =( Как и то что я к каждому релизу на что-то жалуюсь на Хабре =)
Далекие времена PostgreSQL 9.1. Я тогда настройки делал по инструкциям. Магии как с настройками MySQL не припомню. Тем не менее около 2х лет проект работал без нареканий на БД. Что было после — не знаю.
Сейчас настройкой занимается специально обученный человек, так что не совсем в курсе насколько всё изменилось.
Мне казалось наибольшей сложностью перехода с MySQL на PostgreSQL для большинства было незнание стандартного SQL и привычка использовать нестандартные фишки MySQL. В добавок более строгая типизация не позволяла делать всякую фигню как в MySQL без явного приведения типов. А еще в PG foreign key уже тогда нормально работали в отличие от MySQL. Это как из песочницы вылезти в реальный мир.
А еще в PG нет вечного выбора между MyISAM и InnoDB.
Для меня наоборот после перехода на PG всё встало на свои места т.к. в универе был весьма толковый курс по стандартному SQL.
Как я Вас понимаю =) Я лет 10 назад после очередного марафона по оптимизации настроек и запросов в MySQL обнаружил что это недоразумение отказывается использовать выделенные ему 16 гигов оперативки и использует HDD (скажем спасибо TEXT типу колонок). В итоге психанул и перевел проект на PostgreSQL с минимальными изменениями в структуре и типах полей. В итоге мало того что все проблемы с нагрузкой испарились, так я еще и не настраивал в PG ничего кроме разрешенного объема памяти. Тогда еще были проблемы с производительностью COUNT(*), но проект все-равно работал намного быстрее чем MySQL. А потом я начал вспоминать универ и стандарт SQL со всеми его возможностями, которыми в MySQL и не пахло. В общем с того момента я зарекся использовать MySQL в проектах более чем сайт-каталог с небольшим количеством данных.
На сколько я понял — проблема с непопулярностью PostgreSQL в те времена была в основном потому что мало кто знал о нем и мало кто был способен адекватно использовать его возможности. Я вот, например, кайфовал от количества типов колонок и строгости типизации данных в сравнении с MySQL. А многие считают это проблемой или не понимают как это правильно использовать.
А еще больше меня удивляет скудность поддержки PostgreSQL в фреймворках и ORM даже сейчас.
Присоединяйтесь к моему крестовому походу =) Я в этом году на каждый релиз с кучей фич выкатываю несколько багов на которые забили. И, кстати, большинству из них несколько лет и не то чтобы они прямо такие безобидные. Пишу именно на хабре т.к. тут есть хоть какая-то адекватная реакция. Меня задолбал подход JetBrains к разработке IDE в виде "пофиг на баги, даешь 100500 новых фич", которые зачастую тоже багнутые… За год ничего не поменялось к сожалению, но хотя бы часть упомянутых багов исправляют. Правда, в этот раз я словил "Won't fix" на проблеме удобства когда сообщение о проблеме не соответствует реальной проблеме (WEB-20352 'closing tags matches nothing'). И ладно бы сказали что может когда-то поправят, так нет же — написали отмазку и закрыли… Печально это всё =(
Эту настройку я пробовал — она у меня уже давно стоит UTF-8 и после обновления не поменялась. Как было криво так и осталось, к сожалению.
Понятно. Опять намудрили.
Дополню баг в трекере.
Спасибо за подсказку! Помогло =)
Я правильно понимаю что этой настройки нет в File->Settings… ?
Либо они злобные пираты и не палятся в багтрекере =)
Я как бы тоже не использую кириллицу в консольных командах, но в БД у меня всё на русском и часто нужно знать с каким объектом идет работа (все ID не запомнишь) — пока отлаживаю приходится абракадабру видеть что никак не ускоряет процесс разработки. Порой из терминала запускаю. В общем этот run anything капитально так недоделан и, судя по всему, в JetBrains на него забили. Как в том мультике — "и так сойдет!" =(
По кодировке в Run anything — сколько бы там мало голосов ни было, а косяк весьма значительный. Вероятно для большинства это не критично и они не жалуются и не голосуют. Но это не повод забивать на проблему, которой небыло в удобном и отлично работающем command line, выпиленном в пользу Run anything. Я еще долго буду припоминать Вам это решение =) Как минимум пока Run anything не доведете до ума.
Здравствуйте. И это снова я! И опять про то же самое что и в прошлый раз =(
Релиз хороший, наверно лучший за этот год. Но, увы, как обычно забили на работу над ошибками.
В Run вкладке уже минимум год не поддерживается кириллица.
Вот расшифруйте мне это:
Таска — IDEA-240787 и WI-57430 (создал новую т.к. старая не совсем про кодировку и мой комментарий к ней проигнорирован)
Все еще нет истории запусков Run anything — WI-48014. Так сложно делать вкладку на каждый запуск из окошка Run anything?
Поддержка Blade шаблонов до сих пор отвратительна — WI-46437. С самого начала были проблемы с видимостью переменных. Прошли годы, а воз и ныне там.
Так я и не говорил про production версию =) В любом случае нужно будет обновлять код если найдутся несовместимости, а это тоже время. Пока оттестируешь, как раз выйдет пара обновлений.
Беда с переходом на PHP 8 началась с того что некоторые расширения не обновлены. Я столкнулся с 2мя:
Видимо придется какое-то время подождать =(
csrf-token — это токен защиты от подделки запросов (Wikipedia)
Он создается на сервере и вживляется в форму. Т.е. по факту его можно получить только если скачать страницу с формой и достать его из html. Это если говорить про web. Как оно работает в мобильных приложениях я не знаю. Не сталкивался.
Глянул сейчас форму авторизации хабра в web-версии — там нет csrf токена, но есть какой-то скрытый state. Скорее всего это и есть csrf токен. Либо токен как-то передается в AJAX запросы напрямую или через cookies. В общем тут тупиковый вариант скорее всего.
Без официального API вероятно не получится нормально реализовать авторизацию. Да и потом — после авторизации нужно будет узнать какие запросы и куда отправлять чтобы получить нужные данные.
Хромкаст не пробовал. Вообще, похоже что беспроводная передача видеопотока высокого качества пока невозможна (даже с хорошим роутером). Я пытался разобраться в чем может быть проблема и в целом сложилось ощущение что просадки при 1080p вообще у всех, кто пользуется беспроводной передачей видеопотока и решение этой проблемы сейчас не существует. Я предполагаю что, возможно, найдут способ как-то оптимальнее кодировать видео, либо использовать не wi-fi, а что-то пошутсрее. Может к следующей смене проектора что-то изменится в лучшую сторону.
Теперь про wi-fi — он не тянет 1080p. Это выражается в задержке (2-5 секунд) и просадках битрейта. Я плюнул и провел HDMI. Некрасиво, зато можно хоть 40-гиговый фильм запустить и никаких тебе тормозов не будет. А если хочется кайфануть по-полной — поставь программу SVP 4. Бесплатная версия так себе, а вот платная может 120fps выдавать без проблем. Плавность видео прямо потрясающее. Главное чтобы проц тянул.
Новые фичи нужны, никто не спорит. И делать их куда интереснее, по себе знаю. Тем не менее баги имеют свойство размножаться и накапливаться. А потом сожрут разработчиков =)))
Буду надеятся на багобойный релиз.