Как стать автором
Обновить
8
0
Александр @SubarYan

Программист

Отправить сообщение
Для датасета я написал свое веб-приложение. Я упоминал это в статье. Там есть возможность редактирования токенов, как одиночно, так и множеством.

Вот основные функции этого приложения:
  • Загрузка файлов PDF/DOC/DOCX
  • Файловый менеджер для работы с документами
  • Парсинг файлов PDF/DOC/DOCX в обычный текст
  • Запрос к запущенной модели BERT на DeepPavlov с исходными текстами резюме
  • Сохранение результата от DeepPavlov в промежуточную БД для датасета
  • Редактирование данных для датасета в ручном режиме
  • Сохранение датасета
  • Интерфейс для проверки с маркировкой по сущностям


Есть мысли о сборе данных извне, интеграция с LinkedIn или HH.
Как вы правильно заметили, precision — это точность, в данном случае это точность распознавания для модели в целом.
precision: 76.32%;

Значение неплохое, но может быть лучше, это все зависит от качества датасета.
Думал об этом тоже. Собственно поэтому и статью написал.
А в чём именно вы находите преимущество использования Visual Studio для разработки на Python? Почему не PyCharm Community Edition или VSCode?

Преимуществ по факту никаких. Это кто в чем привык работать.
Для чего это? Насколько я помню, deeppavlov и все зависимости для него есть в предсобранных wheel-пакетах и компилировать ничего не нужно. То есть компилятор (MSVC в вашем случае) не понадобится.

При установке nVIDIA CUDA есть эта зависимость.

Потому-что браузер кроме HTML ничего не понимает. Но этот Hugo только статику генерирует в чем его сила?

Решил делать всё на Spring Rest, а для UI взять готовые сверстанные шаблоны. Плюс есть свой небольшой фреймворк.
Я назвал это «проблемой» не объективно, соглашусь. Есть реализации и мы научились с этим жить. Цель статьи только одна взглянуть на веб-разработку под другим углом, и увидеть возможные альтернативные решения для существующих технологий.
Хорошо, я напишу по-другому. Если бы была предложена альтернатива «удобнее»(*) чем HTML вы бы стали ее использовать?

(*) Удобнее я имею в виду что только одними тэгами(без CSS и JS) вы смогли бы собрать полноценный сайт с переходами по страницам без перезагрузок и с синхронизацией интерфейса с данными, а также и визуальными эффектами на страницах.
Безусловно Vaadin ускоряет разработку, но есть проблемы.

Я работал также с Vaadin 8, он еще основан на GWT. И я очень быстро собрал сложный интерфейс с кучей форм и гридов без написания CSS и JavaScript. Также много готовых компонентов написало сообщество разработчиков. В ситуации с Vaadin 14 все происходит иначе. Разработчик данного фреймворка начиная с версии 10 решил отказаться от использования GWT, поскольку проект старый и не развивается.

Разработчики Vaadin написали свой Vaadin Flow с использованием Polymer WebComponents. Фреймворк стал гибче.

Но при написании своего Polymer компонента и внедрения в него других JS библиотек возникают проблемы с конфликтом версий в npm.

Babel для сборки Vaadin компонентов имеет старую версию, и если ваша библиотека не может быть собрана с этой версией, а ей нужна новее, то возникает проблема. Меняя на версию новее перестают собираться компоненты от Vaadin Flow.

Поэтому мне пришлось отказаться от использования данного фреймворка в своем проекте.
Но речь не о том, на чем лучше писать, а речь о том есть ли «золотое сечение» для удобной, скорой и качественной разработки для нас с вами дорогие веб-разработчики.

Напишу кратко о сути проблемы в комментарии.
CSS в целом, том числе и про классы. Да дело не в том как это удобнее технически, я рассуждаю как о проблеме в целом.

Дизайн я обычно использую из сверстанных шаблонов, там всё всегда грамотно скомпоновано, и классы нужные есть, и библиотеки подключены. Я сам не верстаю.
Семантические теги по факту те же самые div, смысл в том что на визуальное отображение они никак не влияют. А ситуация такова что куча шаблонных сайтов с боковыми выплывающими меню и прибитыми хедерами, но тегов для боковой панели, или для прилипающего хедера до сих пор нет. Вот и приходится постоянно те же самые <header/> описывать в CSS чтобы прилипало при скролле, или вообще чтобы всегда к «потолку» был прибит гвоздями.

Вот и остается одна мотивация использовать только для SEO целей, да и то насколько эффективно это еще вопрос.
Нужна гибкая CMS, которая позволит любой дизайн от дизайнера, извините за каламбур, прикрутить к данным, используя дэшборд админки в браузере. Работаю сейчас над такого рода CMS, первую версию уже удалось выпустить.
Конструктор полностью свой. Реализация очень простая. В приложении клиента есть view в котором подключен Java-класс который принимает на вход два параметра по GET, это id-сайта и id-страницы по REST я достаю из MongoDB список виджетов, по сути название файла который по include во view будет подключен. По аналогии CSS и JS также. Всё файлы храню в MongoDB. Сейчас есть задумка и на файловой системе хранить.
Перенес комментарий в ветку.
Пока в поисках. Я ожидал уже что нашел, но попробовал и понял что это не совсем то что хотел. Но все же я поделюсь своими опытами.

1. На данный момент в приложении я использую MongoDB и слой работы с данными написан с использованием Weld CDI. Я бы хотел переписать все на Spring Data в интерграции с MongoDB. Тем самым выкинув все этот самописный код. Я думал что проблема которая возникает с SessionScope связана с моей имплементацией, но последние пару дней после эксперементов и фиксов, я понимаю что в этом плане там написано все замечательно. И все подозрения падают на работу этого AJAX-фреймворка ZK Framework. Далее пункт 2 о нем.

2.ZK Framework этот фреймворк очень удобен в плане шаблонизации. Можно легко брать статично свёрстанный HTML и вставлять во view и уже подключать java-бины и спокойно связывая UI с работой бекэнда. Причем все управление данными на бекэнд и синхронизацию UI берет на себя этот фреймворк. Тем самым легко разделить зоны ответственности работы в приложении. Вообщем принцип похож на JSF. Но есть в этом подходе минус, то что генерация CSS и JS от фреймворка происходит каждый раз при запросе страницы. И время загрузки страницы увеличивается, что визуально раздражает, — страница не имеет сложной структуры, а приходиться ждать секуду задержки. Разработчики позиционируют использования фреймворка как onepage-дизайн. В таком подходе он работает быстро. Потом еще был грустный факт что в последней сборке от ZK Framework'a я нашел небольшой баг, не кретичный, но добавил желание этот фреймворк не использовать больше. Я вместо него сейчас исследую Vaadin Flow 14. В целом неплох, но разработка UI сложнее и дольше.

3. У меня есть самописный слой на JAX-RS(REST API), хочу этот слой заменить на GraphQL. Тем самым упростив получение объектов разных структур лишь изменив параметры запроса.

4. Напоследок нужно изменить приложение клиента которое через REST достает данные из MongoDB, собственно сам результат сборки страниц в CMS это и работа этого приложения. Оно также использует ZK Framework. Хотелось бы использовать только клиентскую технологию, что-то типа ReactJS. Но пока в этом не уверен что это решение лучше.

Как-то так, буду рад услышать ваши размышления на этот счет.
Согласен, но там нет того что я хотел бы видеть. К примеру реализация REST-интерфейсов, надо под каждый сервис писать PHP-класс. В Drupal хоть можно через Views все в админке сделать.

Проблема номер 2, как создать каркас объекта из админки? Я говорю сейчас о объектах в базе данных.

Проблема номер 3, как заверстать купленный HTML-шаблон на Envato в логику данных из админки Wordpress? Я имею ввиду чтобы натянуть дизайн страниц из шаблона на логику данных.

Проблема номер 4, как сделать файловое хранилище через админку? Ну окей, это есть, но это на файловой системе, я использую mongodb для хранения картинок и файлов.
Не совсем только понял почему «Product Hunt назвала OneSoil Map продуктом года в категории AI & Machine Learning». Вы где-то используете нейронные сети в своем проекте?
Все прочитал, есть моменты с которыми не согласен (речь о деталях реализации для MVP, и 3-х колесном автомобиле), но в целом имеет место быть. В жизни всё так и есть. Спасибо за столь подробный коммент.

То что меня подтолкнуло написать свою CMS, это конечно «дубовые» реализации существующих CMS, хотелось уйти от этих рамок, своего рода соревнование с самим собой, смогу ли я сделать то, что я хотел бы использовать. Ту CMS мечты, с которой можно вздохнуть полной грудью.

Информация

В рейтинге
Не участвует
Откуда
Düsseldorf, Nordrhein-Westfalen, Германия
Дата рождения
Зарегистрирован
Активность