26 октября 2021 нет комментариев

Проблематика

В случае большой влажности (например, в дождливую погоду или на море) есть ощущение, что табак в стиках iqos промокает. В следствие чего при использовании табак прилипает к нагревающему элементу и дает меньше дыма. Такая ситуация возникает иногда и для свежераспечатанных пачках стиков

Решение

  • в летнее время держать открытые пачки на солнце
  • в зимнее время держать открытые пачки на батарее
Теги: рецепт

Жизненная ситуация

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

Проблематика

Одной из SEO-проблем CMS Webasyst является повторение значений мета тэгов title и descripton на страницах пагинации.

В частности Яндекс считает это проблемой и выдает соответствующие предупреждения на странице: https://webmaster.yandex.ru/site/ваш_домен/indexing/double-descriptions/

Решение

Решений вышеупомянутой проблемы может быть множество, ниже я привожу одно из них.

Поскольку проблема возникла на страницах пагинации, то и решать ее логично при помощи использования номеров страниц. То есть к значениям тэгов title и descripton добавить номера страниц.

Для этого необходимо в шаблоне используемой темы в файле index.html строчки:

<title>{$wa->title()|escape}</title>
...
<meta name="description" content="{$wa->title()|escape}" />

заменить на:

<title>{if  $page > 1}{$wa->title()|escape} (страница {$page}){else}{$wa->title()|escape}{/if}</title>
...
<meta name="description" content="{if  $page > 1}{$wa->title()|escape} (страница {$page}){else}{$wa->title()|escape}{/if}" />

Лирика

Сколько не дорабатывай свой сайт на бесплатной CMS... Яндекс быстро придумает новые требования... и опять сначала... Видимо всё делается для того, чтобы каста SEO-оптимизаторов не голодала :)

Теги: рецепт

Жизненная ситуация

Часто встречается необоснованное злоупотребление перечисляемыми типами. И вообще в целом в ИТ, и в частности в xsd-схемах. Бывает, что "ноги растут" со стороны разработчиков, у которых используется "хардкод", но бывает, что и сами аналитики создают проблемную ситуацию, совершенно невынужденную.

Сразу оговорюсь, в данном посте буду иметь в виду ситуацию только относительно xsd-схем. Может когда-нибудь попозже попробую экстраполировать вопрос в общем на системы.

Проблематика

Проблема при злоупотреблении перечисляемыми типами в xsd-схемах простая. При изменении состава значений типа возникает необходимость изменять сам перечисляемый тип. Следовательно возникает необходимость менять версию схемы. А если сам процесс перерегистрации схемы и доработки систем под это изменение очень продолжительный (например, он продолжительный в СМЭВ), то эта ситуация может создать очень серьезные проблемы, вплоть до остановки бизнеса.

Решение

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

Гораздо гибче решение обмениваться кодами значений справочника. Сами значения справочника включить в регламент обмена. При каждом изменении значений справочника менять регламент. При этом нет необходимости менять сами xsd-схемы, системы будут продолжать обмен.

Помимо этого смело использовать перечисляемые типы можно для системных вещей. Например, для действий с записью можно смело ограничить значения на "создание", "обновление", "удаление" и т.п. Например:


<xsd:simpleType name="operationType">
   <xsd:restriction base="string">
      <xsd:enumeration value="CREATE">
         <xsd:annotation>
            <xsd:documentation xml:lang="ru">Добавление записи</xsd:documentation>
         </xsd:annotation>
      </xsd:enumeration>
      <xsd:enumeration value="UPDATE">
         <xsd:annotation>
            <xsd:documentation xml:lang="ru">Обновление записи</xsd:documentation>
         </xsd:annotation>
      </xsd:enumeration>
      <xsd:enumeration value="DELETE">
         <xsd:annotation>
            <xsd:documentation xml:lang="ru">Удаление записи</xsd:documentation>
         </xsd:annotation>
      </xsd:enumeration>
   </xsd:restriction>
</xsd:simpleType>

Лирика

Нельзя использовать перечисляемый тип, если значения регламентируются законодательством. Пусть это даже, например, гендерный пол человека. Никто не может с уверенностью дать гарантию, что через несколько лет даже в нашей стране не появятся новые значения пола, например, "онЖеБаба" или "онаЖеМужик". Есть страны, у которых это целый классификатор. Надеюсь, в нашей стране не дойдет до такого.

