Catch log что это за программа
CatchLog Xiaomi — что это за программа и нужна ли она? (com.bsp.catchlog)
Приветствую. Операционка Андроид содержит много компонентов, функций, системных программ. Некоторые отключать нельзя — иначе могут быть серьезные последствия (например bootloop). Другие — вполне можно, так как носят служебный характер, не влияют на стабильность работы.
CatchLog Xiaomi — что это такое?
Приложение, позволяющее узнать износ батареи, а также другую служебную информацию. Удалять не рекомендуется. Можно заморозить.
На форуме 4PDA пишут — отвечает за вызов меню *#*#6485#*#*.
Полное название — Charging and Battery Information, переводится как информация о зарядке и аккумуляторе.
Присутствует в стоковой прошивке Андроид, вывод — системное приложение.
Один пользователь заморозил — проблем не замечено. Морозить лучше используя Titanium Backup (нужны root-права).
Если запустить активити приложения, то там тесты/датчики какие-то, возможно связанные с батареей. Но явно не логи, как может показаться по названию.
Оказывается CatchLog в кастомных прошивках вырезают — видимо не особо важно.
Морозить можно, но CatchLog позволит узнать износ батареи — набираем комбинацию *#*#6485#*#* и смотрим пункты MF_05 и MF_06:
Проверять износ лучше когда телефон только снят был с зарядки. Проверена работа на MiUi 11.0.4.0 (Android 10), на 11.0.5.0 (Android 9) — не работает.
Logcat
Рассмотрим на примере. Очень часто программисту нужно вывести куда-то промежуточные результаты, чтобы понять, почему программа не работает. Особо хитрые временно размещают на экране текстовую метку и выводят туда сообщение при помощи метода textView.setText(«Здесь был Васька»). Но есть способ лучше. В Android есть специальный класс android.util.Log для подобных случаев.
Класс android.util.Log позволяет разбивать сообщения по категориям в зависимости от важности. Для разбивки по категориям используются специальные методы, которые легко запомнить по первым буквам, указывающие на категорию:
В первом параметре метода используется строка, называемая тегом. Обычно принято объявлять глобальную статическую строковую переменную TAG в начале кода:
Некоторые в сложных проектах используют следующий вариант, чтобы понимать, в каком классе происходит вызов:
Далее уже в любом месте вашей программы вы вызываете нужный метод журналирования с этим тегом:
Также используется в исключениях:
Пользователи не видят этот журнал. Но, вы, как разработчик, можете увидеть его через программу LogCat, доступный в Android Studio.
Полный вид сообщения выглядит следующим образом.
03-09 20:44:14.460 3851-3879 / ru.alexanderklimov.cat I/OpenGLRenderer : Initialized EGL, version 1.4
Подобные длинные сообщения не всегда удобны для чтения. Вы можете убрать ненужные элементы. Для этого выберите значок LogCat Header в виде шестерёнки и уберите флажки у опций.
В LogCat вы можете отфильтровать сообщение по заданному типу, чтобы видеть на экране только свои сообщения. Для этого выберите нужный тип тега из выпадающего списка Verbose.
Типы сообщений можно раскрасить разными цветами через настройки File | Settings | Editor | Colors Scheme | Android Logcat.
Для отслеживания сообщений с заданным текстом введите в поле поиска нужную строку и нажмите Enter.
Также активно используйте варианты из других выпадающих списков. Например, выбирайте свой пакет из второй колонки, а в последней выбирайте Show only selected application. Для более точной настройки используйте Edit Fiter Configuration.
По умолчанию, окно LogCat выводится в нижней части студии. При желании, можно выбрать другие варианты через значок настроек окна.
LogCat также можно запустить из командной строки:
Параметры командной строки смотрите в документации.
Быстрое отключение журналирования
Теперь остаётся только присвоить нужное значение переменной isDebug перед созданием готового apk-файла для распространения.
Способ устарел. В 17-й версии Android Build Tools появился класс BuildConfig, содержащий статическое поле DEBUG. Можно проверить следующим образом:
В этом случае конфигурация releaseWithLog будет являться релизной сборкой с ведением логов. Естественно, в коде слегка поменяется проверка:
LogCat на устройстве
Попался в сети пример для просмотра сообщений LogCat на устройстве. С примером не разбирался, оставлю здесь на память.
[MIUI Питання та відповіді] catch log что за приложение
Xiaomi Comm APP
Stay updated on Mi Products and MIUI
Featured
* Recommended to upload a 720*312 image as the cover image
* Changes are irreversible after submitting
Cookies Preference Center
We use cookies on this website. To learn in detail about how we use cookies, please read our full Cookies Notice. To reject all non-essential cookies simply click «Save and Close» below. To accept or reject cookies by category please simply click on the tabs to the left. You can revisit and change your settings at any time. read more
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services such as setting your privacy preferences, logging in or filling in formsYou can set your browser to block or alert you about these cookies, but some parts of thesite will not then work. These cookies do not store any personally identifiable information.
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services such as setting your privacy preferences, logging in or filling in formsYou can set your browser to block or alert you about these cookies, but some parts of thesite will not then work. These cookies do not store any personally identifiable information.
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services such as setting your privacy preferences, logging in or filling in formsYou can set your browser to block or alert you about these cookies, but some parts of thesite will not then work. These cookies do not store any personally identifiable information.
8 продвинутых возможностей модуля logging в Python, которые вы не должны пропустить
Понимайте свою программу без ущерба для производительности
Журналирование — это очень важная часть разработки ПО. Оно помогает разработчикам лучше понимать выполнение программы и судить о дефектах и непредвиденных сбоях. Журнальное сообщение может хранить информацию наподобие текущего статуса программы или того, в каком месте она выполняется. Если происходит ошибка, то разработчики могут быстро найти строку кода, которая вызвала проблему, и действовать с учетом этого.
Python предоставляет довольно мощный и гибкий встроенный модуль logging со множеством возможностей. В этой статье я хочу поделиться восемью продвинутыми возможностями, которые будут полезны при разработке ПО.
Основы модуля logging
Прежде чем приступить к рассмотрению продвинутых возможностей, давайте убедимся, что у нас есть базовое понимание модуля logging.
Логгер
Экземпляр, который мы создаем для генерации записей, называют логгером. Он инстанциируется через logger = logging.getLogger(name). Лучшая практика — это использовать name в качестве имени логгера. name включает в себя имя пакета и имя модуля. Имя будет появляться в журнальном сообщении, что поможет разработчикам быстро находить, где оно было сгенерировано.
Форматировщик и обработчик
У любого логгера есть несколько конфигураций, которые могут быть модифицированы. Более продвинутые конфигурации мы обсудим позже, а наиболее ходовые — это форматировщик (прим. пер.: formatter) и обработчик (прим. пер.: handler).
Форматировщик устанавливает структуру журнального сообщения. Каждое журнальное сообщение — это объект класса LogRecord с несколькими атрибутами (имя модуля — один из них). Когда мы определяем форматировщик, мы можем решить, как должно выглядеть журнальное сообщение вместе с этими атрибутами и, возможно, с атрибутами, созданными нами. Стандартный форматировщик выглядит так:
Кастомизированный форматировщик может выглядеть так:
Обработчик задает целевое местонахождение журнальных сообщений. Журнальное сообщение может быть отправлено в более чем одно место. Собственно говоря, модуль logging предоставляет довольно много стандартных обработчиков. Самые популярные — FileHandler, который отправляет записи в файл, и StreamHandler, который отправляет записи в потоки, такие как sys.stderr или sys.stdout. Экземпляр логгера поддерживает ноль или более обработчиков. Если никакие обработчики не определены, тогда он будет отправлять записи в sys.stderr. Если определен более чем один обработчик, тогда целевое местонахождение журнального сообщения зависит от его уровня и от уровня обработчика.
Например, у меня есть FileHandler с уровнем WARNING (прим. пер.: предупреждение) и StreamHandler с уровнем INFO (прим. пер.: информация). Если я напишу в журнал сообщение об ошибке, то оно будет отправлено как в sys.stdout, так и в файл журнала.
Например:
В этом примере мы создали main.py, package1.py, и app_logger.py. Модуль app_logger.py содержит функцию get_logger, которая возвращает экземпляр логгера. Экземпляр логгера включает в себя кастомный форматировщик и два обработчика: StreamHandler с уровнем INFO и FileHandler с уровнем WARNING. Важно установить базовый уровень в INFO или DEBUG (уровень журналирования по умолчанию — WARNING), в противном случае любые записи журнала по уровню ниже, чем WARNING, будут отфильтрованы. И main.py, и package1.py, используют get_logger, чтобы создавать свои собственные логгеры.
Диаграмма Xiaoxu Gao
Записи с уровнем INFO отправляются как в консольный вывод (sys.stdout), так и в файл журнала, а записи с уровнем WARNING пишутся только в файл журнала. Если вы можете полностью понять, что и почему происходит в этом примере, то мы готовы приступить к более продвинутым возможностям.
1. Создавайте заданные пользователем атрибуты объектов класса LogRecord, используя класс LoggerAdapter
Как я упоминал ранее, у LogRecord есть несколько атрибутов. Разработчики могут выбрать наиболее важные атрибуты и использовать в форматировщике. Помимо того, модуль logging также предоставляет возможность добавить в LogRecord определенные пользователем атрибуты.
Один из способов сделать это — использовать LoggerAdapter. Когда вы создаете адаптер, вы передаете ему экземпляр логгера и свои атрибуты (в словаре). Этот класс предоставляет тот же интерфейс, что и класс Logger, поэтому вы все еще можете вызывать методы наподобие logger.info.
Новый атрибут с фиксированным значением
Если вы хотите иметь что-то вроде атрибута с фиксированным значением в журнальном сообщении, например имя приложения, то вы можете использовать стандартный класс LoggerAdapter и получать значение атрибута при создании логгера (прим. пер.: вероятно, получать откуда-либо, чтобы затем передать конструктору). Не забывайте добавлять этот атрибут в форматировщик. Местоположение атрибута вы можете выбрать по своему усмотрению. В следующем коде я добавляю атрибут app, значение которого определяется, когда я создаю логгер.
Новый атрибут с динамическим значением
В других ситуациях вам, возможно, понадобятся динамические атрибуты, например что-то вроде динамического идентификатора. В таком случае вы можете расширить базовый класс LoggerAdapter и создать свой собственный. Метод process() — то место, где дополнительные атрибуты добавляются к журнальному сообщению. В коде ниже я добавляю динамический атрибут id, который может быть разным в каждом журнальном сообщении. В этом случае вам не нужно добавлять атрибут в форматировщик.
2. Создавайте определенные пользователем атрибуты объектов класса LogRecord, используя класс Filter
Другой способ добавления определенных пользователем атрибутов — использование кастомного Filter. Фильтры предоставляют дополнительную логику для определения того, какие журнальные сообщения выводить. Это шаг после проверки базового уровня журналирования, но до передачи журнального сообщения обработчикам. В дополнение к определению, должно ли журнальное сообщение двигаться дальше, мы также можем вставить новые атрибуты в методе filter().
Диаграмма из официальной документации Python
В этом примере мы добавляем новый атрибут color (прим. пер.: цвет) в методе filter(), значение которого определяется на основе имени уровня в журнальном сообщении. В этом случае имя атрибута снова должно быть добавлено в форматировщик.
3. Многопоточность с модулем logging
Модуль logging на самом деле реализован потокобезопасным способом, поэтому нам не нужны дополнительные усилия. Код ниже показывает, что MainThread и WorkThread разделяют один и тот же экземпляр логгера без проблемы состояния гонки. Также есть встроенный атрибут threadName для форматировщика.
Под капотом модуль logging использует threading.RLock() практически везде. Отличия между RLock от Lock:
Lock может быть получен только один раз и больше не может быть получен до тех пор, пока он не будет освобожден. С другой стороны, RLock может быть получен неоднократно до своего освобождения, но он должен быть освобожден столько же раз.
Lock может быть освобожден любым потоком, а RLock — только тем потоком, который его удерживает.
Любой обработчик, который наследуется от класса Handler, обладает методом handle(), предназначенным для генерации записей. Ниже представлен блок кода метода Handler.handle(). Как видите, обработчик получит и освободит блокировку до и после генерации записи соответственно. Метод emit() может быть реализован по-разному в разных обработчиках.
4. Многопроцессная обработка с модулем logging — QueueHandler
Несмотря на то, что модуль logging потокобезопасен, он не процессобезопасен. Если вы хотите, чтобы несколько процессов вели запись в один и тот же файл журнала, то вы должны вручную позаботиться о доступе к вашему файлу. В соответствии с учебником по logging, есть несколько вариантов.
QueueHandler + «процесс-потребитель»
Один из вариантов — использование QueueHandler. Идея заключается в том, чтобы создать экземпляр класса multiprocessing.Queue и поделить его между любым количеством процессов. В примере ниже у нас есть 2 «процесса-производителя», которые отправляют записи журнала в очередь и «процесс-потребитель», читающий записи из очереди и пишущий их в файл журнала.
У записей журнала в очереди будут, вероятно, разные уровни, так что в функции log_processor мы используем logger.log(record.levelno, record.msg) вместо logger.info() или logger.warning(). В конце (прим. пер.: функции main) мы отправляем сигнал, чтобы позволить процессу log_processor остановиться. Деление экземпляра очереди между множеством процессов или потоков — не новшество, но модуль logging как бы помогает нам справиться с этой ситуацией.
QueueHandler + QueueListener
В модуле logging.handlers есть особый класс с именем QueueListener. Этот класс создает экземпляр слушателя с очередью журнальных сообщений и списком обработчиков для обработки записей журнала. QueueListener может заменить процесс, который мы создали в предыдущем примере, поместив его в переменную listener. При этом будет использовано меньше кода.
SocketHandler
Другое решение, предлагаемое учебником, — отправлять записи из нескольких процессов в SocketHandler и иметь отдельный процесс, который реализует сокет-сервер, читающий записи и отправляющий их в место назначения. В этих источниках есть довольно подробная реализация.
Все эти решения, в основном, следуют одному принципу: отправлять записи из разных процессов в централизованное место — либо в очередь, либо на удаленный сервер. Получатель на другой стороне ответственен за их запись в места назначения.
5. По умолчанию не генерируйте какие-либо журнальные записи библиотеки — NullHandler
На данный момент мы упомянули несколько обработчиков, реализованных модулем logging.
Другой полезный встроенный обработчик — NullHandler. В реализации NullHandler практически ничего нет. Тем не менее, он помогает разработчикам отделить библиотечные записи журнала от записей приложения.
Ниже приведена реализация обработчика NullHandler.
Почему нам нужно отделять записи библиотеки от записей приложения?
Сторонняя библиотека, которая использует logging, по умолчанию не должна выбрасывать вывод журналирования, так как он может быть не нужен разработчику/пользователю приложения, которое использует библиотеку.
Наилучшая практика — по умолчанию не генерировать библиотечные записи журнала и давать пользователю библиотеки возможность решить, хочет ли он получать и обрабатывать эти записи в приложении.
В роли разработчика библиотеки нам нужна только одна строка кода внутри init.py, чтобы добавить NullHandler. Во вложенных пакетах и модулях логгеры остаются прежними. Когда мы устанавливаем этот пакет в наше приложение через pip install, мы по умолчанию не увидим библиотечные записи журнала.
Чтобы сделать эти записи видимыми, нужно добавить обработчики в логгер библиотеки в своем приложении.
Если библиотека не использует NullHandler, но вы хотите отключить записи из библиотеки, то можете установить logging.getLogger(«package»).propagate = False. Если propagate установлен в False, то записи журнала не будут передаваться обработчикам.
6. Делайте ротацию своих файлов журнала — RotatingFileHandler, TimedRotatingFileHandler
RotatingFileHandler поддерживает ротацию файлов журнала, основанную на максимальном размере файла. Здесь должны быть определено два параметра: maxBytes и backupCount. Параметр maxBytes сообщает обработчику, когда делать ротацию журнала. Параметр backupCount — количество файлов журнала. У каждого «продолженного» файла журнала есть суффикс «.1», «.2» в конце имени файла. Если текущее журнальное сообщение вот-вот позволит файлу журнала превысить максимальный размер, то обработчик закроет текущий файл и откроет следующий.
Вот этот пример очень похож на пример из учебника. Должно получиться 6 файлов журнала.
Другой обработчик для ротации файлов — TimeRotatingFileHandler, который позволяет разработчикам создавать ротационные журналы, основываясь на истекшем времени. Условия времени включают: секунду, минуту, час, день, день недели (0=Понедельник) и полночь (журнал продлевается в полночь).
В следующем примере мы делаем ротацию файла журнала каждую секунду с пятью резервными файлами. В каждом резервном файле есть временная метка в качестве суффикса.
7. Исключения в процессе журналирования
Зачастую мы используем logger.error() или logger.exception() при обработке исключений. Но что если сам логгер генерирует исключение? Что случится с программой? Ну, зависит от обстоятельств.
Ошибка логгера обрабатывается, когда обработчик вызывает метод emit(). Это означает, что любое исключение, связанное с форматированием или записью, перехватывается обработчиком, а не поднимается. Если конкретнее, метод handleError() будет выводить трассировку в stderr, и программа продолжится. Если у вас есть кастомный обработчик, наследуемый от класса Handler, то вы можете реализовать свой собственный handleError().
В этом примере во втором журнальном сообщении слишком много аргументов. Поэтому в консольном выводе мы получили трассировку, и выполнение программы все еще могло быть продолжено.
Однако, если исключение произошло за пределами emit(), то оно может быть поднято, и программа остановится. Например, в коде ниже мы добавляем дополнительный атрибут id в logger.info без его обработки в LoggerAdapter. Эта ошибка не обработана и приводит к остановке программы.
8. Три разных способа конфигурирования своего логгера
Последний пункт, которым я хотел поделиться, — о конфигурировании своего логгера. Есть три способа конфигурирования логгера.
используйте код
Самый простой вариант — использовать код для конфигурирования своего логгера, так же, как во всех примерах, что мы видели ранее в этой статье. Но недостаток этого варианта в том, что любая модификация (прим. пер.: конфигурации) требует внесения изменений в исходном коде.
use dictConfig
Второй вариант — записывать конфигурацию в словарь и использовать logging.config.dictConfig, чтобы читать ее. Вы также можете сохранить словарь в JSON-файл и читать оттуда. Плюс в том, что этот файл может быть загружен как внешняя конфигурация, но он может способствовать появлению ошибок из-за своей структуры.
используйте fileConfig
И последний, но не менее важный, третий вариант — использовать logging.config.fileConfig Конфигурация записывается в отдельный файл формата .ini.
Есть возможность обновлять конфигурацию во время выполнения программы через сервер конфигурации. Учебник показывает пример как со стороны клиента, так и со стороны сервера. Конфигурация обновляется посредством подключения через сокет, а на стороне клиента мы используем c = logging.config.listen(PORT) c.start(), чтобы получать самую новую конфигурацию.
Надеюсь, эти советы и приемы, связанные с модулем logging, могут помочь вам создать вокруг вашего приложения хороший фреймворк для журналирования без ущерба для производительности. Если у вас есть что-нибудь, чем можно поделиться, пожалуйста, оставьте комментарий ниже!
Our Software
CatchLog provides quick and easy way to fill and submit electronic log books. Further features include reporting, maps, GPS tracking and more.
FleetManager aggregates all the data from your vessels providing you with accurate and update information allowing you to manage your business more effectively.
FisheryManager lets you collect fishing data so you can monitor the status of the fishery with ease.
Let our experienced team build the solution for you.
What do we offer?
We deliver reliable and easy to use software for e-reporting, analysis and management of your commercial fishing vessels.
Our software is designed to lower your costs, save you time and take the headaches out of managing your fleet.
We have excellent support and strive to keep our customers satisfied!
Our team of developers are working around the clock to make sure the software we provide is reliable, up to date and has all the features you require.
Our motto: «Software designed by Fishermen for Fishermen».
Why Use Catchlog?
What do I get?
Certifications
U.K. CatchLog meets the UK Fishing Vessel’s Electronic Logbook Functional Requirement Specification ERS 3.1 which encompasses the way data is used to process, store, record and send to the Fishing Authority.
Our program also works together with AQIS for Food Safety Management, necessary for the fishing industry that exports their products.
What Fishermen Say
Charlie Fuss, Skipper
CatchLog is the way of the future for the fishing industry. I think every fisherman should give this program a go.
«CatchLog is the way of the future for the fishing industry. I think every fisherman should give this program a go. Even those that may not be completely comfortable with technology will soon discover that CatchLog is a program that is so easy to operate and it will make their job a lot easier for them. CatchLog lets you enter your catch records quickly and easily and then retrieve this information at the click of a button.
I like to wait till I’m on anchor and then feed the data from the previous night into the system, but if you have a computer on board separate to your plotter you can just have it open 24/7 and enter the information in directly each shot if you prefer.
To me a program like CatchLog makes good sense for me as a skipper and for our fishing company too.»
Charlie Fuss, Skipper, Comac Endeavour
Con Triantopoulos, Skipper
«I have been using CatchLog for the past two years and went full on with it last year when we started using it as our sole logbook with data being sent to AFMA via the program.
It is great to do away with the paper records and we got a good report back on our logbooks from AFMA. CatchLog is fairly easy to use, especially if you have a bit of computer experience behind you already. Even someone green to it can learn it in a few days.
There was good support too, with help just a phone call away and any problems sorted out very quickly. I found the whole program useful. It is excellent to have all the data available and calculations made for you the click of a button. I have just started to use it for vessel management as well as logbooks and when you know your prawn price CatchLog can work out all your crew deductions and payments. I recommend CatchLog to other fishermen as an invaluable tool for the industry»
Con Triantopoulos, Skipper, Dampier Pearl
Matthew Smith, Skipper
Since I started using CatchLog 12 months ago it has proven itself to be one of the most useful tools on board.
«Since I started using CatchLog 12 months ago it has proven itself to be one of the most useful tools on board the boat.
CatchLog is so simple and user friendly. Why would anyone still fill out the 4 or 5 paper logs required in our fishery, when they can do it all so quickly and easily using CatchLog? Instead of being a tedious chore, CatchLog makes you want to enter your catch data because it shows you instantly exactly how your vessel is traveling. If you enter a product price you can even get the dollar value for your catch.
The CatchLog back up and customer service is fantastic too, with support at hand whenever you need it and feedback on the program welcomed and taken into consideration for new versions. I highly recommend CatchLog to any fisherman, whatever sector of the industry they are working.»
Matthew Smith, Skipper, FV Cenator
Phil Robson, Fleet Manager
increased productivity for our skippers so they can concentrate on fishing rather than administration.
«The Raptis Group is pleased to say we are one of the first customers to install the CatchLog program on its fleet of vessels and have been active users of the product now for three seasons. During this time, we have supported Dieter Bohm and his CatchLog team to bring the product to market, inputting to the product development schedule by offering our customer requirements and giving valuable feedback on actual field usage. While this development has occurred, the Raptis Group has received value from the product that I can say has been demonstrated through increased productivity for our skippers so they can concentrate on fishing rather than administration.
To the best of our knowledge, there is no product on the market that matches CatchLog’s functionality and while they continue to work closely with companies such as Raptis, it would appear that CatchLog will remain the market leader for vessel management systems in the commercial fishing industry for some time to come.»
Phil Robson, Raptis Fleet Master
Michael O’Brien, Fleet Manager
I now have a complete management system that allows me to manage our vessels for maximum performance and profitability.
“Since leasing the CatchLog Fleet Manager program for our three vessel company we have been able to manage our catch break up and our vessels’ break-even position on a daily basis. Our sales team can now market our product down to the number cartons in each species and grade before the product is landed. The progressive catch total allows us compare our performance at any time of the month or year to budget. Fleet Manager also lets us manage our expenses on a per-vessel basis, right down to where on the vessel it was spent. The charts and reports are a great way to show the skipper and our company shareholders where the costs are and where profits are being made or lost. As the program is run using the cloud storage system it allows me to set individuals up with different levels of usage in the program and they can access it via their own computer, wherever that maybe.
At the end of the day I now have a complete management system that allows me to manage our vessels for maximum performance and profitability. Our shareholders are now more aware of their investment on a daily, weekly or monthly level, depending on their particular requirement. We are also working closely with the CatchLog management team in developing the program further on a daily basis to make it even more impressive.”
Michael O’Brien, Tropic Ocean Prawns
Paul Baetson, Fleet Manager
Fleet Manager for Ruby Marine is all about how we can use the program to boost sales and marketing.
“For our company the advantages of using CatchLog Fleet Manager are:
Before Fleet Manager I had to wait till the end of the season and for the vessel returned to port before I could download the catches from the onboard computer. Now I can see easily see the catch on any given day. If a customer complains about a product i.e. size or quality (e.g. loose head or black spot) I can enter the catch date into Fleet Manager, check the position of the vessel and how much was caught that day. E.g. if a customer buys 4 tons of shrimp and finds some product with a problem I can check the catches for that date and offer an appropriate price reduction only on the amount caught that day, rather than on the whole order. Owners overseas can monitor the catches via the internet eliminating expensive sat phone calls.
Fleet Manager for Ruby Marine is all about how we can use the program to boost sales and marketing.”
Paul Baetson, Ruby Marine Engineering
Adam Doyle, Fleet Manager
Fleet Manger has made the task of Landing Declarations straight forward and easy
Fleet Manger has made the task of Landing Declarations straight forward and easy and can be done in five minutes, with all the additional features FM offers you can have all the information you could ever want on your fleet.
CatchLog 4 has turned electronic reporting into an easy task, simple non confusing interface and straightforward options. You don’t need to be a computer wiz to operate CatchLog.
Adam Doyle, W. Stevenson & Sons Ltd