[WT] [Архив]  [Поиск] Главная Управление
[Совместно с Ычаном]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 18881)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, OGG, PDF, PNG, PSD, RAR, SVG, SWF, TXT, XCF, ZIP размером до 10000 кБ.
  • Ныне 3041 unique user posts. Посмотреть каталог
  • Максимальное количество бампов нити: 500
151778852326.png-(51.07KB, 349×500, kotoba_logo_lg.png)
18881
No. 18881 watch    
DISCLAIMER: Данный проект не является форком kotoba-ib и его разработка не ведется персоналом «Супермаркета».

Этот тред посвящен разработке очередного движка имиджборды под названием «kotoba.js». Движок написан на NodeJS, в качестве базы данных MongoDB, стек express, mongoose, passport.js является сегодня настолько же стандартным, как PHP в свое время. Фронтенд использует Sass и Babel, его сборка автоматизирована (gulp+babelify, но со временем нужно перейти на Webpack). Верстка - полностью валидный HTML5, однако максимально напоминает Вакабу, что позволяет работать стороннему коду (Кукле и мобильным клиентам) без существенных доработок. Так же движок работает по классическому принципу генерирования статичных файлов и имеет схожую структуру каталогов.

Несмотря на наличие современных движков, некоторые их которых даже используют похожий стек (такие как LynxChan и ololord.js), до сих пор тут и там регулярно появляются вопросы по установке морально устаревших Вакабы, Кусабы, Вичана и их форков. При этом установка и обслуживание таких движков крайне затруднительна в виду почти полного отсутствия документации, устаревших зависимостей, и необходимости доработки движка, добавления недостающих функций, и исправления устаревшей верстки.

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

Как выглядит процесс установки типичного движка на локалхост:

  • Установить Apache, PHP, MySQL
  • Убедиться что PHP скомпилирован с нужными флагами и что установлена нужная версия интерпретатора (PHP 5.6 будет ругаться на то, что работало в PHP 5.4)
  • Установить ImageMagic и ffmpeg для поддержки webm
  • Править config.php, проводить манипуляции с install.php (который никогда не выполняется первого раза без ошибок)
Так выглядит установка котобы:

  • Установить docker и docker-compose (дело 1 минуты)
  • Скачать исходный код из репозитория
  • Выполнить docker-compose up -d в папке с кодом.
Установка всех зависимостей произойдет автоматически (при этом оно никак не затронет систему). После этого движок сразу готов к работе. Первый созданный аккаунт получит права администратора, лезть в исходники и править переменные не нужно - все значимые настройки доступны из админки.
Разумеется, речь идет о локалхосте. На боевом сервере нужно еще как минимум запоролить БД, а так же настроить https.

Исходный код: https://github.com/WagonOfDoubt/kotoba.js

На данный момент проект находится в стадии MVP: то есть, самый основной функционал, такой как постинг, работает, но множество ключевых функций еще не реализовано.
Логотип, очевидно, WakabaMark, стилизованный под сервала, символизирует преемственность движка перед Вакабой и подобными, а так же кошачью тематику, и является отсылкой к Kemono Friends.
91 сообщений пропущено. Показаны 50 последних сообщений Развернуть все изображения
No. 19118    
>>19116
>если все это можно с лёгкостью изменить
Ещё раз: телодвижений на добавление одного слова надо проделать больше, чем на добавление ответа в вайпалку. И подменять получается можно не более одной капщи за раз. С оплаченным проездом всё становится вообще очень весело.
>Особенно если это мелкоборда.
Так тут вроде уже спорили, чтоэто двиг общего назначения, а не под конкретные запросы.
No. 19119    
>>19118
>Так тут вроде уже спорили, чтоэто двиг общего назначения, а не под конкретные запросы.
Да тут из этого всего переобувания на лету уже не поймёшь, кому нужен этот двиг. А в данном случае это даже не ОП.
No. 19123    
>>19119
> Да тут из этого всего переобувания на лету
И что же за странность у тебя с переобуванием не так?
> кому нужен этот двиг
Ох, как же я люблю таких людей на анонимных имиджбордах, которые любят за всех рьяно отчитываться злоупотребляя анонимностью...
No. 19127    
151861415369.jpg-(1.37MB, 985×1400, 9b5f1f929527a2f782518c76930271f3.jpg)
19127
>>18968
> NoSQL быстрее SQL

Вруша.

https://www.enterprisedb.com/node/3441

MongoDB в 2018 году вообще не нужно. Разве что если память девать некуда, а надёжность-производительность не важна.
No. 19129    
тред для мемов?
тред для мемов!

