Блог компании dataart

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

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

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

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

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

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

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

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

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

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

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

НПО Аврора

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Гордость

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

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

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

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

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

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

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

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

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

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

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

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

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

Директор DataArt Armenia Арсен Багдасарян 25 лет назад начинал системным администратором. Продолжил тестировщиком, дойдя до руководства QA-департаментом в армянском представительстве Synopsys, затем перешел в аутсорсинг. Вместе с Арсеном мы выбрали несколько историй из его жизни, которые иллюстрируют формирование рынка IT в постсоветской Армении.

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

Культ высшего образования и трудности выбора профессии

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

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

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

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

У отца сразу глаза загорелись он инженер, окончил политехнический институт: Я уже год ему говорю зачем медицинский, у нас в роду медиков нет. Как он потом работу найдет? А по инженерной линии поможем.

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

Отец отговаривал идти на вычислительную технику: пошла молва, что это конец света конкурс большой. Но в конце концов родители сдались: Флаг тебе в руки и барабан мучайся! Год я упорно занимался с замечательным репетитором, физику полюбил настолько, что забыл про двор, футбол,любые другие дела. Но примерно то же происходило со многими моими друзьями: со времен Советского Союза в Армении был культ высшего образования. Поступить в вуз стремились 90 % выпускников школ, к этому подталкивали и родители, даже если сами были рабочими.

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

Безмашинное образование и попытки заработать

Я учился с 1990 по 1995 гг., чтобы как-то прожить, ты должен был уметь вертеться. Все заводы позакрывались, начиная со второго курса чем я только не занимался. Был период, когда возили в Россию и Беларусь армянские сапоги: брали их на производстве, с мешками летели в разные города и там их продавали. Одно время даже работал в левом цеху по производству алкогольных напитков. Девальвация армянского драма тогда привела к тому, что стипендия у меня была 1 доллар.

Образование было безмашинное 34 компьютера на весь факультет. Когда мы изучали язык Фортран, писали в тетрадках, потом ходили в лабораторию группами по 56 человек. Кто-то вводил программу, дальше все вместе смотрели, что она делает. В общем с компьютером мы работали от силы раз в месяц.

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

Когда мы оканчивали 3-й курс, один знакомый приобрел компьютеры для своего офиса и попросил помочь их подключить. Мы с другом сказали, что посмотрим, пришли. Собрался народ, нас представили, как компьютерщиков: Сейчас они всё настроят. Мы попросили, чтобы нам не мешали, заказали кофе, сидим, рассматриваем технику. Монитор, клавиатура есть, а куда воткнуть провода? Смотрим: какие-то разъемы, что-то куда-то нужно совать. Важно не попортить, не туда вставишь короткое замыкание может быть. Минут 3040 трудились, оба были в поту. Потом включили, экран засветился, какие-то строчки пошли DOS.

Мы быстрым шагом дошли до парка, сели на скамейку и оба выдохнули: Не опозорились! После этого во мне что-то щелкнуло. Подумалось: Будет очень стыдно, если меня будут называть компьютерщиком, а я не смогу простой компьютер наладить. Надо было учиться. Но где найти такого специалиста, который мог бы рассказать, что такое операционная система, как работает железо? Первые IT-фирмы в Армении начали открываться только с 9596 года.

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

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

Как запустить IT-отдел с нуля

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

Начали с того, что такое компьютер, для чего нужна клавиатура, что такое монитор и системный блок. Дальше стали рассматривать операционную систему DOS, от нее перешли к Norton Commander. Потом к Windows. Через пару месяцев я был уверен, что меня возьмут на работу куда угодно. Но в основном нужны были программисты, а я больше по системам, по администрации.

В итоге я оказался в НИИ сейсмологии и сейсмостойкого строительства, где заместителем директора работал отец моего близкого друга. После разговора он дал мне ключи и отправил в сопровождении секретарши в компьютерный отдел. Под толстым слоем пыли там стояли два компьютера и матричный принтер. Я должен был прибраться, а потом в одиночку перевернуть работу института, оцифровав все что можно. Простая работа оператора ввести огромное количество бумажных документов в Word, построить таблички в Excel. Зарплата 2030 долларов. Но я все равно оставался ночами.

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

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

Стартап внутри вооруженных сил

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

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

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

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

За неделю мы оборудовали ВЦ, день и ночь готовились к инвентаризации, после которой дивизион признали лучшим в полку и вручили переходящее знамя. Все были счастливы, а ко мне потянулись офицеры из других дивизионов: У нас тоже паренек компьютер хочет принести. Я начал учить людей, а параллельно сам осваивал программирование на C++ по книжке в желтом переплете.

Первые банковские служащие без галстуков

В 1999 году я вернулся в Ереван, и друг предложил мне работу в своей новой фирме, подключавшей банки к общей сети Центрального банка Армении. Мы настроили сеть Сбербанка Армении, во всех 6070 отделениях поставили компьютеры, подключили к сети через модемы нормального интернета еще не было. До сих пор у меня в голове слышны звуки соединения. Обучение банковского персонала оказалось адской работы: в основном там работали немолодые женщины, которые раньше с компьютером не сталкивались. Одна из сотрудниц после каждого движения пыталась посмотреть, что же под ней.

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

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

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

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

Из банка в QA и аутсорс

Еще работая в банке, я заинтересовался новой специальностью тестировщика. К началу 2000-х в Ереване было около 20 IT-компаний, в одной из них HPL (Heuristic Physics Laboratories) работал мой тесть, который был системным программистом еще при СССР. Он порекомендовал меня начальнику отдела тестирования, предупредив, чтобы не брали, если не подойду. На собеседовании были какие-то логические задачки, потом мне предложили на полмесяца место стажера. Дней через 10 начальник отдела говорит: Я очень доволен твоей работой. Меня это еще больше вдохновило, я засиживался допоздна, готовил отчеты. В итоге проработал в HPL 5 лет, стал начальником отдела уже Quality Assurance. Потом пришла новость, что HPL покупает одна из самых передовых компаний в этой области Synopsys. Там я работал еще лет 15, то есть, почти 20 лет на одном месте, с одним коллективом. Уходить было трудно, но я решил двигаться дальше.

