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


28.10.21

Урок 19. Мова гіпертекстової розмітки. Гіпертекстовий документ та його елементи. Текстові елементи веб-сторінки, теги та їх атрибути. Гіперпосилання

19.1. Мова гіпертекстової розмітки В 1989 році Тім Бернерс-Лі запропонував упровадити гіпертекстову систему документів. Наприкінці 1991 року він опублікував у Інтернеті перший загальнодоступний опис мови розмітки HTML — «HTML теги». Він же створив і першу програму для перегляду гіпертекстових документів — браузер. Бернерс-Лі розглядав HTML як похідну мову від SGML, і в середині 1993 року Спеціальна Комісія Інтернет-розробок (IETF) офіційно визначила її такою, опублікувавши першу специфікацію HTML. Наразі більшість веб-документів створюють за допомогою мови розмітки гіпертексту HTML (англійською Hyper Text Markup Language — мова розмітки гіпертексту). Призначення HTML — описати зовнішній вигляд документа за умови, що розміри екрану і масштаб подання тексту можуть змінюватися у процесі перегляду. Розширення (тип) гіпертекстового документа, написаного мовою HTML, — htm або html. 19.2. Гіпертекстовий документ та його елементи Гіпертекст - це текст, у який вбудовані спеціальні коди, що задають форматування тексту, наявність у ньому ілюстрацій, мультимедійних вставок та гіперпосилань. Ці коди визначені у мові програмування HTML - мова гіпертекстової розмітки. Веб-сторінка - це документ у форматі HTML. Процес вставляння в текст кодів HTML називають розміткою. HTML-файл — це програма подання тексту, написана мовою HTML, яку опрацьовує браузер і подає результат у своєму програмному вікні. Дескрипторами називають ті теги, які вказують на спосіб відтворення інформації програмою-браузером. Теги — вказівки HTML — записують у «кутових» дужках, утворених символами «<» і «>» — «менше» й «більше». Контейнери — це парні теги. Контейнери позначають початок і кінець області дії відповідної вказівки. Між цими тегами може міститися текст та інші теги. Тег, що закриває область дії, порівняно з тим, що відкриває, має додаткову косу риску одразу після «кутової» дужки. Oпис властивостей контейнера записують у першому дескрипторі контейнера через пропуск після назви контейнера або з нового рядка. Нечислові значення параметрів прийнято записувати у лапках. Для створення HTML-файлу можна використати найпримітивніший текстовий редактор. Наприклад, Блокнот (NotePad) для ОС Windows. Інколи, у середовищі цих редакторів здійснено виділення кольором дескрипторів. Наприклад, у середовищі Kate для ОС Linux Mint KDE. Хоча привабливішим видається використання спеціалізованих редакторів з поданням сторінки різними способами. Наприклад, редактора Kompozer чи Sublime Text. 19.3. Текстові елементи веб-сторінки, теги та їх атрибути Структура HTML-документа (згідно зі стандартом HTML 4.01). Оголошення типу документа (англійською Document type declaration, Doctype, DTD) — на початку документа тегом . Заголовок документа, розташований у межах контейнера , — містить опис загальних технічних відомостей або додаткову інформацію про документ, яку не відтворюють безпосередньо у браузері. Тіло документа, розташоване у межах контейнера або , — містить основну інформацію про опис документа. Структура HTML-документа Заголовок документа Змістовна частина документа Тег html вказує браузеру, що він опрацьовує HTML-код. Все, що розташовано між парними тегами і є HTML-документом. Атрибутом version можна задати версію HTML: ; Атрибутом lang можна задати основну мову документа, скажімо українську: . Назва документа — текст між тегами і . До тексту назви не застосовують форматування. Назва має бути короткою, інформативною і адекватно відображати зміст документа. У заголовку документа можуть міститися деякі важливі дані, які використовуються браузерами, але в більшості випадків не відображаються, — метадані. Для цього використовується елемент meta, який задають одинарним тегом з такими атрибутами: name — назва змінної; content — значення змінної; charset — кодування документа, наприклад utf-8; lang — код мови, що визначає мову значень змінної; http-equiv — вказує назву додаткового параметра. Атрибут lang потрібно використовувати для створення списку ключових слів певною мовою, на які відгукнеться пошукова система при запиті. Наприклад, англійською: Значення атрибута http-equiv та опис дії атрибута content (після тире): Expires — задає дату і час оновлення документа; Content-Language — аналог атрибуту lang тега html; Content-Type — вказує тип документа та кодування символів; Refresh — задає інтервал у секундах між оновленнями вмісту документа. Приклади опису властивостей тега body: bgcolor="white" — задати білий колір тла; text="black" — задати чорний колір тексту; background="picture.jpg" — задати зображення для тла; bgproperties="fixed" — зображення тла не прокручувати; style="text-align:justify;" — вирівнювати текст за шириною. Крім цих атрибутів тега body використовують і такі: link — колір невідвіданих гіперпосилань; vlink — колір відвіданих гіперпосилань; alink — колір гіперпосилань, обраних користувачем; contenteditable — дозвіл (значення true) або заборона (значення false для елемента body або inherit для усіх інших елементів) користувачу редагувати HTML-документ у браузері. Для введення в HTML-документ зарезервованих символів мови HTML (наприклад, > або &) або символів, які неможливо ввести з клавіатури, передбачено механізм посилань на символи. Для найпоширеніших символів у мові HTML передбачено назви. У цій таблиці вказано деякі посилання і вигляд відповідного символу. Теги форматування символів (дескриптори стилів) завжди є парними: — жирне написання; — курсив; — підкреслення; — перекреслення; — стала ширина літер; — нижній індекс; — верхній індекс; — збільшити шрифт; — зменшити шрифт; — логічний наголос — цитування — текст коду — результат виконання програми — виділення — текст означення (залежно від браузера); — назва змінної або параметра — назва клавіші &#8230; —текст-зразок У поданому вище переліку перші 7 контейнерів (до порожнього рядка) називають фізичними, а наступні — логічними. Форматування тексту мовою HTML виконують з використанням спеціальних тегів:

,

,

,

,
,
— відображення заголовків відповідно 1, 2, 3, 4, 5 і 6 рівнів — перелічено у порядку зменшення розміру шрифту.

— створення нового абзацу без відступу у першому рядку, між абзацами буде порожній рядок;
— відображення тексту у повній відповідності до форматування, здійсненого за допомогою текстового редактора (пропуски, невідтворювані символи кінця рядка); — заборона перенесення слів, яку можна подавити тегом ;
— центрування;
— обривання рядка без пропуску рядка;
— проведення горизонтальної лінії. Перші два види тегів (з перелічених вище) мають атрибут align з такими можливими значеннями: center — центрування; justify — вирівнювання за шириною; left — вирівнювання за лівим краєм; right — вирівнювання за правим краєм і атрибут title — текст підказки. Крім цього тег

має атрибут tabindex, який задає порядковий номер абзацу при переміщенні HTML-документом у вікні браузера за допомогою клавіші Tab. Колір тексту можна задати його назвою англійською мовою: aqua — бірюзовий; black — чорний; blue — світло-синій; fuchsia — бузковий; gray — сірий; green — зелений; lime — салатовий; maroon — бордовий; navy — синій; olive — оливковий; purple — фіолетовий; red — червоний; silver — сріблястий; teal — сіро-зелений; white — білий; yellow — жовтий. Колір можна задати кодами кольорової моделі RGB, як це роблять при роботі з графічним редактором. Наприклад, #ff7800. Контактну інформацію записують у контейнері
. Коментар записують у контейнері або використовують тег . Текст всередині цих тегів на екран браузера не буде показано. 19.4. Гіперпосилання Гіперпосилання - це один з найголовніших компонентів html-документів. Саме завдяки цим звичайним посиланням, Інтернет такий простий у використанні. Розглянемо найпростіші варіанти вставки гіперпосилань: посилання можуть бути як на сайті, так і на сторінці, як на свій сайт, так і на зовнішній, тому коди потрібно розрізняти між собою. Такий код буде працювати тільки на Вашому сайті, для зовнішніх посилань, він не підійде. 1. Для створення посилання на сайт, нам потрібно використовувати код: ***** Де, замість *** – посилання на сайт у форматі «http: // ….», а замість ***** – текст, під який поміщається гіперпосилання. Приклад: Журнал Як зробити все 2. Щоб створити гіперпосилання на сторінку, використовуємо такий же код, тільки тепер вказуємо повністю шлях до сторінки, на прикладі це виглядатиме так: Як зробити переказ Вебмані? 3. Як створити гіперпосилання в html на зовнішній сайт? Для зовнішніх посилань, код слід трохи змінити. Щоб зробити посилання на інший сайт, використовуємо код: ***** Де, замість *** – посилання на зовнішній сайт у форматі «http: // ….», а замість ***** – текст, під який поміщається гіперпосилання. Приклад: Головна сторінка групи Довідник HTML тегів Базові теги

01.09.20

