установить slack ubuntu

В общем, пробовала из официального установщика - не получилось, пробовала скачать пакет и как обычно кликнуть пару раз, потом нажать install - тоже не получилось. Синаптик тож не сработал. Но русские ж не сдаются)

Пришлось через терминал, угу.
В общем, сначала перешла в папку, где лежит слак с помощью команды
cd путь к папке со слаком.
Потом ввела 
sudo dpkg -i   slack-desktop-2.8.2-amd64\ \(1\).deb

Верней хз, как это действует, надо будет потом погуглить, но я подсмотрела, что можно нажать пару раз TAB, оно само подсказывает. Я ввела
sudo dpkg -i   и нажала 2 р. TAB - он мне подсказал шо нужно.

С первого раза у меня не получилось, поэтому я сделала
sudo apt-get install -fy
Это я тоже подсмотрела, как ребята делали, я так поняла это "force yes".
Типа даже если шо-та не так с зависимости, проигнорить это и все равно установить. Помогло :)
После этой магической строчки снова попыталась установить слак и на этот раз успешно :) Я счастлива :)

mysql

SQL phrase stands for Structured Query Language. 

CREATE DATABASE gregs_list; - создать БД с именем таким-то.
Query OK, 1 row affected (0.01 sec) - сообщение от РСУБД о том, что запрос был успешно выполнен.

 USE gregs_list; - мы кагбэ приказывает РСУБД, чтобы она использовала только что созданную БД.
Теперь все последующие операции будут выполняться с БД gregs_list.



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

 BLOB - Binary Large OBject.

javascript, dom

Мы меняем внутреннее содержание объекта с помощью innerHTML, его атрибуты можем менять, а стили мы всегда меняем с помощью вложенного объекта style.
Смысл заключается в том, что мы меняем события и дотягиваемся до определенных свойств объекта, чтобы поменять их так, как нам нужно. 

Запустить в консоли mysql

Вот захотелось мне по трешачку, не через графическую оболочку запустить mysql, а в консольке. Шо-та тупила долго, но потом поняла.

Сначала переходим с помощью команды cd в папку, где лежит экзешник.
У меня это был:
C:\Users\Fedor>cd C:\Program Files\MySQL\MySQL Workbench 6.3 CE
Потом, собственно, пишем сам имя файлика, который надо запустить:
MySQLWorkbench.exe

Оно откроет графическую оболочку, я закрыла и проигнорила.

Потом, чтобы попасть вовнутрь, мы пишем:
mysql -u root -p
вводим пароль

Выпадает откэ, как я понииаю, саксесс:

DB, mysql

Структура SQL.

Контейнер, в котором хранятся таблицы и другие структуры SQL для работы с ними.

БД состоит из таблиц.

Таблица - структура, в которой хранятся данные, упорядоченные по столбцам и строкам.

Столбец (или поле) - фрагмент данных, хранящихся в таблице.

Строка (или запись) - набор столбцов, описывающих атрибуты одного объекта.

Столбцы и строки образуют таблицу.

Т.е., например, сначала инфа о каждом человеке разделяется на категории.

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

Категории = столбцы.

selenium

Selenium - драйвер для браузера. Он (Селениум) позволяет другим програм взаимодействовать с браузером.
Чаще всего этими другими прогами являются тесты. Но можно юзать и для других целей, например, пройтись по всем страницам веб-приложения и поснимать скриншоты, например, для документации.

Драйвер предоставляет некоторый набор команд, который соответствует некоторым функциям устройства, в нашем случае - браузера.
Что должен уметь драйвер для браузера?
- Запускать браузер.
- Открывать в нем какие-то адреса.
- Находить ссылки или др. элементы.
- Выполнять действия с этими элементами (например, кликать по ссылкам).
- Останавливать, чтобы освобождать ресурсы.

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