http://www.youtube.com/watch?v=b2F-DItXtZ
s
No. 19130    
опс
http://www.youtube.com/watch?v=b2F-DItXtZs
No. 19143    
>>18968
>1. NodeJS быстрее PHP.
Ахаха, нет. Если тебе заходит абстрактная херня вместо объективных тестов, то вот тебе порция:

  • Склейка строк в PHP в 2.5 раза быстрее;
  • Наполнение массивов в PHP на 60% быстрее;
  • Наполнение ассоциативных массивов в PHP в 7 раз быстрее;
  • Чтение файлов в PHP в 10 раз быстрее;
  • SELECT запросы к БД в PHP в 2 раза быстрее;

No. 19144    
151880011540.png-(24.90KB, 589×429, tumblr_lyod8mfp621qm9ue5o2_r2_1280.png)
19144
>>19143
No. 19148    
>>19143

> абстрактная херня вместо объективных тестов

> Ахаха
No. 19172    
Ну что ОП, как дела? Будет ли отчёт за неделю, как в прошлый раз?
No. 19173    
151897327123.jpg-(170.25KB, 1001×820, yandere trance -- Misaka imouto.jpg)
19173
Читал описание теста >>19144 по адресу http://zzarbi.tumblr.com/post/16870870471/php-nodejs-mysql-and-mongo

Много думал.

Тесты под названием «Mysql2» и «Mongo2» отличаются тем, что не содержат повторного открытия соединения с сервером. Не удивительно, что Node.js быстр в этом случае, но для чистоты эксперимента тогда и PHP следовало бы запускать аналогично (возможности http://php.net/manual/en/mysqli.persistconns.php и http://php.net/manual/en/pdo.connections.php это позволяют для MySQL, например), а сделано это не было, так что тест ни о чём.
No. 19174    
>>19173
Это имеет смысл, так как сравнивалась производительность типичного веб-приложения на PHP, работающего через cgi, например php-fpm, где на каждый запрос спавнится новый процесс, и наиболее популярного подхода на Node.js: запустить сервер и слушать порт. В первом случае нет возможности держать постоянное соединение с БД. Оба подхода являются дефолтными при выборе соответствующей технологии, говоря "сайт на PHP" подразумевают именно LAMP с php-fpm, а так сделаны все движки для имиджборд на PHP, так же как и на perl, и некоторые на Python, говоря о сайте на Node.js, как правило подразумевают express, и все известные движки на нем написаны именно так.
Так что в контексте данного треда этот тест совсем не ни о чем.
No. 19177    
>>19172
Добавлено удаление постов по паролю. Вроде бы немного, но это ключевая функция, которая не очень тривиальна. Нужно было корректно удалять не только посты из базы данных, но и ссылки на удаленные посты из карты ответов других постов, посты-ответы при удалении тредов, картинки и html-файлы. В дальнейшем с этим уже легко реализовать основные функции админки.
В процессе переход сборки фронтенда с gulp на webpack, что позволит ускорить разработку фронтенда.
No. 19178    
>>19177
>удалять не только посты из базы данных
То есть, тут нельзя будет, как в кусабовском модлоге, посмотреть, что там понаудаляли модераторы. И некровайперов, которые удаляют посты, только через логи сервера ловить, ага.
No. 19179    
>>19178
Чего? Откуда такой вывод?
No. 19180    
>>19179
Из процитированного. Как просмотреть содержание удалённых сообщений, если они и из базы удаляются?
No. 19181    
>>19180
В модлоге. Которого еще нет.
No. 19182    
151899339432.jpg-(126.66KB, 700×990, 1518993394862.jpg)
19182
>>19177
>>19178-кун очень прав. Не смотря на каличность кода кусабы, у нее было несколько ключевых функций, которые отсутствуют в многих современных движках. Например, в том же тиниборде/вичан. Среди них:
  • нет быстрого ответа
меньше действий, что эргономично.
  • multidelete/multiban.
Дохера полезная вещь. Допустим в треде пару дурачков Семёнов устроили сильный срач на постов так 25 а то и больше. И вот, представь, модератору вместо того чтобы выделить сразу ненужные посты на удаление - приходится кликать по каждому посту отдельно. Скорее всего он взорвется так - что удалит тред полностью. Что не очень найс. Как это работает. Когда ты залогонился как админ или модератор, ты заходишь на доску и можешь удалять не через мод-кнопки которые находятся рядом с каждым постом, а как обычные пользователи - с разницей лишь той, что твой пароль может удалить любой пост в пределах доски/досок, где у тебя есть права на удаление. )
  • Бэкап тредов.
