Свою 33-ю годовщину работы в индустрии разработки ПО я отпраздновал 3 июля. Я запомнил эту дату, потому что мой второй день на работе оказался оплачиваемым выходным!
Я хочу показать вам, насколько далеко ушла наша индустрия и сколь многому мы научились.
Логотип первой программной компании, в которой я работал. Изображение в низком разрешении, потому что компания закрылась в 1996 году, и это всё, что я смог найти в Интернете.
Первой компанией по разработке ПО, в которой я работал, была Applied Computing Devices из Терре-Хот, штат Индиана. В организации была куча невероятно умных людей, и с ними было интересно работать. Мы создавали ПО для управления телефонными сетями. Нашими клиентами были AT&T, US Sprint (теперь она называется просто Sprint), GTE (теперь Verizon) и множество региональных компаний-операторов Bell (компаний, занимающихся стационарными телефонами), в том числе Ameritech (которая обслуживала Индиану), BellSouth и Pacific Bell. Эти компании в основном предоставляли стационарные (на бизнес-жаргоне называвшиеся «wireline») телефонные услуги, но некоторые из них уже начали создавать подразделения для работы мобильной связью. Управлять всем этим было трудно, и наши программные продукты были относительно сложными. Чтобы понять некоторые элементы нашего ПО, мне требовались все мои знания курса математики колледжа.
Я был не разработчиком ПО, а техническим писателем. Я писал толстенные бумажные руководства, которые мы отправляли клиентам. В них объяснялось, как устанавливать, настраивать и использовать наше ПО. В те времена индустрия разработки ПО была очень маленькой, а когда я получил степень по математике/computer sciences, экономика находилась в упадке. Мне удавалось пройти не так уж много собеседований на должность кодера, а пройденные собеседования не завершались предложениями работы.
Летом, пока я искал работу, я жил в кампусе, но лето вскоре должно было закончиться и мне пришлось бы возвращаться домой и жить с отцом. Меня совершенно не привлекала эта перспектива, поэтому я решил диверсифицировать усилия и попробовать найти любую работу в программной компании: QA, техподдержка, ИТ, уборщик, кто угодно. Я решил, что потом уже разберусь.
Профессор моего колледжа знал людей из ACD и познакомил меня с ними. Им был нужен технический писатель. Я сказал, что с радостью возьмусь за работу, и они наняли меня за $23 000 в год (сегодня это примерно $54 000). К своему удивлению я обнаружил, что мне нравится писать тексты даже больше, чем писать код. Я научился очень хорошо объяснять пользователям работу нашего сложного технического ПО.
Здание ACD, теперь ставшее домом для Rose-Hulman Ventures
В этой статье я бы хотел рассказать, каково было там работать (параллельно испытывая трепет к своим сверхумным коллегам). В то время индустрия ПО была совершенно другой!
Многое из того, что мы сейчас воспринимаем как должное, ещё не существовало. Интернет существовал, но не было веба. Программное обеспечение доставлялось клиентам на лентах и гибких дисках. Устройство для записи компакт-дисков изобретут ещё через несколько лет. Java не существовало, JavaScript не существовало, .NET не существовало. Самыми используемыми языками были C/C++, FORTRAN, Pascal, Ada, Perl, Tcl и Lisp. А, и, разумеется, COBOL. Как-то летом я работал в колледже программистом на Pascal! Объектно-ориентированное программирование существовало, но было нишевым. Ведущим ОО-языком тогда был Smalltalk. Один из моих соседей по общежитию колледжа стал очень крупной фигурой в сообществе разработчиков на Smalltalk и даже писал книги про Smalltalk!
Кроме того, тогда ещё не существовало концепции распространения программного обеспечения по подписке. Компании платили за ПО наперёд и могли использовать купленный релиз бесконечно. Им приходилось платить повторно за крупные обновления. Некоторые хитрые компании растягивали платежи на несколько лет, но лицензия всё равно была пожизненной.
Когда мы отправляли клиентам по почте новую версию нашего продукта, большинство из них не устанавливало её сразу же, а некоторые вообще никогда не устанавливали её. «Нам вполне подходит версия, на которой мы работаем». Для техподдержки это было сущим кошмаром. В конечном итоге мы решили поддерживать только последние четыре версии, к крайнему раздражению наших клиентов, но к бесконечной благодарности нашего отдела поддержки.
Лучшей из имевшихся систем SDLC (systems development life cycle, жизненного цикла разработки ПО) была каскадная модель (водопад) со всеми её проблемами, которые коснулись нас даже тогда. Вся индустрия работала над очень долгими проектами релизов, например: два месяца на сбор требований и проектирование спецификации, затем девять месяцев кодинга, а далее три месяца тестирования. Даже если мы понимали (а большинство этого не понимало), что мелкие частые релизы во многих отношениях лучше, мы не могли реализовать такую систему. Отправка ПО на физических носителях была дорогостоящей операцией, а частые установки программ мешали бы работе наших клиентов.
В те времена мы думали, что проекты разработки ПО должны управляться как производственные или строительные проекты. Поэтому мы чертили огромные диаграммы Ганта (и распечатывали их на матричном принтере), а потом вешали на широкую стену и использовали их для сверки планов и выполнения работы. В первую неделю кодинга мы всегда выясняли, что не подумали о чём-то на этапе проектирования и нам приходилось перепланировать весь проект и печатать новые диаграммы Ганта. Мы делали это снова и снова для каждого проекта.
Когда код наконец добирался до QA, тестеры находили сотни или тысячи багов. Они почти не видели ПО до тех пор, пока оно не попадёт к ним в руки и их почти не задействовали на этапе создания. Из-за огромного объёма багов этап тестирования всегда требовал намного больше времени, чем было запланировано. Но к тому времени мы уже обещали клиентам, что отправим ПО к определённой дате, поэтому чтобы сдержать обещание, каждый релиз выпускался с целой кучей известных багов, которые мы устраняли в релизе, выпускавшемся несколько недель спустя (так называемом «fast follower»). Умные клиенты научились не устанавливать релиз, пока не появится «fast follower».
Из-за этого проекты всегда превращались в ужасные гонки на выживание со множеством часов переработки в будни и выходные перед датой релиза. Уровень выгорания был высоким. Но увольнялись из-за него очень немногие, потому что мы считали, что так и должно быть. Да и уходить было особо некуда: программных компаний существовало мало, и в них тоже возникали такие гонки на выживание.
Технологический стек (этого термина тогда ещё не существовало) компании ACD состоял из C++ на двух разновидностях UNIX: Ultrix корпорации Digital Equipment Corporation и AIX компании IBM. Наше ПО работало на миникомпьютерах DEC и IBM с архитектурой RISC, эти машины были размером с морозильную камеру. Целая куча таких компьютеров стояла в большой прохладной серверной. Так как компания находилась на задворках Терре-Хот, электричество нам поставлял сельский энергетический кооператив, и питание было не особо надёжным. Не знаю, почему у нас не было бесперебойных источников питания или генератора, никто их не покупал. Примерно раз в месяц происходило кратковременное отключение электричества. Миникомпьютеры были соединены в последовательную цепочку и должны были загружаться по порядку. Для загрузки одной машины требовалось около десяти минут. Для завершения загрузки всех компьютеров приходилось ждать больше трёх часов. Если перепад напряжения происходил примерно после 14 часов, мы просто уходили домой на весь оставшийся день.
Удалённой работы и работы из дома ещё не существовало. На миникомпьютерах можно было работать только в офисной сети. Я думаю, технически возможно было подключить их к Интернету, однако дома у всех нас был только коммутируемый доступ. Проблема заключалась бы не только в скорости, но и в том, что семьи не были бы рады, что пока мы работаем, телефонная линия постоянно занята.
У каждого разработчика на столе стоял терминал, с которого они делали всё. Поначалу все инженеры работали на знаменитых терминалах VT100, но позже компания купила им огромные графические терминалы за $2000, чтобы те могли создавать UI в X Windows. Тогда понятия «дизайн UX» ещё не существовало, поэтому не было разделения на разработку фронтенда и бэкенда. Интерфейс пользователя проектировали разработчики ПО, и большинство из них справлялось с этим не очень хорошо.
Я работал техническим писателем, поэтому у меня был Macintosh II с System 6 (System — это предыдущее название MacOS) и 8 МБ ОЗУ. Для того времени это была мощнейшая машина. Я писал руководства в программе Interleaf. Для подключения к миникомпьютерам я использовал эмулятор терминала на Mac.
В то время разворачивались холивары о текстовых редакторах. IDE ещё не существовало, поэтому все мы писали код в текстовом редакторе. Я был сторонником Emacs, однако большинство моих коллег любило vi.
Наши терминалы были соединены в сеть token ring, связывающуюся с этими миникомпьютерами. Сети token ring не работают, если цепочка их узлов не замкнута, потому что двигаясь по сети, информация перемещается по каждому из узлов. Я не знал этого до дня, когда решил устроить перестановку в своём кубикле. Когда я отключил свой терминал от сети, чтобы переставить его, половина сети вырубилась. В тот день коллеги не пылали ко мне особой любовью.
AIX и Ultrix, а также оборудование, на котором они работали, настолько различались, что наш код представлял собой мешанину операторов IF для AIX и для ULTRIX. Иногда нам приходилось писать отдельные версии целых подпроцедур и функций для AIX и Ultrix. Мы были вынуждены компилировать код дважды, отдельно для AIX и для Ultrix! Когда в 1995 году появился язык Java, он полностью изменил правила игры. Можно писать одну кодовую базу без зависящих от ОС и оборудования IF и отличающихся процедур, и код будет работать на любой машине, на которой можно запустить JVM? Да это же магия вуду!
В то время индустрия ПО была гораздо менее этносоциально разнообразной сферой. Все разработчики ПО в ACD были белыми мужчинами, большинство из них младше 35 лет. В QA ситуация была практически такой же, за исключением одной девушки. В компаниях не было людей с другим цветом кожи и иммигрантов. Говорить о своей ориентации на работе (да и во всех других местах) было небезопасно. Я знал, что один из технических писателей в моём отделе был геем, но узнал я это только потому, что мы стали друзьями и он решил рискнуть и рассказать мне об этом.
В команде разработчиков ПО было две должности: Software Engineer (разработчик ПО) и Senior Software Engineer (старший разработчик ПО). Это было типично для индустрии. Чтобы получить возможность повышения до сениора, нужно было иметь как минимум десять лет опыта работы разработчиком ПО, а чаще пятнадцать лет опыта. Планка требований к сениору тоже была выше, чем сегодня. Я бы сказал, что сениор-разработчик в те времена по уровню навыков и опыта был ближе к современному Staff Engineer (ведущему разработчику) или Principal Engineer (старшему разработчику).
Я был очень доволен ACD, мне нравилось там работать. Так как существовало лишь ограниченное количество телефонных компаний, у нас было около дюжины клиентов. Наши отношения с US Sprint всегда были ненадёжными, и однажды мы слишком разозлили компанию, она разорвала договор с нами и подначивала нас судиться из-за него. Потеря этого дохода подкосила нас, и это стало началом конца ACD. Компания начала постепенно умирать. Я не хотел оказаться безработным в Терре-Хот, поэтому нашёл работу в Индианаполисе и переехал. Тогда, как и сегодня, большинство разработчиков ПО Индианы работает в Индианаполисе.
Напоследок расскажу ещё одну историю про ACD, касающуюся US Sprint. Эта компания сердилась на нас за то, что слишком во многих релизах было много багов. Она отправила нам список всех багов, которые требовала устранить. US Sprint требовала, чтобы мы устранили их к понедельнику, иначе она купит продукт конкурента и уйдёт от нас. Отдел разработки днями и ночами работал над устранением этих багов. Они работали и в выходные, но на утро воскресенья не успели даже притронуться к паре особо явных багов.
Напомню, что нам приходилось отправлять код на физических носителях. Мы пользовались ленточными картриджами, которые были меньше кассеты VHS, но гораздо больше аудиокассеты.
Последний срок отправки Federal Express в воскресенье приближался, а инженеры по-прежнему не закончили работу. (Federal Express переименовали в FedEx только много лет спустя.) Тогда у кого-то появилась гениальная идея: отправить US Sprint пустую ленту с нашим обычным письмом, в котором перечисляются изменения в релизе. Так мы и поступили.
В понедельник нам позвонили из US Sprint: как бы они ни пытались, им не удавалось загрузить ПО с отправленной нами ленты. Отдел техподдержки был к этому готов: «Ох, просим прощения. Понятия не имеем, что могло произойти! Сегодня мы отправим ещё одну ленту».
К тому времени инженеры уже устранили эти последние два бага. Мы записали на новую ленту настоящий модифицированный релиз и отправили его в US Sprint. Компании снова удалось выжить!
Я хочу показать вам, насколько далеко ушла наша индустрия и сколь многому мы научились.
Логотип первой программной компании, в которой я работал. Изображение в низком разрешении, потому что компания закрылась в 1996 году, и это всё, что я смог найти в Интернете.
Первой компанией по разработке ПО, в которой я работал, была Applied Computing Devices из Терре-Хот, штат Индиана. В организации была куча невероятно умных людей, и с ними было интересно работать. Мы создавали ПО для управления телефонными сетями. Нашими клиентами были AT&T, US Sprint (теперь она называется просто Sprint), GTE (теперь Verizon) и множество региональных компаний-операторов Bell (компаний, занимающихся стационарными телефонами), в том числе Ameritech (которая обслуживала Индиану), BellSouth и Pacific Bell. Эти компании в основном предоставляли стационарные (на бизнес-жаргоне называвшиеся «wireline») телефонные услуги, но некоторые из них уже начали создавать подразделения для работы мобильной связью. Управлять всем этим было трудно, и наши программные продукты были относительно сложными. Чтобы понять некоторые элементы нашего ПО, мне требовались все мои знания курса математики колледжа.
Я был не разработчиком ПО, а техническим писателем. Я писал толстенные бумажные руководства, которые мы отправляли клиентам. В них объяснялось, как устанавливать, настраивать и использовать наше ПО. В те времена индустрия разработки ПО была очень маленькой, а когда я получил степень по математике/computer sciences, экономика находилась в упадке. Мне удавалось пройти не так уж много собеседований на должность кодера, а пройденные собеседования не завершались предложениями работы.
Летом, пока я искал работу, я жил в кампусе, но лето вскоре должно было закончиться и мне пришлось бы возвращаться домой и жить с отцом. Меня совершенно не привлекала эта перспектива, поэтому я решил диверсифицировать усилия и попробовать найти любую работу в программной компании: QA, техподдержка, ИТ, уборщик, кто угодно. Я решил, что потом уже разберусь.
Профессор моего колледжа знал людей из ACD и познакомил меня с ними. Им был нужен технический писатель. Я сказал, что с радостью возьмусь за работу, и они наняли меня за $23 000 в год (сегодня это примерно $54 000). К своему удивлению я обнаружил, что мне нравится писать тексты даже больше, чем писать код. Я научился очень хорошо объяснять пользователям работу нашего сложного технического ПО.
Здание ACD, теперь ставшее домом для Rose-Hulman Ventures
В этой статье я бы хотел рассказать, каково было там работать (параллельно испытывая трепет к своим сверхумным коллегам). В то время индустрия ПО была совершенно другой!
Многое из того, что мы сейчас воспринимаем как должное, ещё не существовало. Интернет существовал, но не было веба. Программное обеспечение доставлялось клиентам на лентах и гибких дисках. Устройство для записи компакт-дисков изобретут ещё через несколько лет. Java не существовало, JavaScript не существовало, .NET не существовало. Самыми используемыми языками были C/C++, FORTRAN, Pascal, Ada, Perl, Tcl и Lisp. А, и, разумеется, COBOL. Как-то летом я работал в колледже программистом на Pascal! Объектно-ориентированное программирование существовало, но было нишевым. Ведущим ОО-языком тогда был Smalltalk. Один из моих соседей по общежитию колледжа стал очень крупной фигурой в сообществе разработчиков на Smalltalk и даже писал книги про Smalltalk!
Кроме того, тогда ещё не существовало концепции распространения программного обеспечения по подписке. Компании платили за ПО наперёд и могли использовать купленный релиз бесконечно. Им приходилось платить повторно за крупные обновления. Некоторые хитрые компании растягивали платежи на несколько лет, но лицензия всё равно была пожизненной.
Когда мы отправляли клиентам по почте новую версию нашего продукта, большинство из них не устанавливало её сразу же, а некоторые вообще никогда не устанавливали её. «Нам вполне подходит версия, на которой мы работаем». Для техподдержки это было сущим кошмаром. В конечном итоге мы решили поддерживать только последние четыре версии, к крайнему раздражению наших клиентов, но к бесконечной благодарности нашего отдела поддержки.
Лучшей из имевшихся систем SDLC (systems development life cycle, жизненного цикла разработки ПО) была каскадная модель (водопад) со всеми её проблемами, которые коснулись нас даже тогда. Вся индустрия работала над очень долгими проектами релизов, например: два месяца на сбор требований и проектирование спецификации, затем девять месяцев кодинга, а далее три месяца тестирования. Даже если мы понимали (а большинство этого не понимало), что мелкие частые релизы во многих отношениях лучше, мы не могли реализовать такую систему. Отправка ПО на физических носителях была дорогостоящей операцией, а частые установки программ мешали бы работе наших клиентов.
В те времена мы думали, что проекты разработки ПО должны управляться как производственные или строительные проекты. Поэтому мы чертили огромные диаграммы Ганта (и распечатывали их на матричном принтере), а потом вешали на широкую стену и использовали их для сверки планов и выполнения работы. В первую неделю кодинга мы всегда выясняли, что не подумали о чём-то на этапе проектирования и нам приходилось перепланировать весь проект и печатать новые диаграммы Ганта. Мы делали это снова и снова для каждого проекта.
Когда код наконец добирался до QA, тестеры находили сотни или тысячи багов. Они почти не видели ПО до тех пор, пока оно не попадёт к ним в руки и их почти не задействовали на этапе создания. Из-за огромного объёма багов этап тестирования всегда требовал намного больше времени, чем было запланировано. Но к тому времени мы уже обещали клиентам, что отправим ПО к определённой дате, поэтому чтобы сдержать обещание, каждый релиз выпускался с целой кучей известных багов, которые мы устраняли в релизе, выпускавшемся несколько недель спустя (так называемом «fast follower»). Умные клиенты научились не устанавливать релиз, пока не появится «fast follower».
Из-за этого проекты всегда превращались в ужасные гонки на выживание со множеством часов переработки в будни и выходные перед датой релиза. Уровень выгорания был высоким. Но увольнялись из-за него очень немногие, потому что мы считали, что так и должно быть. Да и уходить было особо некуда: программных компаний существовало мало, и в них тоже возникали такие гонки на выживание.
Технологический стек (этого термина тогда ещё не существовало) компании ACD состоял из C++ на двух разновидностях UNIX: Ultrix корпорации Digital Equipment Corporation и AIX компании IBM. Наше ПО работало на миникомпьютерах DEC и IBM с архитектурой RISC, эти машины были размером с морозильную камеру. Целая куча таких компьютеров стояла в большой прохладной серверной. Так как компания находилась на задворках Терре-Хот, электричество нам поставлял сельский энергетический кооператив, и питание было не особо надёжным. Не знаю, почему у нас не было бесперебойных источников питания или генератора, никто их не покупал. Примерно раз в месяц происходило кратковременное отключение электричества. Миникомпьютеры были соединены в последовательную цепочку и должны были загружаться по порядку. Для загрузки одной машины требовалось около десяти минут. Для завершения загрузки всех компьютеров приходилось ждать больше трёх часов. Если перепад напряжения происходил примерно после 14 часов, мы просто уходили домой на весь оставшийся день.
Удалённой работы и работы из дома ещё не существовало. На миникомпьютерах можно было работать только в офисной сети. Я думаю, технически возможно было подключить их к Интернету, однако дома у всех нас был только коммутируемый доступ. Проблема заключалась бы не только в скорости, но и в том, что семьи не были бы рады, что пока мы работаем, телефонная линия постоянно занята.
У каждого разработчика на столе стоял терминал, с которого они делали всё. Поначалу все инженеры работали на знаменитых терминалах VT100, но позже компания купила им огромные графические терминалы за $2000, чтобы те могли создавать UI в X Windows. Тогда понятия «дизайн UX» ещё не существовало, поэтому не было разделения на разработку фронтенда и бэкенда. Интерфейс пользователя проектировали разработчики ПО, и большинство из них справлялось с этим не очень хорошо.
Я работал техническим писателем, поэтому у меня был Macintosh II с System 6 (System — это предыдущее название MacOS) и 8 МБ ОЗУ. Для того времени это была мощнейшая машина. Я писал руководства в программе Interleaf. Для подключения к миникомпьютерам я использовал эмулятор терминала на Mac.
В то время разворачивались холивары о текстовых редакторах. IDE ещё не существовало, поэтому все мы писали код в текстовом редакторе. Я был сторонником Emacs, однако большинство моих коллег любило vi.
Наши терминалы были соединены в сеть token ring, связывающуюся с этими миникомпьютерами. Сети token ring не работают, если цепочка их узлов не замкнута, потому что двигаясь по сети, информация перемещается по каждому из узлов. Я не знал этого до дня, когда решил устроить перестановку в своём кубикле. Когда я отключил свой терминал от сети, чтобы переставить его, половина сети вырубилась. В тот день коллеги не пылали ко мне особой любовью.
AIX и Ultrix, а также оборудование, на котором они работали, настолько различались, что наш код представлял собой мешанину операторов IF для AIX и для ULTRIX. Иногда нам приходилось писать отдельные версии целых подпроцедур и функций для AIX и Ultrix. Мы были вынуждены компилировать код дважды, отдельно для AIX и для Ultrix! Когда в 1995 году появился язык Java, он полностью изменил правила игры. Можно писать одну кодовую базу без зависящих от ОС и оборудования IF и отличающихся процедур, и код будет работать на любой машине, на которой можно запустить JVM? Да это же магия вуду!
В то время индустрия ПО была гораздо менее этносоциально разнообразной сферой. Все разработчики ПО в ACD были белыми мужчинами, большинство из них младше 35 лет. В QA ситуация была практически такой же, за исключением одной девушки. В компаниях не было людей с другим цветом кожи и иммигрантов. Говорить о своей ориентации на работе (да и во всех других местах) было небезопасно. Я знал, что один из технических писателей в моём отделе был геем, но узнал я это только потому, что мы стали друзьями и он решил рискнуть и рассказать мне об этом.
В команде разработчиков ПО было две должности: Software Engineer (разработчик ПО) и Senior Software Engineer (старший разработчик ПО). Это было типично для индустрии. Чтобы получить возможность повышения до сениора, нужно было иметь как минимум десять лет опыта работы разработчиком ПО, а чаще пятнадцать лет опыта. Планка требований к сениору тоже была выше, чем сегодня. Я бы сказал, что сениор-разработчик в те времена по уровню навыков и опыта был ближе к современному Staff Engineer (ведущему разработчику) или Principal Engineer (старшему разработчику).
Я был очень доволен ACD, мне нравилось там работать. Так как существовало лишь ограниченное количество телефонных компаний, у нас было около дюжины клиентов. Наши отношения с US Sprint всегда были ненадёжными, и однажды мы слишком разозлили компанию, она разорвала договор с нами и подначивала нас судиться из-за него. Потеря этого дохода подкосила нас, и это стало началом конца ACD. Компания начала постепенно умирать. Я не хотел оказаться безработным в Терре-Хот, поэтому нашёл работу в Индианаполисе и переехал. Тогда, как и сегодня, большинство разработчиков ПО Индианы работает в Индианаполисе.
Напоследок расскажу ещё одну историю про ACD, касающуюся US Sprint. Эта компания сердилась на нас за то, что слишком во многих релизах было много багов. Она отправила нам список всех багов, которые требовала устранить. US Sprint требовала, чтобы мы устранили их к понедельнику, иначе она купит продукт конкурента и уйдёт от нас. Отдел разработки днями и ночами работал над устранением этих багов. Они работали и в выходные, но на утро воскресенья не успели даже притронуться к паре особо явных багов.
Напомню, что нам приходилось отправлять код на физических носителях. Мы пользовались ленточными картриджами, которые были меньше кассеты VHS, но гораздо больше аудиокассеты.
Последний срок отправки Federal Express в воскресенье приближался, а инженеры по-прежнему не закончили работу. (Federal Express переименовали в FedEx только много лет спустя.) Тогда у кого-то появилась гениальная идея: отправить US Sprint пустую ленту с нашим обычным письмом, в котором перечисляются изменения в релизе. Так мы и поступили.
В понедельник нам позвонили из US Sprint: как бы они ни пытались, им не удавалось загрузить ПО с отправленной нами ленты. Отдел техподдержки был к этому готов: «Ох, просим прощения. Понятия не имеем, что могло произойти! Сегодня мы отправим ещё одну ленту».
К тому времени инженеры уже устранили эти последние два бага. Мы записали на новую ленту настоящий модифицированный релиз и отправили его в US Sprint. Компании снова удалось выжить!
