*быдлокод, веб, софт, говно

Будь у браузеров прямой доступ к данным, а не к перехуяченному HTML, всё было бы гораздо проще и сопровождаемее. Эх!..

@Lavir, прямой доступ к данным сервера?

Да. Ну или через API какое-нибудь, я не знаю. Через read-only SQL.

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

Ну зачем же так сразу? Есть же JSON-ы всякие, SOAP-ы — вот это всё. Тот же SQL можно ограничить отдельными вьюшками. Короче говоря, интерфейс, с которым могли бы общаться машины, а не только люди. Но, понятно, что никто этого делать не будет. Эх!..

@Lavir, ну так есть уже. Протокол http называется.

Ну, этот протокол настолько абстрактный, что сегодня его пора уже спускать на представительский уровень в модели OSI.

Тем не менее, гуд поинт, машинно-читаемый интерфейс можно сделать и на HTML (и его уже сделали, «семантическая верстка» называется). Это вопрос, э-э-э, ориентации. При написании морды можно ориентироваться на людей, а можно на машины. Но никто не пишет морды, ориентированные на машины, все пишут только под конечного пользователя. Рыночек, блядь, порешал.

Поздравляю с изобретением мета-тегов.

А? Э? Что?

Нативный для веба способ передать клиенту какие-то метаданные с сервера.

Мне нужны не метаданные, а данные.

@Lavir, так тебе же целая страница данных приехала. Что тебе еще нужно?

Блядь, сука, ебаны в рот, ты издеваешься, да? Они там в таком виде, что лучше бы не приходили вообще. Хаотично расставленные теги, рандомные кейворды, мегабайты JS, и потом оказывается, что это не все данные пришли, остальные надо забирать AJAX-ом. Это все равно что распечатывать страничку, потом фотографировать, сжимать шакальным JPEG-ом и в таком виде присылать. Человек-то прочитает (может быть), а вот машина…

@Lavir, машина это тоже читает, парсит, рендерит и показывает тупому пользователю. При это не сильно лажает.
А для всякой дополнительной информации придумали, как тебе уже сказали, meta-теги. Которые лежат внутри той же страницы и
а) по особому названы,
б) содержат потенциально нужную информацию.

Пример такого тега -- title. Браузер находит его внутри тега head и показывает содержимое тега title в заголовке таба/браузера.
Есть и всякие другие, придуманные для разных целей.
Но у них у всех есть проблема: их наличием должен озаботиться программист, который их добавит в генерирование страницы.

А пользовательские браузеры никто в сервер, кроме как по http, не пустит.

В общем-то, у мета-тегов есть ещё важное качество: определённый формат. У каждого мета-тега своя спецификация. Поэтому довод "они там в таком виде, что лучше бы не приходили вообще" не прокатит для мета-тегов. Под каждый тип желаемой для получения с сервера порции метаданных заводится свой тег и всё работает замечательно.

skobkin-ru, именно.

Нет, ты в натуре издеваешься.

машина это тоже читает, парсит, рендерит и показывает тупому пользователю.

Машина это только показывает тупому пользователю.

А для всякой дополнительной информации

Мне не нужна дополнительная информация!

Вот тебе пример. Решил я купить стиральную машину через интернет. У меня в городе есть пять магазинов, у всех есть сайт с каталогом. Я хочу выбрать из всего ассортимента всех пяти магазинов самую лучшую и самую дешевую машину. Для этого я хочу взять их все, отсортировать их по цене, выкинуть отдельных производителей, выкинуть машины без инверторного двигателя, выкинуть то, выкинуть сё и представить это в простой и понятной табличке без рекламы и телефонов.

Будь у всех сайтов в мире хотя бы нормальное JSON API, я бы решил эту задачу за 10 минут — ровно столько, сколько нужно, чтобы набить ERB-шаблон моей таблички. Но сейчас я вынужден писать граббер одного сайта, писать отдельно граббер другого сайта (потому что у него совершенно другой шаблон), материться на третий сайт (потому что его какой-то уёбок сверстал исключительно на тегах <p>, <br>, <b> и <i>, и вычленить из этой каши хотя бы цены вообще невозможно, даже регулярками) и споткнуться на четвертом сайте (потому что там таблица выглядит как (function(x,y){var z=(function(){[]})();z[x]=y();}(Google,Angular)…).

Будь у всех сайтов в мире хотя бы нормальное JSON API

Лол.

я бы решил эту задачу за 10 минут

Лол.

Но сейчас я вынужден писать граббер одного сайта, писать отдельно граббер другого сайта

Как мило, что ты думаешь, что наличие JSON API у каждого сайта избавило бы тебя от проблем :)

@Lavir, открой для себя https://schema.org/Product