Где бы я ни работал, всегда дополнительно занимался чем-то интересным. В 2000-х в Армении не использовали слова аутсорсинг, у нас это называлась левая работа. Но на протяжении 1015 лет у меня была своя команда, мы дружили и делали много разных проектов. Работали под девизом нет ничего невозможного, правда, верили, что можем все. И заказчики нас любили.

После провала в 19901995 гг. началось активное развитие отрасли, с 2000-х пошел резкий рост. Сейчас по официальным данным в Армении около 700 больших и малых IT-компаний, это около 30 тысяч айтишников.

На этом фото Арсен Багдасрян принимает в офисе DataArt в Ереване важных гостей: Радика Ананяна и Рафаела Саргсяна.

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

Проект строится не столько вокруг самого железа и технических деталей разработки ЭВМ, сколько вокруг профессии эвмщика и отражения советской кибернетики в сознании современников. Авторы курса из Arzamas, как и команда IT-музея DataArt, верят, что это важно. На наш взгляд, в республиках Советского Союза и социалистических странах Восточной Европы во второй половине XX века сформировалась особая инженерная культура. Некоторые ее черты IT-специалисты могут и сейчас наблюдать в локальных профессиональных сообществах. Впрочем, эта идея пока остается гипотезой.

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

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

В заключение мы хотим предложить читателям Хабра небольшой опрос.

В мае 2020 года, когда процент коллег без проектов оказался неожиданно высоким, мы решили привлечь желающих к работе с опенсорс. У DataArt есть опыт создания собственных продуктов с открытым исходным кодом: IoT-платформа DeviceHive, .NET-фреймворк Atlas, игровая платформа Kiddo. Но контрибьютором сторонних проектов на уровне компании мы раньше не выступали, и сходу вкладывать в новую инициативу большие ресурсы не планировали. Скорее, хотели посмотреть, как это работает и для чего может пригодиться в будущем.

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

1. Опенсорс может работать на продвижение компании, но это дорого

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

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

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

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

2. Опенсорс не принесет мгновенного признания среди программистов

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

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

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

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

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

3. В крупнейших опенсорс-проектах всем хватит небольших задач

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

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

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

4. Подходящий репозиторий легко выбрать на глаз

Понятно, что отталкиваться проще всего от технологии. В нашем случае на момент высокого idle без проектов больше всего оказалось JavaScript-разработчиков, и первыми на наше предложение откликнулись двое из них. Дальше самое удобное просто взять топ-100 проектов с GitHub, отфильтровать их по нужной технологии и выбирать те, на которые отзывается ваше сердце. Внутри симпатичных вам проектов остается выбрать тикеты, отмеченные самими разработчиками как важные. И оценить хватит ли вам времени, чтобы наверняка справиться с описанной в них проблемой.

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

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

5. Порог для входа в опенсорс существует, но он очень низкий

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

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

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

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

6. В опенсорс есть чему поучиться

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

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

7. Не стоит спешить с обещаниями

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

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

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

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

Вместо заключения

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

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

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

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

Автор: Александр Монахов, Леонтий Онищук, Виталий Гнусин DevOps Engineers, DataArt, Анна Медведенко Project Manager, DataArt

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

1. Что такое Blueprints?

Blueprints сервис Azure Cloud, позволяющий в декларативном виде определять повторяемый набор ресурсов Azure Cloud, соответствующий стандартам и требованиям организации.

Blueprints позволяет разработчикам быстро и удобно разворачивать новое облачное окружение Azure с соблюдением всех требований безопасности и комплаенса.

2. Что можно сделать с помощью Blueprints?

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

• Role Assignments.

• Policy Assignments.

• Azure Resource Manager templates (ARM templates).

• Resource Groups.

В отличие от ARM-темплейтов, сервис Blueprints предназначен для конфигурирования окружения. Такая конфигурация обычно содержит набор из ресурсных групп, политик, ролей и, собственно, ARM-темплейтов. Blueprint содержит все эти артефакты вместе и поддерживает версионирование, что открывает возможность внедрения практик CI/CD.

Также, в отличие от ARM-темплейтов, при разворачивании ресурсов через Blueprint сохраняется связь между определением (что должно быть развернуто) и назначением (что было развернуто). Эта связь позволяет контролировать процесс разворачивания ресурсов.

Каждый Blueprint может (но не обязан) содержать ARM-темплейт.

3. Blueprint as Code

3.1 Предварительные требования

Для удобства работы с Blueprints в Azure DevOps на уровне организации можно установить расширение Azure Blueprints от Neil Peterson.

Работа c Blueprints состоит из следующих этапов:

• Подготовка Blueprint, его артефактов (см. ниже), а также файла с параметрами назначений (assign.json).

• Создание (publish) версии Blueprint в Azure Blueprints service.

• Назначение (assignment) версии Blueprint в результате создается окружение, соответствующее артефактам Blueprint и параметрам из файла assign.json, или же существующее окружение обновляется и приводится в соответствие с ними.

3.2 Структура артефактов Blueprint

Артефакты Blueprint описываются файлами JSON каждый артефакт содержится в отдельном файле.

В общем случае папка с Blueprints и артефактами выглядит так:

Файл blueprint.json основной, его назначение определение самого Blueprint. При деплое Blueprint он вызывается первым, а все артефакты представляют собой его дочерние ресурсы.

Файлassign.json обязателен при операции назначения Blueprint, он содержит значение переменных, которые используются в Blueprint в процессе Assignment (например, имена создающихся компонент, их SKU, регион, в котором будут созданы описанные компоненты, и т. д.). Обычно значения переменных или параметров в этом файле необходимо изменить. Для этого используется трансформация файла.