Но юзеры хотят писать на разных ЯП. Поэтому в дополнение к различным реализациям драйвера для разных браузеров, сущесвтуют и разные реализации интерфейсов для разных ЯП.
(Java, Ptyhon, Ruby, Java Script, C#).

Для каждого браузера нужен свой вспомогательный веб-файл.

Каждое веб-приложение можно условно разделить на 2 части:
1. Веб-сервер, где реализуется какая-то логика, БД.
2. Браузер - графический юзерский интерфейс к этому приложению.

Браузер и веб-сервер взаимодействуют по протоколу http. Браузер отправляет запрос, сервер его обрабатывает и отправляет обратно ответ. Этот ответ содержит какую-то инфу, которую браузер использует для визуализации. Показывает юзеру какие-то кнопки, ссылки, формы, текст и т.д.

Чтобы тестировать серверную часть приложения, браузер не нужен. Его можно заменить http-клиентом, т.е. библиотекой, которая умеет отправлять запросы по протоколу http и получать ответы.
Такие клиенты существуют для разных ЯП, они не имеют юзерского интерфейса, только программный интерфейс, т.е. API.
Иногда это норм, не очень и нужна графическая оболочка.
Но в современных условиях в браузере может быть частична реализована логика приложения. Т.е. данные частично обрабатываются на сервере, частично в браузере. Ну, и юзерский интерфейс становится более сложным и динамичным и его тоже нужно тестировать, как вручную, так и при помощи автотестов.
Причем ща юзерский программный интерфейс становится таким сложным, что страница браузера обновляется не целиком, а частично.
Если раньше по нажатию на ссылку или кнопку, на сервер отправлялся запрос, в ответ приходила целая страница целиком и браузер ее отображал, то ща ситуация поменялась.
Например, юзер начинает вводить текст в поле ввода и на каждое нажатие клавиши, браузер реагирует отправкой запроса на сервер, сообщает, какие буквы уже ввел и сервер предлагает в ответ, какие варианты продолжения введенного текста.
При этом вся страница полностью не обновляется, сервер не присылает готовую страницу, он присылает только маленький кусочек данных, который используется для того, чтобы показывать различные варианты продолжения. Обновляется только маленькая часть страницы. Вот такое поведение сложно сэмулирвоать на уровне протокола http, гораздо проще сделать в браузере.
Необходим инструмент, который это делает в браузере - искать элементы и совершать с ними некоторые действия.
Дальше клево описывается, что т.к. в браузере js, то надо выполнить 4 основные задачи:

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

3 способа: внедренный, сзади, спереди, ыы.
Если заранее внедрить все в браузер. Это делается с помощью расширений.
1) Внедрение ок. Юзер установил разрешение - и все.
2) Как отдавать команды браузеру? Нужно сценарий, который отдает команды, тоже внедрить внутрь браузера. Так и работает Селениум.
Сценарий загружается в определенное отдельное окошко браузера, там нажимаем "выполнить" и он выполняется. Все происходит внутри.
Можно и другим способом - отправлять команды этому введенному js-коду по сети. Для этого необходимо внутри браузера запустить маленький веб-сервер, написанный на языке js и снаружи отправлять команды этому веб-серверу, он будет их принимать и исполнять. Т.е. внедряется масенький сервер, который принимает команды по сети.
3) Если мы внедрили js-код как расширение, это означает, что он работает в специальном привилегированном режиме. Те ограничения, которые накладываются на работающий код внутри страницы, для дополнения расширений не распространяются.
4) Фейл.
Например, если загрузить файл с сервера, появится окно, предлагающее "сохранить файл на локальный диск" и с этим окном ничего сделать нельзя. Через js этим окном управлять не получается.
"-" - схема не универсальна. Механизмы создания расширений для браузеров отличаются друг от друга.

2. Сзади.
Внедрение там, где веб-сервер взаимодействует с браузером. Запросы, которые отправляются на сервер и обратно, можно перехватить инструментом "Прокси". И когда от сервака идет ответ, можно внедрить в него какой-то нужный нам js-код. Т. о. код попадает на страницу и работает внутри браузера. Это юзается в инструменте Сахи (аналог Селениума).
1 - ок.
2 - ок.
3 - код внедряется на страницу, т.е. он работает в непривилегированном режиме с максимальными ограничениями безопасности. В частности очень сложно становится работать с фреймами, если они загружаются с разных сайтов. В этом случае браузер старается их максимально изолировать друг от друга. Даже  Если на хорошую страницу загрузится какой-то вредоносный фрейм, он не сможет на ней ничего сделать.
Если все происходит в рамках одной страницы, то никаких проблем не возникает.
4 - действия, недоступные через js, остаются недоступными.