Но тем не менее в схеме базовых типах СМЭВ сейчас числится такой тип для пола:


<xs:simpleType name="GenderType">
   <xs:annotation>
      <xs:documentation>Пол.</xs:documentation>
   </xs:annotation>
   <xs:restriction base="xs:string">
      <xs:enumeration value="Male"/>
      <xs:enumeration value="Female"/>
   </xs:restriction>
</xs:simpleType>

Другой неправильный пример использования перечисляемого типа это тип boolean со значениями true / false. Понятно же всем, что в России это не работает :) в России полный fuzzy logic, и не факт что хватит третьего значения "Не знаю" ;)

Жизненная ситуация

Повидав немало xsd-схем, я обнаружил, что мало кто использует ограничения на типы даты / времени. Бывает все в схеме по максимуму ограничат, даже больше, чем нужно, а дата и время в используется исходном базовом типе.

Проблематика

Какие в такой ситуации я вижу риски при интеграции систем посредством обмена данными через XML-фалйы:

  • Пропуск при валидации по схеме "дефолтного" значения даты

    Дело в том, что в некоторых базах данных в полях с типом даты и даты / времени вместо значения null (пустого значения используется какое-нибудь минимальное значение, типо 1900-01-01.

    Что это значит.

    А то что при передаче данных по xsd-схеме дата, например, является обязательной, а в интегрируемой системе не реализовано ее корректного заполнения, и система заполнит ее "пустым" значением, например, тем же 1900-01-01. Передаст совсем не бизнесовую дату, которая сломает далее по процессу всю логику

  • Использование неправильного значения времени и даже даты из-за часовых поясов

    Мало кто заморачивается указанием часовых поясов в типах даты / времени xml-файлов, а это может привести к ошибкам, даже если при обмене оба сервера находятся в одном часовом поясе. Просто потому что при развертывании сервера забыли указать для него правильный часовой пояс, и он использует время Гринвича.

    А при обмене между разными часовыми поясами, пож-та, не надо думать, что все сервера настроены на московское время всегда

Решение

У этих описанных выше двух рисков есть одно простое покрытие: использование паттерна ограничения значений.

Ниже приведены примеры такого ограничения. Диапазон значения дат можно менять по вкусу, но с учетом "дефолтного" значения даты в используемой интегрируемой системой базе данных

  • Тип времени и даты


    <xsd:simpleType name="typeTimeStamp">
       <xsd:restriction base="xsd:dateTime">
          <xsd:pattern value="2[0-9][0-9][0-9]-(0[1-9]|1[012])-(0[1-9]|1[0-9]|2[0-9]|3[01])T[0-2][0-9]:[0-5][0-9]:[0-5][0-9](\+(0[2-9]|1[0-2]):00|Z)"/>
       </xsd:restriction>
    </xsd:simpleType>
    Данный паттерн обязывает для времени либо явно указать часовой пояс, либо передать приведенное к Гринвичу время
  • Тип даты


    <xsd:simpleType name="typeDate">
       <xsd:restriction base="xsd:date">
          <xsd:pattern value="2[0-9][0-9][0-9]-(0[1-9]|1[012])-(0[1-9]|1[0-9]|2[0-9]|3[01])"/>
       </xsd:restriction>
    </xsd:simpleType>

Лирика

В примере выше диапазон дат ограничен третьим тысячелетием. Если вы считаете, что ваша схема будет использоваться и в четвертом тысячелетии, то пример выше можно легко поправить с учетом этого :)

Но вообще лучше подстраховаться и значения годов четвертого тысячелетия не обрубать валидацией, да :) чтобы российский, например, госчиновник следующей цивилизации четвертого тысячелетия, откопав такую схему, не рассердился на человека 21-го века и не отправил в прошлое андроида при исполнении показывать кто тут валидный :)

В жизни каждого человека рано или поздно возникает необходимость сравнения двух версий текстовых файлов. Не только в жизни веб-программиста :)

Для этой цели использовать функциональность сравнения Microsoft Word смысла нет, да и не каждый имеет установленным это ПО и не каждый доверит ему сравнение двух текстовых файлов.

