Про програмування на ЕОМ в 1970-х, курсові на перфокартах і роботу в «лихі 90-ті». Історія розробника, який уже 40 років в IT

62-річний Михайло Стрелков уже 40 років в IT. Нині працює керівником проєктів групи розробки ETL УРВІС AT UKRSIBBANK BNP Paribas Group. До цього був програмістом в інших банках, у науковому інституті та на військовому об’єкті. Михайло почав програмувати у 1970-х, кодував ще на Algol 60 і Fortran 4. Щоб працювати з ЕОМ, у студентські роки доводилося використовувати знайомства, а потім на робочому місці чекати своєї черги за розкладом.

Ми попросили розробника поділитися спогадами про IT у 1970–90 роки: де і як вчили програмістів, які були мови програмування, комп’ютери, як вдалося залишитися у професії в «лихі 90-ті»? У статті Михайло розповів і про те, якою роботою найбільше пишається за всі 40 років в індустрії.

З дружиною біля фонтана Треві

Навчання в університеті: «ЕОМ була в спецприміщенні з обмеженим доступом, і ніхто зі студентів її жодного разу не бачив»

Яке було ІТ в 1970–90-ті? Ну, по-перше, самої абревіатури «ІТ» тоді ще й не було. Принаймні я не чув. Там, де я починав, у 1982 році були «програмісти» й «електронщики», які відповідали за «залізо» й ОС, тобто адміни. Де і як навчали цих професій? Електронників — не знаю, мабуть, у політехах, на програмістів ніде не вчили.

Я закінчив мехмат ХНУ, спеціальність — прикладна математика. І йшов туди саме для того, щоб вчити програмування. У школі моїми улюбленими предметами були математика та фізика, хоча більше я розумівся саме на фізиці. В той час був журнал «Квант», який видавав для школярів Московський фізико-технічний інститут. У ньому друкувалися матеріали для поглибленого вивчення математики, підготовки до вступних іспитів на серйозному рівні тощо. І там я натрапив на статтю про програмування, де було написано, що його нині викладають тільки на мехматах, на відділеннях прикладної математики. Я подумав, що це цікаво, і вирішив вступати на мехмат до харківського університету. До того ж цей факультет був дуже потужним, з науковою традицією, яка тягнеться з XIX століття. До речі, моя дружина теж закінчила прикладну математику, тільки в ХАІ, працювала програмісткою деякий час, але потім перейшла у бухгалтерію. Двоє дітей з трьох теж в IT, а тепер і внучка збирається вчитися програмування.

Отже, у 1977 році на першому курсі в ХНУ ми трохи вивчали алгол 60 — це, мабуть, одна з перших високорівневих мов програмування. Там були глобальні та локальні змінні, блоки begin/end. Напевно, алгол 60 найбільше схожий на Pascal, але той просунутіший, там уже з’явилися нові різні фічі. На алголі ми майже не програмували, вивчали його на дошці та папері, писали на листочках програмки, але в комп’ютер не заводили. Чому так? Для студентів це була саме навчальна програма, бо алгол суворий, типізований. А десь ним точно користувались. Пізніше Pascal став стандартною та найкращою мовою програмування для навчання студентів. Цю мову обрали насамперед для того, щоб навчити правильно мислити. Нині у цьому ключі я б віддав перевагу Python.

На другому курсі ми вивчали Fortran 4 (Fortran — скорочення від The IBM Mathematical Formula Translating System). Ця мова програмування була створена спеціально для науковців і добре підходила для їхніх цілей. Там не було типів даних на кшталт рядкових, нічого зайвого — тільки числові дані, але підтримувалися навіть комплексні числа.

Отож ми вивчали Algol 60 на першому курсі та Fortran 4 на другому. І це все. Далі були обчислювальні методи, за якими треба було реалізовувати курсові на Fortran.

До речі, програми писали на папері та віддавали в перфораторну, де вони перетворювалися на пачки перфокарт, які потоком потрапляли у зчитувальний пристрій ЕОМ

ЕОМ була в спецприміщенні з обмеженим доступом, і ніхто зі студентів жодного разу її не бачив. Студенти отримували через кілька днів свої колоди перфокарт і стрічки роздруківок.

Ну, самі розумієте, будь-яка помилка в коді — метри паперу з помилками й іноді дампами пам’яті. Хочеш щось виправити — починай спочатку. Тому швидко всі навчились за допомогою леза та лузги від дірочок у перфокартах виправляти помилки прямо в них. А що тут складного? У перфокарті 8 рядків — це біти, стовпець — байт. Стовпців-байтів на перфокарті, здається, 80. Дірочка є — це 1, немає — 0. Там, де треба з 0 зробити 1, акуратно прорізаєш дірочку, а де навпаки, береш зі сміття вибитий шматочок з перфокарти та втискуєш у непотрібну дірочку. Вони там міцно тримались, бо то був високоякісний картон, хоч і тонкий (його потім ще років 10–15 використовували як закладки до книжок).

Такий вигляд мали перфокарти. Джерело

Я вперше побачив ЕОМ на третьому чи четвертому курсі, коли треба було зробити курсову. Як зазвичай буває, дотягнув до останнього, і один з товаришів, у якого родич працював на металобазі, де була ЕОМ, домовився, щоб нас пустили туди на одну ніч. Там була величезна залізяка, більша за сучасні мейнфрейми IBM, вона блимала сотнями лампочок (насправді кожна з них — то окремі біти регістрів, і якщо ЕОМ зависає, то за цими лампочками можна зрозуміти, в якому вони стані), гула вентиляторами, стрекотала принтером...

Це був кайф. А всього там було приблизно 32К оперативної пам’яті. Ця одна ніч поруч з комп’ютером дала більше, ніж всі ці прорізування та забивання дірочок у перфокартах протягом року. Бо, чесно кажучи, до 3–4 курсу це вже добряче набридло. Свої курсові ми успішно здали.

Ще трохи про мови програмування: «На адаптацію до алгоритмічного мислення у мене пішло, мабуть, тижня два чи три»

