[WT] [Архив]  [Поиск] Главная Управление
[Совместно с Ычаном]
[Назад] [Вся нить] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 13408)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, OGG, PDF, PNG, PSD, RAR, SVG, SWF, TXT, XCF, ZIP размером не более 10000 кБ.
  • Ныне 2239 unique user posts. Посмотреть каталог
  • Максимальное количество бампов треда: 500
Файл: 144750580115.jpg-(268.59KB, 1920×1080, IzfQTfiXUqc.jpg)
13408
No. 13408 watch    
Всем сырнам наверняка понравится моя поделка.
Суть такова: склад картинок, большого их количества. Все картинки пакуются в один большой зашифрованный образ, база данных тоже зашифрована, то есть без файла ключа оттуда ничего не достать. Базовый функционал уже на 80% реализован, сейчас делаю рефакторинг, ускоряющий обработку файлов.
Но у меня не такая большая фантазия, и я хочу услышать, какой еще функционал в такой проге будет нужен. Сейчас почти реализовано деление по альбомам, тегам, поиск по оным же, поиск похожих, дедупликация. Как закончу базу, буду делать туда универсальный парсер чанов, *bоoru, вконтактика, чтобы базу пополнять. Там же будет стеганография, то есть сохранение зашифрованных файлов или текста внутри PNG-картинок.
Сырне интересна такая софтина? Сырна предложит еще функционал? А может у кого есть желание помочь?
Все написано на яве, кроссплатформенно. Код на гитхабе: https://github.com/konachan700/JNekoImageDB
Готовой версии для конечного пользователя еще нет, но кто умеет кодить хоть сколько-то, может потыкать проект веточкой.
34 сообщений пропущено. Показаны 50 последних сообщений Развернуть все изображения
No. 13780    
Файл: 145401826589.jpg-(85.17KB, 1280×720, noseblood.jpg)
13780
>>13702
Что там как у тебя дела, ну расскажи же!
No. 13783    
Файл: 145408143878.jpg-(86.32KB, 660×1020, LZ3eIe79fGU.jpg)
13783
>>13780
Все потихоньку. Я не планирую быстро сделать релиз, поскольку изучаю на этом проекте технологии и фреймворки, отчего по десять раз рефакторю один и тот же модуль. Первая цель - разобраться в яве и всей экосистеме, вторая - сделать юзабельный безглючный релиз. Такой софт с глюками, костылями и изменениями в архитектуре БД никому не нужен. Зальет анон туда миллион пикч, а завтра обновление поломает БД, и анон больше использовать такой софт не будет.
No. 13784    
>>13783
Если оно на яве, я не уверен, что анон его вообще качать будет. Или ты запакуешь всё в один экзешник с jre и не скажешь никому об этом?
No. 13785    
>>13784
Зависит от анона. Я попользую. Но для меня главное - не шифрование. Для меня киллер-фичи такие:

Теги
- получить список тегов и число картинок по каждому
- автодополнение при вводе тегов
- возможность переименовать тег
- посмотреть общие теги и теги, частично присутствующие, у выбранных картинок
- возможность добавить тег всем выбранным картинкам
- возможность убрать тег у тех выбранных картинок, где он есть (может быть не у всех)

Описания - текстовое сообщение произвольной длины у каждой картинки.
- полнотекстовый поиск по этим текстам.

API/java-библиотека для доступа к хранилищу
Пусть там указывается пароль, но получать картинки (как byte[] или InputStream) и метаинформацию через него (описания, теги, mime type).

Поддержка хранилищ в одном файле. Т.е. не postgres, а скажем sqlite (хоть это и так себе вариант). Либо такое - есть этот непонятного формата файл и когда первый раз его открываешь, он индексируется в БД, а потом картинки берутся из него, а поиск и всякие теги берутся из БД для скорости.

