[Перевод] Недоступный веб: как мы развели такой бардак

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

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

О том, насколько печальна ситуация, можно судить по результатам опроса, который я проводил ранее: проблемой доступности вообще не занимаются 84% ответивших. Ещё 12% пытаются делать сайты доступными, но признают, что делают не всё или не так. И только 2% уделяют должное внимание адаптации сайта для людей с ограниченными возможностями.
Честно говоря, я думал, что других странах с этим лучше, но, судя по статье, там всё так же плохо как и у нас.

Давайте делать веб доступных для всех, коллеги — это важно!

---

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

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

В теории.

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

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

Вот что я думаю о том, как мы оказались в такой ситуации и что можем сделать.

1. Мы можем научиться делать сайты, не изучая вопросы доступности, и поступаем именно так

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

Не знаете как создавать доступные продукты? Я рекомендую читать статьи на WebAIM или заценить хэштег #a11y. В будущем я добавлю и свои ресурсы. Подписывайтесь в Твиттере @MischaAndrews.

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

Это критический, системный провал. Мы создаём сайты и приложения, чтобы ими пользовались, однако считаем обеспечение доступности необязательным дополнительным функционалом.

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

Вот что мы можем сделать:

• Учителя: обучайте доступности — и выставляйте за неё оценки. Если не знаете как, пройдите курс по доступности в вебе и распространяйте полученные знания. Даже если вам недостаёт уверенности называть себя экспертом по вопросам доступности, изучите основы, чтобы уменьшить вероятность того, что вы станете давать вредные советы.
  

  NO. DO NOT DO THIS. ALT LABELS HAVE A PURPOSE. They are there to make things more accessible, not be clever. http://pic.twitter.com/E03MKBPKvg

  — Eb (@erabrand) 8 октября 2015 г.

  
  НЕ НАДО ТАК. ALT-АТРИБУТЫ ИМЕЮТ ПРЕДНАЗНАЧЕНИЕ. Они нужны, чтобы повысить доступность, а не для остроумных трюков.
• Создатели контента: не рассчитывайте, что ваша платформа всё сделает за вас. Не сделает. Системы вроде WordPress и Drupal, позволяющие создавать доступные сайты, не гарантируют, что ваши шаблоны или контент будут доступными и автоматические тесты не могут отследить всё. Если не знаете с чего начать, я рекомендую посмотреть этот трёхминутный видеообзор доступности, прочитать эту статью о доступности с точки зрения создателя контента и походить по ресурсам на WebAIM.
• Дизайнеры и разработчики: если вам не хватает знаний — учитесь. Если вы уже знаете что-то полезное, поделитесь своими наработками и подробно расскажите, как вы тестировали доступность и устраняли проблемы. Говорите о доступности не только в рамках специализированных статей и выступлений. Выбирайте платформы и библиотеки, позволяющие создавать и тестировать доступные продукты, но помните, что они не гарантируют доступность — вы всегда должны тестировать и улучшать ваши продукты.
• Менеджеры: подавайте пример. Изучайте вопросы доступности, закладывайте на неё время, обсуждайте её с командой, включите её в описание вакансии и KPI. Наймите консультанта для аудита ваших проектов, проведения обучения и разработки планов создания более доступных продуктов и среды. Принимайте на работу людей с ограниченными возможностями, и, если вы считаете, что это невозможно, выясните почему и устраните эти проблемы в вашей компании.
  

2. Мы не несём ответственности за продукты, недоступные для людей с ограниченными возможностями

Что произойдёт, если продукт недоступен? В большинстве случаев — почти ничего или вообще ничего.

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

И несмотря на то, что обеспечивать доступность обязывает закон (в США, Канаде, Австралии, Великобритании, Новой Зеландии и растущем числе стран Европы), судебные иски редки.

Такое стабильное отсутствие последствий позволяет игнорировать обеспечение доступности в краткосрочной перспективе.

Бывают и исключения. Возможно, вы работаете в классном месте, в котором уделяют должное внимание доступности или ваши пользователи не дают вам про неё забыть.

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

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

Повысьте приоритет доступности — и мы устраним проблему безответственности.

A single person cannot achieve web accessibility for an entire organization. #a11y won't happen unless content is created accessible #csun10

— Denis Boudreau (@dboudreau) 27 марта 2010 г.

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

3. Предположения вводят нас в заблуждение

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

Если сложить все эти предрассудки, можно задаться вопросом: а где тогда работают люди с ограниченными возможностями? Если не в больших компаниях и не в маленьких и не в вашей компании, то где? Если вы думаете, что ответ «нигде», подумайте над тем, почему может быть трудно найти работу, когда люди полагают, что вас не существует.

Но эти предположения неверны. В среднем каждый пятый человек имеет инвалидность и они не всегда бросаются в глаза. У вас могут быть коллеги со слабым зрением (возможно, читать мелкий текст таким людям трудно и ваш интернет должен поддерживать разные размеры шрифта); или с нарушениями опорно-двигательного аппарата (возможно, им сложно пользоваться мышью, поэтому формы должны быть доступны для работы с клавиатуры); или они могут плохо слышать (поэтому вебинары и видео должны сопровождаться субтитрами); или иметь когнитивные нарушения (возможно, они входят в 15-20 процентов людей, испытывающих трудности при чтении, поэтому письменный контент нужно упрощать).

Если вы не считаете, что должны угождать людям с ограниченными возможностями, вы участвуете в дискриминации. Вы создаёте окружение, в котором инвалиды не могут работать.

Когда такое отношение преобладает среди тех, кто создаёт интернет, дискриминация (намеренная или нет) становится встроенной в его структуру.

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

@starbucks Hi, I'd love to be able to use your new mobile order feature, but it is inaccessible to blind iOS users.

— Lindsay Yazzolino (@GrammarGlamor) 30 сентября 2015 г.

Привет, Старбакс. Я бы рада пользоваться вашей новой фичей заказа с мобильного, но она недоступна для слепых пользователей iOS.

@digitalocean I really want to use your service, but sadly your site is still completely inaccessible to people using keyboard navigation

— David Sexton (@daiverd) 13 июля 2016 г.

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

@Sleepio Hi! Is there any way to include subtitles/closed captions? I'm hard of hearing and couldn't understand the Prof :)

— R2-D2 (@NotKdamoney) 18 марта 2015 г.

Привет, Слипио! Можете добавить субтитры? Я плохо слышу и не понимаю, что говорит Профессор.

4. Закон не говорит, что конкретно мы должны делать

По всему миру законы об обеспечении доступности размыты и двусмысленны. В Австралии это Disability Discrimination Act (Закон о дискриминации в отношении инвалидов) 1992, но он не уточняет, что именно вы должны делать с технической точки зрения.

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

Web Content Accessibility Guidelines (WCAG) (Руководство по доступности веб-контента) 2.0 всё чаще используется в качестве международного эталона, но эталон — это не всегда закон (зависит от вашей страны и сферы деятельности).

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

Эта неопределённость усложняет для менеджеров задачу разработки политик доступности, но это не значит, что нужно опустить руки. Самое худшее, что вы можете делать с социальной и юридической точки зрения — ничего. Проверять только соблюдение стандартам WCAG тоже не лучший вариант (и это может не защитить вас от судебных исков), но с этого можно начать.

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

5. Новые тренды выталкивают технологии на неизведанную территорию

Когда клиенты, топ-менеджеры и разработчики (и вообще кто угодно) говорят о цифровых инновациях, всегда ли они реально их хотят? Или «инновационный» используется вместо «модный»?

У большинства веб-дизайнеров был клиент (или несколько), недовольный сайтом, который не «выстрелил». Эти случаи повлияли на нас. Сайт не ценится, если он не «секси».

Хотя эстетика и хороший дизайн и имеют значение, мода опасна тем, что резко меняется и толкает цифровые продукты на неизведанную, непроверенную территорию.

Доступности и стиль — не взаимоисключающие вещи, но следование последним веяниям дизайна (или даже внезапным идеям) без должного осмысления и проверки приведёт к катастрофическим проблемам доступности, не говоря уже о потенциальных проблемах юзабилити.

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

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

Дизайнеры и разработчики: тренируйтесь говорить «нет» непроработанным идеям или выторговывайте больше времени на тестирование и устранение проблем. Твёрдо доносите до клиентов, что доступность — обязательный компонент, на реализацию которого потребуется время. Если придётся, помогите им понять, что продукт, который выглядит готовым может не быть готовым. Пока продукт не протестирован на различных платформах, браузерах и специальных устройствах, он не готов к запуску.

Как нам разгрести этот бардак?

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

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

Мы сами создали этот бардак, соблазнившись быстрыми темпами развития технологий и моды. Так давайте прекратим соблазняться! Давайте уделять время тщательному тестированию и доведению до блеска наших цифровых продуктов. Давайте делать веб доступным для всех, каким он и должен был быть всё это время.

---

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

