Получается, если программирование "всегда чертовски сложно", то оно всегда «идёт с трудом» по определению, не зависимо от «видений»? )
Иногда сталкивался с ситуациями когда результат ясен, но достижение результата дается тяжело, хотя бы по причине необходимости освоить новую, не очень простую предметную область.
Пилотному проекту электронных больничных, который (если верить телевизору) с успехом внедрен в нескольких регионах страны тоже не мало времени, но понятных и исчерпывающих инструкций я не услышал, даже общаясь с местным ФСС. С одной стороны ФСС требует от больниц участия в проекте, с другой, не на все вопросы по организации способны ответить. Ну да ладно, больничные, пожалуй, оффтоп для этой темы.
Я так понял, на практике любой чек можно получить в электронном виде на сайте ОФД или налоговой, вбив в специальной поисковой форме тот или иной набор реквизитов с бумажного. Бумажный чек фискальные регистраторы от 'Штриха' печатаются всегда (те модели, что стоят у нас, по крайней мере).
Согласно 54-ФЗ при расчётах продавец обязан выдать кассовый чек покупателю на бумажном носителе или в электронном виде по sms или e-mail (если есть техническая возможность).
ООО "...", выступая в роли оператора фискальных данных, автоматически отправляет электронные чеки в электронном виде по sms или e-mail, если они содержат адрес получателя.
Обратите внимание: Согласно 126-ФЗ «О связи» от покупателя необходимо получить письменное согласие или заявление на получение sms-рассылки до момента расчёта.
С одной стороны кассирам удобно отфутболивать и без того немногочисленных прогрессивных покупателей, с другой стороны, зачем такая информатизация вообще, если под каждую электронную операцию нужна бумажка?
С электронными больничными, кстати, такая же история — хочешь, чтобы оформили не классический больничный на бланке, пиши заявление, и (в случае чудесного стечения обстоятельств, когда твой работодатель и больница работают в этой новой системе) больничный тебе занесут в базу.
Спасибо за отзыв, но обрезать права — это общая рекомендация, просто отобрать админские? Например, есть типичная локальная сеть небольшой организации (десятки компьютеров xp,7-ки,8-ки), без всяких доменов(1 рабочая группа), с доступом у отдельных юзеров к серверу mssql,1c, общим папкам для хранения и обмена документами. Понятно, что права у всех пользователей не админские, патчи постоянно упоминающиеся в статьях стоят, по папкам windows раскиданы пустые файлы «perfc», но я так и не понял, достаточно ли этого, чтобы вирус не смог воспользоваться инструментами Psexec, WMI?
ИМХО, проблема с графикой в недостаточно большом спросе на качественную, «трудоемкую» графику, а ля «честное 3д с нуля на заказ». Основной потребитель графики — реклама, а там засилье накачанных со стоков готовых полуфабрикатов и шаблонов, обработанных и собранных в шопе, люстре или еще в какой 2д проге в готовый макет. Это быстрее, дешевле, а главное устраивает заказчиков. Да, есть какой-то спрос на 3д у нас (те же игрушки), но он несопоставимо меньше, если сравнивать с зарубежными рынками(читай США). При этом 3д привлекает у нас много начинающих (причины очевидны, этож 3Д!), ну и как и в сайтостроении, или коммерческой фотографии прогнозируемо снижает среднее качество и среднюю цену на работы. Выход — найти способ или тупо ждать, когда экономика страны выйдет на уровень, когда спрос на хорошую графику будет экономически оправдан. Когда т.в. каналы, сайты, полиграфия, и т.д. с годной графикой будут более экономически выгодны, чем с посредственной графикой.
П.С.:
не слишком ли тяжелая 4К картинка для привлечения внимания? )
Благодарю за рекомендации, но, насколько я понял, они не касаются напрямую повышения безопасности используемых вирусом легальных инструментов Psexec, WMI. Я ими сам не пользуюсь, а отключить службы за них отвечающие опасаюсь, т.к., возможно, что-нибудь сломается в штатной работе системы.
Т.е. вопрос в том, как гарантировано не дать вирусу ими воспользоваться не создавая при этом проблем для обычной работы.
Перешли (вынужденно) на онлайн кассы в апреле. За все это время покупателей попросивших прислать чек на мыло или мобилку было ноль. В «ОФД» данные уходят исправно, правда появляются на сайте с задержкой до нескольких часов. У нас бумажные чеки проходят проверку приложением от налоговой, а в соседнем продуктовом магазине нет. У них там в QR закодирована ссылка по которой сразу попадаешь на сайт ОФД с чеком, — удобно, но это, видимо, все равно нарушение. Также, ИМХО, данные ни в какую налоговую автоматом не уходят, там своих проблем хватает, чтобы еще чеки у себя хранить. По запросу по конкретному юр.лицу, я думаю, данные будут получать и скорее всего только итоги за период, чтоб сопоставить с поступившими налогами.
Спасибо за ссылки. Действительно, не совсем тривиально, и пока не понятно насколько это применимо в моей печальной ситуации с локальной сетью, где в основной массе машинки с xp. (
Прямо какая-то беда с этими легальными инструментами, и странно, что так мало информации по настройке безопасности в этом контексте.
А вот атаку через эти легальные инструменты: Psexec, WMI можно как то предотвратить, но так чтобы не сломать штатную работу локальной сети, сервера, пользовательских компьютеров? (а то я так и не нашел рецепта для не продвинутых админов).
Перешли в своей конторе на «онлайн» версии фискальных регистраторов от фирмы штрих-м. ПО древнее самописное, думали придется на 1с переходить, но спасибо разрабам штриха, за то что почти никаких изменений вносить не пришлось, лишь несколько строк, для того, чтобы отправка чеков по смс и почте заработала. И «неспасибо» за то, что подробной документации с примерами по работе с новыми так и не было, все по форумам выискивали. Проблему с размазыванием скидки на весь заказ по ценам в отдельных позициях так и не решили(кто вникал тот в курсе), пока тупо пробиваем одну позицию с обобщенным названием.
Спасибо за пояснения. Мне почему-то казалось, что отладка скриптов в том или ином виде уже существует, раз Qt Creator умеет отлаживать QML приложения. Думал, в основе QJSEngine какая-то разновидность движка V8, а к последнему вроде есть внешние отладчики и документация, но увы, «подключить» не получилось.
Вот бы еще гуру реализовали пример отладчика для QJSEngine скриптов. QJSEngine шустрее, чем старый добрый QtScript, но отсутствие аналогичного примера или хотя бы документации на эту тему, снижает удобство применения.
Интересно, в этом среднем значении (10-12 книг в год) учтены книги прослушанные в наушниках по дороге на работу и обратно? )
~250 рабочих дней, умножаем на ~1 час в день в наушниках, делим на ~10 часов звучания — одна книга, получается ~25 книг в год… все равно маловато. (
Предлагаю учесть еще короткие детские книжки прочитанные ребенку перед сном, тем более они заведомо хорошие. )
Иногда сталкивался с ситуациями когда результат ясен, но достижение результата дается тяжело, хотя бы по причине необходимости освоить новую, не очень простую предметную область.
С одной стороны кассирам удобно отфутболивать и без того немногочисленных прогрессивных покупателей, с другой стороны, зачем такая информатизация вообще, если под каждую электронную операцию нужна бумажка?
С электронными больничными, кстати, такая же история — хочешь, чтобы оформили не классический больничный на бланке, пиши заявление, и (в случае чудесного стечения обстоятельств, когда твой работодатель и больница работают в этой новой системе) больничный тебе занесут в базу.
П.С.:
не слишком ли тяжелая 4К картинка для привлечения внимания? )
Т.е. вопрос в том, как гарантировано не дать вирусу ими воспользоваться не создавая при этом проблем для обычной работы.
Прямо какая-то беда с этими легальными инструментами, и странно, что так мало информации по настройке безопасности в этом контексте.
~250 рабочих дней, умножаем на ~1 час в день в наушниках, делим на ~10 часов звучания — одна книга, получается ~25 книг в год… все равно маловато. (
Предлагаю учесть еще короткие детские книжки прочитанные ребенку перед сном, тем более они заведомо хорошие. )