Данные выкатываете в лог файл. Ваша визуализация для «нормальной» работы не нужна - вы же не будете целый день смотреть на панель. Далее пишите скрипт который раз в день, парусит лог и отправляет вам е-mail если канал упал.
Меньше чего поддерживать/настраивать не говоря о том что работать будет 24x7 и 1000 лет. А в вашей графине/докере и т.д. Завтра выкатят несовместимое обновление и все рухнет.
На днях оказалось что родной vagrant не работает с последнее версией VirtualBox- никогда такого не было и вот опять.
Плюс сколько ресурсов у вас отжирает ваш набор сервисов и сколько будет жрать один iperf3 с парой скриптов?
А ещё есть флоппонет- можно с диском зайти к друзьям, которые уже достали свежие видео. Заодно и потусить с кофе/пивом. А-то вас бы все в интернетах сидеть.
По поводу ускорения чтения из была данных для рендеринга сообщений.
Самым очевидно способом будет создать ещё одну таблицу в которую писать данные относящиеся к +/-100 сообщениям относительно текущего. И просто выбирать все данные для отображения на экране одним запросом Типа. select * from chat_view; И рендерите себе спокойно.
Пользователь все-равно всю историю сообщений не видит, и изменения в них соответсвенно тоже.
Если он прокрутил вверх/вниз экран, заполняем таблицу другой порцией сообщений и снова рендерим. Пока он пальцем по экрану будет водить можно все пере писать и пересчитать….
Если таблицу сделать временной, то даже удалять данные не придётся DB все сама сделает.
Честно говоря у меня вопрос по замеру производительности запросов: Запускать два селектора последовательно и мерить скорость нельзя - оптимизатор запросов будет подготовлен к выполнению похожего запроса и кеш базы данных будут заполнены данными ( холодный кеш vs горячий кеш)
Далее выбор всех строк из таблицы - явно ресурсоёмкая операция при количестве столбцов >X и размере данный > Y (подробности зависят от размера блока в БД, размера кластера на диске и т.д.)
Далее если вы вбираете 3 поля из таблицы то результат может зависеть от того являются ли эти поля частью индекса и как построен индекс, так как если вам повезёт, то БД просто отдаст данные из индекса, без обращения к самой таблице.
Например: поля в таблице: a,b,c,d,…h Индекс построен по столбцам a,b,c,d
Если выбираем столбца a,b,c - нам повезло все данные из индекса. Если добавим поле f - придётся лезть в базу данных и скорость упадёт.
Вопрос что будет при выборе a,b,d - зависит от вашей базы данных. Некоторые умеют выдавать столбцы из индекса игнорирую пропущенные, некоторые нет.
Если у вас ORM - то вы вообще не понимаете что происходит на уровне базы данных, и это для вас :(
В общем, дело ясное что дело темное. Похоже вы добились улучшения на тестовом наборе данных, но не факт что скорость улучшиться на «реальных» данных.
Опять таки, могу предположить что операция записи в БД гораздо быстрее чем операция отсылки сообщения - нет сетевых задержек, не надо устанавливать соединение.
То что вы клиенту показали что сообщение сразу отправлено- не то же самое что сообщение фактически отправлено.
И тем более не равно утверждению что оно дошло до адресата.
Тут статьи написанные ChatGpt ругали, а похоже зря …
Придётся мне за него поработать и summary сделать:
Разрабатывали сервис для клиента
Использовали vie.js для фронта
Использовали python для back-end, но это не точно
Строго следовали требованиям и стандартам заказчика, поэтому использовавши компоненты из его стандартных библиотек
Заказчик вроде как использует SQLAlchemie, мы ее тоже стали использовать, потому что заказчик сказал. потом ее выкинули и за день переписали все используя Tortoise Orm - она асинхронная «в них есть электролиты». Заказчику похоже не сказали.
У заказчики стоит свой гитлаб, куда мы скриптом пихали свои версии из нашей VCS (какой? А Черт ее знает)
ТЗ сразу выкинули, заказчик пересматривали требования, объём работ поплыл, но проект сдали. Что с бюджетом - а кто его знает. …
А ещё у заказчика gRPC используется для синхронизации между сервисами. … (к чему бы это?)
Да, кстати, я вообще-то IT директор а эта статья про управление проектами.
Вместо этого хотелось бы услышать про:
архитектуру
Постольку приложение вроде как медицинское- про работу с пользовательскими данными, которые более чем «персональные данные» и требования к ограничению доступа к которым строже.
Примерное количество пользователей - чтобы нагрузку оценить. 4 если уж SQLAlchemie выкинулись поскольку неполногласие- почему и что конкретно в Torguse ORM лучше кроме того что она асинхронная.
Согласен. Статья не о чем и логически не выверена. Если нейросеть сгенерировала фото которое мы признаём deep-fake, какая может быть защита частных данных? Как доказать что это конкретное изображение Маши или Пети а не «лица похожего на генерального прокурора..» Это же нейросеть нагенерила.
Кстати, читайте историю, Херлуф Битструп - художник карикатурист, которого очень любили в СССР, в своё время занижался иллюстрацией книжки про французских чиновников которые сотрудничали с нацистами. Все имена были изменены чтобы избежать привлечения к ответственности за клевету, но иллюстрации сохраняли портретное сходство.
Художнику ничего не грозило, поскольку он своих героем может изображать как хочет.
Так что если вы напишете под deep-fake фото: Маша Иванова из 10а, то возможно вам что-то будет. А если напишете Маша из 10а. До доказать что-то будет проблематично.
Fossil? Не засоряет все что можно скрытыми папками с данными, а спокойно держит все в отдельном файле SQLite. Тут много найдётся специалистов, которые могут гитом без гит-хаба, гит-лаба пользоваться? Чтобы хотя бы в команде из 3-Х человек кодом обмениваться?
Одели чего? Я тут за бугром - лампочки покупал в обычном дискаунтере Для управления поливом воды - Gardena - берите любой Реле времени - купил на Амазоне :)
Ещё и радиатор отопления воткнул через разъём который с термометром интегрируется - брал на Амазоне первый попавшийся.
Поскольку все «само по себе работает» все равно что брать. Если что-то отвалилось - выкидываете, покупные другой фирмы. Все меняется быстр и безболезненно.
Но мне в приципе мониторинг по телефону не нужен. Во первых на даче интернета нет. Можно роутер с карточкой воткнуть, но зачем? И во вторых, для меня умный дом это не когда я постоянно кнопки жму включать/ выключить, а когда один раз настроил и оно работает.
Соответственно система должна быть максимально децентрализованной и максимально использовать датчики.
То-ли я староват, то-ли программеры нынче не те. Делаем устройство управления умным домом - у автора управление в том числе «критической инфраструктурой» насос, отопление, освещение.
Первым делом навешиваем все на центральный сервер, и подключаем управление по интернету. Если сервер накрылся- всему дому хана. Если отключили электричество всему дому хана.
Делал у себя на даче «полоумный» дом.
1 освещение - LED фонари с солнечной батареей и датчиком движения. Светят как хорошие прожекторы. Цена 10 евро максимум. Включается когда на улице темно и есть движение. В нескольких моделях есть режим подсветки - горит постоянно когда темно. Больше трёх лет - полёт нормальный.
Полив газона - «водяные часы» устанавливаются на водопроводную трубу. К ним подключается датчик влажности у меня проводной, но есть и беспроводные.
Газон поливаем по расписанию. Если пошёл дождь- датчик отключит полив.
Полив в теплице - реле времени, которое включает насос и качает из бочки в бак в теплице. Время насчитано экспериментально.
Ни интернета ни wifi все работает само по себе уже 3 года.
Вообще-то то вы тут не правы, а предыдущий автор вполне прав. Символ разделения дробной и целой части на калькуляторе не имеет значения. Как и символ разделения разрядов. Достояно не использовать для разделения разрядов . Или , и у вас нет проблем с в 99.9 случаев. Даже если вы используете . И , то через 2 минуты пользования калькулятором пользователь поймёт что к чему.
Далее моя целевая аудитория - космонавты на МКС. Соответственно 99% ваших требований летит в корзину так как они очевидны. Более того, поскольку МКС - международная станция, вам прямой путь к скинию ISO норм по отображению цифр, разрядности системы
В ы в своих требованиях допустили ошибку/ у вас только 4 арифметических оператора. В то время как на обычном калькуляторе есть ещё операция смены знака (*-1) которая сильно упрощает расчеты.
Ещё одним вариантом постановки ТЗ на разработку калькулятора - вы делаете улучшенный аналог а не принципиально новое устройство, было бы привести ссылки на существующие образцы, сказать что сделано не так и что надо улучшить. В результате пользы будет больше а бесполезного текста меньше.
Кроме того, если. Включить «дурочку» то под ваше ТЗ подходит калькулятор работающий в любой система счисления с основанием меньше или равным 10. Так что не удивляйтесь, что когда ваш QA введёт пример 1+1 он получит 10 в качестве ответа.
Они ответ дали. В начале статьи: дети из богатых семей получают лучший доступ к дополнительному образованию. Остальное - как мертвому припарки. Если я могу нанять своему ребёнку репетитора, отправить на дополнительные занятия или купить больше книжек, то тот кто этого не может не сможет конкурировать.
Как задачи не переписывай -результат не изменится.
Не спасут. У задаст про еду и деньги глубокие корни: Берём книжку «Витя Малеев в школе и дома» задачи: сколько стоили пилы и топоры, стольк орехов собрали датчик и девочка, сколько стоит пробка и бутылка… Если уж в СССР все задачи вокруг денег вертелись, то что о капиталистических странах говорить …. :)
Это вы про Joplin? Про потерю замёток не скажу. Хотя возможно аттачить теряет - я тут базу замёток из Evernote импортировал. Периодически фигня с приложениями происходит.
Про поддерживаемы объемы - не соглашусь. У меня около. 1000 замёток, с учетом ресурсов, тагов и т.д. 4100 объектов.
Работает нормально. Поиск работает быстро.
В своё время уходил с Evernote поскольку он в тормоз превратился где даже открытие приложение пол часа занимало :)
Ага, меня тоже порадовало- нет экспертизы настроить low latency для существующих Бах данных, но есть экспертиза написать свою с нуля ….
Хотелось бы чтобы автор привёл оценку во сколько VK обошлась бы лицензия на Oracle под их нужды …. Думаю что после этого Oracle можно не упоминать в суе. То же касается и MS SQL.
Далее пошло откровенное передёргивание и натягивание совы на глобус:
Наша база данных поддерживает ACID транзакции, … но транзакции поддерживаются только в рамках узла … Транзакция она как свежеть - бывает первая она же и последняя, поддержка транзакций либо есть либо нет. Тем более если вы ACID поддержку заявили.
Другой вопрос что при определённом размере базы данных и ее географическом распределении классические транзакции вам уже могут и не потребоваться.
Судя по тексту, ответ писал ChatGPT?
Pacman -Ss и дальше можно подставлять буквы алфавита a-z
Выдаст все пакеты где есть эта буква
Главное не что хотели сказать а что сказалось:
«.. и работать под Маком проще чем под Линуксом, где все работает из коробки и работает нормально».
Т.е. ежики кололись и продолжали есть кактус, вместо того чтобы пересесть на Линукс :)
Данные выкатываете в лог файл.
Ваша визуализация для «нормальной» работы не нужна - вы же не будете целый день смотреть на панель.
Далее пишите скрипт который раз в день, парусит лог и отправляет вам е-mail если канал упал.
Меньше чего поддерживать/настраивать не говоря о том что работать будет 24x7 и 1000 лет.
А в вашей графине/докере и т.д. Завтра выкатят несовместимое обновление и все рухнет.
На днях оказалось что родной vagrant не работает с последнее версией VirtualBox- никогда такого не было и вот опять.
Плюс сколько ресурсов у вас отжирает ваш набор сервисов и сколько будет жрать один iperf3 с парой скриптов?
А ещё есть флоппонет- можно с диском зайти к друзьям, которые уже достали свежие видео. Заодно и потусить с кофе/пивом. А-то вас бы все в интернетах сидеть.
Ещё можно запустить iperf3 в режиме сервера на серваке и с локальной/нудной машины запустить iperf3 в режиме клиента.
Ни графаны ни Прометея , ни докеров - две стандартные линуксов утилиты.
По поводу ускорения чтения из была данных для рендеринга сообщений.
Самым очевидно способом будет создать ещё одну таблицу в которую писать данные относящиеся к +/-100 сообщениям относительно текущего.
И просто выбирать все данные для отображения на экране одним запросом
Типа. select * from chat_view;
И рендерите себе спокойно.
Пользователь все-равно всю историю сообщений не видит, и изменения в них соответсвенно тоже.
Если он прокрутил вверх/вниз экран, заполняем таблицу другой порцией сообщений и снова рендерим. Пока он пальцем по экрану будет водить можно все пере писать и пересчитать….
Если таблицу сделать временной, то даже удалять данные не придётся DB все сама сделает.
Честно говоря у меня вопрос по замеру производительности запросов:
Запускать два селектора последовательно и мерить скорость нельзя - оптимизатор запросов будет подготовлен к выполнению похожего запроса и кеш базы данных будут заполнены данными ( холодный кеш vs горячий кеш)
Далее выбор всех строк из таблицы - явно ресурсоёмкая операция при количестве столбцов >X и размере данный > Y (подробности зависят от размера блока в БД, размера кластера на диске и т.д.)
Далее если вы вбираете 3 поля из таблицы то результат может зависеть от того являются ли эти поля частью индекса и как построен индекс, так как если вам повезёт, то БД просто отдаст данные из индекса, без обращения к самой таблице.
Например: поля в таблице: a,b,c,d,…h
Индекс построен по столбцам a,b,c,d
Если выбираем столбца a,b,c - нам повезло все данные из индекса.
Если добавим поле f - придётся лезть в базу данных и скорость упадёт.
Вопрос что будет при выборе a,b,d - зависит от вашей базы данных. Некоторые умеют выдавать столбцы из индекса игнорирую пропущенные, некоторые нет.
Если у вас ORM - то вы вообще не понимаете что происходит на уровне базы данных, и это для вас :(
В общем, дело ясное что дело темное. Похоже вы добились улучшения на тестовом наборе данных, но не факт что скорость улучшиться на «реальных» данных.
Опять таки, могу предположить что операция записи в БД гораздо быстрее чем операция отсылки сообщения - нет сетевых задержек, не надо устанавливать соединение.
То что вы клиенту показали что сообщение сразу отправлено- не то же самое что сообщение фактически отправлено.
И тем более не равно утверждению что оно дошло до адресата.
Тут статьи написанные ChatGpt ругали, а похоже зря …
Придётся мне за него поработать и summary сделать:
Разрабатывали сервис для клиента
Использовали vie.js для фронта
Использовали python для back-end, но это не точно
Строго следовали требованиям и стандартам заказчика, поэтому использовавши компоненты из его стандартных библиотек
Заказчик вроде как использует SQLAlchemie, мы ее тоже стали использовать, потому что заказчик сказал. потом ее выкинули и за день переписали все используя Tortoise Orm - она асинхронная «в них есть электролиты». Заказчику похоже не сказали.
У заказчики стоит свой гитлаб, куда мы скриптом пихали свои версии из нашей VCS (какой? А Черт ее знает)
ТЗ сразу выкинули, заказчик пересматривали требования, объём работ поплыл, но проект сдали. Что с бюджетом - а кто его знает. …
А ещё у заказчика gRPC используется для синхронизации между сервисами. … (к чему бы это?)
Да, кстати, я вообще-то IT директор а эта статья про управление проектами.
Вместо этого хотелось бы услышать про:
архитектуру
Постольку приложение вроде как медицинское- про работу с пользовательскими данными, которые более чем «персональные данные» и требования к ограничению доступа к которым строже.
Примерное количество пользователей - чтобы нагрузку оценить. 4 если уж SQLAlchemie выкинулись поскольку неполногласие- почему и что конкретно в Torguse ORM лучше кроме того что она асинхронная.
Согласен. Статья не о чем и логически не выверена. Если нейросеть сгенерировала фото которое мы признаём deep-fake, какая может быть защита частных данных?
Как доказать что это конкретное изображение Маши или Пети а не «лица похожего на генерального прокурора..»
Это же нейросеть нагенерила.
Кстати, читайте историю, Херлуф Битструп - художник карикатурист, которого очень любили в СССР, в своё время занижался иллюстрацией книжки про французских чиновников которые сотрудничали с нацистами.
Все имена были изменены чтобы избежать привлечения к ответственности за клевету, но иллюстрации сохраняли портретное сходство.
Художнику ничего не грозило, поскольку он своих героем может изображать как хочет.
Так что если вы напишете под deep-fake фото: Маша Иванова из 10а, то возможно вам что-то будет. А если напишете Маша из 10а. До доказать что-то будет проблематично.
Fossil?
Не засоряет все что можно скрытыми папками с данными, а спокойно держит все в отдельном файле SQLite.
Тут много найдётся специалистов, которые могут гитом без гит-хаба, гит-лаба пользоваться? Чтобы хотя бы в команде из 3-Х человек кодом обмениваться?
Одели чего?
Я тут за бугром - лампочки покупал в обычном дискаунтере
Для управления поливом воды - Gardena - берите любой
Реле времени - купил на Амазоне :)
Ещё и радиатор отопления воткнул через разъём который с термометром интегрируется - брал на Амазоне первый попавшийся.
Поскольку все «само по себе работает» все равно что брать. Если что-то отвалилось - выкидываете, покупные другой фирмы. Все меняется быстр и безболезненно.
Но мне в приципе мониторинг по телефону не нужен. Во первых на даче интернета нет. Можно роутер с карточкой воткнуть, но зачем?
И во вторых, для меня умный дом это не когда я постоянно кнопки жму включать/ выключить, а когда один раз настроил и оно работает.
Соответственно система должна быть максимально децентрализованной и максимально использовать датчики.
То-ли я староват, то-ли программеры нынче не те. Делаем устройство управления умным домом - у автора управление в том числе «критической инфраструктурой» насос, отопление, освещение.
Первым делом навешиваем все на центральный сервер, и подключаем управление по интернету. Если сервер накрылся- всему дому хана. Если отключили электричество всему дому хана.
Делал у себя на даче «полоумный» дом.
1 освещение - LED фонари с солнечной батареей и датчиком движения. Светят как хорошие прожекторы. Цена 10 евро максимум. Включается когда на улице темно и есть движение. В нескольких моделях есть режим подсветки - горит постоянно когда темно. Больше трёх лет - полёт нормальный.
Полив газона - «водяные часы» устанавливаются на водопроводную трубу. К ним подключается датчик влажности у меня проводной, но есть и беспроводные.
Газон поливаем по расписанию. Если пошёл дождь- датчик отключит полив.
Полив в теплице - реле времени, которое включает насос и качает из бочки в бак в теплице. Время насчитано экспериментально.
Ни интернета ни wifi все работает само по себе уже 3 года.
Вообще-то то вы тут не правы, а предыдущий автор вполне прав.
Символ разделения дробной и целой части на калькуляторе не имеет значения. Как и символ разделения разрядов. Достояно не использовать для разделения разрядов . Или , и у вас нет проблем с в 99.9 случаев.
Даже если вы используете . И , то через 2 минуты пользования калькулятором пользователь поймёт что к чему.
Далее моя целевая аудитория - космонавты на МКС.
Соответственно 99% ваших требований летит в корзину так как они очевидны.
Более того, поскольку МКС - международная станция, вам прямой путь к скинию ISO норм по отображению цифр, разрядности системы
В ы в своих требованиях допустили ошибку/ у вас только 4 арифметических оператора. В то время как на обычном калькуляторе есть ещё операция смены знака (*-1) которая сильно упрощает расчеты.
Ещё одним вариантом постановки ТЗ на разработку калькулятора - вы делаете улучшенный аналог а не принципиально новое устройство, было бы привести ссылки на существующие образцы, сказать что сделано не так и что надо улучшить.
В результате пользы будет больше а бесполезного текста меньше.
Кроме того, если. Включить «дурочку» то под ваше ТЗ подходит калькулятор работающий в любой система счисления с основанием меньше или равным 10.
Так что не удивляйтесь, что когда ваш QA введёт пример 1+1 он получит 10 в качестве ответа.
Они ответ дали. В начале статьи: дети из богатых семей получают лучший доступ к дополнительному образованию. Остальное - как мертвому припарки.
Если я могу нанять своему ребёнку репетитора, отправить на дополнительные занятия или купить больше книжек, то тот кто этого не может не сможет конкурировать.
Как задачи не переписывай -результат не изменится.
Не спасут. У задаст про еду и деньги глубокие корни: Берём книжку «Витя Малеев в школе и дома» задачи: сколько стоили пилы и топоры, стольк орехов собрали датчик и девочка, сколько стоит пробка и бутылка…
Если уж в СССР все задачи вокруг денег вертелись, то что о капиталистических странах говорить …. :)
WebDAV на своём сервере? Я через lighttpd настраивал. -работает
Это вы про Joplin?
Про потерю замёток не скажу.
Хотя возможно аттачить теряет - я тут базу замёток из Evernote импортировал. Периодически фигня с приложениями происходит.
Про поддерживаемы объемы - не соглашусь. У меня около. 1000 замёток, с учетом ресурсов, тагов и т.д. 4100 объектов.
Работает нормально. Поиск работает быстро.
В своё время уходил с Evernote поскольку он в тормоз превратился где даже открытие приложение пол часа занимало :)
Ага, меня тоже порадовало- нет экспертизы настроить low latency для существующих Бах данных, но есть экспертиза написать свою с нуля ….
Хотелось бы чтобы автор привёл оценку во сколько VK обошлась бы лицензия на Oracle под их нужды ….
Думаю что после этого Oracle можно не упоминать в суе. То же касается и MS SQL.
Далее пошло откровенное передёргивание и натягивание совы на глобус:
Наша база данных поддерживает ACID транзакции, … но транзакции поддерживаются только в рамках узла …
Транзакция она как свежеть - бывает первая она же и последняя, поддержка транзакций либо есть либо нет.
Тем более если вы ACID поддержку заявили.
Другой вопрос что при определённом размере базы данных и ее географическом распределении классические транзакции вам уже могут и не потребоваться.
Joplin - есть синхронизация. Можно сделать через свой сервак.
Есть приложения по iOS и остальные платформы.
Не благодарите :)
Что что а для ведения личных заметой проблем быть не должно.