Daemon, точнее, нужно чтобы Microdata открыли для себя создатели сайтов с магазинами и каталогами.

зачем оно им? Некоторые даже цену не ставят. "Уточняйте".

RA, так отож. @Lavir, ты много сайтов напарсишь, если на них цен не будет? ;)

RA, для продвижения в гуглях, например. Гугл эту микродату прямо в поиске показывает.

Я от того и ржу, что упрёк идёт в сторону серверов, HTTP и браузеров, хотя по сути, проблема в сайтах.

@Lavir, открывеаешь ты пять сайтов своих магазинов, а у всех написано "чтобы узнать цену -- звоните" :)

Я проверил 5 крупных украинских онлайн магазинов: Комфи, Алло, Фокстрот, Розетка, Цитрус. Все пять используют микродата для описания продуктов.

Не, там в каталогах всё путем. А про microdata не слышал. Это где его искать у магазинов надо?

@Lavir, внутри страницы товара. Почитай описание. Плюс у Гугла есть тестер страниц на предмет микродаты.

At first I was like

But then… Блядь, а нахера это надо, если в итоге все равно надо данные помечать отдельно? И нахера, блядь, брать данные, упаковывать их в страницу, чтобы потом клиент распаковывал ее обратно, когда можно данные взять и выдать сразу, ёбанарот? Алсо, у одного сайта такая структура микроданных, у другого сякая, и в итоге надо все равно грабилку писать.

But then I thought more and was like

@Lavir, выдать сразу что именно?

Каталог. В виде JSON. Сейчас вот я отправляю запрос на сервер, сервер мне выдает метровый HTML с JS-ом, говнлм, троянами и itemprop-ами, мой компьютер это все парсит, выгребает, делает JSON и только потом формирует отчет. Почему бы серваку сразу не отдавать мне JSON, чтоб я по нему формировал отчет?

Есть ведь два применения выдачи сайта магазина: 1) почитать глазами; 2) обработать программой.

@Lavir, а теперь прикинь количество запросов второго вида.

А. Да. Точно.

На самом деле нет. Нерелевантно. Держать две точки API дешевле, чем одну, которая выдает нужное представление плюс кучу мусора (ведь дешевле же?). В разработке это тоже не сильно сложнее: если уж так хочется иметь шаблоны на HTML с микроданными, то никто не мешаетл потом на этапе сборки разделять их на human-readable вьюшку и шаблон JSON.

@Lavir, не дешевле. Нужно разработать, протестить, выкатить и не забывать обновлять. Вот теперь я вижу человека ни дня не работавшего в веб-разработке.

Пжи-пжи, достаточно ведь протестить генератор (который лежал бы где-нибудь в NPM, PIP или вообще в репках линуксодистрибов, будь эта фича разработка софта в этом мире востребована) и потом просто хуярить им пары «страничка на HTML — точка API». Да, шаблон HTML с микроданными надо все равно проверять. Разве не так?

@Lavir, шаблон с микроданными проверяется вместе с версткой.
Да и шаблон — это нифига не главное. Основное — данные. Откуда npm/pip/apt/rpm узнает о структуре твоей базы?

Да блин! Вот смотри, есть шаблон ERB:

<html><head>…</head><body>
<% for item in @db.execute("SELECT * FROM products") %>
  <div class='ramochka' itemscope>
    <span class='jirno' itemprop='name'><%=item.name%></span> — <span itemprop='price'><%=item.price%></span> dollars
  </div>
</body></html>

Что мешало в 2010-ом году сделать софтину, которая бы на вход получала этот шаблон, а на выходе выдавала два шаблона:

1.

<html><head>…</head><body>
<% for item in @db.execute("SELECT * FROM products") %>
  <div class='ramochka'>
    <span class='jirno'><%=item.name%></span> — <%=item.price%> dollars
  </div>
<% end %>
</body></html>

2.

{"data":
[
<% for item in @db.execute("SELECT * FROM products") %>
  {
    "name": <%=item.name.quote%>,
    "price": <%=item.price.quote%>
  },
<% end %>
]
}

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

@Lavir, не, ну если у тебя такие шаблоны, то никто не мешает.
А в основном мешают следующие вещи:
- два шаблона нужно тестить два раза;
- нужно поддерживать 2 ендпоинта.

А радости от этого -- полтора гика. А роботы типа гугла-яндекса обычно не используют itemprop.
Для яндекс.маркета делается выгрузка отдельной .xml-ки с товарами, для гугла -- можно использовать sitemap.

Бизнесу-то какая радость от того, что ты напишешь робота-парсера?

два шаблона нужно тестить два раза;

Сказал же, что не нужно! Нужно тестить один шаблон, а пара шаблонов и точек будет генерироваться. Если тестирование происходит методом белого/серого ящика, да.

