Русский
Русский
English
Статистика
Реклама

История it

История клавиши Enter

18.01.2021 16:06:50 | Автор: admin
Большая часть компьютерной клавиатуры унаследована у пишущих машинок; например, клавиша Shift получила своё название потому, что механически сдвигала литероноситель (typebar), так что по красящей ленте ударяла другая его сторона.


Но вот клавишу Enter вы на клавиатуре механической машинки не найдёте: вместо неё на левой стороне каретки был (неподписанный) рычаг.


(Ещё одно бросающееся в глаза отличие её клавиатуры от компьютерной более логичное расположение клавиш Backspace и Tab: клавиша для перемещения по строке влево с левого края клавиатуры, для перемещения вправо с правого края.)

Ясно, что механическую клавишу, сдвигающую массивную каретку на всю ширину листа, было бы тяжело нажимать одним пальцем. Электрические пишущие машинки были лишены такого ограничения; и действительно, на Blickensderfer Electric (1901) впервые появляется клавиша для возврата каретки и перевода строки. Не мудрствуя лукаво, эта клавиша подписана Left. Есть под ней и клавиша Right, медленно сдвигающая каретку в сторону конца строки. Книга The History of the Typewriter (1909) комментирует: Практический эффект состоит в том, что всё от Dear Sir до Yours truly, пишется не поднимая рук от клавиатуры. Если бы даже в этой машинке не было других новшеств, кроме двух клавиш Left и Right, она уже была бы конкурентоспособна на нынешнем рынке.


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

Годом раньше, в 1908, был разработан Morkrum Printing Telegraph позднее он продавался под брендом Teletype, и этот бренд стал нарицательным обозначением телепринтеров. Телетайп объединил более раннюю идею печатающего телеграфа, который автоматически расшифровывал телеграфный код и печатал текст на бумажной ленте, с пользовательским интерфейсом электрической пишущей машинки: для оператора единственная разница состояла в том, что бумажный лист находился не в непосредственной близости от клавиатуры, а за сотни миль. На клавиатуре телетайпа впервые появилась клавиша CAR RET, и рядом с ней LINE FEED: скорее всего, они были разделены для упрощения конструкции приёмника, чтобы каждому принимаемому коду соответствовало одно простое механическое действие. Из телетайпного кода 1908 разделение CR и LF было унаследовано Международным телеграфным кодом (1924), а затем кодировками EBCDIC и ASCII; и даже сто лет спустя, когда последние телетайпы разошлись по музеям, это разделение продолжало усложнять работу программистам.


Но вернёмся в начало прошлого века: электрификация возврата каретки в пишущих машинках возобновилась в 1929, когда фирма Northeast Electric разработала машинку Electromatic. В ней по примеру телетайпа появляется клавиша Carriage Return: пока ещё той же формы, как и все остальные клавиши зато единственная, подписанная по кругу. В 1933 IBM купила подразделение, выпускающее машинки Electromatic, и стала выпускать их под брендом IBM Electromatic, а с 1935 IBM Electric.


Начиная со второй модели, IBM Electric Model A (1949), клавиша стала квадратной, а надпись на ней сократили до более привычного нам Return.


В IBM Selectric (1961) клавиша Return начинает обретать привычную нам форму вертикальную, занимая два ряда. Нововведения в машинках этой серии отсутствие подвижной каретки и сменный литероноситель в виде шарика, позволяющий использовать попеременно разные шрифты обеспечили Selectric колоссальный успех: к 1972 среди американских пишущих машинок 36% были из этой серии, к 1982 90%. В 1975 американская Federal Trade Commission, комментируя жалобу Litton на формирующуюся монополию IBM на рынке пишущих машинок, охарактеризовала Selectric как самое важное изобретение в этой отрасли за всю её историю. Неудивительно, что раскладка, разработанная дизайнером Элиотом Нойсом специально для Selectric, повлияла на всё дальнейшее развитие клавиатур: обратите внимание ещё и на формы клавиш Tab, Caps Lock и Shift.


Можно заметить, что между клавишей с дробями и и Return осталась неаккуратная щель шириной в полклавиши. В следующей машинке серии, IBM Selectric II (1971), туда поместили новую клавишу Express Backspace в результате Return приняла ставшую традиционной форму Г вверх ногами.


На клавишах машинок, производимых для международного рынка, IBM заменяла английские подписи графическими обозначениями: Tab обозначался стрелкой вправо, Backspace стрелкой влево, Caps Lock стрелкой вниз. В экспортных моделях первой Selectric на Return была такая же стрелка влево, как и на Backspace; но 13 сентября 1971 можно считать днём рождения Return в её привычном облике: в Selectric II ей впервые придали не только ставшую традиционной форму, но и ставшее традиционным графическое обозначение .


Тем временем пишущие машинки начали уступать популярность электронным системам обработки текста. Для ввода текста в компьютер изначально использовались те же самые телетайпы; но начали появляться и специализированные терминалы. В знаменитом видеотерминале VT100 (1978) DEC свела воедино две ветви развития клавиатур: формы клавиш Caps Lock, Shift и Return позаимствованы у Selectric II, но справа от правого Shift видим наследие телетайпов отдельную клавишу Line Feed. (На некоторых VT100 ещё и клавиша Break была подписана Here is; зачем такая клавиша на телетайпах понятно, но зачем она при работе с компьютером?) VT100 среди терминалов стал тем же, чем была Selectric среди пишущих машинок; даже в эмуляторе терминала, встроенном в Windows 98, был реализован режим совместимости с VT100!


Кроме видеотерминалов, в 1970-х появился ещё один новый тип устройств персональные компьютеры. Первым ПК можно считать Datapoint 2200 (25 мая 1970) от Computer Terminal Corporation. Его первенство проявилось и ещё в одной области: клавиша в форме впервые получила своё нынешнее название Enter вместо Return; так что дату выпуска Datapoint 2200 можно считать днём рождения Enter.


Самые успешные из первых производителей ПК Apple, Commodore, Tandy Radio Shack нацеливались на аудиторию технологических энтузиастов; но IBM, вдохновившись успехом первопроходцев, задумала персональный компьютер для офисных работников, привыкших ко клавиатуре Selectric. Тем не менее, клавиатура первого IBM PC (1981) на Selectric похожа мало: клавиши, втиснутые в тесный прямоугольник, лишились своих характерных форм; на Enter и Shift даже не поместились подписи! Может быть, какие-то технологические проблемы помешали IBM в 1981 выпустить клавиатуру на пару дюймов шире, где клавиши не пришлось бы так ужимать? Такая клавиатура действительно вышла с IBM AT в 1984: Enter снова Г вверх ногами, а Ctrl, Alt и Caps Lock приняли форму, используемую в Selectric и в VT100 для Caps Lock и Shift.


На 1984 история заканчивается: клавиша, сорок лет бывшая Carriage Return и следующие сорок лет просто Return, получила свои окончательные название, форму и значок.

Подробнее..

GEM. Теория забытых окон

20.01.2021 12:12:03 | Автор: admin


Спустя четыре года после того, как в Xerox разработали первую в истории пользовательскую среду с оконным графическим интерфейсом, американская компания Digital Research, Inc. создала собственную оконную платформу, оснащенную практически всеми компонентами, характерными для современных ОС. Если бы колесо истории повернулось в другую сторону, а обстоятельства сложились несколько иначе, она вполне могла бы занять место Windows в мире операционных систем. В сегодняшней историческо-ностальгической статье мы вспомним эту ушедшую и неоправданно забытую технологию.

1985 год. В Интернете зарегистрированы первые домены верхнего уровня: .arpa, .com, .edu, .gb, .gov, .mil, .net, .org, .us, в СССР началась перестройка, Nintendo выпустила легендарные игры Super Mario Bros и Duck Hunt. А еще этот год положил начало новой эпохе: 20 ноября 1985 состоялся релиз графической оболочки для MS-DOS под названием Microsoft Windows 1.01. Но еще за 8 месяцев до этого радостного события, 28 февраля 1985 года, компания Digital Research выпустила на рынок собственную графическую надстройку с оконным интерфейсом для операционной системы CP/M, получившую название Graphics Environment Manager, или, сокращенно, GEM.

Программная среда GEM поддерживала мышь, в ней имелся Рабочий стол, на котором размещались ярлыки сменных и стационарных накопителей, а также ярлык для виртуального диска классического RAM drive, пространства оперативной памяти, динамически выделяемого системой при загрузке машины для размещения системных файлов. Кроме того, в распоряжении пользователя имелась Корзина, а хранящиеся на дисках файлы и папки отображались в виде значков. Оконный менеджер автоматически создавал для запускаемых приложений отдельные окна с настраиваемыми геометрическими размерами, оснащенные кнопками управления и полосами прокрутки. В распоряжении любителей постучать по клавишам имелась командная строка. В общем, все как в винде. Только появился GEM немного раньше. Первыми машинами, на которых успешно работал GEM, были Atari ST на базе процессора Motorola 68000, но позже платформу портировали под Intel 8088, и она дебютировала на IBM-совместимых машинах, в том числе, в версии под DOS.

image
GEM/1

Можно смело сказать, что дизайнерское и функциональное исполнение GEM было очень похоже на интерфейс первой версии MacOS, если не считать ряда незначительных технических отличий. Например, папки в GEM не открывались в новом окне, их содержимое демонстрировалось пользователю в том же окне, в котором до этого отображалась родительская директория. Дисковые накопители не определялись в системе автоматически: для того, чтобы отобразить ярлык диска на рабочем столе, нужно было воспользоваться пунктом меню Install disk drive. Меню Desk практически полностью соответствовало такому же пункту в MacOS: помимо всплывающего окна с информацией о текущей версии операционной системы, оно выполняло функции, аналогичные Панели задач в MS Windows, а именно, отображало заголовки всех запущенных в данный момент времени приложений.

Эффекты появления тени на фоне всплывающих окон, названий загружаемых приложений, а также псевдотрехмерное обрамление полос прокрутки были удалены из системы по требованию корпорации Apple, которая расценила использование подобных элементов, как прямое нарушение своих авторских прав, поскольку все перечисленные декоративные элементы впервые были реализованы в MacOS, выпущенной в том же 1985 году, но на несколько месяцев раньше. Цветовая палитра отображения окон, рабочего стола и прочих элементов интерфейса GEM поддавалась настройке, причем в составе платформы имелось несколько стандартных цветовых схем. Изменение настроек системы осуществлялось с помощью специальной утилиты, которая носила название Редактор ресурсов.

image
GEM/1

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

Увы, весьма удобный и быстрый для своего времени GEM/1, завоевавший вполне заслуженное признание пользователей и быстро набравший популярность на североамериканском континенте, чрезвычайно не понравился руководителям корпорации Apple, посчитавшим, что Digital Research Inc. украла у них не только саму идею пользовательской оконной среды, но и ее дизайнерско-техническую реализацию. Состоялся громкий, скандальный и позорный судебный процесс, который выиграла компания Apple. GEM/1 был запрещен к дальнейшему распространению, и по решению суда производитель должен был убрать из операционной системы все компоненты, хоть сколько-нибудь напоминающие элементы MacOS. Результатом такого постановления стало появление в 1986 году платформы GEM/2, значительно уступавшей своей предшественнице.

image
GEM/2

GEM/2 работала гораздо менее стабильно и была просто неудобна в использовании. Рабочий стол теперь представлял собой два вытянутых вдоль экрана окна фиксированного размера, оснащенных вертикальными и горизонтальными полосами прокрутки. В верхнем окне отображались подключенные к системе дисковые накопители, нижнее выполняло функции, аналогичные современному Проводнику Windows: в нем отображалось содержимое выбранного в верхнем окне диска. Корзина была удалена с Рабочего стола и вообще отсутствовала в системе.

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

Внесенные в систему изменения были расценены пользователями, как негативные, благодаря чему GEM начал быстро сдавать позиции, утрачивая рынок под натиском только что появившейся Microsoft Windows 1.01. Следует отметить, что первая реализация Windows по своему оформлению тоже недалеко ушла от MacOS, однако Microsoft, в отличие от Digital Research, оказался Apple не по зубам. Положения не спасли ни GEM/3, ни наспех усовершенствованная GEM/4: Windows все увереннее и увереннее вытесняла их с поля битвы. Ситуация несколько изменилась лишь тогда, когда Digital Research выпустила в 1988 году очередную реализацию платформы, которая получила название GEM/5.

image

По своему дизайнерскому оформлению и функциональным возможностям GEM/5 оказался далеко впереди как всех предыдущих реализаций GEM, так и Microsoft Windows версий 1.0, 2.0 и 3.0. Прекрасный и удобный трехмерный интерфейс выглядел просто великолепно, практически все средства управления системой были реализованы в подобном исполнении. Двухоконный внешний вид Рабочего стола практически не изменился, однако в него было внесено очевидное разнообразие обилием всевозможных кнопочек и рамочек. Поскольку разработчикам удалось отойти от стандартной палитры VGA, опции многочисленных меню буквально светились нежно-зеленым фосфорицирующим оттенком, несказанно радуя глаз. При щелчке мышью на управляющих элементах окон и меню операционная система демонстрировала эффект нажатия кнопок, а сам курсор менялся в зависимости от контекста поля, в котором он находился, но, так или иначе, выглядел красиво и аккуратно.

image
GEM/5

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

На базе исходных текстов GEM от Digital Research группа независимых энтузиастов разработала в 1999 году бесплатную платформу FreeGEM, созданную на основе версии GEM/3 образца 1987 года. Рабочий стол все также использовал двухоконную систему, но системные окна вновь стало возможным перемещать по экрану, равно как и изменять их размер. Псевдотрехмерное оформление управляющих элементов было частично позаимствовано из GEM/5, оттуда же была изъята основная цветовая палитра, однако создателям не удалось выйти за рамки количества цветов, диктуемых стандартом VGA, благодаря чему внешний вид окон и диалоговых меню выглядит объективно хуже. Вернулись на свое законное место радио-кнопки, тени и другие элементы, пребывавшие до этого времени под запретом.

image
FreeGEM

В 1990 году компанией Digital Research был выпущен графический менеджер для DRDOS-5, названный ViewMAX/1 и созданный на основе платформы GEM. Однако эта оболочка стала очевидным шагом назад по сравнению с GEM/5. Глядя на ее исполнение, можно смело судить, что разработчики трудились без особого энтузиазма и спустя рукава: оконный менеджер получился не только неудобным, но и откровенно убогим с точки зрения дизайна. ViewMAX/2, входивший в комплект поставки DRDOS-6 в качестве файлового менеджера, получился ничуть не лучше, хотя и включал некоторые визуальные улучшения, вроде объемных окон, расширенной цветовой палитры, и возможности отображать древовидную структуру файлов и папок рядом с содержимым текущей папки (а не вместо нее, как это было раньше).

В ViewMAX/3 разработчики планировали вернуть свободно перемещаемые по экрану окна с произвольно изменяемым размером, но этот оконный менеджер так и не был закончен в связи с безвременной кончиной проекта. ViewMAX/3 должнен был стать оконным менеджером для операционной системы Panther, которая впоследствии была выпущена компанией Novell как сетевая платформа Novell DOS 7. Тексты этой среды были последними исходными кодами операционных систем класса GEM, обнаруженными среди оставшихся в наследство от Digital Research архивов.

Одна из последних реализаций GEM носит название OpenGEM. Как и его прародитель, OpenGEM это 16-разрядная графическая надстройка над DOS, которая, в частности, может запускаться в среде FreeDOS в качестве файлового менеджера. Исходники OpenGEM распространяются на условиях лицензии GNU General Public License (GPL), их можно найти на SourceForge. А классическую платформу GEM пока еще можно скачать на сайтах любителей компьютерной археологии.

В настоящее время OpenGEM является игрушкой нескольких десятков хакеров и энтузиастов, поставивших своей целью поиск, исследование и совершенствование операционных систем прошлого. Так ушел в историю еще один перспективный проект, который при ином стечении обстоятельств мог бы стать объективной альтернативой всемирно распространенной Microsoft Windows в качестве операционной системы для настольных персональных компьютеров.

Подробнее..

Анатолий Шалыто Если человек сомневается, заниматься ли наукой, ему стоит заняться чем-то другим

21.01.2021 20:07:17 | Автор: admin

Анатолий Шалыто доктор технических наук, профессор Университета ИТМО,специалист в области автоматного программирования и проектирования алгоритмов логического управления технологическими процессами. C 1970 года он работает в НПО Аврора, в 2018-м стал одним из первых троих специалистов, награжденных государственной наградой, знаком отличия За наставничество.

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

По совету профессора

Каким вы были в 1213 лет?

Я понимал, что мне нравится математика, и хотел заниматься наукой, но ничего для этого не делал. Единственный кружок шахматы. Правда, я еще серьезно занимался плаванием, которое учит терпеть. Учился хорошо, окончил школу с серебряной медалью. Год ходил в знаменитую физмат школу 30, но решил не попадать в стык 1011-х классов и ушел в школу рабочей молодежи. Потом поступил в Ленинградский электротехнический институт им. Ульянова (Ленина), окончил с отличием, опять хотел заниматься наукой, но получалось не очень внятно, потому что, как сказал один доцент, мы здесь готовим из вас не гениев, а чиновников. Прошло много лет, и я пригласил своего бывшего преподавателя отметить защиту моей докторской, благо она проходила в ЛЭТИ. Он пришел, но, видимо, взгляд на то, кого он готовит, и его самого сформировал таким же за столько лет, находясь в вузе, он так и остался доцентом.

Кто ваши родители?

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

Анатолий Шалыто с отцом на фоне Дома Бенуа на Кировском проспекте Ленинграда, около 1968 года. Фото из семейного архиваАнатолий Шалыто с отцом на фоне Дома Бенуа на Кировском проспекте Ленинграда, около 1968 года. Фото из семейного архива

Поскольку у меня была серебряная медаль, сдавать нужно было только один вступительный экзамен. Жили мы на Каменноостровском проспекте, который назывался тогда Кировским, в Петроградском районе. Встал вопрос, куда поступать в Политехнический или Электротехнический. Проконсультировался у одного старого профессора в институте Бонч-Бруевича, который сказал: Вы понимаете, что до ЛЭТИ вам пешком 15 минут, а до Политехнического на трамвае час пятнадцать? Шесть лет вы будете тратить на дорогу два лишних часа каждый день. Конечно, идите в ЛЭТИ. Я и пошел.

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

В спортивном лагере, 1966 годВ спортивном лагере, 1966 год

Как вы родителям объясняли, чем занимаетесь?

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

НПО Аврора

Потом по распределению я попал в НПО Аврора и зверски занялся наукой многофункциональными логическими модулями. У меня был прекрасный начальник, ставший моим Учителем Валерий Леонидович Артюхов, окончивший физфак ЛГУ. Однажды он сказал: У нас совпадают интересы. Я хочу защитить докторскую, а вам, наверное, нужна кандидатская. Давайте писать вместе.

Что значит писать диссертацию в НПО Аврора, когда надо непрерывно делать проекты для кораблей? Это ж не вуз! Времени было мало, и меня мама очень жалела. Когда люди в выходные дни летом ехали в Сестрорецк или Курорт на пляж, я шел в Публичную библиотеку. Понимал, что если сегодня я холост, более или менее свободен на работе, то завтра могут плотно загрузить. Проекты обычно длятся по пять лет, позже были и такие, что длились лет 20. При этом все эти годы каждую минуту нужно было заниматься серьезными вещами. Я уже тогда понимал, что от перестановки мест слагаемых сумма может измениться: практически все мои одногодки, кто в это время ходил на пляж, теперь на пенсии, а я продолжаю работать и общаюсь с прекрасной молодежью. Сходить на пляж и сейчас успею!

НПО Аврора, 1972 год. Анатолий Шалыто третий справаНПО Аврора, 1972 год. Анатолий Шалыто третий справа

Чем занималась Аврора?

Автоматикой для судов и кораблей это управление их техническими средствами, например, общекорабельными системами. Работа хлопотная, сложная и дико ответственная.

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

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

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

Но денег в конторе все равно было мало. Вот я как-то написал статью в двух частях и в двух экземплярах и принес в общий отдел, чтобы отправить, а ее не берут нет денег на марки. Твоя фамилия сам и отправляй за свой счет. Я мог найти 510 рублей, но не мог понять, почему у меня они должны быть, а у НПО Аврора их нет. Да и счета у меня никакого не было. И это при том, что статья отправлялась с экспертным актом от работы и в тексте было указано, что исследование выполнено в НПО Аврора. Вот и высказал это на повышенных тонах помощнику генерального директора: Я отправляю статью в журнал Академии наук. Либо звоните генеральному и объясняйте причину, почему я хамлю, либо позвоните женщинам в общий отдел и распорядитесь, чтобы они отправили статью. В это время он, явно не испытывая любви ко мне, решал, что делать, и позвонил женщинам.

1972год. Организаторы конференции посудовой автоматике. Крайний слева Витольд Витальевич Войтецкий, самый высокий Олег Павлович Демченко втовремя Генеральный директор НПО Аврора1972год. Организаторы конференции посудовой автоматике. Крайний слева Витольд Витальевич Войтецкий, самый высокий Олег Павлович Демченко втовремя Генеральный директор НПО Аврора

Как долго вы работали в НПО Аврора?

С 1971 года по 2014-й. Я и сейчас там работаю, только по совместительству. С 1998 по 2014 год по совместительству работал в Университете ИТМО, но это совместительство было необычным каждый день минимум по три часа, кроме воскресений и месяца отпуска. Это удивляло окружающих.

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

Приходишь на работу по звонку в 8:30. Опаздывать нельзя. Конструкторское бюро, кульман, письменный стол. Никаких компьютеров еще не было. Если нужны расчеты, идешь в вычислительный центр. И все вкалывают, как звери. Можно посмотреть любой документальный фильм как ракеты в космос запускают, как подлодки сдают. Никакого разгильдяйства быть не могло, его нет и сейчас.

По субботам на шашлыки не ездили с коллегами?

Нет. Мы ездили в будние дни на картошку и на овощные базы. Бывало, 1 января приходилось лимоны из вагонов разгружать за два отгула. Ящики для овощей сколачивали. Летом ездили пропалывать картошку и турнепс, убирать капусту. Особенно поэтичной была уборка пастернака! Женщины с удовольствием ездили, потому что вместо половины шестого освобождались в два часа. Но мне это дико не нравилось. Сейчас сельское хозяйство как-то без нас обходится, но тогда Артюхов мой начальник и учитель мне пояснил, что это воспитательная мера для того, чтобы каждый понимал, что с завтрашнего дня сколачивание ящиков может стать его основным делом.

Студенты науборке урожая совхоза Ручьи в1979 годуСтуденты науборке урожая совхоза Ручьи в1979 году

Источник фото: здесь.

Мы ездили в совхоз Ручьи, это кольцо 94-го автобуса. В нашей конторе, которой я горжусь, не было ни одного героя соцтруда, а в этом совхозе 18. Почему? Потому что им тысячи людей с разных предприятий и институтов помогали, и производительность труда на одну совхозную душу была невероятная. Я все ждал, когда к нам в Аврору придут совхозники и повысят нашу производительность, тогда и у нас герои соцтруда будут.

Расскажите о вычислительной технике НПО Аврора в разные годы.

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

Как поколения вычислительной техники менялись, так были они и в автоматике. Сейчас можно сказать, что вся автоматика превратилась в управляющую вычислительную технику. А раньше вычислительная техника делилась на офисную (научную) и управляющую. Одна из первых управляющих машин была сделана в Ленинграде на Светлане. Двое ученых: Старос и Берг бежали из Америки, набрали очень толковых людей и сделали. Потом машины стали ставить на подводные лодки в качестве ядра боевых информационно-управляющих систем. Сейчас мои ребята выпускники работают в DataArt, JetBrains, Google. Почти никто не идет в Аврору или Гранит. По многим причинам и секретности они не хотят, и платят здесь меньше, и учили их другому. Хотя в одном из частных оборонных предприятий они работают.

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

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

У моей жены отец был конструктором в одном КБ. Он никогда не говорил дома о работе. Запрещено об этом разговаривать, и все. Но это не только у нас во всем мире так. Когда один наш выдающийся мальчик попросил другого выдающегося мальчика, работавшего в Гугле, не то ноутбук, не то телефон, тот ему не дал. Потому что служебный. И это при том, что они к этому моменту дружили уже более десяти лет. Корпорация, защищая свои секреты, запрещает даже на секунду передать кому-то рабочие гаджеты.

Синие и белые халаты

Что представлял собой вычислительный центр, которым вам приходилось пользоваться?

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

Расскажите о людях в синих и белых халатах.

И ламповые и транзисторные машины были ненадежными, все время ломались. Чтобы восстановить работу, нужно было вытаскивать и менять платы. На корабле, даже если плата сломалась, ничего нельзя было паять можно только заменить на исправную из ЗИП. В общем, целая история. Все, кто обеспечивал работу машин, носили синие халаты. Белые носили те, кто на этих машинах работал, обслуживая пользователей, и программировал сам. Только в 1970-х появились распределенные компьютеры, когда мы уже могли самостоятельно вводить программы с дисплеев, минуя перфокарты, а персональные компьютеры в России стали доступны только в 1990-е годы.

Между белыми и синими халатами было какое-то классовое разделение?

Среди синих халатов были не только рабочие, но и инженеры. Допускаю, что рабочие ходили обедать сами по себе, а инженеры чем они от программистов отличаются? Могли одну кафедру окончить. Никакой дискриминации по отношении к тем, кто обслуживал железо, не было. Ты подискриминируй завтра у тебя работать ничего не будет. Кстати, в 1991 году, когда случилось ГКЧП, был брошен клич, и все пошли на Дворцовую площадь. Один молодой человек, который отвечал за вычислительную технику в нашем отделе, сказал: Я все блокирую до победы демократии. И действительно заблокировал компьютеры в отделе. На следующий день, когда демократия победила, он их разблокировал.

Что делали руководители, если разработка заходила тупик?

Начальник нашего отдела, а это 250 человек, спрашивал начальника каждого сектора, какие у него есть проблемы. В чем они: рук не хватает, мозгов? Я, например, не знал, как делать систему питания, а мы все должны были работать как одна команда. Потому что, если завалим план, все останемся без премии. И начальник отдела сказал так: Владимир Николаевич (фамилия его была Киселев), вы у нас большой мастер по системам питания. С сегодняшнего дня подчиняетесь этому человеку. Осталось два месяца надо сделать. Начальник перераспределял силы,и мы всегда выполняли план. Непосильных задач не было. За непосильные задачи давали по три звезды героя: Харитону, Зельдовичу, Курчатову, Сахарову. Людям, которые создавали оборонную промышленность, атомную и водородную бомбы. Наши задачи были нам по силам, поэтому у нас ни одного героя и не было.

Контора провалилась

Случались ли на Авроре какие-то форс-мажорные ситуации?

1974 год. Еду на работу, выхожу из троллейбуса на площади Мужества. Надо успеть к 8:30, а сейчас пять минут девятого. Встречаю замдиректора, он говорит: А что вы не торопитесь? Еще 25 минут, куда торопиться? Надо торопиться. Там все рухнуло. Плавун прорвал метро. Когда подходишь, вроде ничего, только трещина идет по зданию. Но внутри перекрытия одного этажа лежали на другом. Иногда люди в сердцах говорят чтоб эта контора провалилась здесь она повалилась физически, ничего хорошего в этом не оказалось. У меня, в частности, в рабочем столе, до которого было не добраться, диссертация лежала, открытая часть. Думал, дома может быть пожар, могут украсть, а на такой работе что случится?

Что делать дальше? Заново писать? Тогда же компьютеров не было, все от руки. И спасла меня коммунистическая партия. Рядом с моим столом за стеклом находился кабинет начальника отдела. У него в сейфе лежал партбилет и, видимо, что-то еще. Партбилет нужно спасти он не может провалиться. Рабочие из патруля повели его другой лестницей забирать. Когда он документы забрал, я дал одному из этих рабочих денег и мешок: Пойди, пожалуйста, и из стола, который стоит на полу, под которым, правда, нет перекрытий, бумаги возьми. В силу того, что он уже там побывал, рабочий смог сходить и вынес все. Насже для спасения социалистического имущества пускали только c другой стороны, где перекрытия были. Когда я рвался к своему столу, мне говорили: Голос Америки передал, что жертв нет, иихинебудет.

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

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

Кадр из фильма Прорыв, посвященного аварии в Ленинградском метрополитене в 1974 годуКадр из фильма Прорыв, посвященного аварии в Ленинградском метрополитене в 1974 году

Потом встал вопрос, куда нас переселять. Рядом было два института недоделанный Торговый и незаселенный Институт цитологии Академии наук. Вечером приехал Первый секретарь обкома КПСС Романов, позвонил Косыгину. Тот спрашивает: Что больше подходит? Институт цитологии. Забирайте. Потому что с цитологами общаться это как свинью брить. Крику много, а шерсти мало. Единственное, что нам не подходило крематорий для зверей. Мы его убрали, въехали и сразу начали работать.

93 печатных листа одним пальцем

Когда у вас появился первый компьютер?

Первым был арифмометр Феликс в 30-й школе. Потом в ЛЭТИ я делал какие-то лабораторные работы на перфокартах. Занятия по вычислительной технике проходили на огромных машинах типа БЭСМ-6 и Урал.