3.3 Трансформация файла

ФункцияFileTransformможет изменять содержимое XML или JSON-файлов.

Пример:

Файл assign.json, который используется в процессе назначение Blueprint. Нам необходимо изменить значения location, blueprintId, gOrganizationName и g_AzureRegion:

{    "identity": {      "type": "SystemAssigned"    },    "location": "testLocation",    "properties": {      "blueprintId": "testBlueprintId",      "resourceGroups": {},      "parameters": {        "g_Organization_Name": {          "value": "testOrgName"        },        "g_AzureRegion": {          "value": "testLocation"        }      }    }} 

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

variables:  location: 'westeurope'  properties.blueprintId: "/subscriptions/$(SubscriptionId)/providers/Microsoft.Blueprint/blueprints/AM-BP-feature-init"  properties.parameters.g_AzureRegion.value: $(location)  properties.parameters.g_Organization_Name.value: "Integration"

и выполняем трансформацию файла:

- task: FileTransform@1  inputs:    folderPath: '$(Agent.BuildDirectory)\blueprints'    fileType: 'json'    targetFiles: 'assign.json'

Можем посмотреть содержимое трансформированного файла:

- script: type "$(Agent.BuildDirectory)\blueprints\assign.json"

3.4 Типы артефактов

Blueprint состоит из артефактов, причем поддерживаются следующие типы последних:

• Ресурсные группы применяются на уровне подписок.

• ARM-темплейты применяются на уровне подписок и ресурсных групп.

• Назначение политик применяются на уровне подписок и ресурсных групп.

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

Рассмотрим пример файла blueprint.json:

{    "properties": {        "description": "This will be displayed in the essentials, so make it good",        "targetScope": "subscription",        "parameters": {             "principalIds": {                "type": "string",                "metadata": {                    "displayName": "Display Name for Blueprint parameter",                    "description": "This is a blueprint parameter that any artifact can reference. We'll display these descriptions for you in the info bubble",                    "strongType": "PrincipalId"                }            },            "genericBlueprintParameter": {                "type": "string"            }        },        "resourceGroups": {            "SingleRG": {                "description": "An optional description for your RG artifact. FYI location and name properties can be left out and we will assume they are assignment-time parameters",                "location": "eastus"            }        }    },    "type": "Microsoft.Blueprint/blueprints" }

Мы видим два опциональных параметраparameters: principalIdsиgenericBlueprintParameter.

Эти параметры могут быть использованы в любых дочерних артефактах. В этом случае мы определяем параметр ResourceGroup в файле blueprint.json, а не в отдельном файле.

3.5 Параметры

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

Параметр может быть определен в простом виде:

"parameters": {     "genericBlueprintParameter": {        "type": "string"    }}

Типы параметров можно найти в этом разделе документации.

Обращение к параметрам может происходить так же, как это делается в свойствах ARM-темплейтов (defaultValue, allowedValue и т. д.). Также мы можем вызвать параметры, определенные ранее:

"properties": {    "genericBlueprintParameter": "[parameters('principalIds')]",}

Также получить значение параметра можем через конструкцию вида:

${{ parameters.genericBlueprintParameter }}

3.6 Свойства Resource Group

Мы определили свойства Resource Group в главном файле blueprint.json с такими параметрами:

• Месторасположение: "location": "eastus".

• Имя размещения для ResourceGroup: SingleRG.

Ресурсная группа еще не создана, это случится после назначения (assignment).

По желанию мы можем указать имя ресурсной группы добавив "name": "myRgName" как дочерний параметр объекта SingleRG (подробнее посмотреть можно здесь).

3.7 Артефакты

Все артефакты должны иметь следующие параметры:

1. Kind, согласно которому, артефакт может быть:

   a. template,

   b. roleAssignment,

   c. policyAssignment.

2. Type, который для артефактов всегда будет:Microsoft.Blueprint/blueprints/artifacts.

3. Properties основной раздел, в котором описываются все свойства артефакта.

   Например:

   a. dependsOn опционально может указывать на зависимость от других артефактов. Больше информациитут.

   b. resourceGroup опционально может указывать на название ресурсной группы, где будут размещаться ресурсы. Если этот параметр не определен, для размещения ресурсов будет использоваться ресурсная группа, указанная в файле bluepring.json.

Полная спецификация для каждого типа артефактов описана здесь: Policy Assignment, Role Assignment, Template.

3.8 Работа с Blueprints в пайплайнах

Для работы с Blueprints можно использовать:

• powershell командлеты (модуль Az.Blueprint, подробнее см. здесь);

• таски, разработанные Neil Peterson (подробнее см. здесь, их мы и используем в этой статье).

3.8.1. Создание Blueprint

steps:- task: nepeters.azure-blueprints.CreateBlueprint.CreateBlueprint@1  displayName: 'Create Azure Blueprint'  inputs:    azureSubscription: 'nepeters-subscription'    BlueprintName: 'blueprints-demo'    BlueprintPath: ./create    IncludeSubFolders: true    PublishBlueprint: true    ChangeNote: 'Added new artifacts.'

Результаты можно просмотреть на Azure портале -> Blueprints -> Blueprint definitions.

3.8.2. Назначение Blueprint

steps:- task: nepeters.azure-blueprints.AssignBlueprint.AssignBlueprint@1  displayName: 'Assign Azure Blueprint'  inputs:    azureSubscription: 'nepeters-internal'    AssignmentName: 'prod-test-one'    BlueprintName: 'prod-test-one'    ParametersFile: 'assign/assign-blueprint.json'    AlternateSubscription: true    SubscriptionID: '00000000-0000-0000-0000-000000000000'    Wait: true    StopOnFailure: true

Результаты можно просмотреть на Azure портале -> Blueprints -> Assigned blueprints. Эта секция особенно полезна для получения детальных логов при ошибках назначения Blueprint.

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