В остальном все верно. И у меня слегка бомбит от этого. Хочешь, блядь, пожрать нормального хлеба — покупай гектар земли, зерна, комбайн и печку. Хочешь ходить в нормальных тапках — строй швейную фабрику. Хочешь выбрать мультиварку по чему-нибудь кроме цены, фирмы и цвета — изучай программирование, веб-дев и пиши грабберы. Спасибо хоть за микроданные.

@Lavir, кто тебе сказал, что не нужно? Или ты думаешь, что в генераторе не может быть ошибок?
А что, сайты магазинов, куда ты ходишь, не умеют в сравнение товаров?

Пиздец.

нужно поддерживать 2 ендпоинта.

На самом деле, нет. В Symfony, например, ты можешь спокойно в одном экшене отдавать один и тот же набор данных в шаблон и в зависимости от запрошенного клиентом типа контента у тебя либо через Twig отрендерится HTML, либо сериализуется JSON, XML или ещё что ты там понапридумываешь.

Ну, не совсем так, как я написал, но в целом суть - автоматическое разруливание в каком виде отдать пользователю в наличии.

skobkin-ru, и что, при этом не нужно будет тестить оба шаблона?

Или ты думаешь, что в генераторе не может быть ошибок?

Генератор можно было бы написать пять лет назад и оттестировать, как подобает. Никто же не тестирует Yii при каждом деплое, тестируют код, использующий Yii. Ведь так?

А что, сайты магазинов, куда ты ходишь, не умеют в сравнение товаров?

Вот именно, что они только в сравнение и умеют. По цене и цвету.

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

Ну, конечно, нужно будет. Но это не то чтобы сильно страшная задача.
Тем более, если у тебя используется какой-нибудь сериализатор с маппером, с его помощью можно обратно всё это в те же инстансы сущностей или DTO перегнать и довольно просто проверить соответствие. HTML тестировать сложнее. А его тестировать придётся в любом случае - даже если ты не будешь выдавать JSON :)

Вот, я про это и говорю.

Никто же не тестирует Yii при каждом деплое, тестируют код, использующий Yii. Ведь так?

Речь о том, что всё равно функциональный тест на то, что тебе даже JSON-шаблон вернёт то, что ты ожидаешь делать надо. Независимо от того, что Yii оттестирован вдоль и поперёк. Но см /48.

Ты не про это говоришь :)
Если взять твой кейс с "эти магазины могут только в сортировку по цвету" - кастомные форматы выдачи тебе ничего не дадут, если магазин не указывает полные характеристики товара.
То есть, где-то в идеальном мире это всё было бы круто. А так лучше пользоваться каким-нибудь Яндекс.Маркетом.

skobkin-ru, > лучше пользоваться каким-нибудь Яндекс.Маркетом.
для которого магазин готовит и отдает специальную .xml-ку. :)

Да. Потому, что у них отношения с Яндекс.Маркетом на деньги завязаны. А отношения с @Lavir у них ничем не завязаны. Он может у них даже не купить ничего.

skobkin-ru, именно. Поэтому @Lavir приходится писать свой граббер, парсер и сравниватель.

А мог бы просто занести кому-нибудь бабла!

Да ты охуел, «не завязаны»! А деньги-то у кого, блядь? Или в этом новом мире покупатель уже не является главной ценностью? Деньги теперь уже как-то по-другому зарабатываются, от взаимодействия магазина с Яндекс.Маркетом?

Нет, характеристики-то указаны как раз все (ну, кроме срока службы). Просто они: 1) представлены в уебищном виде; 2) сайт не дает по ним фильтровать, сортировать, а иногда и сравнивать.

@Lavir, пока ты не купил — ты магазину сплошной убыток.

А, в этом смысле.

Попробую довести до абсурда. Получается, что мне вообще не надо никакой информации о товаре предоставлять? Ценник из магазина убрать… Да что там, магазин закрыть вообще нафиг. Прям со складов пусть самовывозом берут!

Посчитай, сколько процентов таких как ты, посчитай сколько будет стоить поддержка такой функциональности и ответь, надо ли оно магазину :)

Ну так они и в БД часто в уёбищном виде хранятся. Тебе не смогут нормализованные данные выдать в том же JSON некоторые магазины, даже если бы хотели.

skobkin-ru, теперь ты тут дежуришь.

Торжественно назначаешь меня вахтёром треда?

Ну да, подавляюшее большинство выбирает так:

— Ну, давай открывай. Так. Что так долго-то? Ну, наконец-то. Ой, какие есть! 50 000, кош-ма-а-р, это что за машина-то! Из золота, что ли? Кошмар! Ну ладно, давай наверх. Пджи, вот, вот эту открой. Да, эту. Ой, кака-а-я! А сколько у нее оборотов? Ну подожди, не дергай, дай почитать! Ты-ты-ты… Ой, а у нее загрузка-то всего 4 кг! Не-е-е, это нам не надо, давай другие посмотрим. Ну-ка, а отзывы… Ну что ты все закрыл-то, дай отзывы почитать! У-у-у, бурдюк! Отзывы, да, сюда нажимай. Так, что там пишут. Ты-ты-ты, ты-ты-ты… Угу, поня… Ну подожди, не дергай! Что ты дергаешь-то все? Я читаю, он дергает! Так, ну, понятно. Давай другие. Так, какие еще есть. Ну подожли, не дергай, дай я посмотрю! Верни, вон там была за 15! Вот, вот эту открой. Да, вот эту. Так, что это за машина… Ой, ка-ка-а-я! Во, серебристая, мне как раз под цвет стен надо! Так, ты-ты-ты, 1200 оборотов, вот! Ну подожди, не дергай, что ты дергаешь-то все! Я читаю, он дергает! О-о-ой! Бурдюк ты! Так, оборотов… Крышка, 75°… А это сколько? Ой, это она вот так мало раскрываться будет? У-у-у, не-е-е, это мне не надо такое! Ладно, закрывай. Погоди, а отзывы… Ладно. Ладно, всё, не надо. Давай еще посмотрим. Так, какие еще есть… Ну, LG я не хочу… Вот всякие есть, а которой надо — нету! Так… Ну подожди, куда ты так крутишь-то, я не успеваю! Дай почитать! О-о-ой! Как с тобой тяжело! Так. Так. Ну, там дальше уже за 30 пошли, это уже дорогие, не надо. Ну-ка, а давай еще раз ту посмотрим, вот которую первый раз смотрели? Да, вот эту вот. Да, вот. Открывай! Та-а-ак… Ну вроде так-то тонкая на вид, да? Но вот эта панелька черная, мне не нравится, не могли нормальную сделать, что ли?.. Ну куда ты дергаешь-то, верни! Я смотрю, он дергает! Что за привычка дурацкая, в самом деле! Куда ты дергаешь-то все время? О-о-ой! Ну, ничего, смотрится так, но вот эта панелька… Ладно, давай характеристики. Так, обороты… Ну куда ты убрал-то, верни, я читаю! Ну сейчас я дочитаю, я же не сказала, что дочитала, сейчас я дочитаю и перемотаешь! Что за привычки, правда? О-о-ой! Так, обороты, размер люка… О, функция вот эта, биостирка! Вот это вот мне надо, да! Но 4 кг всего, мало как-то, я не знаю…

Большинству невдомек, что вот эту всю хуйню компьютер вполне может сделать сам. Я, видимо, первый в мире до этого додумался, а также не поленился изучить инструментарий для таких вещей. Инструментарий этот, правда, ГОВНИЩЕ блядское — для простейших вещей нужно иметь PhD и писать килобайтные обертки. Может быть, поэтому численность людей, владеющих этим инструментарием, не превышает еди пренебрежимо мала с точки зрения продавца.

Вот это я тоже не понимаю. Нет, я понимаю, что дьявол кроется в деталях, и сам на простых задачах порождал километровые схемы… Но, блджад, в списке товаров-то какие могут быть детали? Чем не устраивает такая схема:

CREATE TABLE products (
  name TEXT,
  price NUMERIC, -- похуй, какой конкретно тип
  oboroty NUMERIC,
  ecostirka BOOLEAN,
  eshe_harakteristika TEXT
);
CREATE TABLE otzyvy …;
CREATE INDEX index1 … ;
CREATE INDEX index2 … ;

Зачем для товаров вообще нужно больше одной таблицы?

Вот это я тоже не понимаю.

Я тебе говорю о всяких говноуниверсальных CMS и CMF типа Битрикса, где и сама CMS так себе, так и ещё и писать на ней нихуя не умеют. В результате в БД АД творится.
А та таблица товаров, что ты привёл - это вообще пиздец какое специализированное решение под одни лишь стиральные машины. И нет, когда у тебя нормально построена архитектура с опциями и характеристиками выдать нормальный JSON как раз не проблема.
Проблема когда у тебя как в некоторых магазинах это делается, все характеристики в одном текстовом поле лежат, например.

Зачем для товаров вообще нужно больше одной таблицы?

Я серьёзно должен отвечать на этот вопрос?

Как тебя штырит-то!

Магазин же не только стиральными машинами торгует!

@Lavir, угу. поэтому под каждый тип товара запилим отдельную табличку. Потому что у каждого типа товара свой собственный набор аттрибутов. :)

И поэтому он должен разбатывать себе сайт с нуля и только под стиралки.