Первый домашний компьютер купил дочери, когда ей исполнилось 15 лет. Потратил все деньги, которые были. Дочь выходила в интернет, я на компьютере написал две толстенные книги. На нем стоял редактор Лексикон, и я печатал одним пальцем. За три года появилось 93 печатных листа, причем ниоткуда ничего не списывал. Потом распечатывал на струйном принтере каждую страницу минуты по три. По этому поводу мой научный руководитель Артюхов вспоминал историю из своей жизни. Когда он ехал на юг на своем горбатом Запорожце, практически не останавливаясь, то опередил товарищей на Волге, которые по дороге устраивали пикники. Иными словами, если день и ночь работать, даже с Лексиконом и струйным принтером, можно обогнать кого угодно.

628-страничная книга Анатолия Шалыто, выпущенная петербургским издательством Наука в 1998 году628-страничная книга Анатолия Шалыто, выпущенная петербургским издательством Наука в 1998 году

Почему вы ушли из Авроры?

Я не ушел, по сей день продолжаю там работать по совместительству. Поступил туда в 1970 году, и только пять лет назад перешел в Университет ИТМО на основную работу. Почему не раньше? Я в университете по совместительству работал с 1998 года. Зарплата у профессора в университете была тысяч 30, пока в 2013-м не запустили программу Пять в сто, чтобы пять российских вузов попали в топ-100 мира. Мы четыре раза это сделали в области Computer Science. Когда генеральный директор Авроры Войтецкий узнал, что я преподаю, он вызвал меня и спрашивает: Сколько ты там получаешь? Две тысячи в час. Две тысячи чего?, а поняв, что рублей, сказал: Тогда иди работай. Я спокоен никуда не денешься.

Kotlin и Switch-технология

Какому изобретению ваших коллег в Петербурге вы по-хорошему завидуете?

Зависти у меня нет, я горжусь, что ребята из JetBrains создали язык программирования Kotlin. Главный разработчик Андрей Бреслав учился у нас. Сейчас туда подтянулся еще один наш выпускник Роман Елизаров, в 2020 году он возглавил работы по этому языку. Он чемпион России по программированию, один из главных ответственных за проведение олимпиад во всемирном масштабе. В JetBrains вообще много наших. Они участвовали и участвуют в разработке языка, который два года назад на огромной конференции вице-президент Google объявила вторым языком программирования для Андроидов.

В 1991 годуВ 1991 году

Вы написали книгу Switch-технология, где ввели понятие автоматное программирование. Что это такое?

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

К вам пришли успех и признание?

Признание пришло только в Университете ИТМО. Когда Васильев с Парфеновым увидели очень толстую книгу Switch-технология, они поняли, что, если человек в 1998 году смог ее выпустить, значит, в нем есть стержень. Неважно, что там написано. 1992-1996 годы мрак. Нужно было найти деньги (думаете, их кто-то хотел давать?), напечатать, вычитать, издать. И при этом тебя никто не поддерживает все вопреки. Потом началась схватка в Википедии. Понятие Switch-технология никого не задело, потому что ни с кем не соприкасается, но когда я этот подход назвал автоматным программированием

Есть выдающийся ученый Дмитрий Александрович Поспелов, который по сей день остается самым крупным специалистом в области логического управления (к сожалению, в 2019 году он скончался). В 1997 году на конференции по искусственному интеллекту в Ольгино под Санкт-Петербургом я за завтраком рассказал ему смысл Switch-технологии. Он специалист по автоматам, но в программировании их не применял. Спрашиваю: Почему в схемах такой подход используется, а в программах нет? Он ответил: Здоровый подход. Крепко стоит на земле. Назови это автоматным программированием, если привьется, значит, ты попал.

С выпускниками ИТМО, июль 2018 годаС выпускниками ИТМО, июль 2018 года

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

Гордость

Что было самым сложным в 1990-е годы?

Семью прокормить. Кто-то уходил торговать, кто-то уезжал. Я уезжать не хотел. Это моя страна, мой язык. Менять работу тоже не собирался, так как я не буддист и жизнь у меня одна. Я выбрал в молодости ЛЭТИ, автоматику и прочее не для того, чтобы немножко этим позаниматься, а потом торговать бананами. Даже если бы пригласили директором предприятия, которое компьютеры продает, я бы не пошел. Решил бороться и выстоял. Владимир Глебович Парфенов выстоял, Владимир Николаевич Васильев выстоял тоже. Им не на что было на чемпионат мира студентов везти, ходили по компаниям, собирали по 50 долларов. Я носил в Аврору бутерброды в течение пяти-семи лет, получая по 20 долларов в месяц. Но мои родители уехали, и мне оставили квартиру сдавал ее за 200 долларов. Если бы этих денег не было, видимо, и я бы сдался на 20 долларов, да еще с семьей, даже тогда было не прожить.

Я горжусь тем, что ни я, ни Васильев, ни Парфенов никто не колебался ни со страной, ни с работой. Мы выбрали науку и образование и пошли. Я по сей день не знаю, кому было труднее тем, кто уехал, или нам кто здесь остался. Теперь у нас все в порядке, чего и другим желаем. А те, кто в десятки раз богаче нас, не уверен, что находятся в большем кайфе, чем мы. Свобода и уверенность в себе, если вы успешны, не обязательно с деньгами связаны. Важно с кем живешь, работаешь и с кем общаешься. Я же общаюсь с одними из лучших молодых людей мира. Надо мной надежнейшие начальники. На день науки в 2018 году пресс-конференцию давал Владимир Николаевич Васильев наш ректор, так он вспоминал, что еще в 2000-е годы никто не хотел наукой заниматься. И сейчас многие считают, что в вузе главное преподавать. Но что такое по-настоящему преподавать? Это заниматься наукой и на лекциях рассказывать, что ты придумал вчера. А те, кто преподает и кому преподают по опаздывающим на 15 лет учебникам,ничего не добьются.

С выпускниками Сашей Наумовым, Пашей Мавриным (чемпионом мира по программированию 2004 года) и Сережей Вишняковым. 2018 годС выпускниками Сашей Наумовым, Пашей Мавриным (чемпионом мира по программированию 2004 года) и Сережей Вишняковым. 2018 год

На той пресс-конференции я услышал от ректора комплимент: По-моему, Анатолий Абрамович, только мы с вами и верили, что наукой надо заниматься.

Я приземленный человек и неверующий еще к тому же. Как говорил Мичурин, не надо ждать милости от природы, все надо сделать своими руками. Например, на знак отличия За наставничество меня никто не подавал. Генеральный директор НПО Аврора Константин Юрьевич Шилов спросил меня, как я его получил, а потом резюмировал: Я так и думал, что тебя никто не выдвигал. Можно добраться до высот и без помощи со стороны. Надо только при этом очень в себя верить, и чтоб очень уж сильно не мешали.

Дома у вас есть артефакты, вызывающие приятные воспоминания?

Главное приятное воспоминание это как мне вручали в Кремле знак отличия За наставничество. Раньше было три вида знаков отличия: Георгиевский кавалер четырех степеней, который в мирное время практически не вручают, а также знаки отличия За благодеяния и За безупречную службу (для гражданских и военных). И вот учредили четвертый знак отличия За наставничество. Я получил его под номером три указ Президента РФ на трех человек был, а у меня фамилия на Ш. Я троек никогда не получал, и это лучшая тройка в моей жизни. Очень горжусь.

Еще у меня есть фото, как мы в 2008 году с Парфеновым, Васильевым и двумя мальчишками: нашими выпускниками Матвеем Казаковым и Георгием Корневым, получили премию Правительства России в области образования. Тогда в Белом доме (не волнуйтесь в том, что в Москве) награждали, а через 10 лет в Кремле. Все, что у меня есть, выкладываю на сайт is.ifmo.ru, там у меня своего рода музейчик. Я просто считаю, что если ты не Достоевский и не Толстой, надо самому о себе позаботиться. Потому что о Достоевском и Толстом напишут журналисты и историки, а о тебе вряд ли.

В моей человеческой истории главное то, что я в 2008 году придумал сохранять в университете лучших. Люди есть разные. Есть те, кто мечтает работать в промышленности. Есть те, кто стремится уехать на Запад. Я же хочу, чтобы они оставались здесь, иначе все погибнет. И вот я занимаюсь этими суперталантливыми детьми и бьюсь за то, чтобы они оставались не в России даже, а на нашей кафедре. Потому что тогда будет кому учить других, а если будем учить только мы с Парфеновым, то все быстро закончится. Это моя главная миссия. Когда пять чемпионов мира по программированию и два призера этих чемпионатов, а также большое число очень талантливых молодых людей постоянно работают на кафедре, это по нынешним временам большое достижение.

После седьмой победы команды Университета ИТМО в чемпионате мира по программированию, 2017 годПосле седьмой победы команды Университета ИТМО в чемпионате мира по программированию, 2017 год

Один человек спросил меня: У парня есть куча офферов из западных контор, а он остается в ИТМО на кафедре. Как это?. Я отвечаю: Очень сложно оставить первого. Второго уже легче. А пятый у нас Гена Короткевич, который семь раз подряд выиграл Google Code Jam и пять из шести Яндекс. Алгоритм, да и много чего еще.

Геннадий Короткевич самый титулованный спортивный программист в миреГеннадий Короткевич самый титулованный спортивный программист в мире

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

Вручение знака отличия За наставничество. 2018 годВручение знака отличия За наставничество. 2018 год

Университет ИТМО последние годы стремительно развивается и добивается выдающихся результатов. Cамое удивительное, что у нас пять лет назад появились выдающиеся химики, и через три года наш университетпо публикационной активности занял по химии первое (!) место в стране. Пришли два брата Виноградова Александр и Владимир. Они родом из Иваново, после аспирантуры работали один в Израиле, другой в Германии, а хотели работать вместе. В Университете ИТМО это у них получилось. К ним пришли работать ученые из хороших мест. Например, профессор Екатерина Скорб пришла в ИТМО после Института Макса Планка и Гарварда. Однажды в интервью она произнесла одну из лучших фраз о науке, что я когда-либо слышал: Если ко мне подходит молодой человек и спрашивает, стоит ли ему заниматься наукой, я отвечаю: Вам не стоит. Такой вопрос не должен задаваться. Я с детства хотел заниматься наукой, это не случайно получилось. Если человек сомневается, значит, ему стоит заняться чем-то другим.

И еще. Моя книга, посвященная 25-летию кафедры, где я уже больше 20 лет работаю, называется: Мои счастливые годы на кафедре Компьютерные технологии Университета ИТМО. Вот так. Желаю, чтобы и вы могли так сказать или написать о своей работе!

Подробнее..

PAL, GAL и путешествие в цифровое ретро

06.01.2021 02:13:18 | Автор: admin
Идея сделать цифровые логические микросхемы с изменяемой структурой была всегда. Почему? Достаточно посмотреть на толстенный каталог чипов серии TTL 74xx (или советской К155), чтобы такая идея самозародилась. В СССР почти у каждого инженера и радиолюбителя был справочник В.Л. Шило Популярные цифровые микросхемы, который вышел каким-то невероятным тиражом. Но всё равно, хотелось иметь некий универсальный кристалл, из которого можно сделать все остальные микросхемы (ну хорошо, не все, но многие).

Конечно же, полупроводниковая промышленность тоже была не прочь удовлетворить такой спрос. Поэтому, начиная с конца 1960-х, на рынке каждый год появлялось огромное количество подобных устройств из класса PLD (Programmable Logical Device), самых разнообразных архитектур. Это было интереснейшее время! На рынке постоянно появлялось что-нибудь новенькое. Здесь были и различные ULA и БМК и EPROM-устройства на базе пережигаемых перемычек (82Sxxx) и PLA, у которых программировались оба слоя: И и ИЛИ (привет нашим К556РТ1 и К556РТ2) и т.д. Обзор этих ретро-технологий тема для отдельной статьи. Мы же сделаем лишь обзор того, что выстрелило и стало мэйнстримом.

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

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

MMI


Так вот, в далекие 1970-е годы компания-производитель ПЗУ Monolithic Memories Inc. (MMI) выпустила на рынок очередное семейство программируемых чипов. Семейство ВНЕЗАПНО оказалось настолько удачным, что в 1978 году MMI зарегистрировала торговую марку PAL (Programmable Array Logic) и стала лицензировать технологию таким гигантам, как Texas Instruments (серия TIBPAL), National Semiconductor, Philips (PLUS), AMD (AMPAL) и другим.


Даже в СССР не отставали и выпустили клоны, серию К1556.


В чем же секрет? Спроектированное инженерами и для инженеров семейство MMI PAL представляло собой практически чистое воплощение идеи ДНФ (Дизъюнктивная Нормальная Форма).

Здесь надо сделать логическое отступление и взглянуть, что же это такое, ДНФ и откуда оно взялось.

Матлогика


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

Лирическое отступление: есть огромное искушение ничего не писать, а просто посоветовать взять и прочитать недавно переведенный учебник Харрис&Харрис Цифровая схемотехника и архитектура компьютера, а конкретно главу 2 Проектирование комбинационной логики. Это отличная книга! Там даже есть параграф про PAL (п.5.6 Матрицы логических элементов), но такое ощущение, что его безжалостно сократили в очередной редакции.

А для тех, кто захотел канонично, от печки, разобраться в предмете поглубже (бывает!) можно порекомендовать книги 60-х годов по проектированию ЭВМ. Например, книгу Синтез цифровых автоматов В.М. Глушкова (тот самый, который ОГАС!) (М. Государственное издательство физико-математической литературы, 1962г). Книга настолько олдовая, что фамилия Карно записывается как Карнаут. Или можно предложить книгу Синтез схем электронных цифровых машин (Е.Н.Вавилов, Г.П.Портной М. Советское радио 1963).

В современных отечественных учебниках, чем дальше, тем больше этот раздел ужимается.
Например учебник Угрюмов Е.П. Цифровая схемотехника издания 2007 года еще содержал главу про PAL, а издания 2010 уже нет. В настоящее время данная наука почти полностью перекочевала в пыльные бумажные методички кафедр по специальности 230101. Вдобавок, попытка дать студентам этот материал наталкивается на стойкое сопротивление: разговоры про основы воспринимаются учащимися как too old то есть как совершенно ненужный, устаревший хлам. Даже тут, на Хабре есть несколько статей на данную тему, и комментарии наполнены стонами Да-да! Нас тоже зачем-то насиловали этим весь первый курс!.

Так вот, автор сбрасывает себя обязанность писать про пресловутые основы. Предполагается, что читатель, который заглянул на огонек, всё-таки понимает, что такое булева алгебра, что такое И, ИЛИ, НЕ, знает теорему де Моргана и умеет читать схемы на логических элементах.

ПРИМЕЧАНИЕ: Мне тут подсказывают, что в современном курсе цифровой электроники эта дисциплина (Дискретная математика) и Цифровая схемотехника чаще всего разделены на два предмета и учебники у них разные. А Харрис&Харрис в попытке впихнуть все в одну книгу породил монстра на 1600 страниц. Ну OK.

Ах да, ДНФ. В старых книжках говорится (объясняется почему), что при достаточно сложном логическом выражении его лучше всего представить (и это можно сделать для любого выражения!) в виде дизъюнктивной нормальной формы (sum of product, SOP). Несмотря на страшное название, это очень просто. Возьмем логическую функцию Y от трех переменных, A, B, C. Пусть она принимает значение истина тогда и только тогда, когда все три входные переменные равны нулю или же все они равны единице. В ДНФ это запишется крайне просто:



Это так называемая алгебраическая форма. Операция ИЛИ тут записывается как +, а операция И как умножение и, как в обычной алгебре, опускается. Так получилось, что существует множество форматов записи (синтаксисов) булевых выражений. Вот в другой записи:



Си-шное выражение для bool переменных:



Или даже так (синтаксис PALASM):



То есть ДНФ (в алгебраической форме) выглядит как цепочка сложений т.е. многочлен (логическое ИЛИ) из произведений (логическое И) входных переменных (sum of product), причем только тех комбинаций, для которых должна получаться истина. Интуитивно это довольно понятно: Истина, когда это И это, ИЛИ же когда то И то. Как выше упоминалось, в форме ДНФ можно представить любое логическое выражение (и помним, что мы не углубляемся в СДНФ, КНФ, СКНФ, критерий Поста и т.д.).

Оптимизация, оптимизация


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

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

Для изучения механизма работы карты Карно можно, опять же, отправить к учебнику Харрис&Харрис глава 2.7. Но очень уж изящное решение! Кроме того, карты Карно иногда спрашивают на собеседованиях. Карты Карно предназначены для визуального безкомпьютерного упрощения выражений с количеством переменных до 6.

Давайте посмотрим на типичную карту Карно, например на 4 переменных:


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



Если попытаться изобразить в 3D карту Карно для 4-х переменных, ее можно будет представить как развертку такого угловатого тора, имеющего 16 граней (нарисовано в OpenSCAD ).


Возвращаясь к PAL


Обогатившись такими знаниями, давайте вернемся к нашим PAL-кам и посмотрим на их внутреннее устройство. И опять же, хорошим подспорьем тут будет учебник Харрис&Харрис Цифровая схемотехника и архитектура компьютера, а конкретно параграф про PAL (п.5.6 Матрицы логических элементов).

При разработке PAL применяется своеобразная графическая запись, первоначально, видимо, предназначенная для ручного кодирования (до появления PALASM).

Давайте возьмем одну ячейку PAL, самого классического PAL16L8:


Итак, сверху вниз идут колонки входные переменные. Из них: 10 шт. это самые настоящие входы, то есть ножки микросхемы, а 6 шт. это возвраты внутри чипа, что позволяет создавать более сложные многоступенчатые выражения. Понятно, что каждая из этих 16 переменных существует в прямой и инверсной форме, итого мы видим 16*2=32 колонки. Слева мы видим ввод одной переменной в матрицу, в прямом и инверсном виде (вывод 2).

Все эти вертикальные переменные одновременно поступают на элементы И, которые могут использовать некоторые их них (а могут не использовать). Схема примерно такая (тут нарисованы две входные переменные и два элемента И):


Мы видим плавкие перемычки (fuse, F1..F4 и F5..F8), которые задают, какие переменные подключены к И. Именно эти fuse и программируются и задают логическую функцию PAL. Картинка получается довольно громоздкая, поэтому применяют такую сокращенную графическую запись (крестики это подключенные входы):


Вернемся к схеме ячейки PAL:


Как видите, в каждой строке (горизонтали) можно собрать функцию И из 16 (32, учитывая инверсию) возможных входов (переменных). То есть такая вот строка это на самом деле 32-входовый элемент И (программируемый). Чуть позже мы посмотрим, как эти соединения выглядят в прошивке.

Далее по схеме мы видим, что в PAL16L8 имеется 7 штук таких И-шек, объединенных по ИЛИ. Структура у ИЛИ у PAL фиксированная (в отличии от PLA и других архитектур) и не программируется. Кстати, обратите внимание, можно использовать меньшее количество ИЛИ (просто не задавая функций у И в ячейке), а вот больше нельзя!

Как несложно заметить, такая конструкция и является физической реализацией ДНФ или SOP (Sum Of Product то есть сумма произведений). Бинго!

Такие устройства стали называться SPLD (Simple PLD) в противовес CPLD (Complex PLD) и FPGA. Про CPLD кстати, имеется отдельная статья.

Такая простая и элегантная конструкция быстро стала чрезвычайно популярной и стала быстро вытеснять остальные семейства. Вот почему такие гранды, как AMD, Philips, National Semiconductor лицензировали ее.

Популярность PAL-ок пришлась на середину 80-х и начало 90-х. Многие производители чипов, прямо в Datasheet-ах публиковали листинги на PALASM для подключения своих микросхем к другим чипам и к разнообразным микропроцессорным шинам. Некоторые платы начала 90-х представляли собой россыпи PAL-ок, на которых были реализованы сложнейшие схемы. Это позволяло быстро выйти на рынок, до начала производства заказных микросхем LSI. (Погуглите, ну скажем, картинки материнской платы EISA i486 Everex Step Mega Cube или Intel iSBC 386. Все узкие микросхемы с бумажками это PAL ).

Сейчас эту нишу занимают CPLD и FPGA.

Компания MMI выпускала книжки, содержащие массу примеров применения своих микросхем, которые сопровождались забавными рисунками (извините, утащил).


Или даже так, ужас-ужас (Текст: В этой конструкции одна PAL16R8 заменяет 15 TTL микросхем малой и средней степени интеграции ):


Семейство PAL было довольно обширное. Существовали разновидности на разное количество ячеек и входов. Были разновидности с триггерами, что позволяло делать на них синхронные схемы и даже маленькие конечные автоматы (например PAL16R8). Существовали универсальные (Versatile) разновидности, в которых можно выбирать комбинаторную логику или триггера (PAL16V8). Существовали чуть более крупные PAL-ки в 24-выводном корпусе, типа PAL22V10. Микросхемы могли быть упакованы в различные корпуса и могли быть разной скорости, от -5 до -25 наносекунд. Наконец, существовали низкопотребляющие варианты и варианты в CMOS исполнении (например Texas Instrument TICPAL или Cypress Semiconductor PALC).


PALASM


Невероятный успех микросхемам PAL фирмы MMI принёс еще один компонент, без которого покорение рынка было бы немыслимо. Это утилита PALASM. С ее помощью создание прошивки для PAL стало делом настолько легким и простым, что любой инженер с нормальной подготовкой, понимал идею практически сразу. В PALASM вводится названия пинов и логические выражения в человеческой алгебраической форме (которые обычно выглядят как ДНФ), после чего PALASM выдает файл прошивки для программатора (JEDEC). Грубо говоря, компания MMI сделала тот шаг, который когда-то в 1950-е прошли обычные компьютеры, при переходе от ручного выписывания двоичных кодов к более понятной записи выражений машинного языка (ассемблера). А сам PALASM первых версий, в свою очередь, был написан на языке FORTRAN IV и распространялся в исходных текстах, что позволяло запускать его на любой тогдашней машине, где был компилятор, вплоть до ранних персоналок под CP/M и DOS. Да, да, когда-то FORTRAN был общим системным языком для переноса программ

Позже вышел PALASM2, синтаксис немного изменился, оброс разнообразными возможностями, появилось некоторое подобие макросов, оптимизатор, поддержка конечных автоматов и даже симулятор. Компания MMI тоже претерпела изменения, ее активы были поглощены AMD, потом выделены в отдельную компанию Vantis, которую позже купила Lattice Semiconductor. Сам входной язык PALASM послужил прообразом множества подобных и более продвинутых языков, его следы есть в ABEL, CUPL и в VHDL (а вообще-то он сам вырос из FORTRAN-а ).

Наиболее развитый PALASM это версия PALASM4 v1.5a от AMD 1992 года. Понятно, что такая ретро-программа требует для запуска ретро-DOS. Но к счастью, этот вопрос давно решен. Тут нам поможет прекрасная утилита DOSBOX, позволяющая запускать DOS-программы даже на современном Windows 10 64-бит. Хотя DOSBOX вообще-то, предназначен для запуска ретро-игр, но и не-игровые DOS-утилиты неплохо в нем живут и PALASM не исключение. Компания AMD сделала широкий жест и отпустила PALASM в Public Domain, так что пользоваться им можно совершенно легально.

Тут можно найти инструкцию, как поставить PALASM на DOSBOX и также скачать саму программу. Конфигурационный файл DOSBOX хранится в профиле пользователя
C:\Users\%USERNAME\AppData\Local\DOSBox\ dosbox-0.74.conf
Лучше дополнить секцию [autoexec]:

......[autoexec]# Lines in this section will be run at startup.# You can put your MOUNT lines here.@echo offmount c c:\DOSBOXset PALASM=C:\PALASMset PATH=%PATH%;C:\PALASMC:

Из под Linux тоже можно запустить PALASM например с помощью того же DOSBOX или похожего DOSEMU.

Из PAL в GAL


При всём своём удобстве PAL-ы имели и некоторые проблемы. Одна из таких проблем состоит в том, что PAL это однократно программируемое устройство (OTP) с плавкими титано-вольфрамовыми перемычками (Ti-W fuse). При появлении исправлений и замене прошивки приходилось старую микросхему просто выкидывать. Так что многие производители стали предлагать стираемые PAL-ки. История тут длинная, можно, например, вспомнить УФ-стираемые чипы с окошечком, или тот факт, что очень хотелось сохранить совместимость с парком программаторов и алгоритмами прошивки оригинальных PAL (серии PALCE и PEEL от International CMOS Technology (ICT) Corporation) и т.д.

Наконец фирма Lattice Semiconductor в 1985 г. выпустила семейство GAL, которое можно считать своеобразной вершиной PAL-строения. Подобно исходным MMI PAL-ам c буковкой V ( Versatile) (например PAL16V8) чипы GAL (соответственно название будет GAL16V8) могут принимать прошивки ВСЕХ (ну почти) моделей PAL, а вдобавок чип GAL электрически стираемый и многократно прошиваемый. Устройства GAL практически вытеснили все остальные SPLD, за исключением, пожалуй Atmel (нынче Microchip) серии ATF (аналогичный чип у них будет называться ATF16V8).


Для переноса JEDEC файлов (прошивок) старых PAL фирма Lattice Semiconductor выпустила утилиту PALTOGAL (тоже бесплатную и тоже под DOS).

ПРМЕЧАНИЕ: Фирма Lattice Semicronductor рекомендует использовать для разработки ABEL (пакет ispLEVER), а фирма Atmel CUPL (WinCUPL или ProChip Designer). National Semiconductor предлагала свой Opal JR. Но мы в ретро-целях останемся верны PALASM.

ПРИМЕЧАНИЕ2: (для совсем нердов) У GAL все же есть некоторые мелкие отличия, связанные с тем, что MMI PAL это ТТЛШ микросхема, а GAL CMOS.

И конечно же, для прошивки микросхем GAL (и ATF) потребуется специальный программатор. Существуют и PAL-ы, прошиваемые по JTAG, но это редкость (Lattice ispGAL). Хотя программатор для GAL можно сделать самостоятельно (ищется по именам GALBLAST и ATFBLAST), всё же лучше приобрести готовый. Например, TL866 (известный еще как Minipro), которыми забит Aliexpress:


Сами чипы GAL или ATF можно приобрести на том же Aliexpress. Цена за десяток может доходить до 5$ и менее. Не стоит ожидать чудес, чипы будут б/у (помним, что их можно и нужно(!) стереть) и могут иметь следы пайки и маркировку краской или лазером от погибших неведомых устройств, откуда их вытащили трудолюбивые китайцы. Lattice GAL сняты с производства в 2011, но запасов из старой техники хватит еще на пару десятков лет. ATF еще выпускаются.

7-SEG LED


Если помните, в начале статьи мы собирались зажечь светодиод. А точнее не один, а целых семь! Да- да, речь пойдет о 7-сегментном индикаторе, а точнее о реализации банального дешифратора HEX-to-7SEG.


Почему-то так сложилось, что готовых микросхем с такой функцией не так уж и много. Есть десятичные BCD дешифраторы (т.е. без шестнадцатеричных символов ABCDEF), например 7446/7447/7448/7449 и 74246/74247/74248/74249). Полных HEX дешифраторов не так много например Motorola MC14495 Hexadecimal-to-Seven Segment Driver или Fairchild DM9368.

Но цены на PAL (GAL) упали настолько, что сделать дешифратор на SPLD дешевле и быстрее! Вот и давайте для практики его и сделаем, включая шестнадцатеричные цифры ABCDEF (Нет, ЕГГОГ мы декодировать не будем ). Отличное приложение наших олдскульных знаний по матлогике и старым программируемым микросхемам.


Построение такого дешифратора является каноническим примером комбинационной логики и типовой лабораторной работой. В учебнике Харрис&Харрис Цифровая схемотехника и архитектура компьютера пункт 2.7.2 Логическая минимизация на картах Карно содержит пример 2.10 построения такого дешифратора, но только BCD.

На Википедии есть статья, в которой даже приведена нужная нам таблица перекодировки для полного HEX.

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


Давайте для примера рассмотрим сегмент D (нижний). Как мы видим, он загорается 11 раз из 16 возможных входных комбинаций (вертикаль d). Если выписать ДНФ, то формула будет такой:



Но здесь есть проблема! Как мы писали выше, матрица обычных PAL (например в PAL16L8) имеет только 7 ИЛИ (сложений), а у нас 11. Надо или применять более сложный чип или выражение придется оптимизировать.

ПРИМЕЧАНИЕ: В PALASM4 есть встроенный оптимизатор. Вероятно, он смог бы упростить это выражение, только надо эту оптимизацию включить. Но для сохранения ретро-духа пройдем этот этап вручную.

Давайте оптимизируем это выражение по карте Карно. Можно сделать это вручную и получить удовольствие, а можно воспользоваться сайтами, где на JavaScript реализованы эти алгоритмы, например:


На втором сайте в качестве переменных можно вводить: D3,D2,D1,D0. Далее, вводятся номера единичных минитермов (фактически, это входные числа, для которых загорается сегмент D), у нас это 0,2,3,5,6,8,9,11,12,13,14 (0,2,3,5,6,8,9,B,C,D,E) проверяем по красным клеточкам.


Как видите, наше выражение для сегмента D превращается в короткое:


Тут всего 5 штук ИЛИ вместо 11 так что выражение влезает в ячейку PAL. Проделаем это для всех сегментов.