Пізніше, уже наприкінці 1980-х, я зіткнувся з PL/I. Це була потужна мова, таке собі поєднання Fortran з Algol. Там уже були всі блокові конструкції, розвинуті цикли. У Fortran 4 були тільки найпростіші цикли, коли задавалося перше значення, кінцеве значення та крок. А у PL/I — уже нормальні do-while цикли, різні типи даних. Можливо, це була остання мова перед об’єктноорієнтованими.

Взагалі, першою об’єктноорієнтованою мовою вважають Ada. Вона названа на честь Ади Лавлейс, дочки лорда Байрона, яку визнають першою програмісткою у світі. Вона писала код за допомогою всіляких стрічок у XIX столітті. Мова Ada була створена на замовлення військових у США. Не знаю, як її використовували на практиці, я про неї тільки читав. Нині я працюю з Oracle, в якій є вбудована мова PL/SQL. Кажуть, що вона була зроблена на основі Ada. Вже на початку 1990-х я трошки програмував на C. C++ тоді ще не було, мова C# ще пізніше виникла у США.

Цікаве спостереження щодо вивчення мов програмування. Важко було ламати «математичний спосіб мислення», коли є формули або твердження (теореми, тощо), які пов’язані між собою логічно, але не має значення порядок їх використання, і переходити на «алгоритмічний спосіб мислення», де саме порядок виконання і є найголовнішим. І вираз на зразок «X=X+1» є цілком нормальною конструкцією, бо «=» — це не «дорівнює», як у математиці, а означає «призначити». Але спочатку це викликало шок. На адаптацію до такого алгоритмічного мислення у мене пішло, мабуть, тижня два чи три. А найцікавіше, що коли через 20 років я почав вивчати SQL, що є декларативною мовою, то на зворотну адаптацію з алгоритмічного мислення, зі всіма цими if-then-else, do-while тощо, на мислення декларативне: що взяти (select), звідкіля (from), за яких умов (where) тощо, часу знадобилося значно більше. Мабуть, місяці два чи три. Увесь час тягло на цей if-then-else. Знаю деяких колег-програмістів, які так і не змогли перемкнути свій спосіб мислення з алгоритмічного на декларативний. Слава богу, тепер у мене є PL/SQL, мова, яка поєднує і те, і інше.

Перша робота: «Нам дали величезний окремий магнітний диск на 100 Мб — нечуваний обсяг!»

Я випустився з ХНУ 1983 року. Звісно, тоді професія програміста була зовсім не масова. Так, наше відділення прикладної математики випускало за рік три групи, всього людей 60. Приблизно 60–70 % йшли працювати програмістами. Тобто дуже мало. Але у більшій кількості фахівців і не було потреби. На той час, крім науковців і військових, майже ніхто не використовував комп’ютери, хіба ще були бухгалтерські програми. Я потрапив на військовий об’єкт: там справді було класне «залізо», було все, щоб розвиватися.

Ще на останньому курсі університету я вже працював на підприємстві «Електроприлад» (сьогодні «Хартрон»), де розробляли програмне забезпечення та «залізо» для космосу, військових тощо. У народі це підприємство прозвали «67-й ящик». Чому так? Військові підприємства в СРСР не мали військових назв, тільки цивільні для маскування (КБ «Електроприлад») і секретні військові номери — поштові скриньки, яких ніхто не повинен був знати. Але весь Харків знав :)

Похід на байдарках. Друзі майже всі з «Електроприладу». І майже всі теж айтішники. 1982–1985 рр.

Спочатку я там проходив переддипломну практику, а потім уже захистив диплом і перейшов у штат. Щодо зарплати, то складно порівнювати. У нашому відділі всі вважалися інженерами, незалежно від спеціалізації. Тож не знаю, яку платню отримували інші програмісти, але саме «Електроприлад» давав ставку для молодих фахівців вищу, ніж у середньому в галузі у Харкові. Так, скажімо, інженер (необов’язково програміст, будь-який інженер) після закінчення вишу зазвичай отримував 110–120 рублів на місяць, нам же відразу дали 150. Це була суттєва різниця.

Отже, на першій роботі я вже міг щодня насолоджуватись майже власною (вона була одна на відділ) супер-ЕОМ — ЄС-1060 — точною копією IBM System 360/370. А що ви хотіли :) У СРСР навіть моторолер «В’ятка» був близнюком чогось італійського. Була, щоправда, така собі «БЭСМ-6», казали, що це чисто єреванська розробка, але не дуже віриться. За розміром ця ЄС («Єдина система» — загальна назва родини великих ЕОМ в СРСР) була як шафа, завширшки метр, заввишки два метри та завдовжки метрів 5–6. Ну й, звичайно, з лампочками та кнопочками. До речі, щоб її ввімкнути та завантажити, треба було на консолі виконати 15–20 різних команд, які задавали певні параметри ОС. А перезавантажувати доводилось часто, бо нерідко вона зависала.

А якось одного дуже спекотного літа вона взагалі не хотіла працювати, попри те, що вентилятори гули, як літаки в аеропорту. Спеціалісти домовились працювати ночами, бо був, як тепер кажуть, дедлайн на носі. Після цього я код уночі категорично не пишу. Бо те, що тоді написав за кілька ночей, потім виправляв два тижні й дуже обурювався на «того ідіота», який це зробив. На щастя, спека спала, а дедлайн посунули.

Як ми працювали? Був один монітор, під’єднаний до цієї великої ЕОМ, на трьох-чотирьох програмістів

Тому була черга, розклад, і сідали за нього з чітко розпланованою роботою на призначені півтори чи дві години. А в інший час готуйся, є папір — пиши код або розбирайся за лістингами з помилками. Звичайно, іноді була «дідівщина», коли старший і поважний колега міг зігнати молодого в його час, бо «у мене серйозні речі, а ти тут граєшся».

Ще зупинюся на обсягах даних. На наш проєкт, в якому брали участь 5–7 фахівців, дали окремий величезний магнітний диск, здається, на 100 Мб. Нечуваний обсяг! Там було все. Всі наші програми з усіма версіями, а їх було сотні, і всі файли даних до них. Це був такий круглячок у діаметрі приблизно 50 сантиметрів, набраний з окремих дисків, завтовшки 25–30 сантиметрів. Він вставлявся зверху в спеціальний «дисковод». Це була така собі тумбочка заввишки 60–70 сантиметрів, інші сторони теж 60 на 60. Але на той час це було дуже круто, бо деякі колеги, які працювали на інших проєктах, використовували вже згадану раніше «БЭСМ-6», і в них все було суто на магнітних стрічках. І якщо порівнювати з перфокартами, які були в універі, це теж було потужно.

