>>13107
WAD?

>>13107
Генерировать html-ку по темплейту и записям из базы? Отлично подходит. Ты что, freeport7 не видел? Тут любая скриптота подойдет, вообще-то.

>>13108
>>13109
У руби очень сильные проблемы с производительностью. Для борды на три человека ещё терпимо, но при серьёзной посещаемости не очень производительный руби вместе с тяжёлыми рельсами лягут на раз. Это вообще не то для борд. Там нужна асинхронность, быстрота и возможность тонкой настройки, а рубирельсы - предмет для быстрого и несложного клепания одинаковой фигни.

>>13112
Руби хоть и тормоз, но на борде странички необязательно каждый раз перегенерировать заново. Если юзать нехитрое кэширование, будет вполне шустро. Хотя лично мне питон больше нравится. Или сейчас модно go. Или nodejs, если жабоскрипт отвращения не вызывает. Каждый анонимус должен раз в жизни написать свой недоделанный движок борды. Поставить на локалхост и разговаривать с ним.

>>13114
>если жабоскрипт отвращения не вызывает
А почему он должен вызывать отвращение? Всяко лучше рубисинтаксиса для умственно отсталых.

>>13116
Попиши - узнаешь.

>>13112
> но при серьёзной посещаемости не очень производительный руби вместе с тяжёлыми рельсами лягут на раз

Ох уж мне эти делрнисты. Вы прям один и тот же сапог из набора для одноногого инвалида с чуваками, которые угорают по дерьму вроде ORM и эрэнэр "фреймворкам". Есть у меня сейчас небольшая программка, для учета клиентурки и распределения оной по специалистам. Написана на делрни. Так вот, она умудряется тормозить (запросы могут обрабатываться до 30 секунд) на мускуле под который отдано 2ГБ оперативки (сама мускульная базка целиком занимает 300МБ). Это я к тому, что затормозить и можно что угодно. Когда делрнисту дают кластер из сверхпроизводительных машин который он не сумеет стопорнуть своим говноделрни, он просто начнет хуячить в бесконечном цикле форки которые будут порождать другие форки.

>Там нужна асинхронность, быстрота и возможность тонкой настройки

Чел, ты ударился об что-то? 90% любого сайта - статика, которую гененируют не со скоростью 60 кадров в секунду. Как можно говорить о том, что руби на рельсах поляжет под нагрузкой, когда вся эта нагрузка будет сводиться к записи некоторого количества информации в СУБД и перегенерации html кэша? У меня ощущение что эрэнэр у тебя не ложится, просто потому, что это говно уже давно в курсе что за дегенераты на нем пишут и поэтому просто само уже хранит где-нибудь у себя внутри сгенереный html-кэш которым плюется в ответ на типовой запрос.

>>13112
>>13116
Вы из-за Ruby работу потеряли, что ли? Или он покусал вас?

На питоне, или на жажаскрипте.

А почему никто не предложил PHP? Сплошная илита в треде. Простеньку борду на PHP за пол дня набросать можно.

>>13168
>простенькую
Да уж у альтерчана-то побольше функционала, чем у ваших голых сырначей.

>>13168
>А почему никто не предложил PHP?

Очевидно, что мы добрые люди и не хотим, чтобы ОП наживал геморрой со страусиное яйцо и седел обеспечивая работоспособность монстра.

>>13112
А у перла нет?
Вот, например, голая вакаба: http://openchannel.tk/b/
Крутится на SoC с одним ядром ARMv6 700 МГц и 512 Мб ОЗУ.

>>13173
Перловая каша считай что мертва уже. Что бы там не восторженно проповедовали о Rakudo, оно уже отжило своё. И самому добровольно подписывать себя на мучения с полумертвой технологией, к тому же, перла ты не знаешь. Как-то недальновидно. Баги, уязвимости не пофиксишь, функционала не расширишь.

>>13173
Угу, с 3,5 постами. Как только там наберётся хотя бы с тысячу, то база начнёт скрипеть и заваливаться. Был у меня аналогичный "сервак", но не с ARM, а со старенькой целкой.

Кстати, про скорость, PHP7 никто ещё не пробовал? Грят же летает всё, вроде бы...

>>13185
"Ускоряется" не эрэнэр, а железки которые его тягают. И именно поэтому создается ложное впечатление.

>>13184
> Что бы там не восторженно проповедовали о Rakudo
Как говорят разработчики, в декабре 2015 года таки выйдет полноценный официальный стабильный релиз Perl 6. Ждать осталось недолго.

>>13075
>простенькую
Если это ключевое слово, то на php. Однозначно. Точнее на html с внедрёнными php-тегами. У многих стул прожжётся до подвала, но ты никого не слушай, ведь тебе главное простенько.
Занятие на пару часов даже для нуба. Один вечер максимум. Если будет суммарно занимать больше сотни килобайт - отруби себе руки.

>>14239
> имиджборд на html с внедрёнными php-тегами
Та ну, бред. Это невозможно. Можешь мне продемонстрировать и запилить вот такую вот простенькую борду.

>>14291
> продемонстрировать
Коли каждому демонстрировать, никаких сил не хватит.