Пропустила ли я что-то важное в этой статье? Пожалуйста, выскажите своё мнение. Если вы хотите узнавать о других моих статьях, возможно, вы захотите подписаться на меня в Твиттере: @MischaAndrews.

Огромное спасибо получает Adam Van Winden за КДПВ и @erabrand за обратную связь по черновику этой статьи. Любые ошибки или бестактности мои, но она помогала и помогает мне понять, где я бываю пристрастна.

Let's block ads! (Why?)

Еще раз о пользе резервных копий или история о моей неудаче

[Из песочницы] Договорённости о коммуникациях

Поделиться принципами, используемыми в нашей компании, я решил после прочтения статьи, которая мне показалась весьма разумной — «Письмо в студию»: 5 правил общения удалённых разработчиков от CSSSR.

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

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

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

Электронная почта

1. Почту необходимо проверять и реагировать на неё минимум 3 раза в день: утром (по приходе на работу), в дневное время (перед обедом), вечером (за час до окончания работы). Более частая реакция на сообщения по электронной почте приветствуется и одобряется.

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

3. Получив письмо по электронной почте, в случае, если отправитель запросил подтверждение прочтения, его необходимо отправить. Как правило, этот инструмент используют при особой значимости содержимого письма для отправителя. Однако, не стоит девальвировать понятие «Подтверждения прочтения», в настройках по умолчанию не следует автоматически запрашивать подтверждения для всех ваших исходящих писем.

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

5. Новое поручение не отменяет другие работы, если об этом не указано явно.

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

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

8. Если ваш адрес указан в поле «Копия:», то отправитель хочет, чтобы вы были в курсе обсуждения. Если у вас есть предложения/дополнения/вопросы по существу переписки, то о них необходимо отписывать всем участникам переписки, выбрав кнопку «Ответить всем». Ваши предложения могут быть созвучны с мнением другими получателей письма и этим вы сохраните время остальным.

9. Если Вы получаете письмо и Вашего адреса нет в получателях, то отправитель решил поставить Ваш адрес в поле «Скрытая копия». Отправитель хочет, чтобы Вы были в курсе, но не желает, чтобы об этом знал тот, кому непосредственно адресовано письмо. В таком случае, вести переписку предпочтительнее только с отправителем, а не писать в режиме «Ответить всем». Альтернативой может быть пересылка письма из отправленных в адрес «тайного» читателя.

10. Поле «Тема:» не должно оставаться пустым. В нём кратко указывается суть переписки. В дальнейшем это помогает осуществлять поиск и сортировку сообщений.

11. Не меняйте поле «Тема:» при ответах и пересылке. Это делает невозможным автоматическую группировку писем в M$ Outlook в виде бесед. Обратите внимание, что некоторые почтовые клиенты на мобильных устройствах при ответах и пересылке добавляют в поле «Тема:» символы: «>>», «Re:», «Fw:», «На:», «От:» и некоторые другие. При настройке программы убедитесь, что отображения бесед не «рвутся» на ПК в M$ Outlook при ваших ответах и пересылке.

12. Если отправитель не получил от вас ответного письма в течение трёх дней (или в тексте не указан другой срок), то это считается вашим согласием с содержанием письма, приложениями к нему и ссылками на другие ресурсы и информацией.

Назначение встреч, собраний, совещаний

1. Использование календаря M$ Outlook обязательное средство для координации совместной деятельности сотрудников в компании.

2. При получении приглашения на встречу необходимо кроме нажатия кнопки «Принять» направить уведомление о получении (если оно не настроено на автоматическую отправку в Вашем клиенте M$ Outlook).

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

4. Все встречи с жёсткими сроками должны быть отражены в Вашем личном календаре M$ Outlook. Это позволит другим сотрудникам компании при назначении мероприятий принимать во внимание вашу занятость, более эффективно пользоваться Помощником по планированию.

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

6. При назначении встречи обязательно устанавливайте срок напоминания о начале встречи. При получении встречи и подтверждении участия обязательно проверяйте этот срок и при необходимости корректируйте его в своём календаре с учётом необходимой транспортной доступности до места проведения мероприятия. Как правило, в настройках по умолчанию установлено 30 минут, но это время может быть изменено в параметрах Вашего M$ Outlook.

7. При корректировке сроков или отмены периодических встреч не удаляйте их! Предпочтительнее менять конечный срок «старой» встречи и формировать новую повторяющуюся встречу на перспективу. Это позволит оставить след в истории по прошедшим мероприятиям в Вашем календаре и календарях Ваших коллег, тем более, что в приглашениях могут быть дополнительные материалы к встречам, протоколы и т.д.

8. При назначении дополнительной встречи по аналогичному вопросу, не следует переносить встречу, предпочтительнее создавать копию, хотя это и более трудоёмко. Этим вы сохраните «память» как в своём календаре, так и у других участников совещаний. Зачастую, при копировании (дублировании) встречи обнуляется время напоминания у получателей. Обратите на это внимание перед отправкой приглашения! Впрочем, если следовать правилу 6, получатели это исправят.

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

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

Допускаю, что наши соображения покажутся интересными, помогут Вам лично или Вашей компании повысить эффективность IT-коммуникаций или у Вас будут предложения по дополнению/изменению этой статьи.

Диалог участников приветствуется!

Let's block ads! (Why?)

Создание и управление FQDN именем сервера 3CX

[Из песочницы] Автоматизация поддержания соответствия между названиями слоев в редакторе и коде с помощью CodeDom

Android до Госдумы доведет или Мобилизация гражданской сознательности

[Перевод] Книга об интенсивной обработке данных

Здравствуйте, дорогие читатели. Мы редко пишем о книжных «долгостроях», то есть, о работах, которые никак не выйдут на Западе. Но сегодня хотим познакомить вас с постом из блога Мартина Клеппмана, который уже не первый год трудится над фундаментальной книгой "Designing Data-Intensive Applications"

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

В конце 2012 года я написал у себя в блоге пост “Rethinking caching in web apps”. В нем почти 4,000 слов, что гораздо длиннее, чем, согласно народной мудрости должен быть хороший пост. Тем не менее, у меня осталось впечатление, что в нем я лишь слегка копнул те проблемы, о которых нужно рассказать.

Поэтому я задумался – а не написать ли произведение подлиннее, книгу, например. Мне нравится писать, поскольку такой труд стимулирует автора заниматься глубокими исследованиями, продумывать проблему, а затем пытаться все это логично объяснить. Таким образом я прорабатываю проблему гораздо лучше, чем если просто читаю о ней. Или, если выразиться афористичнее:

Писательство помогает понять, насколько неуклюжи твои мысли. – Дик Гиндон

Какие книги уже есть

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

1. Большинство айтишных книг – это прикладные руководства по конкретной технологии. В них предполагается, что вам сказано использовать базу данных X или язык программирования Y, поэтому там и рассказывается, как это делать. Эти книги хороши, но от них мало пользу в ситуациях, когда вы пытаетесь выбрать, какой инструмент — X или Y — вам действительно нужен. Такие книги обычно сосредоточены на достоинствах конкретной технологии и замалчивают ее недостатки.
2. В блогах часто встречаются сравнения нескольких технологий, но в таких публикациях затрагиваются преимущественно поверхностные аспекты (контрольные точки, характеризующие производительность, API, лицензия), а фундаментальное устройство технологии полностью игнорируется. Такие посты можно сравнить с карточками по базам данных из игры Top Trumps, каких-либо глубоких представлений по ним не составишь.
3. Напротив, в учебниках рассматриваются фундаментальные принципы и компромиссы, характерные для различных технологий, но при этом такие книги утрачивают всякую связь с реальностью. Как правило, авторы таких книг – академики с обширным исследовательским опытом в своей теме, не обладающие при этом практическим опытом работы с реальными софтверными системами. Зачастую они излагают технически верные вещи, но эти сведения могут быть бесполезны или просто запутают вас, как только вы возьметесь за создание реальной системы.

Я хотел написать книгу, которая сочетала бы достоинства всех трех категорий. Такую книгу, которая поведает историю больших идей по созданию систем обработки данных, опишет фундаментальные принципы, не меняющиеся при обновлении версий ПО. Но эта книга также не потеряет связи с реальностью, объяснит, что работает на практике, что — нет, и почему. Эта книга исследует инструменты и продукты, уже используемые в реальной практике, сравнит применяемые в них фундаментальные подходы и поможет вам понять, какая технология оптимально подходит для решения конкретной задачи.

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

Я обсуждал эти идеи с разными людьми, в том числе, с сотрудниками O’Reilly, и стало ясно, что не мне одному нужна такая книга. Так зародилась идея книги Designing Data-Intensive Applications. И вы ее легко узнаете на полке – ведь на обложке будет такой классный индостанский вепрь.

Книга «Высоконагруженные приложения. Эффективная обработка больших данных» (извините за многословное заглавие – можете называть ее просто «книга с вепрем») пока готовится к выходу, но на сайте уже выложен early release.