Що я там робив? Спочатку то були переддипломна практика і дипломна робота. І саме тоді я нарешті відчув себе справжнім програмістом. Бо завдання для диплома я мав непросте: треба було, аналізуючи код багатьох модулів на Fortran, автоматично сформувати та надрукувати інформаційні схеми обміну даними між ними (те, що тоді називалося HIPO-діаграмами). Для цього треба було парсити код, знаходити там глобальні змінні, визначати, як вони там використовуються тощо. Тобто за складністю це був майже компілятор, точніше його значна частина. Звичайно, на Fortran 4 такого не втнеш, там навіть не було текстових типів даних.

Тому використовував асемблер і Fortran для друку. Це було круто! Щоправда, старші колеги тільки хмикали, бо вони колись писали ще в машинних кодах. А асемблер, якщо порівнювати з машинними кодами, — цукерка! Там же команди та фрагменти пам’яті (те, що в мовах високого рівня називають змінними, константами тощо) мають справжні імена, а не просто набори бітів з 1 та 0. Асемблер мені потім ніколи не знадобився, але це допомогло добре розібратися, як працює комп’ютер зсередини.

Після закінчення універу та переходу в штат отримав перше серйозне завдання: побудувати модель руху автоматично керованого літального апарата. Там були моделі руху центра мас, руху навкруги центра мас, двигунів, закрилок тощо. Але... Як випускнику мехмату мені довірили тільки кодування. Тобто інші колеги, які були розробниками (алгоритмістами, до речі, забув про них згадати на початку як про частину ІТ разом з програмістами, електронниками й адмінами, даруйте), малювали алгоритми у вигляді блок-схем, а мені треба було тупо все це кодувати на Fortran. Але такого я витримати не міг, тому весь час намагався розібратися в цих блок-схемах. І передусім старався контролювати, щоб десь не вилізла якась непроініційована (тобто без значення) змінна. А там такого було хоч греблю гати, і я набігав не одну марафонську дистанцію до кімнати з розробниками, коли намагався щодо кожного випадку з’ясовувати, що це таке.

Це побачив один старший колега, який уже декілька разів безрезультатно намагався пояснити керівництву, що ці алгоритми в принципі неробочі й вони ніколи не будуть працювати. Він спитав мене, чи я справді закінчив мехмат, і запропонував попрацювати трохи «по-партизанськи». За тиждень видав мені алгоритм з 10 сторінок (те, що я намагався закодувати перед цим, були три чи чотири книги формату А4 завтовшки 10 сантиметрів). На першій сторінці великими блоками був сформований так званий диспетчер (основний цикл з викликами відповідних моделей і блоком автоматичного вибору кроку інтегрування). А на інших — системи диференціальних та інтегральних рівнянь, які й були відповідними моделями. І я реалізував усе це на Fortran, але вже не як кодер, а як розробник і математик. Здебільшого займався цим увечері, щоб не бачило керівництво. Коли ми представили результат керівнику, він спочатку трохи потупав ногами за самодіяльність, але потім визнав, що мій колега мав рацію і що у нас вийшла класна програма. Вона лягла в основу одного з елементів системи, яку ми розробляли.

nn-річчя нашої лабораторії 343 з «Електроприладу», початок 2000-х

Друга робота: «Кайфово розуміти: я створив таке, що проіснувало багато років»

На «Електроприладі» я затримався років на 5, а потім перейшов у Харківський фізико-технічний інститут. Тут я працював 6–7 років, хоч за останні 2–3 роки вже почався розвал через відсутність фінансування науки у 1990-ті. Але у 1985–89 роках у мене була дуже цікава робота. Я фактично став архітектором і головним програмістом на проєкті розробки системи моделювання та проєктування так званого накопичувача-розтягувача електронів (НР), це такий різновид циклічних прискорювачів. Там був потужний колектив фізиків, які виконували числове моделювання на тому ж Fortran. Вони створили безліч різних моделей різних елементів цього прискорювача, але самі в них заплутались, тож інтегрувати все це в одну модель НР було складно, процес займав багато часу. А треба було побудувати сотні таких інтегрованих моделей, щоб вийти на потрібні параметри пучка електронів. От мені й доручили зробити для цього систему.

Те, що в нас вийшло, — це найкраще з моїх досягнень за все життя в ІТ. Я насправді вважаю так. Я розробив чітку систему стандартів кодування (шаблонів) для фізиків, скриптову систему команд управління і таку ж скриптову мову вибору та конфігурації елементів прискорювача в інтегровану модель. Створення нової моделі стало займати кілька хвилин без будь-якого програмування. Всі нові моделі окремих елементів, розроблені фізиками за нашими шаблонами, інтегрувались у систему дуже легко.

У процесі розробки, коли було реалізовано вже 70–80 %, шеф приніс доку на аналогічну американську систему, яка коштувала 500 тис. доларів

Ми подивились і побачили, що системи схожі за ідеологією. Щось було краще в американців, а щось у нас, від чого керівник був у захваті. Ця програма і результати, отримані за її допомогою, були представлені на багатьох міжнародних конференціях і сприяли захисту декількох кандидатських дисертацій. Але я, як дуже ледача людина (якою і повинен бути програміст), цим не займався, бо занадто це клопітлива та бюрократична справа — написання і захист дисертації. Тим паче, що «недовго грала музика» — почалися 1990-ті.

Але коли вже років за 20 я випадково зустрів деяких колишніх колег, то з подивом дізнався, що наша програма і досі працює. Вони перевели її з Fortran 77 на С++, з ЄС — на персоналку, але вся архітектура залишилася. І це справді кайфово розуміти, що ти створив щось таке, що проіснувало вже стільки років, живе та розвивається без твоєї участі. Не знаю, може, і нині ця програма діє.

