?

Log in

No account? Create an account

Категория: it

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

Первый, и самый банальный способ - нажать кнопку PrtScr, и тогда изображение окажется в буфере обмена. Оттуда его можно вставить в любимый графический редактор (например, тот же Paint) или прямо в Outlook (и получить в свой адрес тонну матюков, потому как вставится несжатая картинка, и адресат получит письмо мегабайт эдак на пять...). Чуть более продвинутым пользователям можно нажать Alt-PrtScr, работает так же, но копируется только картинка активного окна. В Windows 8 добавлено сочетание Win-PrtScr, сохраняющее снимок всего экрана в папке \Изображения\Снимки экрана

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

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

Первый из них - Gyazo - довольно узко специализирован и предназначен именно для того, чтобы быстро поделиться скриншотом. Он представляет из себя маленькую программку, ярлык к которой висит в таскбаре. По щелчку на ярлыке курсор превращается в крестик, которым следует выделить на экране прямоугольную область. Выделенная область улетает на сервер Gyazo, после загрузки автоматически открывается страничка со скриншотом (это позволяет перед отправкой оценить, а не попало ли в кадр чего лишнего), а ссылка на картинку поселяется в буфере обмена. Просто берем и отправляем эту ссылку собеседнику - хоть почтой, хоть скайпом, хоть как. Со временем Gyazo обросло еще несколькими фишками - горячие клавиши (в отличие от щелчка по иконке в таскбаре, нажатие сочетания горячих клавиш не сбрасывает контекстные меню),  и даже возможность захвата последовательности действий и их склейки в GIF-анимацию (наверно, это круто, но у меня почему-то оно постоянно падало, да и для записи скринкастов я использую другие программы). Для тех, кому не хватает функциональности, есть платная подписка (стоит целых 2 доллара в месяц), она открывает примитивный веб-редактор (стрелочки на скриншот повесить), а также доступ к истории своих снимков за все время. Каждый сам решает, нужно ли оно ему. Я вот считаю, что не нужно.

В бытность рядовым консультантом я, устав делать скриншоты для инструкций в Paint.NET, спросил у гугля: "а какой есть аналог "Ножниц" под WinXP? Гугль мне ответил: Screenpresso. Эта программка уже который год является моей любимицей. Перехватывает нажатие клавиши PrtScr, после чего предлагает выбрать область (при этом границы окон и частей окон умеет определять сама, умница такая, даже не надо ювелирно прямоугольники выделять), после чего открывает скриншот в редакторе (который, кстати, самый продвинутый и богатый инструментами из всех, что я видел в скриншотилках). Результат обработки автоматически сохраняется в папочку на жестком диске, изображение автоматически помещается в буфер обмена (очень удобно получается делать инструкции: PrtScr - щелчок по окну/менюшке - в редакторе накидал стрелки-номера-области - вставил в Word, а если надо вернуться через какое-то время - в папке все файлы называются по дате-времени). Обработанный скриншот можно отправить по почте, через облачное хранилище, залить на какой-нибудь фотохостинг типа Flickr, или даже применить произвольный VBA или C# скрипт.
Также поддерживается функция Cloudpresso - скриншот в один щелчок заливается в облачное хранилище, и формируется публичная ссылка. Ссылка действительна 8 недель, что обычно более чем достаточно.
Начиная с версии 1.5 бесплатная версия также умеет записывать скринкаст неограниченной длины, но с ватермарком. Раньше было без ватермарка, зато 20 секунд.
Из не очень полезного, но забавного - функция автоматической сборки документа из скриншотов (можно сгенерировать PDF, Docx, HTML или даже анимированную GIF). Файл собирается по принципу "Заголовок скрина - описание скрина - картинка" (кроме GIF, который только из картинок состоит) В бесплатной версии результат обязательно будет с ватермарком. Почему я считаю эту функцию не очень полезной? Да потому, что при подготовке нормальной инструкции описание как правило получается более сложным, а для записи анимации с последовательностью действий удобнее делать полноценный скринкаст.

Минусы у Scrennpresso также есть. Первый и главный - бесплатная редакция программы требует автоматического обновления, и без проверки свежей версии просто откажется запускаться. Особых проблем это не доставляет, выключать компьютер совсем - нечастое занятие, а после гибернации Screenpresso отлично работает. Второй минус - некая тормознутость, сильнее всего проявляющаяся при запуске программы. Впрочем, в этом направлении ведется работа, и версия 1.5 уже заметно шустрее предшественниц.
У Screenpresso есть платная версия, за денежку откроются некоторые новые функции, как, например, возможность изменения уже расставленных в прошлом графических элементов (бесплатная версия сохраняет только растровый файл с итоговым результатом). Полный список плюшек можно увидеть на сайте. Честно говоря, пока на трату 28 евро я не соблазнился.

