Пишу принципиально новый движок для борды. Спрашивайте ваши вопросы. Тред в /b/ удалили :(
>>18848 1) Лень настраивать, до релиза не нужно. 2) Деньги кончились на хостинге.
>>18849 Все, переподнял сервак.
Видел на сайте реквест скринов админки. Выложу их сюда. Админка пока в зайчаточном состоянии, одна полурабочая страница и несколько скетчей. Вообще, админка для меня менее интересная часть проекта, скорее даже муторная.
Скетч панели картинок с прошлого скрина.
Панель рассмотрения жалоб.
>>18896 Тьфу, не та картинка.
>>18895Ты сделал только что более-менее нормальный поиск, который можно даже юзеру.
Бамп. Новинки: Самописная капча, подключена и работает. Картинок сгенерил немного, но для теста сойдет. Что думаете насчет стойкости к автораспознаванию и удобства для юзера? Возможность ответа на пост, по клику на его id откроется форма и вставится этот id. После отправки и сохранения он станет зеленой ссылкой на пост, по ней можно кликнуть и проскроллиться к указанному посту. Цитирование с одной угловой скобкой также работает. По разметке пока все. По-моему получилось удобно, что форма ответа всегда наверху - не нужно скроллить, когда отвечаешь сразу на насколько постов. http://hexchan.org/b/
Прикольно получилось. Мне нравится. Но не логичнее местами поменять ответы со списком тредов? Чтобы по стилю ВК/ ФБ/ Телегу напоминало. Список слева, как только что-то открываешь - оно в середине. Сейчас очень странно всё ощущается. А так - быстро, приятно, потенциал хороший, кмк.
>>18997 Спасибо. С лейаутом можно поэкспериментировать. Мотивация была такая, что поскольку читаешь слева направо, боковик слева будет мешаться. Хотя, с другой стороны, слева он более привычен, как в почтовиках или социалках, да.
>>19000 Это "выберите тред для просмотра" вводит в ступор. Лучше чтобы по-умолчанию панель справа была бы развернута на полный экран, а при выборе треда отъезжала в сторону.
>>19005 А как насчет, ну не знаю, выбрать тред для просмотра? :3 Ладно, на самом деле там будет более осмысленная информация, как тут подсказали. Описание доски, правила, прикрепленные треды. Не все сразу, парни. У меня есть доска с задачами в трелло, их там уже на полсотни, и это еще нет задач по админке. Текущими темпами, боюсь, понадобится еще полгода-год.
> Прошло 3 месяца > Дизайн выкинут > 2/3 кода выкинуто > Смена парадигмы на обычное Django+Python > И это после полутреда моих гневных кукареков о расовом превосходстве Single page apps Ох лол, посаны. Я снова с вами :3(ПОТРЕБИТЕЛЬ БЫЛ ЗАПРЕЩЁН ДЛЯ ЭТОГО СТОЛБА)
Блин, хотел забавненько объявить о своем камбеке, а схлополтал бан. Неловко вышло.
>>19631 Скорее всего, последняя строка гринтекста была лишней.
>>19630 ОП, ты хоть объясни нормально, что вообще случилось. Почему вдруг больше не хочешь делать SPA?
>>19635 Дык он же вроде как забанен. Как он тогда объяснит?
>>19664 Ну, это всего на один день было, по статье "троллинг". Троллил, по факту, сам себя, ну да и ладно. >>19635 Отчасти я просто психанул, из-за огромной кучи мелких проблем ИРЛ и довольно жесткого выгорания на работе, на которой я тоже всем этим дерьмом занимаюсь. Еще в текущей SPA-ветке есть куча недостатков, не все пока придумал, как решить: 1) Во-первых и главных - начало бесить, что для простого, в общем-то, проекта нужно столько кода. Уйма логики дублируется между клиентом и сервером, нужны сложные JS-подпрыгивания, организовывать хранилища данных и там, и там (Redux на клиенте, БД на сервере), синхронизировать их. А в статике - выборку из БД сделал, шаблон с ней отрендерил и збс. 2) Я допустил большой архитектурный проеб в бэкенде. Есть в БД четыре базовые сущности: Доска, Тред, Пост, Картинка, в соответствующей иерархии. Сделал для каждой из них "красивый" REST API. Так вот, пример проблемы. Когда первый раз открываешь сайт, начинают грузиться: отдельно борды, отдельно открытый тред со своими постами, отдельно список тредов для боковой панели. Потом начинаешь ходить по тредам, грузится только открытый тред, боковик не обновляется. Экономия трафика все быстро, простые запросы к бд, все разбито по сущностям, красота. Только, блядь, состояние может между запросами рассинхронизироваться! Ты открываещь тред, в нем последний пост появился только что, в боковике у него дата обновления - позавчера. Если активная переписка идет в треде, он за пять минут может еще 10 постов набрать, а ты еще в боковике видишь что там целых ноль ответов, и по списку он во второй десятке. Или ты подгружаешь "еще тредов", и хотя я сделал так, что порядок при подгрузках будет сохраняться, но число постов и дата обновления снова вызовет недоумение. Если мы добавим к этому всему кеширование, а оно жизненно необходимо - это вообще атас. Даже пятиминутный кеш может создать лютый диссонанс между всеми частями, и черт его знает, как это вообще синхронизировать. Выход я вижу только делать так, как для полностью статичного варианта - за один запрос API выдавать всю пачку данных для отрисовки страницы. Опять же, а с подгрузками что делать?.. 3) Боковая панель. Как бы я не отбрехивался ранее, она красива (наверно), но не удобна. При автообновлении списка тредов их порядок будет меняться, мельтешить будут перед глазами, тред дальше второй страницы тяжело будет найти. Тут решения взаимоисключающие. Отсортировать треды по дате создания - не будут мельтешить, да, но зато активную дискуссию в поднятом с третьей страницы треде ты просто пропустишь.
Так я и пришел к текущему положению дел. Пока пилил статичную версию - наслаждался тем, как все быстро и просто получается. Никакой возни с состоянием приложения, понятно как сделать кеширование, не нужна "сборка" фронтенда. Из хороших новостей - есть админка, смог наконец настроить то, что фреймворк Django генерит по моделям в БД. Там, конечно, не все, к чему привыкли искушенные бордоводы, но жить с этим можно. Пикрелейтед. В ближайших планах - убрать шероховатости интерфейса (сейчас даже в тред не сразу попасть можно, если постов мало), восстановить паритет по фичам со старой версией (скрытие тредов и постов, по-просто). Дальше, я думаю отказаться от личного репозитория и выложить в анонимном на гитхабе. Буду пилить заурядный, но зато универсальный бордодвижок, может кому-то еще пригодится. Потом будут нужны механизмы репортов и банов, переноса тредов между досками. Кеширование. Масштабирование для маленьких экранов. Подсветка постов юзера и ответов на них в треде. Автообновление треда. Вроде как и все. Было на самом деле тяжело признать, что задумка, на которую угробил больше полугода не взлетает.
Такой вопрос, а почему ты не использовал сокеты на SPA?
>>19671 Я бы наверно мог, но зачем? Real-time обновления здесь не сильно нужны, плюс нужен сервер помощнее, плюс бэкенд на Django с веб-сокетами не дружит.
Как и на новом нульче, кукла работать не будет?
>>19672Я всегда думал, что со SPA неразрывно связаны веб-сокеты, особенно в тех местах где используются чаты и нужно вовремя реагировать появление новой информации.В твоём случае это была, как минимум, боковая панель.
>>19673 Нет и не нужно. >>19674 Нет, достаточно старого доброго AJAX. Алсо, имиджборд концептуально не чат, другой формат общения. Текст длиннее, немедленного ответа никто не ждет.
>>19675 Движок не нужен? Тогда зачем ты его пилишь и ведешь по нему тред?
>>19669 > для простого, в общем-то, проекта нужно столько кода. Уйма логики дублируется между клиентом и сервером. Не понимаю что тут такого сложного ты нашел. Ну, с редуксом и реактом я не работал, может, там и вправду сложно. А на сервере у тебя было что-то кроме самой БД и API-ки? > Ты открываещь тред, в нем последний пост появился только что, в боковике у него дата обновления - позавчера. > и хотя я сделал так, что порядок при подгрузках будет сохраняться, но число постов и дата обновления снова вызовет недоумение. А в чем проблема регулярно обновлять его?
Я снова в деле, братцы. http://hexchan.org/b/
>>21082 В консоли у браузера ошибка вылазит (скриншот прилагаю). Рекомендую в скрипте http://hexchan.org/static/imageboard/localCollection.js в функции readCollection() результат работы метода JSON.parse прогонять через метод https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray для проверки. В качестве примера предлагаю первые две строки функции togglethread в скрипте https://410chan.org/lib/javascript/kusaba.js на 410чане.
>>21082 И далѣе: пора бъ навѣсить https://letsencrypt.org/ для того, чтобъ провайдеръ не вмѣшивался въ траффикъ.
>>21090 Спасибо, посмотрю сегодня. >>21092 HTTPS будет, но наверно не от let's encrypt. Я им не доверяю.
>>21090 Ты бы лучше человеку объяснил, как превьюхи в PNG делать, умник.
>>21108 А что с ними не так?
>>21114 http://hexchan.org/media/thumbs/0x00000015.png — они какие-то перешарпленные будто.
>>21116 Тоже обратил внимание на этот файл, но он один такой получился. Остальные арты нормально масштабированы.
>>21117 Остальные — это какие? Там подавляющее большинство картинок в JPG, с ним проблем никогда не было. А с PNG: — скриншот http://hexchan.org/media/thumbs/0x00000021.png перешарплен; — кадр из Dog Days http://hexchan.org/media/thumbs/0x00000025.png перешарплен; — картинка из >>21116 тоже. Ну и не ты первый, и не ты последний, кто на эти грабли наступал. Если идти путём наименьшего сопротивления, то я бы превьюшки делал в одном формате, например в WebP для людей и JPG для всех остальных — сами по себе они всё-равно никому не интересны.
>>21122 А, то есть превью из JPG в PNG нормальные получаются, а из PNG в PNG дефектные? Теперь понял. Надо чет делать тогда.
>>21090 Подстелил соломку на случай кривых значений в LocalStorage. Должно хватить, во всяком случае больше не дампует в консоли. >>21122 Разобрался с картинками, теперь превью для них красивые генерятся. Проблема была в том, что в них использовались индексированные цвета из палитры, я добавил конвертацию в полноценный RGBA. Я и не догадывался, что это все нужно учитывать пока вы не сказали. http://hexchan.org/b/0x000005/#0x000028
Выкладываю код на Гитхаб: https://github.com/hexchan/hexchan-engine
Коллеги, работаю над новой капчей, оцените образец, пожалуйста. Портировал из Вакабы на Python генератор слов, очень он мне нравится. Изображение строится просто - слово отрисовывается побуквенно, буквы размещены с небольшим пересечением и смещением по вертикали, получается почти непрерывная строка, дальше рисуется ее контур. Когда-то читал, что контур буквы тяжелее распознать программно, чем саму букву. Это правда?
>>21167 Не знаю. Немножко банальных преобразований (чистка от мелкого мусора в пеинт/ирфан не входит, извините, только заливка и инверсия), и ни о какой разнице между слитыми буквами и контуром слитых букв нету. Даже от мусора чистить проще, самое большое пятно - капча.
>>21167 Я бы добавил ещё случайные поворот символов на небольшой угол и искажение символов по размеру (сжатие, растяжение). У тебя пока одинаковые символы во всём наборе. Ну и банальщина: смысл подобных мероприятий в том, чтобы усложнить распознавание примитивными техническими средствами сохранив при этом удобство работы нормальных пользователей. Ну а если уж ты насолил человеку, занимающемуся компьютерным распознаванием образов профессионально, то созданием капчи тут, очевидно, не отделаться, так что этот edge case можно не рассматривать — см. дихотомию «Моссад — не Моссад». Ну и я бы больше внимания обращал на фронт, ибо сферический в вакууме бэк никому не интересен, тем более, что его клиенту не видно.
>>21167 Если хочешь безопасности, то делай не просто контуры символов, а разноцветные контуры с переливающимся цветом, мусорными линиями схожих цветов и переливающимся фоном с цветами схожей яркости, чтобы при переводе в чб фон сливался с контурами символов. Но это скучная капча. На твоём месте я бы попробовал изобрести свою мемную рекапчу на хешах. Кроме того, чтобы вайпалки не вайпали просто так, хорошо пошаманить над правами доступа и прочей верификацией открытия страницы в браузере. Например, жс, дающий дополнительный хеш с солью на сервере. Для безжсных можно сделать хитрее: открывать капчу в айфрейме, а капчу генерировать матрицей символов 10×10 с цсс-правилом выравнивания первого символа в начале вьюбокса. То есть обычный пользователь видит условные шесть символов, а вайперу нужно будет найти эти шесть символов из сотни.
>>21171 Последние ухищрения легко решаются простым скриншотом страницы браузера, со всякими электронами реализация ломалки капчи будет проще, чем реализовать саму капчу. Это касается как хитрого жс, так и айфреймов. В 2011 году ЕФГ реализовал похожую защиту капчи с хешем, у многих из-за этого отваливался постинг, но зато кто-то написал вайпалку на adobe air, где был встроенный вебкит. В современных реалиях капча - дань традиции и защита от script kiddie, не стоит тратить много времени на ее взломоустойчивость.
>>21174 >В современных реалиях капча А она когда-то для чего-то другого была нужна?
>>21174 Всё так. И если хочешь защитить что-то капчей — воспользуйся той же рекапчей, но по назначению, а не как обычно: одна капча на сессию, а не на каждый пост.
Рекапча это банально и скучно. Если уж делать свой движок для борды, то есть нечто заранее ненужное, то есть делать просто ради самого процесса деланья, то вполне уместно самому с нуля сделать какие-то фановые фичи. Например, свою капчу. Но я согласен, можно было более креативно подойти. Распознавать выражения лиц, анимешных персонажей, решать задачки по матану или го.
>>21177 Рекапча вполне себе разгадывается. Толку от нее нет, вред один.
>>21252Рекапча если и разгадывается, то только индусами или топовыми нейронками, оба за бесплатно работать не будут. И это главный фактор, отсеивающий 99% вайперов. Алсо рекапчу нужно правильно использовать, уже вроде писал, что если рекапча будет одна на сессию, то обычным пользователям нечего бояться, особенно если с лимитами на постинг по времени поиграться.
>>21253 http://iichan.hk/d/res/247134.html#247394
Бампаю свежим скрином и ссылками: https://hexchan.org/b/ https://github.com/hexchan/hexchan-engine