Для кого эта книга?

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

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

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

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

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

Let's block ads! (Why?)

Группировка моделей телефонов Android по контейнерам Docker

Немного предыстории

Мобильное приложение Badoo существует для основных «нативных» платформ (Android, iOS и Windows Phone) и для мобильного веба. Несмотря на то, что в разработке мы не используем никаких кроссплатформенных фрэймворков, подавляющая часть бизнес-логики в приложениях схожа, и чтобы не дублировать функциональные тесты для всех платформ, мы пишем кроссплатформенные тесты с помощью Cucumber, Calabash и Appium. Это позволяет нам выносить в общую часть и переиспользовать в тестах для всех платформ код, отвечающий за проверку этой самой бизнес-логики. Различной же остается лишь реализация взаимодействия с приложением (более подробно мы рассказывали об этом здесь).

Когда кроссплатформенная автоматизация только начиналась (на iOS и Android), было принято решение использовать в качестве серверов Mac Mini. Это позволило сделать каждую из 8 билд-машин универсальной: на ней можно было собирать и запускать функциональные и юнит-тесты как для приложений на iOS, так и на Android. Такое решение устраивало нас практически всем до тех пор, пока количество функциональных тестов не перевалило за пять сотен для каждой платформы, а прогоны не стали требовать все больше времени. Для того чтобы удержать время прогона в разумных границах, мы постоянно работаем над оптимизацией тестов, а также добавляем новые Android-устройства (для iOS мы добавляем симуляторы по-другому). Со временем у нас появились Mac Mini с более чем 8 смартфонами. Важно отметить, что мы подключаем устройства одной модели к одному серверу, чтобы прогоны тестов были консистентны на одном агенте.

По существу

У себя в Badoo мы решили перенести тестирование устройств Android на Linux-хосты — необходимое оборудование стоит дешевле, а кроме того, компьютеры Mac Mini, используемые для сборки, часто прерывают USB-подключения к устройствам Android, и те внезапно исчезают во время тестирования. Для управления серверами Linux мы в основном используем контейнеры Docker, поэтому решили попробовать создать контейнер для тестирования реальных устройств Android и клонировать его для каждой модели или группы телефонов, чтобы интегрировать контейнер в существующую конфигурацию серверов.

Небольшое замечание: одно из преимуществ Linux по сравнению с Mac заключается в том, что Linux — открытая система. Она показала нам, что причина таинственного исчезновения телефонов при тестировании кроется в разрывах соединений, длящихся доли секунды. Мы исправили тесты, добавив в них повторную попытку подключения, что в значительной степени решило проблему.

По существу: Docker

Docker — это система, которая содержит в себе методы сборки и распространения конфигураций ПО с инфраструктурой операционной системы, изолирующей каждый программный контейнер от остальных компонентов компьютера. Контейнер имеет собственную файловую систему, адресное пространство и пр. Контейнеры исполняются в одном экземпляре операционной системы, но поскольку система сильнее изолирует процессы, это все работает как набор виртуальных машин.

Поясняющие диаграммы, опубликованные на сайте Docker:

На хост-компьютере используется система виртуализации, в которой запущены гостевые экземпляры ОС:

Контейнеры Docker выполняются на одной ОС:

По существу: группировка adb/adbd

Каждый контейнер должен был управлять собственным набором телефонов. Чтобы реализовать это наиболее естественным способом, нужно сопоставить группы разъемов USB разным контейнерам. Устройства, подключенные к разъемам на передней панели компьютера, появляются в каталоге /dev/bus/usb/001, который доступен контейнеру 1; устройства, подключенные к разъемам на задней панели, появляются в каталоге /dev/bus/usb/002, который доступен контейнеру 2. Чтобы увеличить количество подключаемых устройств, была заказана дополнительная плата расширения.
Все это выглядит неплохо, однако команда adb взаимодействует с телефоном через демон, который использует порт по умолчанию 5037 и работает на уровне всего компьютера. Это означает, что первый контейнер, в котором выполняется команда adb, запускает и демон adb (adbd) — в результате остальные контейнеры, подключаемые к этому демону, видят телефоны первого контейнера. Эту проблему можно было бы решить с помощью сетевых возможностей Docker (каждый контейнер получает собственный IP-адрес, а, следовательно, и собственный набор портов), однако мы воспользовались другим механизмом. Для каждого контейнера было присвоено отдельное значение переменной окружения ANDROID_ADB_SERVER_PORT. Мы выделили порт каждому контейнеру, чтобы он запускал собственный демон adb, который видит только телефоны этого контейнера.

В процессе разработки мы поняли, что нельзя выполнять команду adb на уровне хоста, не задав переменную ANDROID_ADB_SERVER_PORT, поскольку демон adbd уровня хоста, способный видеть все порты USB, «крадет» телефоны у контейнеров Docker (телефоны могут взаимодействовать только с одним демоном adbd в каждый момент времени).
Если бы мы использовали только эмуляторы, можно было бы обойтись отдельными процессами adbd, но поскольку мы работаем с реальными устройствами…

По существу: обновление контейнеров при горячем подключении устройств USB

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

Отслеживать добавление и удаление телефонов на хост-компьютере можно по файлам в каталоге /dev/bus/usb, в котором система создает и удаляет файлы, соответствующие телефонам:

while sleep 3; do
  find /dev/bus/usb > /tmp/a
  diff /tmp/a /tmp/b
  mv /tmp/a /tmp/b
 done

К сожалению, в контейнерах Docker телефоны не только не создаются и не удаляются подобным образом; если настроить создание и удаление узлов, то они на самом деле не взаимодействуют с телефонами!

Мы решили этот вопрос «в лоб»: поместили контейнеры в режим --privileged и открыли им доступ ко всему каталогу /dev/bus/usb.

Теперь понадобился другой механизм распределения телефонов по интерфейсным шинам. Я скачал исходный код Android и внес небольшие изменения в файл platform/system/core/adb/usb_linux.cpp

    std::string bus_name = base + "/" + de->d_name;

+    const char* filter = getenv("ADB_DEV_BUS_USB");
+    if (filter && *filter && strcmp(filter, bus_name.c_str())) continue;

    std::unique_ptr<DIR, int(*)(DIR*)> dev_dir(opendir(bus_name.c_str()), closedir);
    if (!dev_dir) continue;

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

Отступление: хотя исправление было совсем несложным, сборку adb пришлось выполнять методом проб и ошибок, поскольку большинство людей включает в сборку все подряд. Мое окончательное решение выглядело так (в чувствительной к регистру файловой системе — я работаю на Mac):

cd src/android-src
source build/envsetup.sh
lunch 6
vi system/core/adb/usb_linux.cpp
JAVA_NOT_REQUIRED=true make adb
out/host/linux-x86/bin/adb

По существу: мультиплексирование портов USB

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

Поскольку я уже влез в код adb, то решил просто добавить еще одну переменную окружения: переменная ADB_VID_PID_FILTER получает список пар идентификаторов vid:pid, и adb игнорирует любые несоответствующие устройства.

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

diff --git a/adb/usb_linux.cpp b/adb/usb_linux.cpp
index 500898a..92e15ca 100644
--- a/adb/usb_linux.cpp
+++ b/adb/usb_linux.cpp
@@ -115,6 +115,71 @@ static inline bool contains_non_digit(const char* name) {
     return false;
 }

+static int iterate_numbers(const char* list, int* rejects) {
+  const char* p = list;
+  char* end;
+  int count = 0;
+  while(true) {
+    long value = strtol(p, &end, 16);
+//printf("%d, %p ... %p (%c) = %ld (...%s)\n", count, p, end, *end, value, p);
+    if (p == end) return count;
+    p = end + 1;
+    count++;
+    if (rejects) rejects[count] = value;
+    if (!*end || !*p) return count;
+  }
+}
+
+int* compute_reject_filter() {
+    char* filter = getenv("ADB_VID_PID_FILTER");
+    if (!filter || !*filter) {
+        filter = getenv("HOME");
+        if (filter) {
+            const char* suffix = "/.android/vidpid.filter";
+            filter = (char*) malloc(strlen(filter) + strlen(suffix) + 1);
+            *filter = 0;
+            strcat(filter, getenv("HOME"));
+            strcat(filter, suffix);
+        }
+    }
+    if (!filter || !*filter) {
+        return (int*) calloc(sizeof(int), 1);
+    }
+    if (*filter == '.' || *filter == '/') {
+        FILE *f = fopen(filter, "r");
+        if (!f) {
+            if (getenv("ADB_VID_PID_FILTER")) {
+                // Only report failure for non-default value
+                printf("Unable to open file '%s'\n", filter);
+            }
+            return (int*) calloc(sizeof(int), 1);
+        }
+        fseek(f, 0, SEEK_END);
+        long fsize = ftell(f);
+        fseek(f, 0, SEEK_SET);  //same as rewind(f);
+        filter = (char*) malloc(fsize + 1);  // Yes, it's a leak.
+        fsize = fread(filter, 1, fsize, f);
+        fclose(f);
+        filter[fsize] = 0;
+    }
+    int count = iterate_numbers(filter, 0);
+    if (count % 2) printf("WARNING: ADB_VID_PID_FILTER contained %d items\n", count);
+    int* rejects = (int*)malloc((count + 1) * sizeof(int));
+    *rejects = count;
+    iterate_numbers(filter, rejects);
+    return rejects;
+}
+
+static int* rejects = 0;
+static bool reject_this_device(int vid, int pid) {
+    if (!*rejects) return false;
+    for ( int len = *rejects; len > 0; len -= 2 ) {
+//printf("%4x:%4x vs %4x:%4x\n", vid, pid, rejects[len - 1], rejects[len]);
+        if ( vid == rejects[len - 1] && pid == rejects[len] ) return false;
+    }
+    return true;
+}
+
 static void find_usb_device(const std::string& base,
         void (*register_device_callback)
                 (const char*, const char*, unsigned char, unsigned char, int, int, unsigned))