1990-ті: «Можливо, було простіше піти на ринок торгувати, але для мене завжди було цікавим програмування»

Але все ж таки почались 1990-ті. СРСР розпався, Україна отримала незалежність — це плюс. Але завершилось фінансування науки — це мінус. Долар полетів у космос, рубль (чи що там тоді було) — навпаки. Затримки зарплати, яка стала дорівнювати 5–7 доларам, досягали кількох місяців. Деякі провідні фахівці отримали гранти від Сороса та вижили як вчені. Велика подяка йому за це.

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

Загалом у 1990-ті бувало все що завгодно — як на Дикому Заході у XIX столітті. Особливо було важко перші роки, потім стало простіше. Цікава історія трапилася у 1991–92 роках у Харківському фізико-технічному інституті. Тоді якраз з’являлись усі ці кооперативчики, які шили одяг. Бо у часи СРСР у Харкові була одна-єдина швейна фабрика імені Тінякова. Але ніхто не хотів носити те, що там виробляли. У 1990-ті ж вибір став більшим, можна було купити одяг на ринку. Особливо популярними стали різноманітні сукні, кофтинки з вишивкою. У нас в інституті був хлопець, дуже талановитий фізик, який гарно розумівся на електроніці, міг спаяти будь-що. І він задумав зробити автоматичний прилад для того, щоб вишивати візерунки на тканині. Японських швейних машинок з програмуванням, звичайно, ще не було. Ідея була така: на рамку натягується тканина, вона встановлюється під машинку, яка управляється програмою, а за допомогою неї можна задавати якийсь візерунок або надпис.

Цей фізик задумав таку штуку як електронник, мене взяв програмістом й іншого хлопця інженером, щоб сконструювати сам прилад. Свою частину фізик зробив швидко. Я ж не досить добре знав ситуацію та почав проєктувати щось глобальне — нову мову програмування спеціально для управління цим станком, продумував усі команди тощо, а треба було робити простіше й оперативніше. Я показав фізику, що виходить. Він глянув і сказав: «Гарно, але якщо це треба доробляти ще пів року, то виходить дуже довго». Другий хлопець-інженер теж не зовсім збагнув замисел. Мабуть, там, де він працював, були великі верстати, бо деталі, які в нього вийшли, більше підходили для автомобіля. Механізм вийшов могутнім, дуже важким, інерційним.

Через пів року я зайшов у гості до цього фізика. А він, виявляється, не здався, сам на колінках усе довів до кінця. Показав мені, як його жінка працює за цим приладом. Так, там доводилося два чи три дні кодувати візерунок, але потім машинка вишивала картинку за 15–20 хвилин.

Взагалі, народ займався чим завгодно — хто що вмів. Держсектор розвалювався, тривала приватизація, створювались маленькі приватні магазинчики, фірмочки, змінювались закони та правила бухгалтерського обліку. Всім потрібні були бухгалтери, а бухгалтерам якесь ПЗ, якого раніше не було. Найбільш популярними тоді стали Clipper, FoxPro, частково Clarion. Вони були схожими на Access: своя маленька БД з кількох DBF-файлів (крім Clarion, там був власний формат БД) і можливість швидко створювати притомний псевдографічний інтерфейс для користувачів (хто заглядав у кодову сторінку ASCII CP866, той бачив там багато різних стрічок, кутків, хрестиків тощо — от з них і складались таблички та кнопочки в інтерфейсах). Я, звичайно, теж цим займався.

Тоді сталася одна невдача, яка все ж пішла на користь, бо дуже просунула мене в розумінні перспективності справжніх реляційних БД

Була одна шабашка: ми робили бухгалтерську систему для вишу на Clipper. Складна логіка, безліч різних умов, коефіцієнтів, жахливо складні алгоритми нарахування зарплат, лікарняних тощо. Але ми зробили її за кілька місяців. Усе працювало, поки нас не попросили доробити її так, щоб з нею могли працювати одночасно кілька бухгалтерів. А в Clipper було якесь блокування на рівні таблиць і рядків, здається. І все. Наш код збільшився за обсягом у 3–4 рази. Програма стала працювати дуже погано, постійно або хтось комусь заважав, або взагалі псував чужі дані. Замовник був незадоволений.

Після кількамісячних страждань ми були змушені здатися і відмовитись від продовження розробки. А коли у 2001–2002 роках мені довелось вперше написати програму в БД Oracle на PL/SQL, якою повинні були послуговуватися декілька десятків користувачів одночасно, я взагалі нічого не робив, щоб забезпечити їхню роботу. Все зробила Oracle сама. До речі, у дискусії, яка почалась на початку 2000-х, де краще реалізовувати бізнес-логіку: в БД її засобами чи в «аплікухах» (Application server), я завжди наводжу цей приклад. Панове програмісти, в сучасних БД на зразок Oracle закладено стільки інтелекту та ресурсів, щоб забезпечити цю багатокористувацьку роботу, можливість відкатів, найвищу надійність тощо, що, коли хтось каже, що може все це зробити у своїй «аплікусі на колінках», я тільки регочу.

Ще кілька слів про «залізо» в 1990-ті. Була серія міні-ЕОМ СМ, був VAX. Ну й PC уже з’явились. Але це на фірмах. А вдома королем був славетний ZX Spectrum фірми Sinclair Research на базі процесора Z80. Це була бомба! Всього від 32 до 64К ОЗУ, без диска та монітора. Замість них — касетний магнітофон і телевізор. До ZX Spectrum купа іграшок на цих касетах. Але головне, що це клондайк для любителів програмування. Була ціла книжка з усіма вихідними кодами на асемблері ядра ОС та інтерпретатора BASIC. Усе відкрито та доступно. Я вже був тоді завеликий і надто зайнятий, щоб дуже гратися ZX Spectrum, але знаю крутих програмістів, яким зараз плюс-мінус 40, котрі починали саме з нього у дитячому віці.




Перехід до банку: «Охочих було набагато більше, ніж вакансій»

