Адрес для входа в РФ: exler.wiki
Криворукие программисты
13.02.2014 19:21
11285
Комментарии (57)
В программе Clipdiary довольно криво реализована работа с их базой данных, где хранится содержимое буферов. Даже если выставляешь параметр "полностью очищать базу при выходе" - там записи, как это делается в базах, просто помечаются как удаленные, а физически не удаляются. Соответственно, база пухнет. За несколько месяцев она распухает до 20-30 гигов (у меня много больших картинок через буфер копируется), и ее надо чистить, чтобы не забивала место на винте.
Для очистки базы данных там есть специальная кнопочка "Очистить базу данных". И дураку понятно, как должна производиться полная очистка базы: грохаем всю базу, создаем новую, пустую. Эта операция займет полсекунды.
Но криворукие программисты, сделавшие данную программу, легких путей не ищут! Знаете, что они делают? Начинают копировать старую базу в новую, не копируя записи, помеченные как удаленные. Попутно они, вероятно, еще и вычисляют число Пи вплоть до миллионного знака после запятой и обсчитывают сигналы внеземных цивилизаций, потому что я не понимаю, как можно базу в каких-то 15 Гб на очень мощном компьютере с шустрым диском обнулять ДВАДЦАТЬ МИНУТ, шерстя диск так, что он раскаляется.
Двадцать минут они обнуляют базу - этим ребятам надо орден дать с формулировкой "Бездари года".
Впрочем, после того как я в первый раз проделал данную процедуру, то быстро нашел решение. Надо просто собственноручно грохнуть базу, а при запуске программы она, не увидев базу, все-таки создает новую, пустую. Что вообще странно, потому что не очень понятно, как они до такого додумались. Но додумались, ура.
Войдите, чтобы оставить комментарий.
За годы работы с компрьютером, перепробовал десятки подобных программ.
Попробовал и эту.
И всё таки, остаюсь с той, с которой работаю долгие годы.
Clipboard Recorder
Программа старенькая и уже не поддерживается, хотя плату требует (но добрые люди помогли решить эту проблему - гуглите).
Её плюс - максимальный минимализм и главное достоинство - показ записи в буфере по клику на программе в трее.
В отличии от других программ, где вылезает окно на пол экрана, в этой, вылезает маленькое, ниспадающее, окошко. В котором, в кратце (можно настроить по желанию) вылезает список всего сохраннённого в буфере.
Вроде бы такая маленькая фишечка, но настолько полезная, что привыкнув её пользоваться, другие программы (подобного типа) использовать (без этой фишечки) уже не могу.
Попробовал и эту.
И всё таки, остаюсь с той, с которой работаю долгие годы.
Clipboard Recorder
Программа старенькая и уже не поддерживается, хотя плату требует (но добрые люди помогли решить эту проблему - гуглите).
Её плюс - максимальный минимализм и главное достоинство - показ записи в буфере по клику на программе в трее.
В отличии от других программ, где вылезает окно на пол экрана, в этой, вылезает маленькое, ниспадающее, окошко. В котором, в кратце (можно настроить по желанию) вылезает список всего сохраннённого в буфере.
Вроде бы такая маленькая фишечка, но настолько полезная, что привыкнув её пользоваться, другие программы (подобного типа) использовать (без этой фишечки) уже не могу.
Программа классная, но с базой оно конечно не очень. Вариант - поставить фильтр на типы файлов (изображения), чтобы они не писались в базу. Мне, например, нужен менеджер буфера обмена в основном для текстовой информации. Вот сейчас глянул - файл ДБ 28 МБ (ему уже больше года точно)
Помнится, после обзора этого менеджера в очередной раз попробовал слезть с CLCL.
Неделю с ней проработал и снёс нафиг. Мне кажется, альтернатив CLCL просто нет. Работает мгновенно. Не тормозит. Ничего лишнего. Никаких глюков и сбоев. У меня настроено на хранение 500 записей в истории и всё это мгновенно открывается по нажатии горячей кнопки. И удобно группируется в меню. Плюс удобно в одном всплывающем окне сделана и история буфера и избранные фрагменты.
Правда я, как програмист, больше работаю с текстом, а не с графикой, но работаю активно.
Кажется, я все возможные программы подобного класса перепробовал уже.
Неделю с ней проработал и снёс нафиг. Мне кажется, альтернатив CLCL просто нет. Работает мгновенно. Не тормозит. Ничего лишнего. Никаких глюков и сбоев. У меня настроено на хранение 500 записей в истории и всё это мгновенно открывается по нажатии горячей кнопки. И удобно группируется в меню. Плюс удобно в одном всплывающем окне сделана и история буфера и избранные фрагменты.
Правда я, как програмист, больше работаю с текстом, а не с графикой, но работаю активно.
Кажется, я все возможные программы подобного класса перепробовал уже.
github.com/hluk/CopyQ не лучше будет?
Алекс, попробуйте ArsClip - шедевральная вещь. Лучшее из того что я пробовал в этой области.
Чувствую что день пройдет под знаком копания в коде пяти летней давности и попытки понять что же это за нафик такой случился, вроде все нормально работало 😄
Проблема ровно одна: название "Очистить базу данных" для кнопки неудачно. Это, скорее, "Сжать", а не "Очистить". Если очень захотеть - можно прикопаться ещё к тому, что не предусмотрели отдельную кнопку действительно полного удаления базы.
За исключением этого, всё совершенно нормально.
Компактизация БД с удалёнными записями путём копирования в свежую БД только актуальных записей - нормальная практика. И тот же TheBat! так всегда делал и делает (не сжимали папочки на несколько гигов и десятков тысяч писем?), и крупные БД, и вообще практически весь софт. Попробуйте предложить другой метод, гарантирующий (sic!) целостность данных в случае внезапного прерывания процесса компактизации.
Долго исполняется на самом крутом железе? Тоже объяснимо: БД настроена на работу с малыми объёмами (или там вообще SQLite?) и при превышении объёма файла, выделение нового пространства делается очень маленьким блоком (не захватывает сразу несколько сотен мегабайт). Следствие такой политики - безумная фрагментация файла БД. После этого сжатие будет идти, очевидно, медленно. Тем более, что свободное место, вероятно, тоже изрядно фрагментировано и новая БД (куда копируем) тоже выделяет место маленькими порциями, заполняя все фрагментационные дырки свободного места. Авторов тут винить сложно: думаю, они просто ориентировались на текст и не предполагали, что кто-то будет таскать через клипборд гигабайты фотографий. "Очень мощный компьютер" тут совершенно ни при чём - объём памяти, скорость процессора, видеокарты, диагональ монитора - ничего из этого не влияет на вышеуказанное. Роляет только access time диска. Можно поместить эту базу на SSD - будет шустрее.
Кстати, про всплывшую в комментариях идею хранения баз TheBat`а на сетевом драйве - очень порадовало. Вы не пробовали кэш браузера разместить там же? Тоже должны быть незабываемые ощущения.
За исключением этого, всё совершенно нормально.
Компактизация БД с удалёнными записями путём копирования в свежую БД только актуальных записей - нормальная практика. И тот же TheBat! так всегда делал и делает (не сжимали папочки на несколько гигов и десятков тысяч писем?), и крупные БД, и вообще практически весь софт. Попробуйте предложить другой метод, гарантирующий (sic!) целостность данных в случае внезапного прерывания процесса компактизации.
Долго исполняется на самом крутом железе? Тоже объяснимо: БД настроена на работу с малыми объёмами (или там вообще SQLite?) и при превышении объёма файла, выделение нового пространства делается очень маленьким блоком (не захватывает сразу несколько сотен мегабайт). Следствие такой политики - безумная фрагментация файла БД. После этого сжатие будет идти, очевидно, медленно. Тем более, что свободное место, вероятно, тоже изрядно фрагментировано и новая БД (куда копируем) тоже выделяет место маленькими порциями, заполняя все фрагментационные дырки свободного места. Авторов тут винить сложно: думаю, они просто ориентировались на текст и не предполагали, что кто-то будет таскать через клипборд гигабайты фотографий. "Очень мощный компьютер" тут совершенно ни при чём - объём памяти, скорость процессора, видеокарты, диагональ монитора - ничего из этого не влияет на вышеуказанное. Роляет только access time диска. Можно поместить эту базу на SSD - будет шустрее.
Кстати, про всплывшую в комментариях идею хранения баз TheBat`а на сетевом драйве - очень порадовало. Вы не пробовали кэш браузера разместить там же? Тоже должны быть незабываемые ощущения.
Erelen: Проблема ровно одна: название "Очистить базу данных" для кнопки неудачно. Это, скорее, "Сжать", а не "Очистить". Если очень захотеть - можно прикопаться ещё к тому, что не предусмотрели отдельную кнопку действительно полного удаления базы.
За исключением этого, всё совершенно нормально.
За исключением этого, всё совершенно нормально.
Собственно, да. Проблема только в 1 (одном) неверно подобранном слове. Вина в этом не программиста, а того надмозга, который английский термин Purge (именно им обозначается чистка базы от записей, помеченных как удаленные) перевел тупо в лоб.
Алекс сидит на последней версии Фаерфокса, отсюда и мысли такие... ждём обновления.
ClipX. Несколько лет пользуюсь. Никаких нареканий
давно я хотел спросить у программистов The Bat! - каким местом им вставлены руки в жопу - но после нескольких попыток ПЛАТНОЙ подписки просто забил. Пока у них не будет адекватной работы по сети и адекватной работы с папками - ни копейки больше.
Я ежедневно сталкиваюсь с проблемами этими. Удалил письмо - оно ПОМЕТИЛОСЬ и попало в корзину. Удалил из корзины - оно ПОМЕТИЛОСЬ.
Мне приходится (у нас 4 сотрудника и почта постоянно приходит больших объёмов) РАЗ В ТРИ ДНЯ через "Управление папками" все сжимать, удалять, проверять.
А уж про работу с большими письмами (там, где есть файлы приложенные мегов на 20) по сети (wi-fi b/g) - умереть не встать.
Проблема - нет другого адекватного клиента, на который перевести тетушек 40-60 лет от роду, раз уже когда-то купил и поставил им этот ужас.
Я ежедневно сталкиваюсь с проблемами этими. Удалил письмо - оно ПОМЕТИЛОСЬ и попало в корзину. Удалил из корзины - оно ПОМЕТИЛОСЬ.
Мне приходится (у нас 4 сотрудника и почта постоянно приходит больших объёмов) РАЗ В ТРИ ДНЯ через "Управление папками" все сжимать, удалять, проверять.
А уж про работу с большими письмами (там, где есть файлы приложенные мегов на 20) по сети (wi-fi b/g) - умереть не встать.
Проблема - нет другого адекватного клиента, на который перевести тетушек 40-60 лет от роду, раз уже когда-то купил и поставил им этот ужас.
HawkieRus:
давно я хотел спросить у программистов The Bat! - каким местом им вставлены руки в жопу - но после нескольких попыток ПЛАТНОЙ подписки просто забил. Пока у них не будет адекватной работы по сети и адекватной работы с папками - ни копейки больше.
Я ежедневно сталкиваюсь с проблемами этими. Удалил письмо - оно ПОМЕТИЛОСЬ и попало в корзину. Удалил из корзины - оно ПОМЕТИЛОСЬ.
Мне приходится (у нас 4 сотрудника и почта постоянно приходит больших объёмов) РАЗ В ТРИ ДНЯ через "Управление папками" все сжимать, удалять, проверять.
А уж про работу с большими письмами (там, где есть файлы приложенные мегов на 20) по сети (wi-fi b/g) - умереть не встать.
Проблема - нет другого адекватного клиента, на который перевести тетушек 40-60 лет от роду, раз уже когда-то купил и поставил им этот ужас.
давно я хотел спросить у программистов The Bat! - каким местом им вставлены руки в жопу - но после нескольких попыток ПЛАТНОЙ подписки просто забил. Пока у них не будет адекватной работы по сети и адекватной работы с папками - ни копейки больше.
Я ежедневно сталкиваюсь с проблемами этими. Удалил письмо - оно ПОМЕТИЛОСЬ и попало в корзину. Удалил из корзины - оно ПОМЕТИЛОСЬ.
Мне приходится (у нас 4 сотрудника и почта постоянно приходит больших объёмов) РАЗ В ТРИ ДНЯ через "Управление папками" все сжимать, удалять, проверять.
А уж про работу с большими письмами (там, где есть файлы приложенные мегов на 20) по сети (wi-fi b/g) - умереть не встать.
Проблема - нет другого адекватного клиента, на который перевести тетушек 40-60 лет от роду, раз уже когда-то купил и поставил им этот ужас.
Можно же поставить сжатие папок при выходе. А приложения лучше хранить отдельно от писем. А ещё проще научить тёток пользоваться гмэйлом, и пусть каждая извращается там как хочет.
HawkieRus:
Я ежедневно сталкиваюсь с проблемами этими. Удалил письмо - оно ПОМЕТИЛОСЬ и попало в корзину. Удалил из корзины - оно ПОМЕТИЛОСЬ.
удаляй с шифтом...
сжимать, правда, все равно придётся...
Я ежедневно сталкиваюсь с проблемами этими. Удалил письмо - оно ПОМЕТИЛОСЬ и попало в корзину. Удалил из корзины - оно ПОМЕТИЛОСЬ.
удаляй с шифтом...
сжимать, правда, все равно придётся...
Похоже, что под "Очистить базу данных" на самом имеется в виду "Сжать базу данных". Тогда всё правильно -- создаётся новая база, в которой уже нет удалённых записей, но сохранена вся остальная информация. Конечно, для того, чтобы "грохнуть" базу (нет такой кнопки?), этот способ некудышний.
Кстати -- база на диске или на SSD? На SSD сжатие должно пройти относительно быстро.
Кстати -- база на диске или на SSD? На SSD сжатие должно пройти относительно быстро.
Это, конечно, ваша песочница и ваш песок, но зачем сразу наезжать на разработчиков. Вроде, опытный человек в области ИТ. Сам не пользовался, но по симптомам проблема в том что они используют dbase локальную базу данных (такая оочень древняя система, но и требующая мало ресурсов). Там, если мне память не изменяет, как раз удаление = помечается строка как удаленная, отчистка = сжатие файла. Если в оракле вы этого не видите, то не значит что он тоже так не делает, даже если и быстрее. Хотя там и потребности в памяти и процессоре совсем другого порядка.
Morgen: они используют dbase локальную базу данных (такая оочень древняя система, но и требующая мало ресурсов)
Ну может в этом и есть ошибка, использовать dbase, когда есть sqlite? ))
Morgen:
Это, конечно, ваша песочница и ваш песок, но зачем сразу наезжать на разработчиков. Вроде, опытный человек в области ИТ. Сам не пользовался, но по симптомам проблема в том что они используют dbase локальную базу данных (такая оочень древняя система, но и требующая мало ресурсов). Там, если мне память не изменяет, как раз удаление = помечается строка как удаленная, отчистка = сжатие файла. Если в оракле вы этого не видите, то не значит что он тоже так не делает, даже если и быстрее. Хотя там и потребности в памяти и процессоре совсем другого порядка.
Это, конечно, ваша песочница и ваш песок, но зачем сразу наезжать на разработчиков. Вроде, опытный человек в области ИТ. Сам не пользовался, но по симптомам проблема в том что они используют dbase локальную базу данных (такая оочень древняя система, но и требующая мало ресурсов). Там, если мне память не изменяет, как раз удаление = помечается строка как удаленная, отчистка = сжатие файла. Если в оракле вы этого не видите, то не значит что он тоже так не делает, даже если и быстрее. Хотя там и потребности в памяти и процессоре совсем другого порядка.
Для поддержания баланса справедливости в природе, можете представить, как криворукие программисты комментируют последние обзоры Экслера с выражениями. Я представил, это реально смешно!
Я работаю с базой корпоративной базой на Оракл онлайн. Это тихий ужас. Кстати главой мелкомягких стал индус )))
Anarrich:
Я работаю с базой корпоративной базой на Оракл онлайн. Это тихий ужас. Кстати главой мелкомягких стал индус )))
Я работаю с базой корпоративной базой на Оракл онлайн. Это тихий ужас. Кстати главой мелкомягких стал индус )))
Если вы ей запросы шлете запросы, то да. А так она у меня в уголочке шуршит на рабочей станции, в виртуалку упакованная и 15 гигов для Oracle это не размер.
кто бездарище спорный вопрос
у меня 10 мегов занимает сейчас база данных, 10 МЕГАБАЙТ!
ибо стоит лимит на сохранение 500 последних клипов, конечно если месяцами копипастить и установить лимит в мильОн клипов то соберутся 20 гигов
у меня 10 мегов занимает сейчас база данных, 10 МЕГАБАЙТ!
ибо стоит лимит на сохранение 500 последних клипов, конечно если месяцами копипастить и установить лимит в мильОн клипов то соберутся 20 гигов
Деревенщина:
кто бездарище спорный вопрос
у меня 10 мегов занимает сейчас база данных, 10 МЕГАБАЙТ!
ибо стоит лимит на сохранение 500 последних клипов, конечно если месяцами копипастить и установить лимит в мильОн клипов то соберутся 20 гигов
кто бездарище спорный вопрос
у меня 10 мегов занимает сейчас база данных, 10 МЕГАБАЙТ!
ибо стоит лимит на сохранение 500 последних клипов, конечно если месяцами копипастить и установить лимит в мильОн клипов то соберутся 20 гигов
У меня там стоит лимит 10 клипов. Запись-то прочитал, осознал?
Alex Exler: выставляешь параметр "полностью очищать базу при выходе"
Ну так сделайте батничек, который сперва будет удалять базу, а потом запускать программу - будет практически аналогичное "полностью очищать базу при входе".
diamant:
Alex Exler: выставляешь параметр "полностью очищать базу при выходе"
Ну так сделайте батничек, который сперва будет удалять базу, а потом запускать программу - будет практически аналогичное "полностью очищать базу при входе".
Alex Exler: выставляешь параметр "полностью очищать базу при выходе"
Ну так сделайте батничек, который сперва будет удалять базу, а потом запускать программу - будет практически аналогичное "полностью очищать базу при входе".
Да это-то понятно.
diamant:
Alex Exler: выставляешь параметр "полностью очищать базу при выходе"
Ну так сделайте батничек, который сперва будет удалять базу, а потом запускать программу - будет практически аналогичное "полностью очищать базу при входе".
Alex Exler: выставляешь параметр "полностью очищать базу при выходе"
Ну так сделайте батничек, который сперва будет удалять базу, а потом запускать программу - будет практически аналогичное "полностью очищать базу при входе".
Батничек на нынешние времена некошерно.
Создавайте cmd-шку.
Вспомнилось. Лет 10 назад меня безумно веселил факт, что оракл на таблице со сложными индексами в которую постоянно вставлялись/удалялись записи через некоторое время исполняет select count(*) from table_name; за несколько МИНУТ даже если она пустая. Видимо это какая-то суровая традиция в области баз данных.
Xecutor: Вспомнилось. Лет 10 назад меня безумно веселил факт, что оракл на таблице со сложными индексами в которую постоянно вставлялись/удалялись записи через некоторое время исполняет select count(*) from table_name; за несколько МИНУТ даже если она пустая. Видимо это какая-то суровая традиция в области баз данных.
Это же Oracle. Вы вставляете, удаляете, а он все это помнит !
Xecutor:
Вспомнилось. Лет 10 назад меня безумно веселил факт, что оракл на таблице со сложными индексами в которую постоянно вставлялись/удалялись записи через некоторое время исполняет select count(*) from table_name; за несколько МИНУТ даже если она пустая. Видимо это какая-то суровая традиция в области баз данных.
Вспомнилось. Лет 10 назад меня безумно веселил факт, что оракл на таблице со сложными индексами в которую постоянно вставлялись/удалялись записи через некоторое время исполняет select count(*) from table_name; за несколько МИНУТ даже если она пустая. Видимо это какая-то суровая традиция в области баз данных.
Вам надо было использовать какое нибудь условие, для включения индексов - иначе он делает полный перебор всех записей :
select count(*) from table_name Where table_name.id>0
Художника обидеть может каждый.