Получается такой файл PALASM 7SEG.PDS
;PALASM Design Description;-------------- Declaration Segment ------------TITLE 7-SEG LED decoderPATTERN 7SEG.PDSREVISION AAUTHOR ALECVCOMPANY HABRDATE 01/01/90CHIP DECODER PAL16L8;-------------- PIN Declarations ---------------;PINS  1  2  3  4  5  6  7  8  9  10      NC D0 D1 D2 D3 NC NC NC NC GND;PINS 11 12 13 14 15 16 17 18 19  20      NC NC G  F  E  D  C  B  A VCC;--------------- Boolean Equation Segment ------EQUATIONS/A = /D0*/D2 + /D0*D3 + D1*D2 + D1*/D2*/D3 + D0*D2*/D3 + /D1*/D2*D3/B = /D2*/D3 + /D0*/D2 + /D0*/D1*/D3 + D0*D1*/D3 + D0*/D1*D3/C = D0*/D1 + D0*/D2 + /D1*/D2 + D2*/D3 + /D2*D3/D = D2*/D1*D0 + /D3*/D2*/D0 + /D2*D1*D0 + D2*D1*/D0 + D3*/D1/E = /D0*/D2 + D2*D3 + /D0*D1 + D1*D3/F = /D0*/D1 + /D2*D3 + D1*D3 + /D0*D2 + /D1*D2*/D3/G = D1*/D2 + D0*D3 + /D2*D3 + /D0*D1 + /D1*D2*/D3;------------- Simulation Segment -------------SIMULATIONTRACE_ON A B C D E F GSETF /D3 /D2 /D1 /D0    ; 0SETF /D3 /D2 /D1  D0    ; 1SETF /D3 /D2  D1 /D0    ; 2SETF /D3 /D2  D1  D0    ; 3SETF /D3  D2 /D1 /D0    ; 4SETF /D3  D2 /D1  D0    ; 5SETF /D3  D2  D1 /D0    ; 6SETF /D3  D2  D1  D0    ; 7SETF  D3 /D2 /D1 /D0    ; 8SETF  D3 /D2 /D1  D0    ; 9SETF  D3 /D2  D1 /D0    ; ASETF  D3 /D2  D1  D0    ; BSETF  D3  D2 /D1 /D0    ; CSETF  D3  D2 /D1  D0    ; DSETF  D3  D2  D1 /D0    ; ESETF  D3  D2  D1  D0    ; FTRACE_OFF

Откомпилируем файл .PDS в файл .JED с помощью PALASM:


Очень интересно, как PALASM разложил наши выражения на плавкие перемычки. Для этого можно заглянут в файл Fuse plot (рисунок перемычек).

Fuse plot файл 7SEG.XPT
PALASM4  PAL ASSEMBLER   - MARKET RELEASE 1.5a (8-20-92) (C) - COPYRIGHT ADVANCED MICRO DEVICES INC., 1992TITLE   :7-SEG LED decoder        AUTHOR :ALECV                    PATTERN :7SEG.PDS                 COMPANY:HABR                     REVISION:A                        DATE   :01/01/90                 PAL16L8DECODER                   11  1111  1111  2222  2222  2233       0123  4567  8901  2345  6789  0123  4567  8901  0    ----  ----  ----  ----  ----  ----  ----  ----    1    -X--  ----  -X--  ----  ----  ----  ----  ----    2    -X--  ----  ----  X---  ----  ----  ----  ----    3    ----  X---  X---  ----  ----  ----  ----  ----    4    ----  X---  -X--  -X--  ----  ----  ----  ----    5    X---  ----  X---  -X--  ----  ----  ----  ----    6    ----  -X--  -X--  X---  ----  ----  ----  ----    7    XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    8    ----  ----  ----  ----  ----  ----  ----  ----    9    ----  ----  -X--  -X--  ----  ----  ----  ----    10   -X--  ----  -X--  ----  ----  ----  ----  ----    11   -X--  -X--  ----  -X--  ----  ----  ----  ----    12   X---  X---  ----  -X--  ----  ----  ----  ----    13   X---  -X--  ----  X---  ----  ----  ----  ----    14   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    15   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    16   ----  ----  ----  ----  ----  ----  ----  ----    17   X---  -X--  ----  ----  ----  ----  ----  ----    18   X---  ----  -X--  ----  ----  ----  ----  ----    19   ----  -X--  -X--  ----  ----  ----  ----  ----    20   ----  ----  X---  -X--  ----  ----  ----  ----    21   ----  ----  -X--  X---  ----  ----  ----  ----    22   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    23   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    24   ----  ----  ----  ----  ----  ----  ----  ----    25   X---  -X--  X---  ----  ----  ----  ----  ----    26   -X--  ----  -X--  -X--  ----  ----  ----  ----    27   X---  X---  -X--  ----  ----  ----  ----  ----    28   -X--  X---  X---  ----  ----  ----  ----  ----    29   ----  -X--  ----  X---  ----  ----  ----  ----    30   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    31   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    32   ----  ----  ----  ----  ----  ----  ----  ----    33   -X--  ----  -X--  ----  ----  ----  ----  ----    34   ----  ----  X---  X---  ----  ----  ----  ----    35   -X--  X---  ----  ----  ----  ----  ----  ----    36   ----  X---  ----  X---  ----  ----  ----  ----    37   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    38   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    39   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    40   ----  ----  ----  ----  ----  ----  ----  ----    41   -X--  -X--  ----  ----  ----  ----  ----  ----    42   ----  ----  -X--  X---  ----  ----  ----  ----    43   ----  X---  ----  X---  ----  ----  ----  ----    44   -X--  ----  X---  ----  ----  ----  ----  ----    45   ----  -X--  X---  -X--  ----  ----  ----  ----    46   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    47   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    48   ----  ----  ----  ----  ----  ----  ----  ----    49   ----  X---  -X--  ----  ----  ----  ----  ----    50   X---  ----  ----  X---  ----  ----  ----  ----    51   ----  ----  -X--  X---  ----  ----  ----  ----    52   -X--  X---  ----  ----  ----  ----  ----  ----    53   ----  -X--  X---  -X--  ----  ----  ----  ----    54   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    55   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    56   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    57   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    58   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    59   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    60   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    61   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    62   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX    63   XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX  XXXX     SUMMARY -------      TOTAL FUSES BLOWN    = 1262

Этот файл лучше рассматривать одновременно с документацией на PAL16L8. Ее можно найти, например, на сайте Texas Istruments: pal16r8am.pdf страница 5.

Сегмент D у нас выведен на 16-й вывод микросхемы. Если мы посмотрим схему PAL, то за него отвечают перемычки, начиная с номера 768. Как несложно догадаться 768 / 32 = 24 это 24-я строка. Сама она отвечает за управление выходом и поэтому пустая. Логические выражения начинаются с перемычки 800, то есть строки 25. Если посмотреть на схему, то в 25-й строке собираются по И: прямой вход D0 (вывод микросхемы 2), инверсия D1 (вывод 3) и прямой вход D2 (пин 4). Это в точности соответствует первому минитерму в формуле для сегмента D! Остальные минитермы из выражения также транслируются в перемычки и в конце объединяются по ИЛИ. Так что PALASM, не мудрствуя лукаво, просто переводит наши ДНФ-выражения в прошивку один в один.

Именно таким способом проектировали прошивки до появления PALASM, в самой старой документации MMI как раз описан этот способ. Надо отметить, что другие семейства, например PLA, не получили вообще или получили утилиты класса PALASM довольно поздно (например ICT PEEL Array PLACE) и не стали такими популярными.

Для программирования GAL полученный файл 7SEG.JED отконвертируем утилитой PALTOGAL:

PALTOGAL C2 R 7SEG.JED 7SEG_GAL.JED

При подключении индикатора к FPGA (на VHDL и Verilog) или к микроконтроллеру логические функции раскладывать нет необходимости и просто используют таблицу. Можно погуглить или посмотреть на Youtube, поиск Семисегментный индикатор.

Практика


Давайте соберем модель декодера семисегментного индикатора (и сдадим курсовик, ха-ха). В качестве генератора импульсов применим обычную микросхемку NE555 (К1006ВИ1). Для наблюдения нам нужен период примерно 1 секунда. Для делителя на 16 в коде 1-2-4-8 можно применить что-нибудь типа К155/К555 ИЕ5 или ИЕ7 (совсем круто было бы сделать счетчик тоже на GAL, но это в следующий раз). В коробочке нашлась К555ИЕ7 (SN74LS193), значит так тому и быть. На вывод R подадим ноль, на выводы V и -1 единицу, на вывод +1 тактовые импульсы с NE555. Счетчик начал считать. Возьмем семисегментный индикатор с общим анодом и нашу GAL. Перед этим сотрем её и прошьем JEDEC файлом. Индикатор попался LTS-4801WC, OK. Выводы счетчика Q0,Q1,Q2,Q3 соединим со входами D0,D1,D2,D3 GAL, а выходы GAL с катодами индикатора через 7 резисторов на 330 Ом.

Получается как-то так:


Заключение


Итак, мы окунулись в историю программируемых логических микросхем (PLD). Мы увидели, что за конструкцией PAL скрывается Древняя Могучая Теория. Выяснилось, что даже сейчас, вполне еще можно применять эти устройства в небольших самоделках. Мы рассмотрели вполне боевой workflow, как это сделать. И да, PAL и GAL совместимы с олдовой теплой 5V TTL электроникой.

Конечно, в такой короткой статье невозможно отразить все аспекты. Вот кратко, про что мы не рассказали:

Не рассмотрели работу симулятора. В PALASM (2 и 4) встроен довольно мощный симулятор, практически язык программирования, с циклами, условными операторами и т.д.

Не рассмотрели построение на PALASM конечных автоматов. Как-нибудь в другой раз.

Не рассмотрели тонкости и ограничения оптимизации, но зато сделали оптимизацию вручную, по карте Карно. Это исключительно в ретро-целях! Сейчас так никто уже не делает (как и сами разработи на PAL).

Не ответили на вопрос: можно ли вводить в PALASM выражения не в ДНФ? Конечно можно. Если выражение синтаксически корректно, PALASM скорее всего его поймет. Но внутри все равно преобразует в ДНФ для воплощения в перемычках.

Не рассмотрели вопрос программирования (прошивки) исходных MMI PAL. Проблема здесь в том, что это однократно программируемые микросхемы и сейчас довольно сложно найти чистые PAL. И их не стереть. А программировались они специальным программатором (например, российский Стерх это умеет). Изначально у MMI был даже метод прошивать PAL как ПЗУ 512x4 на старых программаторах с помощью специальной personality card у первых PAL было ровно 2048 перемычек, но ныне этот способ утрачен.

И еще много чего.
Подробнее..

О русском языке в программировании

03.01.2021 18:23:42 | Автор: admin

Введение

Начну с мелочи. Удобно ли сейчас организована типичная смена раскладки клавиатуры? В смысле переключения на русский/латинский? На мой взгляд, в смартфонах и то удобнее. Не надо нажимать одновременно все эти Shift и Alt. На моем первом домашнем компьютере Электроника-901 (он же ai-PC16) было даже две специальных пустых клавиши примерно там, где сейчас клавиши-окна. Одна переключала на русскую раскладку постоянно, а другая - временно (на время нажатия). Это гораздо удобнее. Впрочем, самый удобный вариант переключения в свое время я сделал сам из массивной педали от швейной машинки Тула, просто соединив ее двумя проводами с контактами DTR и DSR разъема RS-232. В этом случае если программно установить бит DTR в 1, то наличие сигнала DSR означает, что педаль нажата, иначе отпущена. Переключать раскладку без рук оказалось очень эргономично. Увы, по мере распространения новых интерфейсов, RS-232 постепенно сошел на нет и сейчас в ноутбуке педаль просто некуда подключить.

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

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

Но, повторю, громоздкое переключение - это мелочь, не проблема, а, скорее, следствие отношения к использованию русского языка как к чему-то второстепенному и не стоящему внимания. Хотя и эта мелочь нет-нет, да и напомнит о себе, хотя бы в виде модной, но глупой аббревиатуры КВТ (вместо RSDN) на форумах сайта RSDN.RU.

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

Естественность использования родного языка

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

if (a==0 && b==0) return;

Т.е. мысленно про себя произношу если, уходим, а писать все-таки должен if, return. Незаметно приходится все время переводить, пусть и в самой простейшей форме. Поэтому для меня более естественна запись того же оператора в виде:

если a=0 и b=0 тогда возврат;

Я именно так и пишу. И это вовсе не псевдокод, а реальный оператор языка [1], где ключевые слова имеют русские эквиваленты, не требуется различать присваивание и сравнение (а, значит, не нужно удвоение символов), и логические операции можно писать просто как И, ИЛИ, НЕ. Оператор больше стал похож на мысленную фразу и перевод с мысленного русского на программный английский уже не требуется.

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

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

Разумные границы использования

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

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

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

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

Опыт использования родного языка

Если обратиться к собственному опыту использования родного языка, то считаю, что мне в какой-то мере даже повезло: период обучения и освоения пришелся на время, когда русский язык использовался не то, чтобы широко, но вполне естественно, поскольку применялись программные и аппаратные средства отечественной разработки. Как программист я начинал с БЭСМ-6, операционной системы ОС-Диспак, транслятора БЭСМ-АЛГОЛ и диалоговой программы Пульт (при этом работа за терминалом VT-340 очень напоминала работу за первыми персональными компьютерами). В те времена даже в кодовой таблице сначала шел русский алфавит, а затем латинские буквы, отличающиеся по написанию от кириллицы. Вся документация была, естественно, на русском, например, в описании команд БЭСМ-6 все аббревиатуры команд были кириллицей, не было никаких MOV или JMP.

В отличие от ЕС-ЭВМ, в направлении БЭСМ (и Эльбрус) все оставалось по-русски. Правда, до тех пор, пока не появилась разработка дубнинского ядерного центра мониторная система Дубна, в составе которой был ассемблер (тогда такие языки назывались автокодами) со странным именем Мадлен. Так как транслятор сначала переводил на него, некоторые сообщения об ошибках выдавались на уровне ассемблера. И все они были по-английски! Получалось, что одни советские программисты писали сообщения для других советских программистов не на родном языке. Разумеется, Дубна изначально была предназначена для совместной работы где-нибудь в ЦЕРН, поэтому там и было все в международном варианте. Но нам она была поставлена как отечественная система и при этом бесцеремонно отодвинула от родного языка. Например, аббревиатуры команд в Мадлен стали не такими как в исходной документации на БЭСМ-6, что вызывало непонимание и раздражение.

Еще через несколько лет (для меня в 1987 году) в части родного языка все перевернулось с появлением американских персональных компьютеров. Объективно и естественно в первое время никакого русского языка там не было в принципе. Но поскольку это требовалось для набора текстов, приспосабливать их под родной язык все-таки пришлось. Т.е. пришлось перепрошивать ПЗУ видеокарт, наклеивать переводные картинки кириллицы на боковые стенки клавиш, учиться писать драйверы клавиатуры, попутно привыкая к аббревиатурам системы команд x86. Очень скоро русификацией компьютеров и принтеров уже занимались во многих организациях, имеющих ПК, и дело было поставлено буквально на поток. Но при этом русификацией получаемых вместе с компьютерами трансляторов обычно никто не занимался, в лучшем случае лишь переводились руководства.

Возможно, я стал одним из первых, кто озаботился этим и то лишь потому, что полученный вместе с IBM-PC/XT транслятор с языка PL/1 не позволял писать по-русски даже комментарии: все символы с кодом больше 7FН воспринимались им как управляющие. Из-за этого на первых порах комментарии выглядели как теперешние SMS по-русски с телефонов, не имеющих кириллицы. Но разрабатывать программы, не используя родной язык, было для меня совершенно недопустимым. Первое исправление транслятора, которое разрешило кириллицу, оказалось очень легким и привело к мысли дизассемблировать весь транслятор, чтобы стать полноправным владельцем и постепенно сделать его целиком русским. Учитывая, что в PL/1 ключевые слова не зарезервированы, можно иметь одновременно два варианта слов: английский и русский. Поэтому уже написанные программы можно было оставить английскими, зато новые программы можно было писать уже по-русски.

Впоследствии в транслятор было внесено множество доработок, приведенных в [1]. По части русификации были добавлены русские ключевые слова, включая И-ИЛИ-НЕ вместо знаков &, ! и ~. Такой перевод логических операций на русский сразу сделал тексты программ гораздо легче воспринимаемыми. Диагностические сообщения также были переведены и расширены. Много ли существует современных программных средств, которые выдают сообщения об ошибках на русском языке? А ведь это первое, с чем сталкиваются новички. Им и так-то бывает нелегко разобраться, что именно вызвало ошибку, а тут еще и сообщения не на родном языке. Поэтому часто даже вполне внятные сообщения начинают восприниматься ими одинаково: транслятор ругается, а поиск ошибок в тексте производится бессистемным образом, вне связи с полученным сообщением.

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

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

Заключение

На первый взгляд кажется, что сейчас никаких проблем с русским языком нет. Действительно, давно локализованы на национальные языки операционные системы, офисные программы и игры, а кириллица наносится на клавиши заводским способом. Но если обратится к программированию, то здесь русский язык почти полностью вытеснен. Конечно, есть и исключения, например, Бухгалтерия 1С. При этом я ни в коем случае не призываю создавать специально русские языки программирования (остряки сразу же добавят: православные). Напомню, что даже в самом первом международном документе по языку программирования [2] предполагалось три уровня его представления: эталонный, язык публикаций и конкретные представления. Т.е. с самого начала предполагалось, что знаки языка могут быть различными в разных странах, однако должно быть сохранено однозначное соответствие с эталонным представлением.

Сам я использую язык PL/1, созданный на Западе (большей частью в Великобритании), наличие готового транслятора с которого было в свое время даже одним из аргументов принятия в СССР решения копировать IBM 360 в виде ЕС ЭВМ. Но, возможно, обоснованное на тот момент решение в своей программной части в дальнейшем не было подкреплено развитием первоначально скопированного эталона. Конечно, сейчас с позиции послезнания легко советовать, что надо было делать тогда. Впрочем, и тогда многим это было понятно: урок освоения ОС ЕС ясен: можно, и иногда нужно осваивать отдельные образцы зарубежного программного обеспечения, но нельзя становиться на путь постоянного следования за ними [3].

Мой опыт энтузиаста-дилетанта (без профильного образования), показывает, что разобраться в существующем компиляторе не так уж и трудоемко. Коллектив из 4-5 человек где-нибудь в Академгородке сделал бы это быстро и качественно, например, с компилятором IBM для PL/1. Т.е. дизассемблировал бы его и научился транслировать и собирать точную копию исходного. И это надо было делать, конечно, не для русификации, а для того, чтобы стать хозяином транслятора и с этой стартовой площадки продолжить его развитие дальше, уже независимо ни от кого, снабжая армию пользователей ЕС ЭВМ качественным и, главное, совершенствующимся продуктом. А перевод на русский язык компилятора и других утилит был бы всего лишь бонусом, облегчающим сопровождение и использование. Но транслятор с языка PL/1 на ЕС ЭВМ так и не был освоен. Я делаю такой вывод потому, что он так и не был русифицирован, хотя попытки развить язык и были [5].

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

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

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

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

Использование русского языка отражает и общее состояние дел в развитии программирования. Пока в СССР шли собственные разработки - использовался, естественно, и русский язык, например, в таком выдающемся проекте, как Эль-76, где были задействованы большие силы всей страны: в разработке ПО для Эльбруса участвовал ряд университетов, включая Таллин и Кишинев. Прекратились разработки вот русский язык и исчез, а попытки возрождения, например, проект Национальной Программной Платформы, терпят неудачу.

Русский язык это то, что всех нас (и программистов и не программистов) объединяет. Использование родного языка в программировании является и признаком независимого развития этой отрасли и одновременно объективной базой такого развития.

Напоследок приведу исторический анекдот: когда Петр Первый организовывал выпуск нового российского рубля (монеты), ему советовали все надписи сделать на латыни, иначе, мол, такие деньги не будут принимать за границей. Спасибо тому скажу, кто придумает, как оставить деньги в Отечестве, а не тому, кто выведет их иноземцам ответил Петр.

Литература

1. Д.Ю. Караваев К вопросу о совершенствовании языка программирования RSDN Magazine #4 2011

2. А.П. Ершов, С.С. Лавров, М.Р. Шура-Бура Алгоритмический язык АЛГОЛ-60. Пересмотренное сообщение. Москва Мир 1965

3. Г.С. Цейтин Доклад Итоги освоения ОС ЕС (заметки пользователя) 29.08.1983

4. В.М. Табаков Специализированная система гиперпрограммирования для языка ПЛ/1 : диссертация кандидата физико-математических наук : 05.13.11. Калинин, 1984.

Подробнее..

Программистское везение

08.01.2021 14:08:13 | Автор: admin

Более двух десятков лет назад мы разрабатывали устройство, передающее и принимающее данные, используя телевизионный сигнал. Это сейчас все избалованы гигагерцами и гигабайтами, а тогда, имея компьютер типа IBM/PC-AT, на таких скоростях можно было работать только с помощью встроенного контроллера прямого доступа к памяти (ПДП), реализованного в виде микросхем 8237А-5. Это устройство позволяло писать или читать данные, не привлекая центральный процессор.

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

И вот, при заключительном просмотре текста, я вдруг увидел глупую описку в программировании ПДП. Адрес в 16-разрядной 8237А-5 приходилось задавать по частям и при задании номера станицы (т.е. номера куска памяти в 128 Кбайт) вместо команды

OUT DX,AL

было написано

OUT DX,AX

что совершенно бессмысленно, поскольку все используемые в ПДП порты 8-разрядные.
Исправил ляпсус, перетранслировал НЕ работает! Вернул опять бессмысленный AX вместо AL работает. Не может быть!

Начинаю рассуждать. Команда OUT выполняется ведь подобно обычной записи в память, только специальный сигнал INOUT на шине выставляется. Следовательно, если вместо AL я выдаю AX, то это равнозначно тому, что я в один порт (в данном случае 83H) выдаю значение из AL, а в соседний, т.е. получается в 84H значение из AH, а там в этот момент просто ноль.
А что это за порт такой? Вот же таблица всех портов из тогда единственной имевшейся у нас книги Фроловых Аппаратное обеспечение IBM PC:

Назначение и адреса регистров страниц контроллера для IBM AT:
81h Регистр страниц канала 2
82h Регистр страниц канала 3
83h Регистр страниц канала 1
87h Регистр страниц канала 0
89h Регистр страниц канала 6
8Bh Регистр страниц канала 5
8Ah Регистр страниц канала 7
8Fh Регенерация динамической памяти

Нет вообще здесь никакого порта 84H!

Честно говоря, я и сейчас не знаю, что это такое. Может быть, разрешение на работу данного ПДП из всего каскада, а может какая-то особенность конкретной материнской платы или еще одна часть адреса, позволяющая задать его больше чем 16 Мбайт.
Теперь, в эпоху Интернета, доступа к электронным библиотекам и компьютерным форумам, наверное, несложно докопаться, что именно делала запись нуля в неведомый мне порт 84Н. Но это уже неинтересно, поскольку все эти ПДП (DMA) давно ушли в прошлое вместе с шиной ISA и другими древними интерфейсами.

Однако речь о другом. Какое невероятное, прямо волшебное везение для программиста! Кто толкнул меня под руку написать AX вместо AL и именно в этом месте? Ведь ни в одном примере этого не было. Напиши я как положено AL, и мы провозились бы месяцы, подозревая, конечно, неправильную работу нового устройства, а не настройку ПДП. Да и как догадаться, что нужно обратиться к порту, которого даже нет в документации! А сроки были жесткие и не уложись мы в них, проект вообще был бы закрыт с наклеиванием на нас ярлыка неумех и неудачников.

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

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

Подробнее..

О специальных макро в ассемблере

16.01.2021 06:18:31 | Автор: admin

Введение

Много лет назад американским специалистом Гарри Килдэллом (Gary Kildall) в рамках создания системы программирования для персональных компьютеров был разработан транслятор с языка ассемблера для процессора Intel 8086, который он назвал RASM-86 (Relocating ASseMbler). Этот во многом типичный для своего времени продукт имел особенность: он позволял, не меняя транслятора, добавлять описания новых команд процессора с помощью специальных макросредств.

Автор статьи, используя и развивая этот транслятор, успешно применял данные средства по мере появления новых поколений процессоров. Конечно, иногда и сам транслятор требовал ряда доработок, например, при переходе на архитектуру IA-32, а затем и на x86-64 (IA-32e). Тем не менее, изначально заложенная идея позволила легко продолжать эволюцию транслятора до настоящего времени. Некоторые итоги этой работы рассматриваются далее.

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

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

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

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

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

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

Макросредства описания команд

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

CodeMacro AAA  DB 37HEndMCodeMacro DIV divisor:EbSEGFIX divisor  DB 6FHEndMCodeMacro OR dst:Re, src:Ee  SEGFIX src  DB 0BH  MODRM dst,srcEndM

Описание формальных параметров

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

Типы формальных параметров:

A  сумматор EAX/AX/ALC  выражение типа метка D  непосредственный операндE  адресное выражение, записанное в регистре или памятиM  адресное выражение, может иметь базовые и индексные регистрыR  один из общих регистровS  сегментный регистрX  прямое обращение к памяти при обмене с сумматором

Размеры формальных параметров

n - длина неопределеннаb  байтw  словоe  двойное словоd  длина при использовании адреса смещение+сегментsb  знаковый байт, расширяемый до словаse  знаковый байт, расширяемый до двойного слова

Примеры описания формальных параметров:

CodeMacro IN dst:Aw, port:Rw (DX)CodeMacro ROR dst:Ee, count:Rb (CL)

Директивы макроопределений

Первоначально все описания команд х86 свелись к нескольким директивам, часть из которых используются редко. Перевод транслятора на архитектуру IA-32 потребовал добавления лишь одной новой директивы управления префиксами размера/адреса 66H/67H, причем, чтобы не вводить новых ключевых слов используется уже имевшаяся директива, но с другой формой параметра.

Директивы DB, DW и DD

Данные директивы в макро почти эквиваленты обычным операторам ассемблера и используются для задания констант и адресов. Эти директивы характерны и для любых других (не специальных) макросредств.

Директива DW используется для задания адреса (4 байта в 32-х разрядном режиме), а директива DD для задания адреса в виде смещение+сегмент. Примеры использования DB, DW и DD:

CodeMacro CLC  DB 0F8HEndMCodeMacro XOR dst:Ee,src:De  SEGFIX dst  DB 81H  MODRM 6,dst  DW srcEndMCodeMacro CALLF label:Cd  DB 9AH  DD labelEndM

Директива адресации MODRM

Это главная из специальных директив, определяющая адресацию архитектуры IA-32. Она определяет и основное отличие данных макросредств от обычных. Именно микрокод, порождаемый этой директивой, указывает транслятору генерировать адресную часть команды, включая и байт режимов адресации и смещение и SIB-байт, если операнды подразумевают это. Директива имеет два параметра. Это или два имени формальных параметров макро или константа-число и имя. Например:

CodeMacro RCR dst:Ee, count:Rb(CL)  SEGFIX dst  DB 0D3H  MODRM 3,dstEndMCodeMacro XOR dst:Re,src:Ee  SEGFIX src  DB 33H  MODRM dst,srcEndM

Директивы определения относительного адреса RELB, RELW

Эти директивы используются для описания команд передачи управления по относительному адресу, занимающему или байт или 4 байта для IA-32. Пример:

CodeMacro LOOP place:Cb  DB 0E2H  RELB placeEndM

Директива задания кодов DBIT

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

CodeMacro DEC dst:Re  DBIT 5(9), 3(dst(0))EndM

Директива формирования префикса сегмента SEGFIX

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

Директива контроля сегментов NOSEGFIX

Директива имеет параметры в виде имени сегментного регистра и имени формального параметра. Она не генерирует кода, а проверяет, что обращение к данному параметру идет с использованием указанного сегментного регистра, иначе сообщает об ошибке. Эта директива требуется лишь в общих формах команд CMPS и MOVS, где один из операндов может адресоваться только через ES.

Данная директива была расширена для управления префиксами размера и адреса 66H/67H. В этом случае в директиве указывается параметр-число: 0 нет префиксов, 1- может быть префикс 66H, 2 может быть префикс 67H, 3 могут быть оба префикса, 4 всегда есть оба, 5 никогда нет 66H, 6 никогда нет 67H и т.п.

Такими простыми средствами удается описать все множество команд IA-32, например:

CodeMacro FLDCW src:Mw  SEGFIX src  DB 0D9H  MODRM 5, srcEndMCodeMacro CMOVAE dst:Re, src:Ee  SEGFIX src  DB 0FH  DB 43H  MODRM dst,srcEndM

Некоторое исключение из стройной системы описаний составляют команды FPU, имеющие операнд в памяти. Для простоты в RASM разрядность таких команд указывается прямо в мнемонике, а не определяется по размеру операнда в памяти. Поэтому в RASM есть, например, команды FIST16, FIST32 и FIST64. Однако на практике, с точки зрения ясности текста, указание разрядности операнда прямо в имени команды FPU оказалось вполне приемлемым.

Создание псевдокоманд с помощью макросредств

Используя возможность добавления новых комбинаций операндов можно конструировать новые команды процессора. Например, команду MOV ECX,10 часто целесообразно заменять двумя командами с более коротким кодом PUSH 10 и POP ECX. А эти две команды можно описать в виде одного макроопределения:

CodeMacro MOVSX dst:Re, src:Dse  NOSEGFIX 6  DB 6AH  DB src  DBIT 5(0BH),3(dst(0))EndM

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

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

MOV X,Y, где X,Y переменные в памяти;

MOV DS,0 или MOV DS,ES;

Команды PUSH и POP для нескольких регистров сразу, т.е. PUSH EAX,EBX,ECX;

Обращение к портам без указания регистра DX и т.п.

Добавление новых типов команд

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

