Ну собственно выучить как правильно ходят шахматные фигуры это сильно далеко от того чтобы хорошо играть в шахматы. Вот и в современном программировании и его преподавании всё больше и больше фигур и правил и всё меньше реальной работы программиста. По сути работа программиста это ремесло мыслительной дисциплины и устремлённости а из них делают какихто суперэрудитов набитых до умопомрачения никому не нужным синтаксическим сахаром и экзотическими парадигмами. Причём иногда бывает что доходят до настоящего умопомрачения...
Как мне кажется всё это не хранилища а системы для работы именно с log-файлами. Ну да, на борту у них множество инструментов для упрощения и ускорения поиска. Но в настоящей БД данные будут индексироваться и сжиматься де-факто и плюсом разграничение доступа.
Недостаточно компетенций? А что собственно можно ещё ожидать если мы уже 30 лет платим преподавателям всех уровней примерно как дворникам и уборщицам? В итоге необученные люди не работают по специальности и не приобретают нужные навыки а те скудные навыки которые были теряют. И чё то мнится мне что никакой матчинг этим эйчарам не поможет...
Так наоборот же - закинул sql скрипт и вот у тебя уже готовая статистика ну например по клиентам со временем сессии длиннее среднего в 10 раз. Или с большим количеством запросов в одной сессии. Да что угодно можно отследить а потом запросить транзакции той сессии которую надо рассмотреть подробно. При использовании единого log-файла без дополнительных костылей это не получится да и с костылями непросто
Интересно кто нибудь из серьёзных игроков задумывается о том чтобы отказаться от системы логов? Держать всё в неиндексированном, неархивированном представлении безо всякого разграничения доступа по нынешним временам выглядит дико. Разумнее для клиентских сеансов или транзакции или ещё чегото такого создать в какой нибудь стандартной БД стандартную связку таблиц типа "идентификационные и входные данные"-"история изменений и действий" по аналогии как в банках в одной таблице хранят номера счетов и данные владельца а в другой историю транзакций всех счетов. И выборка будет средствами БД и сжатие и разграничение доступа. В логи нужно будет писать только информацию об аварийных событиях которые требуют обязательного расследования.
а кто или что обращалось за информацией из этой сущности по зашифрованному индексу полного наименования сущности?... или клиент с ключом просто получает весь список и ищет что нужно?... тогда зачем сортировать пусть он сам в экселе отсортирует...
возможно я чтото лишнее уже спрашиваю инфобез дело такое тогда лучше не отвечайте
Тогда просто индексировать по хэшу названия. Но зачем это вообще? Название целиком врядли ктото знает точно а начало названия это вообще обычно стандартные "распоряжения" "соглашения" "контракты" то есть абсолютно неинформативные вещи. По смыслу индексы надо строить по номеру, дате и тегам.
Ну FOR цикл это древнейший пример синтаксического сахара. DO-WHILE цикл может заменить его в любых ситуациях. Вообще то что сейчас твориться с языками программирования это какойто ужас. Уже давно ценится не умение кодить а знание кучи мешков синтаксического сахара и здоровенного склада набитого "стандартными типами" которыми, как считается, должен обзавестись каждый уважающий себя язык программирования. Все давно забыли что стандартный тип должен уметь набить на коленке любой, хоть сколько нибудь вменяемый, программист а великое и могучее ООП это по сути простенькие манипуляции с пространствами имён...
Первое что в голову приходит это всё таки раскрыть какоето количество символов в начале ключа. Ну например если разговор про фамилии то пару символов вполне можно. Если обратиться надо по номеру счета или например паспорта то наверное можно просто хэш. Вообще непонятно както в каких условиях может потребоваться такая сортировка и для чего...
Тут недавно пост был про XB-70 "Валькирия" мне там одна фраза понравилась - "но тогда так не работали". В контексте "...кусок обшивки только что вылетел. Сейчас бы наверное программа такого уровня риска не дожила бы до второго прототипа её бы закрыли на третьем серьёзном инциденте. В 1960-х так не работали...". Когда "апполоны" летали их в одну каску пересобирали на орбите в критически ограниченное время и это была штатная процедура а теперь просто перестыковать модуль это прям сложно сложно.
А по мне изначально была бестолковая идея. Ладно бы как перевалочная станция для дозаправки и/или сборки лунных и более далёких кораблей или других тяжёлых спутников которые целиком не запустить. Ну или хотябы какието производства которым необходима невесомость и/или глубокий вакуум. А так кучка бездельников причём очень дорогих бездельников. За всё время существования и масса там уже по моему 400 тонн а по искусственной гравитации ничего даже не пытались а уж чего проще - собери кольцевой модуль и пусти там по кругу полку с кроватями и уже можно спать по человечески а кровати убрал и бегай на здоровье но за все эти года даже этого не удосужились...
хаха)... ну да, шарп хороший язык если бы не его фреймворки...
А так то ну java она и есть java. Когдато помню презирал языки с уборкой мусора и считал что win7 это для пижонов) но это прошло... Тем более в шарпе можно если надо сместиться на довольно таки низкий уровень кодинга.
А про извраты с проводником - кто придумает строить многомерную структуру из файлов возможно с учётом частоты использования и может быть даже по типу векторного пространства токенов в LLM и даст возможность юзеру в выбранных измерениях масштабировать и передвигаться тот свершит революцию... Никому не нужную революцию. С файлами по моему никто практически всерьёз не работает чтоб прям дерево с понятными и строгими ветвями. Работают с поиском. Многие даже не знают где их рабочие данные находятся - открывают пишут сохраняют админ бэкапит вот и всё.
Ну зато это настоящая графика а не псевдосимволы какие нибудь.Ну а память конечно жалко в ZX треть оперативки отдай. Хотя ничего в принципе не мешало загнать в видеопамять код или данные и работать себе не заморачиваясь.
У него в буфере были коды символов из которых сложная электроника формировала на экране изображения. А идея именно в том чтобы простенькой схемой гнать на экран содержимое оперативной памяти "как есть" не заморачиваясь с распознаванием того что там записано.
Венчурные проекты это такая штука в которую нельзя заходить "на всю котлету". И если уж чтото выстрелило то доить эту корову лучше до последнего а не метаться в поисках новой. А так то конечно респект мужику за ZX spectrum. Главное изобретение там конечно было формировать изображение на экране выбирая биты из RAM. Интересно кто это первый придумал...
Интересно бы с безколлекторным двигателем поработать причём на низком уровне чтобы. А тут я как то даже не до конца понимаю зачем дополнительная плата? Для управления током есть стандартные решения. Наверное подсчёт оборотов ещё идёт как то хотя для шаговика это без надобности вроде...
Конечно на этапе компиляции это ещё лучше чем при выполнении. Но разговор то про то что сама концепция вредоносна. Вон например в Котлине есть возможность завести типы которые не могут быть null то есть вынуждают заполнять неинициализированные ссылки ссылками на какой нибудь dumb а потом какой нибудь модуль может решить что этот dumb вполне себе "живой" объект и начать с ним работать ну и пошло поехало...
кстати ну вот не припомню чтобы null поганил память если можно обрисуйте механику...
А вот с этим как раз не соглашусь. NPE это сигнал что программа работает не так как должна. И чем раньше это выяснится тем лучше. А вот если NPE будет както замаскированно или автоисправлено или ещё чтото подобное и программа с ошибкой "на борту" похромает кудато дальше то кончиться всё это может хуже чем просто поиск ошибки в коде.
да и вообще эти null-terminated string это вещь про которую можно сказать что если бы её никогда не существовало то всем на белом свете было бы легче жить)
Помню они меня так достали в C++ что я написал класс обёртку c операторами приведения во все разумные типы чтобы вообще никогда их не использовать... а потом пол года ещё дебажил сам этот класс)
Ну собственно выучить как правильно ходят шахматные фигуры это сильно далеко от того чтобы хорошо играть в шахматы. Вот и в современном программировании и его преподавании всё больше и больше фигур и правил и всё меньше реальной работы программиста. По сути работа программиста это ремесло мыслительной дисциплины и устремлённости а из них делают какихто суперэрудитов набитых до умопомрачения никому не нужным синтаксическим сахаром и экзотическими парадигмами. Причём иногда бывает что доходят до настоящего умопомрачения...
Как мне кажется всё это не хранилища а системы для работы именно с log-файлами. Ну да, на борту у них множество инструментов для упрощения и ускорения поиска. Но в настоящей БД данные будут индексироваться и сжиматься де-факто и плюсом разграничение доступа.
Недостаточно компетенций? А что собственно можно ещё ожидать если мы уже 30 лет платим преподавателям всех уровней примерно как дворникам и уборщицам? В итоге необученные люди не работают по специальности и не приобретают нужные навыки а те скудные навыки которые были теряют. И чё то мнится мне что никакой матчинг этим эйчарам не поможет...
Так наоборот же - закинул sql скрипт и вот у тебя уже готовая статистика ну например по клиентам со временем сессии длиннее среднего в 10 раз. Или с большим количеством запросов в одной сессии. Да что угодно можно отследить а потом запросить транзакции той сессии которую надо рассмотреть подробно. При использовании единого log-файла без дополнительных костылей это не получится да и с костылями непросто
Интересно кто нибудь из серьёзных игроков задумывается о том чтобы отказаться от системы логов? Держать всё в неиндексированном, неархивированном представлении безо всякого разграничения доступа по нынешним временам выглядит дико. Разумнее для клиентских сеансов или транзакции или ещё чегото такого создать в какой нибудь стандартной БД стандартную связку таблиц типа "идентификационные и входные данные"-"история изменений и действий" по аналогии как в банках в одной таблице хранят номера счетов и данные владельца а в другой историю транзакций всех счетов. И выборка будет средствами БД и сжатие и разграничение доступа. В логи нужно будет писать только информацию об аварийных событиях которые требуют обязательного расследования.
а кто или что обращалось за информацией из этой сущности по зашифрованному индексу полного наименования сущности?... или клиент с ключом просто получает весь список и ищет что нужно?... тогда зачем сортировать пусть он сам в экселе отсортирует...
возможно я чтото лишнее уже спрашиваю инфобез дело такое тогда лучше не отвечайте
Тогда просто индексировать по хэшу названия. Но зачем это вообще? Название целиком врядли ктото знает точно а начало названия это вообще обычно стандартные "распоряжения" "соглашения" "контракты" то есть абсолютно неинформативные вещи. По смыслу индексы надо строить по номеру, дате и тегам.
Ну FOR цикл это древнейший пример синтаксического сахара. DO-WHILE цикл может заменить его в любых ситуациях. Вообще то что сейчас твориться с языками программирования это какойто ужас. Уже давно ценится не умение кодить а знание кучи мешков синтаксического сахара и здоровенного склада набитого "стандартными типами" которыми, как считается, должен обзавестись каждый уважающий себя язык программирования. Все давно забыли что стандартный тип должен уметь набить на коленке любой, хоть сколько нибудь вменяемый, программист а великое и могучее ООП это по сути простенькие манипуляции с пространствами имён...
Первое что в голову приходит это всё таки раскрыть какоето количество символов в начале ключа. Ну например если разговор про фамилии то пару символов вполне можно. Если обратиться надо по номеру счета или например паспорта то наверное можно просто хэш. Вообще непонятно както в каких условиях может потребоваться такая сортировка и для чего...
Тут недавно пост был про XB-70 "Валькирия" мне там одна фраза понравилась - "но тогда так не работали". В контексте "...кусок обшивки только что вылетел. Сейчас бы наверное программа такого уровня риска не дожила бы до второго прототипа её бы закрыли на третьем серьёзном инциденте. В 1960-х так не работали...". Когда "апполоны" летали их в одну каску пересобирали на орбите в критически ограниченное время и это была штатная процедура а теперь просто перестыковать модуль это прям сложно сложно.
А по мне изначально была бестолковая идея. Ладно бы как перевалочная станция для дозаправки и/или сборки лунных и более далёких кораблей или других тяжёлых спутников которые целиком не запустить. Ну или хотябы какието производства которым необходима невесомость и/или глубокий вакуум. А так кучка бездельников причём очень дорогих бездельников. За всё время существования и масса там уже по моему 400 тонн а по искусственной гравитации ничего даже не пытались а уж чего проще - собери кольцевой модуль и пусти там по кругу полку с кроватями и уже можно спать по человечески а кровати убрал и бегай на здоровье но за все эти года даже этого не удосужились...
хаха)... ну да, шарп хороший язык если бы не его фреймворки...
А так то ну java она и есть java. Когдато помню презирал языки с уборкой мусора и считал что win7 это для пижонов) но это прошло... Тем более в шарпе можно если надо сместиться на довольно таки низкий уровень кодинга.
А про извраты с проводником - кто придумает строить многомерную структуру из файлов возможно с учётом частоты использования и может быть даже по типу векторного пространства токенов в LLM и даст возможность юзеру в выбранных измерениях масштабировать и передвигаться тот свершит революцию... Никому не нужную революцию. С файлами по моему никто практически всерьёз не работает чтоб прям дерево с понятными и строгими ветвями. Работают с поиском. Многие даже не знают где их рабочие данные находятся - открывают пишут сохраняют админ бэкапит вот и всё.
Ну зато это настоящая графика а не псевдосимволы какие нибудь.Ну а память конечно жалко в ZX треть оперативки отдай. Хотя ничего в принципе не мешало загнать в видеопамять код или данные и работать себе не заморачиваясь.
У него в буфере были коды символов из которых сложная электроника формировала на экране изображения. А идея именно в том чтобы простенькой схемой гнать на экран содержимое оперативной памяти "как есть" не заморачиваясь с распознаванием того что там записано.
Венчурные проекты это такая штука в которую нельзя заходить "на всю котлету". И если уж чтото выстрелило то доить эту корову лучше до последнего а не метаться в поисках новой. А так то конечно респект мужику за ZX spectrum. Главное изобретение там конечно было формировать изображение на экране выбирая биты из RAM. Интересно кто это первый придумал...
Интересно бы с безколлекторным двигателем поработать причём на низком уровне чтобы. А тут я как то даже не до конца понимаю зачем дополнительная плата? Для управления током есть стандартные решения. Наверное подсчёт оборотов ещё идёт как то хотя для шаговика это без надобности вроде...
Спасибо за информацию. Никогда не знал что через null можно обратиться к методу. Как страшно жить)...
а про ссылки равные null ну например разреженный массив но чтобы не в виде коллекции с перегруженным [] а именно с индексным доступом.
Конечно на этапе компиляции это ещё лучше чем при выполнении. Но разговор то про то что сама концепция вредоносна. Вон например в Котлине есть возможность завести типы которые не могут быть null то есть вынуждают заполнять неинициализированные ссылки ссылками на какой нибудь dumb а потом какой нибудь модуль может решить что этот dumb вполне себе "живой" объект и начать с ним работать ну и пошло поехало...
кстати ну вот не припомню чтобы null поганил память если можно обрисуйте механику...
А вот с этим как раз не соглашусь. NPE это сигнал что программа работает не так как должна. И чем раньше это выяснится тем лучше. А вот если NPE будет както замаскированно или автоисправлено или ещё чтото подобное и программа с ошибкой "на борту" похромает кудато дальше то кончиться всё это может хуже чем просто поиск ошибки в коде.
да и вообще эти null-terminated string это вещь про которую можно сказать что если бы её никогда не существовало то всем на белом свете было бы легче жить)
Помню они меня так достали в C++ что я написал класс обёртку c операторами приведения во все разумные типы чтобы вообще никогда их не использовать... а потом пол года ещё дебажил сам этот класс)