Также примитивная сохранялка скриншотов есть в Dropbox. Клиент перехватывает нажатия PrtScr и Ctrl-PrtScr, в первом случае скриншот экрана просто сохраняется в папку Dropbox, во втором - автоматически генерируется ссылка. Я у себя эту возможность отключил: мало того, что функциональность убогая, так еще и перехватывает PrtScr, что конфликтует со ScreenPresso.

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

И буквально по ходу написания этой заметки я узнал о существовании кроссплатформенной скриншотилки Joxi. Сделана она на qt, имеет версии под Windows, Linux и MacOS, имеет очень приятный и функциональный редактор, не уступающий ScreenPresso по возможностям. Для публикации снимков предлагается 1 гигабайт на ресурсе Joxi.ru. Есть опция дублирования всех отправляемых снимков в указанную локальную папку (можно увеличить надежность, указав папку в каком-нибудь облачном хранилище). Есть кнопки быстрой публикации скриншота в соцсетях. По итогам беглого тестирования обнаружились следующие минусы:
1) это все-таки программа для публикации скриншотов в интернете. Сохранение на диск без публикации и копирование картинки в буфер обмена не автоматизированы - при нажатии на кнопку "Сохранить" откроется полноценный диалог сохранения файла, а копирование в буфер необходимо осуществлять нажатием Ctrl-C.
2) не удалось обнаружить функции групповой очистки загруженных изображений, только индивидуальное удаление. Что будет, когда забьется предоставленный гигабайт - представить страшно...

upd. Обнаружил еще неплохой бесплатный скриншотер - Greenshot. Считается, что программа предназначена для разработчиков и технических писателей. Интересные функции есть (например, кнопки автоматической вставки в открытые документы Office), но впечатление портит архаичный интерфейс с мелкими пиктограммками и менюшками, а также отсутствие нумератора (ну люблю я его!)

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

Про SnapRAID + Aufs

Вопрос организации массива дисков встает перед каждым владельцем домашнего сервера. Вариантов тут масса, и все они неплохо задокументированы. Очень много русскоязычной информации можно почерпнуть в профильной ветке на iXBT и в блоге одного из главных ее активистов 2gusia. Одним из наиболее популярных вариантов является использование чудесной файловой системы ZFS. Это действительно невероятно мощная штука, по указанным мной ссылкам можно почерпнуть немало тому доказательств.

Однако (особенно если вы используете Linux) этот вариант не является единственным, и я бы хотел чуть подробнее рассказать об одной из альтернатив ZFS, вполне пригодной для использования в домашнем медиасервере. Это связка из двух программ: SnapRAID и aufs.

SnapRAID обеспечивает аналоги RAID 5-6(-7-8-9...), вычисляя контрольные суммы и храня эти данные на выделенных жестких дисках. В отличие от классического RAID и raidz, он работает поверх файловых систем - на выделенном разделе создается огромный parity-файл, каждый файл на диске лежит на одном конкретном диске. Всего для хранения контрольных сумм можно выделить до 6 дисков (т.е. в теории можно построить просто гигантский массив, устойчивый к гибели до 6 дисков). Важный момент - SnapRAID не обеспечивает полновесный пулинг дисков! В коробке есть функциональность монтирования read only-пула, построенного на симлинках, но оно нам надо? Задачи пулинга возложим на Aufs. Aufs позволяет объединить папки (их система называет Branches - ветки), располагающиеся на самых разных дисках, и взять на себя заботу - куда конкретно положить вот этот файл. Есть различные стратегии балансировки ветвей (забивать ли диски по очереди, или всегда писать на самый свободный). Файл, опять же, всегда находится на одном конкретном диске.

Эту связку активно продвигает сообщество Openmediavault, в нем даже есть плагины для установки и настройки SnapRAID и Aufs из веб-интерфейса.

Попробую описать плюсы и минусы указанной архитектуры. Критика и правки принимаются.

Плюсы:

  • Массив очень легко собрать и разобрать на любых имеющихся дисках. Да-да, тип ФС и заполненность дисков роли почти не играют. Понятно, что для Parity необходимо использовать самые большие из имеющихся дисков, и специфика его использования (один гигантский файл) накладывает некоторые ограничения на выбор ФС - это все описано на сайте SnapRAID. Мой личный конфиг - в SnapRAID массив объединены 5 дисков, 2x 4 Tb (один из них как раз под Parity) на Ext4, 1 x 1 Tb на Ext4, 2 x 1 Tb на NTFS (!). При этом в Aufs-пул не включен один из NTFS-дисков (там лежат файлы жены, и вообще он USB-шный). Вся эта радость довольно стабильно работает, и никто не запрещает добавлять/убирать диски без необходимости сливать куда-нибудь в сторонку всю информацию. Доступ к каждому диску индивидуально остается (например, посмотреть где физически лежит какой файл), хотя вносить изменения подобным образом не рекомендуется (например, если на одноименные папки наложить разные права, могут возникнуть конфузы, а это еще самый очевидный вариант извращения...).

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

  • для чтения 1 файла используется только 1 диск - теоретически, это приводит к некоторому уменьшению шума и энергопотребления сервера.

  • Сравнительно низкие требования к ресурсам ЦПУ и оперативной памяти.

