Неформальное резюме или 20 лет жизни в IT
19.11.2013 Вторник 06:49
Пару с лишним месяцев назад, 1 сентября 2013-го года, как-то незаметно прошла весьма круглая для меня дата — двадцать лет начала трудовой деятельности на ниве программирования. В связи с этим мне показалось интересным записать свои впечатления и интересные моменты, связанные с IT-проектами, над которыми пришлось работать за эти двадцать лет. Для полноты картины я решил включить сюда и мои совсем ранние попытки создать что-то на ниве программирования, которые я предпринимал самостоятельно, ещё будучи школьником и студентом начальных курсов. Надеюсь, что в итоге получилось что-то типа оригинального неформального онлайн-резюме, ну или хотя бы просто нескучные мемуары программиста-старпёра. 
Да мне и самому интересно всё это вспомнить и зафиксировать в блоге, чтобы не ушло в небытиё. Как обычно, начав писать то, что задумывалось как относительно небольшой пост, я не смог остановиться и в итоге накатал целый трактат. Ну, надеюсь хоть кому-нибудь это будет интересно.
Электроника МК-61
1987..88
Первый раз я прикоснулся к чему-то программируемому году примерно в 1987-ом, когда родители купили мне программируемый калькулятор "Электроника МК-61". С помощью него я познакомился с понятием стека и, вообще, начал представлять себе, каким образом алгоритм превращается в программу, то есть в последовательность команд, обрабатываемых процессором. Но всё же на калькуляторе я скорее не программировал, а использовал и изучал готовые программы. В этом деле неоценимую помощь мне оказал журнал "Техника — молодёжи", в котором в те годы был цикл статей, посвящённых отечественным программируемым калькуляторам. Причём это были не сухие теоретические статьи про какие-нибудь инженерные математические расчёты на калькуляторах, а увлекательное фантастическое повествование, в которое очень органично вплеталась идея использования очередной программы, которую можно было самостоятельно ввести в калькулятор и тут же представить себя участником описываемых событий. До сих пор помню тот азарт, с которым мы с друзьями "летали вокруг Луны", используя для расчётов параметров "полёта" программу из статьи. Жалко, что у меня не сохранилась бумажная "карта" Луны и её орбитальных окрестностей с изображением машрута нашего полёта.
Sinclair ZX Spectrum
1989..93
Первым языком программирования, на котором я что-то писал, стал Бейсик (BASIC). А именно его вариант, реализованный в восьмибитном компьютере Sinclair ZX Spectrum. Для тех, кто не в курсе, поясню. Был такой компьютер, выпускавшийся в Великобритании с 1982-ого года до... примерно начала девяностых, наверное. Это был не единственный популярный восьмибитный игровой компьютер тех времён — вспоминаются ещё как минимум "Атари" и "Комодор". Но у Спектрума была совершенно уникальная судьба, связанная с тем, что он стал безумно популярным среди советской/российской технически-ориентированной публики того времени. На постсоветском пространстве выпускались буквально десятки моделей-клонов оригинального компьютера, созданные на отечественной элементной базе (единственным оригинальным элементом был центральный процессор Zilog Z-80; впрочем потом и его стали заменять российским аналогом).
На синклеровском бейсике я создал собственную реализацию известной игры "Удав" (где змея поедает разбросанную по игровому полю еду, становясь при этом длиннее), а также довольно навороченную для меня по тем временам программу для учёта метеорологических данных, с рисованием графиков температуры и давления (как учили в школе на уроках природоведения). Во время написания этой программы я довольно быстро понял, что Бейсик, по крайней мере синклеровский, для написания больших программ не предназначен. При превышении критического значения размера программы, вносить в неё изменения стало крайне проблематично — не хватало номеров строк (sic! Синклеровский Бейсик позволял иметь не более 9999 строк), а вывод текста программы на экран производился со скоростью умирающей черепахи.
Реальная крутизна наступила когда я освоил программирование на ассемблере синклеровского процессора, Zilog Z-80. На самом деле, использование ассемблера было практически единственным способом писать на Синклере хоть что-то серьёзное в плане быстродействия и экономного расходования памяти. Использование любых компиляторов и, тем более, интерпретаторов упиралось в аппаратные ограничения: 48 килобайт ОЗУ (минус почти семь килобайт на экранную память) и процессор с тактовой частотой всего 3,5 МГц. Я написал на ассемблере несколько утилит. Первая умела просто форматировать дискету, но делала это, разумеется, используя не готовую подпрограмму в ядре операционки (иначе программа состояла бы из одного вызова), а низкоуровневые обращения к контроллеру дисковода, благодаря чему её, по идее, можно было использовать для форматирования под любую операционку — не только TR-DOS (операционка Спектрума), но и, например, MS-DOS.
Ещё одна утилита умела копировать дискеты, но делала это не на файловом уровне, а посекторно. Это позволяло использовать её для копирования дискет, защищённых некоторыми методами защиты. Для экономии ресурсов код программы размещался в видео-памяти.
Вершиной же моего творчества на ассемблере Z-80 явилась программа под названием Codex. Это была утилита, предназначенная для копирования файлов между дискетой в формате MS-DOS и дискетой в формате TR-DOS. К сожалению, я написал её только наполовину: программа умела копировать файлы в одном направлении — из MS-DOS в TR-DOS. Конечно, реализовать самому процедуру копирования было непросто, но всё же самым сложным было создать на ассемблере графический пользовательский интерфейс, с какими-никакими окошками. Кстати в 2005-ом году я приводил в блоге скриншоты из Кодекса.
Написание Codex с одной стороны стоило мне больших усилий, а с другой немало поспособствовало приобретению навыка формализовать и упорядочивать процесс создания программы. До сих пор помню пачку из примерно десяти листов формата A4, на которых я вёл учёт всех процедур программы. Для каждой процедуры были указаны точка входа, ожидаемые параметры в стеке и обычной памяти, используемые глобальные переменные, выполняемая функциональность и возвращаемые данные. Титаническая работа, надо заметить. Поддерживать этот список в актуальном состоянии было нетривиальным упражнением на усидчивость, внимательность и терпение.
НИИ
1993-1997
Ну а в 1993-ем году (я учился тогда на третьем курсе Политеха) я оказался в качестве стажёра в одном НИИ, и тогда наконец началась работа не за просто так, а за зарплату. Первым реальным проектом стала программа, эмулировавшая... В общем, что-то там эмулировавшая. Она имела графический интерфейс и была написана на Паскале. Паскаль вообще был основным (скорее даже единственным на тот момент) средством разработки в лаборатории, к которой меня причислили.
На самом деле, этот дебют на ниве профессионального программирования дался мне непросто. Помню, меня снабдили совсекретной книжкой, описывавшей математическую модель, которую мне надо было реализовать в коде. Я как-то долго не мог въехать в суть того, что от меня хотят, и несколько месяцев непонимающе втыкал в формулы, изображая видимость бурной интеллектуальной деятельности. Несмотря на мои усилия по созданию этой видимости, начальство догадывалось, что дело стоит на месте, и тучи надо мной постепенно сгущались. Всё могло бы закончиться печально, но в какой-то момент "плотину прорвало", и я всё понял. Понял что и как надо делать. И за пару недель интенсивной работы завершил проект. Статус кво был восстановлен.
Хочу отметить, что я считаю Паскаль чудесным средством для изучения программирования (на то время). В нём существует масса навязываемых средой ограничений, но эти ограничения — это то, что держит новичка в рамках, позволяющих создавать более-менее качественный, надёжный и поддерживаемый код. В более профессиональных языках программирования (долгое время в индустрии IT таким языком почти исключительно являлся C++) ограничений меньше, что, с одной стороны, даёт большую свободу, с другой — требует от программиста определённой самодисциплины. Вот эту дисциплину отчасти и помогает привить Паскаль.
Примерно году к 1994-ому или 95-ому относится мой первый опыт написать что-то под Винды (до этого всё писалось под MS-DOS, если не считать упражнений на Синклере). Первая прога под Windows была на Паскале (Borland Pascal), и написал я программку расчёта для карточной игры Преферанс (которой мы с друзьями в то время ооооочень увлекались, но это отдельная история). Прога имела оконный интерфейс. Если бы я сейчас взглянул на этот интерфейс, я бы, наверное, содрогнулся: всё вкривь и вкось, какие-то несуразные слайдеры для введения исходных данных, никакого дизайна — всё дефолтно-чёрно-белое и малопригодное для реального использования. В общем, трэш. Но в то время, время когда на VGA-мониторах безраздельно властвовали текстовые досовские окошки, а графический интерфейс с окошками только начинал пробивать себе путь в сердцам пользователей, реализация какого-никакого графического интерфейса с новомодными оконными элементами управления вызывала неподдельный восторг и полные штаны радости.
А потом для меня наступила эпоха C/C++. Примерно году в 1995-ом я прочитал классическую книгу Кернигана и Ричи по C и пару книжек братьев Фроловых по C++. И я очень благодарен этим авторам и их книгам — это было лучшее, что я прочитал из технической литературы в своей жизни. Ну или, по крайней мере, одно из лучшего. Особенно благодарен Фроловым — местами не очень простые концепции языка C++ они объясняли доступным, человеческим языком, что позволило мне освоить язык относительно быстро и достаточно полно.
Отмечу, что много лет спустя, в Атланте, я купил книгу на ту же тему авторства не кого-нибудь, а самого создателя языка C++, Бьёрна Страуструпа (кстати, некоторе время я работал с ним в одной компании — AT&T; впрочем, это настолько гигантская компания, размазанная ровным слоем по всем Штатам, что о том, чтобы увидеть создателя самого главного языка индустрии IT живьём, речи не шло). Так вот, книга Страуструпа произвела на меня гораздо меньшее впечатление чем книги Фроловых. Слишком академично. Фроловы писали с целью объяснить понятным языком. Меня всегда такой подход очень подкупает. Легче всего строить из себя элиту, изрекая нечто заумное, предназначенное тем, кто и так понимает. И гораздо сложнее, но вызывает больше уважения, попытка объяснить простым языком сложные концепции.
Вернёмся к моим баранам проектам. Работая всё в том же НИИ, используя Visual C++ 4.2 я написал прогу для эмуляции морского боя. Она рисовала карту моря, позволяла расставлять на поле брани корабли, вертолёты и подводные лодки, задавать им всем параметры движения и наблюдать за развитием боя. Разработка этой программы стала темой моей дипломной работы в институте.
Потом с уровня прикладного программирования я внезапно нырнул в глубины низкоуровневого программирования драйверов для Windows. Наш НИИ разработал собственный сетевой интерфейс, состоявший из платы, вставлявшейся в слот ISA, для которого понадобилось написать драйвер под винды. Интерфейс использовался для передачи данных между компьютером и нестандартным оборудованием собственной разработки, поэтому стандартные сетевые интерфейсы не катили. Написание этого драйвера было крайне нетривиальной задачей. Пришлось выкурить весь Windows DDK (Drivers Development Kit), прочесть массу технической информации на английском языке. Мой драйвер работал в режиме ядра (kernel mode), то есть имел неограниченный никакими защитами от дурака доступ решительно ко всем внутренним ресурсам операционной системы. Одно неверное движение в коде заканчивалось знаменитым "синим экраном смерти" (BSoD, blue screen of death). Да, и надо отметить, что код драйвера тогда (не знаю, как сейчас) писался на чистом C. Что, конечно, более удобно чем программирование на Ассемблере, но не намного. В общем, написание этого драйвера было, пожалуй, одной из самых сложных задач, с которыми мне приходилось иметь дело.
Кстати, с этим драйвером связана одна забавная история. Дело в том, что поначалу его долго не удавалось заставить работать. Хотя вроде как всё написано как надо. Закрались подозрения, всё ли в порядке с самим сетевым устройством, которое этот драйвер контролировал. Как это проверить? Знаете, когда автомобиль не заводится, рекомендуется первым делом проверить наличие бензина в бензобаке. Примерно в духе этой рекомендации я решил просто осмотреть плату на предмет визуально-детектируемых проблем, не особо при этом на что-то надеясь. Но мне повезло! В одном месте я обнаружил какую-то подозрительную подвижность одного паянного соединения. Нашёл паяльник и пропаял это место. И, о чудо, всё заработало! Начальство реально впечатлилось. Да я и сам, по правде говоря, был в шоке.
Написав драйвер, из программирования где-то в недрах Windows я вернулся обратно в область прикладной разработки. Хотя и с системным уклоном. Теперь мне понадобилось создать сервис (так называемый "контроллер канала"), который служил для обмена данными между различными потребителями, с использованием интерфейса, для которого и был написан мой драйвер. А также надо было создать пример клиента, использующего этот сервис. Это всё опять было написано на C++, но уже с нюансами. Во-первых, надо было как-то заюзать из обычного приложения драйвер для передачи через него данных. Во-вторых, контроллер канала был моим первым приложением, при написании которого я столкнулся с многозадачностью и, соответственно, необходимостью синхронизации доступа к общим данным. Примерно тогда я узнал, что такое мьютексы (mutex, "мутехи", как называл их один мой коллега), критические секции, семафоры и прочие фишки для многопоточности. Ещё одним нюансом была необходимость (не помню уже, чем вызванная) использовать код, собранный компилятором Паскаля, из функций на C++. Задачу удалось успешно решить, попутно выяснив разницу в механизме вызова функций, реализуемом этими двумя языками.
Вообще, надо отметить, что это сейчас ответ на девяносто процентов вопросов, связанных с программированием, как правило можно найти, просто введя свой вопрос в Google и выбрав первую ссылку из списка результатов поиска — скорее всего там будет готовый рецепт для решения вашей программистской проблемы. Google, как известно, знает всё. Но в те времена, о которых идёт речь (1996..97-ой годы), такого слова — Google — ещё просто не существовало в английском языке. Как и одноимённой компании с её поисковым сервисом. Интернет тогда уже постепенно появлялся (я лично впервые набрал что-то в адресной строке браузера в 1995-ом году; кстати, это был Netscape и это было на Sun Solaris), но информации в нём было ещё с гулькин нос, а в нашем НИИ интернет появился и вовсе году в 1997-ом и исключительно в кабинете у генерального директора. Так что до многого приходилось доперать самому и опираться в качестве источника информации на книги, а также разнообразные SDK.
Водоканал
1998-1999
На этом моя карьера в этом НИИ закончилась, и в 1998-ом году я перешёл в структуру, подотчётную Санкт-Петербургскому Водоканалу. О, хотя я работал там всего пару лет, но это была целая эпоха! Работая в команде мы написали для Водоканала замечательное графическое приложение на Visual C++, которое рисовало карту города Санкт-Петербург, отображало на ней водопроводную и канализационную сеть, позволяло смотреть характеристики труб, колодцев (в просторечии — люков) и выполнять прочие полезные функции, например определяло, где какие задвижки на трубах надо перекрыть, чтобы локализовать прорыв водопроводной трубы с минимальным количеством отключенных потребителей.
Работая над этим проектом я впервые стал использовать систему управления базами данных (СУБД). До этого как-то удавалось обходиться без этого — данных было мало, и всё замечательно помещалось в файлах. Понятно, что подробная карта города с нанесёнными на неё инженерными сетями требовала какого-то более продвинутого способа хранения и использования данных чем файлы. Таким способом стала самая, пожалуй, мощная на тот момент система RDBMS Oracle. Решение использовать Oracle мы не принимали, оно было продиктовано использованием в качестве ядра всей системы экзотического пакета программ FRAMME американской компании Intergraph, купленного Водоканалом за какие-то нереальные деньги (что-то порядка нескольких десятков тысяч долларов). Поэтому нам не приходилось принимать каких-то серьёзных архитектурных решений — вся архитектура была создана за нас американскими разработчиками FRAMME. Нам, команде разработки Водоканала, оставалось лишь дописывать свой собственный функционал и органично встраивать его в существующую систему. Я уже за давностью времени не помню деталей архитектуры творения Intergraph, но помню, что в целом это работало и работало неплохо. И относительно несложно расширялось.
Кстати, то самое графическое приложение с картой и трубами мы создали на основе одной из программ пакета, которая называлась FieldView. По сути мы провели руссификацию и глубокую модернизацию данного продукта, добавив большое количество новых функций. Так вот, наш модернизированный продукт с лёгкой руки начальника стал называться "Полегляд", что является примерной калькой с "FieldView". Поначалу это несерьёзное название существовало лишь для внутреннего употребления командой разработчиков, но как-то незаметно вошло в официальные документы, подписывавшиеся большими начальниками в Водоканале.
Наша система начинала внедряться в городе Кронштадте, поэтому одно время мне приходилось часто ездить туда в служебные командировки. Но затем случилось непредвиденное — на рубеже 1999-го и 2000-го годов я неожиданно для самого себя нашёл работу в Америке.
Логистика
2000-2002
В апреле 2000-го года я начал работать в своей первой американской компании. Помню, когда я был маленький у меня тоже была бабушка, я, как и многие, наверное, тогда в моём возрасте, думал о том, каким я буду в 2000-ом году. Прекрасно помню, как я считал, сколько мне будет тогда лет. И сосчитав, приходил к выводу, что много — целых двадцать пять. Но мне ни при каких обстоятельствах не приходило в голову, что жить при этом я буду не просто в другой стране, а на другом континенте. "In the land of opportunity and adventure" (c) Bladerunner. Но в сторону лирику!
Моей первой работой в США стала компания в Атланте, предоставлявшая услуги в форме, как сказали бы сейчас, Software as a Service (SaaS). Нашими услугами пользовались транспортные и логистические компании, которым надо было рассчитать оптимальный маршрут транспортировки груза, рассчитать стоимость и т.п. Наши услуги они получали по платной подписке. Интересным моментом было то, что инвесторами компании была пара каких-то мужиков из Южной Африки (ЮАР). Изначально компания была частной, то есть не имела своих акций для открытой торговли на бирже (в России аналогом, видимо, является ООО). Но в 2001-ом году они выпустили акции (то есть компания стала public, это аналог российского ОАО), и вскоре её поглотила более крупная логистическая компания с канадскими корнями. Я по сей день помню как безудержно радовались три отца-основателя компании в тот день когда было подписано соглашение о слиянии. Видимо, их при этом совсем не обидели деньгами. Впрочем, и простым смертным кое-что перепало за счёт stock options (право, дающееся сотрудниками private-компании, в случае выхода компании на биржу купить акции по фиксированной и, главное, низкой цене).
Но вся эта бизнес-казуистика была в то время как никогда далека от меня, почти что вчерашнего студента, не смыслившего даже в российской модели бизнеса, что уж говорить про чуждую Америку. Я сосредоточился на более понятных мне вещах — освоении новых технологий. И надо сказать, эта компания дала мне многое. Тут я узнал про Microsoft SQL Server, COM, COM+, DCOM, ATL, некоторые шаблоны проектирования, веб-разработку, системы контроля версий (точнее, про одну систему — SourceSafe). Работая здесь я сдал свои первые сертификационные экзамены — это были экзамены от Brainbench по C++ и, кажется, JavaScript. Ещё я понял, что институт (питерский Политех) дал мне очень мало в плане программирования (что отчасти объяснимо — моя специальность была больше ориентирована на проектирование железа, а не на софт). Американские коллеги, закончившие местные технические ВУЗы, постоянно ставили меня в тупик, используя в дискуссиях и применяя в коде какие-то неизвестные мне (но как я теперь знаю, являющиеся классическими и знакомые любому уважающему себя программисту) шаблоны проектирования.
В общем, работа в этой компании была неплохой школой. Спустя полгода после того как я начал у них работать, компания выкупила меня у доставившей меня в Америку рекрутерской конторы, сделав попутно мне мою первую рабочую визу (H-1B). Изначально я приехал в США по визе стажёра — J-1. А в 2002-ом грянул кризис доткомов, и меня с группой товарищей по несчастью сократили и выставили на улицу с пособием в размере месячной зарплаты. Я как сейчас помню этот день. Это был вторник. В понедельник ничего не предвещало того, что случится на следующий день — то есть вообще никому ничего не сказали. Придя во вторник на работу я попытался залогиниться в свой комп, но не смог этого сделать — пароль был сменён. Вскоре после этого меня вызвала к себе тётенька-начальник HR, сообщила пренеприятное известие, выдала пакет документов, сопроводила до моего рабочего места, где я под её присмотром собрал свои личные вещи, затем проводила до выхода из офиса и, попрощавшись, закрыла дверь. И так поступали с каждым сокращённым. Видимо, чтобы оградиться компанию от каких-то необдуманных поступков со стороны тех, кому не повезло. Например, нанесения намеренного вреда компании в отместку за решение о сокращении. Как-то для русского человека это всё звучит несколько дико — ну уволили и уволили. Новую работу найдём. Но для американца сокращение — настоящая трагедия. Я помню слёзы на глазах взрослых мужчин, подвергшихся остракизму. Посмотрел бы я на них если бы они оказались в моих башмаках.
А мои башмаки были совсем незавидными. В тот самый момент когда за мной захлопнулась дверь офиса компании, которой я стал больше не нужен, начали тикать часы, отсчитывавшие оставшееся мне время легального пребывания в США. На тот момент иммиграционное законодательство США отводило месяц на то, чтобы потерявший работу владелец рабочей визы, нашёл новую работу и сделал трансфер визы на новую компанию (американская рабочая виза привязана к работодателю), оставшись таким образом в легальном статусе. При этом помимо таймера иммиграционных властей тикал и таймер просто насущных расходов, главным из которых являлась арендная плата за квартиру. В Америке с неплательщиками не церемонятся. Я своими глазами видел как выглядит выселение (это называется eviction) неплатящих за квартиру. Просто всю мебель и все вещи выносят из квартиры и ставят на газон у выезда из квартирного комплекса. Больший позор представить себе можно, но сложно. Звериный оскал капитализма, чё.
Неофициальная работа
2002
В общем, положение было довольно удручающим. Но выручили друзья. Сначала они помогли мне найти удалённую работу. Рулила процессом предприимчивая девушка из Нью-Йорка, а я выполнял работу удалённо на своём домашнем компе. Это, однако, было временным решением, так как работа была неофициальной, никак не связанной с правами, даваемыми рабочей визой. Пришлось, невзирая на личные предпочтения, заниматься модернизацией приложения, написанного на не слишком почитаемом мной Visual Basic'е, для какой-то телефонной компании. Платили, надо сказать, за это копейки. Но выбирать тогда не приходилось. Отведённый мне месяц на решение вопроса с иммиграционным статусом неумолимо истекал, и я начал всерьёз задумываться о возвращении на родину.
AT&T
2002-2004
И тут внезапно те же друзья дали мне рекомендацию для одной из крупнейших американских компаний, работающей в области телекоммуникаций, — AT&T. У компании оказался "карманный" рекрутер, который очень оперативно сделал трансфер визы, и вскоре я начал совершенно официально и легально работать на телекоммуникационный гигант.
В AT&T я впервые плотно занялся веб-разработкой. Причём сразу на ASP.NET. Таким образом, пре-дотнетные технологии, такие как ASP, PHP, Java обошли меня стороной, и я по-прежнему имею о них крайне поверхностное теоретическое представление. Именно в AT&T я в полной мере осознал, что самая запаристая область программирования — это именно веб-разработка. Я намеренно написал "запаристая", а не "сложная". Писать под веб не сложно, нет. А просто муторно и нудно. И причина этого — в слабой стандартизации и совершенно свободном понимании производителями браузеров существующих стандартов трёх основных инструментов веб-программирования: HTML, CSS и JavaScript. Впрочем, в AT&T разработка велась исключительно под Internet Explorer, поэтому различия в поддержке стандартов были для меня не столь критичны. Но есть, я считаю, в веб-программировании ещё одна фундаментальная проблема, сложившаяся в силу особенностей исторического развития этой ветви IT-индустрии.
Дело в том, что протокол HTTP изначально задумывался как принципиально stateless. То есть, сервер получил запрос, сгенерировал ответ, отослал его обратно и тут же навсегда забыл о том, что произошло. И эта концепция чудесно работает для примитивных приложений. А других приложений в те времена, когда придумывали HTTP, существовать не могло, ибо скорости обмена данными между хостами сети были по нынешним меркам просто черепашьи. Однако прогресс не стоит на месте. Скорости выросли на несколько порядков, и сейчас потребность в веб-функциональности вышла далеко за пределы возможностей stateless-приложений. А протокол, тем не менее, остался тот же. Вот и приходится рулевым нашей индустрии изощряться, придумывая способы использовать нехарактерным образом то, что для такого использования изначально не было предназначено: всякий там Ajax, хитрые фокусы с ViewState, хранящимся в коде ответа, отсылаемого сервером клиенту (что принципиально ломает концепцию statelessness), куки и т.д. Хотя на мой взгляд мы имеем тут дело как раз с тем случаем когда надо "всё выкинуть и переписать заново". Пора отказаться от морально устаревшего протокола HTTP так же, как в своё время Microsoft отказался от MS-DOS, создав версию Windows, для которой костыль в виде MS-DOS был не нужен. Собственно, насколько я понимаю, подобные идеи витают в воздухе, и такая вещь как недавно появившийся протокол WebSocket — это оно и есть: замена HTTP, ориентированная на statefulness и, вообще, тесное взаимодействие клиента и сервера.
Как бы то ни было, для AT&T я работал над созданием нескольких веб-приложений. Одно из них предназначалось для инженеров компании, работающих с весьма обширной сетью оптоволоконных кабелей. Знакомая тема, да? В Водоканале были водопроводные трубы, тут — оптоволоконные кабели, но суть та же. Разница лишь в том, что тут все было оформлено в виде веб-приложения, причём не простого, а с элементом управления ActiveX в качестве графического ядра, используемого для отображения топологии сети в окне браузера и интерактивной работы с этим изображением.
Сеть оптоволокна, принадлежащего AT&T, поистине обширна, и данные об этой сети хранились в нескольких базах данных SQL Server (или Oracle? Уже и не помню за давностью лет). И это был мой первый опыт работы с действительно большими наборами данных. До этого объёмы данных, с которыми я имел дело, были относительно обозримыми, и поэтому можно было не заморачиваться с оптимизацией запросов. Но с базами AT&T такой трюк не проходил. Пришлось плотно познакомиться с разными видами join'ов, индексами, планами выполнения, linked server'ами и т.д. В общем, это был интересный опыт, хотя мне показалось, что существует не так много по-настоящему профессиональной литературы на тему оптимизации в SQL Server и экспертов, шарящих в этом на высоком уровне. Но может, я плохо искал.
Банк
2004-2005
В 2004-ом году я перешёл на работу в один из крупнейших американских банков и самый крупный на юго-востоке страны. Я считаю эту свою работу первой, на которой я наконец оказался в роли старшего программиста (англ. senior engineer). Хотя бы по зарплате. Я понял, что пора пожинать плоды трудных лет изучения программирования (на тот момент мой опыт коммерческой работы составлял одиннадцать лет). При устройстве в банк я попросил сумму, существенно превышавшую мою зарплату в AT&T и, к моему немалому удивлению, получил её. С тех пор я уже никогда не стеснялся просить много. Понятно, что при этом неизбежны и отказы (и их было немало в моей карьере), но можно, как говорил поручик Ржевский, и впендюрить. 
Что также периодически в дальнейшем происходило.
Отношение к безопасности в банке серьёзное. Иначе это не был бы банк. Сердце финансовой системы организации — это иголка, которая в яйце, которое в ларце, который в зайце... (или там по-другому как-то?). В общем, идея ясна — уровней защиты много. Само ядро написано чёрт знает когда на давно забытом людьми языке программирования, тогда же отлажено до абсолютно непогрешимого состояния, работает на мейнфрейме, закрыто семью печатями и, я не удивлюсь, если уже никто не знает, как оно работает и где. Шучу, конечно. Были в банке люди, знавшие всю поднаготную, но это, видимо, были люди особого сорта, обладавшие огромным доверием владельцев банка и, наверное, совсем необделённые деньгами.
В банке я изучил две принципиально новые для меня вещи — веб-сервисы и Plumtree. Про первое, наверное, знают (или, как минимум, слышали) практически все, кто имеет отношение к IT, а про второе не знает, скорее всего, никто. Plumtree — это аналог SharePoint, давно проигравший в конкурентной борьбе своему майкрософтовскому собрату.
Был в банке один интересный момент, о котором хочется упомянуть. Точнее, два. Оба они показывают, что с контракторами (а я, как и многие другие, работал там контрактором) не церемонятся. Дело в том, что в США существует по большому счёту два варианта оформления в компании: сотрудник на полный рабочий день (FTE, full time employee) и контрактор (contractor). FTE получает фиксированную годовую зарплату, обязан работать минимум сорок часов в неделю, за переработку, как правило, ничего дополнительно не получает, и налоги за него платит работодатель. FTE защищён местным трудовым кодексом и уволить его примерно так же непросто как в России — как минимум придётся платить выходное пособие. Контрактор получает почасовую оплату, как правило зарабатывает существенно больше FTE при том же объёме работы, получает дополнительную оплату за переработку, сам платит налоги и гораздо меньше защищён в плане произвола со стороны работодателя. То есть грубо говоря, его можно уволить "сейчас". Что и произошло у нас в коллективе с парой человек. Один сотрудник из-за чего-то повздорил с начальством (деталей я не знаю), и на следующий день он уже не работал. Другой товарищ, видимо, решил, что в банке ему мало а)платят, б)дают работы. Поэтому занялся в рабочее время подработкой на другую фирму. Спалился он когда затеял распечатывать на плоттере банка какую-то здоровую диаграмму, содержание которой не имело никакого отношения к бизнесу компании, что и было замечено админом, помогавшим работящему сотруднику осуществлять данную процедуру. Админ сообщил начальству, ну и карьера этого контрактора в банке закончилась в тот же день.
Raxxla.com
2004..настоящее время
Кроме того, работая в банке я, как ни странно, нашёл время для своего собственного проекта — а именно сайта и блога Raxxla.com. Это было не сложно, ибо под конец проекта работы практически не осталось, поэтому каждый занимался в офисе чем бог на душу положит. Даже в мини-гольф играли, помню. Основная функциональность блога была заложена тогда, в 2004-ом, и с тех пор не особо сильно поменялась. Разве что данные блога (посты, комментарии), которые изначально хранились в XML, ныне хранятся в базе SQL Server. И дизайн сайта как минимум один раз кардинально изменился.
BizTalk, Sharepoint
2005..08
На этом заканчивается моя первая американская эпопея и возобновляется российская. В 2005-ом году я вернулся на родину, где очень быстро нашёл работу (первые собеседования были назначены ещё когда я находился в США). Новая работа, как ни странно, оказалась на американскую компанию. Спектр её деятельности был довольно широким — мы выполняли заказы для разных заказчиков, работавших в самых разных предметных областях. Для меня работа здесь была примечательна тем, что я соприкоснулся с двумя очень замороченными техническими решениями Microsoft — BizTalk и SharePoint. Я считаю, что в обоих случаях Microsoft намудрил такого, что сам испугался. В целом они взяли неплохие архитектурные идеи, но попытались реализовать их настолько глобально, всеобъемлюще и универсально, что получилось нечто, на мой взгляд, монстроидальное, весьма непростое в использовании. И при этом без какой-то особой мега-выгоды, которая бы оправдывала бы такую сложность.
BizTalk поначалу привлёк меня тем, что программы в нём можно... рисовать. Прямо в виде блок-схем алгоритмов. У меня самого идея такого способа программирования иногда до этого возникала. Ведь часто, когда думаешь над новым алгоритмом, сперва рисуешь его на бумаге. Почему бы не сделать так, чтобы рисунок и был программой? К сожалению, когда я попробовал это на практике, я как-то охладел к этой идее. По крайней мере в реализации BizTalk'а графическая форма чего-то, чуть более сложного чем самый элементарный алгоритм, довольно быстро начинала выглядеть совершенно неудобоваримым сгустком прямоугольников и соединявших их стрелок. Разобраться в этом стоило немалых усилий, что представлялось вообще малоосмысленным, учитывая что аналогичная логика, оформленная в виде традиционного кода, разбитого на классы и функции, будет на порядок понятнее.
С Sharepoint я соприкоснулся совсем мимолётно, но понял его ещё меньше чем BizTalk. По-моему, стремление к универсальности надо иногда сдерживать, иначе получаются вот такие малопонятные монстры. Опять же, наверное, вполне можно разобраться в их архитектуре и даже стать экспертом, но я не вижу, какую выгоду даёт такая сложность. По поводу Sharepoint я ни разу ни от кого не слышал восторженных возгласов, зато не один раз встречал в интернете мнения людей, плотно с ним работавших, о том, что чтобы понять Sharepoint, надо поменять некоторые свои убеждения, касающиеся логики — здравый смысл работает там не всегда. Ну и зачем оно такое надо?
Некоторое время назад я кратко пообщался с моими бывшими коллегами из этой компании и выяснил, что практически все их клиенты, использовавшие BizTalk, отказались от него. С Sharepoint'ом ситуация вроде не такая плачевная, и он вроде по-прежнему много где используется, но всё же будущее этого продукта представляется мне не слишком радужным. По сути ведь это не более чем навороченная CMS с возможностью расширения функциональности. Я в CMS не специалист, но по-моему сейчас на рынке есть масса вариантов, более простых в понимании и использовании.
А ещё на этой работе я познакомился с системой контроля версий SVN и её клиентом TortoiseSVN. Как ни странно, за много лет работы это оказалась всего лишь вторая SCM-система, которую я использовал. До этого я соприкасался исключительно с майкрософтовским SourceSafe. Я нашёл SVN очень простой, удобной, понятной и надёжной системой. Для работы над проектами в небольшой команде лучше не придумаешь, имхо.
Уйду чуть-чуть в оффтопик, но хочется об этом сказать. Одним из клиентов компании была контора, строящая бревенчатые дома на заказ. Эх, какие у них на веб-сайте были картинки с этими домами! Живописнейшие места, большие красивые дома, рай на земле просто! Живут же люди.
Шведы
2008..2012
Потом я устроился в российский филиал одной шведской компании и начался мой "скандинавский период". Если не считать трудоустройства в НИИ (в котором я начинал ещё будучи студентом на неполной рабочей неделе), в шведской компании я проработал дольше чем в любой другой — почти четыре года. Длительные командировки в Осло и Стокгольм — это было чудесно. Здесь была масса разнообразных проектов для норвежских и шведских заказчиков. Причём проекты варьировались от весьма серьёзных до довольно, на мой взгляд, несуразных.
На одном из проектов я прочувствовал всю глубину веб-программирования в полной мере. Нигде и никогда до этого я не постигал в такой полноте суть жизненного цикла страницы ASP.NET, не использовал столько навороченных контролов, джава-скрипта и аджакса. А также столь заумных шаблонов проектирования. Всё это было благодаря некоторым моим коллегам — российским и норвежским, рулившим этим проектом, которые не отказывали себе ни в чём когда речь заходила о максимально интенсивном использовании всего инструментария, доступного программисту. У нас просто шаблон на шаблоне сидел и шаблоном погонял. На мой взгляд, такая навороченная архитектура была очень сильно избыточной, хотя и работала правильно и надёжно (по-другому быть не могло — грамотные люди её придумывали).
Кстати, на этом проекте я впервые использовал третью в своей карьере систему управления версиями — TFS. И даже писал какой-то код для интеграции с ней.
Проект был весьма неплохой разминкой для мозгов и дал мне много новых знаний. Но я не могу не отметить, что продвинутость в своей специальности у некоторых людей, судя по всему, накладывает отпечаток на их психологический портрет — с некоторыми коллегами по этому проекту мне было сложно работать. В психологическом плане. И не только мне.
Поэтому я был отчасти рад когда меня перевели на другой проект. И это было очень интересное начинание — впервые в своей карьере я вёл весь проект, хоть и небольшой, целиком — от сбора и анализа требований заказчика (буквально, ездил с этой целью в Стокгольм в компанию-заказчик) до внедрения и поддержки. Благодаря небольшому масштабу проекта мне удалось совместить сразу несколько ролей (хотя обычно это считается плохой практикой): я был техническим руководителем проекта (в команде кроме меня было два разработчика и тестер), архитектором, разработчиком и техническим писателем. Собственно, в техническом плане проект был несложным: по сути мы всего лишь переписали некий сервис для обработки входящих XML-файлов с Delphi на C#. Но и тут была пара интересных моментов. Во-первых, для создания UI к сервису мы использовали новомодную (а значит, "сырую") по тем временам (2009-ый год) технологию ASP.NET MVC. Которую я, как ни странно, умудрился полностью обойти своим вниманием, ибо UI делали другие люди. Во-вторых, сервис использовал какую-никакую многопоточность, так что пришлось вспомнить старые добрые мьютексы и прочие средства синхронизации потоков. Кроме того, мы где-то для чего-то прикрутили WCF.
Кстати, со стороны заказчика проект обсуждал со мной автор той самой Delphi-версии продукта, которую мы переписывали, швед. С ним связано несколько интересных, хотя и офтопичных в рамках данного поста моментов. Во-первых, он страдал сахарным диабетом и один раз немало меня шокировал, достав во время нашей беседы в офисе шприц и ширнувшись инсулином. Не, на самом деле, он меня предупредил о таком развитии событий и его причинах. Если бы он этого не сделал, это был бы совсем неиллюзорный шок. Я бы, наверное, подумал, что все шведы — бытовые наркоманы, ширяющиеся между делом вместо чашки кофе.
Во-вторых, программирование было лишь одним из его занятий по жизни. Выяснилось, что кроме этого он — успешный музыкант со своей домашней студией и рядом выпущенных широким тиражом дисков. Однако он категорически отказался назвать свой музыкальный псевдоним, сказав, что принципиально не раскрывает связь между двумя своими ипостасями — программистской и музыкальной. Ну и наконец, вскоре после нашего с ним общения этот швед... ушёл в декрет. Да, в Швеции в отпуск по уходу за ребёнком может уходить любой из родителей, чем шведские мужчины нередко пользуются. Причём отпуск этот достаточно длительный, не меньше года, если не ошибаюсь (американским роженицам такое может только сниться в розовых снах: тут декрет, насколько я знаю, — неделя или две).
Было в шведской компании за четыре года много и других проектов. Один был связан с многопоточностью и высокой нагрузкой, так что приходилось оптимизировать всё, что можно. Задачей другого проекта была конверсия данных из одной, устаревшей, системы в другую. Из старой системы данные приходили в виде CSV-файлов и в процессе конверсии закачивались в SQL Server. Всё было бы просто если бы надо было просто закачать данные в новую базу. На самом деле, конверсия осуществлялась в уже существующую базу, имеющую свою устоявшуюся и давно используемую структуру, которая хоть и была семантически близкой структуре базы, из которой данные выгружались, но всё же имелись отличия, иногда значительные. Поэтому процесс этот был кропотливым и ответственным, требовавшим активного участия экспертов в предметной области, с которыми нам, как разработчиками, приходилось плотно взаимодействовать. Важно было, во-первых, не ухудшить по дороге качество данных, а также провести конверсию на живой системе в один из выделенных для этого выходных.
Ещё один проект был прекрасным кандидатом на реализацию при помощи упоминавшегося выше BizTalk. Надо было обеспечить автоматической коммуникацией несколько слабосвязанных участников некоторого бизнес-процесса. В общем-то, BizTalk для этого и создавался. Однако в верхах было решено реализовывать систему самостоятельно (BizTalk недёшев, видимо; хотя можно было поискать альтернативы — есть, между прочим, и бесплатные варианты). В итоге мы написали довольно сносную универсальную ESB (Enterprise Service Bus). Хотя там было много всяких недоработок и косяков, конечно, следует это признать. Но меня эта тема настолько увлекла, что я ещё долго после окончания проекта и даже после ухода из этой компании лелеял мысль о том, чтобы самостоятельно написать что-то по-настоящему универсальное, отлаженное, быстрое и надёжное. Я имею в виду ESB. И продавать. Хотя как бороться с бесплатными open-source конкурентами мне не совсем понятно. Как бы то ни было, мысли эти поныне в реальность так и не воплотились.
Норвеги
2012
Наконец, спустя четыре года работы на шведов, я сменил работу. И устроился опять же к скандинавам. В этот раз — к норвегам, в питерский филиал компании SoluDyne. Об этой компании и моём опыте работы в ней я исчерпывающе написал в специальном посте на эту тему: "Наблюдение об одной компании". Добавить мне практически нечего. Полгода на этой работе оказались самым неудачным опытом в моей карьере. Из плюсов там было то, что я изучил Selenium — библиотеку для автоматизированного тестирования веб-приложений, и халявная пицца по пятницам, пожалуй и всё.
VIAcode
2012..13
Сбежав из SoluDyne я нашёл пристанище в питерской компании VIAcode. Проработав там почти год я могу с уверенностью сказать, что это был совершенно уникальный опыт. Дело в том, что VIAcode является официальным вендором Microsoft. Это означает, что мега-корпорация тесно сотрудничает с этой (относительно) небольшой питерской конторой и периодически даёт ей заказы на выполнение проектов. В итоге я получил совершенно уникальную возможность поработать в тесном сотрудничестве с Microsoft, приложить к руку к созданию широко используемого программного обеспечения и даже съездить в командировку в Редмонд, в штаб-квартиру компании. Работа в VIAcode дала и много новых знаний — прежде всего это пакет Microsoft System Center и облачная технология Windows Azure.
System Center — это очень обширный пакет, включающий в себя несколько продуктов, по каждому из которых можно без конца читать и читать литературу. Понятно, что объять необъятное в ограниченное время невозможно, поэтому проекты, в которых я принимал участие, были связаны в основном с одним-двумя продуктами из System Center. Больше всего мне пришлось работать с Operations Manager и Virtual Machine Manager. До начала работы в этой компании я и не подозревал о существовании System Center, но выяснилось, что лет девять назад я по касательной сталкивался с очень-очень ранней инкарнацией System Center Operations Manager (также известного как SCOM), который тогда назывался MOM (Microsoft Operations Manager). Суть этой проги, предназначенной для мониторинга за функционированием какой-либо системы, в том, что будучи установленной на одном или нескольких серверах, она собирает информацию со своих агентов, установленных внутри системы, за которой ведётся наблюдение, и делает эту информацию доступной для админа. Это универсальная концепция, и в принципе SCOM может использоваться для мониторинга совершенно чего угодно, что может каким-либо образом выдавать во внешний мир информацию о своём состоянии. Для того, чтобы начать что-то мониторить, нужно иметь так называемый management pack — специальный модуль расширения для SCOM, который знает, что и как надо делать, чтобы получить, обработать и отобразить данные о функционировании системы. Если же management pack'а для того, за чем хочется наблюдать при помощи SCOM, нет, то его надо написать. В этом и заключалась моя работа.
В качестве учебно-разогревочного задания мне дали задачу написать management pack для WAP (wireless access point), получающий по Telnet информацию о количестве клиентов, подключенных к наблюдаемым WAP, и отображаюший её в SCOM. Это был внутренний проект VIAcode, а для Microsoft я принимал участие в написании другого management pack'а — для Windows Azure. Этот pack уже существовал ранее, а мы писали его вторую версию — с блэкджеком и... в общем, с блэкджеком. Так что к тому, что можно скачать по этой ссылке, я приложил некоторую руку.
Надо сказать, что SCOM — это вещь, которая заставлять поменять то, как работают мозги в процессе программирования. Ибо создание management packs также далеко от традиционного программирования, которым я занимался всё время до этого, как Луна от Земли. Там всё работает по-другому, взаимодействия между частями системы неочевидны, многие детали происходящего скрыты в недрах SCOM, и понять, что и как происходит, иногда крайне сложно. В общем, я не могу сказать, что испытывал какой-то особенный восторг, создавая management pack'и. Традиционное программирование — это то, в чём я себя чувствую гораздо комфортнее.
Другим проектом для Microsoft, в рамках которого я и ездил в Редмонд, был eLearning — портал для дистанционного обучения, одна из возможностей которого предусматривает выполнение "лабораторных работ" на автоматически разворачиваемых в Azure виртуальных машинах. Незадолго до моего ухода из компании проект прошёл фазу GA (general availability), так что по идее должен сейчас быть в публичном доступе.
Надо сказать, что в процессе работы с Microsoft ореол непогрешимой корпорации, в которой работают исключительно гении, никогда не совершающие ошибок, у меня несколько развеялся. Там работают обычные люди, и неразберихи там порой не меньше (а на мой взгляд местами и больше) чем в других IT-компаниях. Несколько напрягал какой-то безумный темп работы, причём, такое впечатление, что создавашийся искусственно и не дававший какого-то положительного выхлопа по сравнению с более спокойной работой. Постоянно надо было что-то спешить делать, постоянно всем не хватало времени, постоянно решения принимались в спешке. Некоторые сотрудники Microsoft даже отменяли свои летние отпуска из-за угрозы срыва сроков сдачи. В общем-то, я люблю иногда поработать активно — я знаю, что при активной работе удельная продуктивность может существенно увеличиваться. Но то, что я видел в Microsoft, это на мой взгляд, перегиб, не дающий ничего кроме плохо продуманной, созданной в спешке архитектуры и такого же кода. Конечно, Microsoft — огромная организация с десятками тысяч сотрудников и сотнями проектов, поэтому не стоит думать, что то, что я описал выше — норма для этой компании. Это лишь частный опыт частного программиста в одном частном проекте. Тот же проект по Azure MP был гораздо более спокойным, последовательным, размеренным и спланированным.
В чём совершенно нельзя отказать Microsoft это в том, что любой их проект — это как сёрфинг на доске, ты постоянно ощущаешь себя на гребне волны. То, что до широкой публики дойдёт через год-два, а то и через несколько лет, в Microsoft делается здесь и сейчас. Cutting edge, fringe area, bleeding edge — это всё про Microsoft. Понятно, что, как и у любой другой компании, у них бывают удачные и неудачные проекты, начинания. Что-то новое приживается и остаётся, что-то забывается и уходит в историю, но бОльшая часть того, чем пользуется сейчас индустрия IT, рождается, апробируется и выпускается в жизнь в Microsoft и подобных ей компаниях, двигающих прогресс вперёд. И это очень интересно.
Америка, часть вторая
2013..настоящее время
Ну а в 2013-ом году началась моя вторая "американская кампания". Я переехал в Бостон и вот уже месяц работаю в компании, создающей сеть, объединяющую в себе участников процесса медицинского страхования, то есть больницы, врачей, пациентов и страховые компании. Рассказ об этой компании, а также о всём, что последует далее — впереди. Где-то, видимо, лет через двадцать.
Продолжение следует!