Нужен для двух случаев: 1) контролировать модераторов, чтобы знать не только сколько и какие посты они удаляют, но и что было в содержании. А вдруг рядом с постами нарушающими правила, они трут ещё просто то что им не нравится. И тогда, если пользователь жалуется на несправедливую модерацию, то админ может по модлогам и бэкапу чекнуть, "гонит" ли пользователь на доске или быть может у него появились "вахтёры". 2) есть некоторые тролли, которые любят создать тред, а потом когда люди начинают отвечать и тред набирает интересную и полезную дискуссию, он берет и удаляет тред. ОП же типо. Ну а про невидимые бампы я вообще молчу.
Да, самое главное: эти посты при желании можно восстановить. С файлами. Но только таким правом обладает админ. Как и удаление корзины. Т.е. получается у нас есть аналог корзины в бд. Удаленные файлы/треды/посты В ЛЮБОМ СЛУЧАЕ попадают в корзину при удалении, а потом только админ способен либо восстановить либо удалить навсегда конкретные посты/файлы.
  • No-read баны. Тоже полезная вещь. Если стоит на апаче то пускай вписывает IP в .htaccess файл. Профиты: более строгое наказание для вайперов. Чтобы они наверняка не смогли завайпать борду и также заодно трафик можно сэкономить.

No. 19183    
>>19177
Хотя быстрый ответ у тебя уже реализован, это хорошо.
No. 19184    
>>19182
Все это довольно очевидно и являлось частью концепции движка изначально.
За исключением только no-read банов. Большой практической цели они не несут, а в случаях защиты от вайпов/ддосов/надзоров можно самому полезть в настройки вебсервера.
No. 19185    
>>19184
>За исключением только no-read банов
То есть, опыт эксплуатации™ Ычана, где их вкатывают каждый день по несколько раз, игнорируется?
No. 19186    
>>19184
> Большой практической цели они не несут
Ну как сказать, высшая же мера наказания.
>>19185
А разве там есть no-read баны?
No. 19191    
151899694112.jpg-(536.04KB, 1056×1504, horror -- Hakurei Reimu.jpg)
19191
Возражение >>19174 признаю убедительным.
No. 19192    
>>19178
Кстати о некровайперах. В Инстанте была правка, возвращающая тред на место, если последний пост, которым был бампнут тред, удаляется.
No. 19193    
>>19192
А также такая правка была в Phutaba
No. 19194    
>>19192
Хороший вообще движок. Только вот доски 2.0 раздражали. Если бы можно было как-то от них избавиться...
No. 19207    
151906159043.jpg-(211.65KB, 430×600, 67313183_p0_master1200.jpg)
19207
Над чем дальше будешь работать после того, как реализовал удаление по паролю постов?
Я бы лично рекомендовал тебе реализовывать в таком хронологическом порядке:
1. bans and moderation features
2. staff permissions system
3. autoupdate and notifications
4. personal settings stored on server
No. 19221    
151913360218.png-(21.90KB, 259×224, 14154262.png)
19221
МЕЛОЧЬ, НО ПРИЯТНО!
В кусабе, в отличии от вичана и вакабы, если изменить имя дефолтное и делать это без генерации страницы, итог один и тот же: изменяются абсолютно все имена. Даже на старых, т.е. последних страниц. Более того, в дефолтное имя нельзя запихнуть массив например, если хочется создать примитивный генератор имен. Было бы здорово, если ты систему имен дефолтных реализовал как в вичане/кусабе
No. 19227    
>>19221
>В Кусабе убогая реализация, не как в Вичане!
>Сделай как в Кусабе/Вичане!
Што.
No. 19228    
>>19227
Как в вакабе хотел сказать. Опечатался
No. 19231    
15191446994.png-(280.00KB, 664×1367, Screenshot-2018-2-20 Kemono Friends.png)
19231
>>19221
Оно там с самого начала так.
No. 19233    
Json api есть?
Тред не читал.
No. 19274    
ОП, как дела? Когда будет запилена админка и модерка?
No. 19382    
Я так понимаю развитие движка заглохло?
No. 19383    
>>19382
Не заглохло, но показывать нечего, пока функции не будут реализованы полностью.
No. 19745    
Как дела?
No. 19756    
Что-то разраб давно уже не допиливал код. А ведь проект и правда годный. Грустно, что он прзабросил его.
No. 19761    
Не паникуйте. Проект не заброшен. Просто есть такие вещи как "работа" и "отсутствие свободного времени".
No. 19777    
152621948876.jpg-(171.03KB, 847×1200, zero.jpg)
19777
Когда я смотрю на код всех энтих проектов на ноде/экспрессе, у меня возникает такой вопрос:
Вам самим нравится писать подобную слабочитаемую лапшу или это вас жс заставляет такое делать?
Реально, как вижу эти портянки кода так плакать хочется.
Но тем не менее желаю удачи в этом деле, хотя сколько я уже подобных проектов видел — заканчивали они одинаково.
No. 19778    
>>19777
Не скажи. С введением async/await предрассудки про лапшу из коллбеков остались в прошлом. А экспресс мало чем отличается от фласка, как в плане функционала, так и читабельности.
Вот самый отполированный файл: https://github.com/WagonOfDoubt/kotoba.js/blob/master/containers/node/controllers/generate.js
Чистая функциональщина, каждая следующая функция вызывает предыдущую. Почти не используются циклы - вместо них семантичные Array#map, forEach и reduce. Или вот https://github.com/WagonOfDoubt/kotoba.js/blob/master/containers/node/models/board.js чисто декларативная схема базы данных.
No. 19779    
>>19778
Со стороны C# это все выглядит смешно.
Тут народ до сих пор месит ActiveRecord, который разве что в пределах простенькой крудни не доставляет боли.
No. 19828    
node_1 | Error: Cannot find module 'express'
node_1 | at Function.Module._resolveFilename (module.js:555:15)
node_1 | at Function.Module._load (module.js:482:25)
node_1 | at Module.require (module.js:604:17)
node_1 | at require (internal/module.js:11:18)
node_1 | at Object.<anonymous> (/home/node/app/index.js:1:79)
node_1 | at Module._compile (module.js:660:30)
node_1 | at Object.Module._extensions..js (module.js:671:10)
node_1 | at Module.load (module.js:573:32)
node_1 | at tryModuleLoad (module.js:513:12)
node_1 | at Function.Module._load (module.js:505:3)
node_1 | error: Forever detected script exited with code: 1
node_1 | error: Script restart attempt #3
node_1 | module.js:557
node_1 | throw err;
node_1 | ^
node_1 |
node_1 | Error: Cannot find module 'express'
node_1 | at Function.Module._resolveFilename (module.js:555:15)
node_1 | at Function.Module._load (module.js:482:25)
node_1 | at Module.require (module.js:604:17)
node_1 | at require (internal/module.js:11:18)
node_1 | at Object.<anonymous> (/home/node/app/index.js:1:79)
node_1 | at Module._compile (module.js:660:30)
node_1 | at Object.Module._extensions..js (module.js:671:10)
node_1 | at Module.load (module.js:573:32)
node_1 | at tryModuleLoad (module.js:513:12)
node_1 | at Function.Module._load (module.js:505:3)
node_1 | error: Forever detected script exited with code: 1
No. 19937    
>>19828
> kotoba.js/containers/node/Dockerfile
> RUN npm install
Странно, что npm install не выполняется при сборке, хотя это всегда происходило раньше, а Dockerfile и docker-compose.yml не менялись с первого коммита.
Как временное решение: выполнить на всякий случай "docker-compose build", запустить движок через "docker-compose up -d", выполнить "docker exec -it kotobajs_node_1 bash" и затем внутри контейнера "npm install".
No. 19947    
Предполагаю, что в сём случае можно нѣсколько ускорить всё дѣло, если «npm install --production» вмѣсто простого «npm install».