Минусы:

  • SnapRAID заточен под медиасервера - сравнительно большие сравнительно редко меняющиеся файлы. Контрольные суммы вычисляются не в риалтайме, scrub тоже необходимо запускать. С обеими задачами справляется Cron.

  • Соответственно, восстановить случайно удаленный/измененный/побившийся файл можно только по последнему снапшоту - если данные не успели засинхронизироваться, или синхронизировалась не та версия, пиши пропало.

  • каждый файл пишется на единственный диск - ни о каком приросте скорости речи быть не может. Хотя не скажу, что для домашнего сервера это критично...

  • Сохраняются только файлы, симлинки и хардлинки - права доступа, владельцы, расширенные атрибуты не сохраняются.

Для автоматизации sync и scrub я использую модификацию довольно популярного скрипта. Изначально этот скрипт только выполнял пересчет контрольных сумм, потом автор SnapRAID-плагина адаптировал его к механизму отправки почты OMV, ну а я дописал туда Scrub массива на каждый 10-й запуск (при еженощном выполнении получаем обновление контрольных сумм каждую ночь, и проверку на ошибки каждые 10 ночей). Финальный скрипт можно почитать вот тут: http://pastebin.com/x2aK67TZ

upd от 05.01.2015: в текущей версии OMV скрипт уже умеет из коробки делать scrub, и даже настраивается из веб-морды, так что ссылка выше уже неактуальна.

 Вопрос выбора архитектуры хранения данных вообще не является однозначно решаемым, и каждый должен найти свой ответ под свои задачи. В случае Linux-медиасервера связка SnapRAID + Aufs, однозначно, заслуживает пристального внимания и права на жизнь.
В конце января я посетил курс в Учебном центре 1С №1 курс под названием "Разработка распределенных информационных систем в "1С:Предприятие 8" (почитать описание и записаться можно тут). Ведет его замечательный преподаватель и методист, Арутюнов Сергей Рафаэльевич. Курс просто архиполезен для всех, кто сталкивается с необходимостью разделять системы по функциональным областям - базами (РИБ, внешние источники), ролями, RLS-ами, разделителями...