При этом в транслятор иногда приходится добавлять и новую группу имен специальных регистров этих команд (внутри транслятора имена это просто переименованные числа). Так, коды имен регистров CR0-CR7 являются внутри транслятора RASM числами 10H-17H, коды имен регистров MM0-MM7 числами 40H-47H, коды имен регистров XMM0-XMM7 числами 50H-57H, и т.д. Младшая цифра чисел (всегда 0-7) участвует в генерации кода через директиву MODRM, а собственно значения чисел используются для задания допустимого диапазона в формальных параметрах новых макро.

При поиске подходящих операндов транслятор проверит, что указанный в команде регистр входит в допустимый диапазон и поэтому, например, в командах MMX вместо MM0 нельзя указать чужой регистр CR0 или XMM0.

Часто в новых множествах команд требуется применить директиву NOSEGFIX 5, выключающую обычные правила использования префикса 66H (в зависимости от размера операндов), поскольку в описываемых командах этот префикс используется по-своему.

Тогда, например, для команд из множества MMX описания выглядят так:

CodeMacro MOVQ dst:Rn(40H,47H),src:Mn  NOSEGFIX 5  SEGFIX src  DB 0FH  DB 6FH  MODRM dst,srcEndM

Для команд из множества XMM:

CodeMacro ADDPS dst:Rn(50H,57H),src:Mn  NOSEGFIX 5  SEGFIX src  DB 0FH  DB 58H  MODRM dst,srcEndM

Для команд из множества SSE2:

CodeMacro ADDPD dst:Rn(50H,57H),src:Mn  NOSEGFIX 5  DB 66H  SEGFIX src  DB 0FH  DB 58H  MODRM dst,srcEndM

Для команд из множества 3DNow!:

CodeMacro PFACC dst:Rn(40H,47H),src:Mn  NOSEGFIX 5  SEGFIX src  DB 0FH   DB 0FH  MODRM dst,src  DB 0AEHEndM

Расширение макросредств для x86-64 (IA-32e), AVX-команд и т.д.

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

Однако все эти доработки потребовали именно расширения, но не кардинальной переделки транслятора.

Использование макросредств для генерации команд процессоров другой архитектуры

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

Анализ показал, что имеется лишь три препятствия такого использования RASM для генерирования команд RISK-архитектуры: конфликт мнемоники команды ST с названием регистра FPU, форма записи инкремента указателя типа X+ и другой способ вычисления относительного адреса, делающий директиву RELW неподходящей.

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

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

Такие несложные доработки транслятора повысили универсальность макросредств. Все RISK-команды были легко описаны с их помощью, например:

CODEMACRO RJMP  k:Cw  RELW 2,12,k  DBIT 8('S'(1))  DBIT 4(0CH),4('S'(9))ENDMCODEMACRO LDI   R_d:Db(16,31),K:Dn  DBIT 4(R_d(0)),4(K(0))  DBIT 4(0EH),4(K(4))ENDMCODEMACRO OUT   P:Dn(0,63),R1_r:Db(0,31)  DBIT 4(R1_r(0)),4(P(0))  DBIT 5(17H),2(P(4)),1(R1_r(4))ENDMи т.д.

И наконец стало можно программировать микроконтроллер AT90S2313 на RASM:

                 ;---- ПЕРЕХОД ПО RESET (0) ----0000 02C0  0006  rjmp РЕСТАРТ                 ;---- ПЕРЕХОД ПО INT 0 (1) ----0002 CBC0  019A  rjmp ПРЕРВАНИЕ_ОТ_ГПРРЕСТАРТ:                 ;---- ИНИЦИАЛИЗАЦИЯ СТЕКА ---- 0006 BFED       ldi  СЧ_ТМ,СТЕК   ;КОНЕЦ РАБОЧЕЙ ПАМЯТИ 0008 BDBF       out  SPL,СЧ_ТМ    ;УСТАНОВИЛИ СТЕК                 ;---- ИНИЦИАЦИЯ ВХОДОВ ПОРТА "B" ---- 000A 2FE5       ldi  tmp,РАЗР_B 000C 27BB       out  DDRB,tmp                 ;---- ИНИЦИАЦИЯ ВХОДОВ ПОРТА "D" ---- 000E 22E0       ldi  tmp,РАЗР_D 0010 21BB       out  DDRD,tmp                 ;---- ИНИЦИАЦИЯ RS-232 ---- 0012 24E0       ldi  tmp,4           ;115200 БОД 0014 29B9       out  UBRR,tmp 0016 28E1       ldi  tmp,(1 SHL RXEN) OR (1 SHL TXEN) 0018 2AB9       out  UCR,tmp

Заключение

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

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

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

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

Разумеется также, что очередные изменения архитектуры (например, переход к x86-64) не могут свестись в трансляторе только к использованию подобных макросредств, а объективно требуют и доработок самого транслятора. Тем не менее, как бы в дальнейшем ни продолжилась эволюция команд процессоров, данные средства наверняка окажутся полезными.

Литература

1. RASM-86 Programmers Guide Digital Research, Сalifornia

http://bitsavers.org/pdf/digitalResearch/pl1/

2. М.Гук, В. Юров Процессоры Pentium 4, Athlon и Duron. СПб.: Из-во Питер, 2001

Подробнее..

Ограничение прав доступа к переменным

20.01.2021 20:22:57 | Автор: admin

Конец восьмидесятых. Всего два года я отсутствовал на родном предприятии, а меня встретил уже меняющийся компьютерный мир. В отделах стали появляться персоналки: у кого IBM-PC/XT, у кого Правец, а у кого ЕС-1840. Число пользователей БЭСМ-6 и даже ЕС и СМ-4 стало асимптотически приближаться к нулю. На фоне новых возможностей все их фишки сразу побледнели. Например, смешно, что еще недавно какая-нибудь замена терминала VT-340 на VT-52100 c памятью на 5 страниц, позволяющей вводить текст еще до включения БЭСМ, казалась важной.

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

Впрочем, последние годы работа с БЭСМ-6 через диалоговую программу Пульт разработки МГУ, как раз очень напоминала работу за первыми персоналками и поэтому переход был несложным.

А вот задачи стали другие. Отдел занимался разработкой ПО системы управления Энергия-Буран. Точнее, отдел занимался комплексацией, верификацией, взаимодействием с наземным ПО и т.п., а собственно разработкой занималось сразу несколько отделов. Я впервые принимал участие в проекте, где были заняты десятки программистов. Язык программирования ПРОЛ-2 разработки ИПМ АН СССР.

Вообще-то, девичья фамилия этого языка была Пролог-Ц от ПРОграммирования ЛОГики. А литера Ц - это, вероятно, ЦУП. Но поскольку в то время на слуху был японский Пролог с его транспьютерами, вероятно разработчикам надоело отвечать на вопросы о применении транспьютеров в Буране, поэтому вторая версия языка вышла под таким скромным и безликим именем.

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

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

Сказано-сделано. Часть транслятора была написана на ассемблере и поэтому летал он ласточкой.

В то время было модно извлекать из внутреннего динамика персоналки разные звуки. Ребята из моего бывшего отдела даже спаяли простой АЦП на параллельный разъем и через микрофон от древней Яузы-5 мы записали ряд сигналов и фраз.

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

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

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

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

Но разбирательство показало, что таки-да, в штатном трансляторе помарка. Вероятно, она проникла в транслятор, когда выяснилось, что ресурсов одной БЦВМ не хватает и приняли решение поставить в Буране две машины, разделив ПО между ними. Транслятор подправили для двух ЭВМ, но он перестал проверять права доступа переменной из процедуры на соседней БЦВМ (или, наоборот, на той же, я уже не помню). В общем, выключилась одна из проверок.

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

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

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

А что, разве при отработке не было случаев, когда один процесс портил переменную другому процессу? Конечно, были. Только во всех этих случаях как раз с правами доступа все было хорошо.

С тех пор прошло уже десятка три лет. Программирование и теоретически и практически ушло далеко вперед и добилось больших успехов.

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

В духе так и не озвученной нами в трансляторе второй половины афоризма Бориса Заходера.

Подробнее..

Перевод Заброшенный сайд-проект, который превратился в бизнес с доходом в 200 млн долларов в год

02.01.2021 20:04:09 | Автор: admin

20-летний путь Бена Честната, основателя MailChimp


Ему было 26 лет, когда его уволили и он основал студию веб-дизайна.

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

После увольнения в 2000 году Бен Честнат занялся тем, что знал лучше всего, разработкой веб-сайтов. За эти годы он создал около двух тысяч рекламных баннеров для своего бывшего работодателя, газеты Cox. Он точно знал, как создавать интерактивные объекты в Интернете.

И я подумал Что ж, это наш шанс открыть компанию. Мой деловой партнёр и я просто нашли клиентов. Мы пошли стучаться в двери по коридору от нашего офиса. И у нас появились оплачиваемые проекты. Мы получили проекты на 13 000 и 32 000$. Даже до получения лицензии на бизнес.

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





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

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

Родился Сhimp


В Rocket Science Group творческие умы уставали от многократного внедрения одной и той же функции на веб-сайты своих клиентов: инструмента для создания списков рассылки. Описанная работа была повторяющейся и созрела для творческой автоматизации. Чтобы избавиться от бремени, команда разработала универсальное решение с самообслуживанием и взимала с клиентов по 1 центу за каждое отправленное письмо.

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


Слух распространялся медленно. Старые клиенты, которые больше не работали с Rocket Science Group, всё ещё использовали инструмент электронной почты. Владельцы малого бизнеса, которые никогда не были клиентами агентства, начали обращаться с запросами. В то время как Бен был сосредоточен на том, чтобы обеспечить студию, его инструмент электронной почты тихо вырастил своих собственных маленьких последователей.

Суммы по-прежнему были незначительными. Когда вы гонитесь за проектами веб-дизайна на 30 000$, несколько счетов на 50$ не требуют особого внимания. По иронии судьбы, именно всё более неэффективная задача выставления этих небольших счетов побудила Бена ввести модель ежемесячной подписки и создать функциональность, связанную с кредитной картой для MailChimp, что фактически породило один из первых продуктов SaaS.

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

  1. Полувирусная модель freemium основная причина успеха Chimp, она способствовала его росту со 100 тыс. до 1 млн. пользователей всего за год. В то время было новшеством предоставить пользователям бесплатный доступ ко всей вашей платформе. Взрывной успех модели freemium был двояким: во-первых, каждое бесплатное электронное письмо содержало в сносках логотип MailChimp, создавая полувирусный цикл органических переходов; поскольку пользователям приходилось платить только после того, как они набирали определённое количество писем в своём списке, получение вашего первого платного плана MailChimp действовало как обряд, на который вы должны были заработать свой путь.
  2. Нишевые социальные платформы. Изначально компания называлась Code. Blog. Tweet. Repeat просто потому, что эта маркетинговая стратегия работала. В 2007 году Twitter был гораздо менее загружен, и MailChimp получил большую известность в сети. Точно так же они купили рекламу, которую будут воспроизводить в начале каждого нового эпизода криминального подкаста под названием Serial. Сегодня подкаст стал хитом он был первым, достигшим 5 млн. загрузок в истории подкастов, но покупка рекламы на нём была хипстерской вещью в то время, а следовательно, недорогой.
  3. Создатель маркетинговых кампаний. В 2014 году диктор одного из рекламных подкастов случайно неправильно произнёс MailChimp как MailKimp. Рекламу транслировали миллиону пользователей, но, по сути, компания решила превратить этот казус в целую маркетинговую кампанию. Вскоре появятся целые бренды MailShrimp, FailChips, VeilHymn и множество других спин-оффов Bumblesnuff-Crimpysnitch-esque были запущены вместе с удивительно креативными кампаниями. Странно? Вроде. Смешно? Просто посмотрите пародию на интервью с художником VeilHymn.
  4. The Chimp! Теории, стоящие за брендингом в качестве универсального продукта, часто бывают глупыми, но шимпанзе определённо сработали у Бена. Еще будучи веб-дизайнером, он узнал, что добавление обезьяны к любому маркетинговому дизайну повышает его эффективность. За прошедшие годы Chimp стал чемпионом бренда, отправляя глупые комментарии пользователям при входе в систему, отключив их в режиме вечеринки в настройках. Серьёзно, сколько ещё почтовых платформ вы сможете назвать?

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

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

Бен: Контент, который мы выпускаем, похож на Второй шанс в жизни Как узнать, когда нужно держаться, а когда сдаться С такой борьбой [малые] предприниматели сталкиваются постоянно. [ ] Мы хотим помочь им выбраться из кухни.

Это звучит банально, но секрет успеха Бена заключается в том, что он был честен с самим собой, зная о своих сильных и слабых сторонах. Когда отец Бена купил ему компьютер, Бен не учился программированию он научился рисовать в программе, для запуска которой требовалось 5 дискет. На самом деле в детстве он хотел стать карикатуристом. MailChimp невероятное достижение инженерной мысли? Возможно. Но его сущность креативность, и этого, по-видимому, достаточно, чтобы построить технологическую компанию на миллиарды.

Заткнись и возьми наши деньги!


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

Главная причина, по которой Бен мог сделать это, заключается в том, что MailChimp с самого первого дня был приносящим доход программным обеспечением. Цены на продукт менялись на протяжении многих лет (за электронную почту > ежемесячную подписку > freemium), но, в отличие от таких продуктов, как WhatsApp, у него была очень чёткая модель дохода, не предполагавшая продажи данных пользователей. Кроме того, крайне важно учитывать, что MailChimp был побочным продуктом управляемой Беном студии, через которую MailChimp финансировался изначально.

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

Непохоже, что Бен был против того, чтобы брать деньги инвестора. Но мир всё ещё восстанавливался после того, как лопнули доткомы, а венчурные компании не жаждали бросаться деньгами в интернет-компании. Многие опасались модели SaaS freemium, которая была новой в то время. Большинство инвесторов, с которыми встречался Бен, утверждали, что MailChimp должна нацелиться на предприятия, потому что там большие деньги, а не на малый бизнес.

Инвесторы не могли проверить доходность. Зачем обслуживать сильно фрагментированную, эмоциональную, малобюджетную аудиторию малого бизнеса, когда 30% выйдут из бизнеса через 2 года, а 50% в ближайшие 5 лет? Исходя из личного опыта Бен понимал, что, даже когда сольные проекты терпят неудачу, они сохраняют свои списки рассылки и большинство из них начинают что-то новое в будущем. Таким образом, MailChimp не обязательно теряет клиента, даже если он временно уходит из бизнеса.

Конечно, как только доходы начали расти, инвесторы выстроились в очередь за дверью MailChimp. За эти годы Бен видел, как десятки конкурентов взяли миллионы на финансирование в надежде перерасти компанию. Каждый участник, поддерживаемый VC, может означать, что Бен совершил ужасную ошибку, оставаясь самофинансируемым. Однако, по состоянию на 2020 год, MailChimp всё ещё находился в комфортном положении с 60%-ной долей в индустрии электронной почты.

Бен: Я в этом бизнесе уже 19 лет. Так что у меня были волны конкурентов, которые брали деньги инвесторов, и я прошёл через стадии, когда говорил: Господи, сейчас они меня убьют. Финансирование становится всё больше и больше и, кажется, ничего не происходит. Мы просто держим прицельный фокус [...] и всё в порядке.

Мог бы MailChimp расти ещё быстрее, если бы у проекта были деньги VC? Возможно. Но, скорее всего, и корпоративные инвесторы постепенно отщепили бы культуру творчества и инноваций MailChimp, что и сделало компанию особенной.

7 интересных фактов о Бене Честнате и MailChimp


  1. Для Бена смесь запахов сигаретного дыма и лака для волос это запах бизнеса. Его мама устроила парикмахерскую на их кухне, и именно так Бен в детстве познакомился с предпринимательством.
  2. При приёме на работу Бен ищет скромных преподавателей, которые настолько хороши, что просят критики. Ему нужны люди, которые достаточно уверены в своих силах, чтобы у них не было проблем с оспариванием их взглядов или с простым объяснением сложных понятий. Бен говорит, что, если человек не может рассказать что-то до глупости просто, он не подходит для MailChimp.
  3. Первый нанятый Беном человек и (предположительно технический) соучредитель Дэн Курциус на собеседовании солгал, что знает, как писать код. После того как он получил работу, он собрал прототип MailChimp, используя книги HTML для чайников. Дэн так старался, что фактически создал (или украл) чистый функциональный код, который поразил Бена. Только через 10 лет соучредитель рассказал Бену о своей импровизации.
  4. Бен подтвердил, что отклонил предложение о приобретении MailChimp за миллиард долларов от неуказанной компании. В свою защиту он говорит, что миллиард долларов не намного больше, чем несколько сотен миллионов.
  5. Держащийся в тени соучредитель Дэн Курциус регулярно и анонимно посещает предприятия малого бизнеса, использующие MailChimp, от студий йоги до складов. Таким образом, компания получает бесценную обратную связь, например, так компания узнала о факте, что многие компании используют MailChimp как CRM, а не как инструмент электронной почты. Это действительно немного странно, когда на мероприятиях MailChimp крупнейшие критики позже узнают, что они разговаривали с соучредителем.
  6. Одна из любимых книг Бена Человек в поисках смысла Виктора Франкла. Франкл психиатр, переживший концентрационный лагерь во время Холокоста. В книге он документирует, как заключённые находят смысл и цель даже в самых бесчеловечных условиях.
  7. Девиз Бена: люби то, что делаешь, а не традиционное делай то, что любишь. Он говоритСо временем все страсти угаснут, если вы превратите их в профессию, и единственный способ сохранить чувство цели научиться любить ремесло, в котором вы хорошо разбираетесь.

Ребята, никто не придёт


В качестве эпилога я бы хотел оставить тебе одну из моих любимых цитат Бена Честнета:

Когда тучи сгущаются и становится тяжело что часто бывает, когда ты предприниматель, я вспоминаю кое-что, что я понял, когда вырос в Апсоне, в Джорджии. Это то, что я сказал друзьям, когда мы заблудились, бродили по лесу. Я сказал: Ребята, никто не придёт. [Бен смеётся] Это звучит не очень позитивно или как-то так, простите, но это то, что вы должны понять: никто не придёт! Всё зависит от нас! Когда ты предприниматель, никто не придёт тебе на помощь. Тебе решать, что нужно делать, чтобы выбраться из этого бардака. Но если ты выберешься из него, к тебе присоединится много людей. [...] Я постоянно говорю это себе.


image



Подробнее..

Перевод Заброшенный сайд-проект, который превратился в бизнес с доходом в 700 млн долларов в год

02.01.2021 22:16:45 | Автор: admin

20-летний путь Бена Честната, основателя MailChimp


Ему было 26 лет, когда его уволили и он основал студию веб-дизайна.

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

После увольнения в 2000 году Бен Честнат занялся тем, что знал лучше всего, разработкой веб-сайтов. За эти годы он создал около двух тысяч рекламных баннеров для своего бывшего работодателя, газеты Cox. Он точно знал, как создавать интерактивные объекты в Интернете.

И я подумал Что ж, это наш шанс открыть компанию. Мой деловой партнёр и я просто нашли клиентов. Мы пошли стучаться в двери по коридору от нашего офиса. И у нас появились оплачиваемые проекты. Мы получили проекты на 13 000 и 32 000$. Даже до получения лицензии на бизнес.

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





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

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

Родился Сhimp


В Rocket Science Group творческие умы уставали от многократного внедрения одной и той же функции на веб-сайты своих клиентов: инструмента для создания списков рассылки. Описанная работа была повторяющейся и созрела для творческой автоматизации. Чтобы избавиться от бремени, команда разработала универсальное решение с самообслуживанием и взимала с клиентов по 1 центу за каждое отправленное письмо.

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


Слух распространялся медленно. Старые клиенты, которые больше не работали с Rocket Science Group, всё ещё использовали инструмент электронной почты. Владельцы малого бизнеса, которые никогда не были клиентами агентства, начали обращаться с запросами. В то время как Бен был сосредоточен на том, чтобы обеспечить студию, его инструмент электронной почты тихо вырастил своих собственных маленьких последователей.

Суммы по-прежнему были незначительными. Когда вы гонитесь за проектами веб-дизайна на 30 000$, несколько счетов на 50$ не требуют особого внимания. По иронии судьбы, именно всё более неэффективная задача выставления этих небольших счетов побудила Бена ввести модель ежемесячной подписки и создать функциональность, связанную с кредитной картой для MailChimp, что фактически породило один из первых продуктов SaaS.

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

  1. Полувирусная модель freemium основная причина успеха Chimp, она способствовала его росту со 100 тыс. до 1 млн. пользователей всего за год. В то время было новшеством предоставить пользователям бесплатный доступ ко всей вашей платформе. Взрывной успех модели freemium был двояким: во-первых, каждое бесплатное электронное письмо содержало в сносках логотип MailChimp, создавая полувирусный цикл органических переходов; поскольку пользователям приходилось платить только после того, как они набирали определённое количество писем в своём списке, получение вашего первого платного плана MailChimp действовало как обряд, на который вы должны были заработать свой путь.
  2. Нишевые социальные платформы. Изначально компания называлась Code. Blog. Tweet. Repeat просто потому, что эта маркетинговая стратегия работала. В 2007 году Twitter был гораздо менее загружен, и MailChimp получил большую известность в сети. Точно так же они купили рекламу, которую будут воспроизводить в начале каждого нового эпизода криминального подкаста под названием Serial. Сегодня подкаст стал хитом он был первым, достигшим 5 млн. загрузок в истории подкастов, но покупка рекламы на нём была хипстерской вещью в то время, а следовательно, недорогой.
  3. Создатель маркетинговых кампаний. В 2014 году диктор одного из рекламных подкастов случайно неправильно произнёс MailChimp как MailKimp. Рекламу транслировали миллиону пользователей, но, по сути, компания решила превратить этот казус в целую маркетинговую кампанию. Вскоре появятся целые бренды MailShrimp, FailChips, VeilHymn и множество других спин-оффов Bumblesnuff-Crimpysnitch-esque были запущены вместе с удивительно креативными кампаниями. Странно? Вроде. Смешно? Просто посмотрите пародию на интервью с художником VeilHymn.
  4. The Chimp! Теории, стоящие за брендингом в качестве универсального продукта, часто бывают глупыми, но шимпанзе определённо сработали у Бена. Еще будучи веб-дизайнером, он узнал, что добавление обезьяны к любому маркетинговому дизайну повышает его эффективность. За прошедшие годы Chimp стал чемпионом бренда, отправляя глупые комментарии пользователям при входе в систему, отключив их в режиме вечеринки в настройках. Серьёзно, сколько ещё почтовых платформ вы сможете назвать?

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

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

Бен: Контент, который мы выпускаем, похож на Второй шанс в жизни Как узнать, когда нужно держаться, а когда сдаться С такой борьбой [малые] предприниматели сталкиваются постоянно. [ ] Мы хотим помочь им выбраться из кухни.

Это звучит банально, но секрет успеха Бена заключается в том, что он был честен с самим собой, зная о своих сильных и слабых сторонах. Когда отец Бена купил ему компьютер, Бен не учился программированию он научился рисовать в программе, для запуска которой требовалось 5 дискет. На самом деле в детстве он хотел стать карикатуристом. MailChimp невероятное достижение инженерной мысли? Возможно. Но его сущность креативность, и этого, по-видимому, достаточно, чтобы построить технологическую компанию на миллиарды.

Заткнись и возьми наши деньги!


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

Главная причина, по которой Бен мог сделать это, заключается в том, что MailChimp с самого первого дня был приносящим доход программным обеспечением. Цены на продукт менялись на протяжении многих лет (за электронную почту > ежемесячную подписку > freemium), но, в отличие от таких продуктов, как WhatsApp, у него была очень чёткая модель дохода, не предполагавшая продажи данных пользователей. Кроме того, крайне важно учитывать, что MailChimp был побочным продуктом управляемой Беном студии, через которую MailChimp финансировался изначально.

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

Непохоже, что Бен был против того, чтобы брать деньги инвестора. Но мир всё ещё восстанавливался после того, как лопнули доткомы, а венчурные компании не жаждали бросаться деньгами в интернет-компании. Многие опасались модели SaaS freemium, которая была новой в то время. Большинство инвесторов, с которыми встречался Бен, утверждали, что MailChimp должна нацелиться на предприятия, потому что там большие деньги, а не на малый бизнес.

Инвесторы не могли проверить доходность. Зачем обслуживать сильно фрагментированную, эмоциональную, малобюджетную аудиторию малого бизнеса, когда 30% выйдут из бизнеса через 2 года, а 50% в ближайшие 5 лет? Исходя из личного опыта Бен понимал, что, даже когда сольные проекты терпят неудачу, они сохраняют свои списки рассылки и большинство из них начинают что-то новое в будущем. Таким образом, MailChimp не обязательно теряет клиента, даже если он временно уходит из бизнеса.

Конечно, как только доходы начали расти, инвесторы выстроились в очередь за дверью MailChimp. За эти годы Бен видел, как десятки конкурентов взяли миллионы на финансирование в надежде перерасти компанию. Каждый участник, поддерживаемый VC, может означать, что Бен совершил ужасную ошибку, оставаясь самофинансируемым. Однако, по состоянию на 2020 год, MailChimp всё ещё находился в комфортном положении с 60%-ной долей в индустрии электронной почты.

Бен: Я в этом бизнесе уже 19 лет. Так что у меня были волны конкурентов, которые брали деньги инвесторов, и я прошёл через стадии, когда говорил: Господи, сейчас они меня убьют. Финансирование становится всё больше и больше и, кажется, ничего не происходит. Мы просто держим прицельный фокус [...] и всё в порядке.

Мог бы MailChimp расти ещё быстрее, если бы у проекта были деньги VC? Возможно. Но, скорее всего, и корпоративные инвесторы постепенно отщепили бы культуру творчества и инноваций MailChimp, что и сделало компанию особенной.

7 интересных фактов о Бене Честнате и MailChimp


  1. Для Бена смесь запахов сигаретного дыма и лака для волос это запах бизнеса. Его мама устроила парикмахерскую на их кухне, и именно так Бен в детстве познакомился с предпринимательством.
  2. При приёме на работу Бен ищет скромных преподавателей, которые настолько хороши, что просят критики. Ему нужны люди, которые достаточно уверены в своих силах, чтобы у них не было проблем с оспариванием их взглядов или с простым объяснением сложных понятий. Бен говорит, что, если человек не может рассказать что-то до глупости просто, он не подходит для MailChimp.
  3. Первый нанятый Беном человек и (предположительно технический) соучредитель Дэн Курциус на собеседовании солгал, что знает, как писать код. После того как он получил работу, он собрал прототип MailChimp, используя книги HTML для чайников. Дэн так старался, что фактически создал (или украл) чистый функциональный код, который поразил Бена. Только через 10 лет соучредитель рассказал Бену о своей импровизации.
  4. Бен подтвердил, что отклонил предложение о приобретении MailChimp за миллиард долларов от неуказанной компании. В свою защиту он говорит, что миллиард долларов не намного больше, чем несколько сотен миллионов.
  5. Держащийся в тени соучредитель Дэн Курциус регулярно и анонимно посещает предприятия малого бизнеса, использующие MailChimp, от студий йоги до складов. Таким образом, компания получает бесценную обратную связь, например, так компания узнала о факте, что многие компании используют MailChimp как CRM, а не как инструмент электронной почты. Это действительно немного странно, когда на мероприятиях MailChimp крупнейшие критики позже узнают, что они разговаривали с соучредителем.
  6. Одна из любимых книг Бена Человек в поисках смысла Виктора Франкла. Франкл психиатр, переживший концентрационный лагерь во время Холокоста. В книге он документирует, как заключённые находят смысл и цель даже в самых бесчеловечных условиях.
  7. Девиз Бена: люби то, что делаешь, а не традиционное делай то, что любишь. Он говоритСо временем все страсти угаснут, если вы превратите их в профессию, и единственный способ сохранить чувство цели научиться любить ремесло, в котором вы хорошо разбираетесь.

Ребята, никто не придёт


В качестве эпилога я бы хотел оставить тебе одну из моих любимых цитат Бена Честнета:

Когда тучи сгущаются и становится тяжело что часто бывает, когда ты предприниматель, я вспоминаю кое-что, что я понял, когда вырос в Апсоне, в Джорджии. Это то, что я сказал друзьям, когда мы заблудились, бродили по лесу. Я сказал: Ребята, никто не придёт. [Бен смеётся] Это звучит не очень позитивно или как-то так, простите, но это то, что вы должны понять: никто не придёт! Всё зависит от нас! Когда ты предприниматель, никто не придёт тебе на помощь. Тебе решать, что нужно делать, чтобы выбраться из этого бардака. Но если ты выберешься из него, к тебе присоединится много людей. [...] Я постоянно говорю это себе.


image



Подробнее..

Перевод Симулируем сцену подбора PIN из Терминатора 2

08.01.2021 12:15:36 | Автор: admin
В начале фильма Терминатор 2: Судный день Джон Коннор использует лэптоп для подбора PIN украденной дебетовой карты.


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


Номеронабиратель (War Dialer) из Военных игр (1983 год)


Чёрный ящик из Тихушников (1992 год)

Недавно я вспомнил эту сцену из Терминатора 2, поэтому начал гуглить лэптоп из Терминатора 2.

Оказалось, что это Atari Portfolio первый в мире палмтоп-компьютер (наладонный компьютер). Он был выпущен в июне 1989 года.


Компьютер имел монохромный ЖК-дисплей с разрешением 240x64 пикселей или 40 символов x 8 строк и работал от трёх батареек AA.

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

Для начала изучим нужные технические требования!

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

banner

Изображение достаточно чёткое, чтобы мы могли с лёгкостью скопировать баннер.

