TrackChecker -программа для отслеживания посылок от MetalDDD

[_Slav1k_]

А если раньше? Вот поставили мы текущее время, если его не оказалось. А на самом деле оно (событие) должно идти первым.

Прыжок в прошлое?
Более ранние события уже зафиксированы. Приходит следующее, без времени. Как оно может быть более ранним? А если такие чудеса и бывают, то:

выставлеям вручную время у события так, чтобы оно попадало куда надо.

Поскольку чудеса крайне редки по определению.

Предложенный Вами вариант так же не идеален.

Ну, идеал, он недостижим. Но это не повод отказываться от небольших улучшений.

 

[MetalDDD]

это не повод отказываться от небольших улучшений

Не повод. Ладно, алгоритм, как я понял, предлагается следующий: у события без времени брать время создания события, если дата создания=дате события, полученной с сервиса.
Правильно я понял?

 

[_Slav1k_]

Ладно, алгоритм, как я понял, предлагается следующий: у события без времени брать время создания события, если дата создания=дате события, полученной с сервиса. Правильно я понял?

Да, именно так. А для "вчерашних" без времени можно ставить 23:59:59. ИМХО, вреда не будет.

 

[MetalDDD]

А для "вчерашних" без времени можно ставить 23:59:59.

так. давайте более алгоритмическим языком.
т.е.: если у события нет времени и его дата раньше(меньше) даты создания, то время события считать 23:59:59. так? блин, это же все криво будет смотреться. Счас у событие без времени просто дата указана... а по новому ко всем безвременным событиями приляпается 23:59:59...

 

[CancheZ]

MetalDDD, "козлик, вася прав"© )) На самом деле предложен вариант времени событий очень даже хороший.

блин, это же все криво будет смотреться. Счас у событие без времени просто дата указана... а по новому ко всем безвременным событиями приляпается 23:59:59...

А что если для таких событий не отображать время, а только сортировать их со временем 23:59:59 или временем получения события с сервиса? Т.е. визуально ничего не изменится не будет смотреться коряво или неправдоподобно, но сортировка событий при этом станет более адекватной.
При этом, если пользователь поменяет время такому событию, то вновь введенное время должно появиться рядом с датой и учитываться при сортировке.

 

[_Slav1k_]

Ну, вчерашнее событие, о котором мы узнали сегодня, явно же было последним из вчерашних? Так что 23:59:59 - вполне, поскольку гарантирует, что в списке оно будет последним.
Иначе такое событие займет случайное место в списке вчерашних.

Если бы было какое-нить поле отвечающее за порядок событий, ко времени можно было бы и не привязываться.
Типа инкрементального ID, чтобы след.запись всегда была как минимум на единицу больше. Хотя такой вариант менее информативен. Со временем лучше.

 

[GrAnd]

Я вот никак не пойму, чем 23:59:59 принципиально лучше 00:00:00?
В первом же случайно ткнутом треке из истории у себя обнаружил следующее:

2.2.2012 - Покинуло сортировочный центр


2.2.2012 16:51 - Прибыло в место вручения

С предложенным алгоритмом сортировка станет также неверной, как и сейчас, в случае если бы первое событие было с датой, а второе - без. И позволю себе напомнить, что в частности Почта России, довольно часто тормозит с обновлением статусов, и эти события могут запросто появиться "задним числом" и прочитаться программой только через день или даже 2 после актуальной даты.
По этой же причине ID (номер нового события) не всегда следует по порядку. Я это уже проверял - нареканий на сортировку кардинально прибавилось - пришлось от этого отказаться.

 

[_Slav1k_]

чем 23:59:59 принципиально лучше 00:00:00

Тем что оно больше Это для вчерашних событий.
А в твоём случае по новому алгоритму было бы примерно так:

2.2.2012 12:10 - Покинуло сортировочный центр

2.2.2012 16:51 - Прибыло в место вручения

Где 12:10 - время когда программа обнаружила событие.

Добавлено спустя 40 мин. 38 сек.
Что касается Почты России - специально глянул, она отдает список с историей, в правильном порядке и со временем.
Предложение с 23:59:59 касалось в основном сервисов, которые дают только последний статус и не всегда указывают время. Там всё должно работать штатно.

В случае сервисов, отдающих список - нужно просто сохранять порядок этого списка. (то самое ID) Проставлять ли при этом время- дело десятое.
Да и в случае списка, если добавилось одно или два события без времени - то и тут алгоритм сработает правильно.

 

[GrAnd]

Где 12:10 - время когда программа обнаружила событие.

При условии, что событие подцепилось программой в тот же день. И как я уже сказал, ПР не гарантирует возникновение этого события немедленно. Может и несколько суток пройти. А если я проверяю треки в ручном режиме, то и подавно нет никаких гарантий.

Что касается Почты России - специально глянул, она отдает список с историей, в правильном порядке и со временем.

Порядок правильный, только вот заполняться этот список может далеко не последовательно. Да и время не у всех статусов есть. У "Покинуло сортировочный центр" и "Вручение" - время очень часто не указывается.

 

[_Slav1k_]

Порядок правильный, только вот заполняться этот список может далеко не последовательно

Ну дык достаточно этот порядок выдерживать. Для сервисов отдающих историю.
Для тех, что дают последний статус - алгоритм работает лучше чем текущий. А таких ИМХО большинство.

Вопрос же не в том, какое время будет стоять там, где его нет. А в том, чтобы порядок событий совпадал с естественным.

 

[GrAnd]

А в том, чтобы порядок событий совпадал с естественным.

Когда идёт отслеживание по нескольким сервисам, то в этом случае становится далеко не очевидным ответ на вопрос как смешивать "порядок" событий от одного сервиса с "порядком" событий от других. Особенно, если один сервис дублирует события другого, но первый указывает время, а второй нет (читай, оно всегда 23:59:59). Тогда события тоже могут перемешаться "не адекватно". В общем, нет в мире идеала.

 

[Comrad]

В этой версии так и не появился перевод с китайского? :(

 

[_Slav1k_]

Когда идёт отслеживание по нескольким сервисам, то в этом случае становится далеко не очевидным ответ на вопрос как смешивать "порядок" событий от одного сервиса с "порядком" событий от других.

Вопрос о том, что хорошо бы сделать тут "эстафету" уже поднимался.
Кроме упомянутых там резонов я бы ещё добавил снижение нагрузки на сайты. зачем опрашивать службу, с которой посылка уже ушла?
Кстати, мне сервисы, которые бы продолжали трекать посылку, когда она от них уже ушла и не попадались...

 

[Ameno]

Пока не побежден: ee (почта Эстонии) - очень жаль. %)
Бедем надеятся на будущее.
У себя изменений не заметил, так ничего и не показывает (околе 15 треков RA.....CN).

 

[CancheZ]

_Slav1k_, GrAnd, вот вы тут спорите, а меня лично просто раздражают события без времени, которые сразу после появления автоматически лезут перед событиями, которые идут по порядку. Т.е. существующая схема сортировки отчасти неприемлема, т.к. она лишена логики и лишает пользователя возможности положиться на программу - за ней постоянно нужен контроль и исправления.
У меня часто события без времени лезут не туда куда нужно, устроим голосование на эту тему?
ИМХО, проблему событий без времени нужно решать, иначе в треках каша. И все упирается в частоту возникновения проблем с такими событиями, если у всех эта функция отрабатывает правильно на 100% - я смирюсь даже с тем, что это функция события без времени отрабатывает лично у меня всегда на 100% неправильно.

 

[GrAnd]

Кстати, мне сервисы, которые бы продолжали трекать посылку, когда она от них уже ушла и не попадались...

USPS -> Почта России. Обе не редко отслеживают от начала до упора. EMS тоже отслеживается в разных странах параллельно.

зачем опрашивать службу, с которой посылка уже ушла?

Для некоторых сервисов в программе проставлено правило "окончания" как раз на стадии экспорт. Так что для них проверки отключается по вылету посылки из страны.

Не знаю, почему вас так раздражает редко и местами неправильная сортировка. Вот мне лично вообще интересен только тот факт, что посылка вообще движется. Т.е. пришло новое событие, глянул, обрадовался, что "наконец-то" и всё. А куда там оно в логах поставилось, не особо и интересно. Особенно после получения посылки.

 

[MetalDDD]

_Slav1k_, GrAnd, CancheZ, В общем подумал я... предложенный ранее алгоритм внесет еще больше каши в порядок следования событий. Если сейчас события без времени ВСЕГДА идут до событий БЕЗ времени, то по новому алгоритму эти события будут находится в абсолютно случайных позициях за указанную дату, что приведет к еще большей каше.
Оставлю пока, как есть, т.к. не вижу более логичного алгоритма. Согласитесь, программа - не человек. И отсортировать по сложной "правильной" человеческой логике она не может.
Возможно сделаю экспериментальную логику сортировки в качестве опции... но, имхо, получится только хуже.

По поводу окончания отслеживания... окончание отслеживания можно разделить на два типа: когда получено ПОСЛЕДНЕЕ событие с сервиса и больше событий не ожидается. И когда получено событие об экспорте...
На данный момент при написании правила об окончании я придерживаюсь правила ПЕРВОГО типа.
т.к. , на примере USPS->rus, к примеру если программой будет пользоваться житель USA, то ему наши события на русском вообще ни к чему, отслеживать он будет только на сервисе USPS. И наверное будет не совсем правильно прекращать отслеживание в этому случае по событию экспорта...

Пока не побежден: ee (почта Эстонии) - очень жаль.

У нового портала почты Эстонии оказался какой-то заумный алгоритм общения на ajax, пока я не выявил способа, как за два запроса получить необходимую информацию с этого сервиса.

 

[_Slav1k_]

USPS -> Почта России. Обе не редко отслеживают от начала до упора.

Ну РусПочта у меня только транзитом, а у USPS такого не замечал. Как за пределы US, так и всё. Но спорить не буду - может и бывает.

В общем подумал я... предложенный ранее алгоритм внесет еще больше каши в порядок следования событий.

Некоторые проблемы могут быть только с "простывшими" событиями. И только на сервисах с историей.
Если ограничится текущим днем - никаких проблем, и вроде бы тут никто не возражал. А если применять алгоритм только к однострочным сервисам - так вообще всё Ок.

То бишь:

у события без времени брать время создания события, если дата создания=дате события, полученной с сервиса.

 

[Platoon]

Отличный софт, использую уже несколько месяцев. Работает стабильно. Недостатков серьезных не вижу. Было бы неплохо, если была бы возможность, сохраняться дату истечения платежа, чтобы не забыть открыть диспут. Вот этого не хватает, сейчас приходится в описании писать, до какого числа стоит бить в колокола.

 

[volp]

Platoon, Есть там такая возможность Меню - События - Добавить событие - ставишь дату оплаты , а потом настраиваешь цвета для разных сроков