3. Спереди.
Большинство современных браузеров предоставляют тот или иной интерфейс для управления или для отладки, которым можно воспользоваться, в частности, для внедрения какого-либо js-кода или выполнения этого кода в браузере, как на странице, так и в привилегированном режиме.
Т.е. в том же режиме, в котором работают дополнения.
1 - ок.
2 - ок.
3 - ок. Можно получить доступ и к страницам, и даже к самому браузеру.
4 - иногда можно сделать те действия, которые не доступны через js.

Унификация.
Разные браузеры предоставляют разные интерфейсы для удаленного управления и отладки. Они содержат похожий набор команд, но технически для каждого браузера это сделано по-разному.
Для хрома - это remote debug.
Для ФФ -  marionette.
ИЕ - можно через ком-интерфейс. COM API.

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

Например, для хром есть исполняемый файл chromdriver, который наружу предоставляет интерфейс Селениум, а внутри взаимодействует через remote debug.

FF - geckodriver.

IE - IEDriverServer.

XML, пространства имен

Я придумываю и ограничиваю себе область действия.




компаундный - составной.

Грубо говоря, у любого тега, у любого элемента имя кагбэ состоит из двух частей:
локальное имя (то, что мы видим)
пространство имен (типа, как папку создали. Аналогия с одинаковыми файлами, но в разных папках, с учетом всего пути к файлу)

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

Если у нас это имя нарицательное, то надо начать с urn, например:

urn: urn:schemas-microsoft-com:xml-data

Но такое используется редко. Только для общеизвестных вещей. Т.е. типа майкрософта.
Для 90 случаев из 100:
В качестве имени пространства имен используется имя своего сайта, он же уникальный. Сразу видно кто это и что это.
URI - uniform resource identifier.
Это универсальный идентификатор пространства имен, может URL - uniform resorse locator или URN - uniform resource name.
Имя лучше начинать с urn: - показывать, что это просто имя.
url - спорный момент. Это указатель, адрес. Если адрес указывает на несуществующий файл (в вебе - битая ссылка), это неправильный url.
Пространство имен - не совсем url. Т.е., грубо говоря, когда прога-анализатор читает наш файл, она никуда не лазит, никуда на эти ссылки не смотрит близко, это просто строка текста, похожая на url.
Т.е. это не для машины, это для людей. Это не обязательно ссылка на существующий сайт.
Очень часто, особенно для промсистем, именем пространства имен действительно является ссылка на сам стандарт (описание стандарта), либо его схема. Типа, правило хорошего тона, народ туда пойдет и посмотрит.

Это по сути уникальная строка текста. Просто, чтобы ее сделать уникальной, для этого мы и пишем http://www.speciailist.ru/course/xml/lab1 - типа, шоб замороченно. Анализатор туда не лазит. Можно туда че угодно зафигачить, но лучше свой сайт.
Это декларативная штука.

2 способа обозначить пространство имен:

Способ 1.

Прямое (глобальное) объявление.
В XML нет ни одного тега или атрибута, обладающего семантикой, кроме одного xmlns.
xmlns - атрибут.
Юзать xmlns - xml name space.

Когда мы пишем любой элемент, любой тег, мы можем сказать xmlns = имя пространства имен. Имя самого пространства, не тега. Т.е. мы назначили, привязали - этот элемент из того пространства имен.

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


Вот пример кода, когда мы на всю доку делаем одно пространство имен, а элементу 'exists' прописываем другое пространство имен.




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

Что такое xhtml?
Это html, записанный синтаксисом xml. Ну, выбросили пару тегов. Не добавили ни одного тега.
В нем появилось пространство имен.
Т.к. они говорят, мол, мы придумали стандарт, но это xml.
xhtml - это прежде всего XML.
Все теги, да, у них есть семантика, это мы придумали, это не ваши теги, у них пространство вот такое.
Тайтл из пространства имен xthml. У него его анализатор может накладывать семантику. Т.е. отличит его от тайтла лессона.

К xhtml применимы все XML-технологии: xpath, трансформаторы.





Способ 2.

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

