«Яндекс» запустил сервис «Документы»
26 апреля 2021 года «Яндекс» объявил о запуске сервиса «Документы». Это онлайн-сервис для создания и совместного редактирования файлов — аналог облачного офисного пакета Google Docs.
Сервис «Документы» позволяет создавать текстовые файлы, таблицы, презентации, поддерживает форматы docx, xlsx и pptx, может конвертировать в эти форматы пользовательские файлы более старых версий.
Для совместной работы над документом пользователю нужно отправить ссылку на редактирование файла другому пользователю. В этом случае другому пользователю не потребуется иметь аккаунт на «Яндексе» для получения доступа к файлу.
Сервис «Документы» доступен в браузере как на ПК, так и на мобильных устройствах. Все файлы сервиса хранятся на облачной платформе «Яндекс.Диск».
В начале апреля 2021 года «МойОфис» запустил бесплатные общедоступные (не требущие регистрации) веб-редакторы текстовых и табличных документов в форматах ODT, ODS, DOCX, XLSX, PDF. Веб-редакторы «МойОфис» построены на базе автономного модуля редактирования и совместимы с любыми браузерами на ПК, на мобильных устройствах пользователям предлагается установить пакет «МойОфис».
- Яндекс
- сервис «Документы»
Кто знает как разрабатывают в Яндексе?
Кто знает, как организован процесс разработки в Яндексе? Интересно следующее, как именно разработчик поднимает проект у себя на локальной машине, чтобы начать работать с кодом? Поднимает ли вообще?
Допустим пришел новый разработчик на проект Яндекс.фотки. По идее он должен вытянуть только код этого проекта из репозитория, чтобы начать с ним работать. Но Яндекс.фотки может зависеть от других сервисов, например от Яндекс.паспорт, чтобы хотя бы залогиниться на Яндекс.фотках. Вот как разработчик это решает? Вытягивает чтоли весь репозиторий яндекса со всеми его сервисами и всё это настраивает?
Или он вытягивает только яндекс.фотки, пишет свой какой-то код и юнит-тесты на него, делает push и все, континиус интегрейшен? Разве не смотрит локально результат своей работы в браузере?
Как вы думаете? Или как бы вы это делали? Если у вас 20 разных сервисов, они как-то друг между другом связаны. Как бы вы поднимали локальную копию проекта? У всех 20 сервисов настраивали бы коннект к бд и еще тонну всяких конфигов, чтобы это всё хотя бы локально заработало?
Как? Поделитесь мыслями. Тоже самое касается любой другой крупной ИТ компании.
- Вопрос задан более трёх лет назад
- 717 просмотров
Комментировать
Решения вопроса 0
Ответы на вопрос 3
Дмитрий Макаров @DmitryITWorksMakarov
Если зависимости представлены интерфейсами, то нет никакой необходимости подтягивать другие проекты — достаточно заглушек. К тому же не всегда возможно привести проект-зависимость в необходимое для тестирования вашего проекта состояние, тогда как заглушка полностью подконтрольна вам. Взаимодействие разных проектов проводится нам этапе интеграционного тестирования. Это совсем отдельная работа.
Эмиль Шарифуллин из «Яндекса»: «Больше всего в работе мне нравится сложность»
Как выглядит рабочий день инфраструктурного инженера в корпорации, какие задачи он решает и как устроиться сеньором в «Яндекс».
Иллюстрация: Imgix / Unsplash / Дима Руденок для Skillbox Media
Мария Даровская
Журналист, коммерческий автор и редактор. Пишет про IT, цифровой маркетинг и бизнес.
Сайт: darovska.com.
Эмиль Шарифуллин
Разработчик инфраструктурных сервисов. Работает в «Яндексе» в сервисе управляемых баз данных. Увлекается воркаутом, практической стрельбой, сноубордом, вокалом, гитарой.
Ссылки
Я делю всю разработку на бизнес-разработку и инфраструктурную — это моё видение мира. Инфраструктурная разработка — это всё то, что вы делаете для разработчиков, а бизнес-разработка — это всевозможные сервисы для конечных пользователей.
Сам я работаю в Yandex Cloud, а наша команда занимается управляемыми базами данных Redis и MongoDB. Суть управляемых баз данных в том, что клиент избавляется от необходимости настройки и администрирования СУБД для своих проектов, потому что мы предоставляем ему развёрнутую и рабочую базу данных на своих мощностях.
У «Яндекса» есть несколько дата-центров в России и один в Финляндии — на собственных серверах, которые производят в Китае и Тайване, а проектируют полностью внутри компании, под свои нужды. Приоритеты — энергоэффективность и удовлетворение потребностей.
В больших компаниях, как правило, существуют разные уровни взаимодействия сотрудников с дата-центрами. Те, кто пишет для них софт, нечасто там появляются и даже могут не особо представлять, как выглядят железки, на которых этот софт запускается. Мои сервисы не слишком низкоуровневые, поэтому сам я в дата-центры не езжу.
Общаясь с ребятами, которые специализируются на бизнес-разработке, я выделил для себя несколько ключевых отличий от работы над инфраструктурными проектами:
Предметно-ориентированное проектирование — DDD . В инфраструктурной разработке оно не используется, а вот в бизнес-разработке применяется довольно часто: реальный мир сложен, и DDD позволяет вам хоть как-то его изучить, чтобы потом на этом описании строить систему. В инфраструктурной разработке требования более формальные и строгие, потому что сервера всегда работают так, как должны и как вы этого от них ожидаете: физику или computer science никто не отменял. У них не так много краевых случаев и исключений, которые постоянно проявляются в обычной жизни. Кстати, именно поэтому я и не люблю бизнес-разработку: там приходится описывать и пытаться формализовать сложные процессы реального мира, взаимодействие людей, а в инфраструктурных проектах сложность заключается в алгоритмах, законах физики и тому подобном.
Сложные, индивидуальные наукоёмкие задачи. В инфраструктурной разработке их приходится решать гораздо чаще, чем в бизнес-разработке, большинство задач в которой, как часто шутят программисты, — перекладывание JSON из запроса в базу данных и обработка их по правилам из DDD.
Согласованная работа нескольких серверов. В инфраструктурной разработке это распространённая задача, и тут много подводных камней: например, очень часто программисты считают сеть и жёсткие диски ненадёжными. Плюс нельзя гарантировать, что вашу программу процессор выполнит именно так, как вы её написали: он может по своему усмотрению подвинуть инструкции или выполнить их в другом порядке.
Поэтому приходится копать довольно глубоко и разбираться в самых низкоуровневых нюансах. А в бизнес-разработке программист обычно защищён от этих проблем стеной фреймворков и кучей слоёв абстракции.
Кстати, современные IT-системы так или иначе построены на костылях — просто потому, что есть вещи, которые нельзя реализовать чисто физически. Например, вы не сможете сделать так, чтобы у вас на нескольких серверах было одинаковое с точностью до наносекунд время. Даже если вы их соедините оптоволоконным кабелем, всё равно пройдёт какое-то время, прежде чем сигнал пройдёт от одного сервера до другого. Поэтому такие моменты нужно заранее продумывать.
Я нисколько не умаляю значимость работы программистов, которые пишут бизнес-сервисы, — просто у них свой, особый мир. И я не смог бы войти в бизнес-разработку прямо сейчас, потому что у меня нет для этого релевантного опыта. Зато мне очень интересно разбираться, как и что работает под капотом.
Работа с инфраструктурой в большой компании
Раньше я разрабатывал инфраструктурные сервисы в Red Hat и контуре CI/CD-системы, системы мониторинга и тому подобное, а сейчас перешёл в сервис управляемых баз данных. Сервис управляемых баз данных — это часть «Яндекс.Облака», которая позволяет максимально просто и удобно развернуть облачную БД и не заморачиваться с поддержкой.
Клиент просто приходит и говорит, что ему нужна MongoDB или Redis и определённое количество ресурсов, а мы устанавливаем и настраиваем нужные пакеты и выдаём ему готовую рабочую БД.
В маленьких компаниях инженерам, которые отвечают за DevOps, достаточно построить систему, которая просто работает. В больших же компаниях нужно поднимать масштабируемые системы — они должны работать в тысячах или миллионах экземпляров.
При этом базовые навыки всё те же: установить пакет и зависимости, которые нужны для работы приложения. Вот только в небольшом стартапе вы будете всё это поднимать на двух-трёх выделенных серверах или арендованном кластере на Kubernetes, в котором всё сразу запустится.
В больших компаниях всё немного по-другому: вам (а скорее вашим коллегам из отдела инфраструктуры) сначала придётся самостоятельно установить и настроить Kubernetes или другой оркестратор и уже после этого добавить все необходимые приложения и конфигурации. А так так подобных задач в больших компаниях много, то есть сотрудники, которые на фул-тайм занимаются исключительно установкой и настройкой Kubernetes.
Мой опыт — на стыке DevOps и программирования. Я плотно занимался DevOps на предыдущей работе, в стартапе, а теперь использую знания и скиллы, чтобы создавать инфраструктурные сервисы для разных компаний.
И на уровне инструментов это очень разные процессы: например, условный Ansible больше подходит для работы на небольших проектах или в небольших командах, так как поддерживать большие плейбуки и раскатывать их на тысячи серверов довольно сложно, поэтому у нас в команде используется salt и куча внутренних специализированных инструментов. И это распространённая практика — даже в Red Hat, команда которой и разработала Ansible, многие его не используют, потому что он им просто не подходит.
Как проходит рабочий день инфраструктурного инженера и какие инструменты он использует
День разработчика в разных компаниях проходит примерно одинаково. Вы просыпаетесь, идёте в душ, наливаете кофе и садитесь за работу. Сначала смотрите, что произошло со вчерашнего дня, обновляете почту, проверяете, есть ли проблемы с code review, а дальше пишете код, ходите на встречи, обсуждаете проблемы.
Помимо стандартных форматов встреч вроде дейли, у нас в команде есть ещё специальные архитектурные встречи, где мы обсуждаем архитектуру проекта и приоритетные задачи по ней. Плюс у меня есть дежурства, на которых надо следить за инфраструктурой и фиксить возникающие проблемы.
На прошлой работе я был тимлидом, и мне ежедневно приходилось созваниваться с другими командами, формулировать большие цели, планировать необходимое железо на год вперёд и выполнять ещё кучу рутинной работы, помимо написания кода. А в «Яндексе» я разработчик — поэтому больше всего времени уходит именно на программирование и не приходится так вовлекаться в менеджерские задачи.
Чем я пользуюсь в работе:
- Редактор кода — в моём случае это Visual Studio Code.
- Средства коммуникации — в зависимости от компании, это может быть Telegram, Zoom, Slack, электронная почта.
- Консоль — в ней я «живу» и провожу большую часть операций.
- Хранилище кода и средства для code review — это могут быть и репозитории, и специализированные инструменты вроде Gerrit. Всё зависит от того, чем привыкла пользоваться команда. Например, в Red Hat ребята, разрабатывающие ядро Linux, обмениваются кодом по электронной почте — отправляют патчи прямо в письмах.
- Docker. Он закрывает потребность во всех остальных инструментах. Если нужна база данных, её можно поднять в Docker, если нужны какие-нибудь средства автоматизации, он и тут выручит. Иногда я даже поднимаю в Docker компилятор или интерпретатор, если необходимо собрать код в конкретной версии. В своё время Docker стал прорывной технологией — и я даже не знаю, как вообще можно без него жить.
- Kubernetes — оркестратор, инструмент для разворачивания контейнеров на большом парке серверов на кластере. Он создаёт большой виртуальный кластер и помогает удобно им управлять. Сейчас Kubernetes работает не только с Docker — хотя изначально в Google создавали Kubernetes именно под него. Например, существует инициатива Open Container, которая описывает, как у вас должны запускаться контейнеры и как они должны выглядеть — и Kubernetes её поддерживает. А форк Kubernetes от Red Hat — OpenShift — умеет работать с аналогом Docker от Red Hat, который называется Podman.
- Собственные инструменты «Яндекса». Для CI/CD мы используем собственные инструменты или общедоступные решения типа Jenkins. Самописные инструменты появляются эволюционно: сначала ты собираешь небольшой скрипт, чтобы автоматизировать какой-то процесс. Потом ты меняешь его, чтобы он по-разному вёл себя в зависимости от задачи, — а дальше внедряешь в другие команды. Например, у нас есть написанные в «Яндексе» система контроля версий, система сборки, свой репозиторий кода. Конечно, такие решения создаются с оглядкой на стандартные инструменты, и многие команды у них совпадают, однако к ним всё равно приходится некоторое время привыкать.
Ключевые знания и навыки сеньора
Я работаю на позиции сеньор-разработчика, а для этого грейда прежде всего важен реальный опыт. Поэтому истории про двадцатилетних тимлидов мне всегда казались немножко смешными: если человек не работал программистом с пятнадцати лет, у него просто не хватит опыта, чтобы заниматься большими системами в двадцать. Итак, что должен знать и уметь сеньор в энтерпрайзе.
Алгоритмы. Сюда я отношу фундаментальные знания алгоритмов, понимание, что такое асимптотика алгоритма , как тот или иной алгоритм будет работать, как устроены распределённые вычисления.
Архитектура и насмотренность в разных технологиях. На предыдущей работе я сам гонял кандидатов по архитектуре и называю это «собеседованиями на сеньора» — потому что понимание архитектуры сразу показывает реальный уровень разработчика. Даже если он легко щёлкает самые заковыристые алгоритмы, но при этом не умеет проектировать системы, он не сеньор.
Ко мне приходили кандидаты, которые проработали 10 лет в одной компании и выросли там от джуниора до сеньора. И все десять лет они занимались одним проектом — да, в нём они разбираются прекрасно, но, когда спрашиваешь у них, как построить какую-то другую систему, они не могут выйти за рамки технологий, которые использовали на протяжении 10 лет. Просто потому, что знают только эти технологии. У них даже появляется некий карго-культ: следовать по определённому маршруту, даже если это далеко не идеальное решение.
А нужен разносторонний опыт, и я думаю, его можно получить, если поработать в разных компаниях. Тогда разработчик сможет увидеть разные решения и технологии, развить хорошую насмотренность. При этом технологии в этих компаниях не должны быть одинаковыми — это поможет разработчику быстро переходить со стека на стек, осваивать новые инструменты и практики.
Например, мне как-то понадобился ZooKeeper. До этого я никогда с ним не работал, но за день прочитал документацию, посмотрел, какие алгоритмы используются внутри, и тут же начал его использовать. Скажу так: чтобы базово изучить любую технологию и написать простые приложения, достаточно одного-двух дней. А через пару месяцев практики вы уже будете неплохо разбираться в новой технологии и чувствовать себя уверенно (ну, кроме Kubernetes, там годами можно копаться в его устройстве).
Единственная технология, к которой я сильно привязан, — это язык Go. Мне он очень нравится, я дичайше кайфую от него и даже проводил курс по Go. При всякой возможности его рекламирую и агитирую всех писать на Go.
Чем выше вы поднимаетесь по карьерной лестнице, тем большую роль начинают играть софт-скиллы — потому что и коммуницировать придётся всё больше и больше. Если джуниор коммуницирует только со своим непосредственным руководителем, то мидл уже обсуждает задачи и решения с коллегами. Тимлид и вовсе выполняет менеджерские обязанности, а значит, коммуникации занимают основную часть его рабочего времени.
Когда я был тимлидом, менеджментом приходилось заниматься больше, чем программированием. А мне нравятся именно инженерные задачи, и необходимость постоянных коммуникаций — написать людям, создать встречу, сходить на встречу — просто утомила. Поэтому я ушёл обратно в разработку.
Как сеньору пройти собеседование в энтерпрайз
Чтобы получить оффер на позицию сеньор-разработчика инфраструктурных сервисов в крупную компанию вроде «Яндекса», придётся пройти несколько собеседований.
Базовые знания. На первом интервью я рассказал о себе и решил банальную алгоритмическую задачу. Ещё меня спрашивали про устройство операционных систем и UNIX в частности, проверяли, насколько хорошо я разбираюсь в computer science, задавали вопросы по SQL. Это всё — база, без которой на высоких позициях работать невозможно.
Junior-разработчик, наверное, может писать код на C#, не зная, что у него под капотом и как работает его код, как создаются те или иные соединения, как происходит сетевое взаимодействие. Он просто посылает HTTP-запрос или обрабатывает HTTP-запросы на своём веб-сервисе, и всё.
Но когда вы разработчик более высокого уровня, нужно понимать, что HTTP-запросы — это несколько слоёв абстракции, а значит, на любом из этих слоёв могут возникнуть проблемы. Банально могут закончиться лимиты на открытый файловый дескриптор, или в сети будут неполадки, пакеты могут теряться. Такие нюансы важно понимать, чтобы разрабатывать отказоустойчивые системы, а не просто «писать код».
Алгоритмы. Наверное, всем известно, что в «Яндексе» на одном из этапов найма технические специалисты проходят интервью по алгоритмам. Поэтому я советую прокачивать навык решения алгоритмических задач. Честно скажу: это не мой конёк, есть люди, которые решают такие задачи на раз-два, а я перед собеседованием в «Яндекс» тщательно готовился — например, с помощью LeetCode. Плюс мне помог предыдущий опыт.
Архитектура. Мне очень понравилось, что на собеседовании давали абстрактную задачу — в моём понимании именно так выглядит правильное интервью на сеньорскую позицию.
В моей картине мира Junior — это тот, кому дают чётко описанную задачу и говорят, что сделать, а он пишет для этого код. Middle уже может самостоятельно написать какой-то функционально законченный блок программы, выбрать для этого подходящие методы. А Senior берётся за вызовы из реального мира: ему просто обозначают проблему, а он выбирает для её решения конкретные технологии, стек, архитектуру, системы.
Пример абстрактной задачи на архитектуру — спроектировать сервис, который будет выдавать промокоды. Это задача реального мира. Вот как стоит подходить к решению таких задач на собеседовании:
1. Проанализировать цель и попытаться определить подводные камни. Чтобы это понять, нужно задать уточняющие вопросы: например, определены ли метрики сервисов, какие будут нагрузки, кто будет пользоваться сервисом, есть ли SLO/SLI/SLA.
2. Проанализировать, что именно важно для пользователя. Например, для нашей задачи это чтобы запрос на выдачу промокода был всегда работоспособен и чтобы запросы не терялись, а также промокоды не выдавались одному и тому же пользователю повторно. Смысл в том, что сначала вы определяете требования, а потом, в зависимости от требований, начинаете проектировать архитектуру.
Если у вас есть опыт, то вы сразу определите слабые места сервиса. Например, два человека с разницей в пару наносекунд могут прислать запрос на промокод. В этом случае может возникнуть канонический пример гонки данных: сервис возьмёт первый попавшийся код, который ему выдаст база данных, и отправит его сразу двум пользователям. В результате у кого-то из них промокод не сработает. Чтобы это исправить, надо синхронизировать процесс и использовать специальные решения: транзакции или сервисы распределённого консенсуса.
3. Оценить, сколько серверов понадобится, и рассказать, как именно вы эту оценку делаете. Можете ли вы представить, сколько у вас в запросе будет данных, какая будет нагрузка, понимаете ли вы, как работают кодировки и сколько символов помещается в тот или иной запрос.
4. Порассуждать вслух: спрогнозировать нагрузку и количество запросов, которые вы сможете обрабатывать в секунду, дать верную оценку можно только исходя из опыта.
5. Рассказать, как всё это задеплоить и заставить корректно работать. Многие кандидаты говорят, что надо арендовать сервер и развернуть Docker Compose. И им задают следующий вопрос: «А что делать, если завтра ляжет сервер или сам сервис?» Так интервьюер смотрит, умеет ли соискатель решать проблемы, был ли у него релевантный опыт. В зависимости от опыта, человек может предложить разместить сервис в Kubernetes, сделать геораспределение, геошардирование данных. Или использовать AnyCast, например, чтобы запросы на конкретный IP-адрес шли в ближайший дата-центр. Решений может быть много. Вопрос в том, знает ли кандидат о них.
Собеседование с командой. Это последний этап, на котором надо рассказать о себе, понять, насколько у вас получится найти общий язык с командой, есть ли совпадение по культуре. Скорее всего, вас спросят, какие задачи вы раньше решали и как они коррелируют с процессами в команде «Яндекса».
Читайте также:
- Как разработчик на С++ превратил свой пет-проект в прибыльный стартап
- Водородная бомба вместо «Hello, world!»: как и для чего придумали первую ЭВМ
- Горячие клавиши в VS Code
Гайд по Яндекс.Документам: функции, возможности, преимущества и недостатки
Яндекс.Документы — это виртуальный сервис для командной работы — аналог Google Docs и Microsoft Office Online с бесплатным доступом. В сервисе можно создавать новые файлы, загружать и редактировать готовые документы, таблицы и презентации.
Функции Яндекс.Документов максимально приближены к функциям стандартного документа Microsoft Word, в сервисе работают те же комбинации горячих клавиш.
В статье говорим о возможностях сервиса и даем инструкцию, как работать в Яндекс.Документах, и бонусом таблица с полезными горячими клавишами.
Возможности сервиса Яндекс.Документы
Пользователи программы могут создавать текстовые документы, таблицы и презентации, загружать файлы из Диска и с компьютера, а также совместно редактировать созданные файлы. Работать можно онлайн или без доступа к интернету.
Для групповой работы аккаунт в Яндексе не обязателен. Но если вы хотите самостоятельно создать файл и подключить к нему коллег, придется сначала создать аккаунт.
В онлайн-сервисе можно работать на персональном компьютере или смартфоне через прямую ссылку docs.yandex.ru, браузер или другие сервисы.
Приложение открывается из Яндекс.Почты, Яндекс.Диска, Яндекс.Телемоста и виртуального рабочего пространства Яндекс 360, в котором хранятся все эти персональные сервисы.
Мобильного приложения для работы в Я.Документах нет, на смартфоне сервис открывается также через Яндекс 360.
В Яндекс.Документах можно редактировать файлы большинства расширений: docx, xlsx и pptx. Система сама переводит устаревшие документы в совместимые.
Перечень всех открываемых форматов указан в Яндекс.Справке.
Яндекс.Документы внешне похожи на стандартный редактор MS Word, потому что сервис — это адаптированное кроссплатформенное приложение «Р7-Офис», которое работает на базе ОС Windows, Linux, Mac OS. Оно сконструировано на пакете OnlyOffice, принадлежащем Windows.
Читайте также: 9 полезных приложений для тайм-менеджмента
Как работать в Яндекс.Документах?
Рассмотрим пошаговую работу в Документах: создание файла, форматирование и настройка совместной работы.
Создание документа
Чтобы создать текстовый файл, нужно выбрать в меню «Новый документ», придумать файлу имя и нажать «Создать».
Чтобы создать таблицу и презентацию, нужно открыть левое меню: щелкнуть на желтую кнопку «Создать» и выбрать необходимое.
Чтобы загрузить файлы с Яндекс.Диска или компьютера, нужно нажать «Открыть из Диска» или черную стрелку справа — для загрузки с компьютера.
В десктопной версии еще можно перетащить файл в окно с недавними документами. На экране появится рамка загрузки с соответствующей надписью.
Работа с документом
Все функции приложения представлены в горизонтальном и вертикальных меню, расположенных вокруг рабочего окна.
Меню Яндекс.Документов состоит из нескольких разделов — файл, главная, вставка, макет, ссылки и блок для совместной работы.
Задачи, которые решают пункты меню:
- Файл — для создания, открывания, размещения на странице, сохранения и печати документов.
- Главная — для изменения параметров выделенных объектов.
- Вставка — для добавления графических объектов и текстовых элементов.
- Макет — для добавления полей, изменения ориентации на странице, настройки колонок и разрывов.
- Ссылки — для добавления оглавлений и сносок.
- Совместная работа — для командной работы над файлом.
Веб-версия внешне похожа на десктопную, но адаптирована под мобильный формат: иконки скрыты в компактном меню. Есть кнопка редактирования текста и всего документа, функции отмены действий и совместной работы.
Управление шрифтами
Этот раздел со шрифтами регулирует название, тип начертания, размер, цвет надписей и выделений, регистров, верхних и нижних индексов.
Документ будет выглядеть интереснее, если изменить стиль оформления или добавить выделения. Для этого нужно выделить фрагмент текста и выбрать иконку на панели инструментов.
Пользователи ускоряют работу в сервисе с помощью горячих клавиш:
- CTRL+B — полужирный.
- CTRL+I — курсив.
- CTRL+U — подчеркивание.
- CTRL+[ — уменьшить шрифт.
- CTRL+] — увеличить шрифт.
Читайте также: Как выбрать правильный шрифт для своего лендинга?
Оформление текста
По умолчанию текст в документе выравнивается по левому краю. Другое выравнивание можно найти в ленте на вкладке «Главная» либо можно использовать горячие клавиши.
Для этого выделяем весь текст с помощью CTRL+A и используем комбинации:
- CTRL+L — по левому краю.
- CTRL+R — по правому краю.
- CTRL+Е — по центру.
- CTRL+J — по ширине.
В этом же разделе «Главная» можно настроить буллиты и цифры для списков, междустрочные интервалы, выравнивания и заливки абзацев.
Как и в программе Microsoft Word, можно отобразить непечатаемые символы (все знаки), чтобы найти лишние пробелы и отступы. Это кнопка ¶ в ленте или команда CTRL + SHIFT + *.
Еще можно выбрать стиль текста. Для этого нужно нажать на кнопку дополнительных параметров справа и выбрать стиль или создать свой новый.
Вставка элементов
Пользователи могут добавлять в документ разные элементы — иллюстрации, фотографии, таблицы, диаграммы, фигуры, ссылки, уравнения и отдельные символы через панель инструментов «Вставка».
«Пустая страница» и «Разрыв страницы» (или CTRL+ENTER) добавляют пустую страницу. «Разрыв раздела» добавляет разные разделы для разного форматирования в одном документе. «Разрыв колонки» — разбивает текст на разные колонки.
«Титульной страницы» с готовыми шаблонами обложек, как в MS Word, здесь нет.
Выпадающее меню «Таблицы» помогает создать или нарисовать таблицу.
Таблица создается в Яндекс.Документах тремя способами:
- Графическим инструментом из меню.
- Кнопкой «Вставить таблицу» — указывается количество столбцов и строк вручную.
- Кнопкой «Нарисовать таблицу» — настраивается разное количество ячеек в строках.
Для редактирования таблиц есть отдельная вкладка «Дополнительные параметры таблицы». Она вызывается при нажатии правой кнопкой мыши по выделенной таблице.
Вставить таблицу из Яндекс.Таблиц через кнопку нельзя. Инструмент добавляется через копирование и горячие клавиши — CTRL+C и CTRL+V.
Иллюстрации и ссылки вставляются аналогичным образом.
Читайте также: Mind map, или интеллект-карта: что это такое, как и где ее создать?
Совместная работа
Для групповой работы над файлом есть отдельная вкладка.
Чтобы начать, нажимают кнопку «Режим совместной работы» и выбирают способ работы:
- В быстром режиме пользователи могут редактировать документ онлайн. Система сохраняет корректировки автоматически.
- В строгом режиме люди сами решают какие изменения сохранять. Система запомнит корректировки, если пользователь нажмет кнопку «Сохранить».
Сохраненные файлы хранятся на Диске.
Дополнительные инструменты
Вертикальное меню в левой части экрана упрощает работу с файлом:
- Поиск. Система ищет текст по всему документу и может заменить его при необходимости. Активируется CTRL+F.
- Комментарии. Через специальную форму пользователи комментируют текст в файле. Активируется CTRL+SHIFT+H.
- Навигация. Ищет информацию по заголовкам. Пользователи могут быстро перемещаться по объемному тексту с помощью заголовков.
- Обратная связь. При нажатии на кнопку активируется онлайн-форма для связи с техподдержкой Яндекса.
- О программе — справочный блок с информацией о разработчике.
В Яндекс.Документы встроена защита от случайного удаления информации, как в Gogole Docs. Действия пользователей сохраняются в истории изменений. При необходимости их можно отметить, выбрав одно из прошлых сохранений.
Для этого нужно кликнуть на три вертикальные точки рядом с файлом в интерфейсе Документов и выбрать История изменений.
Права доступа
Чтобы совместно работать над файлом, нужно отправить ссылку на файл и установить параметры доступа — посмотреть или отредактировать. Настраивать разные права доступа для разных пользователей пока нельзя.
Предоставить доступ можно двумя способами:
- непосредственно в открытом документе, или
- в интерфейсе Документов.
В первом случае используют кнопку вверху экрана «Настроить доступ».
Либо можно в интерфейсе выбрать документ → нажать на три точки в правом верхнем углу → выбрать «Настроить доступ».
Иногда дать доступ редактирования не получается. Причина — в использовании устаревшей версии редактора или файла:
- Если проблема в редакторе старой версии без функции совместного редактирования, нужно закрыть вкладку с файлом, обновить страницу и попробовать поделиться доступом еще раз.
- Если проблема в устаревшем формате файла — DOC, PPT, XLS, нужно создать копию документа в новом разрешении и работать в нем.
Еще одна причина — владелец папки, в которой хранится файл, не обновил редактор. Если он использует устаревший сервис, пользователи не смогут полноценно в нем работать. Нужно попросить право на редактирование страницы у владельца папки.
Читайте также: Как создать идеальное руководство по фирменному стилю
Горячие клавиши Яндекс.Документов
Собрали самые популярные горячие клавиши в одной таблице.
Выделить весь документ
Выравнивание текста по левому краю
Выравнивание по правому краю
Выравнивание по центру
Выравнивание по ширине
Отображение всех знаков (непечатаемых символов)
Вставка пустой страницы
Копировать и вставить
Поиск в документе
Читайте также: Что такое Рунет: история и особенности части Интернета
Преимущества и недостатки Яндекс.Документов
Яндекс.Документами удобно пользоваться. У них понятный интерфейс, бесплатный функционал, есть возможность работать самостоятельно или в команде, а также синхронизировать программу с Яндекс.Диском и другими сервисами.
Программа совместима со всеми файлами, имеющими расширение MS Office. Вкладки удобно переключать, иконки адаптированы под привычный формат Word, при наведении появляются уточняющие надписи.
В отличие от Google и MS Office для работы в Яндекс.Документах нужно меньше всего оперативной памяти — около 100 Мб. У Google Docs такой же файл занимает больше 500 Мб.
Есть подробная справка, описывающая работу с основными функциями сервиса.
Кроме того, в Яндекс.Документах можно работать в офлайн-режиме. При работе без доступа к Интернету изменения вносятся автоматически после подключения устройства к сети. Софт предупредит о потере соединения после того, как переподключится.
Главный минус Документов — недостаток функций:
- Нет готовых шаблонов.
- Нет мобильного приложения.
- Нет встроенного перевода.
- Нельзя ограничить доступ к файлу, разрешив оставлять комментарии, как в Google Docs.
- Мало встроенных шрифтов, нельзя встраивать сторонние начертания.
- Неудобно расположена функция поиска — в левом меню. Если не знать, где она находится, могут возникнуть сложности.
- Нет дополнений и расширений. В Microsoft и Google есть специальные магазины, в которых можно скачать расширения, добавляющие шрифты, создающие документы из заметок и т. д. В Яндексе такого нет.
- Плохо работает автосохранение. Если печатать в документе и резко закрыть браузер, последние изменения не сохранятся.
Для сложных аналитических задач Яндекс.Документы не подходят. Нельзя сделать сводную таблицу или провести АВС-анализ. Но можно выполнить сложную задачу в любом другом документе, а затем загрузить его в Облако.
С решением повседневных задач Яндекс.Документы отлично справляется.