Автор: Андрей Жуков, .NET Team Leader, DataArt

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

Задача, поставленная заказчиком: Azure -> GCP

Заказчик решил перейти из одного облака (Azure) в другое (Google Cloud Platform). В некотором отдаленном будущем вообще планировалось перевести серверную часть на Node.js и развивать систему силами команды full-stack typescript-разработчиков. На момент моего входа в проект там существовала пара ASP.NET MVC приложений, которым решили продлить жизнь. Их мне и предстояло перенести в GCP.

Начальная состояние, факторы, мешающие сразу перейти на GCP

Первоначально имелось два ASP.NET MVC-приложения, которые взаимодействовали с одной общей MS SQL базой данных. Они были развернуты на Azure App Services.

Первое приложение назовем его Web Portal имело пользовательский интерфейс, построенный на базе Razor, TypeScript, JavaScript, Knockout и Bootstrap. С этими клиентскими технологиями никаких проблем не предвиделось. Зато серверная часть приложения использовала несколько сервисов, специфичных для Azure: Azure Service Bus, Azure Blobs, Azure Tables storage, Azure Queue storage. С ними предстояло что-то делать, т. к. в GCP ни один из них не поддерживается. Кроме того, приложение использовало Azure Cache for Redis. Для обработки длительных запросов была задействована служба Azure WebJob, задачи которой передавались через Azure Service Bus. По словам программиста, занимавшегося поддержкой, фоновые задачи могли выполняться до получаса.

Azure WebJobs тоже предстояло чем-то заменить. Архитектура с очередью заданий для длительных вычислений не единственное среди возможных решений можно использовать специализированные библиотеки для фоновых задач, например, Hangfire, или обратиться к IHostedService от Microsoft.

Второе приложение назовем его Web API представляло собой ASP.NET WEB API. Оно использовало только MS SQL базы данных. Вернее, в конфигурационном файле были ссылки на несколько баз данных, в реальности же приложение обращалось только к одной их них. Но об этом нюансе мне только предстояло узнать.

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

Итак, нужно было перевести ASP.NET MVC приложения на ASP.NET Core 3.1, перевести WebJob c .NET Framework на .NET Core, чтобы можно было разворачивать их под Linux. Использовать Windows на GCP возможно, но не целесообразно. Надо было избавиться от сервисов, специфичных для Azure, заменить чем-то Azure WebJob, решить, как будем развертывать приложения в GCP, т. е. выбрать альтернативу Azure App Services. Требовалось добавить поддержку Docker. При этом неплохо было бы внести хоть какую-то архитектуру и поправить качество кода.

Общие принципы и соображения

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

В конце каждого этапа приложение должно находиться в стабильном состоянии, т. е. пройти хотя бы Smoke tests.

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

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

При замене сервисов Azure можно либо подобрать альтернативный GCP-сервис, либо выбрать cloud-agnostic-решение. Выбор сервисов в этом проекте и его обоснование в каждом случае мы рассмотрим отдельно.

План работ

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

1. Web Portal c ASP.NET MVC на ASP.NET Core

   1.1. Анализ кода и зависимостей Web Portal от сервисов Azure и сторонних библиотек, оценка необходимого времени.

   1.2. Перевод Web Portal на .NET Core.

   1.3. Рефакторинг с целью устранения основных проблем.

   1.4. Merge изменений Web Portal из основной ветки репозитория, сделанных параллельно другими разработчиками.

   1.5. Докеризация Web Portal.

   1.6. Тестирование Web Portal, устранение ошибок и развертывание новой версии на Azure.

2. Web API c ASP.NET MVC на ASP.NET Core

   2.1. Написание E2E автоматических тестов для Web API.

   2.2. Анализ кода и зависимостей Web API от сервисов Azure и сторонних библиотек, оценка необходимого времени.

   2.3. Удаление неиспользуемого исходного кода из Web API.

   2.4. Перевод Web API на .NET Core.

   2.5. Рефакторинг Web API с целью устранения основных проблем.

   2.6. Merge изменений Web API из основной ветки репозитория, сделанных параллельно другими разработчиками.

   2.7. Докеризация Web API.

   2.8. Тестирование Web API, устранение ошибок и развертывание новой версии на Azure.

3. Устранение зависимостей от Azure

   3.1. Устранение зависимостей Web Portal от Azure.

4. Развертывание в GCP

   4.1. Развертывание Web Portal в тестовой среде в GCP.

   4.2. Тестирование Web Portal и устранение возможных ошибок.

   4.3. Миграция базы данных для тестовой среды.

   4.4. Развертывание Web API в тестовой среде в GCP.

   4.5. Тестирование Web API и устранение возможных ошибок.

   4.6. Миграция базы данных для prod-среды.

   4.7. Развертывание Web Portal и Web API в prod GCP.

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

.NET Framework -> .NET Core

Перед началом переноса кода я нашел статью о миграции .Net Framework на .Net Core от Microsoft и далее ссылку на миграцию ASP.NET на ASP.NET Core.

С миграцией не-Web-проектов все обстояло относительно просто:

• преобразование формата хранения NuGet-пакетов с помощью Visual Studio 2019;

• адаптирование списка этих пакетов и их версий;

• переход с App.config в XML на settings.json и замена всех имеющихся обращений к конфигурационным значениям на новый синтаксис.

Некоторые версии NuGet-пакетов Azure SDK претерпели изменения, повлекшие несовместимость. В большинстве случаев удалось найти не всегда самую новую, зато поддерживаемую кодом .NET Core версию, которая не требовала бы изменений в логике старого программного кода. Исключением стали пакеты для работы с Azure Service Bus и WebJobs SDK. Пришлось с Azure Service Bus перейти на бинарную сериализацию, а WebJob перевести на новую, обратно несовместимую версию SDK.