С помощью префикса.
Т.е. мы кагбэ вот эту длинную строчку с уникальным именем (который адрес сайта) как-то называем, желательно осмысленно, например, html.
Потом мы просто перед каждым придуманным нами тегом пишем это короткое название, двоеточие и тэг.
Как в этом примере:


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

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

Остальным придумать названия ну, и писать их в нужных тегах.

Единственное, из той картинки, которая выше, не совсем поняла логику. Там тег <a: data xmlns = ...> - типа присваивается пустое пространство, которое, есичо, потом будет дефолтным, но там вначале стоит a: Т.е. сам этот тег относится к пространству имен "а", который еще не прописан (он прописан ниже). Т.е. здесь, похоже, препод забыл убрать присваивание "а" этому тегу.

Вот здесь уже кошерный пример:




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


Все эти вещи - стандарты и все остальное. Т.е. мы хотим получать данные извне. Наша информационная система берет данные и выполняет с ними определенные операции в XML, например, добавляет их в БД или получает. Файл может уйти в неправильном виде: не тот, не той версии, с ошибками. Наша задача - его проверить. Это то, что мы ждем или не то.

Здесь возникает необходимость программной обработки и программной валидации.
У любого XML-документа есть два вида: в его форме - ненарушении синтаксиса (анализатор это проверяет и без нас). И правильность документа.

XML, continuation

Юникод
Винда поддерживает юникод с 98 версии, с 2000 и далее изначально работает на юникоде.
Юникод - абсолютно универсальный способ кодирования текста.
Он позволяет помимо стандартных символов, представлять почти любые шрифты любого языка, спецсимволы, спецграфику и т.д.
Юникод один, но у него есть множество способов кодирования. UTF - способ кодирования.
Например, вот эта цифорка 8, 16 - показывает сколько минимум бит на 1 символ.
Когда мы в UTF-16 - 1 буква либо 2 байта, либо 4 байта.
UTF-8 - 1, 2, 3, 4.
UTF-16 считается, что быстрей обрабатывается, потому что 1 буква четко ложится на машинные слова. Но он неэкономичен.
Для большинства букв первый байт чуть ли не нулевой. Если 1 буква по 2 байта, часто компромисс UTF-8.
В этом случае символы переменной длины. Обработка более сложная, т.е. у него есть таблица.
Если байтик начинается с этого, то это однобайтовый. Если с этого, то двухбайтовый. Если с этих 5, то трехбайтовый и т.д.
Трабла в том, что анализатор должен каким-то образом понять, какую кодировку мы используем.
Хорошо, в XML это указано. А в блокнотике. Когда нажимаем "Сохранить как", там можно выбрать.

ANSI - American National Standard Institute - это однобайтовый. Он разработал ASCI, телетайп. 1 буква - 1 байт.
Юникод - стандартный для ОС.
Когда 16 и 32.
В каком порядке идут байты?
В прямом: старший, средний, младший? Или в машинном: младший, средний, старший?
Может быть стандартный и обратный. 2 разных способа кодирования юникода. Т.е. для каждого больше, чем 1 байт, еще и 2 способа представления.

Нужно каким-то образом просто блокноту подсказать, какой способ кодирования использовался.
Понятие BOM (bite order mark) - метка порядка чередования байтов. Это метка представления кодировки юникода.
В типографике примерно с десяток пробелов: узкий, широкий, неразрывный, с переносом и т.д.
Есть, например, неразрывный непечатный пробел. Он невидимый, но он предназначен для разделения многосложных слов. Автоваз.
Начните свой файл неразрывным непечатным пробелом, т.к. в любом способе кодирования юникода он будет по-разному представляться, но сама прога знает как и поймет, какую кодировку мы использовали.
Вот этот первый символ, как я поняла, показывает какую кодировку мы использовали. В юникод UTF-8 - представляет собой 3 байта. (Ага, если пустой блокнотик сохранить, а потом посмотреть свойства, там будет значитсья 3 байта. Если в 16, то 2 байта).
Т.е. мы еще ничего в блокнот не писали, а там уже содержится этот BOM.
В юникс-системах нет бома, там тока UTF-8.
Там, где юзается ВОМ, сразу понятна, какая кодировка была использована.

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