Прошу подтвердить или опровергнуть.
No. 19958    
>>19947
Суть проблемы описана в https://stackoverflow.com/questions/30043872/docker-compose-node-modules-not-present-in-a-volume-after-npm-install-succeeds и https://stackoverflow.com/questions/38425996/docker-compose-volume-on-node-modules-but-is-empty
Кратко: сначала выполняется npm install и создается папка contaniers/node/node_modules внутри контейнера, затем монтируется вся папка contaniers/node/ с хоста, заменяя собой ту, в которой node_modlues есть.
Еще одно решение, это удалить из docker-compose.yml строчку " - ./containers/node:/home/node/app".
Очень странно, что этого до сих пор никто не заметил. Что впрочем легко объясняется тем, что никто даже не пытался ничего ставить.
Решение с удалением строчки выше оптимально для продакшена, однако усложняет разработку. Возможно стоит сделать так, чтобы npm install выполнялся при запуске контейнера, на не во время сборки. Есть ли в Докере способ сделать так, чтобы монтировалась вся папка, кроме одной подпапки node_modules?
No. 19964    
Исправлено в новом коммите. >>19937>>19958 можно игнорировать.
No. 19968    
>>19958
>Что впрочем легко объясняется тем, что никто даже не пытался ничего ставить.
Докер-докерочек, ага.
No. 19970    
152645539170.png-(11.23KB, 595×177, Screenshot_20180516_102251.png)
19970
キタ━━━(゚∀゚)━━━!!
No. 19972    
152646065273.png-(10.08KB, 538×182, Screenshot_20180516_110200.png)
19972
キタ━━━(゚∀゚)━━━!!
No. 19976    
>>19972
Поменяй права доступа к папке html, очевидно же. Проверь их через ls -l
Конкретно нужно сделать:
~/kotoba.js/$ chmod -R a+w html
и возможно (хотя маловероятно):
~/kotoba.js/$ chmod -R a+w containers/node/html
Только что проверил установку с нуля, у самого все завелось с первого раза.
Удалить сообщение []
Пароль  
[Mod]