Банки — це наше все! Саме про роботу в банку мріяли програмісти у 1990-ті, бо там платили пристойні гроші, причому «по-білому» й узагалі були людські умови роботи та серйозний рівень розробки. Банки з’являлись як гриби, але спробуй туди потрапити, бо охочих було набагато більше, ніж вакансій. Приблизно у 1992–93 році влаштувався в одну контору типу «Роги та копита» (працювала на ринку цінних паперів, цінність яких була така собі), але там ознайомився з Clarion. І ці знання допомогли мені потрапити в банк, бо там була АБС (автоматизована банківська система) саме на ньому, а Clarion був не такий популярний і масовий, як той же Clipper чи FoxPro (останній і потім ще довго тримався).

З того часу почалась моя робота в банках з перервою в рік, коли мій перший банк розвалився (чи його розвалили) і довелося знову шабашити. Щоправда, вже на іншому рівні, бо я знався на банківських системах та Clarion. А він був, можливо, першою системою, яка дозволяла дуже швидко без написання коду розробляти продукт з власною БД і доволі приємним інтерфейсом. Приблизно за тим же принципом, що й Delphi, яка пізніше й зайняла цю нішу. І я, розробивши дві програми на Clarion на дуже популярні тоді теми «Банківська платіжка» та «Товарний склад», почав сам активно шукати клієнтів серед власників приватних магазинів і продавати свої програми з подальшим сапортом. Все було майже ок: прилаштував десь одну «Платіжку», а в іншому місці один «Склад». Перша програма вийшла дуже клієнтоорієнтованою. Мені вдалося зробити так, що бухгалтер набирав щоразу не більше як одне слово, бо те, що він писав раніше, запам’ятовувалось і потім підтягувалось; також там був швидкий пошук. А ось «Склад» був не таким універсальним, його довелося суттєво переробити.

Але згодом з’ясувалося, що «сапорт» це дуже широке поняття: від заправки принтера до встановлення та налаштування ОС на домашньому PC дитинки власника магазина. Чисто за харчі

Тому знову почав шукати банк, знайшов найближчий до дому, потім перейшов в інший, в якому з 2001 року й працюю.

Ну а далі 2000-ні. Саме тоді я почав у банку працювати з БД Oracle, що роблю й досі та не жалкую. Саме про неї і буде повчальна історія. У нас уже було своє сховище даних на Oracle, але самописне, а керівництво завжди хоче чогось покупного. Тому запросили хлопців з київської компанії RStyle, щоб вони продемонстрували своє промислове сховище. Нам треба було наповнити його даними з нашого сховища. Але не один в один, а з суттєвими трансформаціями. Тобто треба було з кількох наших таблиць зробити кілька їхніх, але з іншою структурою. Інакше кажучи, дані повинні були бути ідентичними за змістом, але у сховищах вони розміщувалися в таблицях, які відрізнялися за складом і структурою. Це звичне явище для БД, бо варіантів організації структур є безліч.

Тому нам треба було не просто перенести наші дані до їхнього сховища «як є», а при цьому змінити їхні структури. Наприклад, одну нашу таблицю поділити на дві, як у них, або з п’яти наших зробити одну їхню за допомогою з’єднань та інших модифікацій (щось агрегувати, щось порахувати тощо). Особливо важкою в них була одна дуже широка та довга таблиця, що формувалася з кількох наших, серед яких траплялися теж немаленькі (приблизно по кілька сотень мільйонів записів).

Я тоді ще нічого не розумів в Oracle, трохи писав на Java й активно вивчав її, бо гуру на цьому проєкті був саме джавіст і реально крутий. От він і зайнявся цим завданням — наповненням їхнього сховища даними з нашого, за кілька днів написав код на Java. Запустили у понеділок, а презентація для поважних осіб була призначена на п’ятницю.

Працює ця програма добу, другу, третю... Тобто у середу все ще працює. Дивимось в їхню БД, а там тільки відсотків 10 даних заїхало. Отакої! Ми шоковані. Розуміємо, що не встигнемо, і зриваємо презентацію. І тут хлопчина з тієї компанії, оракліст (їхня БД теж на Oracle) каже: «Гаразд». Зупиняє ту програму, залінковує бази, сідає за комп — і за пів години пише скрипт на SQL. На зразок INSERT INTO, таблиця SELECT... І той SELECT на 2–3 екрани, в якому безліч дужок і різних цікавих слів: from, where, group by, order by, having тощо (join у тій версії Oracle ще не було, замість нього — where) і всі наші вхідні таблиці. Запускає скрипт на виконання. Чекаємо. Минає 15–20 хвилин. Закінчився. Дивимось у БД — усі дані перенеслися на потрібні місця. 10 % за три доби на Java, 100 % за 20 хвилин на Oracle. Що б ви зробили? Я взяв свою товстенну книгу з Java (здається, вони завжди такими були) і засунув якомога далі на книжкову полицю. А цей скрипт роздрукував, повісив на стіну над своїм столом і за ним почав вивчати SQL. Амінь. Хай хтось спробує переконати мене, що для роботи з великими обсягами структурованих табличних даних є щось краще за якісну реляційну БД, ще раз порегочу.

Історія ІТ від 1980-х до початку 2000-х у книгах

Михайло поділився фотографіями зі своєї колекції книжок з програмування та загалом ІТ. Він почав збирати їх ще в університеті, відтоді поповнював колекцію, лише останні років 5 перестав — інтернету вистачає. Скільки їх — не рахував: каже, таких полиць, як на першому фото, 4–5. Михайло розповідає, що у 1980-х книжок було набагато менше, ніж сьогодні, хоча теж достатньо. Були вони доволі дешеві, особливо тоненькі в м’яких обкладинках, тому купував майже все, що траплялося і видавалося цікавим (а цікавим тоді було майже все). В 1990-х було складніше в усіх сенсах, тому купував тільки те, що вкрай необхідно, а з появою інтернету перейшов здебільшого на «самвидав». Більшу частину колекції прочитав, як кажуть, «по діагоналі», тобто зупинявся на окремих фрагментах. Але деякі книги ставали на певний період настільними.















Висновки за довгі роки роботи в IT: «Треба бути готовими до постійного самонавчання»

І насамкінець, як заведено, побажання тим, хто дочитав до цього місця, особливо початківцям в IT. Панове, якщо хочете пробути тут довго, треба бути готовими до постійного самонавчання. Бо всі ці технології змінюються з шаленою швидкістю і випасти з професії легко. Просто одного дня зрозумієте, що ваш шалений досвід, набутий за декілька років, уже нікому не потрібен і треба починати майже з початку. А щоб не зовсім з початку, потрібно мати надійну базу. Для мене нею став мехмат університету, де мізки прокачують так, що багато чого потім здається дитячою забавкою. Хоча, як я казав на початку, конкретних знань в ІТ виш майже не дав. Але то було тоді, нині уже є й окремі IT-спеціальності.

Тепер щодо актуальних дискусій на тему «що краще?»: умовно «код-картинка» — хороший код — чи, перепрошую, «говнокод» (але саме такий термін використовують в IT сьогодні). На жаль, правда в тому, що перший ніхто не оцінить, бо він завжди виходить коротенький, хоча довго пишеться і добре працює. А з другим усе навпаки, тому за нього платять більше. І сапортити його вигідніше, бо постійно щось ламається, і клієнт вас любить, і гроші платить (хоч, може, і кляне при цьому). І не так, як у першого варіанта, коли «поставив і забув», як і клієнт про вас. Так, доводиться і «говнокодити», таке життя. Але намагайтеся хоч іноді писати «код-картинку», бо інакше ніколи не станете професіоналом, а будете чистим «говнокодером», а вони довго в ІТ не живуть.

Ще кілька слів про відносини із замовниками (клієнтами). Як відомо, «клієнт завжди має рацію». Але тут така сама ситуація, що і з «говнокодом». Якщо повсякчас будете тупо виконувати всі забаганки клієнта, навіть коли вони безглузді, замість того, щоб спробувати пояснити йому, в чому він помиляється і переконати зробити по-іншому, то професіоналом вам теж не бути. Вибачте за, можливо, занадто менторський тон. І за те, що, може, хтось зі мною не згоден із деяких питань і що, може, не про все важливе сказав. Але це мої думки й мій досвід, і вони, звичайно, суб’єктивні.

До речі, маю деякий досвід у навчанні БД та SQL з 0 до непоганого рівня, тож якщо комусь треба, звертайтесь.

Всім удачі та довгих років життя в ІТ.

👍НравитсяПонравилось43
В избранноеВ избранном11
Подписаться на тему «карьера»
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


65 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

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

Ви вже 40 років в ІТ. Як ви вважаєте, куди рухається ІТ і особливо розробка? Чи потрібно буде програмісту вміти програмувати через 30-40 років і чи будуть взагалі потрібні програмісти?

Ну, Ви і питання задаєте, одне складніше за інше. Можу тільки відповісти, що якщо тренд, який був і є зараз збережеться, то програмування, у тому вигляді як зараз (з написанням коду) буде все меньше і меньше. Але, щоб його зовсім не стало — це мені складно уявити. Навіть, якщо буде і пристойний штучний інтелект, і різна супер наворочена тулза для самих розробників, необхідність щось кодити на низькому рівні (тоді це може буде щось типа C++), все одно залишиться. Хоча б для розробки, та оптимізації самої цієї тулзи та Ш. І. Але, якщо тренд зміниться, уповільниться, то може ніяких особливих змін і не відбудеться. Наприклад, якби темпи досягнень у фізиці, які були на початку 20-го сторіччя, збереглись би і зараз, то ми вже повинні були б засвоїти антигравітацію, та досягти швидкості світла, не кажучи вже про такі дрібниці, як термоядерний синтез. Але ж нічого з цього немає, і не проглядається. Те ж саме може бути і з ІТ. Можливо, саме зараз їх золотий вік.

Дякую. Але тут є такий нюанс, як мені здається, що програмування залишиться, але їм будуть займатися не люди, а штучний інтелект.

Ото як ші забацає хоча б верстку з макету — покличете)

Собаки будуть програмістами.

А ШІ буде робити щось важливіше — рятувати прогресивне людство від комуністів.

Наприклад, якби темпи досягнень у фізиці, які були на початку 20-го сторіччя, збереглись би і зараз, то ми вже повинні були б засвоїти антигравітацію, та досягти швидкості світла, не кажучи вже про такі дрібниці, як термоядерний синтез. Але ж нічого з цього немає, і не проглядається

Досягнення в будь-якій сфері (в тому числі і науці) залежать від того, який бюджет їй виділяється.
Зараз в ІТ вкладаються величезні кошти, навіть більше ніж в космос, тому тут такий гігантський темп розвитку.
Якщо в 2000-му році за ринковою капіталізацією в ТОП-3 були General Electric, Exxon Mobil і Cisco, то зараз Apple, Amazon і Microsoft.

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

немає прямого зв’язку між кількістю зусиль та результатом.
скільки тра зусиль — щоб йти?
а бігти?
а взяти бронзу у місцевому змаганні?

а на скільки відсотків швидкість бігу звичайної людини менша ніж бігуна отримавшого бронзу?

В фізику теж вкладаються величезні кошти. Один тільки андронний коллайдер, який має довжину кілька кілометрів, і проходить по території кількох країн, чого вартий. Не все вирішується тільки грошима. В будь-якій науці, чи технології, по мірі її розвитку, найбільш ефективні і прості задачі швидко закінчуються, і залишаються дуже складні, і набагато менш ефективні. Поки все це не заходить у глухий кут. Тому, і стосовно Ш.І., я б не був тут таким оптимістом. Те що вже зараз їм називають, або його елементами, насправді, якщо розмістити його на одній шкалі з природним людським інтелектом, і якимось стандартним софтом, типа ОС, буде набагато набагато ближче до цього софту, ніж до справжнього інтелекту. Причому, ближче на декілька порядків. І не факт, що ця ситуація суттєво зміниться в найближчі 10 — 20 років.

4.75 billion. Не так чтобы и много.

На сегодня «священной коровой» термоядерного синтеза является реактор ITER, который разрабатывается с 1985 года.
...
Общая стоимость проекта оценивается в 20-25 миллиардов евро, а его запуск намечен на 2025 год (но это не точно).
...
Даже самые закоренелые оптимисты сейчас не ожидают появления коммерческих токамаков раньше 2060-х годов, а это уже как-то совсем негуманно. Замечу, что 2060-е годы — это уже более 110 лет (!) с начала первых экспериментов в 1950-х годах. Таким образом термоядерная энергетика претендует на звание самого долгоиграющего научно-технического долгостроя в истории человечества. Нет ни одной другой технологии, которая внедрялась бы настолько долго.

Глобальные научно-технические фейлы: управляемый термоядерный синтез
site.ua/yesint/14476

необхідність щось кодити на низькому рівні (тоді це може буде щось типа C++), все одно залишиться

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

а от високий рівень — важче.

легше-важче — то більше готової математики, формальних методів і менше.

Можливо, саме зараз їх золотий вік.

мабудь що так, згоден.
хоча й дивно мені й досі.

Я в 90их теж писав і на FoxPro оті склади(і холіварив Clipper vs FoxPro), бо С геть не кормив, і Clarion мацав, дуже вдала була система. Але... 1С тоді вже показала свої переваги для такого типу ПЗ у нас, в СНД.

Так от в кінці 90их я пам’ятаю захоплюючи перспективи, від тотального ООП до створення галузевих DSL. На хабрі була велика стаття одного з авторів такого для банковскої сфери, у нац банку Беларусі напрацював

Але дуже мало з тих надій виправдалися. «Щось пішло не так», і навіть «клепання формочок» не вдалося формалізувати.

Железо ведёт себя именно так, как его спроектировали.

да, в теории между теорией и практикой нет разницы.
а на практике — она есть.

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

Вот как написали код на верилоге да сигнал интегрити обеспечили так оно и работает.
Никакой разницы с софтом нет.

Что значит железо ведёт себя не так как его спроектировали. Ну вот как написали так и работает. Магии нет.

Вот как написали код на верилоге да сигнал интегрити обеспечили так оно и работает.

ну ну.

Магии нет.

конечно нет. при чем тут магия.

Что значит железо ведёт себя не так как его спроектировали

и самолеты летают — как их спроектировали
и мосты так стоят — как спроектировали — так и стоят.

говорю ж, криворуким программистам NASA дайте консультации.

Что ну-ну?
Я ответил на конкретный комментарий

така ж ситуація у ембедерів — залізо веде себе трішки не так, як його було запроектовано.

Нет там ничего такого в железе.
Из пары десятков проблем с которыми я сталкивался почти все за исключением пары вели к баге в верилоге. Отличий от обычного программирования в этом плане мало.

Что ну-ну?

— А какие они, эти неприятности?
— А вот увидишь!
— Они меня ждут? Эти неприятности?... Тогда я пошёл!

Нет там ничего такого в железе.

ну нет, так нет.

Отличий от обычного программирования в этом плане мало.

ну это понятно, что тот же спольски с его «пятью мирами» просто 3,141596ол.

мне доу тем и нравится — бОльшей концентрации гениев я не знаю в инете.

Я все-таки ел и ем эти устрицы. В отличие от.

Згоден, щось пішло не так. Точніше, не так, як гадали ІТ-шники в 80-х, та 90-х, коли всі вони, і в тому числі їх керівництво були інженерами, та науковцями. А от коли ІТ майже повністю став бізнесом, то змінилась і його логіка.

І ще питання з приводу банківського софта, так як ви вже давно працюєте в банківській сфері.
Як ви вважаєте, що краще (вигідніше) — купити готовий софт і адаптувати його або написати свій?

О, це дуже і дуже складне питання. Як і сам банківський софт. Тому, якщо дуже коротко, відповім так. Якщо це дуже серйозний і потужний банк, то є сенс створювати свій софт, хоча б частково, окремі його елементи, на базі якогось якісного покупного ядра. Якщо маленький, то краще купити щось готове і стандартне, вітчизняного розробника з якісним спортом. Але, в будь-якому разі (і це стосується не тільки банків) треба намагатись уникати створення ’зоопарків рішень’, коли безсистемно, різними бізнесами, чи за їх ініціативою, купуються різні продукти різних вендорів, які, часто дуже погано інтегруються один з одним. І при цьому, ігноруються можливості більш простого і ефективного розширення лінійки споріднених продуктів з різним функционалом від одного вендора. Ну от вже лонгрід виходить, а обіцяв коротко. 😞

я все життя не надивуюсь замовникам
— складний(не завжди великий), унікальний замовник намагається запхати цю унікальність у типове рішення
— типовий, малєнькій — «Ми передивились 10ок галузевих рішень, нам ніяке не підходить: нашому глав буху не підходить колір кнопок у X, фін директору — звіти, у Y три окремих, замість одного, ..., ...,» - тому вирішили замовити розробку, яка врахує всі наші унікальні потреби

Ну да, таке буває. Правда, що вони будуть робити, коли зміняться ці главбух, або фіндиректор? Новий софт замовляти? Бо, як правило, новому керівництву дуже рідко подобається те, що зроблено ’попередніками’.

що вони будуть робити, коли зміняться ці главбух, або фіндиректор?

рватимуть волосся :)

Бо, як правило, новому керівництву дуже рідко подобається те, що зроблено ’попередніками’.

так. і я бачив колекції ПЗ у коробках на полицях, куплене попередниками :)

звісно, такого все менше і менше. Досвід співпраці з ПЗ та самим розробниками накопичується і у менеджерів, і вже знають витрати у грошах та часі, на те чи інше рішення.

Ви не пробували підрахувати, скільки мов програмування та ІТ-технологій вивчили за ці 40 років?

Цікаве питання. Довелось щось писати (на чомусь багато, на чомусь зовсім ні) на таких МП: Fortran-4, 77, Assembler IBM 360/370, ZX-Spectrum, Pl-1, C, Clipper, Foxpro, Clarion, Java, Python, SQL, PlSQL. Але останні років 10 — 15 використовую тільки два останніх. Можливо, у зв’язку з новим проектом, знову доведеться згадати Python. Але він мені вже давно подобається, тому це не лякає. А взагалі, вони всі дуже схожі, особливо основні принципи розробки.