PPPPP   IIIIIII   N    NP   PP     I      NN   N IDENTIFICATIONP   PP     I      N N  NPPPPP      I      N  N N   PROGRAMP          I      N   NNP       IIIIIII   N    NStrike a key when ready ...

После этого Джон нажимает на Enter и на экране начинают прокручиваться числа. Если посмотреть спустя несколько кадров:


то мы увидим, что первая строка чисел выглядит так:

12345678901234567890123457890123456780

Можно было бы предположить, что это просто повторяющиеся четыре раза цифры с 1 по 0, но при внимательном изучении выясняется, что строка длиной всего 38 символов. В третьем повторе пропущена цифра 6, а в последнем цифра 9.

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

Ну, всё выглядит довольно просто. Я осваивал Python, поэтому написал скрипт на Python 3:

#!/usr/bin/env python3import timeimport randomdelay = 0.025print("PPPPP   IIIIIII   N    N")time.sleep(delay)print("P   PP     I      NN   N IDENTIFICATION")time.sleep(delay)print("P   PP     I      N N  N")time.sleep(delay)print("PPPPP      I      N  N N   PROGRAM")time.sleep(delay)print("P          I      N   NN")time.sleep(delay)print("P       IIIIIII   N    N")time.sleep(delay)print('')input("Strike a key when ready ...")print("\n\n12345678901234567890123457890123456780")lines = 1length = 38decrease = 1while True:    for i in range(0, length):        print(random.randint(0,9), end='')    print('')    time.sleep(delay)    lines += 1    if (lines == 5):        lines = 0        length -= decrease        if (decrease == 1):            decrease = 2        else:            decrease = 1    if (length <= 4):        breakfor i in range(0, 10):    print("9003")print("\nPIN IDENTIFICATION NUMBER: 9003")print("\na>", end='')

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

При помощи поиска Google по картинкам я нашёл сайт, продающий пластмассовые панели для Atari Portfolio с нанесённой на экран красивой графикой:


Немного поэкспериментировав с termtosvg, в частности, с функцией SVG-шаблонов, я смог создать этот безумный SVG:


Несмотря на то, что я уже больше десяти лет поддерживаю html5zombo.com, до создания этого SVG я не ценил всех их возможностей. Они могут встраивать изображения? CSS? Javascript? Любой сайт, позволяющий пользователям загружать произвольные SVG и рендерить их, теперь получил моё величайшее уважение.

Пока я развлекался созданием своего небольшого автономного SVG, меня не покидала мысль о том, что мой код на Python на самом деле никогда бы не запустился на Atari Portfolio. В Atari Portfolio установлена DIP Operating System 2.11 (DIP DOS), по большей части совместимая с MS-DOS.

В первых классах старшей школы, ещё до того, как мне начали платить за профессиональное написание ПО, я писал софт для BBS, моды и игры на смеси Turbo Pascal и скриптового языка PCBoard Programming Language, напоминавшего BASIC. Проведя минимальные исследования, я выяснил, что если смогу написать программу на Turbo Pascal и скомпилировать её, то она, вероятно, будет работать на Atari Portfolio.

Я не писал на Turbo Pascal почти 25 лет, но ведь такое не забывается?

Мне нравится форк DOSBox под названием DOSBox-X, поэтому я скачал и установил самую последнюю SDL2-версию для OS X. Затем я нашёл Borland Turbo Pascal 7.0, который помещу сюда, потому что искать его было настоящим мучением.

В этом ZIP вы найдёте четыре файла, которые являются образами гибких дисков. Если поместить их в папку, например, ~/tp, после запуска DOSBox-X и монтирования диска C вы сможете смонтировать их как диск A следующим образом:

imgmount a ~/tp/Disk01.img ~/tp/Disk02.img ~/tp/Disk03.img ~/tp/Disk04.img -floppy

после чего переключиться на диск A: и запустить INSTALL:

A:INSTALL

turbo pascal install

turbo pascal install

turbo pascal install

turbo pascal install

Время от времени придётся заменять гибкие диски, ведь это был 1992 год.

turbo pascal install

Это можно сделать, выбрав в DOSBox-X Drive -> A -> Swap disk. Выполнится переход с Disk 1 на Disk 2. Затем просто продолжайте повторять процесс и нажимать на Ввод, пока не установятся все четыре диска.

После завершения установки она попросить настроить CONFIG.SYS и AUTOEXEC.BAT (не забывайте, это 1992 год).


Ни то, ни другое необязательно. DOSBox-X и так задаёт значение FILES выше необходимого, а добавление к путям просто позволяет запускать TURBO из любого места. После завершения можно выполнить следующую команду:

C:cd tp\binTURBO



В детстве я провёл столько времени с этим IDE, что теперь испытал своего рода ностальгию. Но потом я начал портировать свой скрипт Python на Pascal и ностальгия быстро рассеялась. Хотел бы я сказать, что написал всё целиком в IDE, но в какой-то момент мне пришлось перейти в VSCode, а потом скопировать файл обратно в папку DOS. Люди, которые до сих пор работают в WordPerfect for DOS, я вас и понимаю, и не понимаю.

Вот скрипт, который я получил, потратив много времени на этот туториал по Pascal:

program pinid;uses crt;var i: byte;var pos: byte;var lines: byte;var length: byte;var decrease: byte;var delay_amount: integer;begin     randomize;     delay_amount := 25;     clrscr;     writeln('PPPPP   IIIIIII   N    N');     delay(delay_amount);     writeln('P   PP     I      NN   N IDENTIFICATION');     delay(delay_amount);     writeln('P   PP     I      N N  N');     delay(delay_amount);     writeln('PPPPP      I      N  N N   PROGRAM');     delay(delay_amount);     writeln('P          I      N   NN');     delay(delay_amount);     writeln('P       IIIIIII   N    N');     delay(delay_amount);     writeln('');     write('Strike a key when ready ...');     readln;     writeln('');     writeln('');     writeln('12345678901234567890123457890123456780');     pos := 0;     lines := 1;     length := 38;     decrease := 1;     while true do     begin          for i:= 1 to length do                write(random(9));          writeln('');          delay(delay_amount);          lines := lines + 1;          if (lines = 5) then          begin               lines := 0;               length := length - decrease;               if (decrease = 1) then                   decrease := 2               else                   decrease := 1;          end;          if (length <= 4) then               break;     end;     for i:= 1 to 10 do     begin          writeln('9003');          delay(delay_amount);     end;     writeln('');     writeln('PIN IDENTIFICATION NUMBER: 9003');     writeln('');end.

Краткие объяснения:

  • В Pascal есть объявления типов. Тип byte может быть числом в интервале 0-255.
  • Файлы начинаются с program и названия программы, вероятно потому, что все модули имеют общее пространство имён, но имя файла не важно.
  • Модули импортируются словом uses. Модуль crt используется для манипулирования экраном.
  • := это синтаксис присвоения значения переменной, чтобы можно было сравнивать при помощи = и отличать их друг от друга.
  • Если блоки длиннее одной строки, их нужно оборачивать в begin and end, а не в фигурные скобки или пробелы.
  • Если в начале скрипта не выполнить randomize, то создаваемые случайные числа всегда будут одинаковыми, как и выходные строки.
  • WRITE выводит строку, WRITELN выводит строку с переводом строки. READLN получает ввод до получения перевода строки.

Работает ли код? Вот запущенная в DOSBox-X программа:


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

  1. Купить на Ebay Atari Portfolio.
  2. Купить параллельный интерфейс Atari Portfolio и, вероятно, новую переднюю панель, потому что старая наверняка поцарапана.
  3. Найти в моей коробке с кабелями параллельный кабель.
  4. Найти PC или лэптоп с параллельным портом, установить на него MS-DOS v6.22.
  5. Скачать FT.COM и установить его на PC.
  6. Собрать EXE в Dosbox-X и передать его на Atari Portfolio.
  7. Украсть дебетовую карту.
  8. Обернуть часть карты алюминиевой фольгой, купить последовательный интерфейс Atari Portfolio, подключить кабель к карте.
  9. Запустить программу.
  10. Лёгкие деньги!




На правах рекламы


Закажи и сразу работай! Создание VDS любой конфигурации и с любой операционной системой в течение минуты. Максимальная конфигурация позволит оторваться на полную 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Эпичненько :)

Подробнее..

Тестирование псевдослучайной последовательностью

14.01.2021 20:16:39 | Автор: admin

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

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

Поэтому надо было подготовить простую программу (в смысле ПО) для испытаний. И встал вопрос, что выдавать в качестве информации? Решили все-таки не тривиальную решетку AA55, а псевдослучайную последовательность с помощью примитивного полинома Галуа.

Алгоритм там действительно очень простой:

;---- ВДАЧА ПСЕВДОСЛУЧАЙНОЙ ПОСЛЕДОВАТЕЛЬНОСТИ ----ПСП:  MOV       EBX,ЗНАЧЕНИЕ   ;ПЕРВОНАЧАЛЬНО ВСЕ ЕДИНИЦ      MOV       CX,ДЛИНА_ПСП   ;НОМЕРА ОТВОДОВ ОБРАТНОЙ СВЯЗИ;---- ВСТАВЛЯЕМ ПОЗИЦИЮ ОТВОДА ОБРАТНОЙ СВЯЗИ ----M1:   MOV       EAX,1      XCHG      CH,CL      SHL       EAX,CL      XCHG      CH,CL;---- ОБРАБАТВАЕМ ОЧЕРЕДНОЙ БИТ ----      ROR       EBX,1      JNB       M2;---- ОЧЕРЕДНОЙ БИТ - ЕДИНИЦА ----      AND       EAX,EBX ;ВДЕЛЯЕМ СИГНАЛ ОБРАТНОЙ СВЯЗИ      MOV       EAX,1      JNZ       @      SHL       EAX,CL      OR        EBX,EAX ;ЕСЛИ ОБРАТНАЯ СВЯЗЬ=0, ДОПИСВАЕМ 1      JMPS      M4@:    SHL       EAX,CL      NOT       EAX      AND       EBX,EAX ;ЕСЛИ ОБРАТНАЯ СВЯЗЬ=1, ДОПИСВАЕМ 0      JMPS      M4;---- ОЧЕРЕДНОЙ БИТ - НОЛЬ ----M2:   AND       EAX,EBX ;ВДЕЛЯЕМ СИГНАЛ ОБРАТНОЙ СВЯЗИ      MOV       EAX,1      JZ        @      SHL       EAX,CL      OR        EBX,EAX ;ЕСЛИ ОБРАТНАЯ СВЯЗЬ=1, ДОПИСВАЕМ 1      JMPS      M3@:    SHL       EAX,CL      NOT       EAX      AND       EBX,EAX ;ЕСЛИ ОБРАТНАЯ СВЯЗЬ=0, ДОПИСВАЕМ 0;---- ВДАЧА НУЛЯ ----M3:  CLC     RCR       БАЙТ,1     JMPS      @;---- ВДАЧА ЕДИНИЦ ----M4:  STC     RCR       БАЙТ,1;---- ВДАЧА ОЧЕРЕДНОГО БАЙТА ПСП ----@:   DEC       БИТ    ;БАЙТ ЕЩЕ НЕ КОНЧИЛСЯ ?     JNZ       M1     MOV       БИТ,8  ;ОПЯТЬ 8 БИТ     MOV       ЗНАЧЕНИЕ,EBX ;ДЛЯ ПРОДОЛЖЕНИЯ ПСП     MOV       AL,БАЙТ ;ВДАЛИ ОЧЕРЕДНОЙ БАЙТ ПСП     RET

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

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

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

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

Все повторяется: при включении компьютера аппаратная заявляет, что видит несущую (а это что? Нет у нас никакой несущей!), затем запускаем собственно программу и сигнал опять пропадает. Вдруг через час в переговоры с аппаратной вмешивается телеметрист: да нет никакого пропадания сигнала! Я все нормально принимаю, как и вчера.

Фу-ты, ну-ты. Вчера же действительно все было нормально!

Начинаем разбираться.

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

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

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

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

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

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

Если бы Галуа не погиб в юном возрасте, сколько бы еще открытий мог бы сделать. А если бы он с Чарльзом Бэббиджем бы встретился, ну или бы с Адой Лавлейс, возможно, жили бы мы сейчас совсем в другом компьютерном мире

Подробнее..

Перевод 17 странных фактов о Николе Тесле

18.01.2021 18:09:31 | Автор: admin
image
Никола Тесла, 1890 г. | Изображение Википедия

Если бы не Илон Маск, со своим Tesla Motors, в современном мире мало кто бы уже и вспомнил имя человека, который дал нам электричество (AC). Никола Тесла опередил своё время, не получивши заслуженного признания при жизни.

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

Никола Тесла автор более 700 патентов и инноваций. Ниже в списке некоторые из них:

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

Тесла был гением, который разговаривал на 8 языках: сербохорватском, чешском, немецком, венгерском, французском, английском, итальянском и латыни. Никола был футуристом, придумавшим большое количество устройств почти за 100 лет до того, как они были созданы.

1. Он спрогнозировал появление смартфонов в 1926 году.

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

Когда я прочитала о Тесле 25 лет назад, первая мысль которая возникла у меня в голове была: Что? В то время у всех были компьютеры с ЭЛТ- мониторами. Мы использовали dial-up. Среди моих друзей никто не был владельцем мобильного телефона. Что это за штука, которую можно мало того, что положить в карман, но еще с помощью ее видеть кого-то на другом конце света? Я даже не мог представить концепцию. Тесла также предсказал Wi-Fi, МРТ-камеру и новый мировой порядок с женщинами у власти. Он сделал несколько чертежей луча смерти, который смог бы остановить все будущие войны. Но ФБР забрало документы после смерти ученного и опровергло его разработки. Жизнь Теслы была тяжелой, но очень увлекательной. И она началась со взрыва.

2. Его рождение было символом света.

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

3. Благодаря холере он не стал священником.

Когда Тесла был 5 летним ребенком, его старший брат Дейн упал с лошади и умер. Несчастный случай стал огромным горем для всей семьи. Родственники всегда считали, что Дэйн умнее болезненного Николы, и не возлагали на мальчика больших надежд. Смерть одного из сыновей обеспокоила их отца. Теперь он хотел, чтобы его младший сын стал православным священником и пошел по стопам отца. В этом случае он мог бы посещать ближайшую к их деревне школу. Об обучении в техническом училище, что предполагало переезд в другой регион Австро-Венгрии, отец вовсе не хотел слышать. Но молодой ученый очень любил физику и математику. В 17 лет окончив среднюю школу в соседнем городе и вернувшись в деревню на следующий день он заболел холерой и пролежал в постели 9 месяцев. Несколько раз он был близок к смерти. Пока он был прикован к постели, он убедил отца не отправлять его учится на священника. Отчаявшийся родитель пообещал отправить его на инженерные курсы, если Никола снова выздоровеет. Отец все же сдержал свое обещание, хотя искренне желал для сына совсем другой судьбы.

4. У Теслы были невероятно обостренные чувства.

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

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

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

Молодой гений мог запомнить целые книги и фотографии всего за несколько минут просмотра. Никола утверждал, что обладает силой, как сам он ее называл мозговая инженерия. Уникальность Тесла была в том, что мог детально визуализировать все изобретения в собственной голове и провести им ходовые испытания, при этом он не делая никаких записей. К примеру свой электродвигатель он придумал на прогулке в Будапештском парке, во время чтения книги Гёте Фауст. Внезапно у него в голове возникло изображение вращающегося магнитного поля, отложив книгу в сторону, он незамедлительно нарисовал его схему на песке. Разум этого незаурядного человека хранил множество непостижимых тайн.

image
Никола Тесла с лампочкой 1898 год. | Изображение Википедия


6. Тесла был помешан на мистике.

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

7. После увольнения из лаборатории Эдисона, он зарабатывал на жизнь копанием траншей.

Тесла приехал в Нью-Йорк покинув Европу в 1884 году с рекомендательным письмом для работы на Томаса Эдисона. До этого он несколько лет трудился в парижском региональном отделении компании Эдисона. В компании работало несколько сотен рабочих, Никола был всего одним из них. Проработав там 6 месяцев, с Эдисоном он встречался лишь несколько раз. Как-то ночью, когда молодой инженер засиделся над починкой генераторной установки и состоялась одна из таких встреч. В тот момент Эдисон понял, насколько умен молодой парень. Но молодой инженер проработал там всего 6 месяцев. Возможно, это произошло потому, что Эдисон пообещал заплатить ему $50к (сегодня $12млн), если Никола конструктивно доработает машины постоянного тока, разработанные его компанией. Необходимо было не просто внести изменения в конструкцию, а кардинально переделать уже существующие машины. Тесла работал беспрерывно, чтобы найти решение и сделал это, но Эдисон сказал, что это была шутка, и никакой премии не будет.

Вскоре Тесла покинул лабораторию Эдисона. И пока он искал спонсоров для поддержки своего исследования переменного тока, перебивался работой чернорабочего, рыл канавы за $2 в час, чтобы выживать. Но даже тогда он смотрел в будущее.

8. Тесла еще 120 лет тому назад был активным сторонником возобновляемых источников энергии.

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

По этому поводу Марк Твен как-то сказал: Человек, который остановит это бессмысленное расточительство, стал бы великим благодетелем для человечества. К слову, великий прозаик всегда интересовался наукой и с увлечением говорил о ней, это и связало его с Никола Тесла, которого он называл своим другом.

9. Он чуть не заставил Твена обкакаться.

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


image
Рентгеновский снимок руки Теслы 1896 год | Изображение Википедия

10. Окружающие думали, что он сумасшедший.

Есть вероятность, что у Теслы было расстройства аутистического спектра. По словам профессора Майкла Фицджеральда и Брендана ОБрайена, соавторов книги Как таланты Аспергера изменили мир, сегодня у Теслы был бы диагностирован синдром Аспергера. Он страдал обсессивно-компульсивным расстройством, которое в результате и уничтожило его репутацию. Он ненавидел круглые предметы, украшения, а также прикасаться к чьим-то волосам. Тесла уделял огромное внимание работе. Он утверждал в том, что ему для сна хватает всего 2 часа в день. Он работал с 9 утра до 6 вечера. Затем он ужинал ровно в 8.10 и продолжал работать до 3 часов ночи. Но, несмотря на недостаток сна и большое количество работы, он дожил до 87 лет. Еще Тесла был фанатом числа 3, а также чисел, которые можно разделить на 3. Чего только стоила его странность мыть руки 3 раза подряд. Он обходил свое здание 3 раза перед тем, как войти в него. Ученый использовал 18 носовых платков, чтобы вытирать обеденный стол и столовые приборы перед каждым приемом пищи. Так, как в подростковом возрасте он переболел холерой, у него была паническая боязнь микробов.

11. У Теслы были странные привычки в еде.

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

12. Он держался подальше от женщин.

Тесла был красивым, стройным, рослым (188 см) мужчиной с темными волосами и голубыми глазами. Он обладал утонченным вкусом и хорошими манерами. Женщины его любили. Но он оставался целомудренным. Никола верил, что секс мешает мужчине в работе:Я не могу вспомнить много великих изобретений, которые были созданы женатыми мужчинами. Также ему не нравились женские аксессуары.

13. Он ненавидел жемчуг и украшения.

Была история, как однажды друзья на приеме познакомили Теслу с красивой девушкой. Она была умна и забавна, но на ней были жемчужные серьги. Он едва мог с ней разговаривать, не говоря о том, что бы смотреть ей в лицо. Если его секретарша носила жемчуг, он отправлял ее домой на целый день. По словам Бернарда Карлсона, автора книги Никола Тесла. Изобретатель будущего, этот антагонизм был вызван его стилем эстетики: Он считал, что для того, чтобы добиться успеха, нужно выглядеть успешным. Мы не можем быть уверены в этом. Но мы знаем, что его успех совсем не зависел от наград.

14. Он никогда не получал Нобелевской премии.

Тесла был номинирован на Нобелевскую премию в 1937 году, но комитет провалил его кандидатуру на выборах, отдав за него только 1 голос из 38. В 1909 году ученым Маркони и Брауну вручили Нобелевскую премию за радио. Но в 1943 году, через несколько месяцев после смерти Теслы, Верховный суд восстановил приоритет поданного им ранее патента на радио. Несколько человек так же, получили признание за изобретения, которые сделал Тесла, но, похоже, его это не тревожило. Ему просто было жаль, что у других не было великих идей.

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

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

16. Он обожал голубей.

Тесла часто ходил в Центральный парк, чтобы покормить их. Раненых птиц он приносил к себе домой, что было причиной жалоб на шум и запах от жителей отеля. Перед смертью он жил в нью-йоркском отеле на 33 этаже, в квартире номер 3327. Все свое свободное время он проводил с голубями, а не с людьми. Особенно Тесла любил одного белого голубя. Однажды, когда он лежал в постели и думал, птичка влетела в комнату. Он утверждал, что в ее глазах был ослепительный свет. Он продолжал заботиться о ней, даже когда она заболела. На заболевшего пернатого друга он потратил $2000. Ученый построил устройство, которое поддерживало птицу, пока ее крыло и нога заживали. Я кормил тысячи голубей в течение многих лет. Но была одна, красивая птица, чистая, белая, со светло-серыми кончиками на крыльях. Это была самка. Я любил этого голубя, как мужчина любит женщину, и она любила меня. Пока она была у меня, в моей жизни была цель.
Хотя Тесла и был одиночкой, но он не заслуживал такой ужасной смерти в полном забвении.

17. Он умер без гроша в кармане и позабыт всеми.

Чем старше он становился, тем меньше денег он зарабатывал. Из отеля Уолдорф-Астория в Нью-Йорке он переехал в Сент-Реджис, так как у него накопились огромные неоплаченные счета. Собственно по той же причине его выселили из Сент-Реджиса, но помимо задолженности по оплате, ему вдобавок ко всему соседи предъявляли претензии за дискомфорт и беспорядок, созданный благодаря своей привязанности к голубями. Далее он продолжал переезжать, но уже в более дешевые отели, однако счета по-прежнему оставались не оплаченными. В итоге его бывший работодатель компания Вестингауз начала оплачивать аренду его жилья и выплачивала позабытому гению $125 в месяц в качестве платы за его консультационные услуги. Видимо компания была обеспокоена тем, что бедный ученый вредит их репутации. Тесла также получал скромную сербскую пенсию до самой смерти. Никола Тесла скончался в номере отеля Нью-Йоркер в ночь с 7 на 8 января 1943 года, на 87-м году жизни. Горничная нашла его через два дня, проигнорировав табличку Не беспокоить. Врач постановил, что причиной смерти является сердечный приступ. Похороны Теслы состоялись в Нью-Йорке 10 января 1943 года. Его племянник Сава Косанович в 1952 году вместе с прахом Теслы сумел отправить в Сербию все имущество в 80 сундуках. Прах выставлен в Белграде в музее Николы Теслы.

image
Музей Николы Теслы в Белграде, Сербия | Изображение Википедия

Заключение

Он был гением-изобретателем, создавшим вещи, опередившие время в котором он жил и все еще использующиеся сегодня, Хариш Кришнасвами, доцент кафедры электротехники Колумбийского университета. Тесла был загадочным человеком, который мог заглядывать в далекое будущее. Несмотря на то, что он был лишен привилегий, он умер со страстью к науке, которая изменила 20-й век. Его всегда почитали на Балканах, в регионе, откуда он родом. Республики бывшей Югославии до сих пор воюют за его доброе имя, будь то он серб, хорват или босниец. Тем не менее, всего несколько лет назад мир начал ценить то, что он сделал для человечества.

Пусть будущее расскажет правду и даст оценку каждому в соответствии с его трудами и достижениями. Настоящее принадлежит им; будущее, ради которого я работал на самом деле мне. Никола Тесла

Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Maincubes Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Эволюция оркестратора микросервисов. Как переход на WebClient помог пережить пандемию

19.01.2021 10:15:06 | Автор: admin

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

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

Типовая архитектура оркестратора

Классическая схема оркестратора для ритейла выглядит примерно так:

Фронт запрашивает id одного или нескольких товаров, которые хочет отобразить + id маски. Маска - это alias для списка атрибутов, необходимых для отображения. На разных страницах сайта необходимо показывать разный набор атрибутов, информация об этом лежит в отдельном микросервисе. Далее, имея список товаров и необходимых атрибутов, оркестратор идёт в микросервисы, которые информацией по этим атрибутам обладают. Плюс, надо зайти в рекомендательную систему, которая вернёт список id товаров которые мы можем порекомендовать купить вместе с основным (заменители основного и ему сопутствующие). Этот список тоже нужно обогатить атрибутами по маске, которую запросит фронт.

В общем, логика не бог весть какая, но она есть.

Варианты оптимизации

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

Прикрутить кэш

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

Распараллелить запросы

Как показывает практика, большинство времени подобного рода сервисы просто ждут ответа от их доменных коллег, так что если они могут "ждать" эти ответы не по очереди, а одновременно, то хорошая идея это организовать. Если мы берём стандартный сервер tomcat или undertow, то можно сделать так, чтобы каждый запрос, принимаемый сервером порождал N потоков, каждый из которых ходил бы за своим атрибутом, а поток-родитель потом это всё бы собирал и выплёвывал наверх.

Соединить запросы

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

Что имеется в виду: в сервис приходит массив основных продуктов и их атрибутов, по которым нужно собрать информацию. Помимо этого, к продуктам нужно подобрать рекомендации. Сервис рекомендаций, естественно, возвращает только список продуктовых id, которые также нужно обогатить своим набором атрибутов. Атрибуты эти, отличаются от атрибутов основного продукта и тоже приходят как параметр запроса нашего оркестратора.
Фактически, в оркестратор приходит список основных продуктов и 2 маски: одна для основных запрашиваемых продуктов, и вторая для продуктов, которые мы к ним рекомендуем:

{  "products": ["product1", "product2", ..., "productN"],  "mask" : "product_detail_page_attributes",  "recommendation_mask": "name_and_photo_only"}

Проблема в том, что список id основных продуктов мы знаем сразу, а за списком id продуктов-рекомендаций ещё нужно сходить. Возникает несколько вариантов того, как это сделать:

Вариант 1:

  1. Идём с известными основными продуктами и их атрибутами по микросервисам собирать о них информацию;

  2. Параллельно с этим, идём в сервис рекомендаций, который возвращает нам список id рекомендуемых продуктов;

  3. После того, как сервис рекомендаций вернул список товаров, аналогично первому пункту, идём с уже другим набором атрибутов по сервисам и получаем всю необходимую информацию.

Тут 1 и 2 выполняются параллельно, 3 же придётся подождать первых двух. Как видно, число последовательных запросов: 2, что не так много, но, как показывает практика, проблема может заключаться в их количестве. Это то, что у нас было с самого начала, после этого мы сделали следующую оптимизацию:

Вариант 2:

  1. Сначала идём в сервис рекомендаций и получаем id продуктов-рекомендаций;

  2. После этого добавляем к основным продуктам рекомендованные товары, и к атрибутам основных товаров атрибуты товаров-рекомендаций, и уже со всем этим добром идём к доменным сервисам.

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

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

Тем не менее, второй вариант всё же по моему мнению лучше, т.к.
меньше запросов => меньше потоков => сервис больше таких запросов сможет обработать. Также, доп запрос - это доп затраты на маршаллинг и демаршаллинг, которые могут быть значительными.

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

Выводы:

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

Едем дальше

Итак, мы провели некие оптимизации, и да, сервис действительно стал держать больше нагрузки, но что делать, если этого всё ещё не достаточно?

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

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

  • Не всегда возможно из-за ограничений инфраструктуры. Это сейчас у нас кубер и со скалированием проблем нет, но перед пандемией у нас был всего десяток серверов для приложений и на одном сервере мы мы могли поднять только 1 инстанс оркестратора. Т.е. максимальное количество инстансов, которые мы могли себе позволить - 10;

  • Как показывает практика, это не оптимальный подход. Да, прирост производительности есть, но до для того, чтобы получить необходимые 60ms на 95-й персентиле нужно было этими инстансами прямо таки обмазаться, чего мы себе позволить не могли.

    Время ответа при 5-ти и 8-ми инстансах оркестратораВремя ответа при 5-ти и 8-ми инстансах оркестратора

Анализ проблемы

На самом деле проблему "как разогнать сервис до определённого rps?" можно переформулировать в вопрос "почему на нужном rps сервис не держит?". Для того, чтобы понять в чём проблема, даём нарастающую нагрузку, и, в момент когда сервису плохеет смотрим на состояние.
К сожалению, идея написать статью появилась после того, как мы решили проблему, по этому графики не сохранились, но, если в двух словах, мы увидели, что количество потоков постоянно росло и в какой-то момент garbage collector просто сходит с ума. Причём, ни увеличение возможного количества потоков, ни добавление памяти картину не меняло.

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

рис 3. Путь запроса в undertowрис 3. Путь запроса в undertow
  1. Сервер принимает входящее http соединение. Занимаются этим потоки пула WORKER_IO_THREADS, их обычно по количеству ядер (в нашем примере 4). Допустим, наш запрос попал на XNIO-1 I/O 2. Он установил соединение, и отправил запрос дальше, освобождаясь для принятия новых запросов.

  2. От потока из пула WORKER_IO_THREADS запрос попадает уже на непосредственный обработчик - в нашем случае это XNIO-1 task-2 из пула WORKER_TASK_CORE_THREADS
    Это тот поток, который будет выполнять всё, что мы напишем внутри нашего контроллера.

  3. Как уже говорилось выше, зная список атрибутов, XNIO-1 task-2 создаёт n потоков, каждый из которых параллельно должен добыть какую-то часть информации о продуктах. Потоки берутся из кастомного пула (пулы WORKER_IO_THREADS и WORKER_TASK_CORE_THREADS - это сущности undertow)

  4. Каждый кастомный поток, идёт к клиенту доменного сервиса и делает запрос. Т.к. под капотом используется RestTemplate, поток блокируется и ждёт пока доменный сервис не ответит.

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

