Pull to refresh

Comments 26

Если честно, то хочется спросить — иии? Где пример реализации и прочий контент?

Просто интересное времяпрепровождение для опытных разработчиков

Для опытных разработчиков это не интересно от слова «совсем».
Не соглашусь слегка. Это вопрос количества таких условий в фильтре и/или разных весовых коэффициентов значимости каждого условия для формирования итоговой выборки. Например, ситуация с подчиненностью одного условия другому. Мы сталкивались с реализацией такого фильтра, там не все было прям уж так однозначно.
Вы уж определитесь, это простая задача, которая может рассматриваться, как «практика для изучающих программирование» и «тестовое задание для отбора кандидатов», или все же сложная задача для «интересного времяпрепровождения опытных разработчиков»

Это как бы взаимоисключающие понятия.
Я нигде не утверждал ни того ни другого. Как прошедший аналогичную задачу на практике, ответственно заявляю, что задачи такого плана не всегда тривиальны и не всегда элементарны в своей реализации. Особенно если производительность еще важна.
Рассказываю.

Это делается так
SELECT * FROM Schuhe_Farbe SF, Schuhe_Groesse SG, Alle_Sache AS WHERE SG.Groesse = :Groesse AND SG.Groesse_id = AS.Groesse_id AND AS.Farbe_id = SF.Farbe_id


Задача применима как первая задача в раунде на codeforces, чтобы гроссмейстеры могли за 5 минут заработать себе несколько сотен баллов на фоне новичков, которые будет делать ее 15 минут. =)
постановка задачи не полная, потому как начало выбора может быть с любой позиции — смотря что важно покупателю размер, цвет, замок. если важен замок — значит надо начать фильтрацию с замов, вторым может оказаться размер, и последним цвет. я б добавил кнопку сброса «фильтров». а так — задача для первого класса. и представлять данные в json глупо. первоначально должно всё исходить из структуры таблиц с этими данными, json в данном случае как пятое колесо телеги…
Дополнил, спасибо. Задачу можно расширять в разные стороны по желанию практикующегося. Задача ориентирована на Client-Server-ную архитектуру, из-за этого json. И да, не SQL единым)
Json — это куча лишней работы, первый шаг — преобразовать данные в json, второй шаг — на клиенте преобразовать json в html. (десктоп-клиент для клиент-серверной архитектуры рассматривать нет смысла). Поэтому смело можно исключить одно преобразование — и, соответственно, убрать json как затратную часть. Использовать «серверный рендеринг» сформировать сразу html и его передать клиенту, который вставляется одной строкой.
Задачу можно дополнять, но тогда возникает вопрос — где остановиться? А точку остановки назначит только реальное, конкретное применение. Как тестовое такое задание может служить только как повод для отклонения кандидата :)… И в большей степени является критерием качества постановщика задачи и писателя ТЗ. Чем более точно всё описано — тем меньше времени будет на реализацию.
Как Практика для изучающих программирование — если только как пример необходимости более правильной и более полной постановки задачи.
Как Тестовое задание для отбора кандидатов — лично я оцениваю, что постановка задачи не полная, следовательно и в дальнейшем будут проблемы в этой конторе с постановками задач для программистов.
Как Просто интересное времяпрепровождение для опытных разработчиков — есть задичи и более интересные.
Json — это куча лишней работы, первый шаг — преобразовать данные в json, второй шаг — на клиенте преобразовать json в html. (десктоп-клиент для клиент-серверной архитектуры рассматривать нет смысла). Поэтому смело можно исключить одно преобразование — и, соответственно, убрать json как затратную часть. Использовать «серверный рендеринг» сформировать сразу html и его передать клиенту, который вставляется одной строкой.

Вы это серьёзно? Серверный рендеринг только позволяет уменьшить скорость отображения первого экрана. Но вместе с html передаётся state приложения в том же JSON. Да и html генерируется кодом с клиентского приложения из этого же самого JSON-а. Как вы собираетесь строить state client приложения? Из html-а?

Задачу можно дополнять, но тогда возникает вопрос — где остановиться? А точку остановки назначит только реальное, конкретное применение. Как тестовое такое задание может служить только как повод для отклонения кандидата :)… И в большей степени является критерием качества постановщика задачи и писателя ТЗ. Чем более точно всё описано — тем меньше времени будет на реализацию.
Как Практика для изучающих программирование — если только как пример необходимости более правильной и более полной постановки задачи.
Как Тестовое задание для отбора кандидатов — лично я оцениваю, что постановка задачи не полная, следовательно и в дальнейшем будут проблемы в этой конторе с постановками задач для программистов.


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

Как Просто интересное времяпрепровождение для опытных разработчиков — есть задичи и более интересные.

Вы можете её расширять для большего интереса, как сказано выше в комментариях.
Вы это серьёзно? Серверный рендеринг только позволяет уменьшить скорость отображения первого экрана. Но вместе с html передаётся state приложения в том же JSON. Да и html генерируется кодом с клиентского приложения из этого же самого JSON-а. Как вы собираетесь строить state client приложения? Из html-а?