inPixio Photo Studio 10 Редактирование фотографий.

  • Удалите отвлекающие детали и исправьте ошибки
  • Безупречный вырез ваших фотографий и изображений
  • Создавайте потрясающие фотомонтажи
  • НОВИНКА!  Совершенно новый интерфейс
  • НОВИНКА!  Доступны новые фоны для фотомонтажа
  • НОВИНКА! Кнопка «Поделиться» для Facebook, Twitter, Flickr
  • НОВИНКА! Коррекция изображения в один клик inPixio®

04.05.20

Як пояснити бабусі, що таке Agile за 15 хвилин з картинками

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера

image

Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.

Роли



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


Это заинтересованные лица. Они будут использовать продукт, поддерживать его или будут как-то еще вовлечены в разработку.


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


У заинтересованных лиц много идей, и Пэт помогает сделать из идей пользовательские истории.


Это команда разработчиков. Те, кто будет строить рабочую систему.

Пропускная способность



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

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

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


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

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

Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.



Допустим, команда возьмется сделать 10 новых историй за эту неделю.Если на входе 10 а на выходе 4-6, то команда будет перегружена. Будет спешить, переключаться между задачами, терять мотивацию, в итоге снижается производительность и качество. Это заведомо проигрышная стратегия.

Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”

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

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


Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.

Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.

Есть только один способ держать список задач под контролем — это слово “нет”



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

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


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

Принятие решений


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

Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи — вот что помогает Пэт расставлять приоритеты.

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

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

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

Пэт проводит встречу по очистке Backlogа каждую среду с 11 до 12. Обычно на ней собирается вся команда и иногда несколько заинтересованных лиц. Содержание встреч бывает разным. Фокусировка на оценке, на разбивке историй, на критериях приемки.

Владелец ИТ-продукта должен постоянно со всеми общаться


Матерые владельцы продукта выделяют 2 компонента успеха: страсть к работе и общение. Какие задачи владелец продукта решает месте с командой.

Баланс между сложностью разработки и ценностью пользовательской истории


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



Риски


Бизнес риск: «Правильную ли вещь мы делаем?»

Социальный риск: «Сможем ли мы сделать то что нужно?»

Технический риск: «Будет ли проект работать на данной платформе?»

Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»


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

Компромисс между ценностями знания и ценностями для клиента


С точки зрения заказчика кривая выглядит вот так:



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

Компромисс между краткосрочным и долгосрочным мышлением



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

Делать правильные вещи, делать вещи правильно или делать быстро?



В идеале — все три одновременно, но в реальности приходится выбирать.


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

или


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

или


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

Между ролями в Scrum существует здоровое противостояние



Владелец продукта фокусируется на построении правильных вещей. Команда фокусируется на том, чтобы строить вещи правильно. Scrum-мастер или agile-тренер фокусируется на сокращении цикла обратной связи.

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

Компромисс между разработкой нового продукта и улучшением старого



Продукт никогда не может быть полностью завершен, потому что ему постоянно нужны изменения. Когда команда начинает работу над новым продуктом, что происходит со старым? Передача продукта от одной команды к другой — очень затратно и рискованно. Обычно команда поддерживает старый продукт, разрабатывая новый. Поэтому скорее понятие “Backlog” относится не к продукту а к команде. Backlog — это список вещей, которые хочет владелец продукта от команды. И набор историй для разных продуктов. Владельце продукта нужно постоянно выбирать актуальные для реализации.

График уничтожения историй


Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.


Два тренда — оптимистичный и пессимистичный (можно на глаз). Расстояние между трендами показывает насколько нестабильна скорость работы команды. Со временем эти тренды стабилизируются и конус неопределенности будет уменьшаться.

Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?


Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.


Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.


Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»

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

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

Несколько команд



Пусть у нас несколько владельцев продукта и несколько команд. Модель та же — управление пропускной способностью, коммуникация с заинтересованными лицами, принятие решений по поводу отклонения пользовательских историй. Скорость равна сумме скоростей всех команд. Прогнозирование может быть общее или по каждой команде. У владельцев продуктов появляется дополнительная задача — общение с другими владельцами продукта. Нужно организовать работу над Backlogами так, чтобы минимизировать зависимости и обеспечить синхронизацию. В больших проектах требуется Главный владелец продукта (CPO), чтобы синхронизировать всех остальных.

14.04.20

ІНТЕРАКТИВНІ ІНСТРУМЕНТИ, ТЕХНОЛОГІЇ ТА МЕТОДИ В ОСВІТІ

Прийом для творчої візуалізації навчального матеріалу та її види. Етапи створення власного скрайбінгу та інтернет-інструменти для підготовки їх відеоверсій.
Який спосіб запам'ятовування для Вас найбільш дієвий? Особисто ви зможете відтворити максимум з прочитаного, почутого чи записаного?
Спеціалісти стверджують, що найкраще сприймається візуальна інформація, вона швидше систематизується, а кольорові образи ліпше запам'ятовуються. Тому пропонуємо вашій увазі метод навчання із залученням яскравої візуалізації.

