Ловим баги в шерсти кода, обсуждаем нововведения, реквестируем новые плюшки. Шатания выходят на совершенно новый уровень, сумеет ли Курисаба-тян пережить всю мощь костыльной синергии Хомуры, Рейму и 1.5 анонов? Скоро узнаем. Предыдущий >>32736
>>48378 Из плюсов то что в RPC одна точка входа и не нужно ничего проектировать как в api. У тебя просто набор методов. Это особенно удобно когда методов много. Но все же мне кажется в данном случае для нескольких вьюшек rpc не нужно и даже оверхед.
А для оп-пика обязательно надо было брать порнографию?
>>48357 > Скоро узнаем Вот прошлым вечером и узнали :D
>>48294 >JSON RPC Ок, надо будет посмотреть, что это за зверь такой. >>48299 >[{op_post:POST, answers:234, pic_answers:48, posts:[POST, POST, POST]}, {op_post:POST, answers:458, pic_answers:124, posts:[POST, POST, POST]}] Да, это будет нормально. >Если они на сервере хранятся как отдельные поля, то лучше отдавать отдельно Да, как отдельные. Ок. Там даже размер тамбнейла зачем-то есть. Могу и его отдавать. >>48304 >разве для пхп стандарт не lowerCamelCase для методов? Насколько я видел, PHP — смесь всего: и CamelCase, и lowerCamelCase, и snake_case. >>48309 И? >>48319 >Просто думал, что ты уже знаешь. Не, к сожалению, не проверял. >Интересно, зачем это было? Вот у >>48321 написано. И суть именно в том, чтобы делать его не hidden, а прятать с помощью стиля: ибо первое — более тривиальная вещь и пасётся большим числом ботов, чем второе. >Так можно было в настройках выбрать, задействовать gd или imagemagick. Да. Только последнего на сервере нет. >сервер БУДЕТ пытаться загрузить изображение, даже если его размер превышает всякие рамки здравого смысла. Но разве он не выделит поначалу для него необходимую память (при попытке чего для гигантского изображения он закономерно обломится)? >Например, поставить такой код: Но, конечно, да; раз уж getimagesize() была вызвана, то можно и проверить, заметного оверхеда не будет. >Почему видя png, курисаба делает предпросмотр в png, хоть это и куда больше обычных предпросмотров, а видя gif — делает gif, хоть это и выглядит откровенно убого? Честно? Не знаю. Так было. =) Возможно, чтобы полагаться в превьюшке на imagetype. Ну и, наверное, для того, чтобы фоточки жать как фоточки, а рисунки — как рисунки, а не шакально. Хотя на превьюшке это будет малозаметно. >Пока друг не понял, что это «CATALOG». Да-да. Стоп, а я разве это не вычистил?! Вот же ж... >что делать с loadbalancer'ом, но, присмотревшись, понял, что он безнадёжно сломан. И, при надобности, чинить его и так уже нужно весь. Я, если честно, могу только по названию предположить, для чего он нужен. И не проще ли его выпилить... или всё же пусть остаётся, а если надо будет — починим? >Но, объективно говоря, я не буду тебя бранить, если ты это не закоммитишь в продакшн. Проверку размеров — закоммичу, выпиливание создания каталожных тамбнейлов — тоже, а вот про gif/jpg/png... Тут вот какое дело: большинство тамбов, которые есть — того же типа, что и файл; поэтому либо надо их все конвертать (а я на подобное как-то раз убил целую ночь), либо как-то различать, где тамб jpg-шный, а где — нет. >>48326 >Заинтересовало также поле «MAX_FILE_SIZE». Вроде как оно использовалось для проверок при загрузке файла, которые стали не нужны после реализации js-отправки. >>48331 >они успеют еще 10 API сделать и новый движок, пока я хоть что-то смогу запилить. Отчего-то проиграл. >>48333 >И вся универсальность накрывается, всё равно будут отличия. Так всё дело-то как раз в том, что в целом разметка остаётся той же — и даже тянет за собой исторические вещи. Как, например, тепбе класс .unkfunc для спойлеров? >Не проще ли обойтись гетом с передачей параметров через URL? Как правильно говорит Рейму (>>48335), в строке GET передать можно только что-то небольшое — например, id борды или там номер поста. Список постов, например, — уже нет. >>48334 Лол. А у меня сегодня показывало -4 соединения к базе. Какой-то просто день негатива (в буквальном смысле, от negative — «отрицательный»). P.S. Если вдруг найдёшь причину — сообщи, ладно? >>48335 >Да, Json применять как затычку в каждую дырку — действительно выглядит глуповато. А почему не его? Универсальный механизм представления данных в виде строки, хорошо поддерживается как клентом (javascript), так и сервером (PHP). >>48336 >Единственная причина так делать — быть не такими как все, вот и всё. А какими бывают все? Я просто не знаю. Может, есть и другой велосипед, кроме JSON. >апи никогда не разрастётся до такого, что запрос не влезет в адресную строку Почему же? К примеру, передача массива из 50-100 номеров постов. В 255 символов это точно не впихнуть. >GET значит получить. Я хочу получить список тредов, получить список постов, получить какой-то пост. ...Получить содержимое 50 постов, которые появились в треде с последнего обновления, например (без придумывания костылей типа запроса получить_последние_посты_треда_с_данным_ОП-постом_пришедшие_с_такого_то_момента()). Да, не очень логично, да, сбивает кэширование. Но лучшего способа я не вижу. Впрочем, конечно, можно сделать так, чтобы запрос на получение можно было отправить как GET-ом, так и POST-ом, если надо. >>48353 >то придется предварительно энкодить файл хотя бы в base64. А это уже 33% к весу файла. Так через форму же файл так же отправляется, если я не ошибаюсь. >>48378 >Забавно, я в новый тред с дашачана отписаться не могу. Мда, жесть какая-то. >Как освобожусь, постараюсь разобраться, в чём дело. Да, постарайся, пожалуйста. >>48387 >Но все же мне кажется в данном случае для нескольких вьюшек rpc не нужно и даже оверхед. Да, пожалуй, так оно и есть. >>48410 >А для оп-пика обязательно надо было брать порнографию? Да, что-то меня тоже ОП-Хомочка смущает. Да, кстати, гоменнасай за сегодняшние пропадания Курисача. Тут вообще какое-то адище было. Ваша Хомура вот сейчас только оклемалась от битв с ведьмами, захватившими хостинг Курисача, лол. Во-первых, накрыло базу на сервере (и она не вставала, похоже, даже после ребута), во-вторых, число соединений к базе отчего-то было отрицательным, и в-третьих — я решил в процессе поиска проблем переключить версию PHP на ту, которая более лучше (то есть, седьмую), из-за чего оно поругалось немного на конструкторы классов — пришлось в срочном порядке дописывать, ибо переключение обратно отчего-то ввело сервер в странную ситуацию, когда пятый и седьмой PHP переключались с интервалом в несколько секунд, лол. Алсо, похоже, я нашел механизм, через который нас пытались завалить — это был никакой не модный 0day в mysqld, а банальный SQL injection, который можно было устроить в форме поиска (причём, совершенно дурацким способом). К счастью, я успел это поправить быстрее, чем злодей подобрал нужное количество скобочек и кавычек для классического Robert'); DROP TABLE Students; --. =) И есть подозрение, что вложенными запросами SELECT SLEEP(5) он базу и положил. И ведь только вчера, судя по кэшу гугла, нас обсуждали на тирече (и как раз во время обсуждения клауда зарегистрировала ненормальный пик трафика и посещений). Сбэкаплю-ка я базу на всякий случай, а то вдруг что...
[{op_post:POST, answers:234, pic_answers:48, posts:[POST, POST, POST]}, {op_post:POST, answers:458, pic_answers:124, posts:[POST, POST, POST]}]
getimagesize()
.unkfunc
Robert'); DROP TABLE Students; --
SELECT SLEEP(5)
>>48420 Хранить размер превью важно т.к до загрузки превью браузер ничего не знает о ее размере и страница будет прыгать.
Оп пост в респонзе лучше не выделять, а поместить в посты(потому что внезапно это пост). Так будет удобнее всем. Генерировать превьюшки лучше в jpeg и разве что для png модно оставить т.к альфаканал выглядит красиво. Его по идее можно даже детектить. Если сейчас менять то придется либо в шаблоне ставить условие пересоздавать все превьюшки, либо писать в базу тип превью. Не, я понимаю что быдлокодеры пишут как угодно, но в 2016 игнорировать соглашения и общепринятые стандарты это плохо. Кстати ж надеюсь тут PDO используется?
>>48333 >POST в виде JSON? Хорошо ли это? Не проще ли обойтись гетом с передачей параметров через URL? «get_posts_by_id» может передавать достаточно много информации, так что оно не влезет в URL. Тем более ответ-то все равно нужен JSON. >>48335 >Да, Json применять как затычку в каждую дырку — действительно выглядит глуповато. А какие есть еще оптимальные варианты для мобильных приложений? >>48336 >Полагаю, апи никогда не разрастётся до такого, что запрос не влезет в адресную строку, даже близко такого не будет. «get_posts_by_id». Уже. >>48353 >это не API, а RPC Я, наверное, чего-то не понимаю, но разве RPC — это не один из стандартов для реализации API? Одно другого не исключает же? >но клиенту придется работать с двумя ресурсами Да в общем-то с одним и тем же курисачем, просто рид будет через /json.php, а пост через /boards.php >>48420 >Да, это будет нормально. Тут анон ниже предлагает оп-пост не выделять, а просто ставить первым в список постов. Думаю, он прав, потому что в запросе отдельного треда у меня оп-пост тоже не выделяется, будет унификация. [{answers:234, pic_answers:48, posts:[POST, POST, POST, POST]}, {answers:458, pic_answers:124, posts:[POST, POST, POST, POST]}] >Там даже размер тамбнейла зачем-то есть. Давай, как thumbheight и thumbwidth. Мне кажется, оно вряд ли понадобится, но все-таки. >Отчего-то проиграл. Нет, серьезно, торопится некуда. Можно начать с функции «get_boards», поскольку она самая простая, а заодно станут видны трудности на пути, да и для тестов мне на ближайшее время хватит более чем. >>48428 >Оп пост в респонзе лучше не выделять, а поместить в посты Разницы, на самом деле, для клиента особой нету. Вопрос как будет удобнее на сервере реализовывать.
[{answers:234, pic_answers:48, posts:[POST, POST, POST, POST]}, {answers:458, pic_answers:124, posts:[POST, POST, POST, POST]}]
>>48429 Они предоставляют некий интерфейс, но в RPC ты вызываешь методы через одну точку входа. А сервисы в нем могут могут быть вообще никак не связаны. Про ресурсы это я в смысле что тут будет рпц, а там форма. Не очень кошерно.
>>48428 >Не, я понимаю что быдлокодеры пишут как угодно, но в 2016 игнорировать соглашения и общепринятые стандарты это плохо. Когда речь касается движка 2007 года, в который напихали костылей по самую глотку, то о каких соглашениях может идти речь?
>>48440 Ты пишешь новый код, у которого общего со старым разве что БД. Логично бы начать писать правильно т.к это по сути новый проект(и я предлагаю так и сделать. Будет полезно почитать http://www.phptherightway.com/
>>48452 Я просто мимошел, если что. >у которого общего со старым разве что БД В таком случае да. Я говорил в конексте интеграции каких-то фич в сам движок.
>>48453 Я им уже много раз предлагал не насиловать труп и начать потихоньку переписывать важные компоненты. Или дорабатывать один из современных движков. Сами фичи да, хуево пилить что-то годное, когда основа херовая лапша с «собачками».
>>48420 > Так всё дело-то как раз в том, что в целом разметка остаётся той же — и даже тянет за собой исторические вещи. Вот с чего ты взял вообще? Какую-то совместимость могут сохранять, какую-то — нет. Нельзя быть в этом уверенным, у веб-разработчиков разные требования к совместимости, большинство, я думаю, просто забивает, и вполне справедливо: кукла работает — и хватит на этом. > Как, например, тепбе класс .unkfunc для спойлеров? Это частный пример, в общем-то, ничего не доказывающий. И не для спойлеров, а для цитат. Кстати, скорее всего это используется для универсальности стилей, а не для парсинга. > А почему не его? Универсальный механизм представления данных в виде строки, хорошо поддерживается как клентом (javascript), так и сервером (PHP). > А какими бывают все? Я просто не знаю. Может, есть и другой велосипед, кроме JSON. Универсальный механизм — это application/x-www-form-urlencoded или multipart/form-data, именно таким образом браузер кодирует формы. Через javascript можно передавать любые данные, включая JSON, но стоит 10 раз подумать перед этим. > Почему же? К примеру, передача массива из 50-100 номеров постов. В 255 символов это точно не впихнуть. Зачем ты будешь передавать массив из 50-100 номеров постов? Можно, конечно, сейчас навыдумывать кучу бессмысленных запросов, которые не будут влезать в адресную строку, но давай исходить из потребностей: где могут понадобиться такие длинные запросы? В крайнем случае, если очень нужно, — можно допустить работу как через GET, так и через POST. > ...Получить содержимое 50 постов, которые появились в треде с последнего обновления, например (без придумывания костылей типа запроса получить_последние_посты_треда_с_данным_ОП-постом_пришедшие_с_такого_то_момента()). А номера этих 50 постов ты откуда будешь узнавать? Будет запрос номеров постов в треде, сравнение с текущими, а затем вторым запросом получение нужных постов? Звучит дико. Кстати, то, о чём ты сказал, — не костыль. Так работают все борды, имеющие внизу страницы кнопку «Получить новые посты». Либо же грузят целый тред, но это совсем другая история. > Так через форму же файл так же отправляется, если я не ошибаюсь. Если используется multipart/form-data, то файл в чистом виде отправляется. А он используется. > Да, постарайся, пожалуйста. Я что-то вчера очень утомился, сегодня вечером посмотрю.
>>48357 Хомура окончательно увиабушил в закат.
Не знаю, писали уже или нет, но если открыть последние 50 постов в треде, а потом жмакнуть кнопочку «Получить новые посты», то магия работает как-то не так. >>48529 В смысле?
>>48430 >Не очень кошерно. Если все делать через JSON, то >>48353 >то придется предварительно энкодить файл хотя бы в base64. А это уже 33% к весу файла Это еще более некошерно. >>48519 >Через javascript можно передавать любые данные, включая JSON, но стоит 10 раз подумать перед этим. Какой такой javascript? Приложение мое будет на QML + Python, а модули дашчана или Микучана не знаю, на чем пишутся, но не на JS. >Будет запрос номеров постов в треде, сравнение с текущими, а затем вторым запросом получение нужных постов? Звучит дико. Почему же? Преимущества: 1) Маленькая нагрузка на сервер — отдавать список постов в треде или посты по id нагружает мало. В отличие от той ситуации, когда серверу приходится вычислять, а какие посты клиенту отдавать, а какие у него уже есть. Причем кэширование все равно сбито будет в любом случае, ибо у каждого клиента свои наборы требуемых им постов. 2) Удаленные посты — клиент будет видеть, какие посты удалены, по разнице всписках постов. Минусы: 1) При обновлении 2 запроса вместо одного — один за списком постов, и второй, чтобы получить новые посты.
>>48427 >Хранить размер превью важно т.к до загрузки превью браузер ничего не знает о ее размере и страница будет прыгать. Ок, ладно, тогда вопрос — надо ли его отдавать клиенту? >>48428 >Генерировать превьюшки лучше в jpeg и разве что для png модно оставить т.к альфаканал выглядит красиво. А в теории, в gif можно делать анимированные превьюшки (и такой реквест уже был). Так что, кажется, смысла делать превью исключительно в jpg нет. >Если сейчас менять то придется либо в шаблоне ставить условие пересоздавать все превьюшки, либо писать в базу тип превью. Ага, первое — долго, а второе — костыль. >Не, я понимаю что быдлокодеры пишут как угодно, но в 2016 игнорировать соглашения и общепринятые стандарты это плохо. Если ты можешь — напиши, в конце концов. Я вообще до начала копаний с курисабой с веб-разработкой был знаком весьма поверхностно. >Кстати ж надеюсь тут PDO используется? ADO. >>48429 >Тут анон ниже предлагает оп-пост не выделять, а просто ставить первым в список постов. Да, хорошо. >Давай, как thumbheight и thumbwidth. Мне кажется, оно вряд ли понадобится, но все-таки. Ладно, не жалко, пусть будет. >>48456 >Я им уже много раз предлагал не насиловать труп и начать потихоньку переписывать важные компоненты. А я много раз говорил: чтобы полноценно это сделать, времени лично у меня не хватает. Это надо брать, не знаю, отпуск на месяц, садиться и переписывать это всё. И то у меня именно опыта разработки под веб практически нет (считай, серьёзно я его начал как раз с курисабы). Вчерашняя инъекция в поле поиска тому подтверждение. Давайте поможем Хомуре переписать курисабу Если кто хочет, может написать свой движок, но главное — чтобы он поддерживал все используемые фичи курисабы и при этом позволял если не использование той же самой базы, то хотя бы несложную конвертацию формата базы туда и сюда. >>48519 >Какую-то совместимость могут сохранять, какую-то — нет. >кукла работает — и хватит на этом. Но ведь это уже значит, что базовая совместимость есть. А именно она нужна для клиентов. >Это частный пример, в общем-то, ничего не доказывающий. Правильно, это пример, как раз показывающий то, что большинство старается сохранять совместимость. >И не для спойлеров, а для цитат. Да, пардон. >Кстати, скорее всего это используется для универсальности стилей, а не для парсинга. Но ведь для универсальности же. >Универсальный механизм — это application/x-www-form-urlencoded или multipart/form-data, именно таким образом браузер кодирует формы. Его создание в javascript на порядок сложнее. Сможешь ли ты одной строчкой упаковать в один из этих форматов, к примеру, массив объектов, в том числе содержащих массивы? К примеру, страница доски как раз собой такое и представляет. Конечно, эта страница приходит с сервера, а не уходит на него, но я про то, что проще, когда и туда и сюда идут данные в одном и том же формате. >В крайнем случае, если очень нужно, — можно допустить работу как через GET, так и через POST. Ну я про это и говорю. Так и сделаю, и кто хочет — может работать через GET, кто хочет — через POST. >Будет запрос номеров постов в треде, сравнение с текущими, а затем вторым запросом получение нужных постов? Почему нет? >Кстати, то, о чём ты сказал, — не костыль. Так работают все борды, имеющие внизу страницы кнопку «Получить новые посты». Это просто один метод на совершенно конкретный случай и больше ни на какой. Т.е., никакой реюзабельности и расширяемости. Мне, всё же, больше нравится unix-way, когда есть куча простых инструментов, которые можно комбинировать и получать то, что тебе надо. >Если используется multipart/form-data, то файл в чистом виде отправляется. Хм, всю жизнь думал, что он там точно так же в base64. Ладно, мб я и неправ. >>48529 Нэ? Если что, перекат делал не я >>48613 Да, знаю. В процессе фикса. Кстати, выкачу сюда последние фиксы: — длинные скрипты в админке вызываются два раза (minor) (hard) — DELAYED (таких скриптов уже нет; а вообще проблема сервера, если решим переехать — починим) — есть проблемы с символами utf8mb4 (minor) (hard) — DELAYED (похоже, проблема сервера, если решим переехать — починим) — (NEW) превьюшки вембок генерить (minor) (hard) — DELAYED (проблема сервера, если решим переехать — починим) — (NEW) сделать https от клауды до Курисача (minor) (easy) — DELAYED (проблема сервера, если решим переехать — починим) — если нет куков, отдаются просроченные страницы (normal) (medium) — NEED INFO (теперь страницы генерятся динамикой; проверяйте, не починилось?) — при некоторых условиях пропадает трипкод и имя (minor) (medium) — NEED INFO (не могу воспроизвести; нужна инструкция по воспроизведению бага) — (NEW) превьюшки генерить только в формате jpg (minor) (medium) — NEED INFO (надо взвесить все «за» и «против») — (NEW) read.php сбивает обновление треда (тред перезагрузается и дописывается в конец) (major) (hard) — DONE — (NEW) кукла — request_uri обрезать по знаку вопроса (major) (easy) — DONE — (NEW) SQL-injection в форме поиска (major) (easy) — DONE — включенное автообновление жрёт очень много ресурсов (normal) (hard) — DONE (правда, оказалось, из-за переписывания innerHTML) — хайлайт сбивает автообновление (normal) (medium) — DONE (обновление переписано, теперь должно работать) — автообновление: счетчик тикает, но посты не обновляются (normal) (medium) — DONE (обновление переписано, теперь должно работать) — (NEW) после редактирования постов — два таймера одновременно (normal) (easy) — DONE — (NEW) при обновлении не альтерится карта ответов ОП-поста (normal) (easy) — DONE — (NEW) перейти на PHP 7 (normal) (easy) — DONE — оптимизация подгрузки постов (json) (minor) (hard) — DONE — сделать в шаблоне капчу только если на доске капча включена (minor) (easy) — CANCELLED (не стоит, а то мамкины вайпиры сразу набигают) — word-wrap не работает (minor) (easy) — DONE — кат не помещается в пост с картинкой правильно (minor) (easy) — DONE — (NEW) шрифты брать по https (minor) (easy) — DONE — (NEW) номер добавляемых постов при автообновлении промахивается на 1 (minor) (easy) — DONE — (NEW) «нет новых постов» — убрать при редактировании поста (minor) (easy) — DONE — (NEW) говорить, что в хроме кукла не обнаружена (minor) (easy) — DONE — (NEW) отключать фичи, несовместимые с куклой при первом детекте (minor) (easy) — DONE — (NEW) заголовок в поиске постов через read.php и read2.php (minor) (easy) — DONE — (NEW) в стиле tuvik, claire, cdark, claire.advance черный шрифт во фрейме (minor) (easy) — DONE — видео+картинка (major) (hard) — (NEW) проверка размеров заливаемых пикч (major) (easy) — сделать отправку по Ctrl+Enter настраиваемой (normal) (hard) — без капчи посты с куклы отправляются два раза (normal) (medium) — скрытие постов по имени, тексту поста (minor) (hard) — сделать переключение английского и русского интерфейса (minor) (hard) — (NEW) делать API для Суигинто (minor) (hard) — откуда-то лезет скроллбар и почему-то превьюшка вылезает за край (minor) (medium) — картинки, похоже, разворачиваются больше, чем надо (minor) (medium) — спойлеры картинок (minor) (medium) — cделать отдельно однопоток постов как на хорочане или как на хайбане (minor) (medium) — анимированные превьюшки, выключенные по дефолту (minor) (medium) — сделать улучшенный хеш для бана, чтобы он высчитывался без последних 2-5-10 байт (minor) (medium) — vimeo не отображает превьюшки видео (minor) (medium) — фрейм колбасит (см. пост 42066) (minor) (medium) — чтобы был и диалог открытия и превью по клику на зоне «перетащи файл сюда» (minor) (medium) — скрытие отдельных постов, навроде кнопочки скрытия треда, только для постов (minor) (medium) — сделать, чтобы предпросмотр закрывался при отведении мышки (minor) (medium) — разворачивание поста на предпросмотре со страницы борд (см. пост 46341) (minor) (medium) — (NEW) Из превьюшек удаляются карты ответов при автообновлении (minor) (medium) — (REOPENED) «https://kurisa.ch/sg» переводит на «http://kurisa.ch/sg/» (minor) (hard) — ускорить статистику в админке (minor) (easy) — предпросмотр поста не закрывать при клике по кату (minor) (easy) — предпросмотр поста при правке глючит (minor) (easy) — (NEW) Разворот поста и всплывание меняет номер на 1 (minor) (easy) — (NEW) автообновление косячит в режиме «последние 50 постов» и «первые 100 постов» (minor) (easy) — (NEW) шрифты захостить локально (minor) (easy) — (NEW) выпилить создание каталожных тамбнейлов (minor) (easy)
Микуоверчани н-не отправляет посты и пишет ошибку 301.
>>48635 Размеры не будут лишними, хотя зависит от типа клиента, но отдавать их определенно надо. Анимированные гифки на превью? Кто-то знает толк. Еще и вес соответствующий. Я б написал и уже пишу потихоньку, но дело в том что пишу на go. А это уже сразу минус хостинг, здравствуй вас. По поводу инъекции. Параметры не были забинжены? >>48646 Приду домой пофикшу, или скорее всего завтра.
>>48630 > Почему же? Потому что можно сделать один запрос в стиле «получить все посты, чей номер больше X», где X — номер последнего поста в треде. Получишь тот же результат, только на порядок проще. >>48635 > Но ведь это уже значит, что базовая совместимость есть. А именно она нужна для клиентов. Откуда ты знаешь, какая совместимость есть? Откуда ты знаешь, что совместимость — базовая, а не почти нулевая? > Правильно, это пример, как раз показывающий то, что большинство старается сохранять совместимость. Нет, он этого не показывает. На самом деле, он вообще ничего не показывает. > Его создание в javascript на порядок сложнее. Я тебе по секрету скажу, на чистом javascript всё достаточно сложно. А вот с jquery — в одну строчку. > в том числе содержащих массивы Опять же, давай конкретно, где такое нужно, а не высасывать из пальца. > когда и туда и сюда идут данные в одном и том же формате В общем-то нет. Веб так не работает. > Почему нет? Излишняя сложность ради сложности. > Это просто один метод на совершенно конкретный случай и больше ни на какой. Т.е., никакой реюзабельности и расширяемости. А больше случаев нет, некуда расширять. К тому же ты жертвуешь многим: 1. Нужно 2 запроса к серверу. 2. Более сложный запрос к бд. Не знаю, как сильно второе повлияет на производительность, но селект будет гораздо сложнее. Если раньше ты просто делал select ... where id > 1488, то теперь это будет where id in (1489, 1493, ...) Нашёл код дашачана для курисачика, буду разбираться с проблемой с капчей и минусами в избранном.
>>48674 > Нашёл код дашачана для курисачика, буду разбираться с проблемой с капчей и минусами в избранном. Я, кажется, понял в чём дело. Дело в запросе последних 50 постов в треде (который XXXXX+50.html), если постов меньше, пишет «Слишком мало постов в треде» с кодом 200. А раньше, когда были статические страницы, сервер отдавал 404 т.к. не находил такого файла. Надо сделать, чтобы 404 отдавал как и раньше. Или, как вариант, чтобы выдавал имеющиеся посты, даже если их меньше 50.
И ещё баг нашёл. Запросы вида https://kurisa.ch/read.php?b=sg&t=48357&p=48674&single отдают пост с номером [1]. Если с доски развернуть пост, то его номер заменяется на [1], что не очень красиво. Запрос можно не модифицировать, а вот скриптом сохранить и восстановить номер — можно. Но это мелочь уже, конечно.
А поиск теперь вообще не работает что ли?
>>48688 Что-то лол. И правда не работает. Изи способ избавиться от инъекций. Где-то я такое уже видел.
«Опаньки.» Вдруг обнаружил, что при некоторых обстоятельствах при предпросмотре с другого треда может отвалиться карта ответов. Пока причины неизвестны. Но баг неплохо воспроизводится, если «погулять» по переходам цитат на примере этого поста > >>43032 Если в нём навести на цитату (я испытывал на >>/sg/42824 ), от неё ещё цитату, (We need to go deeper!), а там уже беспорядочно открывать/закрывать вложенные «наводки по цитатам», пока не обнаруживаем, что все карты ответов на всплывающих постах отвалились. Не сильно мажорный баг, я бы сказал. Но, возможно, сможет что-то сказать о внутренностях клиента. Может, это даже поможет что-то решить. На самом деле не верю.
>>48635 >А в теории, в gif можно делать анимированные превьюшки (и такой реквест уже был). Пожалуйста, не надо. Нужно просмотреть гифку — в полном её формате, и по клику. Автовоспроизведение сделает калейдоскоп вместо страницы. А нужно текст читать. >Я вообще до начала копаний с курисабой с веб-разработкой был знаком весьма поверхностно. Ого, даже так. Молодец, что запилил столько всего. >Это надо брать, не знаю, отпуск на месяц, садиться и переписывать это всё. Сейчас будет звучать речь как саботаж, но: лучше распланируй отпуск на что-то здоровское. Такой вот короткий совет. Походы, встречи со старыми друзьями (если они друзья), поездка в горы/море. Курисач пилить нужно. Но и самому жить тоже. Твой темп разработки, мне кажется, и так очень высок. Да, «придём к коммунизму» так мы не совсем скоро. Но и сейчас уже довольно хорошо. >Так и сделаю, и кто хочет — может работать через GET, кто хочет — через POST. Сервером это делается в пару строк. Да и уже сколько лет подряд в PHP есть унифицированный «$_REQUEST». Мне кажется, тут даже думать не нужно. >перейти на PHP 7 А, так вот что это было. Сервер обновили.>>48674 >Я тебе по секрету скажу, на чистом javascript всё достаточно сложно. А вот с jquery — в одну строчку. А ты так же быстро и в одну строчку успел приравнять своё мнение к потолку подземелья. Ну как так. >В общем-то нет. Веб так не работает. И опять-снова. Да какая разница, как он работает обычно или у кого-то там? >Нужно 2 запроса к серверу. Это в первую очередь. Все адекватные люди стараются минимизировать количество установок соединений, т.к. это накладно. А особенно на https.>>48695 >Что-то лол. И правда не работает. А, так вот чего он мне 404 выдал. Я думал, он результат не нешёл.
>>48718 > Я думал, он результат не нешёл. Так он на любой запрос выдаёт, что ничего не найдено.
>>48711 На самом деле, да. Сталкивалась с таким багом уже не раз. Немножко раздражает
>>48718 > А ты так же быстро и в одну строчку успел приравнять своё мнение к потолку подземелья. Ну как так. Это не моё мнение. Обычный ajax на чистом javascript делается через xhr, да ещё данные кодировать надо вручную. А на jquery — $.post. > Да какая разница, как он работает обычно или у кого-то там? Вебу много лет, программированию — тем более. Если ты что-то делаешь не как обычно и как принято, скорее всего ты делаешь говно. Надо обосновывать выбор, а не делать как хочется. Даже если ты думаешь, что твой велосипед получится красивым, не факт, что это реально будет так. > Все адекватные люди стараются минимизировать количество установок соединений, т.к. это накладно. А особенно на https. 2 последовательных запроса, скорее всего, выполнятся на одном соединении.
>>48674 >можно сделать один запрос в стиле «получить все посты, чей номер больше X», где X — номер последнего поста в треде А как же удаленные посты? >Если раньше ты просто делал select ... where id > 1488, то теперь это будет where id in (1489, 1493, ...) Ну, во-первых, select ... where id > 1488 and op_post = 1137; ты забыл второе условие. А во-вторых, стоит проверить скорость выполнения и того и другого запроса, мне интересно, что быстрее.
>>48752 > А как же удаленные посты? Это не столь важная информация, я бы даже сказал наоборот, полезно, что посты не будут удаляться при автообновлении. Но если очень нужно — можно первым запросом получить посты после Х, а вторым запросом — все номера постов, после чего удалить на странице посты не из списка. Это гораздо лучше, чем отбирать номера постов. > ты забыл второе условие. Я хотел акцентировать внимание на совсем другое. Если уйти в строгости, то ты ещё и board == 'sg' and not deleted забыла а может что-то ещё, ведь движок сильно изменился, но дело-то не в этом. > А во-вторых, стоит проверить скорость выполнения и того и другого запроса, мне интересно, что быстрее. Пускай Хомура придёт, займётся, тоже интересно.
>>48751 >Обычный ajax на чистом javascript делается через xhr, да ещё данные кодировать надо вручную. А на jquery — $.post. formdata уже давно есть. Пользуйтесь им. А насчет jquery, уже много где она не нужна. На борде точно. >>48752 >А как же удаленные посты? В кусабе посты только помечаются как удаленные, аля deleted_at, можно их тоже запрашивать(хотя бы с пустой моделью). Суть ведь чтобы пометить их как удаленные, а не убрать из дерева. Да, потестил микучан из гита — работает. Просто соберите из репы или ждите релиза мику. Могу сделать билд если кому надо.
Хомура-чан, поиск теперь из принципа работать не будет?
>>48755 >полезно, что посты не будут удаляться при автообновлении А они и не будут — просто в клиенте помечать их как удаленные. Как куклоскрипт. >можно первым запросом получить посты после Х, а вторым запросом — все номера постов И чем же это лучше-то? Тут вообще получается два запроса. >board == 'sg' Неужели таблица одна на все доски? >>48802 >хотя бы с пустой моделью Извини, не поняла. Что за модель? >Суть ведь чтобы пометить их как удаленные Это уже вопрос клиентского приложения, что с ними делать. >>48806 Не волнуйся, у Хомуры и так много дел, когда освободится — починит. Не надо торопить.
На самом деле QML довольно годная штука, хоть я и ловлю с нее тонны боли, когда наступаю на грабли из-за непонимания. Нет, приложение не делает запрос, там пока вручную сделанная «заглушка».
>>48809 > И чем же это лучше-то? Тут вообще получается два запроса. В исходном варианте их тоже два. Причём запрос списка постов неоправданно сложный, в отличии от моего варианта.
>>48646 Ок, записал, спасибо, Ханако. >>48671 >Параметры не были забинжены? Ну я забыл обернуть запрос в $tc_db->qstr();. >Приду домой пофикшу, или скорее всего завтра. О, это было бы отлично. Хотя бы узнать причину. >>48674 >Получишь тот же результат, только на порядок проще. Но менее универсально. Что, например, если клиент захочет грузить тред не целиком, а только видимую часть? В любом случае, расширить потом можно. Главное — не закладывать сейчас нерасширяемые решения. >Откуда ты знаешь, какая совместимость есть? Откуда ты знаешь, что совместимость — базовая, а не почти нулевая? Если её достаточно, чтобы сторонный софт (кукла, мобильные клиенты) понимали пришедшие им данные — значит, она уже достаточная (в части чтения разметки, я имею в виду). >Нет, он этого не показывает. На самом деле, он вообще ничего не показывает. Ну, я не знаю, как на такое отвечать. Есть мнение, что мы просто не понимаем друг друга. >А вот с jquery — в одну строчку. Show me the magic! По запросу «jquery object to form data» нашел только про обратное преобразование. >Опять же, давай конкретно, где такое нужно, а не высасывать из пальца. Вот я просто тебе скажу такую вещь. Я часто на работе, когда делаю очередную материнку или модуль, стараюсь запилить на них побольше возможностей. Поставить все возможные разъёмы (которые не нужны на данном этапе — просто не покупать и не запаивать), вывести побольше тестпоинтов, сделать хороший запас по питанию, большие диапазоны регулировок, поставить управляемые по PMBus источники и всё такое. И уже не один раз получалось так: 1. Я запиливаю функционал в плату 2. Начальник говорит: чёт много всего, выпили %фичанейм% 3. Я говорю «угу» и не выпиливаю 4. Плата отправляется в производство, на неё делают КД, получают литеру, всё такое 5. Потом звонит другой начальник и говорит: «слушай, а %фичанейм% в твоей плате нет, да? Черт, придется заново разрабатывать похожую плату» 6. Я говорю: «кухихи, нет, есть, я её не выпилил» 7. Другой начальник говорит «о, круто!» и мы имеем новый комплекс с нужной функциональностью через 2 месяца, а не через полгода. 8. ????? 9. PROFIT!! Поэтому так: я тебе не скажу на 100%, где точно будет использоваться такой функционал; может, не будет вообще, а может, наоборот, пригодится. Придумывать примеры применения можно сколько угодно, и мы не угадаем, какой точно будет и будет ли вообще. Но отказываться от возможности запилить функционал, который может потребоваться, я не хочу. >В общем-то нет. Веб так не работает. Расшифруй, пожалуйста. Чем это плохо? > Почему нет? Излишняя сложность ради сложности. > Это просто один метод на совершенно конкретный случай и больше ни на какой. Т.е., никакой реюзабельности и расширяемости. >Нужно 2 запроса к серверу. Отлично, можно запилить два запроса. Настраиваемый (для двухзапросной схемы) и ненастраиваемый (для однозапросной). Проблем в этом нет. >Если раньше ты просто делал select ... where id > 1488, то теперь это будет where id in (1489, 1493, ...) Да, если есть индекс по id (а он есть), то запрос со сравнением выполнился бы быстрее. Однако, там всё равно есть условие IS_DELETED = 0, поэтому ему в любом случае придётся проходить все выбранные строчки. >Нашёл код дашачана для курисачика, буду разбираться с проблемой с капчей и минусами в избранном. О, спасибо, будет хорошо, если удастся накопать причину. >>48678 >Надо сделать, чтобы 404 отдавал как и раньше. Или, как вариант, чтобы выдавал имеющиеся посты, даже если их меньше 50. Хорошо. Как будет лучше? >>48679 Уже есть в списке. Буду править. >>48688 >>48695 >>48806 >>48718 >>48720 >>48806 Упс! Да, чёт поиск сломался. Скоро поправлю, а пока просто оборачивайте то, что ищете, в значки процента, т.е. теперь вместо слово надо писать %слово%. >>48711 Тоже есть в списке, и я даже примерно знаю, из-за чего это. Тоже буду править. >>48718 >Автовоспроизведение сделает калейдоскоп вместо страницы. Да, ты прав, и я тоже так считаю, поэтому у меня специально написано: «выключенные по дефолту». >лучше распланируй отпуск на что-то здоровское. Ну само собой, говоря, что «надо так делать», я не подразумевал, что я действительно так буду делать, кухихи. В отпуске я лучше школьников электронике поучу в ЛМШ и просто отлично проведу с ними время, лол, чем буду сидеть переписывать курисабу простите меня, дорогие курисачане же. =) Но спасибо за заботу, Рейму. =) >Сервером это делается в пару строк. Да и уже сколько лет подряд в PHP есть унифицированный «$_REQUEST». Вот и я о том же. Ладно бы это было сложно, но ведь есть уже предназначенный именно для этого метод. >Все адекватные люди стараются минимизировать количество установок соединений, т.к. это накладно. А особенно на https. Ну тут два запроса — рациональная, имхо, цена гибкости. Можно сделать и однозапросную схему — не проблема же. >>48751 >да ещё данные кодировать надо вручную. Разве в FormData надо что-то кодировать? >Если ты что-то делаешь не как обычно и как принято, скорее всего ты делаешь говно. Пример: много ли ресурсов используют PUT и DELETE для добавления или удаления чего-нибудь — вместо типичного «POST на любую модификацию»? >Надо обосновывать выбор, а не делать как хочется. Я ж, вроде, обосновал. >>48755 >полезно, что посты не будут удаляться при автообновлении. Не называние ли это бага фичей? >Но если очень нужно — можно первым запросом получить посты после Х, а вторым запросом — все номера постов, после чего удалить на странице посты не из списка. Это гораздо лучше, чем отбирать номера постов. Всё равно два запроса, но такой вариант гораздо костыльнее. И всё ради чего? Чтобы не юзать POST? >Пускай Хомура придёт, займётся, тоже интересно. На нашем объёме данных оба запроса будут выполняться исчезающе малое количество времени. >>48809 >Неужели таблица одна на все доски? Конечно, одна, ибо одна структура данных. >>48814 >Причём запрос списка постов неоправданно сложный Как раз-таки нет. Ты перекладываешь сложность на клиент, хотя «выдать посты по списку» — вполне логичная серверная задача, в отличие от костыльного клиентского аналога «запросить всё, а потом вычленять оттуда то, что нужно».
$tc_db->qstr();
IS_DELETED = 0
слово
%слово%
Хомушка, Вам нинадоело бырократией занимацца? Тем более, што это лжа фсё, ага. Сколько небыло просьб в этой канцелярии, а картинку с видевой так и ничиво же, например.
Картинка с видевой не нужна. Пост будет выглядеть коряво. Я категорически против.
>>48818 Да. Нужна возможность прикрепления 5 картинок и видео. Будет в самый раз.
>>48818 Ссылка с раскрыть прям в посте даж, как, например у Юлички и на Двощах? Штож корявого-то, глупый?
>>48821 Завались, жирный.
>>48824 Я серьёзно. Одной пикчи мало.
>>48815 > Но менее универсально. Что, например, если клиент захочет грузить тред не целиком, а только видимую часть? Какую такую видимую часть? > В любом случае, расширить потом можно. Главное — не закладывать сейчас нерасширяемые решения. Можно просто потом добавить запрос на получение нужных постов параллельно к запросу на получение после определённого номера, хуже не станет. И, я уверен, это «потом» уже никогда не наступит или просто нигде не понадобится. > Если её достаточно, чтобы сторонный софт (кукла, мобильные клиенты) понимали пришедшие им данные — значит, она уже достаточная (в части чтения разметки, я имею в виду). Когда вы только ввели отображение номеров постов (в квадратных скобках), вы прописали ему класс postername. Дашачан из-за этого вместо имён постов показывал эти самые числа. Я тогда сообщил об этом разработчику, чтобы он исправил, но, тем не менее, такая небольшая оплошность — и уже что-то перестаёт работать как надо. Или, если помнишь, была проблема, когда ты ввёл новую карту ответов и вынес её в текст поста. Я тогда громко ругался и просил убрать их наружу, иначе эти ответы отображались как текст сообщения. Достаточная совместимость — миф: никогда не угадаешь, где можно накосячить. Не верю я в твои универсальные парсеры для каждого движка. > Ну, я не знаю, как на такое отвечать. Не обязательно отвечать. Во-первых, твой пример сохраняет совместимость для стилей, а не для парсеров, а во-вторых это единичный случай. Нужно доказательство всеобщности, а не существования, понимаешь? > Show me the magic! $.post. Передёшь в него JS объект — он сам из него формирует данные. > Но отказываться от возможности запилить функционал, который может потребоваться, я не хочу. Ради этого ты собираешься вводить свои велосипеды вопреки здравому смыслу. Можешь пофантазировать ещё дальше и тебе уже JSON не будет хватать. За всю жизнь до этого я не встречал сайтов, которые передают массив в массиве и которым вообще такое необходимо. Не надо совсем уж ерунды придумывать. > Расшифруй, пожалуйста. Чем это плохо? В вебе ты делаешь запрос, даже не обязательно пост, а в ответ ты можешь получить текст, картинку, аудио, видео, и т.д. Нет никакой необходимости формат входных и выходных данных делать идентичным, это абсолютно лишнее. > Отлично, можно запилить два запроса. Настраиваемый (для двухзапросной схемы) и ненастраиваемый (для однозапросной). Проблем в этом нет. Проблема в том, что ты плодишь сущности. Даже в двухзапросной системе нет необходимости в настраиваемом запросе. > Хорошо. Как будет лучше? Если сделать как раньше (404), то точно всё будет работать. Если же отдавать посты всегда, то я уже не уверен. Лучше всё таки первый вариант. > Разве в FormData надо что-то кодировать? Любой пост-запрос с содержимым надо во что-то кодировать. Ты строку в send передаёшь, а эту строку надо сформировать так или иначе. > Пример: много ли ресурсов используют PUT и DELETE для добавления или удаления чего-нибудь — вместо типичного «POST на любую модификацию»? Много. Не понимаю, к чему это. > Всё равно два запроса, но такой вариант гораздо костыльнее. И всё ради чего? Чтобы не юзать POST? Моя схема: 1. Запросить все номера постов. 2. Убрать удалённые посты. 3. Запросить новые посты после последнего поста. Твоя схема: 1. Запросить все номера постов. 2. Убрать удалённые посты. 3. Запросить все посты, которых нет на странице и есть в списке постов из первого запроса. Тебе как на клиенте, так и на сервере придётся выполнить больше разных вычислений. Надо как сформировать массив номеров новых постов, так и SQL-запрос с этим самым where id in (...). В моём же случае вообще ничего делать не надо. И ты ещё мой вариант костылём называешь? > Я ж, вроде, обосновал. «Может быть понадобится» — не обоснование.
>>48815 >И уже не один раз получалось так Ну и дела. Это же хардварь, и за каждую фичу нужно платить покупкой деталей. (Или ты оставляешь площадки?) Кстати, тут же вопрос: SPI может потянуть 10Мбит/сек на коротких дистанциях? >Ну тут два запроса — рациональная, имхо, цена гибкости. Можно сделать и однозапросную схему — не проблема же. Ну можно записывать историю последних изменений. Автообновление, всё же, штука активная. Да и работаем уже с динамикой-динамикой. >Пример: много ли ресурсов используют PUT и DELETE для добавления или удаления чего-нибудь — вместо типичного «POST на любую модификацию»? Да уж, ну и пример. Я бы не стал полагаться на них уже не только из сомнений в поддержке клиентами, так даже из сомнений поддержки сервером. Эта модель просто умерла в какое-то время. >Не называние ли это бага фичей? Нет, Хомура. Если бы я писал клиент, обязательно бы оставлял удалённые посты. Потому, что клиент уже по праву получил эту информацию. А потом по команде сервера должен удалять то, что пользователь желал бы прочесть. Неправильно это. Ладно ещё, если сервер просто не прислал. Тогда и говорить нечего. Но вот так действовать.. это уже неправильный клиент получается.
>>48832 >Какую такую видимую часть? Предположу, что имелась ввиду загрузка только малой части треда с последующей автоподгрузкой при надобности. >Достаточная совместимость — миф: никогда не угадаешь, где можно накосячить. Да, это очень глупо, когда каждый для себя определил границы API. Было бы куда лучше, если бы все цеплялись за одни и те же ключевые части. Но и не так много проектов работает с курисабой. Вот конкретно их функционирование и нужно поддерживать. >Ради этого ты собираешься вводить свои велосипеды вопреки здравому смыслу. Какие велосипеды? Что ты несёшь? Мы вообще-то новый движок пилим. >За всю жизнь до этого я не встречал сайтов, которые передают массив в массиве и которым вообще такое необходимо. Это да. >1. Запросить все номера постов. 2. Убрать удалённые посты. 3. Запросить новые посты после последнего поста. Твоя схема: 1. Запросить все номера постов. 2. Убрать удалённые посты. 3. Запросить все посты, которых нет на странице и есть в списке постов из первого запроса. А я вообще сижу и не понимаю, почему бы серверу не вести историю. Так он бы сам мог ответить на вопрос, что нужно клиенту. Там эту историю-то на больше 5 изменений за раз едва ли когда потребуется читать. Обновления же каждые 20 сек. Зато пересылаются все номера постов. Кстати, твой вариант был предыдущим. Мы так хорошо полетели на удалённых постах. Ну хорошо, тогда нужно было реализовать всё аккуратней, и на этом всё. Сейчас же на каждое обновление пересылается данных массив, что даже GET не поместится. Да и, объективно говоря, карта ответов из других тредов под вопросом. С историей последних изменений треда полегче будет ничего не упустить.
>>48817 У меня все ходы записаны, будет тебе картинка с видевой, это наступит скоро, надо только подождать. =) Ладно, постараюсь сделать побыстрей, а то негоже столько времени держать реквест в major-е. >>48818 Для тебя ничего не изменится — если ты, конечно, не залезешь в настройки и не поставишь галочку типа «разворачивать первое видео с ютуба в посте». >>48828 Чому бы не писать несколько постов, или не прикреплять пикчи ссылками? Если каждый будет лепить по десятку пикч к посту — то мы так очень быстро вылетим за наши 15 гигов. >>48832 >Какую такую видимую часть? Например, маленький экранчик, на нем видно, к примеру, три поста. Скроллишь пальцем вверх-вниз — подгружаются другие. >Можно просто потом добавить запрос на получение нужных постов параллельно к запросу на получение после определённого номера, хуже не станет. А я о чём говорю? Два варианта запросов, главное — есть и «быстрый», и «универсальный». >И, я уверен, это «потом» уже никогда не наступит или просто нигде не понадобится. Это невозможно гарантировать (как и обратное). >такая небольшая оплошность — и уже что-то перестаёт работать как надо. Само собой, для каждой борды нужны свои правки — и чем борда дальше от кусабы, тем больше. Но основа всё равно остаётся одна, и парсеры отличаются лишь немного, условно говоря, это не разные парсеры, а один и тот же с небольшой кастомизацией под конкретную борду. К примеру, никто не додумывался, например, посты лепить в, например, голый blockquote вместо td, или систему адресации постов типа '#reply12345' заменять на нечто своё, или стили перелопачивать до неузнаваемости. >Нужно доказательство всеобщности, а не существования, понимаешь? Теперь понимаю. Возможно, я слишком категорично сказал, но я говорил о тенденции, а не о непреложном правиле. >$.post. Передёшь в него JS объект — он сам из него формирует данные. Спасибо, буду знать. >Ради этого ты собираешься вводить свои велосипеды вопреки здравому смыслу. Да где же тут вопреки здравому смыслу-то? Вон, для обновления треда мне, к примеру, уже требуется передавать список постов (впрочем, я всё обновление делаю одним запросом). >Нет никакой необходимости формат входных и выходных данных делать идентичным, это абсолютно лишнее. Ну, необходимости — конечно же, нет. А когда входные и выходные данные представляют собой объекты — то почему бы их и туда, и сюда не передавать в одном формате? >Проблема в том, что ты плодишь сущности. Как раз-таки, без упрощенной схемы сущность (операция) одна: получить перечисленные посты. Понимаешь, не сервер должен думать, что с этим делать, это задача клиента. Серверу сказали «дай мне эти посты» — он дал. Упрощённая схема здесь исключительно для облегчения этой операции в наиболее часто используемом случае (получение новых постов). >Если сделать как раньше (404), то точно всё будет работать. Ок, сделаю тогда так. >Любой пост-запрос с содержимым надо во что-то кодировать. Погоди, а разве это делается не прозрачно для пользователя через FormData::append()? >Много. Не понимаю, к чему это. Я, если честно, ни разу не видел в выводе wireshark-а PUT или DELETE. Исключительно GET и POST. Это к тому, что не всё «в вебе» используется так, как задумано. >И ты ещё мой вариант костылём называешь? Ещё раз говорю: твой вариант предназначен для абсолютно конкретного случая (обновление треда) и более ни для какого. Естественно, именно в этом случае он работает лучше (а в других — не работает вообще). И я не говорю, что он не нужен, просто его наличие не отменяет наличия универсального интерфейса. >«Может быть понадобится» — не обоснование. Тем не менее, оно часто работает. >>48833 >Это же хардварь, и за каждую фичу нужно платить покупкой деталей. (Или ты оставляешь площадки?) Ну, если туда ставится редкая микросхема/соединитель — то да, помечаю их в схеме как незапаиваемые, а в спецификации и перечне элементов как «наличие определяется договором поставки, если не оговорено особо — отсутствует». Но в общем и целом над мыслью поставить лишний разъём-гребёнку со стоимостью в 10 рублей, резисторы со стоимостью меньше рубля штука или там микросхему стоимостью рублей в 20-50 (I2C EEPROM, например) даже задумываться не стоит — на фоне общей стоимости модуля в сотни тысяч рублей это копейки, а профит (хотя бы если его пересчитать в оплату человеко-часов) значительный. >Кстати, тут же вопрос: SPI может потянуть 10Мбит/сек на коротких дистанциях? Да, на 12 МГц мы его пускали. >Эта модель просто умерла в какое-то время. Вот и я о том же. Не всё «в вебе» сделано идеально, есть рудименты, есть просто неудобные или непродуманные вещи. >А потом по команде сервера должен удалять то, что пользователь желал бы прочесть. Я тебя понимаю, да (и сам раньше так думал). Но в целом, вот лично здесь — я старался привести ситуацию к тому, чтобы тред после обновления выглядел так же, как будто страницу целиком перезагрузили. Классическая ситуация: человек отправил пост, увидел в нем ошибку и переотправил его. Итог: если не удалять, то у читающего будут два поста: старый и новый. Некрасиво как-то, как по мне. В конце концов, если человек не хочет, чтобы у него удалялись (как и добавлялись) посты, он просто не будет обновлять тред, верно? >>48834 >Предположу, что имелась ввиду загрузка только малой части треда с последующей автоподгрузкой при надобности. Да. >Мы вообще-то новый движок пилим. Пока что только API. Хотя, если кто-то уже активно пилит движок, то я буду всячески благодарен такому герою =) >А я вообще сижу и не понимаю, почему бы серверу не вести историю. Это сложно (к примеру, я не представляю, как сервер будет отслеживать хотя бы тысячу одновременно подключенных клиентов) и очень чревато рассинхроном.
FormData::append()
>>48814 >Причём запрос списка постов неоправданно сложный, в отличии от моего варианта. Чем же сложен запрос списка по id? Простейший запрос, учитывая что id индексируется и уникально, то время выполнения линейно. >>48832 >Тебе как на клиенте, так и на сервере придётся выполнить больше разных вычислений. Сервер в этом случае ВООБЩЕ практически никаких вычислений не выполняет — он выполняет два запроса, в одном отдает id постов из треда, во-втором посты по id. А вот в твоем случае база вынуждена пробегать все посты после того, который ты отправишь как последний в треде, и смотреть, в каком треде эти посты находятся. >>48834 >почему бы серверу не вести историю. Для каждого клиента? А каждому клиенту история для каждого треда? Да ддосер с большим набором прокси все тут ушатает. >Обновления же каждые 20 сек. У меня автообновления отключены — уже не каждые 20 сек. >>48846 >Хотя, если кто-то уже активно пилит движок, Какой-то анон отписывался в прошлом треде, что пилит.
>>48846 >Это сложно и очень чревато рассинхроном. Разумеется, это нужно реализовывать отдельно. Но создать таблицу, и вписывать туда «тред 1234: в посте 2345 добавлен ответ в карту, время 101; тред 9999: добавлен пост 10000, время 102; тред 9999: добавлен пост 10001, время 103» Пользователь при надобности отсылает номер треда и время. Сервер уже отправляет (проверив на дубликаты, разве что. Ну или тупо отправив несколько раз одно и то же, всяко случай редкий). Можно ещё дополнять вида не помечать «карта ответов» или «пост», а сделать колонку «тип» и сразу дописывать в карту ответов только 1 добавление или 1 удаление. (хотя это уже похоже на мелочи. Хотя и сэкономим ещё чуть больше) Если сервер ответить не может (сообщение слишком давнее), то можно и обновить клиенту весь тред. Т.к. это уже не 20 секунд, и даже не час прошёл. >к примеру, я не представляю, как сервер будет отслеживать хотя бы тысячу одновременно подключенных клиентов. Эти же способом. Не серверу же следить за тем, на каком моменте какой клиент остановился, а клиенту.
>>48851 >Чем же сложен запрос списка по id? Простейший запрос, учитывая что id индексируется и уникально, то время выполнения линейно. Очень условно линейно, основная нагрузка тут О(1). Но вот только что делать, если изменение произошло? Кидать второй запрос, или загружать тред целиком? Более того, так уже происходило сравнение внутри клиента ещё во времена статики. Приводило это к тому, что удалёние постов не фиксировалось. Сразу подскажу, что нужно передавать последний id И количество постов. Учитывая, что добавить пост внутрь других нельзя, то этих данных уже будет достаточно. Но второй запрос при изменении делать нужно. Или весь тред пересылать. Что первое, что второе не так уж здорово.
>>48856 >Но вот только что делать, если изменение произошло? >Кидать второй запрос, или загружать тред целиком? Какой такой второй запрос? Запрос постов по id это и есть ВТОРОЙ запрос. Первый — это запрос всех постов в треде, причем благодаря этому фиксируются удаление. А потом клиент запрашивает только то, чего у него нет.
>>48857 >это запрос всех постов в треде запрос всех НОМЕРОВ постов Фикс.
>>48834> Предположу, что имелась ввиду загрузка только малой части треда с последующей автоподгрузкой при надобности.Последние посты только в голову приходят, а как это сделать — я уже говорил.> Какие велосипеды? Что ты несёшь?Я о JSON в теле запроса вместо привычных способов кодирования.> Кстати, твой вариант был предыдущим. Мы так хорошо полетели на удалённых постах.Если дополнительно запрашивать список постов, то не полетит. Этого нет в предыдущем варианте.> С историей последних изменений треда полегче будет ничего не упустить.Я, кажется, представляю, о чём ты говоришь. Идея прикольная, но я бы забил и просто весь тред грузил чтобы уж точно всё предусмотреть. Больно много возни будет.>>48846> Например, маленький экранчик, на нем видно, к примеру, три поста. Скроллишь пальцем вверх-вниз — подгружаются другие.Вообще не востребованно. Маленький экранчик будет просто грузить все посты. Если бы это было востребованно, давно бы это сделали, но ты первый это придумал.> Это невозможно гарантировать (как и обратное).Учитывая то, что никому кроме тебя такие запросы не нужны, вполне можно.> Ну, необходимости — конечно же, нет. А когда входные и выходные данные представляют собой объекты — то почему бы их и туда, и сюда не передавать в одном формате?Потому что это велосипед и так почти никто не делает. Если нет необходимости — лучше не усложнять, только проще будет.> Как раз-таки, без упрощенной схемы сущность (операция) одна: получить перечисленные посты. Понимаешь, не сервер должен думать, что с этим делать, это задача клиента.А почему не сервер? Ты так за это цепляешься, но у нас конкретная прикладная задача, сервер думает в рамках задачи. И если необходимости получать конкретные посты нет, а её нет, то не надо ничего усложнять.> Погоди, а разве это делается не прозрачно для пользователя через FormData::append()?Я не знаю, что это такое, но в любом случае ты это делаешь.> Это к тому, что не всё «в вебе» используется так, как задумано.Речь не о как задумано, а о как принято. Оказалось, что использовать только гет и пост — удобно.>>48851> Чем же сложен запрос списка по id? Простейший запрос, учитывая что id индексируется и уникально, то время выполнения линейно.Вот >>48832> > Тебе как на клиенте, так и на сервере придётся выполнить больше разных вычислений. Надо как сформировать массив номеров новых постов, так и SQL-запрос с этим самым where id in (...). В моём же случае вообще ничего делать не надо.> Сервер в этом случае ВООБЩЕ практически никаких вычислений не выполняет — он выполняет два запроса, в одном отдает id постов из треда, во-втором посты по id. А вот в твоем случае база вынуждена пробегать все посты после того, который ты отправишь как последний в треде, и смотреть, в каком треде эти посты находятся.Запрос при этом получается проще и, благодаря своей простоте, скорее всего быстрее. В твоём случае база должна побегать все посты и проверять их номер?
>>48863 >Надо как сформировать массив номеров новых постов, так и SQL-запрос с этим самым where id in (...) Массив формирует клиент, а в sql запрос просто передается этот полученный от клиента массив. >В твоём случае база должна побегать все посты и проверять их номер? С чего бы? У нас же индексация по id. >Запрос при этом получается проще Спорим нет? Возьмем крайний случай — предпоследний тред на последней странице и запустим там (виртуально) мой и твой вариант автообновления. Твой вариант — сначала запрос всех номеров постов в треде для проверку на удаленные, потом второй запрос с передачей id 10577 последнего поста — и база должна пробежать 48939-10577 постов чтобы убедится, что среди них нет нового поста в этом треде. Мой вариант — клиент запрашивает список всех постов, сверяет с имеющимся, убеждается, что там нет ничего нового и второй запрос не делает.
>>48940> Массив формирует клиент, а в sql запрос просто передается этот полученный от клиента массив.Из массива нужно сформировать сам селект. Массив сам себя не экранирует и в запрос не вставит.> С чего бы? У нас же индексация по id.Я не знаю, как устроены бд со всеми этими индексациями, но даже Хомура говорит, что скорость одинако мала. Тем более, можно, наверное, индексировать по нескольким столбцами?> Спорим нет? Возьмем крайний случайНастолько крайний, что выполнив такую проверку на клиенте даже в моём случае не придётся делать второй запрос.Но я больше стремлюсь к минимализации работы программисту, нежели компьютеру, тем более если нагрузка почти никакая. Как минимум в этом смысле — да, проще.
>>48854 >Но создать таблицу, и вписывать туда «тред 1234: в посте 2345 добавлен ответ в карту, время 101; тред 9999: добавлен пост 10000, время 102; тред 9999: добавлен пост 10001, время 103» Такое изобретение называется «система контроля версий». Для движка борды это, думаю, оверкилл, но теоретически такая схема возможна. Однако это уже совсем другой порядок размера базы и сложности извлечения из неё инфы. И уж тем более всего лишь ради сокращения сложности клиента, мне кажется, это не очень имеет смысл. Учитывая то, что вычислительная мощность сервера постоянна, а клиентов — растёт с их количеством. >>48856 >Но вот только что делать, если изменение произошло? Кстати, заметь: при автообновлении очень мал счётчик «попаданий» на событие «страница изменилась». >>48856 >>48857 Btw, уже сейчас давно как можно пользоваться json.update.php — в ответ на запрос из списка имеющихся у клиента постов прилетит и список удалённых постов, и html добавленных, и новая карта ответов треда. Это специально для тех, кто желает максимум вместить в один запрос. >>48863 >Я о JSON в теле запроса вместо привычных способов кодирования. Если $.post() имеет подобную функциональность, то я не против. Главное, чтобы при этом на сервере можно было бы легко разобрать то, что он сделал. >давно бы это сделали В мире, где под андроид две читалки для борд, а для IOS — вообще ноль. Угу. >Учитывая то, что никому кроме тебя такие запросы не нужны, вполне можно. Гинто ещё нужны. >но у нас конкретная прикладная задача, сервер думает в рамках задачи. Нет. Запрос к API — это не задача, это инструмент. Одним инструментом можно решать множество задач — важно уметь этим инструментом пользоваться. Например, вот у меня на кухне есть куча разных ножей — для хлеба, яблок, мяса, рыбы от прошлой хозяйки осталось, но когда я решаю, что взять с собой в поход — я беру один универсальный нож, потому что я знаю, что с его помощью я могу решить любую задачу, которую можно решить с помощью ножа. Правда, я до сих пор не могу понять, чем отличаются эти ножи, какой из них какой, и самое главное — какова разница в результате, лол. Так же и с запросом: если я даю возможность передавать параметры как через GET, так и через POST — то с помощью подобной абстракции можно решить даже те задачи, исходные данные для которых не вмещаются в 255 символов. >то не надо ничего усложнять. Писать $_REQUEST вместо $_GET — это усложнять? >Речь не о как задумано, а о как принято. И как же принято? В общем случае да, немодифицирующие запросы к серверу делаются с помощью GET. Но это не железное правило, а так «принято» просто потому, что во многих случаях так проще, когда не нужна функциональность POST. Но когда она нужна — она используется. Тот же контактик сыплет POST-ами при простом скролле ленты или сообщений — просто мама не горюй. >В моём же случае вообще ничего делать не надо. В какой раз уже говорю: если тебе достаточно «простой» функциональности — то и не делай. Я согласен, твоя задача распространена — поэтому я сделаю «упрощённый» вариант для неё. К чему же выпиливать более универсальную функциональность, нужную другим? >>48943 >Из массива нужно сформировать сам селект. Массив сам себя не экранирует и в запрос не вставит. Если не ошибаюсь, это делается автоматизированно (где-то в дебрях read.php надо глянуть). >Хомура говорит, что скорость одинако мала. Что время, затрачиваемое на выполнение запроса одинаково мало.
json.update.php
$.post()
>>48957> Гинто ещё нужны.Ну, на самом деле тоже окажется, что не нужны.> Одним инструментом можно решать множество задач — важно уметь этим инструментом пользоваться.Инструмент для задачи. А задачи таковы, что слишком универсальный инструмент не нужен.> но когда я решаю, что взять с собой в поход — я беру один универсальный нож, потому что я знаю, что с его помощью я могу решить любую задачу, которую можно решить с помощью ножа.У нас тут не поход, а одна лишь резка хлеба. И вот для неё ты решил взять универсальный нож.> Писать $_REQUEST вместо $_GET — это усложнять?Формировать сложный запрос вместо элегантного ии покрывающего все задачи сравнения.> И как же принято?> > application/x-www-form-urlencoded или multipart/form-data> Но когда она нужна — она используется.Вот когда нужна. Прямо очень нужна. Так нужна, что кушать не могу. Велосипедить весело только тому, кто пишет эти велосипеды, да и то во время обучения.> К чему же выпиливать более универсальную функциональность, нужную другим?Я пытаюсь объяснить, что универсальная функциональность тут в принципе не нужна. И даже не выпиливать: апи-то нет, нельзя выпилить то, чего ты ещё не сделал.Ты ни с того ни с сего взялся за абсолютно бесполезную сущность и даже не знаешь, зачем она нужна, мол, зато универсально. Сделай частный упрощённый запрос, а потом, когда время придёт, — общий, если понадобится. Видимо, это будет единственный способ для тебя убедиться, что упрощённый запрос покрывает все задачи.> Что время, затрачиваемое на выполнение запроса одинаково мало.Ага, оговорился, это и имел в виду.
>>48960 >Ну, на самом деле тоже окажется, что не нужны. Ну посмотрим. >А задачи таковы, что слишком универсальный инструмент не нужен. Лучше, когда он есть, чем когда его нет. >И вот для неё ты решил взять универсальный нож. Потому что резать хлеб настойчиво предлагаешь ты, а Гин хочет резать многое другое, вот как-то так. >Формировать сложный запрос Так запрос формирует клиент. Я же только предоставляю ему возможность этот запрос выполнить. >application/x-www-form-urlencoded или multipart/form-data Стоп, мы, вроде как раз про то, что всё получение надо делать GET-ом, или ты уже про что-то другое? Насчёт передачи в формах — это другой разговор, там надо изучать эту тему. Если объект легко передать через форму с помощью $.post и легко на сервере распарсить, то я против ничего не имею. >Прямо очень нужна. Так нужна, что кушать не могу. Контактику вот прямо очень нужен этот POST? >Ты ни с того ни с сего взялся за абсолютно бесполезную сущность и даже не знаешь, зачем она нужна, мол, зато универсально. Начнём с того, что эту сущность сначала попросила Гин, вообще-то. То есть, она уже нужна. Алсо, проще будет оба одновременно сделать, чем по отдельности.
$.post
Чет вы как-то все слишком усложняете. Будь на сервере вебсокеты нужно было бы просто рассылать посты субскрайберам, то же самое и с удалением, достаточно уведомить всех. Осталось только взять впс.
>>48943 >Массив сам себя не экранирует и в запрос не вставит. Хочешь сказать, что это долго? >>48957 >В мире, где под андроид две читалки для борд, а для IOS — вообще ноль. Здесь должен был быть ехидный коммент про пользователей iOS, но я промолчу. Потому что под мою OS тоже нет. >Правда, я до сих пор не могу понять, чем отличаются эти ножи Подозреваю, что ничем, просто здесь так заведено, и нож для мяса/рыбы не желательно лишний раз использовать для всякой мелочи вроде хлеба, чтобы не затуплять без необходимости. >>48960 >Формировать сложный запрос вместо элегантного ии покрывающего все задачи сравнения. Угу, элегантность сравнения только в том, что там букв в запросе меньше, лол. >Ты ни с того ни с сего взялся за абсолютно бесполезную сущность Не только он, а мы вдвоем. >>48975 Если бы еще производительности на них хватало...
>>48977 А тут не нужен уж какой-то сильный сервер, тем более соединений немного. В принципе даже реализация на пхп сгодится, а проблем решится куча.
>>48971> Стоп, мы, вроде как раз про то, что всё получение надо делать GET-ом, или ты уже про что-то другое?Мы о том, что ты хочешь в JSON данные предавать. А потом немного отошли и начали примеры из веба давать.> Контактику вот прямо очень нужен этот POST?Не знаю, я не смотрел код контактика и что он там отправляет.>>48977> Хочешь сказать, что это долго?Для программиста это дольше, больше кода.> Угу, элегантность сравнения только в том, что там букв в запросе меньше, лол.Ну да. Нет этого глупого массива из сколь угодно длинного набора номеров.> Не только он, а мы вдвоем.Да как-то выходит, что тебе она тоже не нужна, потому что частного запроса тебе тоже хватает, а единственная причина, по которой ты его хочешь использовать, — мнимая производительность сервера, которой на самом деле нет и которая клиента не должна беспокоить.
>>48981 >Для программиста это дольше, больше кода. Не знаю как в php, в питоне это все легло бы на sqlalchemy, а кода было бы практически одинаково. Впрочем, программист серверной части у нас Хомура — ей и решать. >Нет этого глупого массива из сколь угодно длинного набора номеров. Ты уперся лбом в то, что тебе, видите ли, не нравится этот массив, и пропагандируешь свой частный способ. >что тебе она тоже не нужна То есть ты будешь за меня решать, что мне нужно? >которая клиента не должна беспокоить. Да она и не будет — клиенту не будет никакой разницы, как его приложение там работает внутри, если оно новые посты подгружает.
>>48984> Ты уперся лбом в то, что тебе, видите ли, не нравится этот массив, и пропагандируешь свой частный способ.Я ценю красоту и простоту кода.> То есть ты будешь за меня решать, что мне нужно?Расскажи тогда, где тебе это нужно, когда тебе частного запроса не хватает? Я так решил потому что ты рассказала, что тебе нужно, и всё это решается частным запросом. Быть может, нужно что-то ещё, но я об этом уже не знаю, просто придумать ещё что-то не получается.> Да она и не будет — клиенту не будет никакой разницы, как его приложение там работает внутри, если оно новые посты подгружает.Клиент это само приложение. Я имел в виду что тебе, как разработчику, должно быть всё равно, используется ли на сервере индексирование при каком-то запросе или нет.
>>48975 Мы же вроде уже решили, что вебсокеты для нас — это слишком, ибо всё решается простыми средствами, а выслушивать «у меня Курисачик перестал открываться, потому что админы режут всё, кроме 80 (и 443) порта» я не хочу. >>48977 >просто здесь так заведено Вот да. Я называю такие причины терминальными — потому что на них и возражать как-то невозможно, и соответствующую тему обсуждения можно считать исчерпанной, лол. >и нож для мяса/рыбы не желательно лишний раз использовать для всякой мелочи вроде хлеба Ну, это нормальное обоснование. Впрочем, в нашем случае мы считаем, что ножи (запросы) можно использовать бесконечно, да, так что тут пример не очень точный. >>48981 >Мы о том, что ты хочешь в JSON данные предавать. Я не против любого другого настолько же универсального формата. Передавать в виде формы — не вопрос, если это легко парсится на стороне сервера (да) и легко упаковывается на стороне клиента (javascript с jquery — видимо, да; то, на чём пишет Гин — не знаю, надо смотреть). >Для программиста это дольше, больше кода. Кода там ненамного больше по сравнению с предоставляемыми им возможностями. >>48987 >и всё это решается частным запросом. Ещё раз: твоим запросом не решается, например, скрытие удалённых постов. Короче, я уже вижу, что к какому-то консенсусу мы не придём. Есть два подхода со своими плюсами и минусами: «сервер — инструмент» (когда бизнес-логика в клиенте, а сервер просто предоставляет всю возможную функциональность) и «сервер — решальшик задач» (когда есть строго определённый круг задач и под каждую задачу свой, сугубо специфический запрос к серверу, который выдаёт всё в наиболее типичном для задачи формате). Пример первого — Linux, пример второго — iOS. И вот это «объяснить пользователю, что ему нужно совсем не то, что он хочет, а то, что может предоставить интерфейс», которое характерно для второго варианта, меня иногда раздражает. Лично я считаю, что нужно давать всю возможную функциональность (первый вариант), быть может, с возможностью коротких вызовов для реализации «особо популярных» задач (второй вариант). Думаю, в таком виде это удовлетворит всех, кроме хейтеров первого варианта, да.
>>49027 Мы уже обсудили что вебсокеты только для автообновления.
>>48863 >Я, кажется, представляю, о чём ты говоришь. Идея прикольная, но я бы забил и просто весь тред грузил чтобы уж точно всё предусмотреть. Больно много возни будет. Как бы тебе сказать. Примерно в таком режиме Курисач уже год как работал. Мы тут не для кодопозитива собрались, нужно развиваться. >Учитывая то, что никому кроме тебя такие запросы не нужны, вполне можно. А я бы не был так категоричен. Более того, Хомура уже говорил, что это предусмотреть дополнительно несложно. И в первую очередь он и принимает решение, как технически будет работать Курисач. >Потому что это велосипед Мы вообще новый движок сейчас изобретаем. Мне даже и сказать про велосипеды нечего, правда. >и так почти никто не делает Взывать к популярности. Хорошо, что для Хомуры это посредственный аргумент. Можешь ещё раз объективно объяснить, чем это плохо? >Если нет необходимости — лучше не усложнять, только проще будет. Необходимость — понятие очень растяжимое. Объективно говоря, для наших задач каждый раз пересылать разметку — лютый overkill, каждый раз устанавливать http-запросы — лютый overkill. В шифровании SSL необходимости тоже нет. Более того, в автообновлении как таковом необходимости нет. Работали и без неё. В оповещениях необходимости особой тоже нет. Это всё для удобства. Вот и JSON был бы неплох для удобства разработки. Если он будет лишним, и вызовет больше неудобств — тогда, конечно, он будет лишним. >И если необходимости получать конкретные посты нет, а её нет, то не надо ничего усложнять. Ты предлагаешь при обновлении стягивать сразу все посты? Вот тут явно протестую: скорость загрузки как по траффику, как по процессору возросла во много раз после перехода на динамику. >но я бы забил и просто весь тред грузил чтобы уж точно всё предусмотреть. Больно много возни будет. Знаешь, я тут кое-что заметил в этих словах. Да, тебе удалось меня довести всего за один пост ^_^ Это не «я бы забил», это ты каждому курисачеру предлагаешь вот так просто грузить каждый раз весь тред с нуля и перестраивать разметку. Хомура уже нас избавил от такой модели обновлений. Потому, что это важно.>>48957 >Такое изобретение называется «система контроля версий». Да, так и называется. >И уж тем более всего лишь ради сокращения сложности клиента, мне кажется, это не очень имеет смысл. >Учитывая то, что вычислительная мощность сервера постоянна, а клиентов — растёт с их количеством. Погоди-ка, это снизит нагрузку и на сервер. Я бы не предлагал, если бы это было тяжелее. Взгляни сам: в большинстве случаев там 0 обновлений, и сервер сразу говорит, что всё на месте. В данный же момент ему нужно сверять для этого имеющиеся номера постов. Когда там 1-2 обновления, это всё ещё будет проще, чем сверять все посты, и вычленять из них недостающие. Отличие от способа «по последнему id и количеству» я уже говорил: такой способ более универсальный, он поддерживает редактирование постов без изменения id и добавление/удаление кросс-тредовых ответов. Если же последние две фичи не нужны, то считаю способ «last id + last post number» наиболее оптимальным. Разве что для удаления/переотправки он требует загрузки всего треда заново. >Кстати, заметь: при автообновлении очень мал счётчик «попаданий» на событие «страница изменилась». Да, поэтому я и говорю, что нужно наиболее оптимизировать на случай, когда ничего не происходит. У постояльцев (которые основную нагрузку и дают) ещё и открыто несколько тредов сразу. Но и обновление всего треда — явление нежелательное. >В мире, где под андроид две читалки для борд, а для IOS — вообще ноль. Тогда нам ещё нужна мобильная веб версия. >Btw, уже сейчас давно как можно пользоваться json.update.php — в ответ на запрос из списка имеющихся у клиента постов прилетит и список удалённых постов, и html добавленных, и новая карта ответов треда. Это специально для тех, кто желает максимум вместить в один запрос. О, спасибо. >Если не ошибаюсь, это делается автоматизированно (где-то в дебрях read.php надо глянуть). Не представляю, о каком «автоматизированно» ты говоришь. >Что время, затрачиваемое на выполнение запроса одинаково мало. Опять ты их насилуешь, хехе?>>48975 >Будь на сервере вебсокеты нужно было бы просто рассылать посты субскрайберам, то же самое и с удалением, достаточно уведомить всех. О, адепт вебсокетов тоже тут. Привет.>>48977 >Если бы еще производительности на них хватало... Как раз вебсокеты — самая лучшая модель по загрузке процессора. Только вот с оперативной памятью беда: на каждое соединение постоянно висит отдельный серверный процесс. Да и не все платформы/браузеры/конфигурации поддерживают вебсокеты. Тот же Kaspersky, да и многие другие антивирусы, например, блокируют вебсокеты просто «на всякий случай».>>48981 >Для программиста это дольше, больше кода. Ты уже что-то пишешь?>>49027 >Есть два подхода со своими плюсами и минусами Всё равно нам нужен будет fallback, и простой интерфейс обновления всего треда целиком (либо постранично, если всё пойдёт дальше) Так что лучше сразу предоставить пользователю на выбор два стула интерфейса, а он пускай решает, что делать. Для внешнего парсинга может быть простой интерфейс с полным обновлением предпочтительнее. А для более продвинутого (в т.ч. браузерного) интерфейса желателен вариант с наименьшими нагрузками.
>>49173 >О, адепт вебсокетов тоже тут. Я периодически захожу почитать. Глядя какие костыли предлагают, я невольно задумываюсь над тем зачем, зачем они это делают? Я кстати закончил модуль работающий с файлами. Завтра приступлю непосредственно к реализации самой доски.
>>49052 Хорошо, тогда выслушивать «у меня тред перестал обновляться, почините» тоже не очень. >>49173 >В данный же момент ему нужно сверять для этого имеющиеся номера постов. Ну сравнение массивов не более 500 uint32_t — очень быстрая операция, как правило, это даже вмещается в одну кэш-строку процессора, так что в идеале выполняется за те же 500 тактов (другое дело, что перед собственно сравнением его его потаскают по памяти и т.п.) Даже SELECT выполняется несоизмеримо дольше (а сервер ведь должен узнать, чё там у базы). >Когда там 1-2 обновления, это всё ещё будет проще, чем сверять все посты, и вычленять из них недостающие. Но эти все обновления нужно будет хранить неограниченное время — а ведь это дублирование данных в базе и её сильное разрастание. >Если же последние две фичи не нужны, то считаю способ «last id + last post number» наиболее оптимальным. Разве что для удаления/переотправки он требует загрузки всего треда заново. Но у нас ведь есть и карта ответов, и удаление постов бывает — поэтому проще обмениваться списком постов и картой ответов (это пара килобайт туда и пара десятков килобайт оттуда). >Да, поэтому я и говорю, что нужно наиболее оптимизировать на случай, когда ничего не происходит. Да, сейчас как раз так и есть: если сервер вернул карту ответов и список постов, идентичные тем, что были до обновления, тогда на странице вообще ничего не модифицируется. >Тогда нам ещё нужна мобильная веб версия. Кстати да, наверное, нужно допилить мобильную версию до вменяемого уровня. >Не представляю, о каком «автоматизированно» ты говоришь. Да, кстати, сейчас тоже посмотрел и понял, что там что-то какая-то ересь, всё вручную делается. И что это всё надо переписывать, лол. >Так что лучше сразу предоставить пользователю на выбор два интерфейса, а он пускай решает, что делать. Вот и я о том же. Кстати, Курисач, я сейчас думаю над реализацией картинки + видео. Думаю сделать так: 1) при постинге с видео — вместо создания видеобокса в посте я в начало поста дописываю ссылку; 2) отключаю всю функциональность видобокса и эмбеддинга видео на сервере; 3) переношу превращение ссылки в видеобокс в kusaba.new.js; 4) делаю галочку в настройках «превращать ссылки на youtube, coub, vimeo в видеобокс» 5) если галочка выключена, то в каждом посте в видео превращается только первая ссылка, если до неё нет никакого текста и к посту не приаттачена картинка; 6) если галочка включена, то превращаются все распознанные ссылки в тексте вне зависимости от того, есть ли в посте картинка или нет. Как вам идея? Какие подводные камни?
>>49027> Ещё раз: твоим запросом не решается, например, скрытие удалённых постов.А как это решается твоим? В 2 запроса? Не смеши меня.>>49173> Мы вообще новый движок сейчас изобретаем. Мне даже и сказать про велосипеды нечего, правда.Одно дело изобретать движок, другое — новые способы передачи данных.> Взывать к популярности.Потому что популярно значит допустимо. Непопулярно значит нужно в конкретных случаях, когда не хватает популярного варианта. Это не наш случай.> Можешь ещё раз объективно объяснить, чем это плохо?И первого раза не было. Я не веб разработчик и вообще не изучал историю и принципы работы веба настолько хорошо, чтобы точно знать, чем JSON плох. Единственное, что я могу предложить, — формы умеют прозрачно кодировать и декодировать все клиенты и сервера. А вот в случае с JSON это всегда будет лишняя работа программисту как на сервере, так и на клиенте.Надо думать, прежде чем делать что-то необычное, а не делать необычное ради необычного.> Необходимость — понятие очень растяжимое.Ты привёл реально необходимые вещи.Нет необходимости передавать разметку? Передавайте JSON. Что-то так или иначе придётся передавать. И вообще сделать бы надо...Про запросы не понял, но у нас веб-браузеры, они только по HTTP умеют общаться с серверами.В шифровании есть необходимость, это обеспечение безопасности.Всё, что ты пишешь дальше, имеет необходимость: стало удобнее.От использования JSON как формата для передачи данных удобнее никому не станет, как я уже сказал, как минимум добавиться явный шаг для его кодирования и декодирования, потому что его поддерживает меньшее число серверов/клиентов. А единственный аргумент за него — «можно передавать массивы массивов», ороро.> Ты предлагаешь при обновлении стягивать сразу все посты?Все посты после последнего.> Это не «я бы забил», это ты каждому курисачеру предлагаешь вот так просто грузить каждый раз весь тред с нуля и перестраивать разметку.Потому что слишком много всего тут сейчас надо предусмотреть, и всё из-за карты ответов. Например, если на пост Х ответили из другого треда, сейчас без полной загрузки треда этого не узнать. Придётся много возиться.>>49332> Кстати, Курисач, я сейчас думаю над реализацией картинки + видео.Не надо усложнять с этой первой ссылкой. Просто убери возможность прикреплять видео, а все ссылки преобразуй в видео боксы. Если в настройках выключена галочка, то вообще ничего не преобразуй.
Я заюзала свой недописанный движок для того, чтобы на нем тестировать клиент. Таки пригодилось. >>49027 >в нашем случае мы считаем, что ножи (запросы) можно использовать бесконечно Использовать какой-то сложный (по нагрузке) запрос для чего-то простого лучше не стоит, как использовать для хлеба нож для мяса. >>49173 >Только вот с оперативной памятью беда Это, в общем-то, тоже проблема с производительностью, причем VDS с большим количеством оперативы нынче дороги. >>49382 >не изучал историю и принципы работы веба настолько хорошо, чтобы точно знать, чем JSON плох. Не знаем, но уже не любим. Шикарно. >формы умеют прозрачно кодировать и декодировать все клиенты и сервера И JSON тоже — фактически везде есть под это утилиты. >его поддерживает меньшее число серверов/клиентов Что не поддерживает JSON? Brainfuck?
>>49396> Не знаем, но уже не любим. Шикарно.Кто не любит? Нужны серьёзные причины для чего-то нестандартного, только и всего. Меня попросили объективные причины чтобы не использовать — я таких не знаю, хотя одну и вспомнил, но дело не в этом.> И JSON тоже — фактически везде есть под это утилиты.Речь не об утилитах, а о фактической поддержке клиентами и серверами, без необходимости дополнительной конвертации, и не важно, ручками ты это делаешь или библиотекой. Потому что формат форм — это стандарт, JSON — нет.> Что не поддерживает JSON? Brainfuck?> > добавиться явный шаг для его кодирования и декодирования
Пока криво и недоделано, но уже что-то. Я в восторге от QML, который сам на себя берет отображение большей части HTML-форматирования (например, эту ссылку) и освобождает меня от парсинга. >>49519 >для чего-то нестандартного >Потому что формат форм — это стандарт, JSON — нет. JSON уже c 2014 международный общепризнанный стандарт. > > > добавиться явный шаг для его кодирования и декодирования Строчка в начале и строчка в конце. Тоже мне сложности.
>>49382 >А как это решается твоим? В 2 запроса? Не смеши меня. Можно в два, можно сделать и в один (сейчас автообновление так работает — в один запрос делает всё). >Непопулярно значит нужно в конкретных случаях, когда не хватает популярного варианта. Это не наш случай. Имхо, как раз наш, если мы, конечно, о передаче массива, а не о дилемме JSON/формы. >Единственное, что я могу предложить, — формы умеют прозрачно кодировать и декодировать все клиенты и сервера. А вот в случае с JSON это всегда будет лишняя работа программисту как на сервере, так и на клиенте. Давай разберём по частям всё тобой написанное. 1. Формы. 1.1. Клиент: $.post(url, ...); — jQuery. Не «прозрачно», но просто. foo = new FormData; foo.append(...); bar = new XMLHTTPRequest; bar.send(foo); — чистый javascript. Нифига не прозрачно. Остальные языки — не знаю, как. В каких-то, быть может, просто/прозрачно, в каких-то нет. Для примера, в PHP я прозрачного метода для POST-запросов не видел. Только такой: $options = array( 'http' => array( 'header' => "Content-type: application/x-www-form-urlencoded\r\n", 'method' => 'POST', 'content' => http_build_query($data) // $data = array('key1' => 'value1', 'key2' => 'value2', ...); ) ); $context = stream_context_create($options); $result = file_get_contents($url, false, $context); 1.2. Сервер: $data = $_REQUEST; — да, согласен, прозрачно. 2. JSON. 2.1. Клиент: $.post(url, ...); — jQuery. Так же. foo = new FormData; foo.append('data',JSON.stringify(data)); bar = new XMLHTTPRequest; bar.send(foo); — чистый javascript. То же самое, за исключением того, что FormData::append() вызывается только один раз для всех передаваемых данных — а значит, код одинаков для любого формата входных данных. В предыдущем случае придётся перебирать все данные, которые мы хотим отправить. 2.2. Сервер: $data = json_decode($_REQUEST['data']); — не совсем прозрачно, но элементарно понятно. И вот ради того, чтобы избежать вот этого вот усложнения в 21 символ, стоит мутить крокодилы с формами на клиенте? > потому что его поддерживает меньшее число серверов/клиентов. WAT >Например, если на пост Х ответили из другого треда, сейчас без полной загрузки треда этого не узнать. WAT Сейчас для этого перезагрузки треда не требуется, только перезагрузка карты ответов (в JSON, кстати), что несоизмеримо быстрее и проще. >Если в настройках выключена галочка, то вообще ничего не преобразуй. Но это нарушило бы привычную функциональность. А мой подход таков: при запиливании новой фичи для тех, кому эта фича не нужна, не должно ничего измениться. >>49396 >Таки пригодилось. Кухихи, вот, оказывается, какая ему судьба была предназначена. Алсо, запилил-таки видео + картинку. Немного, правда, по-другому: 1) при постинге с видео — вместо создания видеобокса в посте я в начало поста дописываю ссылку — да, переписана функция embeddedVideoBox(); 2) отключаю всю функциональность видобокса и эмбеддинга видео на сервере — поскольку ссылка дописывается сервером (чтобы не ломать уже отправленные посты), не стоит этого делать; 3) переношу превращение ссылки в видеобокс в kusaba.new.js — да, сделан «класс» embed_class { init(); process_links(); } ; 3.5) т.к. эта замена длится долго, теперь медленнее грузятся посты с кучей видео, особенно с vimeo и coub, у которых нет простого пути получить тамбнейл (если кто подскажет, буду очень благодарен), и приходится сразу на страницу пихать iframe с плеером — я делаю эту замену только в тех постах, что пришли от сервера, а не во всех видимых (в частности, при развороте поста, всплывании поста, предпросмотре и т.п. грузится только один пост, поэтому заменять нужно только в нём); 4) делаю галочку в настройках «превращать ссылки на youtube, coub, vimeo в видеобокс» — да; 5) если галочка выключена, то в каждом посте в видео превращается только первая ссылка, если до неё нет никакого текста и к посту не приаттачена картинка — сделано хитрее: embeddedVideoBox() ставит ссылкам класс alwaysvisible — они видны всегда; остальные — только при включённой галочке; 6) если галочка включена, то превращаются все распознанные ссылки в тексте вне зависимости от того, есть ли в посте картинка или нет — да. Инфа о том, как юзать — см. >>49597.
$.post(url, ...);
foo = new FormData; foo.append(...); bar = new XMLHTTPRequest; bar.send(foo);
$options = array( 'http' => array( 'header' => "Content-type: application/x-www-form-urlencoded\r\n", 'method' => 'POST', 'content' => http_build_query($data) // $data = array('key1' => 'value1', 'key2' => 'value2', ...); ) ); $context = stream_context_create($options); $result = file_get_contents($url, false, $context);
$data = $_REQUEST;
foo = new FormData; foo.append('data',JSON.stringify(data)); bar = new XMLHTTPRequest; bar.send(foo);
$data = json_decode($_REQUEST['data']);
>>49275 >Я кстати закончил модуль работающий с файлами. Завтра приступлю непосредственно к реализации самой доски. О, молодец. >Ну сравнение массивов не более 500 uint32_t — очень быстрая операция, как правило, это даже вмещается в одну кэш-строку процессора, так что в идеале выполняется за те же 500 тактов (другое дело, что перед собственно сравнением его его потаскают по памяти и т.п.) Даже SELECT выполняется несоизмеримо дольше (а сервер ведь должен узнать, чё там у базы). Ну погоди, мы же говорим про базу данных. Сравнение интов — дело нехитрое. Больше вопрос в том, сколько должен выполнить сервер БД, чтобы из 500 строк повытягивать по 1 инту. Ему нужно довольно много побегать по связям для этого. А результат примерно тот же: после выполнения запроса веб сервер сразу знает, что именно у сервера БД запрашивать. >Но эти все обновления нужно будет хранить неограниченное время — а ведь это дублирование данных в базе и её сильное разрастание. Но не нужно же хранить ВСЕ изменения? Только последние 4-20 минут, всё старее можно удалять. Такой запрос даже за O(n) будет лёгким, будь за последние 20 минут хоть 1000 постов. Не дай бог такой темп на Курисаче >Но у нас ведь есть и карта ответов, и удаление постов бывает — поэтому проще обмениваться списком постов и картой ответов (это пара килобайт туда и пара десятков килобайт оттуда). Ну да. Удаление поста приведёт к перезакачиванию всего треда. >если сервер вернул карту ответов и список постов, идентичные тем, что были до обновления Погоди, карта ответов, как результат, так вся каждое обновление и пересылается? Да и запрос на составление 500 даже номеров — не самая простая задача. Хоть и да, это один запрос к базе, а не два. (Хотя постой, что-то мне подсказывает, что в SQL можно сразу написать сложный запрос вида: на каждую строку, принадлежащую моему треду и позднее «часа Х» достать пост по номеру из её же колонки «пост») Ладно, я и так понял: Подход весьма хорош. Но реализации требует тщательной и аккуратной. Как результат, что с него толку, если я его не пишу. >Кстати, Курисач, я сейчас думаю над реализацией картинки + видео. >Думаю сделать так >Как вам идея? Хмм, а костыль действительно неплох. >Какие подводные камни? Webm не продуман вообще. Всё же, там нужна и полноценная картинка, и полноценное видео. Других, вроде бы, не вижу.>>49382 >новые способы передачи данных. Телепатию через Нибиру рептилоидами >Потому что популярно значит допустимо. А непопулярно, значит, недопустимо уже? Это не смешно. >А вот в случае с JSON это всегда будет лишняя работа программисту как на сервере, так и на клиенте. В этом-то и дело, что тут ты и неправ. Есть удобные методы для работы с JSON. Как на сервере, так и на клиенте. Это Хомура и подметил: почему бы их не применить. А методы настолько удобные, что данными можно манипулировать сразу как массивами по имени (ассоциативными). >потому что его поддерживает меньшее число серверов/клиентов Стандарт Javascript определяет, что должны все. И уже 100 лет как. PHP сервер уже 100 лет как умеет. А новые так изначально с этой функциональностью на борту построены. Снова мимо. >Все посты после последнего. Уже говорили же: а что будем делать при удалении? Я уж не говорю тут, что от редактирования с сохранением номера мы отказались.>>49396 >причем VDS с большим количеством оперативы нынче дороги. Оперативная память осталась дорогой.>>49609 >Алсо, запилил-таки видео + картинку. Да, любопытно. Буду обкатывать.
Ну что, обкатываем: https://www.youtube.com/watch?v=TfH2Zw_YKKk Однострока: Тест 2: https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk Чуточку кода:https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk Inline-кода: https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk Экран-тесты https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk Тест555https://www.youtube.com/watch?v=TfH2Zw_YKKk И как нас тут видно, на днище, капитан?
Однострока:
https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk
>>49585> JSON уже c 2014 международный общепризнанный стандарт.Который ни один браузер не поддерживает в формах, например.> Строчка в начале и строчка в конце. Тоже мне сложности.А можно просто не использовать JSON и не надо вообще ничего добавлять.>>49609> Можно в два, можно сделать и в один (сейчас автообновление так работает — в один запрос делает всё).Одним — это как?> Имхо, как раз наш, если мы, конечно, о передаче массива, а не о дилемме JSON/формы.Для массива и формы хватит. Массива в массиве у вас нет.> Остальные языки — не знаю, как. В каких-то, быть может, просто/прозрачно, в каких-то нет. Для примера, в PHP я прозрачного метода для POST-запросов не видел. Только такой:Очевидно, потому что пхп — серверный язык и не особо подходит чтобы самому запросы делать.> И вот ради того, чтобы избежать вот этого вот усложнения в 21 символ, стоит мутить крокодилы с формами на клиенте?Так где крокодилы на клиенте? На пхп что ли?> WATЯ о прозрачном кодировании/декодировании.> Но это нарушило бы привычную функциональность.Которая, в общем-то, никому не нужна. Сделай предупреждение, что всё, как раньше работать не будет, 2010 год давно закончился и пора сделать по-людски. Никто против и не будет даже.>>49648> А непопулярно, значит, недопустимо уже?А непопулярно значит читай хоть немного дальше того предложения, на которое собираешься отвечать.> А методы настолько удобные, что данными можно манипулировать сразу как массивами по имени (ассоциативными).Сомневаюсь, что такие методы понадобятся. С $_request ведь тоже как с ассоциативным массивом работаешь.> Стандарт Javascript определяет, что должны все. И уже 100 лет как.А при чём тут JS? У меня в курле его нет, например. Да и речь о прозрачном кодировании. Даже браузеры этого не умеют. А через формы не умеют даже непрозрачно.> Уже говорили же: а что будем делать при удалении?2 запроса. В общем-то, запрос по номерам в любом случае требует предварительный запрос номеров. Отсюда и узнаем удалённые.Заодно придумал новый аргумент, чем плох JSON: банально сложнее тестировать и вникать в принципы работы. С формами всё легко: можно легко клиентом кодировать, можно курл использовать, можно хоть в браузере через адресную строку смотреть результат. Апи обычно не для себя любимых делают.
Попробуйте открыть последние 50 постов любого треда.
>>49669 Удваиваю реквест починки. Очень неудобно весь тред скроллить с телефонов, грузится долго.
>>49670 Присоединюсь с просьбой туда же (в 404 хендлер) починить этот чёртов контроль кеширования. Уже не раз замечал, что при загрузке страницы браузер берёт версию, что у него была ещё вчера, вместо обновления.
>>49651 О святая Мадо-ками сама! Нашествие бобров! К такому меня жизнь не готовила, ведьмы как-то проще =) (btw, видно нормально, в коде, само собой, ссылки не раскрываются, заэкранированные тоже). >>49669 >>49670 >>49678 Почистил кэш клауды. Если почистить и кэш браузера тоже, то должно быть норм. Проверяйте, плз. Вообще не понимаю, почему клауда пытается кэшировать вот с таким убойным комплектом директив .htaccess: <Files *.html> RequestHeader add Cookie "prevent-caching" early Header add Expires "Mon, 26 Jul 1997 05:00:00 GMT" Header add Pragma "no-cache" Header add Cache-Control "must-revalidate, no-cache, no-store" Header unset Last-Modified Header unset ETag Header unset Vary </Files> Или ей наплевать, что запрос идет к .html, если он заканчивается 404? Тем более, что как ни странно, в заголовках ответа этих параметров нету... Короче, надо будет разбираться. На >>49648 и >>49666 отвечу вечерком. Хомура мимозабежавшая на Курисач
<Files *.html> RequestHeader add Cookie "prevent-caching" early Header add Expires "Mon, 26 Jul 1997 05:00:00 GMT" Header add Pragma "no-cache" Header add Cache-Control "must-revalidate, no-cache, no-store" Header unset Last-Modified Header unset ETag Header unset Vary </Files>
К-кстати у кого баги с обновление постов в Последние 50 постов зайдите в опции и поставьте галочку «Использовать старый метод обновления треда ». Это временное решение должно помочь, пока не починят.
С сегодняшнего дня у меня в опере мини снова вместо капчи значок загрузки. Единственный способ увидеть капчу, чтобы запостить в тред — зайти напрямую на kurisa.ch/captcha.php Можно ли вернуть, как было?
>>49648 >сколько должен выполнить сервер БД, чтобы из 500 строк повытягивать по 1 инту На самом деле, совсем немного — запрос элементарный: WHERE 'parentid' = $threadid, и всё (ну, ещё boardid, но он тут не важен). Другое дело — когда нужно получить последние посты: тут или WHERE 'parentid' = $threadid AND 'id' > $lastid, или WHERE 'parentid' = $threadid AND 'timestamp' > $last_update. Вытягивать инты ему всё равно придётся, просто в последнем случае он их не будет класть в выходной массив. А мой опыт кусабошатания говорит о том, что быстрее получается вытащить из базы сразу больше, но более простым запросом, а потом отсеять (если надо) уже в скрипте. >Только последние 4-20 минут, всё старее можно удалять. Но это означает, что все, кто обновляет треды реже, чем в 20 минут (а это вполне нормально, если автообновление отключено) — пролетают с «красивым» механизмом автообновления, так? >спойлер Было как-то за ночь, когда вайпали, лол. Если интересно, могу выгрузить csv из админки с темпом постинга или даже сделать xls за последние 400 дней (воу, так у нас же юбилей!) с красивыми графиками. >Погоди, карта ответов, как результат, так вся каждое обновление и пересылается? Да, ибо в ней не так уж много ссылок (в одном из рандомов, близком к бамплимиту намерил 1200 элементов). Сравнивать проще на клиенте, иначе бы пришлось гонять карту туда-обратно, а так — только обратно. >в SQL можно сразу написать сложный запрос вида: на каждую строку, принадлежащую моему треду и позднее «часа Х» достать пост по номеру из её же колонки «пост» Хм. Вроде вполне себе простой запрос, нет? SELECT 'message' FROM ... WHERE 'parentid' = ... AND 'timestamp' > ... >Всё же, там нужна и полноценная картинка, и полноценное видео. Для этого, увы, нужен ffmpeg. Ту самую javascript-реализацию ffmpeg на стороне клиента я рассматриваю исключительно как анекдот, да. =) Соответственно, этот реквест у меня поставлен в статус DELAYED. Но вообще, webm будет работать как обычный файл (и да, одновременно прикреплять webm и картинку будет нельзя — это же всё равно, что прикрепление нескольких картинок). >А методы настолько удобные, что данными можно манипулировать сразу как массивами по имени (ассоциативными). Да, именно это я и пытаюсь сказать. >от редактирования с сохранением номера мы отказались. Ну от него мы отказались презде всего по реквестам здешних жителей. >>49666 >Который ни один браузер не поддерживает в формах Не очень понял. В форму можно запилить поле со значением, в котором будет JSON-строка и сервер спокойно может это поле распарсить. Или ты про то, что JSON в «голом» виде не передаётся? Ну так HTTP тоже, иснкапсулируется в TCP-соединения, те — в IP-пакеты, а те — в Ethernet-фреймы, например. Дополнительный уровень абстракции здесь имеет не такой уж и большой оверхед по сравнению с удобством. >А можно просто не использовать JSON и не надо вообще ничего добавлять. Как видно из моего поста (>>49609) — надо (к примеру, зависящая от типов данных сборка формы на javascript, если не использовать jQuery). >Одним — это как? Туда — список отображённых постов в треде, оттуда — новый список постов, обновлённая карта ответов и html-кусок для дописывания в конец треда. Кстати, да, узкоспециальизированный инструмент строго для одного применения. Такова цена одного запроса вместо двух. >Массива в массиве у вас нет. Ну, как минимум, от сервера прилетает карта ответов в таком виде. От клиента тоже может понадобиться что-либо передавать. Вообще, я смотрю, разговор из предметной области ушёл в рассуждения о высших материях. Мне со стороны сервера совершенно не сложно одинаковым образом разбирать как классический $_REQUEST, так и $_REQUEST['json_data']. Вплоть до того, что можно будет написать if (isset($_REQUEST['json_data'])) $_REQUEST = json_decode($_REQUEST['json_data']) и дальше вообще не задумываться, каким образом прилетели исходные данные. А те, кто пишут клиенты, как хотят, пусть так и пишут. >пхп — серверный язык и не особо подходит чтобы самому запросы делать. Само собой, это был исключительно пример. >Так где крокодилы на клиенте? В многократных FormData::append(). >Я о прозрачном кодировании/декодировании. Я больше чем уверен, что всё, что может отправлять формы, кроме специальных утилит, что только это и умеют, умеет работать и с JSON. >Которая, в общем-то, никому не нужна. Сделай предупреждение, что всё, как раньше работать не будет Если можно сделать так, чтобы этого избежать, и это не труднее — то я считаю, что функциональность надо сохранять. И меня бесит, когда остальные думают противоположным образом и в новых версиях прог выпиливают привычную функциональность. >Никто против и не будет даже. Я буду, например. Мне удобнее ссылку пастить в поле, а не крутить текстбокс куда-то там вверх, когда в нём 30 кб текста. >С $_request ведь тоже как с ассоциативным массивом работаешь. Одноуровневым. JSON более гибок в плане многоуровневых массивов. >У меня в курле его нет, например. О святая Мадо-ками-сама! Да успокойся уже, будет тебе интерфейс с формами, если ты хочешь curl-ом читать Курисач. Да, если человек хочет извращений — я не вправе ему этого запретить. =) А для тех, кому удобнее запихнуть всё в json и не копаясь с формами, отправить одним полем — будет json. Кстати, curl — это как раз такая утилитка про котоую я говорил выше (которая больше ничего не умеет — и не должна уметь, в общем-то). >банально сложнее тестировать и вникать в принципы работы. WAT Ты «сырой» JSON нигде не читаешь, на клиенте данные в него пакуются уже после того, как скомпонованы, а на сервере ты их видишь уже после распаковки. >>49669 Да, это я хотел починить обновление «последних 50 постов» и «первых 100 постов», но вместо этого сломал хэндлер 404. Ещё один повод ночью всё-таки пытаться выспаться, а не шатать курисабу, да. Ближе к утру починил. >>49670 К 8:30 должно было уже быть починено, если до сих пор не починилось — то стоит почистить кэш (кэш клауды я в 15:30 сбросил). >>49817 >С сегодняшнего дня у меня в опере мини снова вместо капчи значок загрузки. Жесть. Так во всех тредах? В других браузерах не проявляется? В консоли оперы видны какие-нибудь сообщения?
WHERE 'parentid' = $threadid
WHERE 'parentid' = $threadid AND 'id' > $lastid
WHERE 'parentid' = $threadid AND 'timestamp' > $last_update
SELECT 'message' FROM ... WHERE 'parentid' = ... AND 'timestamp' > ...
$_REQUEST
$_REQUEST['json_data']
if (isset($_REQUEST['json_data'])) $_REQUEST = json_decode($_REQUEST['json_data'])
>>49833 > Жесть. > Так во всех тредах? > В других браузерах не проявляется? > В консоли оперы видны какие-нибудь сообщения? Ты не так понял. Не Опера, а Опера Мини, мобильный браузер, который грузит веб-страницы через прокси-сервера Оперы. Я через него с телефончика в интернете сижу. Да, во всех тредах.
>>49835 Ох, гоменнасай. Увидел «опера» и уже настроился на десктопную оперу, с которой у Курисача не очень радостные отношения (по крайней мере, были). После чистки кэша всё так же?
>>49837 В Опере Мини нет кэша. Может быть, он есть на прокси-серверах Оперы, но там я почистить не смогу.
>>49833> Или ты про то, что JSON в «голом» виде не передаётся?Именно. Используя xhr можно в голом виде, но из формы — никак. А передавать JSON в поле формы так вообще скрещивание ежа с ужом.> Как видно из моего поста (>>49609) — надо (к примеру, зависящая от типов данных сборка формы на javascript, если не использовать jQuery).Некоторые вообще не умеют не-вручную любые данные формировать, хоть формы, хоть JSON. Зато многие умеют делать это прозрачно, тогда как с JSON, определённо, почти никто.> Туда — список отображённых постов в треде, оттуда — новый список постов, обновлённая карта ответов и html-кусок для дописывания в конец треда.Если вы перейдёте на запрос по номерам, получится 2. Не понятно, к чему ты вообще про это сказал, если ни частным, ни общим запросом в 1 запрос ничего не выйдет.> Ну, как минимум, от сервера прилетает карта ответов в таком виде. От клиента тоже может понадобиться что-либо передавать.Сервер может что угодно передавать, давай не перескакивать на 20 шагов вперёд. Где клиенту потребуется передавать массив в массиве?> так и $_REQUEST['json_data'].Так ты серьёзно ежа с ужом скрестить собрался? Или пхп просто не умеет с другим форматом, отличным от форм, работать?> В многократных FormData::append().У нас jQuery используется, не надо никаких FormData и xhr. Голый JS вообще слабая штука.> Я больше чем уверен, что всё, что может отправлять формы, кроме специальных утилит, что только это и умеют, умеет работать и с JSON.Ну, вообще говоря — нет. > Я буду, например. Мне удобнее ссылку пастить в полеПри отправке скриптом добавляй содержимое поля в начало текста, делов то.> О святая Мадо-ками-сама! Да успокойся уже, будет тебе интерфейс с формами, если ты хочешь curl-ом читать Курисач.А ведь приходилось как-то.И зря ты его недооцениваешь. Через курл удобно потестировать запросы, чтобы разобраться, как они работают. И в случае с JSON это будет от неудобно в случае ежа и ужа до невозможно, если нормально делать. Хотя, может и возможно, лень проверять.
Тестировать надо автоматическими тестами phpunit и прочие, а не curl вручную. Да и json не бинарный, а текстовой, какие могут быть проблемы? Он парсится ничуть не медленнее формы, а уж маппятся они одинаково. Хотел было предложить вместо стандартного реквеста обертку из symfony, ну да ладно, кому как удобнее. Но вообще я согласен с хейтером жсон. Если вы не используюте RPC для всего, вплоть до формы загрузки, то зачем он нужен? Делайте API и все.
>>49666 >Который ни один браузер не поддерживает в формах, например. А при чем тут эти формы? Забудь ты про свои формы, что ты к ним привязался, это API. И все равно ответ-то в JSON придет. >можно курл использовать Ты еще скажи, что в curl нельзя использовать JSON, ага. http://stackoverflow.com/questions/7172784/how-to-post-json-data-with-curl-from-terminal-commandline-to-test-spring-rest Первая строчка в гугле. >>49851 >но из формы — никак. Зачем нам формы? >тогда как с JSON, определённо, почти никто И тут ты мне объясняешь, чего такого непрозрачного в кодировании JSON. >>49851 >Ну, вообще говоря — нет. Примеры? >Через курл удобно потестировать запросы, чтобы разобраться, как они работают. См. выше. >>49860 >Делайте API и все. Так его-то и делаем, на JSON. Просто один анон тут упорно пытается доказать, что JSON не нужен, а когда я ему говорю, что в API надо передавать список номеров постов для получения их содержимого, он начинает мне доказывать, что и это мне, видите ли, не нужно.
>>49840 Хм, то есть, подожди, она каждый раз всё грузит из инета, картинки там, всё-всё-всё? Очень странно, у меня даже в Opera Mobile на Windows Mobile 4 был кэш. >>49851 >А передавать JSON в поле формы так вообще скрещивание ежа с ужом. Почему JSON over HTTP POST — это «скрещивание ежа с ужом», а HTTP over TCP, TCP over IP, IP over Ethernet — нет? >Где клиенту потребуется передавать массив в массиве? Я уже говорил, что пока не знаю, но не считаю, что это нужно запретить пользователю. >Или пхп просто не умеет с другим форматом, отличным от форм, работать? Хм, а интересная идея — пытаться сначала парсить поле формы как json, потом запрос как форму (через $_REQUEST), и наконец, если это не удалось — то php://input как json. Надо будет тоже заложить такую возможность. >У нас jQuery используется А у клиента может и не использоваться. >При отправке скриптом добавляй содержимое поля в начало текста, делов то. Это был один из вариантов, что я рассматривал — но он не был связан с отключением функциональности, в отличие от изначально предложенного тобой. >А ведь приходилось как-то. А месье знает толк в извращениях. Поясняю: я имею в виду не «проверить какую-то фичу и посмотреть что в запросе, что в ответе» — там, действительно, нужна максимальная простота тулзов. Я имею в виду читать в нормальном виде. >И зря ты его недооцениваешь. Я юзаю curl тогда, когда именно он нужен, а не вместо браузера. Для отладки он порой незаменим, а вот в нормальном режиме я лучше посижу через Хоро, например. >Через курл удобно потестировать запросы, чтобы разобраться, как они работают. Именно >до невозможно, если нормально делать. Как Гин пишет ниже — возможно. >>49860 >Если вы не используюте RPC для всего, вплоть до формы загрузки, то зачем он нужен? Банальная простота упаковки и распаковки клиентом и сервером.
php://input
>>49971 > у меня даже в Opera Mobile на Windows Mobile 4 был кэш Opera Mobile и Opera Mini — совершенно разные браузеры. > она каждый раз всё грузит из инета, картинки там, всё-всё-всё? Весь трафик проходит через прокси-сервера Оперы, где веб-страницы переформатируются и сжимаются. Любые запросы, скрипты — всё выполняется через сервера. Конечное устройство только отображает статичную страничку, загружая каждый раз новую после любого обращения к серверу. В общем, раньше при переформатировании страницы Курисача на прокси-сервере Оперы в итоговую страничку, передаваемую мне в телефончик, на место капчи ставилась картинка с капчей, а теперь — значок загрузки. Капча сейчас, как я вижу, не сразу выдаётся, а подгружается после загрузки страницы. Возможно, дело в этом. Два дня назад капча выдавалась так же?
>>49982 >Два дня назад капча выдавалась так же? Да, в том-то и дело. По окончании загрузки вызывается функция refreshCaptcha() и заменяет этот значок загрузки на сгенерированную капчу. Причём, в обычной опере и в хроме в некоторых тредах тоже такое было, но после небольшого шаманства (несколько месяцев назад) с тем, где вызывать функцию refreshCaptcha() (перенёс просто в код страницы из $(document).ready) проблема решилась. В Opera Mini, судя по всему, консоли тоже нет, да?
>>49863> Ты еще скажи, что в curl нельзя использовать JSON, ага.Не был уверен насчёт кастомизации формата. Однако JSON ещё и ручками вбивать надо. Пипец удобно.> Примеры?Курл как раз, но это я поздно. Я вообще мало HTTP клиентов знаю, чтобы кучу примеров приводить, но и его утверждение ни разу не доказано.> он начинает мне доказывать, что и это мне, видите ли, не нужно.Но ведь и правда не нужно. Где тебе оно нужно ты так и не рассказала.>>49971> Почему JSON over HTTP POST — это «скрещивание ежа с ужом», а HTTP over TCP, TCP over IP, IP over Ethernet — нет?Скрещивание это когда ты JSON кодируешь в поле формы, а не отправляешь в чистом виде.До чего забавно, вы так хотите этот JSON и имеете разные представления о том, как его надо передавать. Это так, к слову.> Я уже говорил, что пока не знаю, но не считаю, что это нужно запретить пользователю.Не надо сюда снова приплетать свой линукс вей, пожалуйста. Это уже выглядит как простое оправдание своей лени подумать.> А у клиента может и не использоваться.Что? Тогда сайт работать не будет, тут куча всего jQuery использует.> Как Гин пишет ниже — возможно.Возможно, но не нормально.
>>50013 >Однако JSON ещё и ручками вбивать надо. Данные в любом случае придется вбивать руками, будь то форма, будь то JSON. Даже если брать из файла, то все равно в файл надо будет вбивать руками. >Где тебе оно нужно ты так и не рассказала. Да я уже десять раз разъяснила про обновление. >спойлер Наверное потому, что у Хомуры php, а у меня python. На самом деле, разница между формой и json в питоне такова: форма: payload = {'field1': nujno, 'field2': toje_nujno} r = requests.post(url, data=payload) а json: payload = {'key1': nujno, 'key2': toje_nujno} r = requests.post(url, json=payload) Потому какой-то сложности в использовании json вообще не вижу. >Тогда сайт работать не будет, тут куча всего jQuery использует. Ну всякие дашчаны и прочие обходятся ведь без jQuery спокойно.
payload = {'field1': nujno, 'field2': toje_nujno}
r = requests.post(url, data=payload)
payload = {'key1': nujno, 'key2': toje_nujno}
r = requests.post(url, json=payload)
>>50021> Данные в любом случае придется вбивать руками, будь то форма, будь то JSON. Даже если брать из файла, то все равно в файл надо будет вбивать руками.Вот только форму вбивать гораздо проще, просто несравнимо.> Да я уже десять раз разъяснила про обновление.Для которого достаточно частного запроса. На этом список, видимо, заканчивается.> Ну всякие дашчаны и прочие обходятся ведь без jQuery спокойно.Мы вообще-то про JS до этого говорили. Если клиент (браузер) из-за каких-то нелепых побуждений юзера блокирует jQuery (через адблок, например), то сайт не будет нормально работать.
>>50013 >Однако JSON ещё и ручками вбивать надо. А форму разве нет? >но и его утверждение ни разу не доказано. У меня было не утверждение, а догадка, основанная на впечатлении от известного мне ПО. >спойлер О передаче его не в виде поля формы и возможности удобного распарсивания на php я узнал, пожалуй, только пару дней назад. Мне-то без разницы, как мне его передадут, я смогу схватить данные любым из этих трёх способов. >оправдание своей лени подумать. >лень >запилить три способа работы на выбор вместо одного У меня какое-то не такое представление о лени? >Тогда сайт работать не будет Я про абстрактный клиент на JS, не связанный с сайтом. Естественно, это гипотетический случай, и я его привёл как один из способов создания форм, который я знаю. Суть в демонстрации факта, что есть ситуации, в которых json делается проще, чем форма. >>50038 >Вот только форму вбивать гораздо проще, просто несравнимо. Ставить знаки равенства намного проще, чем двоеточия?
>>50097> У меня какое-то не такое представление о лени?Программирование — техника. Ты просто садишься и пишешь простой код как умеешь тем более когда дело касается простенького сайт на пхп, это больше «пролетарская» работа, вроде работы за станком. Тебе может не лень этим заняться. Включить голову и хорошо подумать, зачем ты что-либо делаешь, безусловно, сложнее, и тут уже включается лень.> есть ситуации, в которых json делается проще, чем форма.Конечно есть. JSON происходит от JS вот это поворот, который умел работать с ним с момента его создания.В общем-то, наличие таких ситуаций мало чего доказывает.> Ставить знаки равенства намного проще, чем двоеточия?А ещё скобки (как минимум 2), запятые, кавычки (ключи и строки).
Не знаю куда идти, спрошу здесь. Почему .онион ссылки через тор не открывает?
>>50259 потому что ты лох и всегда им был
>>50169 >Включить голову и хорошо подумать, зачем ты что-либо делаешь, безусловно, сложнее, и тут уже включается лень. У меня обычно наоборот, чем делать всё механически, я предпочитаю изначально найти какую-нибудь хитрость, дабы облегчить себе эту работу. Другое дело в том, что запиливать функциональность не так сложно, чтобы от этого вообще отказываться. >А ещё скобки (как минимум 2), запятые, кавычки (ключи и строки). Ну если для тебя это настолько тяжело — пользуйся формами, лол, я и то и то сделаю же.
>>50280> У меня обычно наоборот, чем делать всё механически, я предпочитаю изначально найти какую-нибудь хитрость, дабы облегчить себе эту работу.Хитрость это тоже механика, приобретаемая с опытом. А обосновать и доказать всегда тяжелее.> Другое дело в том, что запиливать функциональность не так сложно, чтобы от этого вообще отказываться.Дело не в том, сложно это или нет, а в том, нужно ли это. Ты думаешь, что нужно, а значит нужно передавать JSON, следовательно ты вводишь JSON. А когда тебя просят подумать, ты говоришь, что тебе просто несложно, хотя вопрос по-другому стоял.> Ну если для тебя это настолько тяжело — пользуйся формами, лол, я и то и то сделаю же.Я из тех людей, что любят строгость, а не разброс из множества вариантов работы с системой. Представь, появляется разработчик, читает документацию по апи и видит «а у нас можно и формы, и JSON, и JSON через формы». Реакцию «ух как круто, столько возможностей» это вызовет в последнюю очередь, скорее полное недоумение от того, что вы перенаворотили.Лично мне апи вряд ли понадобится, я просто хочу вас предостеречь, чтобы не получилась очевидная лажа.
>>49708 >Вообще не понимаю, почему клауда пытается кэшировать вот с таким убойным комплектом директив А ты присмотрись. Всё потому, что это всё не прилетает. Вот что пишет транспортный уровень HTTP:HTTP/1.1 200 OK Date: Sun, 29 May 2016 06:04:09 GMT Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive Set-Cookie: __cfduid=*ray_id*; expires=Mon, 29-May-17 06:04:07 GMT; path=/; domain=.kurisa.ch; HttpOnly X-Powered-By: PHP/7.0.7 Vary: Accept-Encoding X-Varnish: 1922183322 Age: 0 Via: 1.1 varnish Server: cloudflare-nginx CF-RAY: *ray_id* >Или ей наплевать, что запрос идет к .html, если он заканчивается 404? Ха. На уровне сервера изменяется ответ в результат 200 OK. И страница тоже весьма валидна, нигде нет кодов ошибки. По сути клауда вообще не знает, что там происходит 404. >А мой опыт кусабошатания говорит о том, что быстрее получается вытащить из базы сразу больше, но более простым запросом, а потом отсеять (если надо) уже в скрипте. А потому, что при таких мелких относительно уровня БД операций, самая дорогостоящая — собственно, сам запрос. Более того, на самом хостинге сервер БД может быть в большой нагрузке, и каждый запрос сначала ждёт очереди. >запрос элементарный: WHERE 'parentid' = $threadid, и всё (ну, ещё boardid, но он тут не важен). Я думал, ты подумаешь сразу над тем, как ему этот запрос выполнять. Хотя да, если у него бинарное дерево — это и вправду быстро. >Но это означает, что все, кто обновляет треды реже, чем в 20 минут (а это вполне нормально, если автообновление отключено) — пролетают с «красивым» механизмом автообновления, так? Хмм. Однако, тоже. Я уже рассчитывал на исключительно «постоянных» клиентов. Ну можно также и увеличить размер базы истории. Т.к. это в любом случае получается очень малая таблица. >первый спойлер Кажется, ты выкладывал. Так или иначе, не думаю, что это нужно. >написать if (isset($_REQUEST['json_data'])) $_REQUEST = json_decode($_REQUEST['json_data']) и дальше вообще не задумываться, каким образом прилетели исходные данные. А те, кто пишут клиенты, как хотят, пусть так и пишут. Чёрт, а это круто. Это же ассоциативный массив. И в него же тоже спокойно можно писать. Однозначно лучший способ. >В консоли оперы видны какие-нибудь сообщения? Консоль в Опере мини (О.О)>>49851 >Так ты серьёзно ежа с ужом скрестить собрался? Или пхп просто не умеет с другим форматом, отличным от форм, работать? >У нас jQuery используется, не надо никаких FormData и xhr. Голый JS вообще слабая штука. «Голый JS» может всё, что предоставляет браузер. Так что я просто подожду хоть какой разумной мысли. Кстати, тот же Meteor фреймворк спокойно пересылает JSON через вебсокеты. И всё это вполне внятно и удобно работает. Честно говоря, я вообще не понимаю твоих возражений. Особенно когда Хомура уже заявляет, что будет унифицированный интерфейс.>>49860 >Он парсится ничуть не медленнее формы, а уж маппятся они одинаково. Если кто смотрел в формат этого самого multipart/form-data, то понял бы, что JSON даже компактнее будет. Да и, кажется мне, его составлять и разбирать процессору даже проще.>>49863 >Зачем нам формы? Кстати, да. Также укажу, что они могут тоже вызвать затруднения у простых видов клиентов.>>49971 >подожди, она каждый раз всё грузит из инета, картинки там, всё-всё-всё? Нет, но она настолько облачная, что даже собственным кешем управление идёт с сервера Оперы. >А у клиента может и не использоваться. Вполне. Вообще скажу о вполне реальной возможности отказа от его использования.>>50013 >Спойлер Кажется, ты не понял. Унифицированность интерфейса говорит о том, что нет совершенно никакой разницы, прилетит этот JSON в форме, в POST'е, или вообще в GET'е. А ты строишь из себя дурака и смеёшься с этого. Если ты пытаешься сказать «Я против того, чтобы делали поддержку JSON потому, что он мне не понравился» — тебя послушают.>>50038 >Вот только форму вбивать гораздо проще, просто несравнимо. Вот это спорный вопрос, между прочим.>>50097 >Ставить знаки равенства намного проще, чем двоеточия? Лол. Но толстите.>>50281 >Ты думаешь, что нужно, а значит нужно передавать JSON, следовательно ты вводишь JSON. А когда тебя просят подумать, ты говоришь, что тебе просто несложно, хотя вопрос по-другому стоял. Объективно говоря, тут я с тобой соглашусь. Можно вполне написать так, чтобы это не было нужно. Но проще написать как сейчас. И ты забываешь, что на клиентской стороне такие же обычные кодеры. А ведь API пишется в первую очередь для них. >Лично мне апи вряд ли понадобится, я просто хочу вас предостеречь Кажется, можно вздохнуть с облегчением. Потому, что JSON действительно легко пристыковать. Будет не нужно — на начальном уровне, где входные запросы распределяются, можно будет всё удалить назад, и вот тебе один интерфейс снова. А будет это к лучшему или нет — уже время покажет.
HTTP/1.1 200 OK Date: Sun, 29 May 2016 06:04:09 GMT Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive Set-Cookie: __cfduid=*ray_id*; expires=Mon, 29-May-17 06:04:07 GMT; path=/; domain=.kurisa.ch; HttpOnly X-Powered-By: PHP/7.0.7 Vary: Accept-Encoding X-Varnish: 1922183322 Age: 0 Via: 1.1 varnish Server: cloudflare-nginx CF-RAY: *ray_id*
multipart/form-data
>>50290> «Голый JS» может всё, что предоставляет браузер.Какая разница, что он может, мы о другом говорили.> Особенно когда Хомура уже заявляет, что будет унифицированный интерфейс.Унифицированный интерфейс не есть хорошо.> Вот это спорный вопрос, между прочим.Абсолютно нет.> Но проще написать как сейчас.Ещё проще вообще ничего не писать, например. И написать, чтобы этого не было нужно, тоже проще. Проще, чем написать всё, конечно же.> И ты забываешь, что на клиентской стороне такие же обычные кодеры. А ведь API пишется в первую очередь для них.Клиентские кодеры предпочтут однозначность. Со стороны эта затея выгдядит абсолютно нелепой, гении линуксопрограммирования дорвались до веба и устроили беспорядок, зато получить посты можно аж 10 разными запросами. Знакомая карикатура? Это несерьёзный подход, люди с таким впервые столкнутся, потому что ни один нормальный веб-сервис себе такого не позволяет.
>>50294 Да, мысли есть. Разумные? Частично. Но мне придётся прекратить обсуждение. Я просто не в состоянии потянуть столько зелени.
>>50281 >Дело не в том, сложно это или нет, а в том, нужно ли это. Тем не менее, Гин, например, нужно. >А когда тебя просят подумать, ты говоришь, что тебе просто несложно Я подумал и понял, что людям надо и хуже при этом не будет. И заодно это несложно. >Я из тех людей, что любят строгость, а не разброс из множества вариантов работы с системой. Ну ты любишь одно, а кто-то другой любит другое. >Реакцию «ух как круто, столько возможностей» это вызовет в последнюю очередь, скорее полное недоумение от того, что вы перенаворотили. Если следовать такой логике, подобную же реакцию должна вызвать документация по любым стандартным библиотекам (или встроенному аналогичному функционалу) какого-нибудь языка программирования (вплоть до linux shell и содержимого /bin и /usr/bin, лол, если это можно так назвать). >>50290 >Всё потому, что это всё не прилетает. Да, я это уже увидел. Страаная очень вещь, надо будет разбираться... >По сути клауда вообще не знает, что там происходит 404. Да, я там немного не то написал — я имел в виду, что, возможно, сервер не выдаёт заголовки, если видит, что произошла 404. >А потому, что при таких мелких относительно уровня БД операций, самая дорогостоящая — собственно, сам запрос. >Более того, на самом хостинге сервер БД может быть в большой нагрузке, и каждый запрос сначала ждёт очереди. Вот-вот. >Ну можно также и увеличить размер базы истории. Вопрос — на сколько? Обооснованного ответа на него нет, всё равно придётся выбирать по какому-то критерию. >Т.к. это в любом случае получается очень малая таблица. Ну это зависит от времени хранения записей. Плюс, их надо оттуда удалять, а это означает, что кто-то должен этим заниматься (может, тот же, кто дописывает туда запись)... В целом, идея твоя мне понятна, хотя я пока и не думаю, что сейчас она решает какую-то насущную проблему. >Кажется, ты выкладывал. Да, я уже успел выложить графичек. =) >Однозначно лучший способ. Вот и я о том же. Очень красиво: вся унификация делается одной строчкой. >Консоль в Опере мини (О.О) Да, я, к сожалению, не имел дел с таким поделием сумрачного браузеростроительного гения, как Opera Mini, поэтому, я уже понял, что возможностей дебага с ней мне не видать... >И ты забываешь, что на клиентской стороне такие же обычные кодеры. А ведь API пишется в первую очередь для них. Да, именно эту мысль я и пытался донести до джейсонхейтер-куна. >>50294 >Унифицированный интерфейс не есть хорошо. WAT >Абсолютно нет. Ну уж точно не >просто несравнимо тяжелее ставить кавычки и двоеточия вместо знаков равенства, лол. >Клиентские кодеры предпочтут однозначность. Ты очень хорошего мнения о клиентских кодерах.
Я просто оставлю это здесь: https://habrahabr.ru/company/pvs-studio/blog/301736/
>>50421> Тем не менее, Гин, например, нужно.Нет, как оказалось, не нужно.> Я подумал и понял, что людям надо и хуже при этом не будет. И заодно это несложно.Я спросил, зачем это надо, где может понадобиться передавать массив в массиве. Теперь ты мне на это говоришь «ну, людям надо, хуже не будет». Мугичкой подумал?> Если следовать такой логике, подобную же реакцию должна вызвать документация по любым стандартным библиотекамВообще-то нет, не вызывает. Стандартные библиотеки как раз очень строги и однозначны.> Ну уж точно не >просто несравнимо тяжелее ставить кавычки и двоеточия вместо знаков равенства, лол.action=getposts&board=sg&thread=1488&after=3000против{"action":"getposts","board":"sg","thread":1488,"after":3000}Ощутимо сложнее, легко ошибиться, просто пропустив кавычку.> Ты очень хорошего мнения о клиентских кодерах.Не понимаю тебя. Чем однозначнее, тем проще разбираться, неважно, насколько хорош клиентский кодер.
action=getposts&board=sg&thread=1488&after=3000
{"action":"getposts","board":"sg","thread":1488,"after":3000}
>>50472 >Нет, как оказалось, не нужно. Может. всё-таки она решит, нужно ей или нет? >Я спросил, зачем это надо, где может понадобиться передавать массив в массиве. Теперь ты мне на это говоришь «ну, людям надо, хуже не будет». Зачем это надо — тебе уже написали выше. Передавать массив в массиве — это одна из возможных вещей, при которой преимущества JSON видны. >Вообще-то нет, не вызывает. Стандартные библиотеки как раз очень строги и однозначны. Угу, а потом появляются с десяток разных способов, к примеру, сделать какую-нибудь операцию со строкой или с массивом. Библиотеки на то и библиотеки, что предоставляют простой инструментарий, которым можно покрыть максимум типичных операций, и без перекрывания возможностей инструментов это невозможно. >Ощутимо сложнее, легко ошибиться, просто пропустив кавычку. Такая ошибка на сервере ловится автоматически. А вот ошибка, когда у тебя в запросе неэкранированные амперсанды, например, для сервера остаётся незамеченной. Не говоря уже о том, что конструировать строку запроса, включающую, например, пробелы, знаки вопроса, амперсанды, кавычки, слеши или тем более, русские буквы — гораздо сложнее, чем в JSON. Хотя я знаю, что ты на это возразишь: что-то типа если это с form-data сложнее, чем с JSON, значит, это никому не нужно! >Чем однозначнее, тем проще разбираться Клиенту не надо разбираться, клиенту надо выбрать максимально удобный для него путь.
>>50012 > В Opera Mini, судя по всему, консоли тоже нет, да? Конечно, нет. Это же просто терминал. Вся обработка на сервере происходит. > По окончании загрузки вызывается функция refreshCaptcha() и заменяет этот значок загрузки на сгенерированную капчу. Значит на прокси-сервере почему-то не выполняется скрипт и не подгружается капча. И чёрт знает, почему раньше подгружалась, если всё так же работало. Одним разработчикам Оперы это известно. Я, конечно, уже приспособился ходить за капчей на captha.php, но если у тебя будут идеи и время, чтобы улучшить совместимость Курисача с Оперой Мини, то было бы здорово.
>>50516 Анон, я п-пока буду капчу отключать и как спать ложится включать. Надеюсь тебе будет удобнее так.
>>50517 Благодарю. Хотя я с телефончика мало сюда пишу, не больше пары постов в день, в основном только читаю. Так что меня текущее положение с капчей почти не напрягает. Но если тебя не затруднит включать и выключать, то будет здорово.
>>50518 Там одну галочку поставить/убрать. Т-так что мне не трудно.
>>50516 >Конечно, нет. Это же просто терминал. Вся обработка на сервере происходит. Ну да, я примерно понял. Жалко, что такой подход, на самом деле, убивает любую возможность дебага, и потому очень тяжело узнать, почему так. >И чёрт знает, почему раньше подгружалась, если всё так же работало. Одним разработчикам Оперы это известно. Вот-вот. Я пока записал себе это как NEED INFO, если вдруг появятся какие идеи — постараюсь проверить.
Хомура, хорош шатать кусабу! Я не знаю, из-за тебя это или нет, но Оверчан (самая новая версия) тупо отказывается постить на Курисач. При любой попытке выдает либо стандартное failed to respond, когда теряет сеть, но чаще 301 — Moved permanently. Естественно, пост не отправляется. Что делать?
>>50537 Это из-за того, что оверчан пытается обращаться к Курисачу по http, его, естественно, перебрасывает на https, но вместо того, чтобы послать запрос на https, оверчан отваливается, считая, что если не 200 — то всё плохо. Нужно, чтобы кто-то собрал билд оверчана с https. Вообще, чем дальше, тем больше я вижу, что переход на https не решил ни одной насущной проблемы, зато принёс огромную кучу неудобств...
>>50545 Уже с-сделали. Судя п-по сообщением выше. >>48802
>>50546 А ведь и точно, значит, возможно, всё должно быть уже решено. Вопрос, получается, только в том, где взять этот билд (если Джинн говорит, что в самой новой транковой версии эта бага не исправлена).
>>50568 Мику ещё н-не выпустила новый патч. Говорят скоро будет.
>>50545В настройках можно принудительно использовать https(оно щас должно быть по дефолту, поэтому и работает). И вообще в чем смысл было перебрасывать на https, сидели бы кто хотел на http и не парились.
>>50759
>>50596 >И вообще в чем смысл было перебрасывать на https, сидели бы кто хотел на http и не парились. Ну, тут выше требовали, чтобы был https и только https, лол.
>>50797 Толку от данного хттпс никакого по сути. Он от клиента до клоды, дальше у вас уже нет сертификата.
>>50799 Ну я тоже не получил вменяемого ответа на вопрос «какие проблемы решит https», кроме аргументов типа «меня будет сложнее выследить». О том, что это расшатает сам Курисач и отвалятся мобильные клиенты — я не очень подумал.
>>50504> Может. всё-таки она решит, нужно ей или нет?Она огласила, что нужно. И для этого эта функциональность не нужна.> Зачем это надо — тебе уже написали выше. Передавать массив в массиве — это одна из возможных вещей, при которой преимущества JSON видны.Нет, не возможных, пока не показано обратное. А больше преимуществ ты мне не назвал.> А вот ошибка, когда у тебя в запросе неэкранированные амперсанды, например, для сервера остаётся незамеченной.Вот только ошибиться с кавычками проще — достаточно случайно недожать клавишу.> Не говоря уже о том, что конструировать строку запроса, включающую, например, пробелы, знаки вопроса, амперсанды, кавычки, слеши или тем более, русские буквы — гораздо сложнее, чем в JSON.Хочется опять задать вопрос — зачем это нужно? Где будут такие запросы, где такая информация будет передаваться? Я вижу только отправку поста, однако, сейчас для этого используется иное кодирование без необходимости экранировать что-либо, к тому же передавать файлы в JSON это вообще пиздец. А в остальных случаях твой аргумент инвалид.> Хотя я знаю, что ты на это возразишь: что-то типа если это с form-data сложнее, чем с JSON, значит, это никому не нужно!Всё верно, абсолютная истина.> Клиенту не надо разбираться, клиенту надо выбрать максимально удобный для него путь.И максимально удобным будет тот, к которому он привык. И ты знаешь какой.
>>50901 По-моему мы ходим по кругу. Ты уверяешь, что Гин не нужны её реквесты, она утверждает, что нужны. Мне кажется, более обоснованно сделать, что просят, чем сопротивляться, если это несложно. А ещё, думается мне, мы больше тут размышляем над тем, делать или не делать, чем нужно времени на то, чтобы удовлетворить всех, написав-таки эти несчастные две строчки. >Нет, не возможных, пока не показано обратное. Вот именно из-за этого обычно получается нерасширяемая и бесполезная ерунда вместо хорошего развиваемого проекта. >Вот только ошибиться с кавычками проще — достаточно случайно недожать клавишу. В результате ты получишь ошибку, взглянешь на запрос у отправишь уже исправленные данные. А вот в случае с амперсандом, в базу может записаться (или тебе выдаться) совсем не то, что надо. Это гораздо хуже, чем ошибка в предыдущем варианте. >Где будут такие запросы, где такая информация будет передаваться? См. выше. >Всё верно, абсолютная истина. Лол, тогда у меня нет комментариев. Поиск текста, например, типа, не нужен. Ок. >И максимально удобным будет тот, к которому он привык. И ты знаешь какой. Например — JSON.
>>50934> Вот именно из-за этого обычно получается нерасширяемая и бесполезная ерунда вместо хорошего развиваемого проекта.Только у дилетантов, не умеющих грамотно планировать. Зачем тогда вообще браться за что-то серьёзное вроде реализации апи — не понятно.> А вот в случае с амперсандом, в базу может записаться (или тебе выдаться) совсем не то, что надо. Это гораздо хуже, чем ошибка в предыдущем варианте.У нас только один запрос редактирует базу, в которым можно ошибиться подобным образом, и там иное кодирование вообще. Так что нет, не хуже.> См. выше.Ссылку.> Лол, тогда у меня нет комментариев. Поиск текста, например, типа, не нужен. Ок.Для тестирования поиска текста я буду искать очень простой текст. И точно не захочу пользоваться пост запросами для этого. А ещё поиск не модифицирует базу.> Например — JSON.Крайне неумелый манёвр. Назови мне хотя бы парочку сайтов, которые принимают данные в JSON. Даже если ты можешь назвать эту парочку — я на каждый из них найду несколько десятков, где используются формы. Ну ты понял, что тут на самом деле привычно.
>>50965 >Только у дилетантов, не умеющих грамотно планировать. Таких дилетантов почему-то 99%. >У нас только один запрос редактирует базу >Для тестирования поиска текста я буду искать очень простой текст. >не захочу пользоваться пост запросами для этого. >поиск не модифицирует базу. Ты всё время сваливаешься на частности. Если уж так говорить, давай, поругайся на Javascript, что в нём есть JSON.stringify() и на PHP, что в нём есть json_decode(). Ведь по твоей логике не просто можно, а необходимо обходиться без парсинга JSON на сервере и создания JSON на клиенте. >Назови мне хотя бы парочку сайтов, которые принимают данные в JSON. Не интересовался этим вопросом, поскольку не вижу проблем в реализации парсинга JSON. Я изучать эти сайты буду дольше, чем делать API, лол. >я на каждый из них найду несколько десятков, где используются формы. Ну, естественно, формы популярнее JSON. Но это не отнимает у последнего право на жизнь. >Ссылку. Да в треде выше я на этот вопрос неоднократно отвечал. Вообще, давай начнём с того, что ты от меня хочешь. Ты хочешь, чтобы я сделал возможность передавать данные только в form-data и никак иначе? Это не решит ни одной проблемы, а возможностей будет меньше, так что не катит.
JSON.stringify()
json_decode()
Нет, я не забила, продолжаю потихоньку делать, хотя прогресс маловат.
Прикрутила картиночки в свое кривоподелие.
Картинки теперь можно открывать (в отдельном окне).
После отправки поста получается эффект, будто страница обновилась. Отбрасывает вверх. Отправка через javascript включена. Выключаю — всё так же. Браузер Chrome 51.0.2704.106 m (64-bit).
>>54123 Решилось
>>51886 Няшечка, а можно с пика минипик нумер 12 который, в хайрезе же? Не шакальничай тока, чур, оставайся няшкой же^^
Я всю историю появления Курисачя проспал, его Клара с Девятачя создал?
>>55186 Н-насколько мне известно, Клара Курисач отдельно запилил.
>>55215 Есть отдельный Курисач? Я про этот. Помню у них отдельный дизайн был, вот и подумал что это Клара его создал, он сейчас во главе?
>>55295 Не, тут в том смысле, что Курисач не являлся филиалом девятача. А если ты именно про Клару, а не про девятач, то вроде бы да, он к девятачу имел изначально отношение. Потом, правда, самоустранился от дел и отдал Курисач Ханако а потом передумал и решил его вернуть, но это отдельная часть Марлезонского балета, да, и вот теперь Курисач таков, каков есть.
>>55301 И где Клара сейчас? Ущёл на пенсию от парашеводства?
>>55488 Скорее всего д-да. А так думаю никто кроме него не знает.
>>55511 Опять это проклятая картинка.
>>55530 Она к-красивая. Хоть и грустная.
У нас серьезные проблемы с автообновлением.
>>55644 Хм. Какие? У меня всё работает. Что не так?
>>55731 Если в т-тред зайти через [Последние 50 постов] начинаются проблемы.
>>55761 Не только.
>>55763 А что ещё?
>>55761 А, ну это известная вещь, да. Всё пытаюсь выкроить время для починки, лол, только всё некогда...
Все еще не работает автообновление треда.
>>56507 Р-работает же. Ну у меня п-по крайне мере.
>>56508 Не работает.
>>56509 С-странно у меня работает. Какой у тебя браузер напомни? И попробуй новый метод. Смайлофаг сказал, что починил его
Не работает удаление недавних постов по паролю.
>>56546 П-попробуй свой пароль там прописать. А не тот который генерируется
Кстати, вот это >>55852 я уже починил. >>56507 Как именно оно у тебя не работает? >>56546 Да, попробуй, что предлагает Ханако в >>56550, а еще можешь попробовать почистить куки и LocalStorage. Алсо, убедись, что в графе «пароль» в постбоксе при отправке поста, и в графе «пароль» рядом с кнопкой «удалить пост» одно и то же. Естественно, если у тебя браузер чистит куки, то если ты не сохраняешь пароль, то он каждую сессию генерится заново, и ты не сможешь тогда удалить пост из предыдущей сессии. Единственное решение в этом случае — сохранять пароль средствами браузера или ручками вписывать в каждое поле.
>>56553 Должен был быть один, прописанный вручную. Ну ладно. Автообновление у меня со старым методом не работает. Кстати, Хомура, может нам сделать смайлики таблицей? Или хотя бы не крутить скроллер как сейчас, а кликать вниз/вверх. Как в ворде выбор тех же стилей. И ты так и не починил форму отправки. Она все также передвигается (с кучей лагов) с помощью клика.
Открываю тред на последних 50 постах. Отвечаю в тред и меня отправляет в тот же тред но уже полностью развёрнутый. Почему не снова в последние 50 постов?
>>56562 >Должен был быть один, прописанный вручную. Это возможно, хоть и сложно, но нужно ли? Проблема с новым паролем после чистки кук от этого не исчезнет. >Автообновление у меня со старым методом не работает. Да я понял уже, а как именно не работает? Например: «не идут секунды», «не подгружает новые посты, хотя они есть» и т.п.? >Хомура, может нам сделать смайлики таблицей? Так у нас было таблицей, выяснилось, что оно много места занимает. >Она все также передвигается (с кучей лагов) с помощью клика. А как ещё её перетаскивать, кроме клика? А про кучу лагов — так таковы издержки яваскрипта, лол. >>56565 Хм, да, логично. Надо будет поправить. Записал в списочек, гляну, как вернусь.
>>56630 >Это возможно, хоть и сложно, но нужно ли? Проблема с новым паролем после чистки кук от этого не исчезнет. Мне показалось, что слетел установленный мною вручную пароль. >Да я понял уже, а как именно не работает? >«не подгружает новые посты, хотя они есть» Сам все понимаешь. >Так у нас было таблицей, выяснилось, что оно много места занимает. А вот на оставшееся ты внимание не обратил. >А как ещё её перетаскивать, кроме клика? То есть без лагов нельзя? Понятно. А если сделать отдельный элемент для перетаскивания (прямоугольничек, например) это ситуацию не изменит?
>>56646 >Мне показалось, что слетел установленный мною вручную пароль. Ну так введи ещё раз, браузеры иногда шалят. >Сам все понимаешь. Лол, вероятно, парсинг сломался. Новый метод работает? >А вот на оставшееся ты внимание не обратил. Ну вроде бы, раньше никому не мешало. =) >То есть без лагов нельзя? Ну я не то, чтобы разбирался, но у меня лагает не так сильно. Если это прямо проблема, могу попробовать посмотреть, но ничего не обещаю. >А если сделать отдельный элемент для перетаскивания (прямоугольничек, например) это ситуацию не изменит? Боюсь, нет — проблема в перерисовке элемента с position: absolute. Ладно, побегу я уже, пожалуй. Буду смотреть/чинить потом, в августе. А сейчас собираться и спать.
>>56630 Может быть тут когда-нибудь станет удобно.
>>56649 После удаления постов галочки остаются.
Перекатывайтесь с этого хостера На one.com низкие цены и год халявы — это конечно хорошо, но вы не одни такие умные. На одном серваке с вами куча сайтов. Процентов 90 из них на дырявом вордпрессе, можно ронять базу по кд, по типу того, что было в мае. Заплатить 4 бакса в месяц за не самый плохой wps не так уж много, по сравнению с безопасностью борды.
>>57914 Да, к-как раз собираемся переезжать
>>58445 Уже нашли хостинг? На https://lowendbox.com/ есть вкусные тарифы. Вплоть до 15-20$ в год за достаточно неплохие сервера. В продакшон их конечно нельзя, но для борды более чем достаточно. Вот, например. https://lowendbox.com/blog/dedistation-ddos-protected-openvz-vps-starting-15year-london-uk/
>>58496 П-пока нет. Большое с-спасибо за примеры.
Привет всем админам и посетителям Курисача! Завтра стартует наша имиджборда Хорахорач. Предлагаем обменяться ссылками, записать друг друга в «список друзей». Сорамимики MPT Ю-тян, Хохоеми-кун и Прорицатель.
Хома, када па несколько картинок в посте можна буде делати же?
>>56780 А чем сейчас неудобно? >>57524 Ок, записал. >>57914 Это в планах, как будет время — перекатимся, думаю. >>58496 О, спасибо за инфу. >>59094 Лол, у Ю-югенда новое название. =) Таки-где этот ваш хорахорач-то? Хоть посмотреть, что из того начинания получилось, лол. >>59374 Таки вроде как-то решили, что такая функциональность не нужна, остановились на видео+картинке, не более.
>>59642 Хорахорач — http://hohoemy.exach.com
>>60252 Заценил. Лол, почти 4к гет-то брать будете? — is a serious power. Как, Ханако, не возражаешь относительно предложения в >>59094 ?
>>60262 Д-да, пусть будут.
>>60277 И где вы нас разместили?
Тест
>>60375 Не спеши. Будет ссылка в фрейме.
>>60383
>>60386 Ох, лол! Т-ты сделал мой день.
>>60262> Заценил. Лол, почти 4к — is a serious power.Да какие 4к. Там нумерация постов вручную была вправлена, виден резкий скачок с ~200 сразу на ~3800.
>>60390 Кстати да, счётчик просто подкручен на 3500 постов.
>>60394 Вообще-то нас вайпали. 8-го августа утром.
>>60252 Всплывающие посты криво сделаны.
Предлагаю отключить поле «Имя». И сменить ужасную капчу.
>>60951 А ч-чем тебе поле Имя не нравится? Насчёт капчи п-посмотри в настройках Simple
>>60386 Лол, так проиграл с этой картинки, что немедленно выпил запилил ссылку. >>60951 Полем «Имя» многие пользуются, а капча — лучше такая, чем всё время выбирать всякие деревья и машины, например, или на которую ломалки распространены.
На всякий случай я просто оставлю очередной дамп трекера здесь. — длинные скрипты в админке вызываются два раза (minor) (hard) — DELAYED (таких скриптов уже нет; а вообще проблема сервера, если решим переехать — починим) — есть проблемы с символами utf8mb4 (minor) (hard) — DELAYED (похоже, проблема сервера, если решим переехать — починим) — превьюшки вембок генерить (minor) (hard) — DELAYED (проблема сервера, если решим переехать — починим) — «https://kurisa.ch/sg» переводит на «http://kurisa.ch/sg/» (minor) (hard) — DELAYED (проблема сервера, если решим переехать — починим) — сделать https от клауды до Курисача (minor) (easy) — DELAYED (проблема сервера, если решим переехать — починим) — анимированные превьюшки, выключенные по дефолту (minor) (medium) — DELAYED (на сервере нет ImageMagick) — (NEW) в опере мини не грузится капча (major) (hard) — NEED INFO (путь решения неизвестен) — если нет куков, отдаются просроченные страницы (normal) (medium) — NEED INFO (теперь страницы генерятся динамикой; проверяйте, не починилось?) — при некоторых условиях пропадает трипкод и имя (minor) (medium) — NEED INFO (не могу воспроизвести; нужна инструкция по воспроизведению бага) — превьюшки генерить только в формате jpg (minor) (medium) — CANCELLED (всё-таки я подумал и решил, что лучше оставить, как есть: у нас слишком много png-превьюшек с прозрачностью, а также не каждый png весит больше jpg). — видео+картинка (major) (hard) — DONE — (NEW) микуоверчани н-не отправляет посты и пишет ошибку 301 (major) (hard) — CANCELLED Разработчику микуоверчана надо переправить http на https. — проверка размеров заливаемых пикч (major) (easy) — DONE — (NEW) поправить поиск — проценты дописать в запрос (major) (easy) — DONE — vimeo не отображает превьюшки видео (minor) (medium) — DONE — картинки, похоже, разворачиваются больше, чем надо (minor) (medium) — DONE — выпилить создание каталожных тамбнейлов (minor) (easy) — DONE — (NEW) картинка вылезает за край (minor) (easy) — DONE — (NEW) отдавать 404 на +50 и -100, где их нет (normal) (easy) — DONE — ускорить статистику в админке (minor) (easy) — DONE — автообновление косячит в режиме «последние 50 постов» и «первые 100 постов» (normal) (medium) — DONE — (NEW) ссылка на хорахорач во фрейме (minor) (easy) — DONE — (NEW) пикчу на страницу «ничего не найдено» (minor) (easy) — DONE (спасибо Рейму!) — сделать отправку по Ctrl+Enter настраиваемой (normal) (hard) — (NEW) допилить мобильный интерфейс (normal) (hard) — из превьюшек удаляются карты ответов при автообновлении (normal) (medium) — (NEW) в Microsoft Edge капча не грузится (normal) (medium) — разворот поста и всплывание меняет номер на 1 (normal) (easy) — скрытие постов по имени, тексту поста (minor) (hard) — сделать переключение английского и русского интерфейса (minor) (hard) — делать API для Суигинто [$_REQUEST, два вызова, thumb height, width] (minor) (hard) — (NEW) лагает при перетаскивании формы ответа (minor) (hard) — без капчи посты с куклы отправляются два раза (minor) (medium) — откуда-то лезет скроллбар и почему-то превьюшка вылезает за край (minor) (medium) — спойлеры картинок (minor) (medium) — cделать отдельно однопоток постов как на хорочане или как на хайбане (minor) (medium) — сделать улучшенный хеш для бана, чтобы он высчитывался без последних 2-5-10 байт (minor) (medium) — фрейм колбасит (см. пост 42066) (minor) (medium) — чтобы был и диалог открытия и превью по клику на зоне «перетащи файл сюда» (minor) (medium) — скрытие отдельных постов, навроде кнопочки скрытия треда, только для постов (minor) (medium) — сделать, чтобы предпросмотр закрывался при отведении мышки (minor) (medium) — разворачивание поста на предпросмотре со страницы борд (см. пост 46341) (minor) (medium) — (NEW) при автообновлении пропадает карта ответов у постов не из этого треда (minor) (medium) — предпросмотр поста не закрывать при клике по кату (minor) (easy) — предпросмотр поста при правке глючит (minor) (easy) — шрифты захостить локально (minor) (easy) — (NEW) в поиске сделать, чтобы текст пропадал при клике (minor) (easy) — (NEW) в стиле Tomorrow не видны чёрточки, которые Рейму ставит (minor) (easy) — (NEW) ответ в +50 или -100 отправляет в тот же тред, но уже полностью развёрнутый (minor) (easy) — (NEW) после удаления постов галочки остаются (minor) (easy) Проверьте, ничего из реквестов не забыл? Алсо, Ханако, кинь сюда реквестики из конфочки, ок?
>>61494 Т-тут вроде все реквесты.
Ребята, а выложить исходники движка вы можете?
>>61640 А з-зачем тебе?
>>61640 Теоретически, я не вижу в этом проблемы — кусаба-таки открытое ПО, а если оно под лицензией GNU или подобной, то наши (и не наши) доработки (кусаба Х — кусаба-нульчан — курисаба) тоже дожны являться открытыми впрочем, в этой стране GNU юридической силы внезапно не имеет, хотя, конечно, это не повод её нарушать налево и направо. С другой стороны, код у нас пока весьма грязен стыдно показывать лол, да и баги, которые в нём могут быть, могут побудить мамкиных хацкеров попытаться дропнуть нам базу или снести какие-нибудь важные файлы, ничего не говоря. В общем, думаю, когда-нибудь, в светлом будущем, наверное, мы его-таки выложим (впрочем, конечно, если Ханако не против, то можно попробовать его выложить когда угодно, ладно уж). Капча «ЗОРЯНКИ». Это вроде птички такие. Интересно, к чему бы это?..
>>61691> а если оно под лицензией GNU или подобной, то наши (и не наши) доработки (кусаба Х — кусаба-нульчан — курисаба) тоже дожны являться открытымиНет. Если ты форкаешь жопаельное ПО и модифицируешь его, выкладывать код модификации ты не обязан. Только в случае если ты будешь её распространять, ты обязан это делать под жопаелью и, как следствие, прилагать исходники.Так вот, ты не распространяешь движок. Ты его форкнул и ты просто пользуешься форком, никто тебя не может обязать твой форк открыть. Использование ПО на публичном сервере != распространение ПО. А вот если ты его решишь открыть — то тут да, только жопаель.
>>61845 Хм, а кстати, да, верная мысль, я как-то не задумывался, что использование — не то же самое, что распространение. Не, ну то есть, это очевидно, но иногда бывает, что очевидные факты, возможно, из-за своей очевидности, как раз упускаются.
>>48357 Админяши, по какому адресу вам писать e-mail?
>>61927 >Админяши, по какому адресу вам писать e-mail? Насколько понимаю, akemi_homura@kurisa.ch
>>61929 Спасибо, няша, но я подожду официального ответа. Тортика вам!
>>61927 П-привет, Ю-тян. Как Смайлофаг з-зайдёт на Курисач думаю сразу же сообщит насчёт почты.
>>61939 А по вышеуказанному адресу писать нельзя?
>>61991 Можно.
>>61998 Хомура-нян! Тебе письмо!
А «разворачивать картинки до исходного размера», это же в полном размере когда?
>>62104 Д-да.
>>62063 Хомура-нян?
>>61865AGPL кстати обязывает выкладывать код даже если модификация используется на публичном сервере. А вот обычный жопаель — нет.
>>62123 >Хомура-нян? Ну, постой-постой. Я, например, последние пару дней от него не слышал никаких вестей вообще. Возможно, работы много или ещё каких дел.
>>62119 А у меня не работает.
>>62063 И ещё одно письмо!
>>62178 Если ты шёлкнешь по большой картинки, то там будет написано что-то вроде: «Картинка ужата на N% по размеру окна» и если ты поставишь галочку на: «Разворачивать картинки до исходного размера» то картинка будет Разворачиваться в полный размер. Или у тебя это не работает?
>>62222 Не работает
>>61929 В принципе, правильно понимаешь. =) >>62123 Да, до почты я добираюсь редко, плюс тут была совершенно сумасшедшая неделя, так что сорьки за ожидание. Вот и Рейму >>62133 правильно говорит. >>62247 Хм... Какой браузер, стоит ли кукла, на каком именно посте это не работает, например? Да, само собой, что разворачиваться больше размеров экрана будут только те пикчи, которые его больше, лол.
>>62355 Ничего страшного, няша. Иногда и у самой завал. Я там тебе ссылку выслала. Жду.
>>62523 Но у меня она почему-то не подсоединяется. Connecting to host, please wait — и всё.
>>62585 Теперь всё должно работать. Попробуй по новой ссылке.
>>62687 Как ты, Юно?
>>62687 Хм. Где? Мне ни в скайп, ни в почту ничего не прилетало. Капча ОТЛОЛ, лол.
>>62766 Великолепно, няша. Раны затянулись. Стала четверокурсницей. Погода на улице тоже радует. Всё складывается хорошо. >>62783 Я писала в скайп, но, если не пришло, напишу и на почту. Вам добра и тортик!
>>62783 Всё, отправила по мейлу. Только воспользуйся ссылкой поскорее — Скайп глючит и время от времени меняет ссылки!
Хомура-нян!...
>>62844 Попробовал вчера ночью — то же самое =( Там не нужно, например, чтобы оба были в онлайне? Я в скайпчике бываю в рабочие дни примерно с часу до четырёх часов ночи.