Да, и притом очень серьёзно. Потому что проверено практикой. Я передаю на клиента готовую строку html, которую просто вставляю .innerHTML = полученная_строка. Использую для связи сервера и клиента websoсket. Возможности wesocket позволяют избавиться от передачи в одном json кучи разной информации (потому как широко используемые ajax поддерживает только режим запрос-ответ). И если мне надо передать что-то кроме самого html, я отправляю клиенту новое сообщение. Как минимум это сокращение трафика. А далее это сокращение обработки клиентом полученных данных — как ни крути — принятый json надо обработать, выделить из него то что надо преобразовать в html и вставить в dom. Использование websocket позволяет сделанным выгодным передачу даже 1 байта — тот же state. Если же требуется передача нескольких значений — использование разделителя позволяет одной командой split сформировать массив и уже с этим массивом работать. Использование json — куча кода для достижения того же. Если есть обработки событий во вставленном «тексте» — использование делегирования решает такие задачи.
Тут есть ещё один факт ускорения системы — отсутствие от постоянного «бомбления» сервера запросами о появившихся данных — сервер сам это сделает при появлении таковых для клиента.
Как вы собираетесь строить state client приложения? Из html-а?
Если не достаточно полно описал выше — обращайтесь.
Задача чётко и полно поставлена. Это реальная бизнес задача из приложения с многолетним опытом. Всё что вам кажется нужно добавить исходит только из ваших предположений, а не опыта тысяч пользователей. Единственное что нужно из этого интерфейса — это id вариации, которое было опущено для простоты.
Я бы согласился, если б у меня не возникли вопросы и предложения. У меня есть приличный опыт в построении систем для работы операторов. Да задача поставлена реальная, но я ставлю себя на место оператора и клиента — и возникают вопросы. В далёкие 90 мне пришлось и программировать и работать на написанном. Мне сразу становилось видно все недостатки написанного интерфейса, а лень заставляла переписывать, чтоб добиться минимума действий, и уменьшения времени для работы с клиентом. Удалось достичь такого, что оператор мог во время приема заказа от клиента сформировать счет с учетом всевозможных вариантов, наличия товара, возможности будущих поставок и пр. и пр. и к концу телефонного разговора отправить готовый счёт по факсу.
А насколько в продакшене веб-сокеты устойчивы к timeout и прочим потерям связи? Какие-нибудь логи и аналитика ведется по этой части?

PS: Я тоже не всегда люблю json, особенно когда его использует везде, где надо и где не надо. Иногда, для ряда задач проще сформировать простейший массив атомарных данных в своем, кастомном формате. У нас такой (достаточно большой и трудоемкий фильтр) например так и реализован.
1. Есть такой stackoverflow.com, однажды они описали что и как у них работает. И для оповещения о изменении информации они используют websocke. У них есть статистика что некоторые websocket коннекты держатся год и более…
2. Есть один программист, который интересовался проверкой websocket коннектами — причина такого интереса оказалась в том, что фруктовый браузер не обрывал ws-коннект при переходе на другую страницу… (в отличии от всех нормальных браузеров). И ему пришлось использовать функцию ping-pong для определения подключён ли клиент.
3. У меня есть поделка на ардуино, которая считывает данные с датчика и отправляет на сервер по протоколу ws, сервер, так же по ws, формирует строку svg и отправляет клиенту, который отображает данные с датчика в виде бегущего графика. Темп примерно 10 измерений в секунду. Так вот если из этой поделки вытащить RJ45 на 10 сек — график останавливается, при подключении — график быстро движется какое-то время и дальше продолжает в нормальном темпе — без потери данных.
Мне кажется, что 1 и 2 пункты имеют что-то общее… по 3 — видимо передающий модуль имеет какой-то объём памяти и происходит накопление в нем если есть обрыв сети потом выплёвывает накопленное…
В моей практике проблем не случалось…
Для передачи набора данных — я их разделяю каким-нибудь не используемым символом — и потом с помощью split преобразую в массив.
А «не активность» окна в браузере разве не «убивает» вебсокет? PS: Фруктовый браузер — это сафари?
А «не активность» окна в браузере разве не «убивает» вебсокет?
не убивает. в хроме есть ключ настройки для того чтоб окно не «умирало» и если не ошибаюсь этот ключ стоит в «не убиваемом положении». по крайней мере у меня с этим проблем не возникало, а для проведения исследования с надкусанным фруктом — надо иметь этот фрукт… Как вариант — есть событие покидания страницы — можно по нему закрывать ws.
да, сафари.
Фаерфокс в моих тестах убивает (по дефолту). Это останавливает от использования на фронте. Событие покидания страницы — это понятно. Но тогда «из коробки» уже не очень получается использовать.
У меня если вкладка не активна — ни ff ни хром не прекращают работать на этой вкладке, настройки по умолчанию… Если идет переключение на другую страницу, даже одного сайта — ws и должно обрываться, на новой странице новое подключение. Это останавливает от использования?
а что обработка покидания страницы — это не из коропки?
Нет, речь не про переход на другую страницу. Именно, что переключение вкладок в браузере. Может там свою лепту вносит nginx, хотя соотв. директива по таймауту в нем прописана.
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 1200s;


