Категорически не рекомендую данную компанию.

Во-первых.
Брал у них по соглашению бронь на земельный участок в посёлке Новокаменский Каменского МО Тюменской области за задаток. Готовили сделку, долго готовили, пока готовили условия по ипотеке не изменились, а именно начальный взнос увеличили с 20% до 30%, то есть сделка для меня стала не допустимой. Попросил вернуть задаток. Сперва начали говорить, что задаток не возвратный. Я говорю, что по соглашению написано что возвратный. Ушли думать. Вернулись, говорят, ну мы на вас потратились, вот тут архитектор в типовом проекте одну стенку дорисовал, сделал рендер, с вас 28 тыс. руб. Из задатка вычитаем. Ребята считают и явно об этом говорят, что им не важно, что условия сделки от банка делают сделку для вас не реальной, им на вас плевать в этом вопросе, считают, что им должен клиент закрывать их риски бизнеса за свой счет. Думайте сами, стоит ли работать с такими ребятами.

Во-вторых.

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

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

КАУФМАНН ЛЮДМИЛА СЕРГЕЕВНА, ИНН 7707083893, ОГРНИП 323745600135589, 423745600681141, 423745600663386, 423745600669333

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

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

Расскажу свой пример. Купили участок земли с кадастровым номером  72:17:0808003:6272 через агентство Этажи через агента Сергея Эдуардовича Останина в 2020 году. Заплатили агентскую комиссию за сделку, что для нас являлось гарантией чистоты сделки. Землю покупали с видом разрешённого использования ИЖС для последующего строительства частного дома. На сделке был предоставлен ЕГРН 2020 года и градостроительный план участка от 2016! года, в которых был указан ВРИ ИЖС. В последствии через три года во время начала строительства оказалось, что по градостромтельному плану населенного пункта и участка вмд разрешенного использования не ИЖС, а транспортная инфраструктура, на строительство частного дома на этом участке получили отказ.

На обращение в юридический отдел Этажей получили официальный письменный ответ о том, что вид разрешённого использования вероятно! был изменен после сделки, а кроме того, клиент сам был инициатором отсутствия проверки по участку и не имеет претензий, о чем он поставил подпись в некоем Уведомлении.

На самом же деле, во-первых, агент не озвучивал на сделке пункт об отсутствии проверки по объекту и отсутствии соответствующего согласия клиента, копию клиента этого Уведомления не выдали! у клиента этого уведомления нет. Во-вторых, не хитрый анализ показывает, что вид разрешённого использования земли на момент сделки уже был не ИЖС, а транспортная инфраструктура. Агент просто это даже не проверял, зачем? Есть же волшебное Уведомление.

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

Ну а рекомендую в принципе не доверять никакому агентству, или доверять, но проверять. Заказывать у агента все необходимые свежие документы по объекту.

В октябре 2021 года столкнулся с примитивнейшим, но действенным разводом от СК ВСК, связанным с досрочным расторжением договора страхования жизни.

После этого почитал интернет и ужаснулся - эта схема массово применяется, и видимо приносит прибыль компании. Куда ж смотрит ЦБ РФ? Мошенники должны быть лишены всех лицензий.

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

Всем кто столкнулся с этой гнусной ситуацией предлагаю обязательно написать о случившимся регулятору (Центробанку) на специальной форме

А тем кто не успел направить заявление о расторжении советую сперва убедиться, что СК обязана 100% по вашему договору в этом случае вернуть деньги, это должно быть явно написано в договоре.

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

В случае большой влажности (например, в дождливую погоду или на море) есть ощущение, что табак в стиках 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

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

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

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

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

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