Переход на неблокирующий подход

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

Чтобы понять в чём суть, мне бы хотелось привести аналогию с фастфудом

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

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

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

Вернёмся к нашему серверу

Если используется блокирующий RestTemplate, то поток, который получает информацию от доменного сервиса делает следующее:
Он стучится к сервису, говорит ему "здрасьте", я такое-то приложение, мне нужна такая-то информация, я буду ждать от вас ответ на таком-то порту, и начинает ждать, что на этот порт от сервиса придёт ответ. Пока ответ не придёт, или пока не наступит таймаут поток ничем полезным заниматься не будет.

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

Потоки из этого нового пула будут принимать "заказы" на общение с сервисами моментально возвращать управление вместе с каким-то аналогом Future и избавляя от необходимости заказчика ждать.

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

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

Теория - это классно, как применить-то?

C 11-й Java доступен httpClient, который реализует описанный выше неблокирующий подход. А с Spring 5 есть его обёртка - WebClient, которым можно заменить RestTemplate.
WebClient - часть spring-webflux, по этому как результат запроса в доменный сервис возвращает Mono/Flux. Наш основной же код приложения работает с CompletableFuture.

Возникает вопрос: можно ли использовать WebClient как замену RestTemplate, получив преимущества неблокирующего приложения, но при этом не переписывая с CompletableFuture на Mono/Flux весь проект?

Ответ: можно, но нужно очень хорошо понимать что делаешь.

Как положить прод, если не любишь читать документацию.

У Mono/Flux есть метод toFuture(), который возвращает как раз CompletableFuture.

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

Потоки WebClient(по умолчанию они зовутся reactor-http-epoll-число), которые должны были постоянно работать оббегая каждый свой список портов, заблокированы.
Всё дело оказалось в методе CompletableFuture thenApply(work) который встретился у нас выше по стеку.
Этот метод, "докидывает" работы в текущий CompletableFuture на котором вызывается. И всё бы ничего, но у нас так получилось, что эта "работа" оказалась блокирующей.

Получилось следующее: через thenApplyпотоку reactor-http-epoll-1 из WebClient было "накинуто" задание сходить в ещё один сервис. Пока он этого не сделает и не вернёт управление наверх он не может выполнять свою основную работу - смотреть не ответили ли доменные сервисы. И причём, в конце этого задания у стояла блокировка, т.е. нужно было обязательно дождаться от этого сервиса ответа. И так исторически сложилось, что библиотека WebClient, распределяющая работу типа "сходить в ещё один сервис" выбрала именно reactor-http-epoll-1 для организации взаимодействия в этом запросе. То есть получилась ситуация, когда поток заблокировался, потому что ждал ответа от сервиса, в то время как он же и должен был этот ответ в получить. Но он не мог бегать и смотреть что ему пришло, т.к. был заблокирован. Вот такой вот deadlock.

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

Мораль же следующая:

Никогда не позволяйте потокам WebClient блокироваться - они постоянно должны работать.

Именно потому что так просто выстрелить себе в ногу, я бы рекомендовал воздержаться от использования CompletableFuture и Mono/Fluxв одном проекте. Если используете Mono/Flux , то лучше перепишите всё на Netty, благо у CompletableFuture и Mono/Fluxочень похожее API. Вот тут в документации написано почему использовать метод toFuture() конвертирующий одно в другое - не очень хорошая практика.

Хэппи-энд

Тем не менее, после правок, всё завелось. После деплоя видим следующую картину:

Где-то на 17:26 произошёл деплой новой версии. Из графика видно что:

  • количество потоков сократилось больше чем в 4 раза (это сократилось количество потоков в CUSTOM_THREAD_POOL с 1000+ до 4-х);

  • потоки в статусе timed-waiting исчезли как класс;

  • количество потоков в статусе waiting не изменилось, но это понятно - нас всё ещё есть нативные воркеры undertow. Можно использовать Netty, тогда не было бы и их - у приложения тогда бы вообще было бы всего 4 универсальных потока, которые занимались бы всем.

Результаты по перфомансу превзошли все ожидания: 0 ошибок и 80 ms 75-й персентиль, при всего 4-х инстансах приложения.

Необходимая производительность в 60 ms на 95 персентиле достигается путём поднятия единственного дополнительного инстанса.

Выводы

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

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

  • кэшировании;

  • параллельном выполнении запросов;

  • объединении запросов.

Именно эти шаги могут уменьшить время ответа запроса.

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

Не советую использовать CompletableFuture и Mono/Flux в одном проекте. Анализ описанных в данной статье проблем при их появлении не тривиален. Как минимум потому, что их не так просто воспроизвести на тестовых стендах. А если используете, то используйте с умом.

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

В чём минусы подхода?

Обсуждая неблокирующее программирование, мы должны понимать, что идея подобной организации потоков не нова. Может быть, она нова в Java, но в Node.js с самого начала всё так и работало. И тем не менее, когда меня пригласили в Леруа Мерлен распиливать монолит, у которого были проблемы с производительностью, то, что мы распиливали, было как раз Node.js приложением. Это говорит о том, что данный подход не является панацеей. Он хорошо работает, когда потоки не нагружены лишней работой и плохо, когда есть много тяжелых вычислений. Но это уже следующий шаг после внедрения неблокирующего клиента).

Люди строили highload на Java и до jdk11/Spring 5, неблокирующее программирование - это всего лишь один из подходов к организации, который хорошо бы иметь в своём распоряжении и применять когда в нём возникнет необходимость.

Спасибо за внимание!

Подробнее..

История Nokia MeeGo

06.01.2021 16:04:08 | Автор: admin

Вступление от переводчика: Эта статья на английском была опубликована в далеком 2012 году. Тогда еще были свежи воспоминания о смене стратегии Nokia, отказе от разработки собственных ОС. А переход на Windows Phone только случился и подавал множество надежд. Сейчас все произошедшее в феврале 2011 года видится исторической вехой на рынке смартфонов и мобильных ОС, которая изменила его раз и навсегда. Я давно положил глаз на этот материал и лелеял надежду на его перевод. Перевод так никто и не сделал, и вот я наконец-то осилил это дело. Не знаю как вам, а мне грустно, что Maemo, MeeGo и даже Windows Phone (куда уж без него) канули в Лету. Без той самой старой Nokia на рыке стало скучно и однообразно. Но тут уж что сделано, то сделано. Я не стал править текст исходя из современных реалий, все описанное положение дел представлено по состоянию на осень 2012 года.

Свои ремарки далее по тексту я буду {выделять курсивом в фигурных скобках}.


11 февраля 2011 года Nokia опубликовала новую стратегию и заключила соглашение о сотрудничестве с Microsoft. Операционная система Windows Phone была выбрана в качестве новой платформы для смартфонов Nokia. MeeGo стал проектом мобильной операционной системы с открытым исходным кодом, который в долгосрочной перспективе будет использоваться для исследования рынка устройств, платформ следующего поколения и взаимодействия с пользователем.

Стратегическое партнерство с Microsoft практически решило судьбу компании Nokia и ОС MeeGo, которая разрабатывалась совместно с Intel с начала 2010 года. Новая стратегия включала отказ от MeeGo и выпуск только одного устройства в двухлетней перспективе.

За неделю до выхода новой стратегии Nokia в Сеть просочилась заметка Стивена Элопа сотрудникам Nokia. В своей записке о горящей платформе Элоп описал проблемы Symbian и MeeGo, а также плохое состояние конкурентоспособности компании по сравнению с экосистемами Apple и Google.

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

Nokia не очень много распространялась о разработке MeeGo. Снимки, просочившиеся в интернет, демонстрируют модель N9 с QWERTY-клавиатурой. Он, как ожидалось, вернет Nokia на вершину рынка смартфонов.

В результате партнерства с Nokia и Microsoft и стратегии с Windows Phone, команда MeeGo была распущена после выпуска N9 и нескольких обновлений прошивки. На это ушло чуть больше года. В конце концов также была похоронена операционная система Meltemi на базе Linux, предназначенная для более дешевых мобильных телефонов, и теперь все доступные ресурсы направлены на Windows Phone. На TaskuMuro.com мы активно следим за разработкой смартфонов Nokia, а также за разработкой операционных систем Maemo и MeeGo на базе Linux. Поскольку в открытом доступе так мало информации об истории MeeGo, мы оставили сообщение на нашем форуме MuroBBS летом 2012 года. В сообщении мы попросили людей, вовлеченных в разработку MeeGo, поделиться своими историями.

Мы получили многочисленные отклики от бывших и нынешних сотрудников Nokia, которые попросили сохранить анонимность. Всего по этой статье было опрошено 10 человек. И большая головоломка под названием Nokia MeeGo начала принимать некую финальную форму. Эта статья в значительной степени основана на информации и интервью из анонимных источников. Мы сделали все возможное, чтобы сравнить информацию, полученную из этих различных источников, и объединить ее с информацией, просочившейся в Интернет за прошедшие годы. Читатели должны понимать, что интервьюируемые работали над проектами, которые были заброшены после нескольких лет разработки. В их словах много обиды, сожалении о потерянном времени, поскольку в прошлом году в Финляндии было уволено около 5000 сотрудников Nokia.

Об авторе

История Nokia MeeGo написана Сампса Курри, который основал технологический сайт Muropaketti в 1999 году. В настоящее время Muropaketti принадлежит Otavamedia. Курри получил степень магистра в Технологическом университете Тампере. В настоящее время Курри производит контент и помогает в разработке сайта через основанную им компанию io-media Ltd. Отзывы о статье могут быть отправлены на sampsa.kurri [a] https://muropaketti.com.

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

Английский перевод статьи был сделан с помощью активных людей с наших форумов MuroBBS. Отдельное спасибо Алекси Ванттинену.

Nokia до MeeGo: OSSO и Maemo

Nokia 770Nokia 770

С 2005 года очень небольшая группа людей с ограниченными ресурсами в Nokia разрабатывала операционную систему Maemo на базе Linux и устройства на ее основе. Команда была известна как OSSO (Open Source Software Operations), и, по словам одного из членов команды, который работал там с самого начала, целью было создание продукта, который изменит мир. Команда OSSO была переименована в команду Maemo в 2007 году. А в результате партнерства Nokia и Intel в 2010 году она была переименована в команду MeeGo. С самого начала группу возглавлял Ари Якси, который ушел из Nokia в октябре 2010 года и перешел в HP для разработки операционной системы WebOS.

Nokia N800Nokia N800

Первыми двумя устройствами были 770, выпущенный в 2005 году, и его последователь, N800, выпущенный в 2007 году. Оба были разработаны с очень небольшими ресурсами. Поскольку команда была небольшой, всего несколько десятков сотрудников, разработка программного обеспечения была быстрой и очень быстрой.

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

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

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

В то же время размер команды вырос, а вместе с ней и бюрократия. Это привело к снижению гибкости и к замедлению в разработке программного обеспечения. Особенно трудно было принять предложения по улучшению, которые поступили от разработчиков команды MeeGo, и многие из-за этих предложений так и не увидели свет. В качестве одного из примеров стоит упомянуть был жест смахивания вверх-вниз в пользовательском интерфейсе Swipe, который закрывает текущее приложение. Предложение было сразу же отвергнуто, но разработчик не сдался, поделившись примером функциональности для тестирования другими. В результате во внутренней системе Bugzilla, используемой сотрудниками Nokia для обработки ошибок, появилась цепочка длиной в несколько сотен сообщений, где руководство и разработчики спорили друг с другом по поводу этой функции. Наконец, эта функция была сделана, и в обновлении PR 1.1 она использовалась по умолчанию.

Первые признаки внутренней конкуренции Nokia между двумя платформами были замечены с устройством N810. Он был выпущен в конце 2007 года и вышел на рынок без функциональности телефона. Это был бы первый телефон Maemo от Nokia, но решение об отказе от функциональности телефона, как говорится, было полностью политическим.

Nokia N810Nokia N810

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

Nokia N900Nokia N900

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

В N900 использовалась ОС Maemo 5 под кодовым названием Fremantle. Ее интерфейс Hildon UI был написан на GTK+. Параллельно с N900 была начата разработка Maemo 6 под кодовым названием Harmattan. Его пользовательский интерфейс должен быть полностью переписан на Qt.

Nokia продолжала разрабатывать Symbian и Maemo для смартфонов с сенсорным экраном, поскольку Symbian по-прежнему продавалась хорошо, и никто не догадывался, насколько быстро телефоны на базе iOS и Android перекроят рынок смартфонов. Внутри Nokia участники команды Maemo понимали, что менеджмент команды Symbian боится за свои места, и использует свои позиции в компании, чтобы любым способом замедлить развитие Maemo.

Nokia Maemo + Intel Moblin = MeeGo

На MWC в Барселоне в феврале 2010 года Nokia и Intel объявили, что объединят свои разрабатываемые операционные системы на базе Linux в новый совместный проект под названием MeeGo.

Тогда Nokia занималась разработкой операционной системы Maemo 6, которая была преемницей Maemo 5, использованной в 2009 году в смартфоне Nokia N900. Intel разрабатывает свою операционную систему Moblin (Mobile Linux) с 2007 года, и последняя версия Moblin 2 была специально разработана для работы в нетбуках с процессорами Atom с архитектурой Intel x86. MeeGo использовал среду разработки Qt и ядро от Moblin.

Nokia и Intel полагали, что производители устройств, операторы, производители чипов, разработчики программного обеспечения и приложений смогут широко использовать MeeGo. В пресс-релизе было указано, что Nokia и другие производители представят устройства на базе MeeGo в течение 2010 года.

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

Harmattan

Nokia приступила к разработке операционной системы Maemo 6 еще в 2008 году, и Nokia и Intel решили объединить Maemo и Moblin в MeeGo. Nokia решила продолжить разработку Maemo 6 под кодовым названием Harmattan и сделать его максимально совместимым с MeeGo. Nokia назвала свои версии операционной системы Maemo разными ветрами. Например, харматан это название пассата в Западной Африке.

Предполагалось, что Harmattan станет мостом между Maemo и MeeGo, который разрабатывался в сотрудничестве с Intel. Harmattan был разработан с использованием API совместимого с MeeGo версии 1.2. APT от Debian должен быть использован в качестве системы пакетов для приложений, тогда как в MeeGo пакетным менеджером был RPM (Red Hat Package Manager).

Проблемы с инструментами разработки пользовательского интерфейса

Примерно в то же время, в 2008 году Nokia купила инструментарий Qt у норвежской компании Trolltech. Qt является кроссплатформенной средой разработки программного обеспечения и пользовательских интерфейсов с поддержкой C++. После приобретения Qt, команды Symbian и Maemo начали работу над собственными инструментами для создания пользовательского интерфейса ОС для смартфонов на основе Qt QGraphicsView. Инструмент разработки команды Symbian был известен как Orbit, а инструмент от Maemo был известен как libdui (Direct UI Library). Сотни людей работали над этими проектами в Nokia, и многие понимали, что в этом нет никакого смысла.

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

Orbit от команды Symbian очень похож на libdui. Тем не менее, команды никак не обменивались наработками. Ходили слухи, что в какой-то момент даже решили, что Orbit должна заменить libdui, что повлечет за собой полное переписывание слоя пользовательского интерфейса Harmattan. В конце концов, от этой идеи отказались и несколько месяцев работы пошли прахом.

Пользовательский интерфейс Harmattan был написан с помощью libdui, имя которого позже было изменено на libmeegotouch. В дополнение к этому началась разработка Qt Components набора виджетов с использованием QML на основе JavaScript (Qt Meta-object Language). Qt Components должны были наконец объединить разработку пользовательского интерфейса MeeGo и Symbian, и приложения, написанные на QML, будут работать в обеих операционных системах.

Концепция пользовательского интерфейса Maemo 6

На мероприятии Maemo Summit в октябре 2009 года, состоявшегося еще до начала сотрудничества между Intel и MeeGo, Nokia продемонстрировала концепт интерфейса Maemo 6, разработанного с помощью Qt. В Maemo 6 было обещано объединить стандартный пользовательский опыт и онлайн-составляющую под одной визуальной крышей. Рабочий стол пользовательского интерфейса состоял из нескольких областей (принцип холста) и был заполнен апплетами, виджетами и значками запуска приложений.

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

UMPC Portal, Maemo 6 Early Info. (Slides and info direct from the MaemoSummit)

Интерфейс Harmattan

Оригинальная концепция

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

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

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

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

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

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

Первая версия интерфейса Harmattan

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

Оригинальный пользовательский интерфейс Harmattan, изображение предоставлено Tech CrunchОригинальный пользовательский интерфейс Harmattan, изображение предоставлено Tech Crunch

В течение 2009 года оригинальная концепция и теории, стоящие за ней, были пересмотрены из-за коммуникативных проблем в команде разработчиков и ее расширения. Вместо нескольких холстов на экране появилось много элементов с обширным набором виджетов внутри. Требований стало больше, и количество домашних экранов пришлось увеличить до нескольких. Пользовательский интерфейс становился дезорганизованным и сложным, особенно для разработчиков, но отзывы от пользовательских тестов были лучше, чем когда-либо прежде. Идея была в том, чтобы вложиться в графику интерфейса Harmattan, но эти усилия не были видны в первых реальных версиях интерфейса. Он отличался и из-за излишней сложности было мало общего с оригинальными психологическими теориями. Между тем крайний срок выпуска первого устройства Harmattan от Nokia под кодовым названием Columbus прошел, и разочарование разработчиков возросло.

Интерфейс Simple Dali

Интерфейс Simple Dali, изображение предоставлено: EngadgetИнтерфейс Simple Dali, изображение предоставлено: Engadget

Люди, которые стали руководителями по дизайну пользовательского интерфейса в конце 2009 года, не поняли всей концепции Harmattan UI. И в итоге она была заброшена. В конце декабря 2009 года началась разработка нового интерфейса названием Simple Dali. С его совершенно другой идеей последние остатки оригинальной теории деятельности были отброшены.

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

Он стал очень похож на смартфоны конкурентов. Хотя интерфейс был более понятным и знакомым для разработчиков, он не был конкурентоспособным. Термины Linux и open source не были достаточны для продаж потребителям.

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

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

Swipe UI

В августе 2010 года началась разработка третьей версии интерфейса для Harmattan. Первый рабочий прототип интерфейса под кодовым названием Seattle был закончен через пару дней. Из первых концептуальных изображений стало очевидно, что этот интерфейс был, вероятно, лучшим из когда-либо существовавших в смартфонах. В Seattle было явно видно сколько усилий было вложено в дизайн. Также к жизни вернулись некоторые из основных принципов первоначального пользовательского интерфейса Harmattan, которые были проигнорированы в Dali.

По словам многих из опрошенных нами людей, концепт Seattle UI или Swipe UI был разработан дизайнерской студией 8020 из Нью-Йорка, в которой работают несколько бывших сотрудников Apple и Adobe. Логотип Nokia виден на странице ссылок на веб-сайте компании {сейчас он недоступен прим. перев.}, но изображения Swipe UI не найдены. Несмотря на то, что концепция исходила от внешнего аутсорсера, остальные элементы дизайна были созданы силами Nokia.

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

Устройства Harmattan и MeeGo, разработанные Nokia

По словам сотрудника, который с самого начала работал в командах OSSO, Maemo и MeeGo, оригинальной стратегией MeeGo Кая Остямо (управляющего подразделением Nokia Devices с 2007 по 2010 год) была разработка одного флагманского телефона на рынке в год по аналогии с Apple. По крайней мере, в этой стратегии не планировалось одновременно выводить на рынок множество устройств на базе MeeGo. Ведь даже разработка одного устройства требовала огромных затрат, что уж говорить о нескольких.

Columbus (RM-581)

Первое устройство Nokia на Harmattan получило кодовое имя Columbus и должно быть выпущено в первой половине 2010 года. То есть, всего через несколько месяцев после объявления о сотрудничестве по разработке MeeGo между Nokia и Intel. Тем не менее, путаница и задержки в разработке интерфейса Harmattan привела к отставанию по сравнению с первоначальным графиком выпуска. Релиз Columbus был отменен в конце 2009 года, когда была начата разработка интерфейса Simple Dali для нового устройства под кодовым названием Dali.

Дизайн Columbus похож на Nokia N8 на базе Symbian^3, который увидел свет осенью 2010 года. После отказа от Columbus было решено использовать его дизайн в телефонах Symbian. Это вызвало восхищение у команды Maemo.

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

На задней стороне находится 12-мегапиксельная камера с автофокусом и оптикой Carl Zeiss, скорее всего та же, что и в N8.

Источник: My Nokia Blog, Exclusive: Leaked Images of RM-581 ColumbusHarmattan Prototype

N9-00 Dali (RM-680)

После задержек в разработке пользовательского интерфейса Harmattan и отмены Columbus в качестве устройства для разработки использовался смартфон под кодовым названием Dali с клавиатурой QWERTY. Весной 2010 года он был платформой разработки для интерфейса Simple Dali замену оригинального интерфейса для Harmattan, который был отменен в конце 2009 года.

Dali должен был выпущен на рынок под индексом N9-00. Тем не менее, выпуск было решено отменить, потому что его посчитали устаревшим к моменту поступления в продажу. Некоторый объем устройств (92 000 штук) уже был изготовлен, поэтому Dali был выпущен одновременно с N9 как устройство только для разработчиков под названием N950. Его нельзя было купить, но Nokia распространяла его среди разработчиков.

Корпус Dali был сделан из алюминия и имел 4-дюймовый ЖК-дисплей с разрешением 854480. Сердцем устройства был чипсет Texas Instruments OMAP 3630 (ARM Cortex A8), графический чип PowerVR SGX530 и 1 ГБ ОЗУ. Телефон также был оснащен модулем камеры на 12 мегапикселей.

Engadget, Nokias QWERTY-slidin N9 shows up in the wilds of China

N9-01 Lankku (RM-696)

21 июня 2011 года Nokia выпустила N9, который проходил под кодовым названием Lankku. Он использовал операционную систему MeeGo 1.2 Harmattan. Вместо того, чтобы рекламировать его как телефон на MeeGo, его фишками были дизайн и интерфейс Swipe. Корпус N9 изготавливается путем фрезерования крышки из единого куска поликарбоната, сверху было изогнутое защитное стекло. Позже Nokia использовала дизайн N9 в своих телефонах Lumia на Windows и выиграла множество дизайнерских премий. Элементы из Swipe UI использовались в доступных телефонах Asha от Nokia.

Lankku должен был появиться на рынке с индексом N9-01. После того, как Nokia объявила о своей новой стратегии на рынке смартфонов в апреле 2011 года выпуск модели N9-00 с QWERTY-клавиатурой (кодовое название Dali) было решено отменить, именно Lankku был выбран для разработки готового продукта и получил название N9.

N9 имеет те же характеристики, что и Dali. Это SoC Texas Instruments OMAP 3630 (ARM Cortex A8), работающим на частоте 1 ГГц, графическим процессором PowerVR SGX530 и гигабайтом оперативной памяти. В задней части находится 8-мегапиксельная камера с оптикой Carl Zeiss и двойная светодиодная вспышка.

N9 появился в рознице в сентябре 2011 года, и для него было выпущено несколько обновлений программного обеспечения. Последнее из которых PR 1.3, стало доступно в июле 2012 года. Пару дней спустя многие члены команды MeeGo покинули компанию, включая менеджера Сотириса Макриганниса.

Lauta (RM-742)

Nokia собиралась выпустить телефон под кодовым названием Lauta с клавиатурой QWERTY сразу после Lankku в конце 2011 года. Корпус телефона был, как и у N9 сделан из поликарбоната. Единственное отличие выдвижная клавиатура QWERTY. Внутри Lauta использован тот же OMAP 3630 от TI, что и в N9.

Это был бы преемник N900, которого так ждали многие, но он никогда не видел свет как готовый продукт. Nokia обычно давала официальный индекс модели в последнюю минуту перед выпуском, а индекс Lauta не известен. И не факт, что он вообще когда-либо существовал.

Источник: My Nokia Blog, Leaked Prototype: Nokia Lauta RM-742 Cancelled Immediate N9 Successor

Soiro (Intel MeeGo)

Так же Nokia разработала устройство на основе SoC Intel Atom и архитектуры x86 под кодовым названием Soiro. Имеется весьма скудное количество информации об этом устройстве, но оно точно использует тот же дизайн, что и Lauta. Это означало наличие выдвижной QWERTY-клавиатуры.

Вместо Harmattan в Soiro использовалась платформа Ilmatar _{которую назвали в честь богини воздуха Ильматар, в финской мифологии участвовашей в создании мира прим. перев.}_, что означало применение пакетного менеджера RPM и адаптацию платформы под аппаратное обеспечение Intel. По словам разработчиков программного обеспечения, с которыми мы беседовали, работа с платформой Ilmatar и оборудованием Intel была чрезвычайно сложной задачей.

Интерфейс Ilmatar должен был использовать другой подход, целью которого было выяснить, какая информация будет получена от пользователя. Для этого использовались современные технологии, которые определяли как эта информация может быть представлена в самом интерфейсе. Новый интерфейс, отличался от того, что было ранее. Интерфейс Ilmatar должен был стать одним из преимуществ устройства Intel-MeeGo от Nokia.

Планшет Senna

Engadget, Nokia collects design patent for a tablet

Многие бывшие работники Nokia, с которыми мы беседовали, подтвердили, что дизайн планшета под кодовым названием Senna до этого засветился в патентах компании. Senna был похож на гигантский N9, и был основан на платформе ST-Ericsson NovaThor U8500. Он поддерживал видеосъемку с разрешением 1080p. Senna использовал настоящую MeeGo вместо Harmattan, но пользовательский интерфейс и приложения были такими же, как в N9.

U8500 состоит из двух ядер ARM Cortex A9, графического процессора ARM Mali 400 и имеет модем HSPA +, интегрированный в один и тот же чип.

Рабочий прототип планшета с дизайном N9 был также представлен в конце 2010 года генеральному директору Стивену Элопу, который похвалил устройство. Однако, немного позже Senna навсегда канул в Лету вместе с отказом от стратегии MeeGo.

Engadget, Is this Nokias tablet-shaped MeeGo device?

Fonearena, Nokia MeeGo Device Based on ST Ericsson U8500 Platform

Сотрудничество Nokia и Intel

В времена руководства Олли-Пекки Калласвуо компания Nokia активно работала за пределами США. Особенно активна она была в конце эпохи его правления. Nokia полностью провалилась в Северной Америке, ситуация была катастрофической. iPhone от Apple и Android от Google обеспечили более простой пользовательский опыт, чем Symbian. Поэтому, Nokia могла продавать только продукты, представленные глобально. Их предлагали только мобильным операторам и клиентам из Америки, которые явно об этом просили.

В начале 2010 года стало ясно, что на североамериканском рынке будут доминировать сети LTE и телефоны с поддержкой LTE. В то же время Nokia приняла критические решения относительно железа, которое будет использоваться в будущих устройствах MeeGo.

В октябре 2008 года Texas Instruments объявила, что прекратит развивать направление модемов для смартфонов и начала поиск покупателя на этот бизнес. Будучи в весьма затруднительном финансовом положении, TI намеревалась сэкономить около 200 миллионов долларов и сосредоточиться исключительно на разработке процессора OMAP 4.

Для Nokia это означало конец использования TI OMAP на смартфонах с MeeGo. А все, потому что ранее Nokia решила покупать чипсеты для смартфонов, то есть процессор и модем у одного и того же производителя. Nokia использовала SoC OMAP от TI во всех своих ранних устройствах на Maemo, а также разрабатывала свои устройства Harmattan на основе TI OMAP 3640.

  • N770: OMAP 1710

  • N800: OMAP 2420 (330 МГц)

  • N810: OMAP 2420 (400 МГц)

  • N900: OMAP 3430

  • N950, N9 и Lauta: OMAP 3640

Альтернативами линейкам SoC OMAP 3 от TI были Qualcomm и Intel. Nokia отдала предпочтение Intel. Qualcomm могли бы предложить выполнение адаптации аппаратного обеспечения, низкоуровневой прослойки ПО, объединяющего операционную систему с чипсетом. Однако она не помогла бы в разработке операционной системы, то есть Harmattan или MeeGo. У Intel была скороспелая MeeGo и возможность сотрудничества в этом направлении.

Один из собеседников назвал решение относительно Intel катастрофическим. Однако для Qualcomm, MeeGo не была бы слишком приоритетной разработкой по сравнению с Android и Windows Phone. Выбор Intel как поставщика, полностью игнорировал рынок Северной Америки, поскольку у Intel не было значительных планов по поддержки CDMA-сетей, которые широко используются в США.

Nokia и Intel также вложили значительные средства в разработку сетевой технологии четвертого поколения WiMAX, которая параллельно конкурировала с LTE. Среди конкурентов по 4G первое появление WiMAX состоялось, когда Sprint построил сеть 4G в США с использованием технологии WiMAX. Однако, развертывание сети было медленным, и на практике скорости передачи данных в сети были далеки от теоретических максимальных скоростей.

Предлагаемые LTE лучшая совместимость, надежность и фактические скорости передачи, сделали эту технологию предпочтительной для операторов сетей при построении сетей 4G. Когда Nokia делала свой будущий выбор аппаратного обеспечения после OMAP от TI, у Intel не было осмысленного плана или графика реализации поддержки LTE.