надо попробовать без него и без https туннеля
Я могу открыть несколько вкладок и на каждой будет свой коннект ws, они друг другу не мешают. Могу даже открыть из одной страницы новое окно. Я использую apache. Https не должен влиять. Если у клиента стоит старый прокси, который не знает что такое ws, то он не пропускает ws, но такой проки wss пропускает без проблем.
У меня сделано так, что если клиент не активен, т.е. не взаимодействует с сервером, командой с сервера происходит переключение на страницу входа, сброс http сессии, закрытие ws сессии/коннекта.
Как вы обрабатываете ошибки в websocket-ах? Например нам нужно 20 разносторонних данных, 2-3 из них одинакового типа, но с разными id и один из них не пришёл, что-то сломалось или данных нет или запрос не верный?

Как вы описываете дерево, вложенность структур?

Если есть обработки событий во вставленном «тексте» — использование делегирования решает такие задачи.

Если у вас таблица с фильтрами и сортировкой + на каждый элемент есть чекбокс.
При изменении фильтрации или сортировки вы отправляете весь html с сервера? Это же как раз нагрузочные данные. Когда у нас есть template и в него вставляются только чистые данные из JSON — это уменьшает нагрузку на сеть.

После того как выбрано несколько чекбоксов и надо отправить запрос, вы будете проходить по DOM и искать какие элементы выделены?

JSON — это JS Object Notation (ваш кэп). Это представление объектов JS в читаемом виде. Это ни какой-то промежуточный слой, который преобразовывается во что-то другое. Получается вы создаёте свою структуру и пишите свой парсер?
Как вы обрабатываете ошибки в websocket-ах? Например нам нужно 20 разносторонних данных, 2-3 из них одинакового типа, но с разными id и один из них не пришёл, что-то сломалось или данных нет или запрос не верный?
честно говоря не совсем понял вопроса. Что подразумевается под ошибками? У вас есть сообщение, в котором могут присутствовать или не присутствовать какие-то данные? и необходимо это как-то обработать? чтоб понять что пришло а что нет? Если так — то в этом случае, действительно, лучше использовать json.
Как вы описываете дерево, вложенность структур?
Как ни странно, я обхожусь без таких навороченных структур, может быть потому, что просто пересылаю малыми частями. Тут надо смотреть конкретную задачу и её решение.
Если у вас таблица с фильтрами и сортировкой + на каждый элемент есть есть чекбокс.
При изменении фильтрации или сортировки вы отправляете весь html с сервера? Это же как раз нагрузочные данные. Когда у нас есть template и в него вставляются только чистые данные из JSON — это уменьшает нагрузку на сеть.
Я противник использования фильтрации и сортировки на клиенте. Потому что это подразумевает отправку клиенту всего набора данных. Я сторонник того что это всё делается на сервере, а клиент только отображает.
Я сторонник того чтоб клиент получал минимум данных — только те что можно взглядом оценить и обработать — эти данные получить применив все возможности базы. Как пример — есть выподающий список, позволяющий выбирать необходимую запись (к примеру наименование товара) — не гнать же на клиента все тысячи строк данных… Грамотные фильтры позволяют отправлять минимизированный набор данных.
После того как выбрано несколько чекбоксов и надо отправить запрос, вы будете проходить по DOM и искать какие элементы выделены?
Даже если это делать «в лоб» — это очень не сложно и не затратно, а если подойти грамотно — то вообще просто и дёшево.
JSON — это JS Object Notation (ваш кэп). Это представление объектов JS в читаемом виде. Это ни какой-то промежуточный слой, который преобразовывается во что-то другое. Получается вы создаёте свою структуру и пишите свой парсер?
Может это покажется странным, но стоимость ws позволяет избежать такой необходимости. Мне хватает того, что я могу использовать передаваемый набор данных с простым разделителем, и в качестве парсера простой split.
В общем чтобы конкретно обсуждать — надо конкретное задание, потому что практика показывает когда есть возможность дешёвой фулдуплексной связи решение задачи координально отличается от решения при использовании ajax, комет, лонгполинг
Если понадобится использовать на андроиде, тоже будет html гонять? Имеется в виду нативное приложение.
отображение данных на нативном приложении и браузере явно не соответствует по передаваемым данным как по структуре так и по формату. Поэтому нет смысла городить одно решение для всего. Если нужно будет для нативного приложения — можно и json, а можно и конкретно по месту вариант сделать… Ради призрачного "… если..." не смысла городить кучу лишнего.
Это задача не на пол часа, как кажется на первый взгляд.
Sign up to leave a comment.

Articles