XML позволяет представлять любые данные. Это может быть обмен данными на предприятии.
Это Business-to-Business E-Commerce. Различные представления данных.


XML дает нам уровень синтаксиса. И уровень грамматики и уровень семантики мы придумываем сами.


Жесткие правила. Парсер читает документ, если находит ошибку, отказывается от его обработки. Первый уровень правильности - well-formed document - все синтаксические правила XML.



т.е. можно так:
<author id="1"> Pushkin</author>
<desc id="123">
</desc>

А вот так нельзя:
<author id="1" id="123"> Pushkin</author> т.е. 2 раза употребить атрибут id в одном теге.
<desc id="3">
</desc>

well-formed - это первый уровень проверки.
второй уровень - это если он соответствует своей грамматике.

XML

XML - способ представления структурированных данных. Ну, чтобы с ними было потом легче работать.
Язык разметки - разделение данных на составные части.
HTML - не абстрактные данные, а просто html-страничку.
У всех ЯР - один "-". Они не универсальны.
XML - постарались сделать универсальный, расширяемый язык разметки данных.
Он не один - это типовой стандартный ЯР, представленный Web3org. Есть параллельные стандарты.
Например, для передачи данных  - json or YАML.
Extandable Markup Language - XML.
1. Ща XML - абсолютно универсальный ЯР данных, расширяемый.
2. Независимость от платформы, ОС и программ обработки.
3. Позволяет сохранять структуру у метаданные, обязательную инфу о том, что мы собираемся сохранить, передать, перетащить. Т.е. представление произвольных данных и дополнительный метаинформации.

Прайс-лист, платежка, которую мы отправляем - это данные.
XML - документ, базирующийся стандарт. У XML - ед. измерения, квант - это документ, просто готовый документ.

Документ может содержать:
- данные (просто текст). Типа, просто текстовый документ, блокнотик. Ща уже никто так не пишет, никто не пишет в блокнот.
- структура. Нужно структурирование. Что мы предлагаем, кто мы такие и т.д. Главы, подглавы, разделы, подразделы и т.д.
- представление. То, как мы его увидим на экране или принтере.

HTML - описание довольно примитивной странички, много уступающего тому же верду.
XML - тут нет уровня представления. Описывает ТОЛЬКО ДАННЫЕ И ТОЛЬКО ОТНОШЕНИЯ.

Как отобразится это на экране браузера? Вопрос не имеет смысла.
Т.е. это мощный язык, более абстрактный, этажом выше. XML - абстракция, но она расширяемая.

XML использует для разметки тэги, метки.
Тег - это сам тег.
Элемент - это тег и элемент.

Элементы могут быть вложенными.

Синтаксис - правила записи элементов разметки.
Грамматика - отношения элементов разметки друг к другу.
Семантика - смысловые значения элементов.

Чем отличаются теги HTML? По смыслу.
<b> и <strong> - разный смысл. Один жирный, а другой сильный, важный.
<p> и <div>
в <p>  не может быть внутри другого параграфа, заголовка, а в <div> division - раздел, сколько угодно подразделов и заголовков, таблиц.

В XML - нет семантики и грамматики. Ее не на чем строить. Тэгов там 0 или бесконечное количество.

Есть только синтаксис.

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

DTD - это и есть схемы. Мы кагбэ декларируем, что отныне и впредь, все кто будет пользоваться моим языком, вот его грамматические правила. Это для валидации. У нас появляется смысл.

Любой XML-документ состоит из пролога или декларации.
Что такое пролог?
Это начало доки.
<?xml version="1.0" encoding="windows-1251" ?> - декларативное.
<? - это для обработки.
<?format drive="c"?> - процессинговые инструкции, т.е. инструкции по обработке доки. В доке могут быть не сами данные, а объяснения что с ним надо делать.
Например, перед прочтением сжечь - формат диск С.

<?xml version="1.0" encoding="UTF-8"?> - пролог
<?format drive="c"?> - что с ним надо сделать
<data> - данные самого документа
</data>

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

Т.е. в самом доке мы пишем не только данные, но и инструкции что с ними надо делать. Это и есть пролог доки. Т.е. то, что предшествует самим данным. Тут еще и декларация самой доки.

В сам док могут входить комментарии. Это неанализируемая часть текста. Они могут иметь такой же смысл, как и тэги и реально анализироваться прогой.
<!-- Это комментарий --> . НЕЛЬЗЯ <!-------------------- -->
! - декларирую коммент.
Можно зафигачить в комментарий половину разметки, это легко. Главное - не 2 минуса подряд. Т.е. можно сделать так:
<!--
<data>

</data>--> - так очень удобно отсекать часть текста.

Правила:
1. Любой элемент регистрочувствителен.
2. Элементы могут содержать подчеркивания, точку, дефис. Ну, и буквы и цифры.
3. Не допускается пробел.
4. Имя элемента всегда начинается с буквы.
5. По определению нет одиночных тегов. Любой тег должен быть закрыт.
Бывает необходимость придумать такой тег, где по смыслу никогда не будет содержимого. Например, как <br> в html.
В этом случае можно написать так: <exists />
Т.е. вместо
<exists> </exists> можно написать:
<exists />
Это просто сокращение, абсолютно идентичные записи.
Т.е. когда анализатор их обработает, он их покажет одинаково.
У тегов могут быть сколько угодно любых атрибутов. 
Атрибуты мы тоже придумываем сами. Значение атрибутов всегда обрамляется двойными кавычками.
<price currnency="RUR">200</price>
Но некоторые анализаторы, парсеры, допускают вольность. Например, писать одинарные кавычки вместо двойных. Или где сокращенный тег, писать без пробела перед слешем, т.е. не так: <exists />, а так: <exists/>. Но по стандарту - двойные кавычки и пробел перед закрывающим тегом, там, где мы его сокращаем.

Единицей обработки в XML является 1 документ. Обрабатывается 1 документ.
Забегая вперед, есть еще фрагмент, но об этом потом.
Документ - это один элемент. Всегда. Т.е. 1 тег.
Он называется рутом, корнем, элементом документа.
У любого дока всегда будет 1 тег.
Т.е. 1 тег верхнего уровня.

В этом доке - это элемент <pricelist>.

Как нарисовать пустой документ?
<doc /> - вот так.


Что отличает от HTML
- процессинг
- секции CDATA

Грубо говоря, мы сказали, что XML работает с данными. В чистом исходном XML данные только одни - текст.
Т.е. дока состоит из элементов, в которых могу находиться текстовые данные. Например, имя автора.

Программа-анализатор рассматривает любые данные как PCDATA - Parced Character Data. Т.е. когда анализатор выискивает наши теги, он то, что у них внутри, он рассматривает как парсируемые (анализируемые) текстовые данные.

В XML мы не можем записать в тексте a > b. Это запрещенный символ.

3 запрещенных символа:
1. <
2. >
3. &

Чтобы эти теги заменить, мы используем сущности, но об этом потом.

Если очень надо, то тут появляется CDATA - Character Data, не parceble, т.е. непарсируемые, необрабатываемые и неанализируемые текстовые данные.

Здесь есть специальная конструкция, которая показывает, что здесь просто текст от сих до сих и ничего с ним не надо делать.
Это все запиливается внутрь такой шняги:
<![CDATA[
         PCDATA CDATA a > b &
  ]]>

Здесь можно больше, меньше и амперсанд. Анализатор перестает обращать на него внимание.

Вот нормальная картинка:

Кодировка юникод

Почистить куки локально

На том, сайте, где мы хотим почистить, нажать F12, откроется Developoer Tools.
Там слева сектор Storage
Нажать Local Storage, в дереве выбрать этот магаз, там ПКМ - clear.
Ну, и с куками сделать ту же процедуру. Они находятся чуть ниже)
Саксесс)

Создать сразу много мыл. Друг подсказал mail.ru.

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

Разрешения на разные модели

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

Apple iPhone 4 (4, 4S)     iOS     3.5     8.9     640     960     320     326     200% XHDPI     2:3

Apple iPhone 5 (5c, 5s)     iOS     4.0     10.0     640     1136     320     326     200% XHDPI     40 : 71

Apple iPad Mini     iOS     7.9     20.0     768     1024     768     163     100% MDPI     3 : 4

Apple iPhone 6     iOS     4.7     11.9     750     1334     750     326     100% MDPI     9 : 16

Apple iPhone 7+     iOS     5.5     14.0     1080     1920     1080     401     100% MDPI     9 : 16

Android     5.5     13.9     1920     1080     1920     401     100% MDPI     16 : 9     3:5

Sony Xperia Z4     Android     10.1     25.7     2560     1600     2560     299     100% MDPI     5 : 8

Apple iPhone X  5.8" 2436×1125 пикселей, 458 пикселей на дюйм  21:10 ориентировочно

ыва

https://mixpanel.com/trends/#report/iphone_models/from_date:-229,to_date:0 - открывать с впн, есичо.

Разрешения для стримов:

LOW(480, 270),

MID(640, 360),

HIGH(720, 405)

ыва

Отчеты по приложениям

Отчеты по iOS, Android, Backend.

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

Т.к. это все будет сейчас висеть на мен

Опишу здесь весь процесс генерации отчетов.
Итак, чтобы в джире найти все

project = WWWA and status in ( "waiting on uat", "waiting for qa assignment", "Done") AND Updated > "2017/09/25" ORDER BY updated DESC

Итак, разберем запрос:
Фильтры, по которым ищем:
project =
status in
updated >
order by

Ага, тут еще разные знаки
=, видимо, точное совпадение
in, видимо, место, где
>, видимо, после 25 сентября 2017 до текущего дня.
by, видимо, сортировать по апдейченным

Значения этих фильтров могут быть такие:
PROJECT, пока:
- project WWA
- project WIA
- project WWWA

STATUS IN:
Если ищем по нескольким параметрам, как я поняла, надо брать в круглые скобки и писать значения в кавычках.
Значения мы берем из джиры. Ща гляну какие там могут быть статусы. Угу, как я поняла, там у каждого типа (бага, дефект, таска и т.д.) разные статусы. Хз, так ли это.

В моем случае я пишу эти три:
- waiting on uat (user acceptance testing)
- waiting for qa assignment
- done

По идее в дефекте есть еще:
- in development
- waiting for QA assignment
- QA testing
- waiting on feedback
- waiting to start
- open
- move to backlog requested
- backlog
- re-opened
- closed
- request for close
- rejected
- waiting on uat
Не нашла здесь done. Хз, почему. Может, вообще эти все статусы не могут быть значениями, которые можно фигачить в БД джиры.

Ага, нагуглила манчик по JQL:

https://confluence.atlassian.com/jirasoftwarecloud/advanced-searching-764478330.html#Advancedsearching-ConstructingJQLqueries

https://confluence.atlassian.com/jirasoftwarecloud/advanced-searching-fields-reference-764478339.html

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

Updated > - сюда запиливаем дату.


ORDER BY updated DESC - DESC - descending order, т.е. по возрастанию.

Ага, вот такой запросик.

Потом мы делаем экспорт в Excel CSV (current fields).

Загружается CSV-табличка.

CSV (от англ. Comma-Separated Values — значения, разделённые запятыми) — текстовый формат, предназначенный для представления табличных данных.

Мы открываем эту загруженную табличку, делаем новую вкладку в этом же документе.
Переходим на новую вкладку.
В ней мы нажимаем на вкладку "Данные", там слева выбираем "Из текста".

Потом выбираем с компа ту же табличку, которая нам выгрузилась из джиры.
Выскакивает окошко "Мастер текстов (импорт)
Там мы убираем радиобаттон с "фиксированной ширины" и ставим его "с разделителями".

Потом отмечаем чекбокс, что "Мои данные содержат заголовки".
Нажимаем "Далее".
Потом убираем чекбокс "знак табуляции" и ставим "запятая".
Нажимаем "Далее".
Потом окошко оставляем по дефолту и генерим.
Появляется окошко импорта данных.
Там есть параметр "Имеющийся лист".
Ну, и там прописана ячейка, с которой будет вставлена таблица.
По дефолту !$A$1, т.е. A1, ну, с первой верхней левой ячейки.

$ - это абсолютная адресация, я так поняла, что чтобы зафиксировать какую-то фигню, надо будет потом еще погуглить на эту тему.