Что ты видишь тут невозможного, я не знаю. Вместо бд — текстовые/json файлы, а один и тот же php файл может обрабатывать и POST и GET запросы (постинг / просмотр тредов).
Можно пойти даже ещё дальше и php будет только складировать ввод в файлы, а весь редеринг перенести на клиент.

>>14295
Ну так сделай такую борду и выложи на гитхабе, чтобы я мог себе лучше представить как она работает на практике, а также поковыряться в ее движке.
> Коли каждому демонстрировать, никаких сил не хватит.
С чего бы каждому? Ты просто ее запилии выложи на гитхабе, а потом можешь просто ссылочку на нее давать всем, кто не верит, вроде меня.

>Напиши мне АИБ чтоб продемонстрировать фишку
>Нет ты
>и выложи на гитхабе с пруфами
Ну вы даёте...
>>14295
Зачем так извращаться? В php работа с базами данных простая как кирпич положить. Нет, можно конечно, но тогда придётся вручную сочинять структуру хранения данных. И не факт что без опыта это удачно получится.
>имиджборд на html с внедрёнными php-тегами
>весь редеринг перенести на клиент
У меня с ваших камасутроидей мозг речным членистоногим встаёт. Какой язык вы упарывали, что теперь только так можете думать?

>>14299
> В php работа с базами данных простая как кирпич положить
Ага, и с расбросанными по пути граблями от проблем с UTF и до всяких инъекций.
> Нет, можно конечно, но тогда придётся вручную сочинять структуру хранения данных
JSON уже "сочинён".

> камасутроидей
Насёт первого человек очевидно перепутал местами, и должно быть имел ввиду «PHP-файл с HTML-тегами внутри», каковую кашу и представляли собой обычно все похапе-приложения. Это сейчас развился более верный подход с шаблонизаторами и MVC…

Второе же — рендеринг на клиенте — это реалии современного веба. Angular, SPA, нет, не слышали?

Откуда такое стремление сделать из задачки для школьника кусабамонстра с ООП и библиотеками? И клиентской частью в виде контрольного. Зачем тогда PHP? Пишите на Си.
>>14313
>с расбросанными по пути граблями
Не преувеличивай проблему.
>JSON уже "сочинён"
А сами файлы просто в кучу валить?
>Это сейчас развился более верный подход с шаблонизаторами и MVC
>шаблонизаторами
>на PHP
Пихапе сам один большой шаблонизатор блджад! И функций встроенных в нём до морского ктулху напичкано именно для того, чтоб люди фреймворки свои не пилили, а готовыми как на JQery пользовались. Человек явно попросил простого способа. Нет, давайте зубы лечить через кактус.
>рендеринг на клиенте — это реалии современного веба
>современного веба
>PHP
Выберете что то одно.

я думаю это руби, питон, пхп и тд...

я пишу на перле борду так как проще.

Пробывал поглядывать в вакабу, то там такой мрак, что начал поглядывать в кусабу на пхп.

щас думаю над тем как лучше банить пользователей, и абузо трекер запилить.

>>14380
Зря поглядываешь. Чел её походу ради лулзов с будущих батхёртов писал.

>>14382
Ычую.

>>14380
Еще один модераст растет.

>>14382

Я только реализацию кусабы-марка подсмотрел. там она на регекспах.

реализацию Вакабы-марк у вакабы просто не читаймая(точнее парсинг постов), несмотря на то что она на перле. С двощей подсмотрел Рефлинки, и стиль, и сам двощ-марк

Все остальное велосипеды собственной конструкции. Щас пилю велосипед чтобы можно было хранить безлимитное(ну практически, и с оговорками ) количество файлов, на бесконечном( правда денег у меня не хватит ) количестве серверов, с дупликацией файлов, и тогда можно будет не запиливать автоудаление тредов, и вообще сделать треды бесконечными™ хотя я не уверен что оно заработает как надо, так концепт оф пруф

>>14386
Ты на бесконечность сразу не замахивайся. Иначе переполнение буфера схватишь.
>несмотря на то что она на перле
Так это же вроже фишка перла? Нет? Я правда не смотрел ещё.

>>14387
>бесконечность
ну пока ботленек не словлю, где-нибудь.

>Так это же вроде фишка перла
к сожелению да, оно позволяет писать очень "свободно".
Я порой хочу пожать руку создателем Го, и Гвидона, зато что они пресекают такое рукоблудие как в перле и рубях.

>>14380
На Джаве пиши же.

Пишу новый лучший(тм) движок на ноде, в качестве БД Монго, так как его с нодой чаще всего используют. Возник вопрос по топологии БД. Проблема заключается в следующем: в обычных SQL-движках каждый пост имеет свойство parent, в котором хранится id оп-поста, у оп-поста parent 0, так движок знает, что это тред.
Проблема с монго в том, что если для генерации страницы нужно получить например 10 тредов и для каждого треда по 5 последних сообщений, то получается нужно делать 11 запросов. С другой стороны, если в оп-посте будет массив со ссылками на ответы, то операция намного упрощается, но тогда при удалении отдельного поста надо будет не забывать удалять его id из этого массива.
Кто ставил себе LynxChan или другие движки с mongo, как там выглядит база?