Даже сегодня, по прошествии 2,5 лет, Intel не предлагает интегрированную поддержку LTE в своем последнем SoC Atom Medfield. Она только объявила о начале поставок тестовых версий своего модема Intel XMM 7160 к концу года, а также о доступности этих чипов в 2013.

TechCruch, Intel Confirms Medfield x86 Chips Dont Support LTE Yet

Переговоры с Qualcomm были, по-видимому, возобновлены позже, и планировалось выпустить устройство MeeGo на основе Snapdragon от Qualcomm после выпуска аппарата на базе Intel MeeGo.

Дополнение: После публикации материала мы получили информацию, что Nokia в начале 2011 года разрабатывала версию N9 с Qualcomm Snapdragon для рынка США (скорее всего, RM-716). Это дало возможность выбрать Nokia новую стратегию. так как Windows Phone был создан на аналогичной платформе. Прототип Sea Ray (Lumia 800) с дизайном, идентичным N9, демонстрировался сразу после запуска N9.

Платформы Intel для смартфонов: Moorestown и Medfeild

В дополнение к отсутствию поддержки LTE, другой разработчик MeeGo рассказал, что Intel пыталась со своей стороны замедлить развитие MeeGo. MeeGo был разработан с поддержкой архитектур x86 и ARM, а набор из чипсета Intel Atom и ОС MeeGo, который получил кодовое название Ilmatar еще не был готов. Intel боялась, что она будет не самой сильной стороной с ее чипами на x86, и многие вещи, связанные с разработкой операционной системы, были полностью свалены на Nokia.

Весной 2010 года Intel представила на рынке платформу для смартфонов под кодовым названием Moorestown, которая состояла из процессора под кодовым названием Lincroft, изготовленного по техпроцессу 45 нм, чипа периферии Langwell (65 нм) и модема. Семейство чипсетов Atom Z6xx работало на тактовой частоте 1,2-1,9 ГГц, имело одно ядро процессора и графический процессор Intel GMA 600. Платформа Moorestown так и не была выпущена на рынок смартфонов и была заброшена Intel.

В начале 2011 года Intel показала платформу Medfield, изготовленной по техпроцесссу 32 нм, в которой все функции сведены в один SoC под кодовым названием Penwell. Платформа Penwell оснащена процессором Atom с тактовой частотой 1-2 ГГц с поддержкой Hyper-Threading, графическим процессором PowerVR SGX 540, 512 КБ кэш-памяти второго уровня и контроллером памяти LPDDR2.

В течение 2012 года было выпущено несколько телефонов Android на базе Medfield, таких как Lenovo K800 и Orange San Diego. RAZR i от Motorola самый продвинутый смартфон на базе Intel, в котором используется платформа чип Atom Z2460 (Medfield) с частотой 2 ГГц.

Стивен Элоп как генеральный директор Nokia

Главным изменением, когда Стивен Элоп занял кресло генерального директора Nokia стал фокус на рынок Северной Америки. Согласно взглядам Элопа, тенденции, которые берут свое начало в США, будут доминировать по всему миру. Это доказали iPhone и Android. Вот почему Nokia должна была быть конкурентоспособной на сложном американском рынке, чтобы добиться успеха во всем мире.

Вскоре после начала работы в Nokia Элоп начал работу над проектом Sea Eagle, целью которого было разобраться и проанализировать альтернативы стратегии Nokia на рынке смартфонов. В дополнение к десяткам сотрудников внутри компании, были наняты консультанты извне. В результате было принято решение, что комбинация Symbian и MeeGo была недостаточна для успешной долгосрочной стратегии.

В США AT&T согласилась бы продавать N9, хотя аппаратно он считался устаревшим по сравнению с конкурентами Android. Видимо, еще одна версия N9 была в разработке для Verizon под кодовым названием RM-716 {как раз та самая версия на Snapdragon, см. выше прим. перев.}. Даже если бы N9 был выпущен в Северной Америке в 2011 году, у Nokia не было преемника с поддержкой LTE, который можно было бы продавать в долгосрочной перспективе на динамичном рынке смартфонов.

В записке, которую Элоп, разослал своим сотрудникам, было отмечено, что к концу 2011 года Nokia может поставить на рынок только один телефон на MeeGo. По ходу анализа ситуации, выяснилось, что у команды MeeGo не было ни одного устройства, которое можно было бы показать Элопу или правлению Nokia. А ведь эти устройства должны были появится к праздникам конца 2010 года.

Устройства на основе OMAP 3630, примененного в N9, могли бы появиться на рынке в сжатые сроки, но экосистему для конкуренции с Apple и Google, пришлось бы строить вокруг чипа без LTE и поддержки североамериканских операторов. Так же по ходу сотрудничества с Intel не было бы чипсета среднего класса, который позволил создать конкурента с более дешевыми телефонами Android. Symbian для этого более не подходил.

Летом 2011 года работа над Nokia N9 была завершена, и он был готов к релизу. Поставки в магазины начались осенью этого же года, так как у Nokia наконец-то был четкий план по разработке. Это был прямой результат стратегии Windows Phone принятой Nokia и Microsoft. Компания дала полномочия команде принимать решения, над проектом работало меньше людей, внутреннее и внешнее соперничество в Nokia наконец-то прекратилось. Все сосредоточились на завершении продукта.

В итоге MeeGo не привлекла других производителей. Nokia была лидером рынка, и другие считали, что Nokia занимает слишком много места в проекте MeeGo. В конце 2010 года были проведены переговоры с Samsung, LG и Sony Ericsson, но никто из них не решился на сотрудничество с Nokia для развития экосистемы MeeGo. Кроме того, крупные европейские операторы одновременно отказались от инвестиций в проект.

Горящая платформа и новая стратегия смартфонов Nokia (февраль 2011 г.)

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

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

Этот человек пережил падение и нахождение в холодной воде. После спасения он заметил, что горящая платформа привела к радикальным изменениям в его поведении.

Элоп написал, что все последние месяцы он обсуждал ситуацию с акционерами, операторами, разработчиками, поставщиками и сотрудниками, и сказал, что Nokia также стояла на краю горящей платформы. Под платформой Элоп подразумевал мобильные телефоны Nokia, смартфоны, операционные системы MeeGo и Symbian. На этой платформе, однако произошел, не один взрыв. Их было много. При этом он ссылался на агрессивных конкурентов, таких как Apple iPhone, Google Android и дешевые мобильные телефоны как грибы после дождя, появляющиеся на рынке Китая. По словам Элопа, на 2011 год у Nokia не было продукта, который был бы даже близок к пользовательскому опыту iPhone выпущенному в 2007 году. А Android за прошедшие два года уже обогнал Symbian.

Ожидалось, что MeeGo позволит укрепить позиции на рынке смартфонов высокого класса, однако, по словам Элопа, в обозримой перспективе у Nokia будет только одно устройство MeeGo к концу 2011 года.

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

Nokia + Microsoft = Lumia + Windows Phone

В соответствии с новой стратегией Nokia, объявленной 11 февраля 2011 года, компания договорилась о стратегическом партнерстве с Microsoft для создания глобальной мобильной экосистемы. ОС Windows Phone 7 от Microsoft, выпущенная осенью 2010 года, и ее последующие версии станут новой основной платформой для смартфонов Nokia. Nokia объявила о разработке новых функций для системы в тех областях, где компания является лидером на рынке, например, в области цифровых изображений.

С вновь объявленным партнерством Nokia внесет свой вклад в будущее платформы Microsoft Windows Phone. Nokia предоставит экспертные знания в области проектирования аппаратного обеспечения, языковой поддержки и локализации программного обеспечения и поможет вывести Windows Phone в новые ценовые сегменты, области рынка, новые регионы.

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

Nokia и Microsoft объединят свои силы для создания экосистемы с невероятными глобальными масштабами. Теперь мы как тройка удалая, продолжил Элоп.

Nokia Lumia 700 и 800Nokia Lumia 700 и 800

Nokia выпустила свои первые телефоны Lumia 710 и 800 на базе Windows Phone 7.5 в сентябре 2011 года, которые представли накануне на мероприятии Nokia World.

Jolla продолжает разработку MeeGo от Nokia

Финская компания Jolla Ltd., основанная бывшими разработчиками MeeGo из Nokia, вышла в свет через Twitter в июле 2012 года. Компания, в которой на данный момент работает около 60 человек, продолжает разработку операционной системы и смартфонов MeeGo, где ранее остановилась Nokia.

Операционная система на базе MeeGo, использующая пакетный менеджер RPM, получила название Sailfish. Jolla запустит лицензирование Sailfish для производителей устройств весной 2013 года. Sailfish строится на основе проекта с открытым исходным кодом Qt и Mer Core и масштабируема для использования в смартфонах, планшетах и телевизорах, и других устройствах.

Jolla представит интерфейс системы, который она разработала, на мероприятии Slush, которое состоится 21-22 ноября. Там же Jolla также собирается анонсировать SDK для ОС Sailfish. Кроме того, Jolla намерена раскрыть информацию о своем устройстве на Sailfish до Рождества.

Согласно пресс-релизу Jolla, они объединили партнеров, включая производителей чипов, OEM и ODM, операторов и розничных продавцов. Они также собрали около 200 миллионов евро на создание экосистемы вокруг операционной системы Sailfish. Эти операции будут управляться из Гонконга, так как компания полагает, что следующие большие изменения на рынке мобильной связи должны произойти в Китае.

Заключение

Практически все нынешние и бывшие сотрудники Nokia, у которых я брал интервью, высоко оценили работу команд Maemo и MeeGo, хотя в процессе было набито много шишек. Состав команды был очень многонациональными, а задачи были очень интересными, и все участники по-настоящему радели за общее дело. Многие заявили, что гордятся N9.

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

Оглядываясь назад, можно легко указать на факторы, которые привели к падению MeeGo. Nokia создавала Harmattan и MeeGo вместе с Symbian. Ресурсы тратились впустую, когда обе команды разрабатывали свои собственные инструменты проектирования пользовательского интерфейса на основе Qt. Приложения создавались с использованием незавершенных инструментов разработки. Кроме того, отсутствовала коммуникация внутри команды Maemo. Развитие Harmattan началось вместе с Fremantle или Maemo 5, но между соответствующими командами не было обмена информацией. Ошибки развития, допущенные с Fremantle, повторялись при разработке Harmattan.

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

Интерфейс Harmattan был разработан без понимания того, в каком устройстве он будет применен. В конечном итоге интерфейс был переработан дважды, и это заняло почти два года. Во время разработки были похоронены два устройства Columbus и Dali. Возможно, Swipe UI и N9, была бы успешной комбинацией, но платформа OMAP 3 от TI считалась устаревшей на момент выпуска N9. Не было речи и о поддержке LTE.

MeeGo стал новым Symbian в начале 2009 года. Все доступные ресурсы и персонал были брошены на MeeGo. У новых сотрудников могло не быть какой-либо конкретной задачи, потребовалось много времени, чтобы найти для них какие-то подходящее место в структуре. Появлялось все больше руководящих должностей, что в итоге не помогало двигать проект вперед и вести его к завершению. Каждый в Nokia имел свое мнение о MeeGo, и команда MeeGo слушала всех.

Выбор Intel в качестве партнера по разработке ОС и предоставлению железа был самой большой ошибкой. Intel годами разработала мобильный чипы на базе Atom x86, но только в этом году первые смартфоны на базе x86 были поступили в продажу. Даже сейчас у Intel нет модема для сетей LTE, и эта ситуация продлится до 2013 года. Более того, у Intel не было чипа для устройств начального и среднего уровня. А это было необходимо, чтобы конкурировать с недорогими смартфонами Android.

Пока Nokia погружалась в пучину разработки Harmattan и MeeGo, ее злейшие конкуренты Apple и Google успешно создали работающие экосистемы вокруг своих операционных систем и захватили рынок Северной Америки. Nokia попыталась привлечь других производителей к разработке экосистемы MeeGo. Однако заинтересованных сторон не было, и Nokia осталась одна. Без поддержки LTE, а также без надежных партнеров в войне экосистем прорыв на рынок США был бы едва ли выполним.

iOS от Apple закрытая платформа, а Google не позволил бы Nokia иметь какие-либо преференции при присоединении к платформе Android. Nokia выбрала Windows Phone в качестве своей новой стратегии для смартфонов под руководством Стивена Элопа и начала стратегическое сотрудничество с Microsoft. Теперь у Nokia есть Windows Phone 8 и полный карт-бланш на все.

В этой статье мы в основном брали интервью у финских сотрудников Nokia. Если у вас есть более подробная информация, чтобы поделиться анонимно, пожалуйста, свяжитесь с sampsa.kurri [a] https://muropaketti.com. Особенно приветствуется вся информация о железе от Intel, Lauta, Soiro и Qualcomm.

Подробнее..
Категории: *nix , Гаджеты , История it , Meego , Maemo , Nokia n900

Войны лоббистов и развитие BIM. Часть 4 Борьба CAD и BIM. Монополии и лоббисты в строительной отрасли

15.01.2021 10:11:34 | Автор: admin

В прошлой статье: часть 3: Отцы BIM технологий. Кто стоит за успехом Autodesk и openBIM было показано, насколько все команды разработчиков BIM инструментов связаны друг с другом и как каждая команда разработчиков, заимствовав идеи друг у друга, пыталась сделать свою уникальную BIM программу. При этом почти все значительные идеи или разработки не были созданы большими корпорациями: Autodesk, Nemetschek Group, или Hexagon просто вовремя покупали стартапы у недовольных бывших сотрудников своих конкурентов.

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

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

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

Также теперь эта карта доступна для комментирования: чтобы добавить комментарий к этой схеме или более подробно рассмотреть отдельные фрагменты карты, перейдите по ссылке: Карта развития BIM с 1980 г. по настоящее время

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

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

Начало борьбы CAD и BIM. Пролог.

Все, что сегодня связано с BIM технологиями, пришло к нам из CAD мира 80-х годов, когда в конструировании использовались исключительно CAD технологии. Самые крупные производители CAD ПО в 80-е годы создавали медленное и неуклюжее ПО на устаревших языках программирования - Фортране и ассемблере: IBM / Dassault (CADAM и CATIA), Computervision (CADDS), SDRC (I-DEAS и Intergraph (IGDS и InterAct). Все эти корпорации в начале 90-х отклонили идеи Самуила Гайзберга по разработке новых инструментов в проектировании как малоинтересные и не имеющие будущего технологии. Подробнее об этом в третьей части.

Но за несколько лет, с 1988 по 1990, команде PTC под руководством Гайзберга удаётся полностью изменить подход к конструированию и проектированию во всём мире на несколько десятилетий вперёд. Используя твердотельное параметрическое моделирование с концепцией единой модели, Pro/Engineer от PTC становится первой программой 3D CAD/MCAD, которая почти полностью (кроме рисования пером) реализовала идеи, впервые продемонстрированные Sketchpad Ивана Сазерленда в 1962 году. И уже к середине 90-х Pro/Engineer безвозвратно изменяет представление пользователей CAD программ об интерфейсах, простоте использования программ и быстроте твердотельного проектирования.

Такую же революцию на рынке проектирования в строительной отрасли, которая позже получит имя BIM, осуществил через 10 лет ученик Гайзберга, выпускник Ленинградского университета - Леонид Райц, которого через 10 лет после эмиграции из Советского Союза его бывший учитель математики - Гайзберг - в 1986 году устраивает одним из первых сотрудников в свою новую компанию PTC. За несколько лет, к 1988 году, под руководством Гайзберга Райц создаёт геометрическое ядро для программы Pro/Engineer.

Автодеск открывает для себя BIM

2002 год считается годом рождения новой идеологии, придуманной корпорацией Autodesk - Building Information Modeling - BIM.

В википедии на странице BIM:

In 2002, Autodesk released a white paper entitled "Building Information Modeling, and other software vendors also started to assert their involvement in the field.

До 2002 года сам Autodesk без значимых успехов (как это часто случается с большими бюрократическими организациями) силами своих внутренних разработчиков пытался создать 3D CAD замену своему единственному успешному продукту AutoCAD, который был куплен в 1982 году у Mike Riddle и на котором John Walker (будущий первый CEO Autodesk) смог выстроить успешную бизнес-модель по продаже лицензий - фирму Autodesk.

В 1992 году John Walker передаёт управление компанией новому CEO - Carol Bartz, получает пакет акций Autodesk на 42 mln.$ и эмигрирует в Швейцарию. Сэтого момента, если смотреть на годовые отчеты корпорации Autodesk c 1992 по 2002, складывается впечатление, что после ухода из компании Mike Riddle (создателя AutoCAD) единственным продуктом, кроме AutoCAD, которым занимались разработчики Autodesk и который сегодня ещё остался на рынке проектирования, был AutoCAD Architectural Desktop (о котором сегодня сама корпорация уже старается не упоминать).

Также в этот период Autodesk пытался убрать с рынка своих потенциальных конкурентов, таких как VersaCAD, IntelliCAD, AutoSketch, перекупая стартапы и борясь в судах за патенты и лицензии, чтобы не дать возможности этим стартапам продаться конкурентам.

Но что же обнаружил Autodesk, что в 2002 году резко становится лидером 3D BIM проектирования, опубликовав white paper про BIM, который даст начало новой эпохе в мире проектирования?

Конкретно в 2002 году Autodesk покупает стартап Revit Леонида Райца и именно в предпродажных презентациях Леонида Райца, которые были созданы для переговоров с Autodesk логично искать источник white paper BIM, выпущенного через год после продажи.

За 6 лет команда разработчиков Revit с нуля создала радикально новый подход для программного обеспечения САПР для строительства: с параметрическим моделированием и концепцией единой модели данных для всего проекта, разработанных Самуилом Гайзбергом и Леонидом Райцем ещё в 1988 году для программы Pro/Engineer.

После несостоявшейся попытки Autodesk купить Solidworks (копия программы Pro/Engineer), после неудачного преследования разработчиков IntelliCADD, в 2001 году - уже после покупки Revit - CEO Autodesk Carol Ann Bartz, не ожидая от этого очередного стартапа значимой прибыли, охарактеризовывает Revit как небольшую экспериментальную базу пользователей.

В то время она ещё не подозревает, какой продукт получил Autodesk всего за 130 mln $ и что за Леонидом Райцем стоят не только наработки PTC, но и собственно Самуил Гайзберг, который подарил жизнь таким программам, как Solidworks и Digital Project (для сравнения в 2018 году Autodesk заплатил за Plangrid: стартап-приложения для планшета - $875 mln. Одним из главных учередителей этого стартапа стала бывший CEO Autodesk - Carol Ann Bartz).

В 2000-е новую программу Digital Project, смесь разработки SolidWorks, Catia и Франка Гери, в своей работе использовали многие архитекторы и лауреаты прицкеровской премии, в том числе Заха Хадид с её знаменитыми изгибами и космическими формами зданий, которые после 2005 года стали больше походить на машиностроительные проекты.

Таким образом, технологии, используемые в Revit и доступные машиностроительной отрасли уже с начала 90-х,только через 10 лет, к началу 2000-х, доходят наконец до крупнейшей экосистемы в мире - строительной отрасли.

Экспансия идеологии BIM и программы Revit

В 2002 году, после покупки Revit, Autodesk открывает наконец для себя мир параметрического твердотельного 3D моделирования - технологии, которые ускользнули от Autodesk в конце 90-х из-за отказа разработчиков Solidworks продавать свою компанию по жёсткой цене Autodesk (в 1997 Solidworks за 310 mln $ всё же уходит французской корпорации Dassault Systemes).

И уже через год два вице-президента Autodesk - Phil Bernstein и Jim Lynch - выпускают White Paper - Building Information Modeling (которая была скорее всего в большей части скопирована из презентаций разработчиков Revit) и открывают BIM-идеологию для всего мира.

С этого момента, с 2003 года, начинается отсчет для новой идеологии, захватившей весь мир строительства на следующие двадцать лет, - BIM.

Как же проходила борьба CAD и BIM с того момента, как Autodesk провозгласил приход новой эпохи BIM, или, точнее, как проходила с 2003 года экспансия Revit-технологий в строительное проектирование во всём мире?

Благодаря открытым поисковым данным Google сегодня мы можем проследить этот процесс соперничества CAD и BIM по годам. Посмотрим на развитие популярности CAD и BIM проектирования в странах G20 (The Group of Twenty, major advanced and emerging economies) с 2004 по 2020 год.

Я выделил 4 основных, самых популярных, поисковых запросов, которые были важны в сфере проектирования и планирования, начиная с 2003 года:

  • AutoCAD - основная программа для проектирования и создания 2D чертежей

  • Revit - молодая программа из машиностроения с новым параметрическим моделированием и единой моделью проекта

  • Archicad - основной представитель концепции openBIM, в 2000 году единственный достойный представитель 3D проектирования с визуализацией

  • BIM - запрос по этой фразе показывает интерес к теме BIM относительно других запросов, которые волновали проектировщиков в период с 2003 по 2020 год

Открытые данные по поисковым запросам и реальный интерес к тому или иному продукту или товару могут быть часто не связаны друг с другом, например, в том случае, если этот продукт продается в основном оффлайн (без использования интернета). Но если речь идет о программах и цифровых продуктах, то, конечно, по интересу к продукту в поиске можно относительно судить по общему интересу к продукту и его продажам. Объективные показатели Google Trends по каждому запросу показывают относительную популярность запроса: 100 баллов означают максимальный интерес к теме, а 0 недостаточное количество информации по ней.

В следующем видео я собрал данные по интересу к запросам: Autocad, Revit, Archicad, BIM в каждой из стран, входящих в G20 с 2004 по 2020 год.

По данным, представленным в видео, видно, что с момента начала продаж Revit, который ознаменовал White Paper BIM, интерес к устаревшим технологиям CAD в мире начинает падать. Основные выводы, которые можно сделать из полученных данных:

  • В англоязычных странах (USA, Canada, Australia, UK, South Africa) интерес к теме BIM (точнее, к технологиям и идеям BIM, которые используются в программе Revit) к началу 2021 побеждает технологию 2D проектирования с использованием AutoCAD

  • Европейские страны активно интересуются BIM темой, но, в отличие от англоязычных стран, не хотят полностью попадать под зависимость от корпорации Autodesk, стремясь поддерживать местных локальных производителей САПР ПО, которые пытаются работать по концепту openBIM

  • Южная Америка (за исключением Бразилии) и Азия (за исключением Китая) только начинают проявлять интерес к использованию BIM технологий и начинают инвестировать своё время в эти новые хайповые технологии.

Дополнительный insight по этим данным: в большие национальные праздники, такие как Рождество и Новый год (на видео декабрь 2020 - праздники и lockdown ) во многих странах, запросы по продукту AutoCAD на один месяц уступают интересу по теме BIM и Revit. Люди в праздники, отключившись от рабочих процессов, охотно осваивают новую тему - BIM и Revit.

По поисковым данным можно сказать, что интерес к AutoCAD, то есть к 2D проектированию будет снижаться и дальше. Большинство компаний, занятых проектированием, будут переходить на более прогрессивный Revit, так же как в 90-е все основные машиностроительные компании мира массово переводили свое конструирование на PRO/Engineer.

Но, к сожалению, Revit является не локомотивом корпорации Autodesk, а скорее, тупиковым путем её развития.

Revit - это тупиковый путь развития Autodesk

Как показывают 40 лет существования компании Autodesk, разработчики из силиконовой долины за это время не смогли самостоятельно сделать новых прорывных продуктов ни в одном из направлений CAD и BIM. Почти все программы Autodesk были куплены на рынке стартапов в 90-е и 2000-е годы. А через несколько лет после покупки этих стартапов по жёсткой цене создатели и основные разработчики покидали Autodesk.

Так и создатель Revit - Леонид Райц, который сам не имел отношения к строительству, - в 2004 году покидает компанию Autodesk и после продажи своего стартапа сам становится венчурным инвестором. И хотя Autodesk начинает получать миллиардную выручку на продажах лицензий Revit, активная разработка программы после ухода создателей Revit тормозится, и с этого момента не видно больших нововведений и развития новых инструментов для работы архитекторов и проектировщиков.

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

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

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

История (подробнее в части 3: Отцы BIM технологий. Кто стоит за успехом Autodesk и openBIM) показывает, что за новыми технологиями бесполезно обращаться к сытым и богатым корпорациям. Все прорывные технологии и стартапы двигают вперед только недовольные и голодные разработчики.

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

  • те, кто не готов подстраиваться под Autodesk, подвергаются ценовым репрессиям;

  • основная масса проектировщиков полностью зависит от продукции Autodesk и практически не может пользоваться (или с трудом, через костыли IFC) другими программами;

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

  • основные силы и инвестиции корпорации идут на поддержку продукта, массовую скупку технологий и экспансию идеологии в другие страны;

  • Autodesk собирает под своим крылом разработчиков стартапов, которые, получив денежную свободу, сразу же бегут из корпорации;

  • Autodesk устраняет конкурентов, покупая стартапы и через суды блокируя патенты и дальнейшую разработку конкурентноспособных продуктов.

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

Но всё же какой-то небольшой стимул к развитию у Autodesk остался. Это небольшое противостояние идеологии closedBIM c openBIM на востоке - в некоторых странах Европы и Азии.

Этот искусственный конфликт идеологий нечаянно подарила себе сама корпорация Autodesk, создав (просто зарегистрировав на своё имя) в середине 90-х для выхода из 2D проектирования мировой 3D формат IFC и картельную организацию IAI.

Может быть, openBIM - это та спасительная альтернатива, которая сможет дать отпор каждый год повышающей свои цены Autodesk?!

openBIM - достойная альтернатива Revit?

Единственной альтернативой программе Revit сегодня является зоопарк программ, которые работают по принципу openBIM - через обмен данными в формате IFC.

По представленным во второй части открытым поисковым данным видно, что во всём мире выделяется только несколько стран (Кения, Румыния, Австрия, Швейцария и Германия), которые используют в своей строительной отрасли для проектирования концепт openBIM.

В основном это немецкоговорящие страны. И главным предводителем всего движения openBIM в Европе логично является Nemetschek Group с двумя продуктами: Allplan и Archicad. Они, возможно, уже были бы на грани исчезновения, если бы не формат IFC, который сейчас на время спасает бизнес-модель европейской корпорации.

Формат IFC - это продукт разработки команды мюнхенского университета (и позже зарегистрированный корпорацией Autodesk). Он контролируется с 1997 картелем производителей программ САПР и других корпораций, заинтересованных в установлении своих стандартов во всём мире. Во главе всей этой организации в стоит главный комитет этой социалистической идеологии - buildingSMART International.

Что же такое формат IFC, на котором построен весь концепт openBIM? (про создание IFC подробнее в третьей части):

  1. IFC - это обыкновенный формат PDF, только немного более интеллектуальный

  2. Формат IFC не является форматом обмена данными для дальнейшего редактирования

  3. В IFC нет возможности прикладывать чертежи в единой связке с моделью

  4. Сама модель проекта или любого элемента в формате IFC не подходят для продолжения работы над ними

То есть после импорта IFC файла в любую BIM программу его нельзя будет отредактировать или дополнить. А если вы всё-таки захотите это сделать (а вы захотите это сделать), то оптимальным выходом будет полное воссоздание геометрии в той программе, в которой вы работаете, при этом эта работа будет похожа на копирование рисунка (модели IFC) при помощи светового стола по жирным линиям рисунка оригинала.

Для чего же тогда нужен IFC? Этот формат может понадобиться вам только в том случае, если совместная работа по разделам проекта с другими фирмами, которые предпочитают использовать местные программы, невозможна в одной программе Revit или Archicad. Также вам придётся экспортировать модель в формат IFC, если вашему заказчику понадобится весь проект в формате IFC. Но проблемой в случае экспорте/импорте из разных программ является то, что при импорте IFC вы часто получаете продукт невысокого качества.

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

Хорошим доказательством этого является опрос, проведенный федеральным министерством транспорта, строительства и городского развития Германии (Bundesministerium fr Verkehr, Bau und Stadtentwicklung) среди BIM специалистов в 2013 году.

На вопрос Соответствует ли формат обмена IFC содержанию и вашим формальным требованиям для обмена модельными данными? больше половины опрошенных BIM специалистов ответили, что формат IFC соответствует их требованиям меньше чем на 25%.

Поэтому передовые компании, которые сегодня считаются в Германии ведущими в развитии технологий BIM, такие как Max Bgl, Goldbeck, Hochtief после своего неудачного опыта работы с разными форматами и проблемами импорта/экспорта - переходят на проектирование полного цикла по концепту closedBIM в программу Revit.

Если министерства получают такие исследования и отзывы о затрудненной работе по концепции openBIM, почему тогда многие компании в Германии продолжают настаивать на перспективности этих подходов и почему немецкоговорящие страны выбрали этот не самый лёгкий путь?

Почему немецкоговорящие страны выбрали путь openBIM?

Чтобы понять эту логику, для этого уже в который раз обратимся к истории создания концепции openBIM. В 1995 Autodesk берёт разработку мюнхенского университета формат IFC и создает на его основе новое направление для своей бизнес-модели, под которую создается картельная организация IAI - Индустриальный Альянс за Совместимость. Через два года, уже в 1997 году, Autodesk переводит тему с американского континента в международный масштаб и переименовывает Индустриальный Альянс за Совместимость в Международный Альянс за Совместимость (где опять в названии начинает мелькать попытка создания новой мировой идеологии).

Но, как обычно, у Autodesk ничего не получилось придумать с форматом IFC (до сих пор продукты Autodesk, по невнимательности или по умыслу - с трудом работают с форматом IFC) и к началу 2000-х общий интерес к организации IAI начинает падать. Сам же Autodesk, наконец удачно купивший настоящую BIM программу Revit и окончательно потеряв интерес к социалистической идее Альянса за Совместимость, переключается на создание новой продающей идеологии - BIM.

Европейским же производителям САПР программ не остается ничего, как в начале 2000-х, видя стремительный успех программы Revit, с её закрытым подходом к обмену файлов, открывать заново теряющую популярность и оставленную Autodesk организацию IAI.

Для того чтобы пробудить интерес к старой идее IAI, проводится ребрендинг всего старого картеля, новое имя которого теперь становится настолько же красивым и понятным, как и аббревиатура BIM - buildingSMART. То есть теперь это не просто Международная Организация, которая устанавливает свои стандарты для всего мира, и не просто информационное BIM моделирование от Autodesk. Теперь buildingSMART - это разумное строительство, которое поможет вам сохранить ваше время и ваши инвестиции при проектировании. То есть buildingSMART представляет себя как надстройка над BIM c бережным и умным подходом к данным, получаемым при проектировании.

Также удачной маркетинговой находкой стало создание выражения openBIM - аналога выражения open Source - к которому openBIM не имеет никакого отношения. OpenBIM подразумевает под собой противопоставление концепции closedBIM, которое было притянуто в большей степени самой buildingSMART к корпорации Autodesk. Жаль только, что по факту никакого отношения к open выражение openBIM не имеет и что на практике концепция openBIM оказалась простым средством соединения небольших европейских и азиатских производителей closedBIM программ друг с другом.

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

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

Таким образом, если у вас нет нескольких десятков лишних тысяч, то вы не сможете, к сожалению, участвовать в обсуждении этой мировой открытой технологии openBIM. No money, no honey.

После ребрендинга в 2005 году в buildingSMART заходят все европейские производители местных программ, которые с экспансией Revit, теряя с каждым годом клиентов, теперь находят способ борьбы с Revit - в лоббировании интересов openBIM. C этого момента начинается активное лоббирование интересов концепции openBIM на уровне правительств в тех странах, в которых это лоббирование возможно.

На счастье немецкого филиала buildingSMART, в Берлине к этому времени уже было около 5000 лоббистов, готовых помогать лоббировать интересы немецких компаний, концернов, а также отдельных отраслей. Из них 778 лоббистов имеют прямой доступ в бундестаг, и посещают его, уж точно, не с целью посещения библиотеки. 10% из них (так как строительство занимает 10% от ВВП) - примерно 80 лоббистов, заняты продвижением интересов конкретных компаний связанных со строительной отраслью.

Для примера стандартной схемы лоббирования интересов в строительной отрасли возьмем миллиардный рынок изоляционных материалов Германии.

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

Палочку эстафеты в этом направлении теперь подхватили немецкие производители софта. Производители программ с устаревшими интерфейсами и know-how из 80-х, как и Autodesk, не способны сегодня (благодаря созданию отличной инфраструктуры в 90-е годы) создавать новые технологии и программы. Но, чтобы не потерять место на миллиардном рынке САПР в Европе, через лоббирование своих интересов и законодательных инициатив они предлагают европейским правительствам открыть новую эру проектирования в Европе под эгидой openBIM.

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

Как на практике происходит лоббирование концепции openBIM?

Как лоббирование происходит на практике

Возьмём для примера инфраструктурное строительство Германии. Одним из главных игроков на этом рынке является акционерная компания со стопроцентным государственным участием - Немецкие железные дороги (Deutsche Bahn). Deutsche Bahn, один из крупнейших строительных подрядчиков Германии в середине 2000-х, замечает новые эпохальные технологии от Autodesk и создает инструменты и библиотеки элементов для быстрого проектирования, что приводит компанию за короткое время в новый мир BIM технологий и инструментов, которые используются в новых продуктах Autodesk.

Но производители местных программ САПР в таком быстром развитии уровня проектирования видят видят угрозу для своего бизнеса. Ещё 20 лет назад, до начала эры интернета (а в некоторых регионах ещё и сегодня) они доводили до людей информацию о новых технологиях и новых CAD программах через книги, журналы, газеты и продавцов ПО, которые гастролировали от компании к компании, рассказывая про новые технологии за процент от продаж.

Таким образом,к концу 90-х из-за отсутствия современных продуктов от Autodesk и вследствие отсутствия прозрачности в доступе к информации, производители местных САПР чувствовали себя уютно на рынке Европе и мало заботились о конкуренции.

Но с приходом новых технологий от Revit и BIM идей, европейским производителям приходится искать новые пути, чтобы оставаться на рынке программ САПР. Для этого воскрешается организация IAI, которая после 2005 года становится более европейской. Теперь благодаря пролоббированным законодательным инициативам при поддержке министерств, большие немецкие компании с государственным участием разворачиваются в сторону совместной работы по методикам buildingSMART. И вся ситуация с развитием строительства теперь встаёт на рельсы концепции openBIM.

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

В итоге компании вынуждены посылать своих специалистов и менеджеров на двухдневный вебинар для получения важного сертификата buildingSMART, без которого компании не получить необходимый заказ. На этом чисто теоретическом вебинаре за 2 тысячи евро объясняется идеология openBIM и важность работы с проектами через обмен данных в формате IFC при помощи многообразия программ и аббревиатур (BAP, PIM, LIM, PIA, LIA, OIA), а также аккуратно указывается на преимущества некоторых программ в проектировании по данному методу. После чего следует экзамен, где проверяются основные понятия, которые нужны для работы с зоопарком программ по концепции openBIM.

В итоге эта стратегия лоббирования интересов openBIM и бюрократизация процессов приводит сегодня Германию в конкретной отрасли к плановой экономике и к тому, что в Германии процент строительных проектов, в которых применяется BIM, находится на самом низком уровне в Европе, составляя в 2019 году всего 20%. При этом в северных странах Европы количество проектов с применением BIM - больше 60%.

В итоге, сегодня концепция openBIM побеждает в отдельно взятой стране и как следствие в целом регионе Европы.

Дополнительно я сравнил данные по распространению технологии BIM в Европе c популярностью поискового запроса по слову Revit в период с 2004 по 2020 год.

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

Самым проблемным из них стал столичный аэропорт в Берлине (BER), проектирование которого велось в начале 2000-х и строительство которого планировалось провести за 3 года. Изначальная сдача объекта была запланирована на 2011 год, но в итоге строительство длилось 14 лет и объект был сдан в эксплуатацию только в октябре 2020 года. В начале проектирования проекта BER технологии BIM только зарождались, но можно логично предположить, что до ввода в эксплуатацию в 2020 году единая модель проекта по концепции openBIM всё же была сформирована.

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

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

Тему с лоббированием отдельных интересов хорошо дополняет цитата из интервью (в газете Handelsblatt) с иконой немецкой промышленности - Martin Herrenknecht (создатель тоннелепроходческих щитов), который на вопрос по поводу развития инфраструктурных проектов в Германии ответил:

700 депутатов Бундестага ведут самостоятельную жизнь и имеют мало отношения к реальной повседневной жизни граждан. Меня очень беспокоит положение дел в Германии. Оно становится очень серьёзным.

В заключение

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

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

А кто из нас сегодня добровольно готов будет отказаться от спекуляции цен и откатов?

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

Монополии buildingSMART и Autodesk сегодня являются прямым отражением интересов своих подопечных - строительного сообщества. Именно поэтому строительная отрасль в целом и проектировочные бюро в частности не могут жаловаться на своих правителей-диктаторов (корпорацию Autodesk & co.), если сами они, на своём уровне, сегодня не готовы перейти в социализм и согласиться на прозрачную работу через стандартизированные классификаторы и прозрачные расценки по работам и материалам.

Какие низы, такие и верхи. Народ стоит своего правителя.

Шарль Морис де Талейран-Перигор

Должно ли государство заниматься вопросами контроля и установления правил? Конечно, нет. Строительная отрасль должна начать меняться снизу.

Хочется добавить, что,благодаря дешевым деньгам пенсионных и государственных фондов, сила корпораций и организаций, лоббирующих конкретные интересы, растёт в параболической прогрессии не только в отдельных странах, но и в мире. Пятёрка основных корпораций находятся под управление одних и тех же инвестиционных фондов: Warburg, BNP, Blackrock (см. карту схему: BIM development map) и они перестают конфликтовать и бороться за выживание. На счетах этих корпораций скапливается огромное количество дешевых денег: они в состоянии поглотить любой стартап и технологии в любой стране мира и на любых услових.

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

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

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

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

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

Буду рад вашим комментариям, уточнениям и критике.

Подробнее..

Перевод Все придумано до нас современные VR-технологии базируются на идеях 60-х годов прошлого века

06.01.2021 16:04:08 | Автор: admin

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

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

Взаимодействие и эмуляция


Важнейшими элементами VR являются интерактивность, возможность взаимодействия с окружением, и само окружение, вернее, его эмуляция. В 1960-х существовало два прототипа этих технологий.

Так, Link Trainer был ранним прототипом симулятора полетов. Цель проекта предоставить пользователю реалистичное полетное оборудование и обеспечить обратную связь с инструментами управления полетом. Все это давало возможность студенту-авиатору получить наглядное представление о полете и разных его условиях без риска для себя и самолета. Подходил симулятор и для профессионалов, которые могли совершенствовать свои навыки.



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

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


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

The Ultimate Display


В 1965 году Иван Сазерленд (Ivan Sutherland), специалист по компьютерным технологиям, написал эссе The Ultimate Display (PDF). В нем он изложил идеи, которые опередили его время. К сожалению, для их реализации не было технологических возможностей, хотя кое-что автор все же сделал. Что касается эссе, то оно небольшое, всего две странички. В первой части автор размышляет об интерактивности компьютеров и технологиях ввода 60-х.

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

Полная интерактивность



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

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

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

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

Идеи из 60-х, которые удалось реализовать


Большинство концепций и идей, описанных авторами в 60-х, мы используем сейчас в виде технологий. Вот основные идеи.

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

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

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

Тактильная обратная связь

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

Отслеживание положения головы и рук

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

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

Осязание, обоняние, иные тактильные ощущения

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

А что пока не получается внедрить?


Высокоточное отслеживание взгляда

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

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

Точная силовая обратная связь

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

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

Идеальная симуляция

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

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

Звучит, как часть сюжета Матрицы, правда?

Отделяем важные функции от просто классных


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

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

Зато очень важно экран с хорошим трекингом и малой задержкой. Человек знает, что у него на голове шлем, но мозг как бы не обращает внимания на это, считая картинку на экране реальной. Подобного нет, если использовать старые видешлемы. Например, в середине 90-х был доступен Forte VFX1 VR. Но, конечно, он и рядом не стоял с нынешними видеошлемами. Технологии того времени просто не позволяли создать качественную виртуальную реальность, куда человек мог бы погрузиться с головой.

Что дальше?


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


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

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

Подробнее..

Путь в IT воспоминания бумера, часть 1 из 3

19.01.2021 16:11:16 | Автор: admin

(Навеяно статьей Олды в IT). На самом деле я не бумер, так как родился в 1968 году и отношусь, скорее, к "потерянному" поколению. Но дети мне говорят "ok, бумер", так что я не против этого ярлыка. Тем более, что время это было прекрасное (не в СССР, конечно). Мощные машины, нет театра безопасности, приход в аэропорт за 15 минут до вылета (я это застал!). Ну а в нашем 2020/2021 вообще, без слез в прошлое не взглянешь.

Если бы путешественник во времени из 1960-70х оказался бы в наше время, то мне с грустью пришлось бы ему сказать, что глобально все изменилось только к худшему. На Луну летать перестали, в аэропорту разве что трусы не надо снимать, тотальная слежка, машины превратились в "европерделки", ну и вирус. Стоит ли это возможность строчить посты в социальных сетях и не видеть родственников месяцами и еще некоторых мелких плюсов? Не думаю. END OF старческое брюзжание;

Мое первое IT воспоминание - БЭСМ-6. Я стою с мамой в вычислительном центре на улице Марата. Работает программа для расчета поведения фреона, медленно подбираясь к критической точке. И когда эта точка достигается, программа останавливается по ошибке. Мама переживает. Это, вероятно, был 1978 год.

С БЭСМ мне так и не удалось познакомиться. Зато папе на работе давали в пользование калькуляторы. Я все время что-то считал и строил графики:

Этот калькулятор мне дал очень хорошее "чувство числа" - даже когда ты не можешь вычислить ответ, ты сразу понимаешь, что вот тут слишком мало или слишком много. Уже тогда нашел в этом калькуляторе скрытый регистр. Еще можно было ставить его на приемник Ленинград 002 и слушать на средних волнах помехи, создаваемые калькулятором. Вначале они были однообразными, но стоило ему сильно разрядиться - в эфире начиналось нечто, и немыслимые трели сменяли друг друга.

Следующим моим другом стал вот этот калькулятор, самый первый программируемый.

Он был примитивнее более поздних моделей. Например, в этой модели для формирования команды условного или безусловного перехода адрес набирался не цифрами. Вместо этого делалось так: допустим, адрес перехода 56. Надо вспомнить, какая команда имеет код 56 и набрать ее (своеобразная обратная логика).

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

Вдруг меня озарило, что если к числу добавить 10000000, вычесть 10000000, то результат округлится, и если сравнить результат с исходным результатом деления, мы сразу все поймем. В момент этого озарения я и стал программистом, попутно поняв, что можно проверять только нечетные делители (и 2), и до sqrt(x). Это было тривиальным шагом для IT, но громадным шагом для меня. Вроде Армстронг сказал почти так. Тогда я был в классе в пятом-шестом.

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

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

Одновременно я (тоже на работе у мамы) получил доступ к очень странной машине, ДЗ-28. Это совершенно удивительное творение компьютерной мысли. Не могу не рассказать о ней.

Машина выглядела как огромный калькулятор, который работал в двоично-десятичной системе. Числа были 12-значными, плюс знач числа, знак порядка, две цифры порядка - 16 тетрад. На экране был виден и регистр X, и Y (да, все та же стрелочка вверх и обратная польская запись). При этом память у него была 32K, а были модели и с бОльшей памятью. После программируемого калькулятора это был совершенно фантастический объем памяти!

Программы можно было записывать на ленту. Но самым фантастическим в этом устройстве была его система команд. Это была запредельная эклектика. Плавающие числа хранились иногда в 8 байтах, а иногда в 16 по тетрадам (четные/нечетные в соседних тетрадах). Для целых система команд походила чем то на PDP-11 - были регистры R0-R7, команды CMP, JMP, и короткие BR, BEQ, BNEQ, BGT и подобные в районе +/- 127 байт.

Одновременно присутствовал переход по метке. Была команда - метка (код не помню). Второй байт был номером метки, так что меток было 255. Команда перейти на метку эту метку искала. Да, перебирая всю память с адреса 0, читая байт за байтом, правильно отделяя однобайтные команды от двухбайтных. Далее эта команда либо находила метку, либо упиралась в команду 0512 (END) (О боже, почему я помню коды?). Команда END, также была нужна, чтобы ограничить область, которая пишется на магнитофон. Довольно подробная документация писала, что сканирование памяти осуществляется со скоростью 1 байт за 4 микросекунды.

Кстати, о кодах. Команды вводились так:

Слева наверху кнопки 80.40,20,10 работали как триггер, переключая лампочки разрядов. Допустим, нам надо было ввести команду STOP (05 14). Надо было убедиться что горят лампочки .1.1 (40+10 = 50), то есть 05 в старшей тетраде. Если лампочки горят по другому, то надо нажать на кнопку тех лампочек, которые горят не так. Теперь, когда в старшей тетраде у нас 05, нажимаем клавишу 14. Ввелось 05 14.

Уже позже я встретил эту машину подключенной к знаменитому фразинскому терминалу и с бейсиком.

Но школьное время заканчивалось, я уже вкусил немного PDP-11 с RSX-11M, и начинался новый этап жизни.

(дальше будет больше событий и техники - планирую части 'Институт, СМ и VAX' и 'Карьера в лихие 90е'

Подробнее..

Электромеханический арифмометр ВК-2

02.01.2021 14:12:00 | Автор: admin

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

Машина представляет собой дальнейшее усовершенствование известнейшего арифмометра Однера (арифмометры Феликс и ему подобные). Усовершенствования направлены прежде всего на ускорение работы и автоматизацию некоторых операций. В частности, одним из самых больших неудобств является то, что в арифмометре Феликс число необходимо набирать на барабане с помощью рычажков, по очереди двигая их на соответствующую позицию. Это занимает достаточно много времени и требует внимания оператора. В данном арифмометре (как и в предыдущей модели, ВК-1) числа вводятся намного быстрее - нажатием цифровых клавиш, почти как в современном калькуляторе. Также в нем полностью автоматизированы операции деления и очистки установочного регистра (барабана). Умножение полуавтоматическое.

Арифмометр выпускался с 1951 по начало 1970-х. Данная модель выпущена в 1974 г., одна из последних. Сделан по образу и подобию шведской модели фирмы FACIT, которая выпускалась с 1939 года. Вес 11 кг.

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

Назначение рычажков и клавиш.

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

Клавиши со стрелочками служат для ручного сдвига барабана на разряд влево, вправо и в крайнее левое положение (для операции деления). Эти клавиши аналогичны по назначению таким же у арифмометров Феликс и ВК-1.

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

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

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

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

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

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

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

Кому-то может показаться это немного непривычным из-за отсутствия кнопки =, но так было на всех машинах того времени. Более того, даже первые электронные калькуляторы повторяли приемы работы как на механических арифмометрах и на них тоже отсутствовала клавиша = (например, калькулятор Б3-24).

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

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

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

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

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

В отличие от умножения, деление на машине полностью автоматическое. Обнуляем счетчики результата и оборотов. Рычажок внизу ставим в правое положение, на установочном барабане набираем делимое. Если мы хотим получить максимум значащих разрядов после запятой, делимое надо записать в левую часть счетчика результата. Затем набираем на барабане делитель и тоже смещаем влево. Далее нажимаем кнопку и остальное машина сделает сама! Машина последовательно пробежится по всем разрядам и остановится. В счетчике результата мы увидим частное от деления. Да, тут тоже нужно правильно расставить запятые. Запятая у частного должна стоять на цифре, равной цифре делимого минус цифры делителя.

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

Небольшое видео с демонстрацией работы.

Что происходит на видео: вычисляем (758,36 + 44,20 - 356,99) * 125,74 / 14,01.

Сбрасываем счетчики, обнуляем барабан. Вводим число 758,36, прибавляем к нему 44,20, получаем промежуточный результат 802,56. Затем вычитаем из него 356,99 (промежуточный результат 445,57). Результат заново набираем на барабане, сбрасываем счетчики и умножаем его на 125,74 в полуавтоматическом режиме. Корректируем результат, получаем 56025,9718. Это число заново набираем на барабане, переносим в левую часть и делим на 14,01. Получаем окончательный результат 3998,9987.

Вопросы и замечания прошу писать в комментариях.

Подробнее..

IBM PCAT

05.01.2021 16:09:52 | Автор: admin

Представляю вам очередной обзор ретро ЭВМ на этот раз клона компьютера IBM PC AT, он же 286, он же "двойка" . Несмотря на то, что это клон, он почти один-в-один, вплоть до расположения микросхем на печатной плате, повторяет оригинальный IBM 5170.

IBM PC/AT (cокращение от Advanced Technology ) относится к 3 поколению семейства компьютеров IBM PC (после, собственно, IBM PC и IBM PC/XT). Именно компьютеры этого поколения можно назвать прародителями всех современных компьютеров семейства х86, поскольку именно в этом поколении появились большое количество нововведений и фич, которые сохраняются для совместимости и поныне. Конечно, многие эти фичи со временем превратились в палки, мешающие дальнейшему развитию системы, для их обхода придуманы многочисленные костыли. Есть мнение, что система х86 до сих пор держит пальму первенства по количеству атавизмов, заплат и костылей, наделанных с момента появления первого IBM PC/AT.

Первые IBM PC/AT были выпущены в 1984 г. Мой экземпляр, судя по датам на микросхемах примерно 1988 г. выпуска. Начали его делать в 1986 году. На это указывают даты БИОСа и копирайты.

Что же было введено нового в этом компьютере по сравнению с предыдущими моделями?

Прежде всего, это применение самого современного на тот момент процессора 80286. Процессор позволял адресовать 16 Мб оперативной памяти по 16-разрядной шине данных и работал на частоте 6 или 8 МГц.

По сравнению с IBM PC/XT это существенный шаг вперед, обеспечивающий в 3-6 раз большую производительность. Также этот процессор поддерживал защищенный режим и многозадачность, но она была реализована не очень удачно и была несовместима с ранее разработанными программами для х86. Поэтому многозадачные ОС использовались на IBM PC/AT очень ограниченно, в основном там безраздельно властвовал DOS.

16-разрядная шина данных потянула за собой новую шину AT-bus (ISA 16 бит). Эта шина была механически совместимой и со старой 8-битной шиной что сделало ее достаточно популярной. Настолько, что она продержалась почти 20 лет и исчезла с материнских плат компьютеров лишь в начале 2000-х годов. Эта шина также широко использовалась (и до сих пор используется) во встраиваемых системах, где она известна как шина РС/104.

Эта шина также дала жизнь популярному параллельному интерфейсу подключения жестких дисков IDE. Спецификация ATA (AT attachment) по сути является лишь буферизированной шиной АТ. Этот интерфейс продержался еще дольше и исчез с материнских плат только в 2010-х.

На плате IBM PC/AT появилась микросхема CMOS-памяти, в которой хранились настройки BIOS Setup. Теперь конфигурировать аппаратные средства можно было программно, а не перемычками на плате. Эта память питалась от маломощной батарейки. Эта же батарейка питала и часы реального времени, наличие которых начиная с этой модели стало стандартом. Теперь не надо каждый раз при старте компьютера вручную вводить дату и время.

Кстати, один очень интересный нюанс: в этом клоне, как и в оригинальной машине IBM PC/AT нет встроенной в ПЗУ программы BIOS Setup. При старте компьютера сколько не нажимай DEL, F2 и прочие комбинации, ничего не произойдет. Я поначалу не знал этого нюанса и меня это очень озадачивало. Специальную программу для конфигурации BIOS'а нужно запускать с диска как и любую другую программу для DOS. Оригинальную, конкретно для этой платы, конечно же найти не удалось, но благодаря высокой степени стандартизации расположения данных в микросхеме CMOS, подойдет и любая другая. Вот как она примерно выглядит.

Отсутствие встроенного BIOS Setupа встретилось мне еще в одном клоне IBM PC/AT, даже еще более "современном". А так, практически во всех 286 клонах программа BIOS Setup уже была зашита в ПЗУ BIOSa и вызывалась привычным всем нам образом - нажатием клавиши DEL. Даже более того, на некоторых платах 286 в ПЗУ была зашита программа тестирования железа, такой простенький аналог Check Itа. На 386 такого уже не было. Но зато на некоторых 486 появился модный графический (!) BIOS Setup с окошками а-ля Windows 3.0!

Также с новым компьютером появилась и новая клавиатура, несовместимая с IBM PC/XT. Раскладка этой клавиатуры стала стандартом де-факто и используется и поныне. Также высок уровень ее аппаратной совместимости. АТ - клавиатуру 1986 года выпуска можно подключить к современному компу через переходник DIN-PS/2, и через обратный переходник можно подключить относительно современную PS/2 клавиатуру к старому IBM PC/AT. И на удивление все будет работать.

В новой модели стали доступны дисководы 5" с емкостью 1,2 Мбайт (на ХТ и ранее поддерживались обычно дискеты не более 720 Кб), а со временем и дисководы 3". В моей модели стоят 2 шт MD 5201 фирмы Canon, емкостью по 360 КБ (исключительно ради исторического соответствия, можно без проблем поменять на 1,2 Мб, и на 3-дюймовые). Обычно в моделях тех лет ставили 2 разных дисковода. Один умел работать со 180 КБ, 360 КБ, 720 КБ, второй с 1,2 Мб. Потому как дискеты для тех и других достаточно сильно несовместимы. Различие связано с коэрцитивной силой магнитного слоя, у дискеты на 1,2 Мб она в 2 раза выше.

Перечень видеоадаптеров для этой модели поражает воображение можно было поставить любой, MDA, CGA, EGA и даже, появившийся позднее VGA. И все будет работать! В моем ПК стоит видеоадаптер PGA или PGC (Professional Graphics Adapter или Professional Graphics Controller) фирмы ORCHID.

Данный контроллер позволяет выводить 256 цветов на экран разрешением 640х480 (как у появившегося намного позднее VGA). Это очень интересный адаптер, даже по одному его виду можно понять что стоил он в свое время баснословных денег. Огромная плата, под завязку забитая микросхемами и заправляет там всем процессор 80186.

Это тот самый процессор, промежуточное звено между 8086 процессором и 80286. Этот процессор никогда не ставился в персональные компьютеры, а применялся в основном, во встраиваемых системах. Вот и здесь он рулит выводом картинки на экран. Еще один интересный момент: этот видеоадаптер, по сути состоит из двух видеоадаптеров: EGA и PGA.

Нашлепка вторым этажом обычная видеокарта EGA, ее контакты непосредственно выходят на шину ISA. Видеосигналы с этой платы выходят на выходные разъемы через контакты реле на основной плате. Таким образом, компьютер стартует и начинает работать как бы с видеоадаптером EGA, но когда драйвер PGA дает команду своему адаптеру включится, тот с помощью реле отключает адаптер EGA от монитора и подключает вместо него себя.

Для работы с таким хитрым адаптером, конечно же необходим специальный монитор, который должен как поддерживать эти режимы, так и быть совместимым по уровням сигналов. В отличие от видеоадаптеров CGA и EGA, где выходные уровни сигналов цифровые ТТЛ (0 В или 5 В), уровни сигналов RGB этого видеоадаптера аналоговые амплитудой 1 В (как, например, аналоговые сигналы RGB в видеокартах VGA или как аналоговые сигналы RGB в большинстве отечественных ПК). В настоящее время найти монитор CGA или EGA уже существенная проблема, не говоря уж о таком, весьма специфическом мониторе.

Поэтому для этого компьютера я решил взять обычный монитор VGA или SVGA и немного его доработать, сделать возможным его работу на пониженной частоте строчной развертки. Мне попался под руку монитор неизвестной фирмы TYSTAR. Вообще, для такой доработки подойдет любой монитор с аналоговыми регулировками. Процесс доработки я насколько это возможно подробно расписал на сайте zx-pk.ru (http://personeltest.ru/aways/zx-pk.ru/threads/29452-peredelka-vga-na-15-kgts-dubl-2.html). Вкратце, доработка сводится к понижению напряжения питания строчной развертки тем или иным способом, понижению частоты строчной развертки и коррекции геометрических искажений, возникающих при снижении частоты.

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

Порты COM, GAME и LPT обеспечиваются отдельным контроллером.

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

На шине ISA сидит MFM-контроллер КТ-102, контроллер ничем не примечательный, работает совместно с широко распространенным жестким диском MFM типа ST-225 фирмы Seagate емкостью аж целых 20 Мб.

На контроллер даже сохранился бумажный мануал!

На материнской плате в панельках набраны 640 кБ ОЗУ (тех, которых должно хватать каждому).

Рядом стоят панельки для ПЗУ, их четыре, заняты две (вероятно, старший и младший байты 16-разрядного слова). Под небольшим радиатором в панельке стоит процессор в керамическом корпусе, рядом математический сопроцессор 80287.

Все остальное пространство материнской платы плотно забито микросхемами малой и средней степени интеграции. Специализированного чипсета на материнке нет, все собрано на рассыпухе. Материнская плата формата АТ, а точнее full AT. Она значительно больше как по длине, так и по ширине. Не во всякий АТ корпус она залезет. Как правило, значительная часть АТ корпусов допускает установку плат формата baby AT и меньше (micro AT и пр.).

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

В шину АТ также втыкается интересная штуковина плата расширения оперативной памяти. Она нужна для тех, кому уже не хватает 640 кБ ОЗУ. Поскольку на шину АТ отображаются все проводники адреса и данных, прямо в слот можно воткнуть дополнительную память.

Такой фокус возможен на самых первых материнках, с простой логикой на рассыпухе. На более поздних, собранных на чипсете, такой фокус может и не пройти. На дополнительной плате смонтирован свой собственный контроллер динамического ОЗУ и 5 банков памяти по 512 кБ, всего 2,5 Мб дополнительной памяти. Интересная особенность платы дополнительных банков памяти 5 шт, число нечетное и не степень двойки. Описание на эту плату я найти не смог, даже на сайте th99. Причем, все подобные платы имеют, по крайней мере, четное число банков памяти - 2, 4 или 6. С пятью банками нет вообще ни одной.

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

Попробуем теперь запустить компьютер. При старте кратковременно высвечивается строка с версией BIOS EGA видеоадаптера.

Потом появляются сообщения БИОСа материнской платы, начинается тест памяти.

Если с жестким диском все ок, он размечен, отформатирован и правильно прописан, с него начинает грузиться MS DOS.

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

Как видно из тестов, данный компьютер всего в 3 с копейками раза быстрее исходного IBM PC, в 23 раз быстрее его по математическим операциям и в 2 с лишним раза быстрее по видеоподсистеме. И по ощущениям тормозит лишь ненамного меньше чем ХТ-шки. Ну, а действительно, что еще ждать от процессора с частотой 6 МГц.

Но это уже 286! В него можно воткнуть видеокарту VGA и запускать значительно большее количество игрушек и различных программ. Например, вот как выглядит игра Block Out на EGA.

Вот и все что я хотел рассказать об этом экспонате. Предложения и замечания прошу писать в комментариях.

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru