ну это я уже понял

запилил расширение, если кому-то интересно могу скинуть

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

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

гугл хочет

ты что-то путаешь

гугл хочет стили в head, скрипты перед </body>

гугл хочет стили в head, скрипты перед </body>

http://ybex.com/d/t5hdxkuvq21su9rdgfngothlj33564f4b4kggv2i.html

они про скрипты мишут

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

просто у них сообщение одно и на скрипты и на стили

удали 8 скриптов - сообщение должно пропасть

не пропадет, я это уже проверял

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

https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery

новые css будут же вызывать перерендер страницы

по-моему он не будет полный, т.е. без белого листа на мнгновенье

гугл хочет

То что вы пытаетесь сделать называется critical path css, и вполне себе отличная штука и без требований Гугла Другой вопрос - зачем он в вашем проекте? Такой подход выгоден либо когда у вас много однообразно контента, с кучей обвяза, либо когда у вас очень тяжелые основные css

Я, конечно, не видел, но скажу сразу: такой подход выгоден когда у вас свой css, а не minified bootstrap, и тд

Я кстати баловался для оптимизации css и выполнения данной рекомендации гугла. Критичные CSS запилил в код, а в футер переместил подгружаемый файл CSS .. и все равно гугл ругается на рендер CSS , будь то он в конце или нет. Кое каким костылем для мобильного теста его только получилось обмануть

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

Кстати через этот костыль media="none" для мобильных pagespeed теперь перестал ругаться на css https://i.g1k.ru/YzdiOT.png

а то что не оптимизируемо, так это счетчики гугла и яндекса..

вот примерно такой костыль использовал http://stackoverflow.com/questions/32759272/how-to-load-css-asynchronously помимо critical path css

Такой вопрос появился из темы оптимизации под гугл, кто чем сжимает изображения?

Такой вопрос появился из темы оптимизации под гугл, кто чем сжимает изображения?

Я использую https://github.com/Alex-Bond/yii2-thumbler, вроде нормально

Я использую https://github.com/Alex-Bond/yii2-thumbler, вроде нормально

Спасибо, гляну что за зверь, впервые вижу что в компоненте yii используется библиотека от симфонии оО

Такой вопрос появился из темы оптимизации под гугл, кто чем сжимает изображения?

Можно установить gulp, настроить вотчеры и таски один раз и больше не париться.

Я использую server-side pagespeed

Кинте ссылки на какие нибудь годные видеоконференции на русском языке по yii

Я использую server-side pagespeed

немного не понял, вы имеете в виду модуль для nginx/apache ?

Можно установить gulp, настроить вотчеры и таски один раз и больше не париться.

тоже вариант, но хотелось бы что то на php, на шаред хостинг не получиться поставить gulp

Кинте ссылки на какие нибудь годные видеоконференции на русском языке по yii

Да что их кидать, забей в youtube yiiconf

Да что их кидать, забей в youtube yiiconf

не всегда с конфы прям найти можно что-то годное на ютубике

Хорошо, а где еще можно достать видеоконференций ?

Слышь! Есть видеоконфа ? А если найду ?)

?

немного не понял, вы имеете в виду модуль для nginx/apache ?

Ага) (Предыдущий ответ удалил, ибо сонный перепутал сообщения куда отвечать)

Ребята, а кто-то работал с postgreSQL? Насколько она перспективней MySQL? Для yii, я думаю, пофиг будет, какая СУБД на сервере - только конфиг поправить, чтобы драйвер был другой?

Ребята, а кто-то работал с postgreSQL? Насколько она перспективней MySQL? Для yii, я думаю, пофиг будет, какая СУБД на сервере - только конфиг поправить, чтобы драйвер был другой?

по всем аспектам круче

если ты можешь работать на mysql и тебе нужно сдать проект в сроки то работай на mysql

по всем аспектам круче

Ну не прям уж по всем

если ты можешь работать на mysql и тебе нужно сдать проект в сроки то работай на mysql

замени mysql на postgresql и получится равнозначное сообщение

Иначе у каждого еврея на компе бы инстанс был поднят

если ты можешь работать на mysql и тебе нужно сдать проект в сроки то работай на mysql

Мне для собственного развития MySQL умеем, можем, но интересно поковыряться в чем то новом)

Иначе у каждого еврея на компе бы инстанс был поднят

популярность, но это не функциональное свойство

Дело не популярности А чтоб не возникли сложности в реализации проекта который сорвут сроки

популярность, но это не функциональное свойство

На мой взгляд преимущества довольно специфичные

Ну не прям уж по всем

Может есть какой-то круг задач, в которых postgreSQL показывает себя лучше чем, например, MySQL?

если для себя то пожалуйста

Мне для собственного развития MySQL умеем, можем, но интересно поковыряться в чем то новом)

на простых проектах можешь не заметить разницы

Дело не популярности А чтоб не возникли сложности в реализации проекта который сорвут сроки

я про это и сказал. ноль проблем.

я конечно не про изучение новой БД на базе нового проекта. сначала изучить надо

на простых проектах можешь не заметить разницы

А какую себе задачу поставить, чтобы использовать postgreSQL на максимум? Ну или, по крайней мере, оценить аспекты работы, и увидеть разницу (если она есть) с MySQL

На мой взгляд преимущества довольно специфичные

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

плюс mysql только в распространенносятх на шаредах каких-нибудь

быстрее - не факт

функциональнее - да

но это, как в ворде тексты набивать, которые и в блокноте можно

А какую себе задачу поставить, чтобы использовать postgreSQL на максимум? Ну или, по крайней мере, оценить аспекты работы, и увидеть разницу (если она есть) с MySQL

хз. window function почитай на хабре, сравни типы данных с mysql

я конечно не про изучение новой БД на базе нового проекта. сначала изучить надо

А чё мне изучать? Для начала нужно оценить как с этим работать. Благодаря orm я могу забыть про разные бд на фоне. Значит, как программисту, мне важно понять, будут ли проблемы при переводе yii с MySQL на postgreSQL, и какие я получу преимущества, или подводные камни, после смены БД

А уже потом, после того, как я с этим поработаю, уже лезть в дебри, в конфиги, механику работы

ERROR: S client not available

хорошая фишка - индексы по выражениям, например price > 100 или результат любой функции

хз. window function почитай на хабре, сравни типы данных с mysql

Читал, сравнивал типы данных Но все же хотелось бы услышать отзывы людей, которые с этим работали, что, по их мнению, заслуживает внимания

Просто с MySQL каждый в этом диалоге работал, ставлю 10$ :D

А вот тех, кто postgreSQL может - не так то и много

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

А вот тех, кто postgreSQL может - не так то и много

Тут много https://telegram.me/pgsql

А вот тех, кто postgreSQL может - не так то и много

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

А вот тех, кто postgreSQL может - не так то и много

Надо различать pl/pgsql и стандарт SQL, с последним хоть в оракле можно "уметь"

хз. window function почитай на хабре, сравни типы данных с mysql

mariadb умеет, mysql умер давно

mariadb умеет, mysql умер давно

че-то не замечаю смерти) вижу новые версии регулярные и разработку нового stable. в прочем и window в mariadb пока в stable не вижу

perl тоже новые версии выходят

perl тоже новые версии выходят

и? вопрос в критериях смерти.

че-то не замечаю смерти) вижу новые версии регулярные и разработку нового stable. в прочем и window в mariadb пока в stable не вижу

Доктор сказал умерла, значит умерла (с)

https://yasb.exileed.com/telegram/chat/1001046156199

я на пятом месте :D

почти самый флудераст

SELECT DISTINCT dma_campaign_expert.user_id, dma_campaign_expert.campaign_id, dma_campaign.percent_pay from dma_campaign_expert left join dma_campaign on dma_campaign.id = dma_campaign_expert.campaign_id where dma_campaign_expert.campaign_id is not null order by dma_campaign.percent_pay desc кто скажет, почему тут distint не пашет

Может потому что связь один ко многим?

а как реализовать выборку? у меня есть таблицы: dma_campaign_expert expert | campaign 2 | 4 2 | 3 1 | 3 dma_campaign id | percent_pay 3 | 55 4 | 44 нужно выбрать записи из таблицы dma_campaign_expert, но у одного эксперта должна быть одна кампания. кампания выбирается та, у которой больший percent_pay результат: expert | campaign 2 | 3 1 | 3

у которой больший percent_pay Подзапрос или having

having сломает пагинацию если она подразумевается

кампания выбирается та, у которой больший percent_pay. Больший должен быть именно для того экспрета, у которого несколько кампаний, а не во всей таблице

чет пока не понимаю как хавинг прикрутить

А, да, хэвинг не пойдёт в таком случае

GROUP BY MAX

SELECT dma_campaign_expert.user_id, dma_campaign_expert.campaign_id, t.percent_pay FROM (SELECT MAX(percent_pay) AS percent_pay, id FROM dma_campaign GROUP BY id) AS t LEFT JOIN dma_campaign_expert ON t.id = dma_campaign_expert.campaign_id WHERE dma_campaign_expert.campaign_id IS NOT NULL ORDER BY t.percent_pay DESC

SELECT dma_campaign_expert.user_id, dma_campaign_expert.campaign_id, t.percent_pay FROM (SELECT MAX(percent_pay) AS percent_pay, id FROM dma_campaign GROUP BY id) AS t LEFT JOIN dma_campaign_expert ON t.id = dma_campaign_expert.campaign_id WHERE dma_campaign_expert.campaign_id IS NOT NULL ORDER BY t.percent_pay DESC

неа, не пашет

+---------+-------------+-------------+ | user_id | campaign_id | percent_pay | +---------+-------------+-------------+ | 1000 | 3 | 44 | | 1001 | 3 | 44 | | 1000 | 4 | 55 | +---------+-------------+-------------+

user_id не должен повторяться