@@ -127,6 +192,8 @@ static void find_usb_device(const std::string& base,
         if (contains_non_digit(de->d_name)) continue;

         std::string bus_name = base + "/" + de->d_name;
+        const char* filter = getenv("ADB_DEV_BUS_USB");
+        if (filter && *filter && strcmp(filter, bus_name.c_str())) continue;

         std::unique_ptr<DIR, int(*)(DIR*)> dev_dir(opendir(bus_name.c_str()), closedir);
         if (!dev_dir) continue;
@@ -176,6 +243,12 @@ static void find_usb_device(const std::string& base,
             pid = device->idProduct;
             DBGX("[ %s is V:%04x P:%04x ]\n", dev_name.c_str(), vid, pid);

+            if(reject_this_device(vid, pid)) {
+                D("usb_config_vid_pid_reject");
+                unix_close(fd);
+                continue;
+            }
+
                 // should have config descriptor next
             config = (struct usb_config_descriptor *)bufptr;
             bufptr += USB_DT_CONFIG_SIZE;
@@ -574,6 +647,7 @@ static void register_device(const char* dev_name, const char* dev_path,
 static void device_poll_thread(void*) {
     adb_thread_setname("device poll");
     D("Created device thread");
+    rejects = compute_reject_filter();
     while (true) {
         // TODO: Use inotify.
         find_usb_device("/dev/bus/usb", register_device);

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

Tim Baverstock,
QA automation engineer

Let's block ads! (Why?)

[СПб, Анонс] Встреча CodeFreeze с разработчиком PHP Дмитрием Стоговым про внутреннее устройство виртуальной машины PHP

В среду, 7 сентября, в 20:00 в питерском офисе компании JetBrains состоится встреча с Дмитрием Стоговым, разработчиком компилятора PHP, сотрудником Zend Technologies. Тема встречи — внутреннее устройство виртуальной машины PHP и, в частности, последние изменения в PHP 7.

Участие, как всегда, бесплатное. Регистрация — по ссылке. Количество мест ограничено.

О докладе

Виртуальная машина PHP имеет различные внутренние изменения, однако самые интересные — поднимающие производительность от версии к версии. Именно о них расскажет Дмитрий, уделив внимание последним изменениям, реализованным в PHP 7 и принесшим двукратное улучшение, и новым идеям, реализуемым в ещё не выпущенных версиях.

Доклад будет интересен всем интересующимся разработкой интерпретируемых языков программирования.

О докладчике

Дмитрий Стогов — Principal Engineer в Zend Technologies. Один из лидеров разработки Open Source PHP, ведущий раработчиков PHP, лидер проекта PHPNG заложившего основу для PHP 7, автор нескольких PHP расширений.

http://ift.tt/2clin17

Бонус — PhpStorm Tips & Tricks

После доклада Дмитрия выступит Анна Лебедева, PhpStorm Product Marketing Manager в JetBrains. Анна расскажет о PhpStorm и даст несколько советов по использованию, поделится знаниями о «неочевидных» фичах в IDE, которые делают процесс разработки более лёгким и эффективным, и затронет тему поддержки языка PHP 7 в PhpStorm.​

---

Участие бесплатное, количество мест ограничено. Регистрация — ТУТ.

Онлайн-трансляции не будет — будет запись. Видео будет выложено на YouTube-канале CodeFreeze через неделю после встречи.

Let's block ads! (Why?)

Упрощенная процедура арбитражного производства: «подводные камни» для IT и не только

[Перевод] GitLab Container Registry

В мае этого года вышел релиз ГитЛаба 8.8. Частью этого релиза был запуск встроенного Docker Container Registry. Ниже перевод майской статьи, посвященной этому.

Недавно нами был выпущен GitLab версии 8.8, в которой поддержка CI стала еще лучше. Теперь в GitLab можно строить конвейеры (pipelines) для визуализации сборок, тестов, развертывания и любых других этапов жизненного цикла вашего ПО. Сегодня мы представляем вам следующий этап: GitLab Container Registry .

GitLab Container Registry — это безопасный приватный реестр для образов (images) Docker, разработанный с помощью ПО с открытым кодом. GitLab Container Registry полностью интегрирован в GitLab.

Ключевыми особенностями GitLab являются непрерывность процесса разработки и взаимная интеграция различных элементов; эти принципы сохраняются и при работе с нашим реестром. Теперь при помощи GitLab Container Registry вы можете использовать ваши Docker-образы для GitLab CI, создавать специальные образы для отдельных тегов и веток, а также многое другое.

Стоит отметить, что GitLab Container Registry является первым реестром Docker, полностью интегрированным в систему управления Git-репозиториями. Кроме того, GitLab Container Registry не требует отдельной установки, так как является частью GitLab 8.8; c его помощью можно легко скачивать и загружать образы на GitLab CI. И еще он бесплатный.

Для того, чтобы узнать, как включить использование GitLab Container Registry, обратитесь к документации для администратора.

Основы Docker

Основной единицей работы с Docker является образ, в котором содержится все необходимое для запуска и работы приложения. Зачастую образы создаются автоматически, как часть процесса непрерывной интеграции — то есть они обновляются при каждом изменении кода. В случаях, когда образы создаются для совместного использования, их нужно где-то хранить. Как раз для этого и применяется реестр образов.

Реестр позволяет хранить образы для дальнейшего переиспользования и категоризовать их, используя теги. Хорошей идеей является создание реестра для хранения приватных образов, используемых только внутри компании, или, к примеру, образов для запуска и прогона тестов. При использовании GitLab Container Registry не нужно настраивать и поддерживать дополнительные сервисы или использовать публичные реестры.

Тесная интеграция с GitLab

GitLab Container Registry полностью интегрирован в GitLab, что позволяет разработчикам с легкостью создавать, тестировать и запускать образы Docker, используя GitLab CI или другие инструменты, совместимые с Docker.

• Для аутентификации и разграничения доступа используются пользователи и группы из вашего инстанса GitLab.
• Нет необходимости создавать дополнительные репозитории для работы с реестром – реестр является частью вашего проекта в GitLab.
• В проекте появляется новая вкладка Container Registry, в которой перечислены все образы, относящиеся к данному проекту.
• У каждого проекта может быть собственный реестр образов (опционально, может быть отключено для любого отдельного проекта).
• Можно легко скачивать и загружать образы на GitLab CI.
• Не нужно скачивать и устанавливать дополнительный софт.

Упростите ваш рабочий процесс

Работа с GitLab Container Registry проста и безопасна. Вот несколько примеров того, как использование GitLab Container Registry может упростить процесс разработки и развертывания ПО:

• Проводите сборку образов Docker с помощью GitLab CI с последующим их хранением в GitLab Container Registry.
• Привязывайте образы к веткам, тегам исходного кода или используйте любой другой способ, подходящий для вашего процесса разработки. Созданные образы можно быстро и легко сохранить на GitLab.
• Используйте собственные образы сборок, хранящиеся в вашем реестре, для тестирования приложений.
• Пусть остальные участники команды также участвуют в разработке образов. Это не потребует от них дополнительных усилий, так как используется тот же рабочий процесс, к которому они привыкли. GitLab CI позволяет проводить автоматическую сборку образов, унаследованных от ваших, что в свою очередь позволяет с легкостью добавлять фиксы и новые фичи в базовый образ, используемый вашей командой.
• Настройте CaaS на использование образов напрямую из GitLab Container Registry, получив таким образом процесс непрерывного развертывания кода. Это позволит проводить автоматическое развертывание приложений в облако (Docker Cloud, Docker Swarm, Kubernetes и т. п.) каждый раз, когда вы собираете или тестируете образ.

С чего начать?

В первую очередь, попросите вашего системного администратора подключить GitLab Container Registry так, как описано в документации для администратора..

После этого вы сможете включить опцию Container Registry в вашем проекте.

Для того, чтобы начать использовать реестр, сперва нужно залогиниться:

docker login registry.example.com

После этого можно просто собирать и пушить образы на GitLab:

docker build -t http://ift.tt/1Tz8Hg6 .
docker push http://ift.tt/1Tz8Hg6

Также GitLab предоставляет простой интерфейс для управления контейнерами. Нажмите на Container Registry в вашем проекте — в открывшемся окне вы увидите все теги в вашем репозитории и легко сможете удалить любой из них.

Для получения более подробной информации обратитесь к GitLab Container Registry user guide.

Используйте совместно с GitLab CI

Встроенный интерфейс для управления CI GitLab’а можно использовать для сборки, пуша и развертывания созданных образов.

Внимание: для этого требуется GitLab Runner 1.2.

Внимание: Для того, чтобы использовать Docker в образах Docker, необходимо установить флаг privileged в конфигурации Runner’а. Пока что это невозможно сделать в общих (shared) Runner’ах на GitLab.com. Мы планируем добавить этот флаг в ближайшее время, а пока что стоит использовать собственные Runner’ы.

Вот пример конфигурационного файла GitLab CI (.gitlab-ci.yml), который собирает образ, запускает тесты и, в случае их успешного прохождения, присваивает билду тег и загружает билд в реестр образов:

build_image:
  image: docker:git
  services:
  - docker:dind
  script:
    - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.example.com
    - docker build -t http://ift.tt/1s5b2Gy .
    - docker run http://ift.tt/1s5b2Gy /script/to/run/tests
    - docker push http://ift.tt/1Tz8Lwo
  only:
    - master

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

image: docker:git
services:
- docker:dind

stages:
- build
- test
- release
- deploy

variables:
  CONTAINER_TEST_IMAGE: http://ift.tt/1s5avV7
  CONTAINER_RELEASE_IMAGE: http://ift.tt/1Tz8Lwo

before_script:
  - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.example.com

build:
  stage: build
  script:
    - docker build -t $CONTAINER_TEST_IMAGE .
    - docker push $CONTAINER_TEST_IMAGE

test1:
  stage: test
  script:
    - docker run $CONTAINER_TEST_IMAGE /script/to/run/tests

test2:
  stage: test
  script:
    - docker run $CONTAINER_TEST_IMAGE /script/to/run/another/test

release-image:
  stage: release
  script:
    - docker pull $CONTAINER_TEST_IMAGE
    - docker tag $CONTAINER_TEST_IMAGE $CONTAINER_RELEASE_IMAGE
    - docker push $CONTAINER_RELEASE_IMAGE
  only:
    - master

deploy:
  stage: deploy
  script:
    - ./deploy.sh
  only:
    - master

Подводя итоги

GitLab Container Registry — последнее на данный момент дополнение к встроенному набору инструментов для цикла разработки ПО GitLab. Это дополнение доступно начиная с версии GitLab 8.8. С использованием этой функциональности проводить тестирование и развертывание образов Docker стало гораздо проще. GitLab Container Registry идет в комплекте с GitLab CE и GitLab EE без какой-либо доплаты и устанавливается поверх той же инфраструктуры, что настроена у вас для GitLab.

Container Registry доступен на GitLab.com, он абсолютно бесплатен, и вы можете начать пользоваться им прямо сейчас!

Важно: Для того, чтобы использовать Docker в образах Docker необходимо установить флаг privileged в настройках Runner’а. Пока что это невозможно сделать в общих Runner’ах на GitLab.com. Мы планируем добавить этот флаг в ближайшее время. Все уже ок.

P.S. Будет здорово, если поделитесь опытом использования в комментариях.

Let's block ads! (Why?)

Как технологические компании влияют на медиа-бизнес

Как компания Edmunds ускорила свой сайт на 80% и получила на 20% больше просмотров

[Перевод] OK Google, что насчет хороших интерфейсов?

О процессе создания сервера – от идеи к деталям

Здравствуйте! Меня зовут Алексей, я руковожу созданием оборудования в компании YADRO – координирую работу всех, кто так или иначе вовлечен в процесс разработки.

В конце прошлой статьи Максим maxf75 немного коснулся особенностей расположения разъёмов памяти. Сегодня я расскажу в целом про то, как мы пришли к тому варианту архитектуры и компоновки, над которыми работаем сейчас.

Вид проектируемого сервера сзади со снятой задней решёткой.

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

Надо отметить, что решения, которые доступны на рынке сейчас и которые позволяют обеспечить действительно большой объём памяти, обладают одним существенным недостатком – стоимость сервера в разы превышает стоимость установленной в нём памяти. Именно поэтому мы приняли решение создать сервер, который сломает эту традицию и позволит предоставить в одной машине до 8 ТБ памяти при сохранении низкой общей (насколько это возможно вообще учитывая стоимость собственно 8 ТБ DDR4) стоимости решения.

Вместе с целью максимизации объёма памяти сразу возникло стремление обеспечить высокую плотность – иногда это оказывается важным фактором, определяющим конкурентное преимущество при сравнении с другими серверами. После пары недель размышлений и прикидок на бумажках у меня возникло ощущение, что мы сможем уложить все это в стандартное 19” шасси высотой 2U.

Память

Учитывая целевой объём памяти и общее количество планок, её размещение — определяющий фактор при построении компоновки сервера. Понятно, что разместить 128 модулей DIMM на системной плате просто невозможно как исходя из банальной геометрии (плата будет гигантских размеров), так и исходя из требований Signal Integrity. Очевидно, что для упихивания нашего количества памяти нужно делать вертикально размещаемые в шасси райзеры, которые подключаются к системной плате. На райзерах необходимо разместить коннекторы под DIMM’ы и буфер памяти Centaur, который содержит кэш и обеспечивает доступ процессора к памяти (один процессор поддерживает до 4-х буферов памяти).

Первая идея компоновки райзера подразумевала размещение модулей с одной стороны, а буфера памяти сбоку рядом с ними, как на картинке. Но, во-первых, мы уперлись в ограничение по длине трасс от буфера к DIMM’ам, а во-вторых поняли, что будут проблемы с их выравниванием.

Первоначальная схема компоновки райзера памяти

Пришлось делать иначе — размещать чип буфера памяти между двумя группами DIMM’ов. Сначала было немножко неочевидно, пройдет ли такое решение по высоте, но аккуратно посчитав высоту райзера, мы поняли, что при размещении компонентов с минимальными допусками получившаяся плата как раз по высоте проходит между дном и крышкой 2U-корпуса. Таким образом, коннектор для подключения к системной плате необходимо было вынести вбок, и райзер получился таким:

Плата сложная, 18 слоев.

Локальное хранилище и вентиляторы охлаждения

Дальше занялись построением общей компоновки сервера. Традиционно в передней части шасси располагаются диски для локального хранилища. Для шасси высотой 2U наиболее стандартными вариантами являются либо 24 × 2.5”, либо 12 × 3.5”. Мы выбрали первый – 3.5” диски нас в данном проекте не сильно интересуют, поскольку мы ориентируемся скорее на SSD.

Позади дисков классически размещаются вентиляторы — тут тоже не было особенных вопросов: поставили 5 вентиляторов распространённого размера 80 × 38 мм – собственно, максимум, который помещался по ширине. Тут тоже были задачи, с которыми пришлось повозиться – при размещении пяти вентиляторов практически не остается места под коннекторы (необходимо же обеспечить возможность их замены на ходу). Выкрутились, найдя очень компактные коннекторы и разместив их фактически в объёме, занимаемом самими вентиляторами.

Подключение вентиляторов. Для удобства отображения скрыт ближний вентилятор и ближняя направляющая рамка.

Вентиляторы подключаются к лежащей под ними плате, которая разводит линии питания и управления оборотами. У каждого вентилятора свой канал управления. На картинке видны шины питания, ведущие к плате — они проходят вдоль левой стороны сервера, если развернуть его блоками питания к себе. По правой стороне проходит шлейф для передачи управляющих сигналов ШИМ от системной платы.

С подключением локальных дисков тоже все не так просто. Нам очень нравится стандарт NVMe, и мы в целом считаем, что за ним будущее. Какие бы новые типы памяти не появились в обозримом периоде (тот же 3D-XPoint от союза Intel и Micron), скорее всего они найдут применение и в варианте NVMe дисков, поскольку PCI Express сегодня является наиболее коротким путем подключить что бы то ни было к процессору (да, мы знаем про NV-DIMM, но это очень дорогой компромисс, который к тому же отъедает ценные для нас слоты под память). С другой стороны, нам бы не хотелось окончательно и бесповоротно отказываться от поддержки SAS/SATA. Эти соображение достаточно логичным образом привели нас к решению о том, что на системной плате мы будем размещать коннекторы, позволяющие нам вывести шину PCI Express кабелем к дисковым контроллерам, будь то коммутатор PCI Express или SAS HBA/RAID контроллер.

В качестве наиболее подходящей для нас пары разъём-кабель было выбрано решение NanoPitch от Molex (на самом деле это просто реализация активно продвигаемого PCI SIG стандарта OCuLink). Кабели для внутренних подключений достаточно компактны и позволяют по одному кабелю прокидывать до 8 лэйнов PCIe Gen3.

Дальше возник вопрос о том, а где собственно размещать дисковые контроллеры. На бэкплэйне, к которому подключаются диски, сделать это просто невозможно (чипы что SAS-контроллеров, что PCIe коммутаторов слишком большие для этого). После внимательного изучения размеров дисков, максимально допустимой высоты шасси и проработки разных вариантов конструкции дисковых треев стало понятно, что в целом есть возможность разместить плату с контроллерами над дисками. Такое размещение, во-первых, упрощает её подключение к дисковому бэкплейну (можно применить стандартные CardEdge коннекторы), а во-вторых, позволяет снизить высоту дисковых треев за счет отказа от световодов и размещения всей индикации на плате контроллера.

В итоге получилась такая схема подключения:

Для разнообразия — художества от руки. Схема подключения дисков. Магнитная доска, маркеры, 2016 год.

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

Блоки питания

Блоки питания обычно ставят в левом или правом заднем углу корпуса. Нам было удобнее, исходя из дизайна PDB (Power Distribution Board), расположить их в левом (если смотреть сзади). Блоки питания решили использовать стандарта CRPS, основными преимуществами которого являются высокая удельная мощность блоков питания (2 кВт уже сегодня, до 2,4 – почти завтра), высокий КПД, а самое главное — это не какой-то проприетарный стандарт одного вендора, а стандарт, инициатором которого был в свое время Intel и который был поддержан значительным количеством компаний. Два двухкиловаттных блока питания в нашем случае расположены друг над другом.

Ещё немного про память

Поскольку на каждом райзере мы размещаем по одному буферу памяти и по 8 DIMM’ов (максимально поддерживаемое Centaur’ом количество), то получается, что нам требуется четыре райзера на процессор, то есть всего 16 в шасси. Исходя из высоты стандартных модулей DDR4 RDIMM в ширину таких райзеров в шасси можно разместить не более 11 (да и то, приходится использовать Ultra-low seating DIMM-сокеты и ужиматься, считая десятые доли миллиметров). Поэтому ещё 5 райзеров пришлось поставить в другое место, на заднюю часть системной платы. Собственно, это и привело в итоге к разворачиванию одного процессора на 180 градусов (последняя Ктулху-картинка в прошлой статье). Учитывая высоту наших райзеров памяти от дна до крышки сервера, к ограничениям формы системной платы добавился ещё один вырез.

После этого осталось только разместить разъёмы для стандартных карт PCI Express, количество которых однозначно определилось свободным местом. Получилось разместить 5 слотов, плюс отдельный коннектор для платы менеджмента (для разгрузки системной платы мы решили вынести на отдельную карту BMC, USB и Ethernet — всё это поместили на отдельную небольшую плату, которая устанавливается в тот самый шестой разъём).

Общая схема

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

Легенда:

0. Системная плата.
1. Процессоры IBM POWER8 SCM Turismo.
2. Райзеры памяти с DIMM’ами.
3. 24 × 2.5” диска и дисковый бэкплейн
4. Слоты для карт расширения (поддерживаются только HHHL, то есть низкопрофильные карты).
5. Плата управления.
6. Вентиляторы системы охлаждения.
7. Блоки питания.

Вот эти соображения, которые я описал, и определили облик сервера. Итого: стандартное 19” шасси высотой 2U, 4 сокета для процессоров POWER8, 16 разъёмов для райзеров с планками памяти (всего до 128 модулей DIMM во всём сервере, по 8 на каждом райзере), 5 стандартных PCI Express слотов для карт расширения и одна карта управления.

Let's block ads! (Why?)

Как это работает: Пара слов о DNS

Являясь провайдером виртуальной инфраструктуры, компания 1cloud интересуется сетевыми технологиями, о которых мы регулярно рассказываем в своем блоге. Сегодня мы подготовили материал, затрагивающий тему доменных имен. В нем мы рассмотрим базовые аспекты функционирования DNS и вопросы безопасности DNS-серверов.

/ фото James Cridland CC

Изначально, до распространения интернета, адреса преобразовывались согласно содержимому файла hosts, рассылаемого на каждую из машин в сети. Однако по мере её роста такой метод перестал оправдывать себя – появилась потребность в новом механизме, которым и стала DNS, разработанная в 1983 году Полом Мокапетрисом (Paul Mockapetris).

Что такое DNS?

Система доменных имен (DNS) является одной из фундаментальных технологий современной интернет-среды и представляет собой распределенную систему хранения и обработки информации о доменных зонах. Она необходима, в первую очередь, для соотнесения IP-адресов устройств в сети и более удобных для человеческого восприятия символьных имен.

DNS состоит из распределенной базы имен, чья структура напоминает логическое дерево, называемое пространством имен домена. Каждый узел в этом пространстве имеет свое уникальное имя. Это логическое дерево «растет» из корневого домена, который является самым верхним уровнем иерархии DNS и обозначается символом – точкой. А уже от корневого элемента ответвляются поддоменые зоны или узлы (компьютеры).

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

В иерархическом же пространстве имен каждое имя составлено из нескольких частей: например, домена первого уровня .ru, домена второго уровня 1cloud.ru, домена третьего уровня panel.1cloud.ru и т. д. Этот тип пространства имен позволяет легко проводить проверки на дубликаты, и при этом организациям не нужно беспокоиться, что префикс, выбранный для хоста, занят кем-то другим – полный адрес будет отличаться.

Сопоставление имен

Давайте взглянем, как происходит сопоставление имен и IP-адресов. Предположим, пользователь набирает в строке браузера www.1cloud.ru и нажимает Enter. Браузер посылает запрос DNS-серверу сети, а сервер, в свою очередь, либо отвечает сам (если ответ ему известен), либо пересылает запрос одному из высокоуровневых доменных серверов (или корневому).

Затем запрос начинает свое путешествие – корневой сервер пересылает его серверу первого уровня (поддерживающего зону .ru). Тот – серверу второго уровня (1cloud) и так далее, пока не найдется сервер, который точно знает запрошенное имя и адрес, либо знает, что такого имени не существует. После этого запрос начинает движение обратно. Чтобы наглядно объяснить, как это работает, ребята из dnssimple подготовили красочный комикс, который вы можете найти по ссылке.

Также стоит пару слов сказать про процедуру обратного сопоставления – получение имени по предоставленному IP-адресу. Это происходит, например, при проверках сервера электронной почты. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя.

Кто управляет и поддерживает DNS-сервера?

Когда вы вводите адрес интернет-ресурса в строку браузера, он отправляет запрос на DNS-сервер отвечающий за корневую зону. Таких серверов 13 и они управляются различными операторами и организациями. Например, сервер a.root-servers.net имеет IP-адрес 198.41.0.4 и находится в ведении компании Verisign, а e.root-servers.net (192.203.230.10) обслуживает НАСА.

Каждый из этих операторов предоставляет данную услугу бесплатно, а также обеспечивает бесперебойную работу, поскольку при отказе любого из этих серверов станут недоступны целые зоны интернета. Ранее корневые DNS-серверы, являющиеся основой для обработки всех запросов о доменных именах в интернете, располагались в Северной Америке. Однако с внедрением технологии альтернативной адресации они «распространились» по всему миру, и фактически их число увеличилось с 13 до 123, что позволило повысить надёжность фундамента DNS.

Например, в Северной Америке находятся 40 серверов (32,5%), в Европе – 35 (28,5%), еще 6 серверов располагаются в Южной Америке (4,9%) и 3 – в Африке (2,4%). Если взглянуть на карту, то DNS-серверы расположены согласно интенсивности использования интернет-инфраструктуры.

Защита от атак

Атаки на DNS – далеко не новая стратегия хакеров, однако только недавно борьба с этим видом угроз стала принимать глобальный характер.

«В прошлом уже происходили атаки на DNS-сервера, приводящие к массовым сбоям. Как-то из-за подмены DNS-записи в течение часа для пользователей был недоступен известный всем сервис Twitter, – рассказывает Алексей Шевченко, руководитель направления инфраструктурных решений российского представительства ESET. – Но куда опаснее атаки на корневые DNS-сервера. В частности, широкую огласку получили атаки в октябре 2002 года, когда неизвестные пытались провести DDoS-атаку на 10 из 13 DNS-серверов верхнего уровня».

Протокол DNS использует для работы TCP- или UDP-порт для ответов на запросы. Традиционно они отправляются в виде одной UDP-датаграммы. Однако UDP является протоколом без установления соединения и поэтому обладает уязвимостями, связанными с подделкой адресов – многие из атак, проводимых на DNS-сервера, полагаются на подмену. Чтобы этому препятствовать, используют ряд методик, направленных на повышение безопасности.

Одним из вариантов может служить технология uRPF (Unicast Reverse Path Forwarding), идея которой заключается в определении того, может ли пакет с определенным адресом отправителя быть принят на конкретном сетевом интерфейсе. Если пакет получен с сетевого интерфейса, который используется для передачи данных, адресованных отправителю этого пакета, то пакет считается прошедшим проверку. В противном случае он отбрасывается.

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

Еще один вариант – использование функции IP Source Guard. Она основывается на технологии uRPF и отслеживании DHCP-пакетов для фильтрации поддельного трафика на отдельных портах коммутатора. IP Source Guard проверяет DHCP-трафик в сети и определяет, какие IP-адреса были назначены сетевым устройствам.

После того как эта информация была собрана и сохранена в таблице объединения отслеживания DHCP-пакетов, IP Source Guard может использовать ее для фильтрации IP-пакетов, полученных сетевым устройством. Если пакет получен с IP-адресом источника, который не соответствует таблице объединения отслеживания DHCP-пакетов, то пакет отбрасывается.

Также стоит отметить утилиту dns-validator, которая наблюдает за передачей всех пакетов DNS, сопоставляет каждый запрос с ответом и в случае несовпадения заголовков уведомляет об этом пользователя. Подробная информация доступна в репозитории на GitHub.

Заключение

Система доменных имён разработана в еще 80-х годах прошлого века и продолжает обеспечивать удобство работы с адресным пространством интернета до сих пор. Более того, технологии DNS постоянно развиваются, например, одним из значимых нововведений недавнего времени стало внедрение доменных имен на национальных алфавитах (в том числе кириллический домен первого уровня.рф).

Постоянно ведутся работы по повышению надежности, чтобы сделать систему менее чувствительной к сбоям (стихийные бедствия, отключения электросети и т. д.), и это очень важно, поскольку интернет стал неотъемлемой частью нашей жизни, и «терять» его, даже на пару минут, совершенно не хочется.

Кстати, компания 1cloud предлагает своим пользователям VPS бесплатную услугу «DNS-хостинг» – инструмент, упрощающий администрирование ваших проектов за счет работы с общим интерфейсом для управления хостами и ссылающимися на них доменами.

О чем еще мы пишем:

• Мифы об облачных технологиях. Часть 1
• Мифы об облачных технологиях. Часть 2
• Как создать провайдера виртуальной инфраструктуры
• Как выбрать направление для развития ИТ-проекта
• Что нужно знать об IaaS-провайдере до начала работы

Let's block ads! (Why?)

Путеводитель по решениям ONLYOFFICE для образования

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

Далее расскажем о том, как ONLYOFFICE может помочь в учебном процессе и/или его организации.

ONLYOFFICE в школах и вузах: чтобы что?

ONLYOFFICE изначально задумывался как решение для бизнеса, но время (и интерес со стороны НКО и образовательных учреждений) показало, он более универсален. Функции, которые создавались с прицелом на оптимизацию бизнес-процессов, вполне способны работать и на образование.

Теперь мы видим как минимум два направления использования нашего софта в этой сфере:

• Организация внутреннего документооборота и управление школой/вузом;
• Использование непосредственно в учебном процессе для организации взаимодействия учеников и преподавателей.

Вот какие инструменты предлагает ONLYOFFICE для оптимизации обоих направлений:

• Онлайн-редакторы для просмотра, обмена, совместного редактирования и комментирования письменных работ учащихся (о том, чем именно редакторы ONLYOFFICE превосходят Google Docs и MS Office Online читать тут);
• модуль Документы для организованного хранения файлов и предоставления доступа к ним — это могут быть как бухгалтерские документы, приказы, учебные планы, так и раздаточные материалы для уроков, лекции и пр.
• модуль Проекты для организации и контроля учебных и внеучебных мероприятий;
• Сообщество — своеобразная соцсеть с блогами, форумами и чатом для общения и обсуждения важных тем в реальном времени. Может также работать как система оповещения о событиях, датах каникул, праздничных дней;
• модуль CRM для хранения необходимых контактов (например, номеров родителей в случае школ);
• Почта для управления корреспонденцией, оповещения об изменениях в расписании;
• Календарь для отслеживания важных событий и занятости преподавателей.

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

Кратчайший гайд по решениям для образовательных организаций

ONLYOFFICE в облаке

Решение включает всю функциональность ONLYOFFICE + 2Гб дискового пространства. Оно бесплатно для всех НКО и любых общеобразовательных организаций.

Идеально подойдет учебным учреждениям с небольшим количеством пользователей. Например, языковым или бизнес-школам: систему документ-менеджмента можно использовать как для ведения бухгалтерии, составления расписаний и управления внутренними ресурсами, так и для хранения материалов для учащихся и проверки их работ. Только подумайте: необязательно отправлять миллион отсканированных документов на десятки почтовых ящиков — их можно просто пошарить ученикам. Необязательно скачивать и править написанные учениками эссе, а потом отправлять их обратно по электронной почте — всё это можно сделать на портале с помощью нашего совместного редактирования! (да, по поводу языковой школы — это у автора наболело)

Серверная версия ONLYOFFICE

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

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

Бесплатна для общеобразовательных школ, для остальных образовательных организаций — скидки.

Десктопные редакторы

для редактирования текстовых документов, электронных таблиц и презентаций без подключения к интернету. Подойдут тем, кто по экономическим соображения избегает лицензионного MS Office и (по каким-либо причинам) никак не может смириться с необходимостью пользоваться LibreOffice. Очень простой интерфейс позволит быстро привыкнуть даже самым консервативным преподавателям. Кстати, десктопы также можно подключить и к облаку, и серверу и при необходимости легко переключаться между оффлайн- и онлайн- режимами редактирования.

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

Онлайн-редакторы для интеграции

Мы не думали об этом, пока не получили запрос на интеграцию редакторов от пары университетов из Западной Европы.

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

ONLYOFFICE в кадетском корпусе

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

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

Причины решения лежат на поверхности: учебное учреждение относится к Минобороны и практически вся внутренняя документация как минимум имеет гриф «Для служебного пользования». Кроме того, по федеральному закону, который мы все помним и любим, вся информация должна располагаться на серверах внутри РФ. Это побудило представителей кадетского корпуса искать именно серверное решение, работающее на базе Linux. Поиски остановились на open source версии ONLYOFFICE.

(Отвергнутые решения: Google Apps, Office 365 и «Битрикс 24», распространяемые на коммерческой основе. Кроме того, на момент перехода только «Битрикс» начал переносить свои сервера в Россию).

Небольшой спойлер: позднее в СПбКВК перешли с открытой версии на наше корпоративное серверное решение ONLYOFFICE Enterprise Edition. На самом деле, именно продуктивное сотрудничество с кадетским корпусом побудило нас сделать Enterprise Edition бесплатным для школ.

Системные требования и немного технических деталей

Для установки ONLYOFFICE на школьный сервер должны выполняться следующие требования:

• Двухъядерный процессор с тактовой частотой 2 ГГц;
• минимум 6Гб оперативной памяти;
• 64-битная версия Linux/Ubuntu;
• место на жестком диске — от 40 Гб.

В кадетском корпусе ONLYOFFICE развернут на базе дистрибутива Xubuntu GNU/Linux версии 14.04 с 64-битной архитектурой (выбрана версия Ubuntu с облегченным рабочим столом XFCE).

ИНФОЗОНА кадетского корпуса

Система электронного документооборота, созданная с помощью ONLYOFFICE в кадетском корпусе, получила гордое имя «ИНФОЗОНА». Ей пользуются преподаватели, методисты и администрация кадетского корпуса. Общее число пользователей системы около 100 человек, которые работают в четырех различных зданиях.

Как рассказал нам глава Лаборатории Инновационных образовательных технологий Виталий Битюнников, трудностей перехода на новое ПО почти никто не испытал: у всех сотрудников был необходимый минимум опыта работа с Google Apps и после коротенькой мотивирующей речи и совсем небольшого обучения все легко перестроились (некоторым так же пришлось сменить Internet Explorer на Google Chrome, но мы считаем, что всем от этого только лучше).

Сейчас решение используют исключительно для управления информационными ресурсами школы. Но в то же время в Лаборатории ИоТ думают подключить к системе и самих воспитанников корпуса. В этом случае число пользователей системы вырастет до 800, и ONLYOFFICE станет неотъемлемой частью учебного процесса, чего нам самим, признаться, очень бы хотелось.

Почти конец

Самое приятное, что в кадетском корпусе не просто внедрили ONLYOFFICE: разработанную систему представляют на конференциях и таких мероприятиях как День инноваций Минобороны, а в Лаборатории ИоТ подготовили целое методическое пособие, чтобы упростить переход других школ на СПО и ONLYOFFICE.

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

В общем, весь этот пафос к тому, что если вы представляете образовательное учреждение, пишите нам на edu@onlyoffice.com. Найдем решение ONLYOFFICE для вас.

Let's block ads! (Why?)

[Из песочницы] Советы по работе с Steam GreenLight или как не погрязнуть в болоте

Для многих из нас зеленый свет для собственной игры в Steam GreenLight является целью, к которой люди готовы идти месяцами, а то и годами. Настает тот день, когда игра готова и пришло время выложить её на всеобщее обозрение. С чего же начать и как не ошибиться? Об этом и пойдёт речь в данной статье

P.S. Через все описанное ниже автор прошел лично, с целью набить как можно больше шишек.

О платформе

Английский всему голова

Первая и самая главная особенность, которой в свое время автор пренебрег, является то, что большинство пользователей говорят на английском языке.

Данные по загрузкам в разных странах

Вывод #1. Английский язык должен быть основным

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

Вывод #2. Некоторые негативно относятся к русским одиночкам

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

Время работает против вас

До момента, как ваша игра выйдет из поля зрения в общем списке у вас будет от 1,5 до 2 дней. Дальше надеется на естественный интерес к вашему проекту не приходится.

Проверено на личном опыте:

Внятный ролик стоит больше предоставления прототипа

К игре, которая была выложена на площадке, был прикреплен урезанный вариант игры на Google Play. Так вот. За положенные полтора дня естественного прироста интереса, никто не скачал прототип. Ещё один плюсик в то, что у вашей игры есть только ролик и описание, чтобы понравиться людям!

Статистика проекта на Google Play:

Что со всем этим делать?

Так как попасть в сотню разработчиков, чьи приложения проходят через порог GreenLight?

Выводы из всего вышесказанного и то, что может пригодиться

• Нужно постоянно поддерживать информационное поле. У вас есть ТОЛЬКО до двух дней после запуска, пока ваш проект сам привлекает к себе внимание. Но это не принесет нужное количество просмотров и одобрений, которые необходимы. Вы САМИ должны привлекать внимание к своему проекту;
• Простое видео не всегда хорошо. Помимо простоты, ролик должен четко описывать, что именно представляет из себя ваша игра. Пусть даже это займет не одну, а две или даже три минуты;
• Английский ваш друг. Английский — международный язык. Если этим пренебречь, вы можете сильно потерять в голосах.

Удачи вам! И да поможет вам тот, в кого вы верите!

Let's block ads! (Why?)

Защита периметра: старые атаки не хуже новых

Интервью с дизайнером: Михаил Озорнин

Это пилотный выпуск серии интервью с дизайнерами интерфейсов. Не супер-звездами, а обычными ребятами, которые работают над коммерческими и массовыми продуктами и сервисами. Сегодня главный герой — Михаил Озорнин. Он проектирует интерфейсы для мрачных мужчин в костюмах и галстуках. А еще Михаил — выпускник первого набора школы Горбунова.

Расскажи о себе вкратце: чем занимаешься, где и над чем работаешь, чем увлекаешься помимо работы?

Я был разработчиком, системным аналитиком, менеджером проектов, а потом пришел в проектирование и дизайн. Сейчас — дизайнер интерфейсов в Positive Technologies. Спорим, вы о ней не слышали? Обычно её не знает никто за пределами рынка информационной безопасности, а ИБ-специалисты знают все поголовно.

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

Вырос в Екатеринбурге, переехал в Москву. Люблю велосипеды (в городах) и путешествия, предпочту Амстердам или Питер вместо Пхукета или Бали.

Что в дизайне для тебя самое интересное? За что любишь эту профессию?

Мне нравится мысль, что я хотя бы немного делаю мир более упорядоченным, проще и эстетичней. Этакая борьба со вторым началом термодинамики. Радуюсь, когда я приношу решение и реакция «оу, а так можно было?». Такое, правда, бывает очень и очень нечасто.

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

С этим сложно. Рынок корпоративных программных продуктов часто далек от хорошего дизайна. (Вот Артём Локи немного пишет про это). Соберусь и напишу пост для тех, кто не знаком, что такое корпоративное ПО.

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

MaxPatrol — один из продуктов Positive Technologies, где работает Михаил

Вот что приходится применять:

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

Многие компании не показывают скриншоты продуктов, наша, как правило, тоже. Публично моих продуктов вроде не было. Но поверьте, там мало чего интересного.

Что посоветуешь начинающим дизайнерам, как лучше всего прокачаться в профессии?

1. Пройти школу бюро Горбунова, см. следующий вопрос.
2. Поработать с хорошим арт-директором или ведущим дизайнером. У меня этого способа в жизни не было, но учеба показала, что он очень круто помогает.
3. Очень помогает устраивать себе марафоны. Делать каждый день какую-то штуку: за неделю нарисовать 300 иконок, сверстать 100 ценников или придумывать и рисовать по мобильному приложению в день. Есть даже такой марафон Daily UI, я подписался, но сразу бросил — понял, что не смогу держать темп.
4. Перестать читать статьи «23 правила построения сайтов» и прочитать оригиналы в книгах.
5. Учить английский, почти все хорошее публикуется или только на английском, или сначала на английском. На русском или не переводят, или переводят плохо.
6. Научиться немного верстать и программировать: так будет проще найти общий язык с разработчиками, да и просто в жизни поможет не делать вручную всякую рутину.

Ты закончил школу бюро Горбунова. Что скажешь о ней?

Через месяц после окончания я написал пост «9 месяцев в Школе стажёров Бюро», в котором описал результаты и мнение. Я перечитал его сейчас и в общей оценке до сих пор согласен. Единственное, что для «продуктового дизайнера» там маловато про продукт: исследования, гипотезы, прототипы, ЭмВиПи. Я немного зря тогда употребил этот термин. Не хватало типографики не на макроуровне, а на уровне шрифтов.

В общем, это были самые полезные 9 месяцев для меня как дизайнера. Не жалею, и если бы вернулся в то время, пошел бы снова и на этот раз постарался получить от школы больше.

Какие инструменты используешь в работе? Какие из них считаешь безупречными?

У меня всё как и у всех: скетч, бумажный блокнот, атом, альфред, мейл.апп, скриншотилка и скайп. Безупречных среди них нет.

Скетч: не потому, что Фотошоп — плохой, я просто не умею им пользоваться. Я долго пользовался файрворксом, но потом стало ясно что в нем нет будущего. Скетч — это нормально сделанный файрворкс.

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

Альфред распробовал только месяца полтора назад (до этого не пошел), сейчас без него неудобно. Число моих сниппетов и воркфлоу медленно растёт.

Последние несколько месяцев вынужденно не пользуюсь Мейл.аппом, он перестал нормально работать с Эксченджем. Жду релиза Сиерры — в ней починили обратно.

Покажи скриншот экрана своего смартфона

Смартфона у меня нет. Есть телефон Филипс Ксениум Х130, он умеет звонить и писать смски.

Вместо смартфона вот экран планшета, я на нем делаю все то, что люди на смартфонах. У кого-то лопата 6'', у меня почти 10.

Какие книги больше всего рекомендуешь коллегам?

Я согласен со входным списком Школы стажёров:

Список литературы школы Горбунова

Еще раз посмотрел свои оценки на Лайвлибе, всё так. Все эти книги стоит прочитать. Некоторые лучше, некоторые хуже, но все нужны.
Начать с Нормана и Раскина (пропустить окончание про Кэнон Кэт), потом Тафти. По верстке: Мюллер-Брокманн больше академическая, для жизни полезней Харровер.

Что я бы добавил:

• «Основы стиля в типографике» Брингхёрста,
• «Образцы шрифтов» Чихольда,
• «Ремоут» от 37 Signals,
• «Об интерфейсе» Купера,
• «100 фактов, которые нужно знать о людях» Сьюзан Вайншенк (перевод названия на русский — катастрофа).

В каких профессиональных сообществах состоишь? Какие посещаешь конференции?

Так вышло, что в сообществах ни в каких не состою: подписан на UX Russia, но там давно нет жизни, числюсь в «Полезном клубе», но там тоже мало что происходит.

Из конференций иногда хожу на WUD или Dribble Meetup, когда оказываюсь в городе. К UX Russia отношусь скептически: последние две, на которых был, были очень откровенно плохие.

Ценю, когда конференции выкладывают видео, смотрю доклады на удвоенной скорости.

Что тебя больше всего огорчает в отрасли и в коллегах?

Мне тяжело работать с людьми, у которых сильно отличаются принципы. Отсутствие 1–2 из принципов усложняет совместную работу, отсутствие нескольких делает совместную работу маловероятной.

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

Хочешь что-нибудь сказать коллегам-дизайнерам? Совет или напутствие?

Делайте хорошо и не делайте плохо :–)

---

Михаил на Хабре: mikeozornin

Let's block ads! (Why?)