>>18234
Казалось, я где-то слышал, что в NoSQL-базах принцип организации обратный обычному и в родительской сущности хранят ссылки на дочерние, а то и вовсе их целиком.

>>18234 >>18235

Выбирать хранилище Mongo лучше в том случае, если в голове есть готовая NoSQL-схема хранения своих данных.

Если её нѣтъ или если не удаётся избавиться от ощущения, что с SQL-базой и SQL-запросами было бы гораздо проще управляться с этими данными (а запросы NoSQL выглядят какими-то непростыми), то тогда не надо ломать традиции, а надо продолжать оставаться на SQL.

Хотя Mongo действительно обладает популярностью как хранилище данных, никто никого не принуждает употреблять его под Node.js; всё даже наоборот: в npm можно отыскать готовые пакеты, поддерживающие буквально какую угодно систему управления базами данных, хоть NoSQL, хоть SQL. (В случае клиент-серверных систем это клиенты, а в случае бессерверных систем это джаваскриптовые обёртки вокруг API.)

Если для борды не планируется с самого начала посещаемость, превосходящая 100 000 — 1 000 000 загрузок страниц в сутки, то я бы вообще не стал городить клиент-серверную систему (с выделенным сервером баз данных), а сидел бы на SQLite, потому что документ https://sqlite.org/whentouse.html называет это применение годным (и по своему опыту я согласен).

Простенький диалект языка SQL, употребляемый SQLite, по адресу https://sqlite.org/lang.html изложен. (Основные недостатки по адресу https://sqlite.org/omitted.html перечислены. Жить не мешают.)

Пакет ставится ≈очевидным способом («npm install sqlite3»).

Чтобы два раза не вставать, заодно в качестве веб-сервера для Node.js порекомендую Express («npm install express»), хотя эта рекомендация вообще-то является общим местом, так что и без моих усилий многие её слышали и руководствуются.

И так как при создании борды почти всегда необходим удобный язык шаблонов (например, на 410чане Kusaba использует Smarty), то рекомендую язык http://handlebarsjs.com/ и установку «npm install express-handlebars» для поддержки его на Express.

> .:O.JI.|).o|o./-.Г:.
Еле прочитал. Действительно.

Какое api для борд считается наиболее стандартным? Чтобы большинство клиентов поддерживали его из коробки, стоило только добавить ссылку.
Какие фичи наиболее нужны из тех, чего нет в кусабе?

>>18245
Апи — выдумки неосиляторов. Тебе достаточно иметь похожую на вакабовскую/кусабовскую вёрстку (классы, структуру), чтобы парсеры парсили как и Вакабу/Кусабу.

Вопрос по бордостроению.
Классические движки генерируют статический html, и после отправки формы делают редирект на доску или в тред. При этом новый пересобранный html отдается nginx'ом или apache'м. И хотя в ответе сервера с редиректом со статусом 304 проставлены заголовки 'no-cache' и прочие, сам html отдается вебсервером без таких заголовков, и браузер его кеширует, из-за чего непосредственно после редиректа нового поста не видно до обновления страницы.
Такая проблема универсальна по многим движкам и заключается в неправильной кофигурации вебсервера.
Так вот, как настроить nginx так, чтобы после редиректа от бы отдавал в заголовке no-cache, но поступал бы обычным образом, если редиректа не было. nginx настроен как реверс-прокси, и все post-запросы пробрасывает на другой порт, статику отдает как обычно.

>>18286
Etag?

>>18286
> редиректом со статусом 304
302, конечно же.
>>18287
Похоже что nginx шлет одинаковые заголовки ответа, когда документ только что изменился. Все поля, и ETag, и Last-Modified совпадают. В конфиге nginx при этом ничего по сути нет, указан root /var/www/html;, да и все.
Похоже он просто не видит, что файл уже изменился. Если обновить страницу вручную, то работает.

>>18289
В 2018 до сих пор остались ретрограды, которые не признают ничего, кроме ванильной вакабы.
Для нормальных людей есть REST api и клиент на Angular, но таких даже в 2018 пока меньшинство.

Вот интересно, возможно ли написать свою борду на ангуляре (4-5) + что угодно на бэкэнде? Или в таком случае нарушатся какие-нибудь основные фишки по типу анонимности на борде?
Потому что по сути, весь функционал можно где-то за месяц самому написать.

>>18291
Новый нульчан например на Vue.js написан с бекендом на PHP. И писался он как раз месяца два-три.

>>18292
Очень, очень плохой пример использования веб-приложений как обычного сайта.

>>18292
Он выглядит сверхерово. Привел ты конечно пример, мда.

>>18291 На жаве (на спринге) + ангуляре можно за неделю слабать полноценную борду. Там десяток рестов всего-то выйдет, и пару тысяч строк кода в самом плохом случае, а так меньше. Вопрос один: кому оно надо вообще?

>>18401
Мне кажется вполне неплохо для практики. Хотя, для практики уж тогда интереснее будет полноценный форум сделать.

>>18402
омг, хотел подписаться, получил заголовок