@RA
RA
07 Dec 2016

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

--
крутатенька

Рекомендовано: skobkin-ru и HobbitMage
08 Dec 2016

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

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

08 Dec 2016

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

#ootxuv/2 в ответ на /1
08 Dec 2016

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

#ootxuv/3 в ответ на /2
08 Dec 2016

Исус Мария. Единое АПИ для всех web-серверов. Может лучше полный ssh-доступ всем?

#ootxuv/4 в ответ на /3
08 Dec 2016

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

#ootxuv/6 в ответ на /4
08 Dec 2016

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

#ootxuv/7 в ответ на /6
08 Dec 2016

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

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

#ootxuv/8 в ответ на /7
08 Dec 2016

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

#ootxuv/5 в ответ на /3
08 Dec 2016

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

#ootxuv/9 в ответ на /1
08 Dec 2016

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

#ootxuv/11 в ответ на /10
09 Dec 2016

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

#ootxuv/12 в ответ на /11
09 Dec 2016

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

#ootxuv/13 в ответ на /12
09 Dec 2016

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

#ootxuv/14 в ответ на /13
09 Dec 2016

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

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

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

#ootxuv/15 в ответ на /14
09 Dec 2016

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

#ootxuv/16 в ответ на /15
09 Dec 2016

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

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

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

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

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

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

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

Комментарий был отредактирован в 16:22:27 09.12.2016
#ootxuv/18 в ответ на /16
09 Dec 2016

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

Лол.

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

Лол.

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

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

#ootxuv/19 в ответ на /18
09 Dec 2016

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

#ootxuv/21 в ответ на /20
09 Dec 2016

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

#ootxuv/22 в ответ на /21
09 Dec 2016

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

#ootxuv/23 в ответ на /22
09 Dec 2016

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

#ootxuv/25 в ответ на /23
09 Dec 2016

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

#ootxuv/24 в ответ на /22
09 Dec 2016

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

#ootxuv/27 в ответ на /21
09 Dec 2016

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

#ootxuv/26 в ответ на /18
10 Dec 2016

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

Комментарий был отредактирован в 08:08:31 10.12.2016
#ootxuv/28 в ответ на /26
10 Dec 2016

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

#ootxuv/29 в ответ на /28
10 Dec 2016

At first I was like

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

But then I thought more and was like

#ootxuv/30 в ответ на /29
10 Dec 2016

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

#ootxuv/31 в ответ на /30
10 Dec 2016

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

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

Комментарий был отредактирован в 22:23:22 10.12.2016
#ootxuv/32 в ответ на /31
11 Dec 2016

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

#ootxuv/33 в ответ на /32
11 Dec 2016

А. Да. Точно.

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

#ootxuv/34 в ответ на /33
11 Dec 2016

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

#ootxuv/35 в ответ на /34
11 Dec 2016

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

#ootxuv/36 в ответ на /35
12 Dec 2016

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

#ootxuv/37 в ответ на /36
12 Dec 2016

Да блин! Вот смотри, есть шаблон 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 %>
]
}
#ootxuv/38 в ответ на /37
12 Dec 2016

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

#ootxuv/39 в ответ на /38
12 Dec 2016

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

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

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

#ootxuv/40 в ответ на /39
12 Dec 2016

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

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

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

#ootxuv/41 в ответ на /40
12 Dec 2016

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

#ootxuv/42 в ответ на /41
12 Dec 2016

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

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

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

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

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

#ootxuv/47 в ответ на /42
12 Dec 2016

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

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

#ootxuv/50 в ответ на /47
12 Dec 2016

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

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

#ootxuv/44 в ответ на /40
12 Dec 2016

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

#ootxuv/45 в ответ на /44
12 Dec 2016

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

#ootxuv/46 в ответ на /44
12 Dec 2016

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

#ootxuv/48 в ответ на /46
12 Dec 2016

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

#ootxuv/51 в ответ на /49
12 Dec 2016

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

#ootxuv/52 в ответ на /51
12 Dec 2016

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

#ootxuv/53 в ответ на /52
12 Dec 2016

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

#ootxuv/54 в ответ на /53
12 Dec 2016

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

#ootxuv/55 в ответ на /54
12 Dec 2016

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

#ootxuv/56 в ответ на /53
12 Dec 2016

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

#ootxuv/58 в ответ на /56
12 Dec 2016

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

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

#ootxuv/59 в ответ на /58
12 Dec 2016

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

#ootxuv/60 в ответ на /59
13 Dec 2016

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

#ootxuv/63 в ответ на /62
13 Dec 2016

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

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

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

#ootxuv/64 в ответ на /60
12 Dec 2016

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

#ootxuv/57 в ответ на /51
12 Dec 2016

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

#ootxuv/61 в ответ на /57
13 Dec 2016

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

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

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

#ootxuv/65 в ответ на /61
13 Dec 2016

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

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

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

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

#ootxuv/66 в ответ на /65
13 Dec 2016

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

#ootxuv/68 в ответ на /66
13 Dec 2016

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

#ootxuv/69 в ответ на /68
13 Dec 2016

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

#ootxuv/70 в ответ на /68

Добавить пост

Вы можете выбрать до 10 файлов общим размером не более 10 МБ.
Для форматирования текста используется Markdown.