Автор Тема: Обсуждение и предложения по реализации базы данных проб оборудования  (Прочитано 71603 раз)

Оффлайн ksa

  • Модератор глобальный
  • *****
  • Сообщений: 9 049
Спасибо ruslandh и kostyalamer за присланные файлы. Скрипт отправки (тестовый) и ящик более не потребуются (я на это надеюсь). Теперь сосредоточусь на других компонентах с серверной стороны, тут есть над чем подумать и поработать. При этом, конечно, скрипт для пользователя практически готов, но это лишь малая часть (как и приемщик на стороне сервера, который тоже практически готов) и в выкладывании его раньше времени в публичный доступ, на мой взгляд, смысла мало. Но, если есть желающие посмотреть на код заранее и прокомментировать, то могу выложить (пока только скрипт для клиентских машин с не до конца написанным функционалом), правда не сейчас, а несколько позже, т.к. пока не до конца ещё соорудил часть, отвечающую за отправку (плюс тут ещё есть некоторые неразрешенные моменты с точки зрения архитектуры - думаю, есть ли смысл в их реализации или можно сделать эту часть архитектурно независимой и опять же есть ли в этом всем смысл).

Оффлайн ksa

  • Модератор глобальный
  • *****
  • Сообщений: 9 049
Выкладываю рабочий прототип клиента для обмена данными с сервером (~118 строк комментарии, ~129 строк код, остальное - пустые строки отступов).
Что не сделано (и что, соответственно, можно записать в планы, при этом встает вопрос целесообразности):
0) Отправка архива с пробой на сервер (будет в любом случае доделано, потому как это необходимое действие)
1) Отправка комментария к пробе (его можно будет менять, но только тому, кто покажет серверу такую же пробу, как и в предыдущий раз, при этом предполагаю сделать возможность подсовывать скрипту архив со старой пробой, если при посылке комментария повторно конфигурация машины как-либо отличалась). Другими словами, комментарии привязываются к конкретной пробе оборудования
2) Получение от сервера комментария по пробе
3) Со стороны сервера (в смысле обработки полученной информации и её отображении затем в интерфейсе веб-браузера) попробую реализовать поддержку (для начала) железа самого компьютера, без оглядки на периферию типа флешек, камер, фотоаппаратов, телефонов, принтеров, сканеров и т.п., причем пока ещё не углублялся в вопрос с wifi картами и bluetooth устройствами
4) Попробовать сделать обмен с сервером через постоянное соединение (без вызовов единичных экземпляров nc для приема/отправки конкретных составляющих обмена между сервером и клиентом)
Что хотелось бы получить от участников сообщества:
1) Конструктивную критику (для тех, кто умеет читать не только комментарии, но и код) в части предложенного прототипа как такового (алгоритмики)
2) Конструктивную критику в части кода
3) Вопросы (если что-то не совсем понятно из комментариев и хотелось бы получить более развернутый ответ), если таковые будут

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 20 159
    • Домашняя страница
Ты бы в Git это вёл, чтобы патчи присылать было удобнее. И общее описание оборудования (как в inxi и lshw).
Андрей Черепанов (cas@)

Оффлайн ksa

  • Модератор глобальный
  • *****
  • Сообщений: 9 049
И общее описание оборудования (как в inxi и lshw)
К чему это замечание относится (не понял) ?
Ты бы в Git это вёл, чтобы патчи присылать было удобнее
Увы, я с гитом не дружу и аккаунта у меня там нет (и не планируется). Выкладываю я все это не ради патчей (хотя и они приветствуются), а ради более четкого формирования картины всей системы в моей голове, чтобы мне было проще набросать работающие прототипы, работающие из командной строки (пока веб морда не готова). Так можно будет с базой работать и без браузера (планирую такое сделать и все задокументировать прямо в скриптах, потому как отдельно я вряд ли буду писать документацию), чисто из командной строки (если кому-то так окажется удобнее). Правда тут возникнет вопрос удобочитаемого вывода на экран получаемых с сервера данных. Но это дело поправимое. Не я, так кто-нибудь другой сделает опцию "показать красиво" :)
Но чтобы сделать подобное во всей полноте веб морды, понадобится много усилий. Поэтому пока сосредоточусь на архитектуре, чтобы некоторые компоненты можно было уже и не трогать по крупному (пустить в свободное плавание, чтобы их можно было использовать), а сосредоточиться на обработке информации на стороне сервера (там работы больше всего, само собой). Может получиться так, что клиент будет вроде как универсальным (то есть, доставить данные/получить запрос/запросить информацию и получить). Вот и пытаюсь эту матрешку мысленно собрать как можно точнее в деталях, чтобы меньше потом переписывать. С другой стороны, понимаю, что вопрос перезрел и хорошо бы предоставить уже что-нибудь рабочее и готовое к использованию.

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 361
  • Учиться .... Телепатами не рождаются, ими ....
Ну в Git выложить не проблема, могу сам выложить, если мне доверишь.

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 20 159
    • Домашняя страница
Ну в Git выложить не проблема, могу сам выложить, если мне доверишь.
Твой git, тебе и выкладывать. Но лучше пусть автор куда-нибудь на github выложит. Полезно для открытости, отслеживания, доработки и опакечивания будет.
Андрей Черепанов (cas@)

Оффлайн ksa

  • Модератор глобальный
  • *****
  • Сообщений: 9 049
Ну в Git выложить не проблема, могу сам выложить, если мне доверишь.
Твой git, тебе и выкладывать. Но лучше пусть автор куда-нибудь на github выложит. Полезно для открытости, отслеживания, доработки и опакечивания будет.
Погодите, не так быстро :-)
Я, собственно, вот о чём. Правильной ли дорогой я иду? Быть может что-то забыл или делаю что-то не то. Меня это больше всего сейчас интересует (мнение со стороны).
Вот, положим, эта привязка комментария к пробе. Нужна ли она ? С одной стороны, вроде как и нужна (не помешает). Можно хоть как-то гарантировать, что комментарий составлен автором, отославшим пробу. С другой стороны, доступ к комментариям, возможно, будет необходим людям, которые понимают в драйверах, их особенностях и т.п. (бишь продвинутые граждане). В случае привязки доступ второй категории к комментариям будет закрыт (средствами утилиты командной строки), но может быть открыт через веб-морду. Да, если у второй группы товарищей будет архив с пробой, то и у них может быть доступ к комментариям из командной строки. Можно, конечно, все это отбросить и сделать по варианту утилиты из росы (там при отправке пользователь указывает некую метку своей пробы и может потом по ней с пробой что-либо делать, как я это понял, может тут и ошибаюсь). Но мое мнение таково, что чем проще обращение с базой в целом (меньше ключей командной строки не в ущерб функционалу), тем лучше. Может быть хранение архива пробы не так логично по сравнению с хранением некоего ключа (идентификатора), но в первом случае доступ (надо подумать) можно было бы организовать по первой строке (идентификационной), которая отправляется на сервер при отправке пробы на сервер. Плюс архива с собранными файлами в том, что данные для входа (условно пароль/логин) в базу формируются на основе файлов архива без участия человека, т.е. автоматически. Минус в том, что архив нельзя записать на бумажку и ввести в другом месте - его придется таскать с собой (правда при этом, уже после отправки информации о железе и софте в базу, вполне можно из этого архива повыкидывать все лишнее и оставить только то, что нужно для формирования логина/пароля для входа в базу, а, точнее, получения доступа к информации своей пробы; это можно возложить на клиента, но нужно ли?). При этом можно и имя архива поменять и собрать все файлы в архиве без вложенных директорий (это тоже скрипт позволяет делать).
Да, ещё такой момент. Я все это затеял ещё и потому, что попутно хотел иметь возможность протестировать две системы хранения информации. Одну для утилиты командной строки (report-sender + серверная часть и это будет работа с хранилищем), а вторую для "базы данных" (где я подумываю использовать одну из баз, если получится разобраться и вникнуть в tcl), где будет зеркальная хранилищу информация, просто представлена она будет несколько иначе с точки зрения организации. Но это я уже замахиваюсь на Вильяма нашего, Шекспира, чего может и не стоит делать. А база та есть в каждом дистрибутиве альт линукс и она весьма кстати (с моей точки зрения) подходит для поставленной задачи. Другой вопрос, что инструментарием для её использования я пока не владею, поэтому и веб морда в планах после утилит командной строки вместе с составляющими серверной части (чтобы можно было уже работать, а "красоту" веб морды задействовать после, по мере готовности).
PS Вопросы/предложения/замечания можете и на почту слать, если лень на форум заходить. Почта в профиле должна быть, также она есть в заголовке выложенного рабочего прототипа.

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 20 159
    • Домашняя страница
Увы, времени столько читать и смотреть код у меня нет.
Андрей Черепанов (cas@)

Оффлайн ksa

  • Модератор глобальный
  • *****
  • Сообщений: 9 049
Увы, времени столько читать и смотреть код у меня нет.
Тогда хотя бы по части функционала (того, что я в предыдущем сообщении написал). Взгляд со стороны мне сейчас более важен (поэтому и первым пунктом стоит в обратной связи), а за кодом дело не станет, когда картина ясна и понятна.

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 361
  • Учиться .... Телепатами не рождаются, ими ....
a="Architecture:"
arch=$(lscpu|sed -n "/$a/p"|sed "s/$a *//")
В coreutils есть такая команда - arch, пример:
arch=`arch` ; echo arch=$arch
arch=x86_64

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 361
  • Учиться .... Телепатами не рождаются, ими ....
Вообще-то конструкция $(команда) - работает только в bash, для совместимости с другими shell лучше применять в скриптах команду
`команда`

PS для форума всегда пишу $(команда), по одной причине - ` легко перепутать по внешнему виду с '

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 361
  • Учиться .... Телепатами не рождаются, ими ....

Оффлайн ksa

  • Модератор глобальный
  • *****
  • Сообщений: 9 049
Вообще-то конструкция $(команда) - работает только в bash
Тогда может на баш и завязаться ?
для совместимости с другими shell лучше применять в скриптах команду
`команда`
И много дистрибутивов не используют баш ? В альте-то точно баш в поставке по умолчанию присутствует.
Если никто не против, поместил сюда скрипт:
Я не против, но смысла в этом мало. Разве только для того, чтобы не потерялось и знатоки git могли себе его клонировать :)

Оффлайн ksa

  • Модератор глобальный
  • *****
  • Сообщений: 9 049
Ещё сейчас посмотрел скрипт в гите у Руслана. Увидел ошибку в выдаче кода возврата для отсутствующего пакета (или пакета не той версии - я как раз обработку ошибок переписывал полностью и, видимо, этот момент упустил). Прототип он прототип и есть (не альфа и не бета, а прототип, чтобы обсудить функционал, что мне более важно, чем поиск ошибок, т.к., если окажется, что движение идет не в ту сторону, то возможно придется многое переписать и вновь написанный код может иметь мало общего с этим прототипом).

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 361
  • Учиться .... Телепатами не рождаются, ими ....
Ну вот - и смысл нашёлся - посмотрел на скрипт со стороны и ошибку нашёл :-)