Не слушай >>13421 - коммиты разумнее разбивать по смыслу. А когда меняешь что-то в одной и той же вещи по смыслу, делать надобно Amend (пока не запушил на гитхаб). Так ты не будешь бессмысленно повышать энтропию в репозитории.
No. 13786    
Я когда исходники смотрел, меня сильно удивило, что морда на JavaFX. Хотя наверно здесь это лучше, чем веб или Swing.
No. 13787    
Забыл еще одну Самую Главную Киллерфичу.
Разумная избыточность не в ущерб шифрованию.
Т.е. если винт посыпется или еще чего, нужно чтобы вот всё это хранилище не рассыпалось. Чтобы можно было "лечить архив": из поврежденного хранилища снова сделать чистое, размером поменьше (выкинув поврежденные части).
No. 13788    
Предлагаю создавать еще немножко метаинформации из самой картинки. Например, можно находить средний цвет картинки и искать их не по тегам, а ближайшие картинки к оттенку (гуглить "Формула цветового отличия", если используешь CIELab, можно заюзать CIE76 даже).
No. 13789    
Файл: 145410307391.png-(451.64KB, 1280×720, please respond [Leopard-Raws] Love Lab - 03 RAW (T.png)
13789
>>13783
> Я не планирую быстро сделать релиз
> по десять раз рефакторю один и тот же модуль
> сделать юзабельный безглючный релиз
> софт с глюками, костылями никому не нужен
Оставайся таким как можно дольше.
No. 13790    
>>13786
Так дестопное приложение же. Свинг морально устарел, веб чисто теоретически требует сервера кому нужна возня с установкой и настройкой, да и в случае веб-приложения на манер i2p повышается сложность настройки-установки.
>>13787
Если сам файл базы с записями о картинках (h2) не будет поврежден, то отдельные битые пикчи ничего не испортят. Бэкап базы и настроек будет штатной фичей.
>>13785
Почти все перечисленное будет.
>>13784
Да, релиз на гитхабе будет во всех видах, в том числе собранный .exe - кому как удобнее. Хотя, по хорошему счету, .jar ассоциируются в винде с жавой и запускаются как ехе-шники, если стоит сама жава.
No. 13794    
>>13790
>если стоит сама жава
Многие не хотят опорочивать свою систему жавой.
No. 13804    
Файл: 145454798867.jpg-(131.59KB, 650×682, [Commie] Teekyuu - 30 [BD 720p AAC] [5EDE8DF0]_000.jpg)
13804
>>13794
/0.
Сидеть на венде и рассуждать об «опорочивании» чего-либо смешно, а в швабодном мире без джавы лайбриофис не откроешь.
No. 13810    
>>13804
В швабодном мире есть латекс.
No. 13815    
>>13810 Латекс — это для изделия №2. TeX отсылает к слову «техника» и читается соответсвенно.
No. 13897    
Файл: 145684079151.png-(253.09KB, 694×761, 271.png)
13897
>>13810
А я как-то пытался настроить имакс с затурой для работы в латехе. Для непосвящённых: имакс выступает в роли IDE, где вы собираете документ, пинаете из него PDF-вьювер, а также прыгаете из вьювера на код в документе. Естественно, ТеХ не умеет в PDF сам и ему нужны прослойки-прослоечьки. Короче ниасилил я всю эту кухню, хотя конпеляция участка кода в превью прям на месте (без вызова вьювера) была завораживающей.
No. 13899    
>>13897
> Естественно, ТеХ не умеет в PDF
Умеет. Называется pdf(la)tex.
No. 13900    
>>13804
Открыть-то можно, не собрать разве, если по dep'ам судить.
No. 13901    
>>13899
Да, я перепутал. Превью должно было генериться из DVI, и для его вывода нужна была отдельная приблуда xdvi.
No. 13912    
Если у кого-то проблемы с организацией картинок, то советую посмотреть на Hydrus Network. Это локальная база данных, пилится забугорным аноном. Есть свой репозиторий тегов, можно подключать базы данных картинок с бур типа гелбуры или р34.
No. 13913    
Оп, очень полезную и нужную штуку делаешь, сам всё хочу написать подобное для своих нужд, но каждый раз боюсь начинать такой большой проект.
Но бляяя, на жабе? Десктопное приложение на жабе? ЗАЧЕМ??? Это же сразу нахуй, опять же будет раздутое неюзабельное говно, жрущее гигабайты памяти и дико тормозящее на йобао-суперкомпьютерах.
No. 13923    
Файл: 145755402218.jpg-(472.89KB, 2400×1800, 14528989873690.jpg)
13923
>>13913
Жава не тормозит со времен выхода 1.7 если не раньше, и слухи эти больше вызваны сраным IE6- и апплетами в нем (да, оекаки им родня), что писали жопорукие тыжпрограммисты. Память под кучу оно забирает максимум, да, но во-первых, нафига памяти быть пустой, а во-вторых, двумя параметрами самой жавы эту прожорливость можно отключить, если внутренняя амфибия сильно душит. Ровно та же городская легенда, что и про VB, который и правда был жутким монстром первое время, но теперь в определенных применениях крайне удобен и незаменим. И ровно та же бугуртная горотская легенда про память в андроиде, и целая ниша "чистилок" ее. Память должна использоваться, а не болтаться свободной. Скорость генерации превьюшек у меня одинаковая с тем же долфином из кде или проводником винды. Скорость IO на мелких файлах выше на порядки того же проводника за счет многопоточности.
Жава дает переносимость между платформами, и ничего более подходящего нет. QT слишком хитровыебан и слабодокументитрован против жавы, на чистых плюсах такое писать работы в десять раз больше одна безопасная обработка строк чего стоит и непереносимо, скриптовые языки слишком медлительны и обрасли мхом фреймворков так, что за век не изучить на хороший для префекциониста уровень.
No. 13925    
Файл: 145759356482.jpg-(23.96KB, 400×300, smaylik.jpg)
13925
>>13923
>QT слишком хитровыебан и слабодокументитрован против жавы
>хитровыебан
>слабодокументитрован
No. 13926    
>>13923
>И ровно та же бугуртная горотская легенда про память в андроиде, и целая ниша "чистилок" ее. Память должна использоваться, а не болтаться свободной

У меня тут на днях paged-память кончилась в винде. Это произошло потому, что три программы, одна из которых мне нужна, подумали, что память не должна быть свободной. Superfetch тоже так думал, пока я не отключил его.

Идите в лес, гражданин, короче.
No. 13929    
>>13923
>Жава не тормозит
Уже смешно, ага.
Мне откровенно похуй на легенды, но из двух десятков десктопных приложений на жабе, которыми мне доводилось пользоваться достаточно продолжительное время, чтобы оценить производительность, 100% приложений жрали память как голодные волки и выдавали жуткие тормоза в самые неподходящие моменты. Мне похуй на то, какие там невъебенные скорости работы с файловой системой, или что скорость математических расчётов выше, чем в нативном коде и т.д., но если приложение подвисает и тормозит на уровне пользовательского интерфейса - оно тормознутое говно по определеню. И пока что под это определение подходят 100% виденных мной жаба-приложений.
И нет, я не мазохист, мне приходилось пользоваться этим говном потому что приложения узкоспециализированные и выбора попросту не было.
No. 13930    
>>13912
Посмотрел, кстати, пока что это самое приличное из всего, что видел подобного, но бля, оно меееедлееееннооооеееееее. Питон, к тому же однопоточный, даёт о себе знать. Подключил к нему бд тегов данбуры - и всё, банально при попытке вбить тег в поиск оно подвисает секунд на пять. Короче, неюзабельно.
No. 13931    
Файл: 145762533144.jpg-(111.21KB, 850×811, sample_0db21d38e9c9143d22fe143099e2ae6d.jpg)
13931
>>13929
>но если приложение подвисает и тормозит на уровне пользовательского интерфейса - оно тормознутое говно по определеню
Всецело в руках говнокодеров, считающих что-то в gui-потоке. Тормоза там только из-за этого, и такой подход чуть ли не стандарт отрасли, сам плююсь. Принцип нормального кодинга в жаве такой - если место в коде может даже теоретически дать задержку при выполнении более 20-50мс - ссанымии тряпками в отдельный поток его гнать. У меня на лету идет копирование\шифрование картинок, с суровым таким IO, сама система виснет - гуй работает прекрасно.
>>13926
Не нравится - отключи эту фичу у меня в релизе она будет выключена сразу. Жава по скорости разработки выигрывает у тех же плюсов, и дает переносимость. Ничего другого просто нет. Ко всему прочему у меня первая цель - выучить жаву, а потом уже сделать что-то на ней.
>>13925
Мне это показалось именно так. Но могу быть неправ.
No. 13932    
>>13931
А управление ВНЕЗАПНЫМ сборщиком мусора(второй основной причиной жабьих тормозов) вам тоже уже позволили, или он до сих пор ВНЕЗАПЕН?
No. 13933    
>>13931
>Не нравится - отключи эту фичу

Я не о жабе говорил, а о том, что **ПАМЯТЬ ДОЛЖНА ИСПОЛЬЗОВАТЬСЯ**.
No. 13934    
Файл: 14576346118.jpg-(191.54KB, 504×835, mabinogi_2015_10_11_001.jpg)
13934
>>13932
Но что нужно делать, чтобы сборщик создавал тормоза? for () { new Thread(new Runnable(){...}).run(); }? Я гонял 16 потоков, в каждом идет пережатие пикч, шифрование, дергание хибернейта, дергание levelDB, еще была генерация хешей похожести в репу не попало по причине полной велосипедности - по показаниям профилировщика 10-15% в сборщике мусора в самом худшем случае. IO 65-85мбайт\сек, ОС охуевала, но я не видел, чтобы программа сидела в сборщике хоть сколько-то значимое время.
Да, месье любят вместо написания пулов или использования уже готовых решений тупо плодить тяжелые объекты, и это второй херовый "стандарт отрасли". Там 50-70% в сборщике норм - вот все и тормозит. Этак и на сях можно malloc/calloc каждый раз делать и бросать, а потом плевать ядом, что С тормозит и жрет гигабайты памяти.
А на критических местах не грех и System.gc(); сделать, но без фанатизма.
No. 13942    
>у меня первая цель - выучить жаву
То есть ты еще не выучил, а уже рассуждаешь так, будто поработал сеньором в паре крупных проектов? Типичный студент, защищающий говно, которым его накормили в шараге. Еще кажется ему что-то там, а утверждает как эксперт блять. Охуеваю с таких довнов.
No. 13943    
Файл: 145794124239.jpg-(76.88KB, 850×478, sample_35b567b108b10d61eeb4cbad821b871e.jpg)
13943
>>13942
> **KUUDAH**
В шараге я не учился. Вообще. Но прежде чем начать делать проект, я тонну постов на SO перелопатил, пару-тройку книг и до того имел опыт кодинга на сях, php и когда-то очень давно кодил на VB. Так что опыт у меня приличный и разное оборудование на поиграть тоже есть.
Другое дело, что вся эта хуйня несистематизиована и "по верхам". С жавой то уже года три знаком, но вот порядок в знаниях оной начал наводить вот этим вот проектом, чтобы дальше по ней работать. Сейчас уже в раздумьях, надо было С лучше вытягивать на нормальный уровень, но вакансий на С почти нет.
No. 13944    
>>13943
Ну то есть у тебя кроме вороха плохо систематизированной теории ничего нет, как я и сказал. Вот и не квохчи тогда. Теория != практика.
No. 13962    
Файл: 145873484682.jpg-(109.08KB, 900×900, consider.jpg)
13962
>>13912
Ставил как-то. Повертел туда-сюда, так и не понял, как туда хоть что-то добавить.

>>13923
> но во-первых, нафига памяти быть пустой
Чтобы не выгружалась в своп. inb4
> 2016
> своп
На линуксах vm.swappiness установлен по дефолту в 60, если мне память не изменяет. Значение инверсное — то есть, когда память забивается на 40%, система уже начинает по-тихому тормозить в своп. Поэтому я этот парметр загоняю обычно в 15.
> а во-вторых, двумя параметрами самой жавы эту прожорливость можно отключить
В jcontrol никаких параметров регулирующих, сколько памяти отжирать, нет. По крайней мере в Oracle JDK 1.8 на GNU/Linux.
> скриптовые языки слишком медлительны и обрасли мхом фреймворков
Некоторые скриптовые языки компилируются в байткод.

>>13929
> но из двух десятков десктопных приложений на жабе
Нельзя говорить об инструменте по двадцати прикладным программам написанным на нём хуй знает кем и как. /Для десктопа — так тем более./

>>13931
> сама система виснет - гуй работает прекрасно.
> система виснет
К вам CONFIG_AUTOSCHED ещё не завезли штоле?
No. 13964    
>>13962
> то есть, когда память забивается на 40%, система уже начинает по-тихому тормозить в своп
Нет. Этот параметр отвечает за то, насколько охотно ядро вытесняет анонимные страницы в своп по сравнению с тем, как оно вытесняет отображённые в память страницы в файлы.
No. 13965    
Файл: 145876311772.png-(585.66KB, 1152×720, шта2.png)
13965
>>13964
No. 13966    
>>13965
А, дошло.
No. 14088    
>>13443
zoner
No. 14091    
Файл: 146387631973.png-(110.99KB, 600×476, 5839d2e5ff565ecad0e8b61195e909c0ef3b51854fe27ca72d.png)
14091
>>14088
> The program Zps.exe has encountered a serious problem and needs to close. We are sorry for the inconvenience.
No. 14954    
>>13408
>>делаю рефакторинг, ускоряющий обработку файлов
это оптимизация, рефакторинг улучшает читаемость кода.
No. 15000    
>>14954

Одно другое не исключает. Рефакторинг - это значительные структурные изменения.
No. 15895    
Бамп годному проекту.
No. 15916    
Файл: 148959312114.gz-(3.60KB, picrelated_tar.gz)
15916
Исправил баги в своей поделке.
No. 15998    
Файл: 149113327037.gz-(4.49KB, picrelated-r21_tar.gz)
15998
Дополнил свою поделку ещё раз.
No. 16002    
оценим, оценим...
и да - для рефакторинга всегда есть место
No. 16017    
>>15998
А теперь пару слов... Почему не Гитхаб, а?
No. 16021    
>>16020
Ну и потому, что я решил использовать у себя дома svn и от гитхаба будет деанон ещё.
No. 16056    
>>15998
Ты ОП? Ну хоть бы написал что исправлно или добавлено.

>>16020
Твоя программа нарушает чьи-то права или патенты?
No. 16071    
>>16056
>Твоя программа нарушает чьи-то права или патенты?
Я уже svn использовать решил. По двум причинам -- искоробочность во фряхе и номера версий вместо хешей.
No. 16072    
>>16071
Ну и незашкваренность хипстерами-вебдванольниками ещё.
No. 16096    
>>16021
> Ну и потому, что я решил использовать у себя дома svn
https://help.github.com/articles/support-for-subversion-clients/
> и от гитхаба будет деанон ещё.
Регаешь на фейкомыло и запрещаешь его показ в настройках аккаунта.
[Назад] [Вся нить] [Последние 50 сообщений]

Удалить сообщение []
Пароль  
[Mod]