Автор Тема: Предложения по будущему системы hcl  (Прочитано 11368 раз)

Оффлайн neobht

  • Завсегдатай
  • *
  • Сообщений: 390
Re: Предложения по будущему системы hcl
« Ответ #30 : 18.07.2017 20:06:05 »
То, что назначение и подход - это я уже понял. Я спрашиваю как раз пояснить в чем там недостатки? Что в подходе не так? В чем неправильность назначения?
Php и отображалки с красивостями мы естественно не сравниваем, сейчас речь о другом. Почему вы считаете, что система в основе которой не лежит субд сможет быстрее давать результат на огромных базах, где быстрые выборки на основе построения специализированных индексов и прочих субдшных фишек быстрого извлечения информации хуже вашей файловой реализации? Может быть просто вы не задумывались еще об этом? И почему практичный и весьма универсальный подход основанный на json для загрузки на сервер информации и который обладает простотой и наглядностью исполнения практически в любых современных реализациях - ни к чему, а применяемый подход у вас гибче?


Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 8 991
Re: Предложения по будущему системы hcl
« Ответ #31 : 18.07.2017 20:40:55 »
Почему вы считаете, что система в основе которой не лежит субд сможет быстрее давать результат на огромных базах, где быстрые выборки на основе построения специализированных индексов и прочих субдшных фишек быстрого извлечения информации хуже вашей файловой реализации? Может быть просто вы не задумывались еще об этом?
Потому, что вы считаете мою систему чистой воды базой. Но это не совсем так. Это система гибридная и она предназначена (в перспективе) под решение разнообразных задач, которые в своем базисе имеют несколько констант, которые, уверен, будут всегда, пока существует процесс альт линукс.
И почему практичный и весьма универсальный подход основанный на json для загрузки на сервер информации и который обладает простотой и наглядностью исполнения практически в любых современных реализациях - ни к чему, а применяемый подход у вас гибче?
Хотя бы потому, что код клиента меняться будет не сильно, протокол обмена меняться не будет. Может быть лишь увеличение количества информации для сбора и основная работа будет на серверной стороне (что в случае тонкого клиента и должно быть). Универсальность выдачи информации сокращает раза в два количество необходимого кода (как мне кажется). При этом всякие навороты вроде диаграм и графиков можно доделать позже.
Если вас терзает json и субд, то вам никто не мешает сделать лучше и быстрее. Я же вам не мешаю делать вещи и не влезаю со своими советами, потому что для меня прерогатива творчества незыблема. Инструментарий уже вторичен в этом смысле.
Я спрашиваю как раз пояснить в чем там недостатки? Что в подходе не так? В чем неправильность назначения?
Всё так для их целей и задач (как я их понял по косвенным признакам). Для тех целей, которые я закладывал, эти решения не совсем подходят (хотя в чём-то они кажутся проще, но устойчивость к вышибанию данных из базы в моем случае выше априори, т.к. в случае повреждения файла базы и без наличия бэкапа данные извлечь без вспомогательных инструментов будет непросто, в моем же случае вся оставшаяся без повреждений база остается невредимой и доступной тут же не отходя от кассы). Это может показаться мелочью в современных реалиях, но я это сознательно закладывал архитектурно в самом начале. Также закладывался принцип минимума внешних зависимостей, в том числе и от самого php интерпретатора, максимальное использование базовых вещей, которые идут в любом дистрибутиве альта. Другими словами, вновь и вновь вы видите, что подход и цели другие, что накладывает отпечаток на используемые решения.
 Может быть поэтому я отличаюсь от "современных программеров", которые отталкиваются от решений решений (типа бэкапа баз штатными средствами, делая реверанс в сторону универсальности применяемых шаблонов). Отчасти поэтому мы имеем с софтом то, что имеем. Когда продумывать архитектуру не надо - мощностей ведь много и они дешевые в массовой статистике. Современное железо отучает думать стратегически, может быть и не всегда, но в массе своей это так за исключением некоторых направлений, где условия более жесткие и по-другому просто нельзя.

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 8 991
Re: Предложения по будущему системы hcl
« Ответ #32 : 18.07.2017 20:54:55 »
Мне начинает казаться, что тема становится похожей на монолог. Это не есть хорошо. Сегодня отправил письмо Михаилу (mike@) с просьбой осветить ситуацию с обсуждением или отсутствием такового. Будем подождать. Не хочется грузить реально занятых людей (у них там хороший перетрях сборочного процесса идёт, а я тут суюсь с кучкой костылей на шелле с пхп) какой-то непонятной поделкой. Нет так нет, не велика беда. Буду хостить пока будет возможность, а дальше посмотрим, но без участия людей толку не будет - востребованности не будет (основной смысл сделать востребованной, а в идеале - используемой в реальности для каких-либо целей, которые будут хотя бы в общих чертах озвучены), а без востребованности не будет и интереса развивать.

Оффлайн neobht

  • Завсегдатай
  • *
  • Сообщений: 390
Re: Предложения по будущему системы hcl
« Ответ #33 : 19.07.2017 15:44:52 »
Вы же не хотите открывать код. Вам не нужны люди. Вы хотите код на официальное сопровождение ООО.
Люди как подтянутся?

По описанным обоснованиям и заложенным принципам и их реализации, я косвенно наблюдаю лишь ряд ошибок ввиду того, что вы не создавали похожие решения. То, что вам кажется преимуществом, вы не видите, как является недостатком в перспективе развития и роста. На мой взгляд развитие программирования и принципов построения информационных систем с каждым годом упрощается и становится более универсальным. Чем больше создаешь систем, тем больше это понимаешь. И если вдруг так случится, что ваш код кто-то начнет развивать, то его перепишут кардинально и вам либо с этим придется согласиться, либо код останется только с вами и не будет иметь развития. Я могу ошибаться конечно и анализирую это со сторлны лишь своего опыта.

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 8 991
Re: Предложения по будущему системы hcl
« Ответ #34 : 19.07.2017 17:39:23 »
Вы же не хотите открывать код. Вам не нужны люди. Вы хотите код на официальное сопровождение ООО.
Люди как подтянутся?
Не на официальное сопровождение, а хостинг чтобы был официальный, с официальным доменным именем (ведь какой-то там ресурс с боку никому не интересен по большому счету). А я из авторов и не выписывался, поэтому продолжу делать доработки, если это потребуется. Правда хотелось бы кого-нибудь более подкованного в php иметь в качестве соавтора (а может даже и не одного человека). Если кто-то возьмет заложенные идеи и перепишет на чем-то другом (и это даст хоть какие-то очевидные преимущества в сравнении с моей поделкой), то я только за. В этом случае мне ничего не помешает изменить лицензию на, к примеру, public domain. Но, похоже, проект канет в лету по той причине, что эта тема, судя по всему, никому кроме меня неинтересна от слова совсем (есть дружеские советы, весьма уместные/полезные и бодрящие слова, но дальше этого дело не идет, к сожалению).