(Бұл мақалада бағдарламалық жасақтаманың келесі буынының басым бөлігі неліктен серверге негізделетіні, мұның бағдарламашылар үшін нені білдіретіні және бұл жаңа бағдарлама түрі стартаптар үшін неліктен зор мүмкіндік екені түсіндіріледі. Мақала BBN Labs-тағы баяндама негізінде жазылған.)
1995 жылдың жазында досым Роберт Моррис екеуміз стартап ашуды ұйғардық. Ол кезде Netscape-тің IPO-сына дейінгі PR-науқан қызып тұрған және баспасөзде онлайн-сауда туралы көп айтылып жатқан еді. Сол кезде Интернетте қолмен жасалған бар-жоғы отыз шақты нақты дүкен болған шығар. Егер онлайн-дүкендер көп болатын болса, оларды жасайтын бағдарламалық жасақтама қажет болады деген оймен, біз оны жазуға кірістік.
Алғашқы бір аптадай уақыт бойы біз мұны кәдімгі десктоптық қосымша ретінде жасауды көздедік. Бір күні бағдарламаны біздің веб-серверде іске қосып, интерфейс ретінде браузерді пайдалану туралы ой келді. Біз бағдарламаны Интернет арқылы жұмыс істейтіндей етіп қайта жазып көрдік, сонда дұрыс бағыт осы екені анық болды. Егер біз бағдарламалық жасақтаманы серверде жұмыс істейтіндей етіп жазсақ, бұл пайдаланушылар үшін де, біз үшін де әлдеқайда оңай болар еді.
Бұл жақсы жоспар болып шықты. Қазір Yahoo Store ретінде бұл бағдарлама шамамен 14 000 пайдаланушысы бар ең танымал онлайн-дүкен құрастырушы болып табылады.
Біз Viaweb-ті бастаған кезде, бағдарламалық жасақтама серверде жұмыс істейді деген сөзімізді ешкім дерлік түсінбеді. Бір жылдан кейін Hotmail іске қосылғаннан кейін ғана адамдар мұны түсіне бастады. Қазір бәрі бұл тәсілдің дұрыс екенін біледі. Біздің істегенімізге енді берілген атау да бар: Application Service Provider немесе ASP.
Менің ойымша, келесі буын бағдарламалық жасақтамасының көп бөлігі осы үлгі бойынша жазылады. Тіпті бәрінен де көп жоғалтатын Microsoft-тың өзі кейбір нәрселерді десктоптан көшірудің сөзсіздігін түсінген сияқты. Егер бағдарламалық жасақтама десктоптан серверлерге ауысса, бұл әзірлеушілер үшін мүлде басқа әлемді білдіреді. Бұл мақалада осы жаңа әлемге алғашқы болып келгендердің бірі ретінде көрген таңғаларлық нәрселеріміз сипатталады. Бағдарламалық жасақтама қаншалықты серверлерге көшсе, менің мұнда сипаттап отырғаным – соншалықты болашақтың бейнесі.
Келесі қадам не болмақ?
Десктоптық бағдарламалар дәуіріне көз жүгірткенде, алғашқы автокөлік иелерінің қандай қиындықтарға төзгеніне қалай таңғалсақ, адамдардың шыдап келген қолайсыздықтарына да солай таңғалатын боламыз деп ойлаймын. Алғашқы жиырма-отыз жыл бойы көлік иелену үшін көліктің қыр-сырын жетік білетін маман болу керек еді. Бірақ автокөлік соншалықты үлкен артықшылық бергендіктен, маман емес көптеген адамдар да оған ие болғысы келді.
Қазір компьютерлер де осы кезеңде. Десктоптық компьютерге ие болған кезде, оның ішінде не болып жатқаны туралы өзіңіз білгіңіз келгеннен әлдеқайда көп нәрсені үйренуге мәжбүр боласыз. Дегенмен, АҚШ-тағы үй шаруашылықтарының жартысынан астамында ол бар. Анамның электрондық пошта мен есеп-қисап жүргізуге қолданатын компьютері бар. Шамамен бір жыл бұрын ол Apple-ден операциялық жүйенің жаңа нұсқасына жеңілдік ұсынған хат алып, қатты мазасызданды. Компьютерді пошта мен есеп-қисап үшін пайдаланғысы келетін алпыс бес жастағы әйел жаңа операциялық жүйелерді орнату туралы ойлануға мәжбүр болса, бұл жерде бір гәп бар. Қарапайым пайдаланушылар «device driver» немесе «patch» түгілі, тіпті «операциялық жүйе» деген сөздерді де білмеуі керек.
Енді пайдаланушыларды жүйелік әкімші болудан құтқаратын бағдарламалық жасақтаманы жеткізудің басқа тәсілі бар. Веб-негізді қосымшалар — бұл веб-серверлерде жұмыс істейтін және веб-беттерді пайдаланушы интерфейсі ретінде қолданатын бағдарламалар. Қарапайым пайдаланушы үшін бұл жаңа бағдарламалық жасақтама десктоптық бағдарламаларға қарағанда жеңілірек, арзанырақ, ұтқыр, сенімдірек және көбінесе қуаттырақ болады.
Веб-негізді бағдарламалық жасақтамамен пайдаланушылардың көпшілігі өздері қолданатын қосымшалардан басқа ештеңе туралы бас қатырмайды. Барлық күрделі әрі құбылмалы нәрселер бір жердегі серверде сақталып, оны осындай іске машықтанған адамдар бақылап отырады. Осылайша, бағдарламаны пайдалану үшін әдетте дербес компьютердің өзі қажет болмай қалады. Сізге тек пернетақтасы, экраны және веб-браузері бар құрылғы ғана керек болады. Мүмкін оның сымсыз Интернет байланысы болар. Мүмкін ол сіздің ұялы телефоныңыз да болар. Ол не болса да, тұтынушылық электроника болады: шамамен 200 доллар тұратын және адамдар көбінесе корпусының түріне қарап таңдайтын зат. Қазір телефондарға төлеп жүргеніңіздей, құрылғының өзіне қарағанда Интернет қызметтеріне көбірек ақша төлейсіз. [1]
Шертудің серверге барып-қайтуы шамамен секундтың оннан бір бөлігін алады, сондықтан Photoshop сияқты өте интерактивті бағдарламаларды пайдаланушылар әлі де есептеулердің десктопта жүргізілгенін қалайтын болады. Бірақ адамдардың көпшілігі компьютерді не үшін пайдаланатынына қарасаңыз, секундтың оннан бір бөлігіне тең кідіріс проблема тудырмайды. Менің анама десктоптық компьютердің шын мәнінде қажеті жоқ, және ол сияқты адамдар өте көп.
Пайдаланушыларға берер ұтысы
Үйімнің жанында бамперіне «қолайсыздық көргенше, өлген артық» деп жазылған көлік тұр. Адамдардың көбі әрдайым ең аз күш жұмсауды талап ететін таңдауды жасайды. Егер веб-негізді бағдарламалық жасақтама жеңіске жетсе, бұл оның ыңғайлырақ болуынан болады. Және ол пайдаланушылар үшін де, әзірлеушілер үшін де солай болатындай көрінеді.
Таза веб-негізді қосымшаны пайдалану үшін сізге тек Интернетке қосылған браузер қажет. Сондықтан сіз веб-негізді қосымшаны кез келген жерде пайдалана аласыз. Бағдарламаны десктоп компьютеріңізге орнатқан кезде, оны тек сол компьютерде ғана қолдана аласыз. Одан да сорақысы, сіздің файлдарыңыз сол компьютерде қамалып қалады. Адамдар желілерге үйренген сайын бұл үлгінің қолайсыздығы барған сайын айқындала түседі.
Мұндағы алғашқы қадам веб-негізді электрондық пошта болды. Қай жерде жүрсеңіз де электрондық пошта хабарламаларына қолжетімділік болуы керек екенін енді миллиондаған адамдар түсінеді. Ал егер поштаңызды көре алсаңыз, күнтізбеңізді неге көрмеске? Егер әріптестеріңізбен құжатты талқылай алсаңыз, оны неге өңдей алмайсыз? Неліктен сіздің кез келген деректеріңіз алыстағы үстелде тұрған қандай да бір компьютерде қамалып қалуы керек?
«Сіздің компьютеріңіз» деген ұғым толығымен жойылып, оның орнын «сіздің деректеріңіз» басуда. Деректеріңізге кез келген компьютерден қол жеткізе алуыңыз керек. Дәлірек айтқанда, кез келген клиенттен, ал клиенттің міндетті түрде компьютер болуы шарт емес.
Клиенттер деректерді сақтамауы керек; олар телефон сияқты болуы тиіс. Шын мәнінде олар телефонға айналуы мүмкін, немесе керісінше. Клиенттер кішірейген сайын, деректеріңізді оларда сақтамаудың тағы бір себебі пайда болады: үнемі өзіңізбен бірге алып жүретін нәрсе жоғалып кетуі немесе ұрлануы мүмкін. Қалта компьютеріңізді (PDA) таксиде қалдыру дискінің істен шығуымен бірдей, тек бұл жағдайда деректеріңіз жойылып кетпей, басқа біреудің қолына түседі.
Таза веб-негізді бағдарламалық жасақтамада деректеріңіз де, қосымшаларыңыз да клиентте сақталмайды. Сондықтан оны пайдалану үшін ештеңе орнатудың қажеті жоқ. Ал орнату болмаған соң, орнату кезінде қате кетеді деп уайымдамайсыз. Қосымша мен операциялық жүйеңіздің арасында үйлесімсіздік болуы мүмкін емес, өйткені бағдарлама сіздің операциялық жүйеңізде іске қосылмайды.
Орнатуды қажет етпейтіндіктен, веб-негізді бағдарламалық жасақтаманы «сатып алмас» бұрын байқап көру оңай әрі үйреншікті жайтқа айналады. Кез келген веб-қосымша ұсынылған сайтқа кіріп-ақ, оны тегін сынап көру мүмкіндігі болуы керек. Viaweb-те біздің бүкіл сайтымыз пайдаланушыларды осы сынақтан өткізуге нұсқайтын үлкен меңзер сияқты еді.
Демо-нұсқаны сынап көргеннен кейін, қызметке тіркелу үшін қысқа пішінді толтырудан басқа ештеңе талап етілмеуі керек (неғұрлым қысқа болса, соғұрлым жақсы). Пайдаланушы істеуі керек соңғы әрекет осы болуға тиіс. Веб-негізді бағдарламалық жасақтаманың көмегімен сіз қосымша ақы төлемей-ақ, ешқандай әрекет жасамай-ақ, тіпті ол туралы білмей-ақ жаңа шығарылымдарды алып отырасыз.
Жаңартулар қазіргідей үлкен сілкініс болмайды. Уақыт өте келе қосымшалар білдіртпей қуатты бола түседі. Бұл әзірлеушілер тарапынан белгілі бір күш-жігерді талап етеді. Олар бағдарламалық жасақтаманы пайдаланушыларды шатастырмай жаңартылатындай етіп жобалауы керек. Бұл жаңа мәселе, бірақ оны шешудің жолдары бар.
Веб-негізді қосымшаларда барлығы бірдей нұсқаны пайдаланады және қателер (bug) анықталған бойда түзетілуі мүмкін. Сондықтан веб-негізді бағдарламалық жасақтамада десктоптық бағдарламаларға қарағанда қателер әлдеқайда аз болуы тиіс. Viaweb-те бір мезгілде біз білетін оннан астам қате болды деп айта алмаймын. Бұл десктоптық бағдарламаларға қарағанда еселеп жақсы көрсеткіш.
Веб-негізді қосымшаларды бірнеше адам бір уақытта пайдалана алады. Бұл бірлесіп жұмыс істейтін қосымшалар үшін айқын ұтыс, бірақ пайдаланушылар мұның мүмкін екенін түсінген бойда, олар көптеген қосымшалардан осыны талап ете бастайтынына бәс тігуге бармын. Мысалы, бір құжатты екі адамның бірге өңдеуіне мүмкіндік беру көбінесе пайдалы болады. Viaweb бірнеше пайдаланушыға сайтты бір мезгілде өңдеуге мүмкіндік берді; бұл пайдаланушылар солай қалайды деп күткендіктен емес, бағдарламаны жазудың дұрыс жолы сол болғандықтан жасалды, бірақ көбісі мұны шын мәнінде қалағаны белгілі болды.
Веб-негізді қосымшаны пайдаланған кезде деректеріңіз қауіпсіз болады. Дискілердің істен шығуы мүлдем тоқтамайды, бірақ пайдаланушылар бұл туралы енді естімейтін болады. Олар серверлік орталықтардың (server farms) ішінде орын алады. Ал веб-негізді қосымшаларды ұсынатын компаниялар резервтік көшірмелерді (backup) міндетті түрде жасайтын болады — оларда осындай мәселелерге бас қатыратын нағыз жүйелік әкімшілер болғандықтан ғана емес, сонымен бірге адамдардың деректерін жоғалтып алған ASP өте үлкен қиындыққа тап болатындықтан. Адамдар дискінің бұзылуынан өз деректерін жоғалтқанда, қатты ашулана алмайды, өйткені кінәлайтын өздерінен басқа ешкім жоқ. Ал компания олардың деректерін жоғалтса, олар әлдеқайда қатты ашуланады.
Соңында, веб-негізді бағдарламалық жасақтама вирустарға азырақ бейім болуы тиіс. Егер клиент браузерден басқа ештеңе іске қоспаса, вирустарды жұқтыру ықтималдығы аз болады және жергілікті жерде зақымданатын деректер жоқ. Ал серверлердің өзіне шабуыл жасайтын бағдарлама олардың өте жақсы қорғалғанын көреді. [2]
Пайдаланушылар үшін веб-негізді бағдарламалық жасақтама азырақ күйзеліс тудыратын болады. Менің ойымша, қатардағы Windows пайдаланушысының ішкі жан-дүниесіне үңілсеңіз, осы сипаттамаға сәйкес келетін бағдарламалық жасақтамаға деген орасан зор әрі әлі оянбаған құштарлықты табар едіңіз. Бұл құштарлық сыртқа шықса, қуатты күшке айналуы мүмкін.
Код қаласы
Әзірлеушілер үшін веб-негізді және десктоптық бағдарламалардың арасындағы ең айқын айырмашылық — веб-қосымшаның бір ғана код кесегінен тұрмайтындығында. Ол бір ғана үлкен бинарлық файл емес, әртүрлі типтегі бағдарламалардың жиынтығы болады. Сондықтан веб-негізді бағдарламалық жасақтаманы жобалау ғимарат салудан гөрі қала жобалауға ұқсайды: ғимараттармен қатар жолдар, көше белгілері, коммуналдық қызметтер, полиция мен өрт сөндіру бөлімдері, сондай-ақ өсім мен әртүрлі апаттарға арналған жоспарлар қажет.
Viaweb-те бағдарламалық жасақтама құрамына пайдаланушылар тікелей байланысатын айтарлықтай үлкен қосымшалар, сол қосымшалар пайдаланатын бағдарламалар, мәселелерді іздеп фондық режимде үнемі жұмыс істейтін бағдарламалар, бірдеңе бұзылса қайта іске қосуға тырысатын бағдарламалар, статистика жинау немесе іздеу үшін индекстер құру мақсатында мезгіл-мезгіл іске қосылатын бағдарламалар, ресурстарды қоқыстан тазарту (garbage-collect) немесе деректерді жылжыту не қалпына келтіру үшін біз тікелей іске қосқан бағдарламалар, пайдаланушы кейпіне енетін бағдарламалар (өнімділікті өлшеу немесе қателерді анықтау үшін), желі ақауларын диагностикалауға арналған бағдарламалар, резервтік көшірме жасау бағдарламалары, сыртқы қызметтерге арналған интерфейстер, сервердің нақты уақыттағы статистикасын көрсететін әсерлі бақылау тақталарын басқаратын бағдарламалар (келушілерге өте қызық болды, бірақ біз үшін де таптырмас құрал еді), ашық бастапқы кодты бағдарламаларға енгізілген өзгертулер (соның ішінде қателерді түзету) және өте көп конфигурациялық файлдар мен баптаулар кірді. Бізді Yahoo сатып алғаннан кейін, Тревор Блэквелл дүкендерді жұмысын тоқтатпай-ақ бүкіл ел бойынша жаңа серверлерге көшіруге арналған керемет бағдарлама жазды. Бағдарламалар біздің пейджерлерімізге хабарлама жіберді, пайдаланушыларға факстар мен электрондық хаттар жолдады, несиелік карта процессорларымен транзакциялар жүргізді және сокеттер, пайптар, http сұраныстары, ssh, udp пакеттері, ортақ жад және файлдар арқылы бір-бірімен байланысып тұрды. Viaweb-тің кейбір тұстары тіпті бағдарламалардың мүлдем болмауынан тұрды, өйткені Unix қауіпсіздігінің басты кілттерінің бірі — адамдар сіздің серверлеріңізге бұзып кіру үшін пайдалануы мүмкін қажетсіз утилиталарды іске қоспау.
Бұл тек бағдарламалық жасақтамамен шектелмеді. Біз сервер конфигурациялары туралы ойлануға көп уақыт бөлдік. Біз серверлерді бөлшектерден өзіміз құрастырдық — жартылай ақша үнемдеу үшін, жартылай өзімізге дәл керегін алу үшін. Жоғары тұрған провайдеріміздің (ISP) барлық магистральдық желілерге жеткілікті жылдам байланысы бар-жоғын ойластыруға тура келді. Біз RAID жеткізушілерімен бірінен соң бірімен кездесіп жүрдік.
Бірақ аппараттық құрал — тек бас ауыртатын нәрсе емес. Оны өзіңіз басқарған кезде, пайдаланушылар үшін көп нәрсе жасай аласыз. Десктоптық қосымшада сіз белгілі бір минималды аппараттық талаптарды көрсете аласыз, бірақ оған ештеңе қоса алмайсыз. Егер сіз серверлерді басқарсаңыз, тиісті жабдықты орнату арқылы барлық пайдаланушыларыңызға бір сәтте пейджерге хабар жіберуге, немесе факс жолдауға, немесе телефон арқылы командалар беруге, немесе несие карталарын өңдеуге және т.б. мүмкіндік бере аласыз. Біз үнемі аппараттық құралдар арқылы жаңа мүмкіндіктер қосудың жолдарын іздедік. Бұл пайдаланушыларға ұнағаны үшін ғана емес, сонымен бірге аппараттық құралдарды тікелей басқара алмайтын (өйткені олар десктоптық бағдарламаларды сатты немесе веб-қосымшаларды провайдерлер арқылы қайта сатты) бәсекелестерден ерекшеленудің бір тәсілі болды.
Веб-негізді қосымшадағы бағдарламалық жасақтама бір ғана бинарлық файл емес, бағдарламалар жиынтығы болатындықтан, оны кез келген бағдарламалау тілінде жазуға болады. Десктоптық бағдарлама жазған кезде, сіз іс жүзінде қосымшаны негізгі операциялық жүйе сияқты тілде — яғни C және C++ тілдерінде жазуға мәжбүр боласыз. Осылайша бұл тілдер (әсіресе менеджерлер мен венчурлық капиталистер сияқты техникалық емес адамдар арасында) «салмақты» бағдарламалық жасақтаманы әзірлеуге арналған тілдер ретінде қарастырыла бастады. Бірақ бұл тек десктоптық бағдарламаларды жеткізу тәсілінің салдары ғана еді. Серверге негізделген бағдарламалық жасақтама үшін кез келген тілді пайдалануға болады. [3] Бүгінде ең үздік хакерлердің көбі C және C++ тілдерінен мүлде алшақ тілдерді қолдануда: Perl, Python және тіпті Lisp.
Серверге негізделген бағдарламалық жасақтамада сізге қандай тілді қолдану керектігін ешкім айта алмайды, өйткені сіз бүкіл жүйені аппараттық құралға дейін толық бақылайсыз. Әртүрлі тапсырмалар үшін әртүрлі тілдер тиімді. Әрқайсысы үшін ең жақсысын таңдай аласыз. Ал бәсекелестеріңіз болған кезде, «істей аласыз» деген «істеуге міндеттісіз» дегенді білдіреді (бұған кейінірек ораламыз), өйткені бұл мүмкіндікті сіз пайдаланбасаңыз, бәсекелестеріңіз пайдаланады.
Біздің бәсекелестеріміздің көбі C және C++ тілдерін пайдаланды, және бұл олардың бағдарламалық жасақтамасын көзге көрінетіндей нашар етті, өйткені (басқа себептермен қатар) олар CGI скрипттерінің күйсіздігін (statelessness) айналып өте алмады. Егер бірдеңені өзгерткіңіз келсе, барлық өзгерістер төменгі жағында Жаңарту (Update) батырмасы бар бір бетте орын алуы керек еді. Мен басқа жерде жазғанымдай, әлі күнге дейін көпшілік зерттеу тілі деп санайтын Lisp-ті қолдану арқылы біз Viaweb редакторын десктоптық бағдарлама сияқты жұмыс істейтіндей ете алдық.
Шығарылымдар (Releases)
Бұл жаңа әлемдегі ең маңызды өзгерістердің бірі — шығарылымдарды жасау тәсілі. Десктоптық бағдарламалық жасақтама бизнесінде шығарылым жасау — бұл бүкіл компания бір ғана алып код кесегін шығару үшін бар күшін салып, қатты күйзелетін үлкен ауыртпалық. Бұл процестің өзіне де, нәтижесінде алынған өнімге де қатысты айқын салыстырулар ойға келеді.
Серверге негізделген бағдарламалық жасақтаманың көмегімен сіз өзіңіз үшін жазып жатқан бағдарламадағыдай өзгерістерді оңай енгізе аласыз. Сіз бағдарламаны сирек болатын үлкен жарылыс ретінде емес, дәйекті, шағын өзгерістер түрінде шығарасыз. Әдеттегі десктоптық бағдарламалық жасақтама компаниясы жылына бір немесе екі шығарылым жасай алады. Viaweb-те біз күніне үш-бес шығарылым жасайтын едік.
Осы жаңа үлгіге көшкен кезде, бағдарламалық жасақтаманы әзірлеу процесі оның қалай шығарылатынына қаншалықты тәуелді екенін түсінесіз. Десктоптық бағдарламалар бизнесінде кездесетін ең жағымсыз мәселелердің көбі шығарылымдардың осы апатты сипатына байланысты болып келеді.
Жылына бір ғана жаңа нұсқаны шығарған кезде, қателермен көтерме түрде айналысуға бейім боласыз. Шығарылым мерзімінен біраз уақыт бұрын сіз кодтың жартысы жұлынып алынып, жаңасымен ауыстырылған жаңа нұсқаны жинайсыз, бұл сансыз көп қателерді тудырады. Содан кейін QA қызметкерлерінің жасағы іске кірісіп, оларды санай бастайды, ал бағдарламашылар тізім бойынша оларды түзетеді. Олар әдетте тізімнің соңына жете алмайды, тіпті оның соңы қайда екенін де ешкім нақты білмейді. Бұл тоғаннан қоқыс аулағанмен бірдей. Бағдарламаның ішінде не болып жатқанын ешқашан нақты білмейсіз. Ең жақсы жағдайда, сіз статистикалық сипаттағы дұрыстыққа қол жеткізесіз.
Серверге негізделген бағдарламалық жасақтамада өзгерістердің көпшілігі шағын және біртіндеп енгізіледі. Мұның өзі жаңа қателердің пайда болу ықтималдығын азайтады. Бұл сондай-ақ бағдарламаны шығарар алдында нені мұқият тексеру керектігін білдіреді: ең соңғы өзгерткен нәрсеңізді. Нәтижесінде сіз кодты әлдеқайда берік бақылауда ұстайсыз. Әдеттегідей, оның ішінде не болып жатқанын біліп отырасыз. Әрине, сіз бастапқы кодты жатқа білмейсіз, бірақ бастапқы кодты оқығанда, қандай да бір құпияны ашуға тырысқан тергеуші сияқты емес, аспаптар панелін шолып отырған ұшқыш сияқты қарайсыз.
Десктоптық бағдарламалар қателерге деген белгілі бір фатализмді тудырады. Сіз қателерге толы өнімді жөнелтіп жатқаныңызды білесіз, тіпті оның орнын толтыру тетіктерін де жасап қойғансыз (мысалы, патч шығарылымдары). Олай болса, тағы бірнеше қате үшін неге алаңдау керек? Көп ұзамай сіз толық жұмыс істемейтінін біле тұра тұтас функцияларды шығара бересіз. Apple осы жылдың басында дәл осылай жасады. Олар шығу мерзімі төрт рет шегерілген жаңа операциялық жүйесін шығаруға мәжбүр болды, бірақ бағдарламалық жасақтаманың кейбір бөлігі (CD мен DVD қолдауы) дайын болмады. Шешім қандай болды? Олар аяқталмаған бөліктерінсіз ОЖ-ны шығарды, ал пайдаланушылар оларды кейінірек орнатуға мәжбүр болды.
Веб-негізді бағдарламалық жасақтамада бағдарламаны жұмыс істемей тұрып шығарудың еш қажеті жоқ және ол жұмыс істеген бойда оны бірден шығара аласыз.
Саланың ардагері: бағдарлама жұмыс істемейінше оны шығармау керек деген керемет естіледі, бірақ бағдарламалық жасақтаманың жаңа нұсқасын белгілі бір күнге дейін жеткізуге уәде берген болсаңыз не болады? — деп ойлауы мүмкін. Веб-негізді бағдарламада сіз мұндай уәде бермес едіңіз, өйткені онда нұсқалар жоқ. Бағдарламаңыз біртіндеп және үздіксіз өзгеріп отырады. Кейбір өзгерістер басқаларынан үлкенірек болуы мүмкін, бірақ нұсқалар туралы идея веб-негізді бағдарламалық жасақтамаға табиғи түрде үйлеспейді.
Егер біреу Viaweb-ті есіне алса, бұл оғаш көрінуі мүмкін, өйткені біз үнемі жаңа нұсқаларды жариялап отыратынбыз. Бұл тек PR мақсатында жасалды. Біз білгендей, салалық баспасөз нұсқа нөмірлерімен ойлайды. Олар үлкен шығарылым үшін, яғни нұсқа нөміріндегі бірінші цифрдың өзгеруіне арнап көлемді материал жазады, ал нүктеден кейінгі жаңа цифр үшін, яғни шағын шығарылым үшін көбінесе бір ғана абзац арнайды.
Кейбір бәсекелестеріміз десктоптық бағдарламаларды ұсынып жүрді және оларда шынымен де нұсқа нөмірлері болды. Осы шығарылымдары үшін (олардың бар болуының өзі бізге артта қалушылықтың дәлелі болып көрінді) олар түрлі жарнамаға ие болды. Біз құр қалғымыз келмеді, сондықтан өз бағдарламамызға да нұсқа нөмірлерін бере бастадық. Бізге жарнама қажет болған кезде, біз соңғы «шығарылымнан» бері қосқан барлық мүмкіндіктердің тізімін жасап, бағдарламаға жаңа нұсқа нөмірін қойып, жаңа нұсқаның дереу қолжетімді екенін айтып пресс-релиз шығаратынбыз. Таңғаларлығы, ешкім бізді бұл үшін ешқашан ұстап алған жоқ.
Бізді сатып алғанға дейін біз мұны үш рет жасадық, осылайша 4-нұсқада болдық. Егер дұрыс есімде болса, 4.1 нұсқасында. Viaweb Yahoo Store-ға айналғаннан кейін, жарнамаға бұдан былай аса мұқтаждық болмады, сондықтан бағдарламалық жасақтама дамуын жалғастырғанымен, нұсқа нөмірлері идеясы бірте-бірте қойыла салды.
Қателер (Bugs)
Веб-негізді бағдарламалық жасақтаманың тағы бір маңызды техникалық артықшылығы — көптеген қателерді дәл қайталауға (reproduce) болатындығында. Пайдаланушылардың деректері тікелей сіздің дискіңізде тұрады. Егер біреу бағдарламаңызды бұзып алса, десктоптық бағдарламадағыдай не болып жатқанын жорамалдауға тырысудың қажеті жоқ: олар телефонмен сөйлесіп тұрған кезде-ақ сіз қатені өз көзіңізбен қайталап көре аласыз. Егер қосымшаңызға қателерді байқайтын код орнатылған болса, бұл туралы тіпті алдын ала біліп те отыруыңыз мүмкін.
Веб-негізді бағдарламалық жасақтама тәулік бойы қолданылады, сондықтан сіз жасаған әрбір нәрсе бірден қатаң сынақтан өтеді. Қателер тез анықталады.
Бағдарламалық жасақтама компаниялары кейде бағдарламаның қателерін пайдаланушыларға түзетеді деп айыпталады. Менің ұсынып отырғаным да дәл осы. Веб-негізді бағдарламалық жасақтама үшін бұл шын мәнінде жақсы жоспар, өйткені қателер азырақ және өтпелі болады. Бағдарламалық жасақтаманы біртіндеп шығарғанда, сізде бастапқыда қателер әлдеқайда аз болады. Ал қателерді қайталап көруге және өзгерістерді лезде шығаруға болатын кезде, сіз пайда болған қателердің көпшілігін бірден тауып, түзете аласыз. Бізде бір уақытта ресми bug-tracking жүйесімен бас қатыратындай ешқашан көп қате болған емес.
Әрине, өзгерістерді шығармас бұрын сынап көруіңіз керек, сондықтан ешқандай үлкен қателер шығып кетпеуі тиіс. Сөзсіз өтіп кететін аздаған қателер шекаралық жағдайларға байланысты болады және біреу шағымданып қоңырау шалғанға дейін оларға тап болған санаулы пайдаланушыларға ғана әсер етеді. Қателерді бірден түзететін болсаңыз, қарапайым пайдаланушы үшін жалпы нәтиже — қателердің әлдеқайда аз болуы. Қарапайым Viaweb пайдаланушысы қатені өмірінде көрді ме екен, күмәнім бар.
Жаңа қателерді түзету ескілерін түзетуден оңайырақ. Жаңа ғана жазған кодыңыздың қатесін табу әдетте өте жылдам жүреді. Ол пайда болған кезде, сіз тіпті бастапқы кодқа қарамай-ақ не дұрыс емес екенін біліп отырасыз, өйткені іштей бұл туралы уайымдап жүрген болатынсыз. Алты ай бұрын жазған нәрсеңіздің қатесін түзету (жылына бір рет шығаратын болсаңыз, орташа жағдай осы) әлдеқайда көп жұмысты талап етеді. Кодты жақсы түсінбегендіктен, оны дөрекі түрде түзетуіңіз немесе тіпті одан да көп қателер енгізуіңіз әбден мүмкін. [4]
Қателерді ерте анықтаған кезде, күрделі қабаттасқан қателер де аз болады. Күрделі қателер — бұл өзара әрекеттесетін екі бөлек қате: баспалдақпен түсіп келе жатып сүрінесіз, ал сүйенішке қолыңызды созғанда, ол қолыңызда жұлынып қалады. Бағдарламалық жасақтамада мұндай қатені табу ең қиын және оның салдары да ең ауыр болады. [5] Дәстүрлі «бәрін бұзып, содан кейін қателерді сүзгіден өткізу» тәсілі табиғи түрде көптеген осындай қабаттасқан қателерді тудырады. Ал шағын өзгерістер сериясымен шығарылатын бағдарламалық жасақтама бұған бейім емес. Едендер кейіннен бірдеңеге кептеліп қалуы мүмкін кез келген бос заттардан үнемі тазартылып отырады.
Функционалдық бағдарламалау деп аталатын әдісті қолдану бұл ретте көмектеседі. Функционалдық бағдарламалау жанама әсерлерден (side-effects) аулақ болуды білдіреді. Бұл коммерциялық бағдарламалық жасақтамадан гөрі ғылыми мақалаларда көбірек кездесетін нәрсе, бірақ веб-негізді қосымшалар үшін бұл өте пайдалы болып шықты. Бүкіл бағдарламаларды таза функционалдық код ретінде жазу қиын, бірақ оның қомақты бөліктерін осылай жазуға болады. Бұл сіздің бағдарламалық жасақтамаңыздың сол бөліктерін сынауды жеңілдетеді, өйткені оларда күй (state) болмайды, және бұл сіз үнемі шағын өзгерістер енгізіп, оларды сынап отыратын жағдайда өте ыңғайлы. Мен Viaweb редакторының көп бөлігін осы стильде жаздым, ал өзіміздің RTML скрипт тілімізді таза функционалдық тілге айналдырдық.
Десктоптық бағдарлама бизнесіндегі адамдарға бұған сену қиын болар, бірақ Viaweb-те қателер дерлік ойынға айналды. Шығарылған қателердің көпшілігі шекаралық жағдайларға қатысты болғандықтан, оларға тап болған пайдаланушылар көбінесе жүйенің мүмкіндіктерін барынша пайдаланып жүрген озық пайдаланушылар болды. Озық пайдаланушылар қателерге кешіріммен қарайды, әсіресе сіз ол қатені олар сұраған қандай да бір функцияны қосу барысында енгізген болсаңыз. Шындығында, қателер сирек болғандықтан және оларды көру үшін күрделі әрекеттер жасау керек болғандықтан, озық пайдаланушылар оны тауып алғанына жиі мақтанатын. Олар техникалық қолдау қызметіне ашумен емес, бізден ұпай алып кеткендей, жеңімпаз көңіл-күймен қоңырау шалатын.
Қолдау көрсету
Қателерді қайталап көруге болатын кезде, бұл тұтынушыларға қолдау көрсетуге деген көзқарасыңызды өзгертеді. Көптеген бағдарламалық жасақтама компанияларында қолдау көрсету клиенттердің көңілін көтерудің бір тәсілі ретінде ұсынылады. Олар сізге не белгілі бір қате бойынша қоңырау шалады, немесе жай ғана бірдеңені дұрыс істемейді және сіз оның не екенін анықтауыңыз керек. Қай жағдайда да сіз олардан көп нәрсе үйрене алмайсыз. Сондықтан қолдау көрсету қоңырауларын әзірлеушілерден барынша оқшаулағыңыз келетін мазасыз шаруа ретінде көресіз.
Viaweb-те бәрі басқаша болды. Viaweb-те қолдау көрсету тегін болды, өйткені біз тұтынушылардан кері байланыс алғымыз келді. Егер біреуде мәселе туындаса, біз қатені қайталап көріп, түзетуді дереу шығару үшін ол туралы бірден білгіміз келетін.
Сондықтан Viaweb-те әзірлеушілер қолдау көрсету қызметімен әрқашан тығыз байланыста болды. Тұтынушыларға қолдау көрсету қызметкерлері бағдарламашылардан шамамен отыз фут жерде отыратын және нағыз қате туралы хабармен кез келген уақытта олардың жұмысын бөле алатындарын білетін. Біз үлкен қатені жөндеу үшін директорлар кеңесінің жиналысынан шығып кететінбіз.
Қолдау көрсетуге қатысты біздің тәсіліміз барлығын бақыттырақ етті. Тұтынушылар дән риза болды. Қолдау көрсету желісіне қоңырау шалып, маңызды жаңалық алып келген адамдай қабылданғаныңызды елестетіп көріңізші. Тұтынушыларға қолдау көрсету қызметкерлеріне бұл ұнады, себебі олар скрипттерді оқып берудің орнына пайдаланушыларға шынымен көмектесе алды. Ал бағдарламашыларға қателер туралы екінші қолдан жеткен бұлыңғыр есептерді ғана естімей, оларды өздері қайталап көру мүмкіндігі ұнады.
Қателерді сол мезетте жөндеу саясатымыз қолдау көрсету қызметкерлері мен хакерлер арасындағы қарым-қатынасты өзгертті. Көптеген бағдарламалық жасақтама компанияларында қолдау көрсету қызметкерлері — жалақысы төмен тірі қалқандар, ал хакерлер — әлемді жаратушы Тәңірдің шағын көшірмелері. Қателер туралы хабарлау процедурасы қандай болса да, ол көбінесе бір бағытты болады: қате туралы естіген қолдау көрсетушілер қандай да бір пішінді толтырады, ол ақырында (мүмкін QA арқылы) бағдарламашыларға өтеді, ал олар оны істейтін істер тізіміне қосады. Viaweb-те бәрі мүлдем басқаша еді. Клиенттен қате туралы естігеннен кейін бір минут өтпей-ақ қолдау көрсету қызметкерлері бағдарламашының қасында тұрып, оның: «Қарғыс атсын, сенікі дұрыс, бұл қате екен», дегенін ести алатын. Хакерлерден сол «сенікі дұрыс» деген сөзді есту қолдау көрсету қызметкерлерін қатты қуантатын. Олар бізге қателерді дәл жаңа ғана ұстаған тышқанын алып келген мысық сияқты үмітті кейіппен алып келетін. Бұл сондай-ақ оларды қатенің қаншалықты маңызды екенін бағалауда мұқият болуға үйретті, өйткені енді олардың абыройы таразыға түсіп тұрған еді.
Бізді Yahoo сатып алғаннан кейін, тұтынушыларға қолдау көрсету қызметкерлерін бағдарламашылардан алысқа көшірді. Тек сонда ғана біз олардың іс жүзінде QA, тіпті белгілі бір деңгейде маркетинг те болғанын түсіндік. Қателерді ұстаумен қатар, олар пайдаланушыларды шатастыратын мүмкіндіктер сияқты бұлыңғыр, қатеге ұқсас нәрселер туралы білімнің сақтаушылары еді. [6] Олар сондай-ақ фокус-топтың өкілі іспетті болды; біз олардан екі жаңа мүмкіндіктің қайсысы пайдаланушыларға көбірек керек екенін сұрай алатынбыз және олар әрқашан дұрыс айтатын.
Моральдық рух
Бағдарламалық жасақтаманы дереу шығару мүмкіндігі — үлкен мотивация. Жұмысқа жаяу бара жатып, бағдарламаға қандай да бір өзгеріс енгізгім келетінін жиі ойлайтынмын да, оны сол күні-ақ жасайтынмын. Бұл үлкенірек мүмкіндіктер үшін де тиімді болды. Тіпті бір нәрсені жазуға екі апта кететін болса да (жобалардың көбі бұдан ұзаққа созылмайтын), жұмыс біткен бойда оның нәтижесін бағдарламадан көре алатынымды білетінмін.
Егер келесі релизді бір жыл күтуге тура келсе, мен бұл идеялардың көбін тым болмағанда белгілі бір уақытқа кейінге ысырып қояр едім. Алайда идеялардың бір ерекшелігі — олар жаңа идеяларды тудырады. Бірдеңе жазуға отырғанда, оған кіретін идеялардың жартысы жазу барысында ойға келген идеялар екенін байқадыңыз ба? Дәл осы нәрсе бағдарламалық жасақтамада да болады. Бір идеяны жүзеге асыру үшін жұмыс істеу сізге көбірек идея береді. Сондықтан идеяны кейінге қалдыру тек оны жүзеге асыруды кешіктіріп қана қоймайды, сонымен бірге оны жүзеге асырудан туындайтын барлық басқа идеялардан да айырады. Шын мәнінде, идеяны кейінге ысырып қою жаңа идеялардың пайда болуына да кедергі келтіруі мүмкін: жаңа бір мүмкіндік туралы ойлай бастағанда, кейінге қалдырылған нәрселерге көзіңіз түсіп, «бірақ менде келесі релизге арналған жаңа нәрселер онсыз да көп қой» деп ойлайсыз.
Ірі компаниялар мүмкіндіктерді жүзеге асырудың орнына оларды жоспарлайды. Viaweb-те біз кейде осы мәселе бойынша қиындықтарға тап болатынбыз. Инвесторлар мен сарапшылар бізден болашаққа қандай жоспарларымыз бар екенін сұрайтын. Шын мәнінде, бізде ешқандай жоспар болған жоқ. Бізде жақсартқымыз келген нәрселер туралы жалпы түсініктер ғана болды, бірақ мұны қалай жасау керектігін білсек, оны баяғыда-ақ істер едік. Алдағы алты айда не істемекші болдық? Ең көп ұтыс әкелетіндей көрінген нәрсені. Мен бұл жауапты ашық айтуға батылым жетті ме, жоқ па, білмеймін, бірақ шындық осы еді. Жоспарлар — бұл кейінге ысырылған идеялардың басқаша атауы ғана. Біз жақсы идеялар ойлап тапқан кезде, оларды бірден жүзеге асыратынбыз.
Viaweb-те, басқа да көптеген бағдарламалық жасақтама компанияларындағы сияқты, кодтың көп бөлігінің нақты бір иесі болды. Бірақ бір нәрсеге иелік етсеңіз, сіз оған шын мәнінде иелік ететінсіз: бағдарлама бөлігінің иесінен басқа ешкім релизді мақұлдауға (немесе ол туралы білуге де) міндетті емес еді. Әріптестеріңіздің алдында ақымақ болып көрінуден қорқудан басқа бұзылудан сақтайтын ешқандай қорғаныс болған жоқ, ал бұл толықтай жеткілікті еді. Мен кодты еш ойланбай, жай ғана алға қарай жаза бергендей әсер қалдыруым мүмкін. Біз шынымен де жылдам қозғалдық, бірақ бағдарламалық жасақтаманы сол серверлерге шығармас бұрын өте мұқият ойланатынбыз. Ал сенімділік үшін асықпай қозғалудан гөрі, зейін қою маңыздырақ. Зейінін барынша салғандықтан, Әскери-теңіз күштерінің ұшқышы салмағы 40 000 фунт болатын ұшақты түнде, шайқалып тұрған авианосец палубасына сағатына 140 миль жылдамдықпен, кәдімгі жасөспірімнің бейглді кесуінен әлдеқайда қауіпсіз қондыра алады.
Бағдарламалық жасақтаманы осылай жазу — әрине, екі жүзді қылыш. Бұл нашар идеяларды оларды ойлап тапқан адамдар емес, комитеттер қадағалайтын ортанқол мамандардан тұратын үлкен компанияға қарағанда, жақсы, сенімді бағдарламашылардың шағын командасы үшін әлдеқайда жақсы жұмыс істейді.
Керісінше Брукс
Бақытымызға орай, вебке негізделген бағдарламалық жасақтама шынымен де аз бағдарламашыны қажет етеді. Мен кезінде инженерия саласында барлығы 100-ден астам адам жұмыс істейтін орта көлемді десктоптық бағдарламалық жасақтама компаниясында жұмыс істегенмін. Олардың тек 13-і ғана өнімді әзірлеумен айналысатын. Қалғандарының бәрі релиздермен, порттаумен және т.б. жұмыс істейтін. Вебке негізделген бағдарламалық жасақтамамен сізге бар болғаны (ең көбі) сол 13 адам қажет, өйткені мұнда ешқандай релиздер, порттау және басқалар жоқ.
Viaweb-ті бар болғаны үш-ақ адам жазған. [7] Мен әрқашан көбірек адам жалдау туралы қысым көретінмін, өйткені біз компанияның сатылғанын қаладық және сатып алушылар үшін бар болғаны үш бағдарламашысы бар компанияға жоғары баға төлеу қиын болатынын білдік. (Шешім: біз көбірек адам жалдадық, бірақ оларға жаңа жобалар құрып бердік.)
Бағдарламалық жасақтаманы аз бағдарламашымен жаза алсаңыз, бұл ақшадан да көп нәрсені үнемдейді. Фред Брукс The Mythical Man-Month кітабында атап өткендей, жобаға адамдарды қосу оны баяулатуға бейім. Әзірлеушілер арасындағы мүмкін болатын байланыстар саны топтың көлеміне қарай экспоненциалды түрде өседі. Топ неғұрлым үлкен болса, олар өз бағдарламалық жасақтамаларының бірлесіп қалай жұмыс істейтінін келісу үшін жиналыстарда соғұрлым көп уақыт өткізеді және күтпеген өзара әрекеттесулерден туындайтын қателер соғұрлым көп болады. Бақытымызға орай, бұл процесс керісінше де жұмыс істейді: топтар кішірейген сайын, бағдарламалық жасақтаманы әзірлеу экспоненциалды түрде тиімдірек болады. Viaweb-тегі бағдарламашылардың шынайы жиналыс өткізгенін есіме түсіре алмаймын. Бізде түскі асқа бара жатып айта алатын сөзден артық ешқашан ештеңе болған емес.
Бұл жерде бір кемшілік болса, ол — барлық бағдарламашылар белгілі бір деңгейде жүйелік әкімшілер де болуы керек. Бағдарламалық жасақтаманы хостингке орналастырған кезде біреу серверлерді бақылап отыруы керек, ал іс жүзінде мұны дұрыс жасай алатын жалғыз адамдар — осы бағдарламаны жазғандар. Viaweb-те жүйемізде құрамдас бөліктер өте көп болды және ол жиі өзгеріп отырды, сондықтан бағдарлама мен инфрақұрылым арасында нақты шекара болған жоқ. Мұндай шекараны ерікті түрде белгілеу біздің дизайн таңдауымызды шектер еді. Сондықтан біз бір күні («бір-екі айдан кейін») бәрі тұрақталып, жұмысы тек серверлерге алаңдау болатын адамды жалдай аламыз деп үнемі үміттенсек те, бұл ешқашан болған жоқ.
Өнімді белсенді түрде әзірлеп жатқан кезде, бұдан басқаша болуы мүмкін емес деп ойлаймын. Вебке негізделген бағдарламалық жасақтама ешқашан жазып, тапсырып, үйге қайтып кететін дүние болмайды. Бұл — дәл қазір серверлеріңізде жұмыс істеп тұрған тірі нәрсе. Қауіпті қате тек бір пайдаланушының процесін тоқтатып қана қоймай, олардың барлығын бұзуы мүмкін. Егер кодыңыздағы қате дискідегі кейбір деректерді бүлдірсе, оны жөндеуге тура келеді. Және тағы солай кете береді. Біз серверлерді әр минут сайын бақылаудың қажеті жоқ екенін түсіндік (бірінші жыл шамасында өткен соң), бірақ соңғы уақытта өзгерткен нәрселеріңізге міндетті түрде назар аударып отыруыңыз керек. Кодты түнде шығарып, содан кейін үйге кетіп қалмайсыз.
Пайдаланушыларды бақылау
Серверге негізделген бағдарламалық жасақтамамен сіз өз кодыңызбен тығызырақ байланыста боласыз. Сондай-ақ пайдаланушыларыңызбен де тығызырақ байланыста бола аласыз. Intuit бөлшек сауда дүкендерінде тұтынушыларға өздерін таныстырып, олардың соңынан үйіне еріп баруды өтінуімен танымал. Егер біреудің сіздің бағдарламаңызды алғаш рет қалай қолданғанын көрген болсаңыз, оларды қандай тосынсыйлар күтіп тұрғанын білесіз.
Бағдарламалық жасақтама пайдаланушылар одан не күтсе, соны орындауы керек. Бірақ, маған сеніңіз, пайдаланушыларды өз көзіңізбен көрмейінше, олардың не ойлайтынын мүлде біле алмайсыз. Ал серверге негізделген бағдарламалық жасақтама олардың әрекеті туралы бұрын-соңды болмаған ақпарат береді. Сіз шағын, жасанды фокус-топтармен шектелмейсіз. Әрбір пайдаланушы жасаған әрбір шертуді көре аласыз. Сіз нені қарау керектігін мұқият ойластыруыңыз керек, себебі пайдаланушылардың жеке өміріне қол сұққыңыз келмейді, бірақ тіпті ең жалпы статистикалық іріктеудің өзі өте пайдалы болуы мүмкін.
Пайдаланушылар сіздің серверіңізде болғанда, мәселен, бенчмарктерге сенудің қажеті жоқ. Бенчмарктер — бұл симуляцияланған пайдаланушылар. Серверге негізделген бағдарламалық жасақтаманың арқасында сіз нақты пайдаланушыларды бақылай аласыз. Нені оңтайландыру керектігін шешу үшін жай ғана серверге кіріп, процессордың (CPU) ресурсын не жеп жатқанын көріңіз. Сондай-ақ оңтайландыруды қашан тоқтату керектігін де білесіз: біз ақырында Viaweb редакторын CPU-мен емес, жадпен шектелетін (memory-bound) деңгейге жеткіздік, ал пайдаланушылар деректерінің көлемін азайту үшін қолымыздан ештеңе келмейтіндіктен (яғни, оңай жолы болмады), дәл осы жерден тоқтаған дұрыс екенін түсіндік.
Серверге негізделген бағдарламалық жасақтама үшін тиімділік өте маңызды, себебі сіз аппараттық құралдарға ақы төлейсіз. Бір серверде қызмет көрсете алатын пайдаланушылар саны — негізгі шығындарыңыздың бөлгіші, сондықтан бағдарламалық жасақтамаңызды өте тиімді ете алсаңыз, бәсекелестерден төмен баға ұсынып, сонда да пайда таба аласыз. Viaweb-те біз бір пайдаланушыға шаққандағы күрделі шығындарды шамамен 5 долларға дейін төмендеттік. Қазір бұл одан да аз болар еді, бәлкім, оларға бірінші айдың шотын жіберу құнынан да арзан шығар. Егер бағдарламалық жасақтамаңыз жеткілікті дәрежеде тиімді болса, қазір аппараттық құрал тегін дерлік.
Пайдаланушыларды бақылау оңтайландырумен қатар дизайн жағынан да жол көрсете алады. Viaweb-те алдыңғы қатарлы пайдаланушыларға парақшаның өз стильдерін жасауға мүмкіндік беретін RTML деп аталатын скрипт тілі болды. Біз RTML-дің ұсыныстар жәшігіне ұқсас нәрсеге айналғанын байқадық, себебі пайдаланушылар оны тек алдын ала дайындалған стильдер олар қалаған нәрсені істей алмаған кезде ғана пайдаланатын. Мәселен, басында редактор батырмалар тақтасын парақтың бойына қоятын, бірақ бірнеше пайдаланушы батырмаларды сол жаққа орналастыру үшін RTML-ді қолданғаннан кейін, біз мұны алдын ала дайындалған парақша стильдерінде таңдау мүмкіндігі (шын мәнінде әдепкі күй) етіп қойдық.
Сонымен қатар пайдаланушыларды бақылау арқылы олардың қашан қиындыққа тап болғанын жиі байқауға болады. Ал тұтынушы әрқашан дұрыс болғандықтан, бұл сіз жөндеуіңіз керек нәрсенің белгісі. Viaweb-те пайдаланушыларды тартудың басты кілті онлайн тест-драйв болды. Бұл маркетологтар жасаған слайдтар жиынтығы ғана емес еді. Біздің тест-драйвта пайдаланушылар бағдарламалық жасақтаманы шынымен қолданып көрді. Оған шамамен бес минут кетті және соңында олар нақты, жұмыс істеп тұрған дүкен құрып шықты.
Тест-драйв — бізге барлық дерлік жаңа пайдаланушыларды тартқан тәсіл болды. Вебке негізделген қосымшалардың көпшілігінде солай болады деп ойлаймын. Егер пайдаланушылар тест-драйвтан сәтті өтсе, оларға өнім ұнайды. Егер олар шатасып қалса немесе жалықса, ұнамайды. Сондықтан тест-драйвтан көбірек адамның өтуі үшін жасай алатын кез келген нәрсе біздің өсу қарқынымызды арттыратын еді.
Мен тест-драйвтан өтіп жатқан адамдардың шерту жолдарын зерттеп, белгілі бір қадамда олар шатасып, браузердің «Артқа» батырмасын басатынын байқадым. (Егер вебке негізделген қосымшаларды жазып көрсеңіз, «Артқа» батырмасы сіздің ең қызықты философиялық мәселелеріңіздің біріне айналатынын түсінесіз.) Сондықтан мен сол жерге пайдаланушыларға жұмыстың аяқталуға жақын қалғанын ескертетін және «Артқа» батырмасын баспауды еске салатын хабарлама қостым. Вебке негізделген бағдарламалық жасақтаманың тағы бір керемет жері — енгізілген өзгерістерден лезде кері байланыс аласыз: тест-драйвты аяқтаған адамдардың саны бірден 60%-дан 90%-ға дейін өсті. Ал жаңа пайдаланушылар саны аяқталған тест-драйвтар санына байланысты болғандықтан, бір ғана осы өзгерістің арқасында біздің табысымыздың өсімі 50%-ға артты.
Ақша
1990 жылдардың басында мен бағдарламалық жасақтаманың жазылым бизнесі екені айтылған мақаланы оқыдым. Басында бұл өте циникалық мәлімдеме болып көрінді. Бірақ кейінірек оның шындықты көрсететінін түсіндім: бағдарламалық жасақтаманы әзірлеу — бұл үздіксіз процесс. Адамдарды сізге ақша төлеуді жалғастыру үшін үнемі жаңа нұсқаларды сатып алуға және орнатуға мәжбүрлеудің орнына, жазылым ақысын ашық түрде алу дұрысырақ деп санаймын. Және бақытымызға орай, жазылым — вебке негізделген қосымшалар үшін ақы алудың ең табиғи тәсілі.
Қосымшаларды хостингке орналастыру — бұл компаниялар тегін бағдарламалар (freeware) толтыра алмайтын рөлді атқаратын сала. Қосымшаларды хостингте ұстау үлкен стресс тудырады және нақты шығындарды талап етеді. Ешкім мұны тегін жасағысы келмейді.
Компаниялар үшін вебке негізделген қосымшалар — тамаша кіріс көзі. Әр тоқсанды бос парақтан бастаудың орнына, сізде тұрақты кіріс ағыны болады. Бағдарламалық жасақтамаңыз біртіндеп дамитындықтан, жаңа модельдің сәтсіз болуы мүмкін деп алаңдамайсыз; жаңа модельдің болуы, өз алдына, тіпті қажет те емес, ал егер бағдарламаға пайдаланушыларға ұнамайтын бірдеңе жасасаңыз, оны бірден білесіз. Сізде өндіріп алуға келмейтін шоттармен мәселе болмайды; егер біреу төлегісі келмесе, сіз жай ғана қызметті өшіре аласыз. Және қарақшылықтың болуы мүмкін емес.
Соңғы «артықшылық» проблемаға айналуы мүмкін. Қарақшылықтың белгілі бір көлемі бағдарламалық жасақтама компаниялары үшін пайдалы. Егер қандай да бір пайдаланушы сіздің бағдарламаңызды ешқандай бағаға сатып алмайтын болса, ол оның қарақшылық көшірмесін пайдаланса, сіз ештеңе жоғалтпайсыз. Шын мәнінде, сіз ұтасыз, өйткені ол сіздің бағдарламаңыздың стандартқа айналуына көмектесетін тағы бір пайдаланушы — немесе ол мектепті бітіргеннен кейін көшірмесін сатып алуы мүмкін.
Мүмкіндік болған кезде, компаниялар баға дискриминациясы деп аталатын нәрсені жасағанды ұнатады, бұл әр клиенттен оның шамасы жететіндей максималды баға алу дегенді білдіреді. [8] Бағдарламалық жасақтама баға дискриминациясына өте қолайлы, өйткені шекті шығындар нөлге жақын. Сондықтан кейбір бағдарламалар Intel машиналарына қарағанда Suns машиналарында жұмыс істеу үшін қымбатырақ тұрады: Suns қолданатын компания ақша үнемдеуге қызықпайды және олардан еш қорықпай көбірек ақы алуға болады. Қарақшылық, шын мәнінде, баға дискриминациясының ең төменгі деңгейі болып табылады. Менің ойымша, бағдарламалық жасақтама компаниялары мұны түсінеді және қарақшылықтың кейбір түрлеріне әдейі көз жұмады. [9] Серверге негізделген бағдарламалық жасақтамамен оларға басқа шешім табуға тура келеді.
Вебке негізделген бағдарламалық жасақтама, әсіресе десктоптық бағдарламалық жасақтамамен салыстырғанда, жақсы сатылады, себебі оны сатып алу оңай. Адамдар бір нәрсені сатып алуға шешім қабылдайды, содан кейін оны сатып алады деп екі бөлек қадам ретінде ойлауыңыз мүмкін. Viaweb-ке дейін мен де осы сұрақ туралы ойлаған шамамда солай ойлайтынмын. Шын мәнінде, екінші қадам біріншіге қайта әсер етуі мүмкін: егер бір нәрсені сатып алу қиын болса, адамдар оны қалайтын-қаламайтыны туралы ойын өзгертеді. Және керісінше: сатып алу оңай болған кезде, сіз затты көбірек сатасыз. Мен Amazon болғандықтан кітаптарды көбірек сатып аламын. Вебке негізделген бағдарламалық жасақтама — бұл әлемдегі сатып алуға ең оңай нәрсе, әсіресе егер сіз онлайн демо-нұсқасын жаңа ғана қолданып көрген болсаңыз. Пайдаланушылар несие картасының нөмірін енгізуден артық көп нәрсе жасамауы керек. (Оларды көбірек нәрсе жасауға мәжбүрлеу — өз мойныңызға алған қауіп-қатер.)
Кейде вебке негізделген бағдарламалық жасақтама қайта сатушы (reseller) ретінде әрекет ететін интернет-провайдерлер (ISP) арқылы ұсынылады. Бұл — жаман идея. Серверлерді өзіңіз басқаруыңыз керек, өйткені аппараттық және бағдарламалық құралдарды үнемі жетілдіріп отыруыңыз қажет. Егер сіз серверлерді тікелей бақылаудан бас тартсаңыз, вебке негізделген қосымшаларды әзірлеудің көптеген артықшылықтарынан айырыласыз.
Біздің бірнеше бәсекелесіміз осылайша өз аяғына өзі оқ атты — көбінесе, меніңше, бұл үлкен әлеуетті арнаға қызыққан костюмділердің (басшылардың) кесірінен болды, олар осы арна арқылы сатқысы келген өнімді бүлдіріп алатынын түсінбеді. Вебке негізделген бағдарламалық жасақтаманы интернет-провайдерлер арқылы сату — бұл сушиді автоматтар арқылы сатумен бірдей.
Тұтынушылар
Тұтынушылар кім болады? Viaweb-те олар бастапқыда жеке тұлғалар мен шағын компаниялар болды және бұл вебке негізделген қосымшалар үшін қағидаға айналады деп ойлаймын. Бұл жаңа нәрселерді сынап көруге дайын пайдаланушылар, бір жағынан олар икемдірек болғандықтан, екінші жағынан жаңа технологияның шығындары азырақ болғанын қалайтындықтан.
Вебке негізделген қосымшалар көбінесе үлкен компаниялар үшін де ең жақсы нәрсе болады (бірақ олар мұны баяу түсінеді). Ең жақсы интранет — бұл Интернет. Егер компания нағыз вебке негізделген қосымшаларды қолданса, бағдарламалық жасақтама жақсырақ жұмыс істейді, серверлер жақсырақ басқарылады және қызметкерлер кез келген жерден жүйеге қол жеткізе алады.
Бұл тәсілге қарсы дәлел әдетте қауіпсіздікке келіп тіреледі: егер қызметкерлер үшін кіру оңайырақ болса, бұл қаскүнемдер үшін де солай болады. Кейбір ірі саудагерлер клиенттердің несие карталары туралы ақпарат өз серверлерінде қауіпсіз болады деп ойлағандықтан, Viaweb-ті қолдануға құлықсыз болды. Бұл ойды дипломатиялық түрде жеткізу оңай болған жоқ, бірақ шын мәнінде бұл деректер олардың қолдарына қарағанда біздің қолымызда әлдеқайда қауіпсіз еді. Қауіпсіздікті басқару үшін кім жақсы мамандарды жалдай алады: бүкіл бизнесі серверлерді іске қосу болып табылатын технологиялық стартап па, әлде киім сататын дүкен бе? Бізде қауіпсіздікке алаңдайтын жақсырақ мамандар ғана емес, біз бұл туралы көбірек бас қатырдық. Егер біреу киім дүкенінің серверлеріне бұзып кірсе, бұл ең көбі бір саудагерге әсер етеді, оны жасырып қалуға болар еді және ең нашар жағдайда бір адам жұмыстан шығарылуы мүмкін. Егер біреу біздікін бұзып кірсе, бұл мыңдаған саудагерге әсер етуі мүмкін, бәлкім, CNet жаңалықтарына шығар еді және біздің бизнесімізді күйретуі мүмкін еді.
Егер ақшаңызды қауіпсіз сақтағыңыз келсе, оны үйде матрацтың астында ұстайсыз ба, әлде банкке саласыз ба? Бұл дәлел сервер әкімшілігінің барлық аспектілеріне қатысты: тек қауіпсіздікке ғана емес, сонымен бірге тоқтаусыз жұмыс істеу уақытына (uptime), өткізу қабілетіне, жүктемені басқаруға, сақтық көшірме жасауға және т.б. Біздің өмір сүруіміз осы нәрселерді дұрыс орындауға байланысты болды. Ойыншық өндіруші үшін қауіпті ойыншық, немесе тамақ өңдеуші үшін сальмонелланың өршуі қандай қауіпті болса, сервердегі ақаулар біз үшін сондай үлкен кесел еді.
Вебке негізделген қосымшаларды пайдаланатын ірі компания белгілі бір деңгейде IT-ді аутсорсингке береді. Бұл қаншалықты түбегейлі болып көрінсе де, менің ойымша, бұл жалпы алғанда жақсы идея. Компаниялар ішкі жүйелік әкімшілерден гөрі осылайша жақсырақ қызмет алуы мүмкін. Жүйелік әкімшілер қырсық әрі жауапсыз болып кетуі мүмкін, өйткені олар бәсекелестік қысымға тікелей ұшырамайды: сатушы тұтынушылармен қарым-қатынас жасауы керек, ал әзірлеуші бәсекелестердің бағдарламалық жасақтамасымен күресуі керек, бірақ жүйелік әкімші, кәрі бойдақ сияқты, өзін тәртіпте ұстайтын сыртқы күштерге сирек тап болады. [10] Viaweb-те бізді тәртіпте ұстайтын сыртқы күштер жеткілікті болды. Бізге қоңырау шалған адамдар жай ғана әріптестер емес, тұтынушылар еді. Егер сервер тұрып қалса, біз орнымыздан ұшып тұратынбыз; бұл туралы ойлаудың өзі, көп жылдар өтсе де, бойымды адреналинге толтырады.
Сондықтан вебке негізделген қосымшалар, әдетте, үлкен компаниялар үшін де дұрыс жауап болады. Алайда, олар мұны десктоп компьютерлер кезіндегідей ең соңында түсінетін болады. Және белгілі бір дәрежеде сол себепті: ірі компанияларды оларға қымбатырақ бірдеңе қажет екеніне сендіру үлкен ақша тұратын болады.
Бай тұтынушылар арзан шешімдер жақсырақ болған кезде де қымбат шешімдерді сатып алуға бейім келеді, өйткені қымбат шешімдерді ұсынатын адамдар оларды сату үшін көбірек ақша жұмсай алады. Viaweb-те біз әрдайым осыған қарсы тұрдық. Біз бірнеше ірі саудагерлерден айырылып қалдық, өйткені веб-консалтингтік фирмалар оларды өз серверіндегі арнайы жасалған онлайн дүкен үшін жарты миллион доллар төлесе, әлдеқайда жақсы болатынына сендірді. Әдетте, бұл оларға еш жақсылық әкелмеді, мұны Рождестволық сауда маусымы келіп, олардың серверіндегі жүктемелер артқан кезде бірнешеуі түсінді. Viaweb осы саудагерлердің көпшілігі алған нәрсеге қарағанда әлдеқайда күрделі болды, бірақ біздің оларға мұны айтуға шамамыз жетпеді. Айына 300 долларға біз тұтынушыларға презентация жасау үшін әдемі киінген және беделді көрінетін адамдар тобын жіберуге мүмкіндігіміз болмады.
Ірі компаниялар төлейтін артық төлемнің үлкен бөлігі — оларға қымбат заттарды сату құны. (Егер Қорғаныс министрлігі әжетхана орындықтары үшін мың доллар төлесе, бұл ішінара әжетхана орындықтарын мың долларға сату қымбат тұратындықтан.) Және бұл интранет бағдарламалық жасақтамасының нашар идея болғанына қарамастан, әрі қарай дами беруінің бір себебі. Бұл жай ғана қымбатырақ. Бұл жұмбақтың шешімін табу мүмкін емес, сондықтан ең жақсы жоспар — алдымен кішігірім тұтынушыларға бағытталу. Қалғандары уақыт өте келе келеді.
Сервердің ұрпағы
Бағдарламалық жасақтаманы серверде іске қосу — жаңа нәрсе емес. Шын мәнінде, бұл ескі модель: мейнфрейм қосымшаларының барлығы серверге негізделген. Егер серверге негізделген бағдарламалық жасақтама осындай жақсы идея болса, неге ол өткен жолы жеңілді? Неліктен десктоп компьютерлер мейнфреймдерді көлеңкеде қалдырды?
Бастапқыда десктоп компьютерлер айтарлықтай қауіп төндіретіндей көрінбеді. Алғашқы пайдаланушылардың барлығы хакерлер — немесе сол кезде аталғандай, әуесқойлар еді. Олар микрокомпьютерлерді арзан болғандықтан ұнатты. Алғаш рет жеке компьютеріңіз болуы мүмкін болды. «Дербес компьютер» тіркесі қазір тіліміздің бір бөлігі болып табылады, бірақ ол алғаш қолданылған кезде бүгінгі таңда «дербес спутник» тіркесі сияқты әдейі батыл естілетін.
Неліктен десктоп компьютерлер үстемдікке ие болды? Менің ойымша, оларда жақсырақ бағдарламалық жасақтама болғандықтан. Ал микрокомпьютерлік бағдарламалық жасақтаманың жақсырақ болуының себебі — оны шағын компаниялар жаза алғандығында деп ойлаймын.
Көптеген адамдар стартаптардың алғашқы кезеңде қаншалықты нәзік және сенімсіз болатынын түсінбейді деп ойлаймын. Көптеген стартаптар кездейсоқ дерлік басталады — күндізгі жұмысы бар немесе оқып жүрген екі жігіт, егер болашағы бар болып көрінсе, компанияға айналуы мүмкін бір нәрсенің прототипін жазады. Осы дернәсілдік (бастапқы) кезеңде кез келген елеулі кедергі стартапты бірден тоқтатады. Мейнфрейм бағдарламалық жасақтамасын жазу басында тым көп міндеттемені қажет етті. Әзірлеу машиналары қымбат болды және тұтынушылар ірі компаниялар болатындықтан, оларға сату үшін әсерлі көрінетін сату бөлімі қажет болатын. Мейнфрейм бағдарламалық жасақтамасын жазу үшін стартап бастау — кешке Apple II-де бірдеңе құрастыра салудан әлдеқайда салмақты іс еді. Сондықтан мейнфрейм қосымшаларын жазатын көптеген стартаптар болған жоқ.
Десктоп компьютерлердің келуі көптеген жаңа бағдарламалардың пайда болуына түрткі болды, өйткені оларға арналған қосымшаларды жазу бастапқы сатыдағы стартаптар үшін қолжетімді мақсат болып көрінді. Әзірлеу арзан болды және тұтынушылар компьютерлік дүкендер арқылы немесе тіпті пошта арқылы байланысуға болатын жеке адамдар еді.
Десктоп компьютерлерді кең аудиторияға алып шыққан қосымша — бірінші электрондық кесте VisiCalc болды. Оны шатырда жұмыс істейтін екі жігіт жазған болатын, бірақ ол мейнфреймнің ешқандай бағдарламалық жасақтамасы істей алмайтын нәрселерді жасады. [11] VisiCalc өз уақытында соншалықты үлкен серпіліс болды, адамдар Apple II-ні тек осы бағдарламаны іске қосу үшін сатып алды. Және бұл үрдістің бастауы болды: десктоп компьютерлер стартаптар оларға бағдарламалық жасақтама жазғандықтан жеңіске жетті.
Серверге негізделген бағдарламалық жасақтама бұл жолы жақсы болатын сияқты, өйткені оны стартаптар жазады. Қазір компьютерлер соншалықты арзан, сондықтан сіз біз сияқты десктоп компьютерді сервер ретінде пайдаланып бастай аласыз. Қымбат емес процессорлар жұмыс станциялары нарығын жұтып қойды (қазір бұл сөзді сирек естисіз) және серверлер нарығының көп бөлігін жаулап алды; Интернеттегі кез келген жүктеме сияқты жоғары жүктемелермен жұмыс істейтін Yahoo серверлерінде де сіздің десктоп компьютеріңіздегідей қымбат емес Intel процессорлары бар. Ал бағдарламалық жасақтаманы жазып болғаннан кейін оны сату үшін сізге бар болғаны веб-сайт қажет. Біздің барлық дерлік пайдаланушыларымыз біздің сайтқа ауызша тараған сөздер мен баспасөздегі сілтемелер арқылы тікелей келді. [12]
Viaweb қарапайым бастапқы кезеңдегі стартап еді. Біз компания құрудан қорықтық, сондықтан алғашқы бірнеше ай бойы кез келген сәтте тоқтата салатын эксперимент ретінде қарап, өзімізді жұбаттық. Бақытымызға орай, техникалық мәселелерден басқа кедергілер аз болды. Біз бағдарламалық жасақтаманы жазып жатқан кезде біздің веб-серверіміз сыртқы әлемге модемдік желі (dialup) арқылы қосылған, әзірлеу үшін пайдаланылған сол десктоп компьютері болды. Бұл кезеңдегі біздің жалғыз шығынымыз тамақ пен жалдау ақысы ғана еді.
Қазір стартаптар үшін веб-негізделген бағдарламалық жасақтама жазуға бұрынғыдан да көбірек себеп бар, өйткені десктоптық БЖ жазудың қызығы әлдеқайда азайып кетті. Егер қазір десктоптық БЖ жазғыңыз келсе, оны Microsoft-тың талаптарымен жасайсыз: олардың API-ларын шақырып, қатеге толы операциялық жүйесінің кемшіліктерін айналып өтуге мәжбүр боласыз. Ал егер сәті түсіп, жұртқа кең тарайтын бірдеңе жаза алсаңыз, Microsoft үшін бар болғаны нарықты зерттеп бергеніңізді түсінуіңіз мүмкін.
Егер компания стартаптар негіз ретінде қолданатын платформа жасағысы келсе, оны хакерлердің өздері қолданғысы келетіндей етуі керек. Бұл оның қымбат емес және жақсы жобаланған болуы керек дегенді білдіреді. Mac алғаш шыққан кезде хакерлер арасында танымал болды, олардың көбі оған арнап БЖ жазды. [13] Windows жағдайында мұны азырақ көресіз, өйткені хакерлер оны қолданбайды. Бағдарламалық жасақтаманы жақсы жазатын адамдар қазір әдетте Linux немесе FreeBSD қолданады.
Біз десктоптық БЖ жазу үшін стартап бастар ма едік деп ойламаймын, өйткені десктоптық БЖ Windows жүйесінде жұмыс істеуі керек, ал Windows-қа арнап БЖ жазбас бұрын оны өзіміз қолдануға мәжбүр болар едік. Веб бізге Windows-ты айналып өтіп, Unix-те жұмыс істейтін бағдарламалық жасақтаманы браузер арқылы тікелей пайдаланушыларға жеткізуге мүмкіндік берді. Бұл жиырма бес жыл бұрын ДК-лердің (персоналды компьютерлердің) пайда болуы секілді еркіндік сыйлайтын перспектива.
Microsoft
Кезінде десктоп компьютерлер алғаш шыққанда, бәрі қорқатын алып IBM болатын. Қазір мұны елестету қиын, бірақ сол кездегі сезім менің есімде жақсы сақталған. Қазіргі қорқынышты алып — Microsoft, және олар өздеріне төніп тұрған қауіпке IBM сияқты соқыр қарайды деп ойламаймын. Өйткені, Microsoft өз бизнесін IBM-нің назарынан тыс қалған дәл сол соқыр аймақта әдейі құрған еді.
Мен бұған дейін анама десктоп компьютердің онша қажеті жоқ екенін айтқанмын. Пайдаланушылардың көпшілігіне де қажет емес шығар. Бұл Microsoft үшін үлкен мәселе және олар мұны біледі. Егер қолданбалар қашықтағы серверлерде жұмыс істесе, Windows ешкімге керек болмай қалады. Microsoft не істейді? Олар десктопты бақылау мүмкіндігін пайдаланып, бағдарламалық жасақтаманың бұл жаңа буынына тосқауыл қоя ала ма немесе оны шектей ала ма?
Менің болжамымша, Microsoft сервер мен десктоптың қандай да бір буданын (гибридін) дамытады, онда операциялық жүйе олардың бақылауындағы серверлермен бірлесе жұмыс істейтін болады. Ең болмағанда, файлдар мұны қалайтын пайдаланушылар үшін орталықтандырылған түрде қолжетімді болады. Microsoft егер амалы табылса, есептеулерді толығымен серверде жасап, клиент ретінде тек браузерді ғана қалдыру сияқты шектен шыққан қадамға барады деп күтпеймін. Егер сізге клиент ретінде тек браузер қажет болса, клиенттік жақта сізге Microsoft керек емес, ал егер Microsoft клиентті бақыламаса, пайдаланушыларды өздерінің серверлік қолданбаларына итермелей алмайды.
Меніңше, Microsoft-қа бұл жынды қайтадан шөлмекке тығу қиынға соғады. Клиенттердің түрлері тым көп болғандықтан, олардың бәрін бақылау мүмкін болмайды. Ал егер Microsoft қолданбалары тек кейбір клиенттерде ғана жұмыс істесе, бәсекелестер кез келген клиенттен жұмыс істейтін қолданбаларды ұсыну арқылы олардың алдын орап кете алады. [14]
Веб-негізделген қолданбалар әлемінде Microsoft-қа автоматты түрде берілетін орын жоқ. Олар өздеріне орын ойып алуы мүмкін, бірақ десктоптық қолданбалар әлемінде үстемдік еткендей бұл жаңа әлемде үстемдік ете алады деп ойламаймын.
Мәселе оларды бәсекелестері сүріндіреді дегенде емес, олардың өздері сүрінетінінде. Веб-негізделген БЖ-ның өсуімен олар тек техникалық қиындықтармен ғана емес, өздерінің қиялымен (өз-өзін алдаумен) бетпе-бет келеді. Оларға қажет нәрсе — өздерінің қазіргі бизнесін каннибализациялау (өзін-өзі жеу), бірақ олардың бұған батылы баратынын көре алмай отырмын. Оларды осы күнге дейін жеткізген бірбеткей табандылық енді олардың өздеріне қарсы жұмыс істейтін болады. IBM дәл осындай жағдайда болған еді және олар бұл жағдайды еңсере алмады. IBM микрокомпьютерлер бизнесіне кеш әрі құлықсыз кірді, өйткені олар өздерінің сауын сиыры — мейнфреймдік есептеулерге қауіп төндіруге батпай, екіұдай күйде болды. Microsoft та дәл солай десктопты сақтап қалғысы келіп тұралап қалады. Сауын сиыр мойныңа мініп алған оңбаған бір ауыр жүкке айналуы мүмкін.
Мен серверлік қолданбаларда ешкім үстемдік етпейді деп отырған жоқпын. Түбінде әйтеуір біреу үстемдік орнататын шығар. Бірақ микрокомпьютерлердің алғашқы күндеріндегідей, көңілді хаостың ұзақ әрі тамаша кезеңі болады деп ойлаймын. Бұл стартаптар үшін керемет уақыт болған еді. Көптеген шағын компаниялар керемет дүниелер жасау арқылы гүлденіп, жетістікке жетті.
Стартаптар, бірақ бұрынғыдан да бетер
Классикалық стартап — жылдам әрі бейресми, адамдары аз және ақшасы шектеулі болады. Сол аз ғана адам өте қатты жұмыс істейді және технология олар қабылдаған шешімдердің нәтижесін еселеп арттырады. Егер олар жеңсе, үлкен жеңіске жетеді.
Веб-негізделген қолданбалар жазатын стартапта сіз стартаптармен байланыстыратын барлық нәрсе шегіне жетеді. Сіз тіпті одан да аз адаммен және одан да аз ақшамен өнімді жазып, іске қоса аласыз. Сізге бұрынғыдан да жылдам болу керек және бұрынғыдан да бейресми болуға еркіңіз бар. Сіз өнімді тура мағынасында пәтердің қонақ бөлмесінде отырған үш жігітпен және провайдерде орналасқан бір сервермен іске қоса аласыз. Біз дәл солай жасадық.
Уақыт өте келе командалар кішірейе түсті, жылдамырақ және бейресми бола түсті. 1960 жылы бағдарламалық жасақтама жасау дегеніміз — мүйізді жиекті көзілдірік таққан және жіңішке қара галстук таққан бір бөлме толы ер адамдардың IBM-нің код жазу бланкілерінде күніне он жол кодты тынымсыз жазуын білдіретін. 1980 жылы бұл кеңсеге джинсымен келіп, vt100 терминалдарына мәтін теретін сегіз-он адамнан тұратын команда болды. Қазір бұл — қонақ бөлмеде ноутбуктермен отырған екі-үш жігіт. (Джинсы кию бейресмиліктің соңғы нүктесі емес болып шықты).
Стартаптар — күйзеліске толы дүние, ал бұл, өкінішке қарай, веб-негізделген қолданбаларда да шегіне жетеді. Көптеген бағдарламалық жасақтама компанияларында, әсіресе бастапқы кезеңде, әзірлеушілер үстелдің астында ұйықтайтын кезеңдер болады және т.с.с. Веб-негізделген БЖ-ның алаңдататын тұсы — мұның әдеттегі қалыпты жағдайға айналуына ештеңе кедергі бола алмайды. Үстел астында ұйықтау туралы әңгімелер әдетте: «ақыры өнімді шығардық та, бәріміз үйге барып бір апта бойы ұйықтадық» деп аяқталады. Веб-негізделген БЖ ешқашан «шығарылып» бітпейді. Қалағаныңызша күн сайын 16 сағаттан жұмыс істей аласыз. Ал сіз бұлай істей алатындықтан, әрі бәсекелестеріңіз де бұлай істей алатындықтан, сіз осылай істеуге мәжбүр боласыз. Қолыңнан келеді, демек солай істеуге міндеттісің. Бұл — Паркинсон заңының керісінше жұмыс істеуі.
Ең жаманы — жұмыс сағаттары емес, жауапкершілік. Бағдарламашылар мен жүйелік әкімшілердің дәстүрлі түрде бөлек-бөлек өз уайымдары болады. Бағдарламашылар багтарды (қателерді), ал жүйелік әкімшілер инфрақұрылымды уайымдауы керек. Бағдарламашылар бастапқы кодқа басымен кіріп, ұзақ күн өткізуі мүмкін, бірақ белгілі бір уақытта олар үйіне барып, оны ұмыта алады. Жүйелік әкімшілер жұмысты ешқашан толық тастап кете алмайды, бірақ оларды таңғы 4:00-де шақырған кезде де, олар әдетте аса күрделі ештеңе істеуге мәжбүр болмайды. Веб-негізделген қолданбаларда күйзелістің осы екі түрі бірігіп кетеді. Бағдарламашылар жүйелік әкімшіге айналады, бірақ әдетте бұл жұмысты көтеруге болатындай ететін нақты белгіленген шекараларсыз қалады.
Viaweb-те біз алғашқы алты айды тек бағдарлама жазумен өткіздік. Біз ерте кезеңдегі стартапқа тән әдеттегідей ұзақ сағаттар бойы жұмыс істедік. Десктоптық БЖ компаниясында бұл біздің барынша қатты жұмыс істеген бөлігіміз болар еді, бірақ келесі кезеңмен — серверімізге пайдаланушыларды қабылдай бастаған кезбен салыстырғанда, бұл демалыс сияқты көрінді. Viaweb-ті Yahoo-ға сатудың екінші ең үлкен пайдасы (ақшадан кейінгі) — осының барлығына деген түпкі жауапкершілікті үлкен компанияның мойнына арта салу мүмкіндігі болды.
Десктоптық БЖ пайдаланушыларды жүйелік әкімші болуға мәжбүрлейді. Ал веб-негізделген БЖ бағдарламашыларды соған мәжбүр етеді. Жалпы алғанда күйзеліс азырақ, бірақ бағдарламашылар үшін көбірек. Бұл міндетті түрде жаман жаңалық емес. Егер сіз үлкен компаниямен бәсекелесіп жатқан стартап болсаңыз, бұл — жақсы жаңалық. [15] Веб-негізделген қолданбалар бәсекелестеріңізден көбірек жұмыс істеу арқылы оларды басып озудың тікелей жолын ұсынады. Ешбір стартап одан артықты сұрамайды.
Тек жеткілікті деңгейде жақсы
Веб-негізделген қолданбаларды жазудан сізді қаймықтыруы мүмкін бір нәрсе — веб-беттердің UI (пайдаланушы интерфейсі) ретінде тым олқы соғуы. Бұл проблема, оны мойындаймын. Біз HTML мен HTTP-ге шынымен қосқымыз келген бірнеше нәрсе бар еді. Алайда ең бастысы — веб-беттердің жеткілікті деңгейде ғана жақсы болуы.
Бұл жерде алғашқы микрокомпьютерлермен ұқсастық бар. Ол машиналардағы процессорлар шын мәнінде компьютерлердің Орталық процессорлары (CPU) болуға арналмаған еді. Олар бағдаршамдар сияқты құрылғыларда қолданылуға арналған болатын. Бірақ Altair-ді жобалаған Эд Робертс сияқты жігіттер олардың жеткілікті деңгейде жақсы екенін түсінді. Осы чиптердің бірін сәл жадпен (алғашқы Altair-де 256 байт) және алдыңғы панельдегі ауыстырғыштармен біріктіруге болатын еді, сөйтіп сізде жұмыс істейтін компьютер пайда болатын. Өзіңіздің жеке компьютеріңіздің болуы соншалықты қызықты болғандықтан, қаншалықты шектеулі болса да, оларды сатып алғысы келетін адамдар көп болды.
Веб-беттер қолданбалардың интерфейсі болу үшін жасалмаған еді, бірақ олар жеткілікті деңгейде жақсы. Және пайдаланушылардың едәуір бөлігі үшін кез келген браузерден пайдалануға болатын бағдарламалық жасақтама интерфейстегі кез келген ыңғайсыздықты басып түсетін жеңіс болып табылады. Мүмкін сіз HTML көмегімен ең әдемі электрондық кестені жаза алмассыз, бірақ бірнеше адам әртүрлі жерден арнайы клиенттік бағдарламасыз бір уақытта қолдана алатын, немесе нақты уақыттағы деректер ағынын біріктіре алатын, немесе белгілі бір шарттар орындалғанда сізге хабарлама жібере алатын электрондық кестені жаза аласыз. Ең бастысы, сіз тіпті әлі атауы да жоқ қолданбалардың жаңа түрлерін жаза аласыз. VisiCalc жай ғана мейнфрейм қолданбасының микрокомпьютерлік нұсқасы емес еді — ол қолданбаның жаңа түрі болатын.
Әрине, серверлік қолданбалар міндетті түрде веб-негізделген болуы шарт емес. Басқа бір клиент түрін қолдануға да болар еді. Бірақ бұл жаман идея екеніне мен толықтай сенімдімін. Егер бәрі сіздің клиентіңізді орнатады деп топшылай алсаңыз, бұл өте ыңғайлы болар еді — тіпті олардың бәрі солай істейді деп өзіңізді оңай сендіріп те тастар едіңіз — бірақ егер олар орнатпаса, шаруаңыз бітті дей беріңіз. Веб-негізделген БЖ клиент туралы ешқандай алғышарт қоймайтындықтан, ол Веб жұмыс істейтін кез келген жерде жұмыс істейді. Бұл қазірдің өзінде үлкен артықшылық және жаңа веб-құрылғылар көбейген сайын бұл артықшылық тек арта түседі. Пайдаланушылар сізді жақсы көретін болады, өйткені бағдарламаңыз жай ғана жұмыс істейді, ал сіздің өміріңіз жеңілдейді, себебі оны әрбір жаңа клиентке бейімдеп әуре болмайсыз. [16]
Мен Вебтің дамуын кез келген адам сияқты жіті қадағалап отырғандаймын және клиенттермен не болатынын болжай алмаймын. Конвергенция келе жатқан сияқты, бірақ қай жерде? Мен жеңімпазды таңдай алмаймын. Болжай алатын бір нәрсем — AOL мен Microsoft арасындағы қақтығыс. Microsoft-тың .NET-і қандай болып шықса да, ол десктопты серверлермен байланыстыруды қамтитын шығар. Егер AOL қарсы күреспесе, олар не шетке ысырылады, не Microsoft-тың клиенттік және серверлік бағдарламаларының арасындағы жай құбырға айналады. Егер Microsoft пен AOL арасында клиенттер соғысы басталса, екеуінде де жұмыс істейтініне кепілдік беретін жалғыз нәрсе — Вебті қарап шығу болады, демек, веб-негізделген қолданбалар барлық жерде жұмыс істейтін жалғыз түр болып қалады.
Мұның бәрі қалай аяқталады? Мен білмеймін. Ал егер сіз веб-негізделген қолданбаларға бәс тіксеңіз, оны білудің қажеті де жоқ. Ешкім веб-шолуды бұзбайынша оны бұза алмайды. Веб бағдарламалық жасақтаманы жеткізудің жалғыз жолы болмауы мүмкін, бірақ бұл қазір жұмыс істеп тұрған және ұзақ уақыт бойы жұмыс істейтін жол. Веб-негізделген қолданбаларды әзірлеу арзан және оны ең кішкентай стартаптың өзі де жеткізе алады. Олар көп еңбекті қажет етеді және ерекше күйзелісті болып келеді, бірақ бұл стартаптардың мүмкіндігін тек жақсарта түседі.
Неге байқап көрмеске?
Э. Б. Уайт фермер досынан көптеген электр қоршауларында ток мүлдем жоқ екенін білгенде таңғалған екен. Сиырлар олардан аулақ жүруді үйреніп алады, содан кейін ток жүргізудің қажеті де болмай қалады. «Көтеріліңдер, сиырлар!» деп жазды ол, «Деспоттар қорылдап ұйықтап жатқанда, бостандықтарыңды алыңдар!»
Егер сіз бір күні стартап бастауды ойлап жүрген хакер болсаңыз, сізді бұдан тежеп тұрған екі нәрсе болуы мүмкін. Біріншісі — сіз бизнес туралы ештеңе білмейсіз. Екіншісі — бәсекелестіктен қорқасыз. Бұл екі қоршауда да ешқандай ток жоқ.
Бизнес туралы білуіңіз керек екі-ақ нәрсе бар: пайдаланушылар ұнататын нәрсе жасаңыз және тапқаныңыз жұмсағаныңыздан көп болсын. Егер осы екеуін дұрыс орындасаңыз, сіз көптеген стартаптардан озып кетесіз. Қалғанын бара-бара өзіңіз-ақ түсініп аласыз.
Сіз бастапқыда жұмсағаныңыздан көп таба алмауыңыз мүмкін, бірақ арадағы алшақтық жеткілікті деңгейде тез қысқарып жатса, бәрі жақсы болады. Егер бастағанда қаражатыңыз аз болса, бұл кем дегенде үнемшілдік әдетін қалыптастыруға көмектеседі. Неғұрлым аз жұмсасаңыз, жұмсағаныңыздан көп табу соғұрлым оңай болады. Бақытымызға орай, веб-негізделген қолданбаны іске қосу өте арзанға түсуі мүмкін. Біз оны 10 000 доллардан аз ақшамен іске қостық, ал бүгінде бұл одан да арзан болар еді. Бізге серверге мыңдаған доллар, ал SSL алу үшін тағы да мыңдаған доллар жұмсауға тура келді. (Сол кезде SSL бағдарламасын сататын жалғыз компания Netscape еді.) Қазір сіз SSL қосылған, әлдеқайда қуатты серверді біз кезінде тек интернет трафигі үшін төлеген сомадан да аз ақшаға жалға ала аласыз. Қазір сіз веб-негізделген қолданбаны сәнді кеңсе креслосының құнынан да арзанға іске қоса аласыз.
Пайдаланушылар ұнататын дүние жасауға келетін болсақ, мынадай жалпы кеңестер бар. Алдымен өзіңіз қолданғыңыз келетіндей қарапайым әрі таза нәрсе жасаудан бастаңыз. 1.0 нұсқасын тез шығарыңыз, содан кейін пайдаланушыларды мұқият тыңдай отырып, БЖ-ны жақсартуды жалғастырыңыз. Тұтынушы әрқашан құқылы, бірақ әртүрлі тұтынушылар әртүрлі мәселелерде құқылы; ең қарапайым пайдаланушылар нені оңайлату және айқындау керектігін көрсетеді, ал ең озық пайдаланушылар қандай функцияларды қосу керектігін айтады. Бағдарламалық жасақтаманың ең керемет қасиеті — оның оңайлығы, бірақ бұған жетудің жолы — пайдаланушының таңдауын шектеу емес, әдепкі баптауларды дұрыс жасау. Егер бәсекелестеріңіздің БЖ-сы нашар болса, масаттанып кетпеңіз; БЖ-ны салыстыратын өлшем — оның қандай бола алатыны, қазіргі бәсекелестеріңіздің қолында бары емес. Өз бағдарламаңызды өзіңіз үнемі қолданыңыз. Viaweb онлайн-дүкен құрастырушы болуы керек еді, бірақ біз оны өзіміздің жеке сайтымызды жасау үшін де пайдаландық. Маркетологтарды, дизайнерлерді немесе өнім менеджерлерін тек олардың лауазымдары үшін ғана тыңдамаңыз. Егер олардың жақсы идеялары болса, пайдаланыңыз, бірақ шешім қабылдау — сіздің қолыңызда; БЖ-ны бағдарламалық жасақтама туралы аздап білетін дизайнерлер емес, дизайнды түсінетін хакерлер жобалауы керек. Егер сіз бағдарламалық жасақтаманы жүзеге асырумен қатар жобалай алмасаңыз, стартап бастамаңыз.
Енді бәсекелестік туралы сөйлесейік. Сіз өзіңіз сияқты хакерлер тобынан емес, кеңселері, бизнес-жоспарлары, сатушылары және т.б. бар нақты компаниялардан қорқатын шығарсыз, солай ма? Шын мәнінде, олар сізден, сіз олардан қорыққаннан гөрі қаттырақ қорқады және бұл өте орынды. Бірнеше хакерге кеңсе жалдауды немесе сатушыларды жалдауды үйреніп алу кез келген көлемдегі компанияға бағдарламалық жасақтама жазғызуға қарағанда әлдеқайда оңай. Мен екі жағында да болдым және мұны жақсы білемін. Viaweb-ті Yahoo сатып алған кезде, мен кенеттен үлкен компанияда жұмыс істеп жатқанымды көрдім, бұл беліңнен келетін суда жүгіруге тырысқанмен бірдей болды.
Мен Yahoo-ды жамандағым келмейді. Оларда жақсы хакерлер болды, ал жоғары басшылық нағыз істің көзін табатындар еді. Үлкен компания үшін олар ерекше болатын. Бірақ олардың өнімділігі кішкентай стартаптың өнімділігінің шамамен оннан бір бөлігіндей ғана еді. Ешбір үлкен компания бұдан әлдеқайда жақсырақ істей алмайды. Microsoft-тың қорқыныштылығы — сондай алып компанияның бағдарламалық жасақтаманы мүлдем жасай алатындығында. Олар жүре алатын тау сияқты.
Қорықпаңыз. Microsoft жасай алмайтын нәрселердің көбін сіз жасай аласыз, дәл олар жасай алатын нәрсені сіз жасай алмайтындай. Және сізді ешкім тоқтата алмайды. Веб-негізделген қолданбаларды жасау үшін ешкімнен рұқсат сұраудың қажеті жоқ. Лицензиялық келісімдер жасасудың, бөлшек сауда дүкендеріндегі сөрелерден орын алудың немесе қолданбаңызды операциялық жүйемен бірге қосып ұсыну үшін біреудің алдында құрдай жорғалаудың қажеті жоқ. Сіз БЖ-ны тікелей браузерге жеткізе аласыз, және ешкім пайдаланушыларға вебті шарлауға тыйым салмайынша, сіз бен әлеуетті пайдаланушылар арасына тұра алмайды.
Сенбеуіңіз мүмкін, бірақ сізге уәде беремін, Microsoft сізден қорқады. Тоқмейілсіген орта буын менеджерлері қорықпауы мүмкін, бірақ Билл қорқады, өйткені ол 1975 жылы — бағдарламалық жасақтаманы жеткізудің жаңа тәсілі пайда болған соңғы ретте дәл сіз сияқты болған еді.
Ескертпелер
[1] Ақшаның көбі қызмет көрсетуде екенін түсінген жеңіл клиенттер жасайтын компаниялар әдетте аппараттық жасақтаманы онлайн қызметпен біріктіруге тырысты. Бұл тәсіл онша жақсы нәтиже бермеді, бұған бір жағынан тұрмыстық электрониканы жасау және онлайн қызметті жүргізу үшін екі түрлі компания қажет екендігі себеп болса, екінші жағынан пайдаланушылар бұл идеяны жек көрді. Ұстараны тегін беріп, оның жүзінен ақша табу Gillette үшін жұмыс істейтін шығар, бірақ ұстара веб-терминалға қарағанда әлдеқайда жеңіл міндеттеме. Ұялы телефон өндірушілері қызмет көрсетуден түсетін кірісті иемденуге тырыспай, жай ғана аппараттық жасақтаманы сатуға қанағаттанады. Интернет-клиенттер үшін де осы үлгі дұрыс болар еді. Егер біреу кез келген интернет-провайдер арқылы қосылуға болатын, веб-браузері бар әдемі ғана шағын құрылғыны сатса, елдегі әрбір технофоб оның біреуін сатып алар еді.
[2] Қауіпсіздік әрқашан кез келген дизайн шешімінен гөрі қателік жібермеуге көбірек байланысты, бірақ серверлік БЖ-ның табиғаты әзірлеушілерді қателік жібермеуге көбірек көңіл бөлуге мәжбүр етеді. Сервердің бұзылуы сондай үлкен зардап әкелуі мүмкін, сондықтан ASP-лер (бизнесте қалғысы келетіндер) қауіпсіздікке мұқият қарайтын болады.
[3] 1995 жылы біз Viaweb-ті бастаған кезде, Java апплеттері серверлік қолданбаларды әзірлеу үшін бәрі қолданатын технология болады деп есептелген еді. Апплеттер бізге ескірген идея болып көрінді. Клиентте іске қосу үшін бағдарламаларды жүктеп алу керек пе? Бағдарламаларды серверде іске қосып, мәселені түбегейлі шешкен оңайырақ емес пе. Біз апплеттерге аз уақыт жұмсадық, бірақ сансыз басқа стартаптар осы батпаққа тартылған болуы керек. Одан тірі шыққандар аз шығар, әйтпесе Microsoft компаниясы Explorer-дің ең соңғы нұсқасында Java-дан бас тартып, оңай құтылып кете алмас еді.
[4] Бұл тұжырым Тревор Блэквеллге тиесілі, ол былай деп қосты: «бағдарламалық жасақтаманы жазу құны оның көлеміне қарай сызықтықтан да жоғары қарқынмен артады. Бәлкім, бұл көбінесе ескі қателерді түзетуге байланысты шығар, ал егер барлық қателер тез табылса, құн сызықтық сипатқа жақынырақ болуы мүмкін».
[5] Багтың табуға ең қиын түрі — бір баг екіншісінің орнын толтырып тұратын құрама багтың бір түрі болуы мүмкін. Бір багты түзегенде, екіншісі көрінеді. Бірақ кінә түзетуде сияқты болып көрінеді, өйткені сіз өзгерткен ең соңғы нәрсе сол болды.
[6] Viaweb ішінде біз бір рет бағдарламамыздың ең жаман тұсын сипаттау бойынша конкурс өткіздік. Тұтынушыларды қолдау бөлімінің екі қызметкері әлі күнге дейін есіме түссе денем түршігетін жауаптарымен бірінші орынды бөлісіп алды. Біз екі мәселені де дереу түзеттік.
[7] Роберт Моррис сатып алушылар тапсырыс беру үшін пайдаланған тапсырыс беру жүйесін жазды. Тревор Блэквелл кескіндер генераторын және саудагерлер тапсырыстарды алу, статистиканы көру және домендік атауларды конфигурациялау және т.б. үшін пайдаланған басқарушы бағдарламаны (менеджерді) жазды. Мен саудагерлер өз сайттарын құру үшін пайдаланған редакторды жаздым. Тапсырыс беру жүйесі мен кескін генераторы C және C++ тілдерінде, басқарушы бағдарлама көбінесе Perl тілінде, ал редактор Lisp тілінде жазылды.
[8] Бағалық кемсітушілік (дискриминация) соншалықты кең таралған (бөлшек саудагердің сатып алу қабілеті сіз үшін бағаның төмендеуін білдіреді дегенін қаншалықты жиі естідіңіз?), сондықтан мен оған АҚШ-та 1936 жылғы Робинсон-Пэтман актісі бойынша тыйым салынғанын білгенде таңғалдым. Бұл заң қатаң түрде орындалмайтын сияқты.
[9] Наоми Кляйн No Logo кітабында «қалалық жастар» ұнататын киім брендтері дүкеннен ұрлық жасаудың алдын алуға аса қатты тырыспайды, өйткені олардың мақсатты нарығында ұрылар сән көшбасшылары болып табылады дейді.
[10] Компаниялар көбінесе нені аутсорсингке беру керектігін және нені бермеу керектігін ойлайды. Мүмкін болатын жауаптардың бірі: бәсекелестік қысымға тікелей ұшырамайтын кез келген жұмысты аутсорсингке беріңіз, өйткені оны аутсорсингке беру оны сол арқылы бәсекелестік қысымға ұшыратады.
[11] Бұл екі жігіт Дэн Бриклин мен Боб Франкстон еді. Дэн бірнеше күнде Basic тілінде прототип жазды, содан кейін келесі жыл бойы олар бірге (негізінен түнде) 6502 машиналық тілінде жазылған неғұрлым қуатты нұсқаны жасау үшін жұмыс істеді. Дэн ол кезде Гарвард бизнес мектебінде оқитын, ал Бобтың ресми түрде БЖ жазатын күндізгі жұмысы бар еді. «Бизнес бастауда ешқандай үлкен тәуекел болған жоқ», — деп жазды Боб, «Егер ол сәтсіз болса, сәтсіз болар еді. Оқасы жоқ».
[12] Бұл мен айтқандай оңай емес. Ауызша таралудың (сарафандық радионың) басталуы үшін азапты түрде ұзақ уақыт қажет болды және біз айына 16 000 долларға PR агенттігін (мойындау керек, бұл саладағы ең үздігі) жалдағанға дейін баспасөзде көп жариялана қойған жоқпыз. Дегенмен, жалғыз маңызды арна біздің өз веб-сайтымыз болғаны рас еді.
[13] Егер Mac соншалықты керемет болса, ол неге жеңілді? Тағы да сол шығын мәселесі. Microsoft бағдарламалық жасақтама бизнесіне назар аударды және Apple-дің аппараттық жасақтамасына арзан құрамдас бөліктер жеткізушілердің тобырын қарсы қойды. Сондай-ақ маңызды кезеңде билікті костюмділердің (шенеунік менеджерлердің) қолға алуы да көмектесе қойған жоқ.
[14] Веб-негізделген қолданбаларға көмектесетін және БЖ-ның келесі буынының Microsoft-тың тасасында қалып қоймауына көмектесетін бір нәрсе — жақсы ашық бастапқы кодты браузер болар еді. Mozilla — ашық бастапқы кодты, бірақ тым ұзақ уақыт бойы корпоративтік БЖ болғандықтан зардап шеккен сияқты. Белсенді қолдау көрсетілетін шағын, жылдам браузер өз алдына керемет нәрсе болар еді және бұл компанияларды шағын веб-құрылғылар жасауға ынталандыруы мүмкін еді.
Сонымен қатар, дұрыс ашық бастапқы кодты браузер HTTP мен HTML-дің одан әрі дамуына себеп болар еді (мысалы, Perl дамыған сияқты). Бұл веб-негізделген қолданбаларға сілтемені таңдау мен оған өту арасындағы айырмашылықты ажырата білуге үлкен көмек берер еді; мұны істеу үшін бір сұраныста бірнеше URL-ге рұқсат беру үшін HTTP-ді сәл ғана жетілдіру жеткілікті болар еді. Каскадты мәзірлер де жақсы болар еді.
Егер әлемді өзгерткіңіз келсе, жаңа Mosaic жазыңыз. Тым кеш деп ойлайсыз ба? 1998 жылы көптеген адамдар жаңа іздеу жүйесін шығару тым кеш деп ойлады, бірақ Google олардың қателескенін дәлелдеді. Егер қазіргі нұсқалар жеткілікті деңгейде нашар болса, жаңа бірдеңе үшін әрқашан орын табылады. Оның алдымен барлық тегін ОЖ-лерде жұмыс істейтініне көз жеткізіңіз — жаңа дүниелер олардың пайдаланушыларынан басталады.
[15] Бұл туралы жеке тәжірибесінен кез келген адамнан артық білетін Тревор Блэквелл былай деп жазады:
«Мен тіпті арырақ барып, серверлік бағдарламалық жасақтаманың бағдарламашылар үшін тым қиын болғандықтан, ірі компаниялардан түбегейлі экономикалық ауысуға әкелетінін айтар едім. Ол бағдарламашылардан тек өз компаниясы болған кезде ғана беруге дайын болатын қарқындылық пен берілгендікті талап етеді. БЖ компаниялары аса талап етпейтін ортада жұмыс істеу үшін білікті адамдарды жалдай алады және қиындықтарға төзу үшін біліксіз адамдарды жалдай алады, бірақ олар жанын салып тынымсыз жұмыс істеу үшін жоғары білікті адамдарды жалдай алмайды. Капитал енді қажет болмағандықтан, ірі компаниялардың ұсынатын ештеңесі жоқ».
[16] Бұл эссенің түпнұсқа нұсқасында мен Javascript-тен аулақ болуға кеңес берген едім. Бұл 2001 жылы жақсы жоспар болды, бірақ Javascript қазір жұмыс істейді.
Осы мақаланың нобайларын оқып шыққандары үшін Сара Харлинге, Тревор Блэквеллге, Роберт Морриске, Эрик Реймондқа, Кен Андерсонға және Дэн Гиффинге; VisiCalc туралы ақпарат бергені үшін Дэн Бриклин мен Боб Франкстонға; және BBN-де сөз сөйлеуге шақырғаны үшін тағы да Кен Андерсонға алғыс айтамын.