Linux Foundation регулярно запускает инициативы по развитию дата-центров и сетевых технологий провайдеров. Одна из последних — Open Programmable Infrastructure (OPI) — направлена на разработку стандартов для «умных сетевых адаптеров» (SmartNIC). Обсудим, какие задачи будут решать участники этого проекта.

Какие проблемы будут решать

Термином SmartNIC называют умные сетевые адаптеры. Еще их обозначают как DPU или IPU — в индустрии нет устоявшегося мнения по этому поводу. Задача устройства — разгрузить центральный процессор сервера или СХД. Оно берет на себя обработку трафика, протоколов и даже отдельных вычислений в приложениях. Но на сегодняшний день с устройствами такого класса связаны две ключевые проблемы.

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

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

Так, в рамках Open Programmable Infrastructure (OPI) инженеры создадут набор открытых фреймворков и API, которые стандартизируют подходы к работе с умными адаптерами. К инициативе уже подключились крупные производители сетевого аппаратного обеспечения и графических карт и облачные провайдеры.

Есть ли перспективы

Ряд организаций уже занимается развитием open source технологий, связанных со SmartNIC. Американская Netronome выложила в свободный доступ прошивку для сетевых адаптеров, способных запускать BPF-программы. О том, что это такое, рассказывал пользователь Хабра. Разработчики Ubuntu вносят изменения в OVN и OpenStack, чтобы упростить их интеграцию с DPU. Собственные сетевые адаптеры разрабатывают и китайские облачные провайдеры. Они называют их CIPU, добавляя больше неопределенности в и без того широкий спектр наименований технологии.

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

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

Дополнительное чтение в блоге VAS Experts: 

• Гибридное шифрование с открытым ключом — теперь в формате RFC

• Торрент-трафик растет: наши наблюдения

• CG-NAT — зачем нужен и как начать пользоваться

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

Был еще вариант китайских усилителей класса D: обещана огромная мощность, околонулевые искажения и компактный корпус. И при всем при этом цена на уровне нескольких тысяч рублей! В отзывах сплошь похвала и одобрение. В результате купил усилитель фирмы S.M.S.L. На следующий день сдал обратно в магазин: казалось, что слушаешь скрежет стекла. Короче, звук был очень неприятным.

Тогда и возникла идея самосбора. Схема должна была быть простой в сборке и настройке, широко распространенной, не требовать дорого оборудования и редких деталей, а также обеспечивать хорошее качество звука в небольшой комнате. В качестве такой схемы остановился на широко известном классическом усилителе Джона Линсли-Худа от 1969 года (он же «JLH 1969»). На самом деле схем, удовлетворяющих заданным критериям, множество, и у каждой свои приверженцы, свои плюсы и минусы. Основные минусы JLH: требовательность к компонентам, постоянное высокое потребление электроэнергии и, как следствие, сильный нагрев, невысокая выходная мощность (раскачать более 10 ватт на канал надо очень постараться). Указанные недостатки меня не смутили и я начал изучать теорию. Вот примерный список:

• На что способен китайский усилитель А-класса JLH 1969?

• Простой усилитель класса А

• Всё об усилителе JLH

За 20-30 долларов на Али продаются готовые комплекты для сборки (плата + детали россыпью), но так как хороший звук будет только при хороших деталях, имеет смысл заказывать там только печатные платы, а детали добывать в местах, вызывающих больше доверия. Я заказал две платы (правый и левый каналы для симметричного расположения в корпусе).

Пока ждал платы, спроектировал корпус из фанеры под размеры ниши. Фанеру 10 мм купил и раскроил в Леруа, отобрал куски без сучков. Боковыми стенками корпуса должны были служить солидные алюминиевые радиаторы типа АВМ-053-150 (123×38х150 мм), по две штуки на правую и левую стенку.

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

В сравнении с предлагаемой схемой, увеличены емкости конденсаторов, а транзисторы заменены на те, которые удалось достать. Маломощные транзисторы подбирались по коэффициенту усиления на выдаче в магазине (за что большое спасибо сотрудникам), получилось подобрать транзисторы 2N2907A с коэффициентом усиления порядка 170 и около 200 для 2N1711. Мощными выходными транзисторами TESLA KD 3055 (1980 г. выпуска) поделился товарищ, у которого они были из источника, не подлежащего разглашению. Среди них удалось отобрать две пары с коэффициентами усиления 55/57 и 67/68. Для схемы очень важна идентичность параметров транзисторов выходного каскада, потому один из каналов получается чуть громче, но это несложно скомпенсировать при дальнейшей настройке. Более того, просто перемещение головы слушателя приводит к гораздо большему перепаду воспринимаемой громкости, чем такая разница коэффициентов усиления выходных пар транзисторов.

Несмотря на то, что транзисторы TESLA заведомо оригинальные, с некоторых из них при мойке спиртом начисто стерлась маркировка. Хорошо, что успел заранее пронумеровать маркером. Маркер спиртом не смылся.

Для измерения коэффициента усиления мощных транзисторов собрал вот такую схему с двумя амперметрами и питанием от двух батареек АА (2 х 1.5 вольта):

Очень удобно подобрать ток базы равным 1 мА, в этом случае показания второго амперметра покажут коэффициент усиления. В показанной на рисунке схеме он равен 60. Кстати, все схемы, которые требовали моделирования, проверял через Falstad Circuit Simulator, скриншот из него. Рекомендую.

Мелочевку на плату тоже старался подбирать качественную: конденсаторы EPCOS и Panasonic, подстроечные резисторы Bourns, маломощные сопротивления не 0.125 Вт, а на 0.25 Вт.

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

Трансформатор использован тороидальный,18 вольт, 6 ампер, с одной вторичной обмоткой. Фильтрующие конденсаторы EPCOS на 35 вольт, 22 тыс. мкФ, включены в две группы по две штуки. Сопротивление — цементное, на 20 ватт, 0.44 Ома. Выпрямитель — диодный мост на 50 ампер 100 вольт, установлен на теплоотводе. Можно использовать радиатор от старого процессора типа 486 и т.п. Можно купить выпрямитель подороже, с меньшим падением напряжения на диодах, и он будет греться меньше.

Результирующее напряжение на выходе блока питания на холостом ходу — 26 вольт. Под нагрузкой снижается до 22 вольт.

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

По прибытии плат занялся монтажом схемы. Вот как выглядела собранная плата одного из каналов:

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

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

Далее поженили плату и радиатор. Вот так выглядит собранный усилитель одного канала

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

В итоге все было расположено в корпусе (прошу прощения за топорный дизайн а-ля дикобраз из Икеи)

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

В целом проект напомнил то, как было принято собирать схемы радиолюбителями в СССР, кому это нравится, рекомендую к повторению.

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

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

Итак поехали…

Загрузка датасета

На сайте https://data.gov.ru/ находим и скачиваем датасет Объекты культурного наследия на территории Санкт-Петербурга. Последнее обновление датировано 2016 годом, но для объектов возрастом в пару веков это не будет проблемой.

Давайте оценим количество данных, с которыми будем работать:

import pandas data = pandas.read_csv('spb_memo.csv') print('Количество строк:', len(data))

Количество строк: 9275

Ого, более девяти тысяч объектов культурного наследия! Недаром наш город называют культурной столицей России. Что есть внутри?

data.head()

Выборка по районам

У нас есть названия объектов, даты постройки, адреса и даже имена авторов, отлично!

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

districts = list(data['district']) districts_unique = list(set(districts)) total_per_district = []  for district in set(districts):     district_counter = 0     for index in range(len(districts)):         if districts[index] == district:             district_counter += 1     total_per_district.append(district_counter)  seaborn.barplot(x=total_per_district, y=districts_unique)

Никаких сюрпризов. Большинство памятников архитектуры располагаются в Центральном, Петродворцовом и Адмиралтейских районах города. Это самый что ни на есть центр. На периферии объектов значительно меньше, за исключением Пушкинского района. Но вряд ли за свои короткие выходные друг поедет так далеко, хотя и много потеряет. Как бы там ни было, вычёркиваем Пушкинский район, а также другие районы, находящиеся за КАДом.

outside_districts = ['Пушкинский', 'Кронштадтский', 'Кронштадт',      'Колпинский', 'Курортный', 'Приморский', 'Санкт-Петербург'] districts_unique = [item for item in districts_unique      if item not in outside_districts ]  for district in districts_unique:     district_counter = 0     for index in range(len(districts)):         if districts[index] == district:             district_counter += 1     total_per_district.append(district_counter)  seaborn.barplot(x=total_per_district, y=districts_unique)

Проверка других столбцов

Что ж, круг сужается, двигаемся дальше. В датасете есть такая характеристика объектов, как протекционная категория. Будет ли нам полезна эта колонка?

protection_categories = list(data['protection_category']) protection_categories_unique = list(set(protection_categories)) total_per_category = []  for category in set(protection_categories):     category_counter = 0     for index in range(len(districts)):         if protection_categories[index] == category:             category_counter += 1     total_per_category.append(category_counter)      seaborn.barplot(x=total_per_category, y=protection_categories_unique) 

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

Выборка по авторам

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

authors_all = list(data['author']) authors = [] total_per_author = []      for author_line in authors_all:     if author_line == author_line:         if ',' in author_line:             for author in author_line.replace(';', ',').replace('арх. ', '').replace('худ. ', '').replace('гражд.инж. ', '').replace('архитекторы ', '').replace('фонтанный мастер ', '').replace('арх-ры ', '').split(','):                 author = author.strip()                 if author not in authors:                     authors.append(author.strip())                     total_per_author.append(1)                 else:                     index = authors.index(author.strip())                     total_per_author[index] += 1         else:             if author not in authors:                 authors.append(author.strip())                  authors_df = pandas.DataFrame(authors, columns=['name']) authors_df['count'] = total_per_author  seaborn.barplot(x=authors_df['count'],                  y=authors_df['name']) 

Этот график совсем не выглядит информативным. Чисто для целей визуализации предлагаю посмотреть тех авторов, которые построили более 20 объектов. Меняем последние строчки кода на:

most_frequent_authors_df = authors_df.loc[(authors_df['count'] > 20)]      seaborn.barplot(x=most_frequent_authors_df['count'],                  y=most_frequent_authors_df['name'])

Чем дальше, тем интересней! И кто же этот Г.А. Симонов, который судя по статистике отстроил чуть ли не половину города, а в честь него даже ни одной улицы не назвали? Заглянем в Википедию:

Григорий Александрович Симонов (23 января 1893, Ташкент — 31 января 1974, Москва) — советский архитектор, инженер, педагог.
Г. А. Симонов родился в Ташкенте. Детство провел в Троицке, там окончил гимназию.
Окончил Петроградский Институт гражданских инженеров в 1920 году, где преподавал с 1929 года.
В 1919—1922 гг. обучался в Академии Художеств.
С 1924 года руководил Проектным Бюро Стройкома.
С 1943 года — заместитель председателя Государственного Комитета по делам архитектуры при Совете Народных Комиссаров СССР.
С 1947 по 1949 год — председатель Комитета по делам архитектуры при Совмине СССР.
С 1955 года — преподаватель Московского архитектурно-строительного института.

Теперь понятно, это послереволюционный, советский архитектор, руководивший сооружением множества объектов в тогдашнем Ленинграде. Если отставить личность товарища Симонова в покое, что еще мы здесь видим? Имеет место выброс статистических данных — Симонов упоминается так часто, что затмевает других. К тому же друг попросил старинные памятники архитектуры. Так что, ни в коем случае не умаляя творцов последнего века, давайте исключим из выборки все сооружения старше 1900 года. Правда тут есть небольшая проблема…

В нашем датасете столбец с датами — текстовый, произвольной длинны и содержания. Где-то стоит одна дата, где-то период, где-то просто двухзначная цифра века постройки. В данном случае мы не можем сделать числовую выборку, а можем работать только со строками. Если бы точность была важна, можно было бы преобразовать этот столбец, как мы сделали с авторами, можно было бы отбирать строки регулярными выражениями. Но это всего лишь поездка друга, так что решаем не усложнять, и волевым решением отсекаем все даты, где встречается число 19. Мы упустим несколько построек, где в поле дата указано «конец 19 в.», «1819» и тому подобных. Примем это как допустимые потери.

districts_authors_df = pandas.DataFrame(districts_unique, columns=['district']) lat = [] lon = []  for col in most_frequent_authors_df['name']:     districts_authors_df[col] = 0      districts_authors_df.set_index('district', inplace=True)  top_poi = []  for district in districts_unique:     district_df = data.loc[(data['district'] == district) & (~data["date"].str.contains('19', na=True))]     for index, row in district_df.iterrows():         for author in most_frequent_authors_df['name']:             if row['author'] == row['author'] and author in row['author']:                 districts_authors_df[author][district] += 1                 top_poi.append(row['number'])  districts_authors_df.drop('автор не установлен', axis=1, inplace=True) #districts_authors_df = districts_authors_df.loc[(districts_authors_df>5).any(axis=1)] #!=0  seaborn.heatmap(districts_authors_df, xticklabels=True, yticklabels=True) #, annot=True

Ситуация проясняется. У нас теперь есть список наиболее интересных для нашей задачи районов и авторов. Переменная top_poi (Top Points of Interests) содержит номера наших призеров. Но где именно находятся объекты? Пришло время для геокодирования…

Геокодирование

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

Для начала сделаем копию нашего датасета и добавим туда два новых поля: долгота и широта:

df = pandas.read_csv('spb_memo.csv') df['lat'] = float('nan') df['lon'] = float('nan') df.to_csv("spb_memo_geo.csv", index=False)

У геокодера Яндекса бесплатно только 1000 запросов в сутки. В нашей переменной top_poi содержится чуть меньше 500 объектов, так что на это исследование у нас сегодня хватает:

df = pandas.read_csv('spb_memo_geo.csv') from decimal import Decimal import os from dotenv import load_dotenv from yandex_geocoder import Client  load_dotenv('.env') yandex_geo_api_key = os.environ.get("yaGeoApi") client = Client(yandex_geo_api_key)  coordinates = 0 api_limit_per_day = 1000  for poi in top_poi:     if api_limit_per_day > 0:         poi_row = df.loc[(df['number'] == poi)]         if poi_row.empty:             lat = float('nan')         else:             lat = list(poi_row['lat'])[0]         addr = list(poi_row['address'])         if lat != lat and len(addr) > 0 and addr[0] == addr[0] and len(addr[0]) > 5:             coords = client.coordinates("Санкт-Петербург, " + addr[0])             df.loc[poi_row.index, 'lon'], df.loc[poi_row.index, 'lat'] = coords             api_limit_per_day -= 1  df.to_csv("spb_memo_geo.csv", index=False)

Последний отсев

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

df = pandas.read_csv('spb_memo_geo.csv') lat_lon = df[df['number'].isin(top_poi)] x = list(lat_lon['lat']) y = list(lat_lon['lon'])  seaborn.scatterplot(x=x, y=y, c=['red'])

Вы будете правы, если скажите, что такое расположение точек не соответствует сторонам света — по X должна быть долгота, а по Y — широта. Но на данном этапе нам это и не нужно. Мы ищем зависимости, отклонения, совпадения и т.д.

И что это за одинокая точка в левом верхнем углу, из-за которой у нас верхняя половина графика пустая?

print(df.loc[(df['lat'] < 59.8) & (df['lon'] > 31)])

7922    Летний сад Name: name, dtype: object

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

lat_lon = df.loc[df['number'].isin(top_poi) & (df['lat'] > 59.6) &                   (df['lat'] < 62) & (df['lon'] > 29) & (df['lon'] < 30.8)] x = list(lat_lon['lat']) y = list(lat_lon['lon'])  seaborn.scatterplot(x=x, y=y, c=['red'])

Итог

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

xy_center = (sum(x) / len(x), sum(y) / len(x))  seaborn.scatterplot(x=y, y=x, c=['red']) seaborn.scatterplot(x=[xy_center[1]], y=[xy_center[0]], c=['green'])

Зеленая точка и есть наше заветное место. Интересно, а где это вообще?

print(xy_center[1], ',', xy_center[0])

59.926768, 30.294057

Снова прибегнем к геокодеру Яндекса, но на этот раз в обратном направлении — для преобразования координат обратно в адрес:

address = client.address(Decimal("30.294057"), Decimal("59.926768")) print(address)

Россия, Санкт-Петербург, набережная Крюкова канала

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

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

Финальная визуализация

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

Напоследок, давайте сделаем все красиво, и действительно сопоставим наши данные с реальной картой, используя библиотеку OSMnx, основанную на данных OpenStreetMap (спасибо Carlos Lannister за подсказку):

import osmnx as ox  # Center of map latitude = 59.939099 longitude = 30.315877  point = (latitude, longitude) G = ox.graph_from_point(point, dist=10000, retain_all=True, simplify = True,                          network_type='all')  u = [] v = [] key = [] data = [] for uu, vv, kkey, ddata in G.edges(keys=True, data=True):     u.append(uu)     v.append(vv)     key.append(kkey)     data.append(ddata)      # List to store colors roadColors = [] roadWidths = []  for item in data:     if "length" in item.keys():         if item["length"] <= 100:             linewidth = 0.10             color = "#a6a6a6"                       elif item["length"] > 100 and item["length"] <= 200:             linewidth = 0.15             color = "#676767"                      elif item["length"] > 200 and item["length"] <= 400:             linewidth = 0.25             color = "#454545"                      elif item["length"] > 400 and item["length"] <= 800:             color = "#d5d5d5"             linewidth = 0.35         else:             color = "#ededed"             linewidth = 0.45     else:         color = "#a6a6a6"         linewidth = 0.10                  roadColors.append(color)     roadWidths.append(linewidth)              bgcolor = "#061529"  fig, ax = ox.plot_graph(G, node_size=0,figsize=(27, 40),                          dpi = 300,bgcolor = bgcolor,                         save = False, edge_color=roadColors,                         edge_linewidth=roadWidths, edge_alpha=1,                         show=False, close=False)  for i in range(len(x)): #     ax.scatter(y[i], x[i], s = 100, c='red')  ax.scatter(xy_center[1], xy_center[0], s = 100, c='green') 

Как видно из кода, красные точки — это объекты культурного наследия Санк-Петербурга (в данном случае порядка 1 300 объектов, без ограничения по годам), а зеленая точка — рекомендованное место старта.

Если захотите проверить мои расчёты, можете найти все файлы в моём репозитории Github.

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

Моя история программирования: как всё начиналось

Я обожаю кодинг. Писать на BASIC я начал еще в 11 лет. Дело в том, что я принадлежу к удачливому поколению — именно мы одними из первых начали пользоваться ПК не выходя из дома. Первый опыт с BASIC я получил на компьютере Epson HX-20. А это, на минуточку, один из первых портативных компьютеров в мире! До сих пор я жалею, что продал этот замечательный образчик компьютерной истории, когда учился в колледже.

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

Моя история

Сейчас мне 51 год, и спустя 40 лет практики на более чем 20 различных языках я рад признаться, что до сих пор сижу на этом «крючке». 

Последние лет двадцать я с удовольствием рассказываю детям от 15 до 100 лет о моей карьере и любви к программированию. И неизменно подчеркиваю, что «буду продолжать кодить до тех пор, пока кто-то не оторвет мои холодные мертвые пальцы от клавиатуры». Наверное, это звучит немного… нездорово, зато четко передает суть. Программирование — это моя страсть, и мне повезло, что мне платят за то, что я занимаюсь любимым делом. К тому же за эти 20 лет я осознал, что, помимо написания кода, я чертовски люблю учить людей программировать.

У хороших историй есть герои

Лучший способ предсказать будущее — это придумать его. © Алан Кей, 1971 год.

На фото выше — ноутбук XO, который я купил во время благотворительной акции One Laptop Per Child Give One Get One в 2007 году. Программа, запущенная на экране, — Squeak eToys. А Алан Кэй — автор проекта eToys, построенного на базе Squeak Smalltalk.

Мне посчастливилось познакомиться с Аланом Кеем, когда я работал в Goldman Sachs, — его пригласили выступить на Talks at GS Panel. Очень здорово, что я могу в любой момент посмотреть запись его выступления и заново пережить те же чувства. Если вы не знаете, кто такой Алан Кей, или просто не видели это выступление, то по ссылке выше вы можете посмотреть, как Алан рассказывает часть своей истории. Алан Кей был так добр, что подписал мой ноутбук XO как раз в день этого выступления — 26 февраля 2015 года.

В хороших историях зачастую есть «Герои». Алан Кей — один из моих компьютерных героев. В 11 лет я понятия не имел, кто это такой. Более того, я познакомился с его работами уже после колледжа, когда мне было далеко за 20. Иногда я думаю, что мне было суждено найти своего героя, измениться под впечатлением от его личности — и в конце концов познакомиться с ним в реальности.

1980-е

В середине-конце 80-х я освоил кучу языков программирования, таких как BASIC, FORTRAN, COBOL, Pascal, Logo, Prolog, Dbase III+ и Clipper ’87. Я самостоятельно изучил Dbase III+ и сразу после окончания школы на полставки устроился консультантом по Clipper Summer ’87. Это помогло мне подкопить денег и оплатить обучение в университете Rutgers Newark/NJIT.

1990-е

Окончив университет, я устроился на должность программиста в отдел рейтингов и андеррайтинга компании Blue Cross Blue Shield of New Jersey (BCBSNJ). Я начал программировать в Clipper 5.x, а позднее освоил Windows-версию Clipper, которая называлась CA-Visual Objects. Мне довелось поработать в DOS, Windows 3.1, OS/2, а затем и в Windows 95/NT.

В середине 90-х годов BCBSNJ передала свой ИТ-отдел на аутсорсинг компании Integrated System Solutions Corporation (ISSC), которая позже превратилась в IBM Global Services. Я в одночасье стал сотрудником IBM. Сначала это немного пугало, но оказалось, что это отличная карьерная возможность. Работа в IBM привела меня на путь изучения самого важного языка программирования в моей карьере. Именно на этом пути я открыл для себя, кто такой Алан Кей, и узнал, какое влияние он оказал на современные вычисления.

В октябре 1994 года я посетил пятинедельную программу практического погружения в объектно-ориентированное программирование на Smalltalk. С этой программы начинался курс Университета объектных технологий IBM. Пять недель я провел в Атланте, изучая ООП и паттерны проектирования с помощью VisualAge Smalltalk от IBM. Занятия проходили каждый день и длились по 6-8 часов, а преподавали нам потрясающие отраслевые эксперты в области ООП и Smalltalk, такие как Гика ван Эмде Боас. Остальные 4-6 часов, остававшиеся в сутках, я тратил на кодинг и изучение VisualAge Smalltalk в лаборатории. Кроме того, в эти пять недель я прочитал свою первую книгу по объектно-ориентированному проектированию, написанную Ребеккой Вирфс-Брок. Ребекка Вирфс-Брок — еще один из моих «героев» от мира программирования. Я считаю себя счастливым обладателем подписанных копий обеих ее книг по ООП.

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

Вернувшись на работу, я решил во что бы то ни стало найти проект, который я мог бы построить, используя IBM VisualAge Smalltalk. А пока что продолжил создавать приложения на CA-Visual Objects. Теперь я мог применить новые навыки программирования и проектирования на этом объектно-ориентированном языке. Я был заряжен энергией и хотел поделиться этой энергией с другими. Поэтому я агитировал за отправку на пятинедельную программу погружения в Smalltalk как можно больше своих коллег. Примерно через год вместе с двумя другими разработчиками, которые прошли программу погружения в Smalltalk, я начал работать над проектом по созданию системы Medicare Enrollment. В помощь нам удалось привлечь экспертов-наставников из группы IBM Rapid Solutions. Это был огромный и познавательный опыт.

Затем я занялся перепроектированием и повторной реализацией всех систем корпоративного рейтинга и андеррайтинга, которые я ранее написал на Clipper, только теперь с использованием IBM VisualAge Smalltalk. Во время этой работы, которая длилась около трех лет, мы наняли эксперта-консультанта по Distributed Smalltalk. Именно от него я узнал, кто такие Алан Кей и Дэн Ингаллс. Дэн Ингаллс — еще один из моих программистов-героев, который написал потрясающую книгу под названием Design Principles Behind Smalltalk.

2000-е и наши дни

В 2000 году я решил оставить свой прекрасный путь разработчика на Smalltalk и переключиться на Visual Basic и более популярные в корпоративном секторе языки, такие как Java. Мой бывший наставник по Distributed Smalltalk посоветовал мне взяться за изучение Java и как можно скорее стать в нем экспертом — так я и поступил. Меня радовала открывающаяся перспектива, но было жаль прощаться с прошлым и уходить на Visual Basic и Java. Я променял летающую машину времени DeLorean на велосипед Schwinn и грузовик Ford. Велосипед выглядел новым и блестящим, но по большей части бесполезным для чего-либо, кроме тривиальных приложений. Грузовик позволял делать много тяжелой работы, но требовал немало бензина (сил разработчика).

В Goldman Sachs (GS) я пришел в 2001 году. Я начал с должности архитектора приложений, был повышен до CTO, год прожил в Лондоне, стал техническим директором по технологии контроллеров, был повышен до Tech Fellow, создал удивительно талантливую команду Core Platform Team, обеспечил развитие присутствия GS на GitHub и был повышен до управляющего директора. Подумать только, целых 13 лет моей жизни уместились всего в одном предложении! В GS я больше 15 лет программировал на Java и создал библиотеку, которая в 2012 году была опубликована под названием GS Collections, а в конце 2015 года стала Eclipse Collections.

Почему я написал Eclipse Collections? После пяти лет программирования на Java я устал повторять одни и те же шаблоны программирования снова и снова. Я понимал, чего не хватало в Java, потому что в эпоху работы со Smalltalk встретил немало крутых, продвинутых решений. В то время мне было сложно объяснить разработчикам, чего именно они лишены в Java. Поэтому я решил написать собственную реализацию некоторых функций, которых после Smalltalk мне остро не хватало в Java. За эти годы я обучил многих Java-разработчиков Smalltalk, ООП, OOAD, Lambdas, TDD, рефакторингу. Все это были вещи, которые я освоил на Smalltalk еще в 1990-х годах.

Восторг от программирования

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

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

Но это совершенно неправильный, ненормальный путь! Да, я и сам ненавидел писать на Java первые несколько лет, но я никогда не терял своей любви к программированию в целом. Мне не хватало любимых Smalltalk и Clipper, потому что с ними я мог работать гораздо продуктивнее и веселее! Несколько лет я работал в Java Specification Request (JSR) 335 Expert Group (EG) с такими экспертами отрасли, как Брайан Гетц, Даг Лиа, Дэн Хайдинга, Реми Форакс, Сэм Пуллара, Тим Пейерлс, Боб Ли, Кевин Буррильон, Андрей Бреслав, Влад Захаров и некоторыми другими людьми. Мы все хотели улучшить язык Java, внедрив в него лямбды, чтобы программирование на нем приносило гораздо больше пользы и удовольствия. Сейчас я могу оглянуться назад и сказать, что помог JSR 335 EG «изобрести будущее» для Java. Работа на Java с версии 8 стала гораздо интереснее и эффективнее. Но на свете еще так много безрадостных разработчиков. Возможно, они просто не знают, как себе помочь!

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

Делиться — значит заботиться

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

Недавно я выступил на Pittsburgh Java User Group. Моя речь называлась «Smalltalk или Java? Почему бы не то и другое!». На YouTube есть запись этого выступления. При желании вы можете посмотреть, как я вживую пишу код в Smalltalk IDE, чего я не делал уже очень давно. Это отличный пример того, как я делюсь своей радостью от программирования на Smalltalk и Java с другими людьми. Если у вас найдется время посмотреть его — заранее благодарен! Надеюсь, вам понравится!

После сорока лет кодинга я решил писать гораздо чаще. Я выполняю личную миссию: поделиться с людьми как можно большим количеством информации о Java, Eclipse Collections и Smalltalk. Сейчас в месяц я пишу 1-2 поста на Medium. В августе исполнится 5 лет с того момента, как я впервые публично взялся за перо. Я хочу внести свой вклад в то, чтобы сделать будущее лучше и сохранить радость программирования для будущих поколений.

Семь лет назад я получил замечательный подарок от одного из моих компьютерных героев — Алана Кея. Ноутбук XO, который он подписал для меня, — это то, чем я всегда буду дорожить. Алан тогда не мог знать, ведь он только что встретил меня, насколько пророческим оказался его автограф. Он написал: «Будущее будет лучше» Когда он это написал, моя жена готовилась к поездке в больницу для проведения трансплантации стволовых клеток. У меня не было иного выхода — только всей душой поверить в то, что Алан написал мне. Этот подписанный ноутбук буквально довел меня до слез, когда я принес его домой и рассказал жене эту историю. Алан преподнес нам в дар свой бесконечный оптимизм.

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

Одна из радостей, которую я познал в программировании на Java и которую не успел испытать в Smalltalk, — это радость от работы с большим и дружным сообществом. Сообщество Java просто невероятно. Я рад быть частью этого яркого сообщества. Вместе мы продолжим делать будущее лучше — для всех, кто работает с Java. Восторг от программирования обязан продолжаться!

Написать данный материал меня побудила статья «Нам он и нафиг не нужон, технический писатель ваш!» (с) или для чего он вам всё-таки нужен» (далее – Статья) и он является отчасти ответом на некоторые мысли, озвученные в ней, а также содержит информацию о моем видении работы технического писателя (далее – ТП). Поэтому также приглашаю автора Статьи @champ_7777777к прочтению.

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

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

Более 10 лет занимаюсь написанием всего и вся, а примеряться к этой деятельности стал намного раньше, еще во время учебы в университете. Львиная доля материалов относится к техническим и около техническим текстам, хотя грань между ними весьма размытая. Степень «техничности» текстов зависит от пожеланий заказчиков и конечно моей погруженности в тематику. Берусь только за задачи, где обладаю компетенциями или могу разобраться и выполнить работу в срок. Последние 5 лет занят в проектировании систем информационной безопасности. В своей работе большую часть времени занимаюсь тем, что собираю информацию, обрабатываю ее и разбираюсь, что написать и меньшую часть непосредственно пишу. Пожалуй, в этом главное отличие профессии ТП от других, связанных с написанием чего-либо – технический писатель – это больше про «технический», чем про «писатель». Это же является и критерием того, как понять, ТП или не ТП:).

Зачем нужен ТП?

В Статье сказано:

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

Компания в целом как раз очень хорошо понимает, для решения каких задач именно им нужен ТП. На разных уровнях по-разному, но понимают.

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

В Статье сказано:

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

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

Основная проблема

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

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

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

Тренировать удары

В Статье сказано:

«Однако, тут нужно любить «тренировать 10 тысяч раз один удар, а не 10 тысяч различных ударов», как говорил Брюс Ли. Полировать, оттачивать себя. Тогда придёт профессиональный успех.».

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

Ищу тебя

Здесь скажу про поиск ТП, чего автор Статьи коснулся в разделе «Основная боль».

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

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

Оформление

Из рассмотрено в Статье примера (раздел «Драма и проблематика») коснусь кириллицы в англицизмах.

В Статье сказано:

«Биг дата» — большая натяжка, «жира, гугл почта, иксолла» — совсем не то. Вы спросите, а как понять, как можно, а как нельзя? Честно, я и сам уже многие годы задаюсь вопросом, почему «USB» мы пишем так, а не «ЮСБ», а «СМС» допускается писать кириллицей.

Самый простой способ избежать ошибки – гуглить на предмет используемости.

Можно также использовать Reverso Context или Microsoft Language Portal — здесь можно найти перевод терминов в контексте. Как на русском, так и на английском. Просто можно брать самый употребляемый вариант того или иного термина.

В соответствии с ГОСТ 34.602-2020 техническое задание содержит раздел «Требования к документированию». Хорошим тоном считается указать в нем хотя бы минимальные требования к документации. Они в том числе включают то, что документация разрабатывается на русском языке. Допускается использованием в тексте общепринятых названий технологий, продуктов иностранного производства и т.п. на английском языке. Даже если у вас нет ТЗ по данному ГОСТу или его нет вообще настоятельно рекомендую придерживаться данного правила.

Только «USB» и не смотря на широко распространенное «СМС» – только «SMS». Позволю себе побыть занудой в данном случае. Из Википедии: SMS (сокр. от англ. Short Message Service – «служба коротких сообщений») – технология приёма и передачи коротких текстовых сообщений с помощью сотового телефона. Поэтому «SMS» в технических текстах не должно применяться в качестве синонима этих самых «коротких сообщений» (рука-лицо). Считаю допустимым: «SMS-сообщение». При этом изначально нужно ввести данное понятие, например, так: двухфакторная аутентификация осуществляется посредством ввода имени пользователя и пароля условно постоянного действия с последующим вводом одноразового кода, направляемого пользователю с использованием технологии приема и передачи коротких текстовых сообщений (далее – SMS-сообщения) на телефонный номер, указанный при регистрации. Кроме того, даже не смотря ввод понятия в тексте, оно вносится в список определений. После этого можно смело применять данное определение.

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

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

Заключение

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