Поскольку мой основной инструмент работы с различными текстовыми файлами (xsd, xml, json, php, tpl и многие другие) это Notepad Plus Plus, то я нашел способ делать сравнение в нем. Я только нашел :) респект ребятам, которые это реализовали в свободном доступе.

Способ простой:

  1. Устанавливаете Notepad Plus Plus
  2. Устанавливаете в нем плагин Compare
  3. Открываете в Notepad Plus Plus оба файла
  4. Нажимаете на подпункт меню Compare в меню плагинов

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

Еще один совет: если при поиске плагина по названию compare вы его не видите, значит (скорее всего) у вас старая версия Notepad Plus Plus - ее просто нужно обновить

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

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

Кроме того, буду рад замечаниям и отзывам, постараюсь ответить на интересующие вас вопросы, попробую решить присланные вами задачки.

Помимо всего я готов на условиях дополнительной временной занятости (freelance) решать более серьезные задачи. Имею большой опыт в системной аналитике, в том числе серьезные государственные федеральные проекты (СМЭВ, ЕПГУ - то, чем я занимаюсь).

Мой контакт в телеграмме: @farlander

4 сентября 2020 нет комментариев

В текущем итак не простом две тысяче короновирусном году мой текущий хостинг-провайдер RU-CENTER решил не предоставлять продление моего архивного тарифа.

Мой тариф был 2005 года и был весьма гуманен относительно текущих цен. С этим тарифом я переходил от одного хостера к другому раза четыре по причине их поглощения. И вот теперь RU-CENTER поглотил всех и решил, что халява закончилась. Наверное имеет право, по крайней мере мы точно имеем право выбирать.

Я конечно же стал искать. И нашел один хостинг, который предлагает примерно такую же цену, как на моем тарифе 2005 года, а именно от 72 рублей в месяц. При этом этот хостер является официальным партнером регистратора российских доменов REG.RU и предоставляет возможность выбора хостинга на территории Российской Федерации. Помимо расположения в РФ можно выбрать сервера в Германии, Нидерландах, Швейцарии, в Уркаине даже на, в штатах.

Кроме того, у меня есть ссылка, пройдя по которой вы получите еще 10% скидки на любой тариф хостинга, 1% на регистрацию домена и 5% на прочие услуги.

Скидка на услуги FORNEX.COM

После долгого периода "самоизоляции", который мы своей семьей терпеливо пересидели дома, мы столкнулись с совершенно не понятной нам и не логичной ситуацией. А именно с "приостановкой эпидемии", как многие подозревают, в целях проведения парада и проведения голосования по поправкам к Конституции.

Расскажу конкретно нашу историю. Хотя слышно подобных по Московской области их много. У всех историй есть одно общее: медицина игнорирует заболевших граждан, больные вынуждены за свой счет обращаться к платной медицине. Наверняка в Московской области области ситуация не самая худшая, но и не самая лучшая. Точно знаю, что в Тюменской области намного лучше, но там систему медицины подняли очень давно, наверное еще при Собянине. Так что по поводу ситуации в других регионах прошу поведать в комментариях (см. ниже).

Собственно что случилось? Моя жена заболела, была температура 37,5, слабость, позже начался кашель.

После недели болезни мы начали бить тревогу. Для начала я позвонил в скорую, описал ситуацию, спросил - что делать? Ответили, что нужно вызывать врача на дом, что для скорой такая ситуация (температура 37,5 в течение недели и слабость) не являются достаточными для выезда.

Я начал вызывать врача на дом. Есть в Московской области единый номер горячей линии портала здравоохранения 8 (800) 550-50-30, я позвонил на него 12 июня в обед и вызвал врача на дом, заявку приняли и обещали врача в течение дня. Врач не пришел, 13 июня я уже три раза звонил по этому номеру и объяснял, что врач не пришел, что делать. Оператор мог только оформлять заявки на вызов врача, связи с поликлиниками у него нет. Кроме того, я позвонил на Единую горячую линию стопкороновирус.рф по номеру 8-800-2000-112, там мне ответили, что ситуация конечно странная, врач должен был быть 12 июня, но сделать они ничего не могут, претензии не принимают, с претензиями отправили по номеру 8 (495) 748-48-80, который в выходные работает только в режиме автоответчика. То есть в выходные помирайте молча как хотите.

В понедельник 15 июня вызвали врача уже по прямому номеру поликлиники, врач пришел в течение полудня. Врач зашел в уличной обуви без бахил, без перчаток и без обработки рук антисептиком, был только респиратор на нем. Врач выслушал, поглядел горло, послушал легкие. Сказал, чтобы жена сама пешком через неделю пришла в поликлинику для оформления больничного, а пока принимала противовирусные. На мои слова об ее ответственности в случае осложнения, врач ответил, что никакой ответственности нет. Если хотите тест на короновирус, рентген и КТ, то через неделю приходите к врачу, он направит к инфекционисту, а тот в случае необходимости что-нибудь из этого назначит. Занавес.

Неделю мы не дождались. Болезнь протекала тяжело. Вызвали врача на дом еще раз. В надежде, что уж теперь-то после осложнения назначит что-нибудь. Назначил только принимать антибиотики таблетками, поставил диагноз ОРВИ (без единого анализа) и напомнил прийти самим в поликлинику для продления больничного. Занавес.

После этого мы стали лечиться сами уколами антибиотиков, стало лучше. А когда приходили в поликлинику за больничным, в очереди (время это заняло более трех часов!) услышали и пострашнее истории. Бабуля 74 года с аналогичными симптомами тоже не могла попасть в больницу, тоже вынуждена была ходить в поликлинику пешком. А для нее намного тяжелее все воспринималось, что у нас молодых одышка и тяжелое дыхание, то у нее невозможность дышать. В больницу ее положили только после того, как она за свой счет сама пешком сделала КТ и показала результаты врачу. До этого тоже даже рентген выпросить не могла.

Собственно ситуация в Московской по крайней области с медициной далеко не такая красивая, как поют на федеральных каналах. Пациент у нас скорее мертв, чем жив. Возможно врачей вынудили сверху перед парадом Победы и голосованием по поправкам в Конституцию приостановить рост заболеваемости. Если так, то это ужасно, это просто геноцид. Другой вариант тоже пугает: если такая ситуация была и до (во время карантина) и будет после.

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

PS Прошу оставлять в комментариях ваши истории, чтобы картина складывалась более общая.

6 февраля 2019 нет комментариев

Крайне не рекомендую пользоваться услугами интернет-магазина Онлайн Трейд по причине больших проблем со сдачей товара ненадлежащего качества по гарантии.

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

Чтобы получить возврат средств в Онлайн Трейд вам придется мотаться по различным точкам несколько раз, а именно:

В любой пункт выдачи Онлайн Трейд, чтобы поставить печать магазина в гарантийный талон

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

    Итого по продолжительности это у меня заняло два месяца.

    Сервис booking несомненно удобен и весьма популярен по всем мире.

    Но есть один весьма немаловажный нюанс: ваше заселение в забронированный объект сервис booking никак не обеспечивает.

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

    Чтобы не быть голословным: забронировал (номер брони 1646450379) апартаменты в Иваново на 1 января 2019 года, позвонил за неделю убедиться в брони - по контактному номеру ответили, что все хорошо и ждем вас. Когда я уже ехал по адресу данного объекта и звонил - контактный номер не отвечал. Поскольку объект был квартирой к жилом доме, идти разбираться по сути было некуда. По итогу пришлось по справочнику обзванивать гостиницы, чтобы не остаться ночевать на улице всей  семьей.

    По возвращению из путешествия я пытался разобраться в ситуации с поддержкой booking, но не нашел их участия в данной проблеме. Заметьте, в данном сервисе нет функции не заселения по вине хозяина объекта, такой случай не является для сервиса важным и по сути игнорируется. С третьего только моего обращения в поддержку я получил такой ответ:

    Уважаемый Александр, Благодарим Вас, что воспользовались услугами Booking.com. Мы обращаемся к Вам по поводу бронирования 1646450379 в Apartment on Moskovsky 17 (заезд: 2019-01-01, отъезд: 2019-01-02). Ситуации переселения гостей случаются, и мы не можем блокировать объекты размещения в данной ситуации. К сожалению, поскольку Вы по факту не проживали в данном объекте размещения, Вы не может оставить отзыв на сайте. Еще раз приносим извинения за неудобства. Пожалуйста, обращайтесь к нам в случае возникновения любых дополнительных вопросов. С уважением, --
    Ljusjena S.
    Booking.com Customer Service Team