C миграцией ASP.NET MVC на ASP.NET Core дело обстояло намного сложнее. Все перечисленные выше действия нужно было проделать и для Web-проектов. Но начинать пришлось с нового ASP.NET Core проекта, куда мы перенесли код старого проекта. Структура ASP.NET Core проекта сильно отличается от предшественника, многие стандартные классы ASP.NET MVC претерпели изменения. Ниже я привожу список того, что изменили мы, и большая его часть будет актуальна для любого перехода с ASP.NET MVC на ASP.NET Core.

1. Создание нового проекта ASP.NET Core и перенос в него основного кода из старого ASP.NET MVC проекта.

2. Корректировка зависимостей проекта от внешних библиотек (в нашем случае это были только NuGet-пакеты, соображения по поводу версий библиотек см. выше).

3. Замена Web.config на appsettings.json и все связанные с этим изменения в коде.

4. Внедрение стандартного механизма Dependency injection от .NET Core вместо любой его альтернативы, использовавшейся в Asp.NET MVC проекте.

5. Использование StaticFiles middleware для всех корневых папок статических файлов: изображений, шрифтов, JavaScript-скриптов, CSS-стилей и т. д.

app.UseStaticFiles(); // wwwrootapp.UseStaticFiles(new StaticFileOptions   {     FileProvider = new PhysicalFileProvider(         Path.Combine(Directory.GetCurrentDirectory(), "Scripts")),     RequestPath = "/Scripts"});

Можно перенести все статические файлы в wwwroot.

6. Переход к использованию bundleconfig.json для всех JavaScript и CSS-бандлов вместо старых механизмов. Изменение синтаксиса подключения JavaScript и CSS:

<link rel="stylesheet" href="~/bundles/Content.css" asp-append-version="true" /><script src="~/bundles/modernizr.js" asp-append-version="true"></script>

Чтобы директива asp-append-version="true" работала корректно, бандлы (bundles) должны находиться в корне, т. е. в папке wwwroot (смотри здесь).

Для отладки бандлов я использовал адаптированную версию хелпера отсюда.

7. Изменение механизма обработки UnhadledExceptions: в ASP.NET Core реализована его поддержка, остается с ней разобраться и использовать вместо того, что применялось в проекте раньше.

8. Логирование: я адаптировал старые механизмы логирования для использования стандартных в ASP.NET Core и внедрил Serilog. Последнее опционально, но, по-моему, сделать это стоит для получения гибкого structured logging c огромным количеством вариантов хранения логов.

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

10. Routing: в старом проекте использовался механизм, основанный на templates, его надо было чуть-чуть подправить.

11. JSON-сериализация: В ASP.NET Core по умолчанию используется библиотека System.Text.Json вместо Newtonsoft.Json. Microsoft утверждает, что она работает быстрее предшественницы, однако, в отличие от последней, она не поддерживает многое из того, что Newtonsoft.Json умела делать из коробки безо всякого участия программиста. Хорошо, что есть возможность переключиться обратно на Newtonsoft.Json. Именно это я и сделал, когда выяснил, что большая часть сериализации в Web API была сломана, и вернуть ее в рабочее состояние с помощью новой библиотеки, если и возможно, очень непросто. Подробнее об использовании Newtonsoft.Json можно прочитать здесь.

12. В старом проекте использовался Typescript 2.3. С его подключением пришлось повозиться, потребовалось установить Node.js, подобрать правильную версию пакета Microsoft.TypeScript.MSBuild, добавить и настроить tsconfig.json, поправить файл определений (Definitions) для библиотеки Knockout, кое-где добавить директивы //@ts-ignore.

13. Код для принудительной поддержки HTTPS включается автоматически при включении этой опции в визарде проекта. Старый код, использующий пользовательский атрибут HttpsOnly, был при этом убран.

14. Все низкоуровневые действия, такие как получение параметров из body запроса, URL запроса, HTTP Headers и HttpContext потребовали изменений, т. к. API для доступа к ним претерпел изменения по сравнению с ASP.NET MVC. Работы было бы заметно меньше, если бы в старом проекте чаще использовались стандартные binding механизмы через параметры экшенов (Actions) и контроллеров (Controllers).

15. Был добавлен Swagger c помощью библиотеки Swashbuckle.AspNetCore.Swagger.

16. Нестандартный механизм Authentication потребовал рефакторинга для приведения его к стандартному виду.

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

Что делать со специфичными сервисами Azure?

После перехода на ASP.NET Core предстояло избавиться от Azure-сервисов. Можно было либо подобрать решения, которые не зависят от облачной платформы, либо найти что-то подходящее из списка GCP. Благо у многих сервисов есть прямые альтернативы у других облачных провайдеров.

Azure Service Bus мы по настоятельной рекомендации заказчика решили заменить на Redis Pub/Sub. Это достаточно простой инструмент, не настолько мощный и гибкий как, например, RabbitMQ. Но для нашего простого сценария его хватало, а в пользу такого выбора говорило то, что Redis в проекте уже использовался. Время подтвердило решение было правильным. Логика работы с очередью была абстрагирована и выделена в два класса, один из которых реализует отправку произвольного объекта, другой получает сообщения и передает их на обработку. На выделение этих объектов ушло всего несколько часов, а если сам Redis Pub/Sub вдруг потребуется заменить, то и это будет очень просто.

Azure Blobs были заменены на GCP Blobs. Решение очевидное, но все-таки различие в функциональности сервисов нашлось: GCP Blobs не поддерживает добавление данных в конец существующего блоба. В нашем проекте такой блоб использовался для создания подобия логов в формате CSV. На платформе Google мы решили записывать эту информацию в Google Cloud operations suite, ранее известный как Stackdriver.

Хранилище Azure Table Storage использовалось для записи логов приложения и доступа к ним из Web Portal. Для этого существовал логгер, написанный самостоятельно. Мы решили привести этот процесс в соответствие с практиками от Microsoft, т. е. использовать их интерфейс ILogger. Кроме того, была внедрена библиотека для структурного логирования Serilog. В GCP логирование настроили в Stackdriver.