Здесь я бы хотел отметить некоторые тезисы, которые вынес для себя после прохождения курса:

  1. В отличие от платформы 8.1, где каждая информационная база могла встречаться в списке ровно один раз, в 8.2/8.3 можно ее вписать столько раз, сколько нужно, обвешав, например, разными параметрами. Соответственно, каждая строка списка теперь несет несколько иной методический смысл - группа ИБ идентифицирует информационную систему, а конкретный элемент списка - точку входа в данную систему. Благодаря обилию средств интеграции с одной стороны и разделителей - с другой, понятия "точка входа" и "информационная база" в общем случае не совпадают.

  2. В платформе 8.3 появилась очень мощная функция, которую, кстати, почему-то проигнорировал в своем обзоре Евгений Гилев - ключ /UsePrivilegedMode , который позволит пользователю с административными правами запустить сеанс в привилегированном режиме. Это позволяет вообще отказаться от роли "ПолныеПрава", и дать администратору роль, в которой будет только галочка "Администрирование". А когда потребуется доступ к данным - он сможет культурно войти с ключом, сделать свое грязное дело и культурно выйти. Важное замечание - ключ не откроет аналог "полного" интерфейса - командный интерфейс будет отображать только то, к чему есть доступ в роли (в описанном случае - ничего), так что Use "Все действия", Luke...

  3. Небольшая заметка касательно ролей - если мы играем доступом к объектам/реквизитам, стандартные реквизиты в 8.3 надо контролировать отдельно - галочки доступа к ним не изменяются, если взвести/снять галочку доступа к самому объекту.

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

  5. Разделители создают обособленные области памяти, и разделяют, помимо собственно данных, также блокировки, нумераторы и т.д. Так что при использовании разделителей может оказаться ненужным механизм префиксов номеров. Ну и автоматически работающая сквозная автонумерация внутри каждого разделителя еще раз подчеркнет, что не стоит для аналогичных задач использовать RLS (добавлю также от себя, что RLS - это то еще средство внесения тормозов в систему...)

  6. В случае, если разделителем является справочник, значение его идентифицируется по коду.

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

  8. На любую условность в отображении надо заводить функциональные опции

  9. При использовании стандартных обменов, если загружаются изменения конфигурации, пакет надо считать 2 раза! Первый раз - загрузятся изменения конфы, потом идем в Конфигуратор, применяем их, обновляемся, возвращаемся в режим Предприятия и считываем сообщение еще раз.

  10. В лаунчере функция "Добавить существующую базу" не проверяет существование файловой базы. Этим можно пользоваться для проектирования распределенной системы.

  11. Типовой механизм создания начального образа базы не может накладывать на данные никакие отборы. Если есть необходимость выгружать не все - придется писать свой механизм.

  12. Очень мощный метод - УстановитьПривилегированныйРежим(). Работает только на сервере. Позволяет, например, реализовать следующую архитектуру взаимодействия баз: создаем общий модуль, в котором будут интерфейсные процедуры, каждая из них будет начинаться с установки привилегированного режима. Снимать его не обязательно- при завершении процедуры он сбросится автоматически. А внешний пользователь будет иметь право ТОЛЬКО на внешнее соединение :-) Таким образом мы не паримся с его ролями, и контролируем все, что он сможет увидеть, внутри интерфейсных процедур. Общий принцип проектирования: внешняя часть интерфейса должна быть стабильной!

  13. Если мы используем РИБ, то для каждого действия должна быть единственная точка ввода данных! Например, если часть бухгалтерии (какой-нибудь филиал) мы вынесли в периферийный узел, для остальных филиалов также надо создать периферийные узлы, в архивной базе первичные данные вводиться уже не должны!

  14. Платформа 8.3 имеет полновесные конфигуратор и клиент под Linux, что позволяет на линуксовом сервере программно запускать конфигуратор, например, для выгрузки/загрузки базы, методом ЗапуститьПриложение.

  15. Веб-сервисы - единственный способ взаимодействия баз 1С под Linux (ну нету там COM-соединения, это чисто виндовая технология...)

  16. Если не получается подключиться по COM к внешней базе, можно программно проверить, существует ли файл comcntr.dll нужной версии и выполнить regsvr прямо в процедуре.

  17. 1С: Предприятие имеет возможность указания пользовательских параметров запуска в командной строке по ключу /C. Если передаваемую строку параметров парсить в процедуре ПередНачаломРаботыСистемы, можно создать свое API для конкретной конфигурации. Исполняться оно будет на клиенте. Далее можно использовать эти команды, например, в bat-файлах. Получится такой вот аналог фоновых/регламентных заданий на клиенте.

  18. Когда COM-соединение перестает нам быть нужным, надо не забывать его рубить кодом типа Соединение = неопределено. Иначе есть риск, что оно подвиснет, и будет у нас висячее зомби...

  19. Какие-либо процедуры, кроме предопределенных обработчиков, методически некорректно прописывать в модулях приложения. Надо заводить отдельные модули.

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

  21. Еще одно преимущество веб-сервисов перед COM - внешнее COM-соединение съест еще 1 лицензию. А подключение к веб-сервису лицензию не ест, т.к. не активируется еще один клиент.

  22. WSСсылки работают только на сервере!

  23. COM-соединение должно служить только для взаимодействия 2 клиентов 1С под Windows. Во всех остальных случаях (например, для связи 2 серверов) рекомендуется использовать вебсервисы.

  24. Для внешнего доступа к веб-сервису рекомендуется завести отдельного пользователя, и дать ему права только на операции веб-сервиса.

  25. Методически правильно работать с Automation через неглобальный общий модуль.

  26. Хитрость при организации хранилища сопроводительных файлов - если именовать все файлы в папке GUID-ами, то ОС очень быстро ее проиндексирует за счет того, что длина имен файлов будет одинаковой. А сопоставление понятного имени GUID-у будет выполнять 1С. Получается быстро, и база не распухает.

  27. Если мы передаем в процедуру/функцию параметры, которые не планируем изменять, всегда рекомендуется их помечать словом Знач. Дело вот в чем. 1С возвращает назад не только результат функции, но и все параметры, не помеченные как Знач. Еще раз: если мы с клиента вызвали серверную процедуру - она нам вернет все параметры, которые мы ей отдали. А это мало того что трафик, так еще и возможна ситуация, когда с клиента на сервер улетела строка, а прилетела ТаблицаЗначений, которая, как мы помним, на клиенте существовать не может. Пример гипотетический, понято, что это очевидный косяк, но все же...

  28. Механизм внешних источников данных до сих пор сырой.

  29. Новый функционал 8.3 - поддержка иерархии внешних источников данных. Мы задаем поле, содержащее в себе идентификатор родителя. Эту иерархию подхватывают формы списка и СКД.

  30. не разобрал свой почерк :-) Будет еще один повод тебе, мой дорогой читатель, сходить на эти курсы :-)

Тэги: