А зачем мне туда что-то вкладывать?
Я написал разметку, которая предполагает что внутри .menu лежат .item. А если вдруг, не пойми зачем, мне понадобится влепить что-либо между ними я просто добавлю один уровень в SCSS и будет не
.menu{
& > .item{}
}
а
.menu{
& > .some_shitty_block > .item{}
}
или если мне надо будет расписать стили того блока, то так:
.menu{
& > .some_shitty_block {
& > .item{}
}
}
Все доводы БЭМщиков это какие-то членовредительские моменты, когда «где-то между» ВДРУГ! возникают левые блоки. У меня они не возникают вдруг, код пишу я и моя команда внутри котороой есть оговоренности, а чаще всего один глобальный блок — один разраб, а значит и разметка и стили пишет один мозг, а если у него элементы появляются «вдруг», то встает вопрос «какого он забыл в команде»
Типа, от 1 до 10 000 с шагом 1. Такое в intarray не положить.
Ну, вот такое, опять же, просто решить:
SELECT * FROM products WHERE width>=1 AND width<=10000 AND (width%2)::boolean;
А что касается этого:
С таким вариантом проблема, когда продукты разнородные и у них есть не только width, но и height, depth, length, diagonal, density, volume, etc.
Каждый фильтр = столбец.
Надо по-просту верно составлять запрос, выставляя фильтры в порядке убывания фактора сокращения выборки, самые тяжелые фильры оставляя «на потом». А после этого прогнать запрос через EXPLAIN (ANALYSE, buffers) и поиграться с расположением фильтров.
агрЕгациях, вать машу!!!! *аштрисёт* (┛ಠДಠ)┛彡┻━┻
И речь вообще не про эластик, а про методики ускорения запросов с параметрической фильтрацией посредством intarray, каким боком сюда затесались полнотекстовые солр и эластик?
Да-да, помнится, делал удаление дублей до того как познакомился с окнами, а потом после. С окнами это один запрос, а без — страшно подумать, добавление столбца, создание последовательности, потом выборка по хевингу, и все это в табле с 2+млн записей, ужас! ( '/ /_ / /)
поэтому поддерживаться профессионалами, из наших налогов, быть свободным и без цензуры.
Вот это вы загнули =)
Это коммерческий проект, он не будет оплачиваться из налогов.
Даже если он и будет оплачиваться из налогов, то он по определению не будет свободным и без цензуры, ибо будет принадлежать какому-либо государству и как следствие оплачиваться из налогов граждан этого государства, а значит он будет как минимум содержать цензуру, как максимум доступен только гражданам того гос-ва. *щас представился квиток, в котором один из пунктов «обслуживание портала youtube.com за текущий месяц» :D*
Ну, такого ада я не встречал, в таком контексте — да. Обычно если до 20 сек, то пропустить нельзя, свыше — можно, если брать ютуб и рекламу в московском метро, например.
То есть реклама перед видео на видео-хостинге есть зло и хостер обязан предоставлять вам доступ к контенту за просто так? Спуститесь на землю, уверен вы на работу не за спасибо ходите.
Полагаю, потому, что на JS довольно сложно наговнокодить в «самом начале», когда тебе просто надо по нажатию на кнопочку прятать один элемент и показывать другой. Потом приходят колбэки и асинхронный отстрел всех твоих асинхронных ног, внутри замыкания — так что твои асинхронные ноги оказываются и не твоими вовсе, вот на этот моменте больше половины и отсеивается.
Так что такого уж глобального говнокода, на мой взгляд, на JS меньше, в то время как на пыхе можно с испугу неожиданно и по инерции фреймворк свой умудриться написать как сделал я когда-то.
В вашей реализации есть косяк в том что мы можем запросить сравнение размеров еще до загрузки картинки. Тогда придётся проверять его ещё раз после и так до тех пор, пока картинка не загрузится.
А что касается кеша, то и ваша реализация его не переборет.
В случае с событиями просто следует обрабатывать сразу два события load — Тогда сайт однозначно доступен и error — Тогда однозначно недоступен. До десктопа сейчас доеду, форкну и предложу свой вариант
По-моему дело в том что на широких экранах не размазывают инфу по всему свободному пространству, просто потому, что есть пределы фокуса зрения по ширине.
У меня например монитор 3440х1440 и для меня было бы странным заполнение всей ширины экрана плитками с товарами, не беря в расчёт тот факт что я всегда использую браузер в пол экрана.
Я написал разметку, которая предполагает что внутри
.menuлежат.item. А если вдруг, не пойми зачем, мне понадобится влепить что-либо между ними я просто добавлю один уровень в SCSS и будет неа
или если мне надо будет расписать стили того блока, то так:
Все доводы БЭМщиков это какие-то членовредительские моменты, когда «где-то между» ВДРУГ! возникают левые блоки. У меня они не возникают вдруг, код пишу я и моя команда внутри котороой есть оговоренности, а чаще всего один глобальный блок — один разраб, а значит и разметка и стили пишет один мозг, а если у него элементы появляются «вдруг», то встает вопрос «какого он забыл в команде»
А дальше хоть 10 раз одно в другое вложит, оно не посыпется.
Ну, вот такое, опять же, просто решить:
А что касается этого:
Надо по-просту верно составлять запрос, выставляя фильтры в порядке убывания фактора сокращения выборки, самые тяжелые фильры оставляя «на потом». А после этого прогнать запрос через
EXPLAIN (ANALYSE, buffers)и поиграться с расположением фильтров.Если какой-то более упоротый рейндж, в котором не все подряд значения, то с применением intarray выходит что-то а-ля:
Правда такой вариант работает в районе 40-50 раз медленнее. И тогда уже лучше использовать опять же ортодоксальный IN
который работает с той же скорость что
>= AND <=агрЕгациях, вать машу!!!!*аштрисёт* (┛ಠДಠ)┛彡┻━┻И речь вообще не про эластик, а про методики ускорения запросов с параметрической фильтрацией посредством intarray, каким боком сюда затесались полнотекстовые солр и эластик?
Вот это вы загнули =)
Так что такого уж глобального говнокода, на мой взгляд, на JS меньше, в то время как на пыхе можно
с испугунеожиданно и по инерции фреймворк свой умудриться написатькак сделал я когда-то.А что касается кеша, то и ваша реализация его не переборет.
В случае с событиями просто следует обрабатывать сразу два события load — Тогда сайт однозначно доступен и error — Тогда однозначно недоступен. До десктопа сейчас доеду, форкну и предложу свой вариант
У меня например монитор 3440х1440 и для меня было бы странным заполнение всей ширины экрана плитками с товарами, не беря в расчёт тот факт что я всегда использую браузер в пол экрана.