Какое-то время проект должен был параллельно работать и на GCP, и на Azure. Поэтому вся функциональность, зависящая от платформы, была выделена в отдельные классы, реализующие общие интерфейсы: IBlobService, IRequestLogger, ILogReader. Абстрагирование логирования было достигнуто автоматически за счет использования библиотеки Serilog. Но для того, чтобы показывать логи в Web Portal, как это делалось в старом приложении, понадобилось адаптировать порядок записей в Azure Table Storage, реализуя свой Serilog.Sinks.AzureTableStorage.KeyGenerator.IKeyGenerator. В GCP для чтения логов изGoogle Cloud operations были созданы Log Router Sinks, передающие данные в BigQuery, откуда приложение и получало их.

Что делать с Azure WebJobs?

Сервис Azure WebJobs доступен только для Azure App Services on Windows. По сути он представляет собой консольное приложение, использующее специальный Azure WebJobs SDK. Зависимость от этого SDK я убрал. Приложение осталось постоянно работающим консольным и следует похожей логике:

static async Task Main(string[] args){.   var builder = new HostBuilder();  ...              var host = builder.Build();  using (host)  {     await host.RunAsync();  }...}

За всю работу отвечает зарегистрированный с помощью Dependency Injection класс

public class RedisPubSubMessageProcessor : Microsoft.Extensions.Hosting.IHostedService{...public async Task StartAsync(CancellationToken cancellationToken)...public async Task StopAsync(CancellationToken cancellationToken)...}

Это стандартный для .NET Core механизм. Несмотря на отсутствие зависимости от Azure WebJob SDK, это консольное приложение успешно работает как Azure WebJob. Оно также без проблем работает в Linux Docker-контейнере под управлением Kubernetes, о чем речь в статье пойдет позже.

Рефакторинг по дороге

Архитектура и код приложения были далеки от идеала. В ходе многих шагов постепенно производились небольшие изменения кода, который они затрагивали. Были и специально запланированные этапы рефакторинга, согласованные и оцененные вместе с заказчиком. На этих этапах мы устраняли проблемы с аутентификацией и авторизацией, переводили их на практики от Microsoft. Был отдельный этап по внесению некой архитектуры, выделению слоев, устранению ненужных зависимостей. Работа с Web API началась с этапа удаления неиспользуемого кода. При замене многих Azure-сервисов на первом этапе производилось определение интерфейсов, выделение данных зависимостей в отдельные классы.

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

Docker

С поддержкой Docker все сложилось довольно гладко. Dockerfile можно легко добавить с помощью Visual Studio. Я добавил их для всех проектов, соответствующих приложениям, для Web Portal, Web API, WebJob (который в дальнейшем превратился просто в консольное приложение). Эти стандартные Dockerfile от Microsoft не претерпели особенных изменений и заработали из коробки за единственным исключением пришлось в Dockerfile для Web Portal добавить команды для установки Node.js. Этого требует build контейнер для работы с TypeScript.

RUN apt-get update && \apt-get -y install curl gnupg && \curl -sL https://deb.nodesource.com/setup_12.x  | bash - && \apt-get -y install nodejs

Azure App Services -> GKE

Нет единственно правильного решения для развертывания .NET Core-приложений в GCP, вы всегда можете выбрать из нескольких опций:

• App Engine Flex.

• Kubernetes Engine.

• Compute Engine.

В нашем случае я остановился на Google Kubernetes Engine (GKE). Причем к этому моменту у нас уже были контейнеризованные приложения (Linux). GKE, оказалось, пожалуй, наиболее гибким из трех представленных выше решений. Оно позволяет разделять ресурсы кластера между несколькими приложениями, как в нашем случае. В принципе для выбора одного из трех вариантов можно воспользоваться блок-схемой по этой сслыке.

Выше описаны все решения по используемым сервисам GCP, кроме MS SQL Server, который мы заменили на Cloud SQL от Google.

Тестирование

Web Portal тестировался вручную, после каждого этапа я сам проводил простенький Smoke-тест. Это было обусловлено наличием пользовательского интерфейса. Если по завершении очередного этапа, новый кусок кода выпускался в Prod, к его тестированию подключались другие пользователи, в частности, Product Owner. Но выделенных QA-специалистов, в проекте, к сожалению, не было. Разумеется, все выявленные ошибки исправлялись до начала очередного этапа. Позднее был добавлен простой Puppeteer-тест, который исполнял сценарий загрузки одного из двух типов отчетов с какими-то параметрами и сравнивал полученный отчет с эталонным. Тест был интегрирован в CICD. Добавить какие-то юнит-тесты было проблематично по причине отсутствия какой-либо архитектуры.

Первым этапом миграции Web API, наоборот, было написание тестов. Для это использовался Postman, затем эти тесты вызывались в CICD с помощью Newman. Еще раньше к старому коду была добавлена интеграция со Swagger, который помог сформировать начальный список адресов методов и попробовать многие из них. Одним из следующих шагов было определение актуального перечня операций. Для этого использовались логи IIS (Internet Information Services), которые были доступны за полтора месяца. Для многих актуальных методов перечня было создано несколько тестов с разными параметрами. Тесты, приводящие к изменению данных в базе, были выделены в отдельную Postman-коллекцию и не запускались на общих средах выполнения. Разумеется, все это было параметризовано, чтобы можно было запускать и на Staging, и на Prod, и на Dev.

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

Azure MS SQL -> GCP Managed MS SQL

Миграция MS SQL из Managed Azure в GCP Cloud SQL оказалась не такой простой задачей, как представлялось вначале. Основных причин тому оказался несколько:

• Очень большой размер базы данных (Azure портал показал: Database data storage /

  Used space 181GB).

• Наличие зависимостей от внешних таблиц.

• Отсутствие общего формата для экспорта из Azure и импорта в GCP Cloud SQL.

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

Перед началом миграции нужно удалить все ссылки на внешние таблицы и базы данных, иначе миграция будет неудачной. Azure SQL поддерживает экспорт только в формат bacpac, более компактный по сравнению со стандартным backup форматом. В нашем случае вышло 6 Гб в bacpac против 154 Гб в backup. Но GCP Cloud позволят импортировать только backup, поэтому нам потребовалась конвертация, сделать которую удалось лишь посредством восстановления в локальную MS SQL из bacpac и создания backup уже из нее. Для этих операций потребовалось установить последнюю версию Microsoft SQL Server Management Studio, причем локальный сервер MS SQL Server был версией ниже. Немало операций заняли по многу часов, некоторые и вовсе длились по несколько дней. Рекомендую увеличить квоту Azure SQL перед импортом и сделать копию prod базы, чтобы импортировать из нее. Где-то нам потребовалось передавать файл между облаками, чтобы ускорить загрузку на локальную машину. Мы также добавили SSD-диск на 1 Тб специально под файлы базы данных.

Задачи на будущее

При переходе с Azure App Services на GCP Kubernetes мы потеряли CICD, Feature Branch deployments, Blue/Green deployment. На Kubernetes все это несколько сложнее и требует иной реализации, но наверняка делается посредством все тех же Github Actions. В новом облаке следуем концепции Iac (Infrastructure-as-Code) вместе с Pulumi.

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

Иван Левицкий, Salesforce разработчик, DataArt

Привет! Меня зовут Иван, как Salesforce разработчик я успел поработать уже в нескольких аутсорсинговых и аутстаффинговых компаниях, в локальных и распределенных командах, с клиентами из разных стран и индустрий. Соответственно, и потребности у заказчиков различались: одним инфраструктура Salesforce была нужна для внутренних систем, другим для работы с клиентами, третьим для разработки ISV-решений. С июля 2017 года моего первого знакомства с Salesforce я получил девять сертификатов, дважды экзамены мне приходилось пересдавать.

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

О Salesforce

Немного о самом Salesforce, на случай если вы им предметно еще не интересовались. Это компания и одновременно ее ключевой продукт мировой лидер в области CRM. Но это не все, в Salesforce позиционируют себя как первый Cloud based CRM Solution и очень любят вспоминать термин No Software (даже используют в номере своего телефона 1-800-NO-SOFTWARE). А продукт с самого начала был задуман как SaaS Software as a Service облачная система, очень гибкая в плане настройки, масштабирования и расширения. Salesforce предлагает множество готовых решений для различных областей бизнеса: Sales Cloud, Service Cloud, Experience Cloud (Ex Community Cloud), CPQ, Force.com sites, Marketing B2B (Pardot), B2C clouds и это далеко не полный список.

Даже если вам не приходилось работать с инфраструктурой Salesforce, о новостях компании вы время от времени наверняка слышите: она в разное время поглотила таких IT-гигантов как Slack, Heroku и Tableau, не считая множества игроков поменьше, но также с серьезными именами. Кстати, Salesforce как компанию несколько раз признавали лучшим работодателем США, и на поддержку сообщества клиентов и Salesforce специалистов она тоже тратит значительные ресурсы. Короче говоря Salesforce экосистема в полном смысле слова.

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

Для чего вообще нужна сертификация?

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

Насколько мне известно, сертификаты высоко ценятся среди:

Project Managerов Project Management Professional Certification (PMP);

Cyber Security специалистов: OSCP, OSCE, CISSP, SANS;

Salesforce специалистов.

Даже у бизнес-аналитиков мнения на этот счет уже значительно расходятся.

Что дает Salesforce сертификация?

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

Зачем это нужно Salesforce?

1. Сертификация обеспечивает ему дополнительный доход: допуск к экзамену стоит $ 200 или $ 400 (их очень много и предназначены они для людей разного профессионального уровня). Пересдача обойдется в $ 100 или $ 200, соответственно. Также есть возможность стать Salesforce CTA (Certified Technical Architect) всего за $ 6000 ($ 3000 за пересдачу). Тем не менее, речь здесь идет скорее о самоокупаемости самой системы сертификации, которая требует значительных ресурсов, в том числе человеческих.

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

Для чего это компании, в которой вы работаете?

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

Зато если ваша компания предоставляет услуги аутсорсинга или аутстаффинга, сертификация сотрудников становится для нее приоритетной.

Почему это так важно?

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

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

Для чего это лично вам?

1. Ваши сертификаты привязаны персонально к вам, а не к компании.

2. Даже если вы скептически относитесь к сертификации, вы все равно согласитесь с тем, что сертификаты характеризуют вас как человека, готового учиться. И все-таки гарантируют, что хотя бы кое-что по теме вы знаете.

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

Я уже молчу о возможности потешить свое эго, распечатав и повесив сертификаты на видном месте. Что вы, лично я так никогда не делал! Но в целом система ачивок, бейджей и титулов в Salesforce настроена здорово, и участвовать в настолько геймифицированном процессе приятно.

С чего начать?

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

Далее нужно ознакомиться со списком всех специальностей, работающих с Salesforce, и выбрать для себя наиболее подходящую. Так называемый Career Path вы можете посмотреть здесь.

Salesforce Certification Paths

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

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

Очень часто наличие сертификата Salesforce Certified Administrator обязательное условие для допуска к другим экзаменам. Прежде всего тем, которые предназначены для консультантов. Для администраторов и Marketing Cloud Email специалистов Salesforce предусматривает пробные экзамены стоимостью $20. Их успешная сдача не гарантирует успешного прохождения реального испытания, зато помогает выявить собственные слабые стороны, а если таких не находится укрепляет уверенность в себе.

Как подготовиться к Salesforce экзамену?

1. Выбрав сертификат, на который хотите сдавать, убедитесь, что у вас соблюдены все условия допуска к нему. Некоторые сертификаты таких условий не имеют, но проверить стоит в любом случае.

Сделать это можно при регистрации на экзамен на сайте Webassesor.

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

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

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

4. Как только план готов, пора регистрироваться на экзамен. Без дедлайна ваши планы это просто планы. Даже если вы не успеете подготовиться к выбранному вами дню, за 72 часа до сдачи сможете перенести ее на более поздний срок бесплатно. Только не откладывайте решение на последний момент, иначе за изменение даты придется доплатить еще $ 75.

5. Действуйте.

Рекомендации по подготовке

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

Разделите весь процесс подготовки на пять этапов.

1-й этап (особенно важный, если у вас нет практического опыта) ознакомление с Trailhead, официальной платформой для изучения Salesforce. Начинать стоит с trailов, в названии которых есть словосочетания "Quick Start" или "Quick Look". В качестве самого первого рекомендую этот Trailhead: Quick Look (5 mins).

2-й этап знакомство с описанием экзамена. Его можно найти здесь: выберете роль и соответствующий экзамен.

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

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

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

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

Бонусы:

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

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

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

Полезные ссылки:

https://quizlet.com/ просто вбейте в строку поиска нужный вам экзамен;

https://t.me/SalesforceA группа в Telegram, где бесплатно выкладывают обновленные дампы Salesforce экзаменов;

https://focusonforce.com/ здесь есть все: теория, практика и объяснения каждого ответа. Сайт платный, но он того стоит.

На экзамене

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

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

Распределите отведенное вам время. Не зацикливайтесь на сложном вопросе, у вас таких еще 64. Отложите его на потом.

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

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

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

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

Послесловие

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

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

Удачи на экзаменах!

На сайте IT-музея DataArt собраны шесть больших глав обистории вычислительной техники вСССР, фото и описания нескольких десятков экспонатов,личные истории разработчиков ЭВМ и программистов, которые на них работали. Специально для Хабра мы собрали небольшую серию постеров с предметами коллекции музея.

Компьютер Электроника КР-03

СССР, Козьмодемьянск, завод Копир, конец 1980-х начало 1990-х

Компьютер из заводского радиоконструктора для самостоятельной сборки. В комплект входили печатная плата для Радио-86РК с незначительными изменениями, клавиатура Электроника МС7007 и другие элементы, включая ОЗУ на 16 Кб. Экземпляр из нашей коллекции доработан добавлен дисковод под 5-дюймовые дискеты.

Видеотерминал Mera Elzab 7953

В номенклатуре СМ ЭВМ СМ 7209

Польская Народная Республика, Забж, Завод Mera Elzab, 1988

Подобные терминалы использовались как устройства ввода-вывода информации для машин СМ ЭВМ поздних поколений: СМ 4, СМ 1300, СМ 1420, Mera 60, или для оригинальных PDP-11. Экран отображает 1920 символов в 24 строки по 80 символов в каждой. Экранная память построена на статических элементах памяти 1024х4 бит. Видеотерминал управляется при помощи микропроцессоров Intel i8080 или Z80, которые могли заменять аналогами: советским КР580ВК80 и немецким U880, соответственно. Клавиатуру к терминалу СМ 7209 выпускали на заводе Zbrojovka Brno в Чехословакии.

Видеотерминал ВТА-2000

Украинская ССР, Винница, завод Терминал, начало 1980-х

Символьный монитор и клавиатура подключались к мини-ЭВМ СМ-1 и СМ-2, архитектура которых была заимствована у машины DEC PDP-11. Выпуск ВТА-2000 в Виннице наладили, чтобы заменить польский видеотерминал Mera и венгерский Videoton. Хотя их ввозили из стран, входивших в СЭВ, они оставались импортными: стоили дороже и оплачивались в валюте, которую приходилось экономить.

Ленточный накопитель (tape drive) Archive corporation FT-20

США, Archive Corp., 1988

Устройство предназначено для записи информации на специальные картриджи объемом 120 Мб. Калифорнийская компания Archive Corporation занималась производством накопителей на магнитной ленте в конце 1980-х и начале 1990-х годов.

Матричный принтер Epson LX 800

Япония, Seiko Epson, конец 1980-х

Эта модель от японского гиганта Seiko Epson, одного из крупнейших производителей принтеров в мире, была популярна на территории бывшего СССР во второй половине 1990-х. Матрица из 9 игл могла печатать на отдельных листах или на протяжной ленте.

Портативный компьютер Apple Macintosh PowerBook 520

СШАКитай, Apple, 1994

После ухода Стива Джобса в Apple были разработаны несколько продуктов, в частности, ноутбук PowerBook 520 с 9,5-дюймовым монохромным жидкокристаллическим экраном. Микропроцессор 68LC040 от компании Motorola имел тактовую частоту 25 мГц, а объем ОЗУ машины мог быть либо 4, либо 12 Мб. Весил ноутбук уже относительно немного 2,9 кг, а в продажу поступал с предустановленной системой Mac OS 7.1. Стартовая цена базовой модели составляла $2250.

Фото на обложке персональная микро-ЭВМ Электроника МС 0511, разработанная в 1987 году в Зеленограде специально для учебных классов информатики.

Математические машины Армении первый большой спецпроект IT-музея DataArt. Он посвящен армянским инженерам-электронщикам и вычислительной технике, созданной ими во второй половине XX века.

Ереванский научно-исследовательский институт математических машин, открытый в 1956 году, стал одной из первых в СССР организаций, изначально ориентированных на разработку ЭВМ. Первые крупные проекты ЕрНИИММ были завершены уже в начале 1960-х, за 30 последующих лет армянские конструкторы сыграли заметную роль в истории развития вычислительной техники в Восточной Европе. В Ереване проектировали и собирали новые машины для науки и образования, промышленности и транспорта, управления и оборонных программ.

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

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

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