Що таке скрайбінг

Скрайбінг (з англійської scribe - робити екскіз, нарис) – це метод розповіді чи пояснення, який супроводжується графічною ілюстрацією головного змісту сказаного. Виходить свого роду ефект паралельного наслідування, тобто ми слухаємо розповідь про щось і одночасно бачимо графічну відповідність почутому.
«Покоління мобільного інтернету», автор проекту: Сопін Владислав, Запорізька спеціалізована школа-інтернат ІІ-ІІІ ступенів «Січовий колегіум» Запорізької обласної ради

Навіщо потрібен скрайбінг

Головна мета скрайбінгу – допомогти краще опанувати зміст та запам'ятати сенс нової інформації завдяки залученню візуалізації. Головне завдання цього прийому – донести інформацію у максимально зрозумілому і привабливому для слухача форматі.
Тому для створення яскравої картинки залучаються різноманітні типи зображень – малюнки, піктограми, символи, окремі ключові слова (написи, гасла), схеми, діаграми тощо.
 
Унаочнення теоретичних відомостей щодо внутрішньої будови Землі
Головні переваги скрайбінгу:
  • яскравість;
  • лаконічність;
  • інформативність;
  • креативність представлення інформації.
В ідеалі, дивлячись на скрайб-візуалізацію, слухач повинен відтворити в пам'яті почуту розповідь хоча б у загальних рисах.

Різновиди візуалізації:

Скрайбінг – це не лише короткі мальовані відео. Практично кожен вчитель практикує унаочнення на уроках, підкріплюючи пояснення відповідними схемами чи малюнками на дошці. Тому в залежності від часу відтворення виділяють такі види скрайбінгу:
  1. Скрайбінг-фасілітація – супроподження розповіді схематичними малюнками, графіками, діаграмами тощо у реальному часі. Такий формат практикується вчителями на уроках найчастіше.
  2. Відеоскрайбінг – короткі яскраві відеопояснення з певних питань, які супроводжуються схематичними малюнками, класичним прикладом такої візуалізації є принцип викладання youtube-каналів «Научпок», «Цікава наука» тощо.

В залежності від форм залучення наочності виділяють такі різновиди скрайбінгу:
  • мальований (схеми та малюнки зроблені від руки на будь-якій поверхні);
  • аплікаційний (на фон наклеюються чи накладаються готові зображення).
  • магнітний (зображення закріплюються на поверхні за допомогою магнітів);
  • фланелеграфний (готові зображення чіпляються до ворсистої поверхні за допомогою липучок тощо);
  • 3D-скрайбінг (об'ємні малюнки, які створюються за допомогою 3D-ручки).

Головні етапи створення скрайбінгу:

Перш ніж приступати до створення візуалізацій, окресліть головний зміст, який ви плануєте донести до учнів. Це необхідно аби через надмірну кількість образів не втратився сенс змісту розповіді. Тому рекомендуємо здійснювати підготовку таким чином:
  • Придумати ідею. Вона повинна бути зрозумілою і актуальною.
  • Обрати спосіб візуалізації. В залежності від мети та доступних засобів оберіть, яким чином буде зображено головний зміст (малюнок, аплікація, магніти тощо).
  • Підготувати сценарій. Необхідно заздалегідь продумати план розповіді та дібрати відповідне візуальне відтворення до кожного з етапів.
  • Зробити заготовки. Якщо заплановане яскраве представлення у реальному часі, підготуйте відповідні заготовки для здійснення певного виду скрайбінгу (маркери чи кольорову крейду для мальованого; наліпки, аплікації, магніти, 3D-ручки для інших видів). Якщо запланований відеоскрайбінг, оберіть найбільш зручну для вас програму, в якій можна створити та змонтувати сюжетні складові у єдиний відеоряд.
  • Провести скрайбінг-сесію або змонтувати відеоролик. На фінішному етапі необхідно перевірити, що образи в достатній мірі відтворюють теоретичний зміст, а пояснення вміщується в запланований час.

04.02.20

Рядок, що біжить, відповідь

ПРИКЛАД НА БЛОЗІ
<span style="margin: 0px; padding-bottom: 0px; padding-left: 0px;color:blue;"><marquee behavior="alternate" bgcolor="yellow" height="35" scrollamount="3"><b><i><tt>"Найдите работу, в которую влюбитесь, и вам больше не придется трудиться ни одного дня в жизни". Конфуций<br /></tt></i></b></marquee></span><br /><br />