Дякую за відповідь. Як ви вважаєте, програмісти за ці 40 років змінилися? Стали краще/гірше/ розумніше/бiльш або менш дисциплінованими?

Як на мене, суттєво змінилось саме ІТ. Я маю на увазі не тільки самі технології, це очевидно. А їх суть, я б сказав систему цінностей в ІТ. На самому початку, цим займались виключно науковці, і тому це була наука. Правда, багато хто вважав це мистецтвом. І підходи були відповідними — дуже цінувалися красиві, та ефективні з інженерної, та архітектурної точки зору рішення. І результати були відповідні : компілятори, ОС, реляційні БД, інтернет, і тд, ітп. Весь цей софт надзвичайно складний, і містить в собі величезну інтелектуальну складову. Їм займались, насамперед математики. Якщо повернутись до деякої термінології цієї статті, ’говнокода’ там не було. Але пізніше, коли ІТ перейшло з стану науки, та мистецтва, у стан бізнесу, відповідно змінилась і система цінностей. І зараз цього ’говнокоду’ скільки завгодно, бо він більш ефективний з точки зору бізнесу, хоча з наукової, та інженерної точки зору він і є це слово. Програмісти не стали гірше, просто в багатьох з них теж змінилась система цінностей.

Програмісти не стали гірше, просто в багатьох з них теж змінилась система цінностей.

Тобто якщо перефразувати, то програмування перетворилося з мистецтва в бізнес, коммерціоналізіровалось.

У кожному місті є музеї, а є Андріївський Узвіз, повний мистецтва.
от у мистецтво з Узвозу — і йде рух.

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

але за останні років 15 я бачу що воно рухається у бік написання літераутрних творів: ессе, оповідань, романів з обмеженням у часі написання — контракт з видавцевм суворо вимагає здати у друкарню у конкретний термін :)

інженерним воно залишається тілько у ембедерів. там такий домен.

І підходи були відповідними — дуже цінувалися красиві, та ефективні з інженерної, та архітектурної точки зору рішення. І результати були відповідні : компілятори, ОС, реляційні БД, інтернет, і тд, ітп.
Якщо повернутись до деякої термінології цієї статті, ’говнокода’ там не було.

Я бы не согласился, вот пример habr.com/ru/post/429946 Из моего опыта самый лютый говнокод как раз таки пишут ученые, то что нам на питоне передавали физики — приходилось переделывать по неделе и плакать.

Дякую за вашу розповiдь

Ще кілька слів про відносини із замовниками (клієнтами). Як відомо, «клієнт завжди має рацію». Але тут така сама ситуація, що і з «говнокодом». Якщо повсякчас будете тупо виконувати всі забаганки клієнта, навіть коли вони безглузді, замість того, щоб спробувати пояснити йому, в чому він помиляється і переконати зробити по-іншому, то професіоналом вам теж не бути.

Цю тезу потрібно вигравірувати і повісити на видному місці в кожній компанії.

Бачу, Вам теж не раз доводилось пояснювати замовнику, чого він хоче насправді 😀

Файна стаття. Відчувається і досвід і мудрість, що приходять лише з роками.
Ну ось, наприклад:

А щоб не зовсім з початку, потрібно мати надійну базу.

Шкода що більша половина місцевого контингенту взагалі не зрозуміє про яку таку базу (мо відпочинку?) мова.
Одним словом, респектище.

Дякую за добрі слова. Але мені здається, що Ви налаштовані занадто песиместично стосовно молодого покоління ІТ-шників в цьому питанні. До мене, насправді це розуміння прийшло теж далеко не відразу, а тільки коли вперше зіткнувся з ситуацією, коли деякий набутий досвід, вдруг втратив свою цінність, і довелось набувати новий.

Текстові типи даних в Фортрані були (чи є) — на початку 90-х мій однокурсник наваяв цілий препроцесор який транслював DML (то була мова для матмоделювання і опису фігур за допомогою R-функцій) в той же Фортран. На Фортрані.

То вже в Fortran-77 вони з’явились, а в Fortran-4 їх ще не було. Хоча, можливо, через якісь бібліотеки і можна було їх прикручивати.

На ЕСовском Фортране-4 можно было реализовывать через тип LOGICAL*1, работали текстовые константы. Вот чего я не помню уже это как делались всякие аналоги chr(), ord()...

ціла епоха пройшла перед очима :) круто!

Дякую.

Як наче читаєш про подвиги античних героїв.

І трошки сумно від розуміння того як багато могли б такі люди зробити якби не мали витрачати час та сили на елементарне виживання, влаштування побуту, якби мали доступ до техніки та тогочасних знань світу за межами соцтабору :(

Та Ви перебільшуєте, ніяких ’подвигів античних героїв’ тоді не було, було звичайне життя. Просто, трохи не таке, як зараз.

Дякую за ділення досвідом. Було цікаво читати.

І я Вас дякую.

Дякую за цікаву статтю. Довгих років життя Михайлу

За якою з Ваших «старих» ЕОМ Ви хотіли б посидіти ще раз. просто так, якби була така можливість?

Да, якщо чесно, то мабуть ні за якою. Всі ці зелені букви на чорному моніторі з редакторами типа ’командна строка’ ... Там навіть копіпасту ще не було (коли в MS Dos вперше з ним зіткнувся, був дуже здивований, як, виявляється просто можно редагувати код, та тексти) . Ні, краще звичайний ноутбук.

Так, доводиться і «говнокодити», таке життя.

лол што

тобто це ваш свідомий вибір ??

А Вам ні? Ніколи? Можу тільки Вам позаздрити, якщо так.

ситуации когда софт нужен позавчера, а не через год крайне распространены как в аутсорсинге, так и в продуктах. Бизнес есть бизнес.

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

Тема «читалочки» для перфокарт не раскрыта :) lh3.googleusercontent.com/...​FAMsHhhfyMJS27z_KrrDXG1Nw

Її називали картрідер. Теж така типа тумбочка, з лотком для перфокарт. Туди клали їх колоду, і цей картрідер заглатував їх з величезною швидкістю і звуком, майже як у двигуна автомобіля, якщо зняти глушник.

Подписаться на комментарии