Selle teema teemad on nii laiaulatuslikud ja võimalike lähenemisviiside poolest mitmekesised, et iga realistlik vastus vältimatutele küsimustele võib osutada ainult üldisele teele. Paljud inimesed soovivad ja loodavad tänapäeval luua dünaamilisi (andmepõhiseid) veebipõhiseid esitusi, mille arhitektuur mahutab hõlpsasti uut materjali, läbivaatamist ja külastajate suhtlust. Selgitatud on näiteks dünaamiline veebisait. Kuigi kvaliteetsete projektide eesmärk on kõigi usinate inimeste käeulatuses, oleks viga alahinnata seda, mis lõppkokkuvõttes on sisuliselt keeruline ülesanne, eriti mis tahes tulevase projekti tehnilistes objektides. Isegi kõige lihtsamad dünaamilised veebikohad nõuavad piisavaid oskusi erinevatel erialadel. Hädavajalike eesmärkide saavutamisel ei saa keegi kõrvale kalduda heast andmebaasikujundusest. Ainuüksi selles distsipliinis ettevalmistamine on oluline (kuid mitte välistav) töö. Kui meil on projekti eesmärkide kokkuvõte, peame nägema ette usaldusväärsed vahendid nende saavutamiseks. Seejärel on meil valida programmeerimiskeeled või tööriistad, mis põhinevad ideaalse projektiarhitektuuri visioonil. Tervikpildi nägemine algusest peale on siis kõige olulisem oskus üldse.
1
Mõelge sellele, millised tööriistad ja protsessid teie eesmärke saavutavad. Kuna iga dünaamilise veebikohaloleku keskne tuum on selle andmebaas ja andmete töötlemine, on meie esimene oluline eesmärk teha andmebaasimootori osas kaugeleulatuv otsus. Ei ole hea mõte loota, et teete sellise otsuse juhuslikult vaid mõnel esmapilgul kõige mõistlikumal viisil. Selle esimese otsuse oluline eesmärk on planeerida meie projekt viisil (koos tööriistade ja andmebaasimootoritega), mis toetab teie tegevust. vajadusi kogu teekonnal läbi tuleviku, mille puhul, kuna tegite õiged esialgsed otsused, tuginete tõhusalt oma esialgsele alusele, tõhusalt ja ilma takistusteta. See tähendab, et näiteks ideaaljuhul pole teie valitud andmebaasimootor lihtsalt lihtne või näiliselt lihtne täna kasutusele võtta; algusest peale peab see olema mootor, mis toetab teie järgnevaid töötlemisnõudeid. Mõnikord mõjutavad kaubanduslikud kaalutlused selliseid valikuid veelgi. Millised mootorid on külastamismahukad (ja kulukad)? Millised mootorid on juurutustes praktiliselt osalemisvabad, mis toetavad töötlemise eesmärke, mida teie lõplik projekt peab säilitama? Üldiselt tuleb järgida mootori valimist ühe kahest võimalikust paigutusest lähtuvalt. Selleks peate esmalt kaardistama oma põhilised tabelivajadused. Professionaalil pole isegi vaja seda kaarti koostada (olenemata sellest, kas tegemist on sadade või tuhandete tabelitega), sest tavaliselt näeb ta kohe, kas arhitektuur ja tulevased vajadused, mida vajate, on lugemis- või kirjutamismahukad. Seejärel valite sobiva andmebaasi selle üldise paigutuse põhjal ja võib-olla veelgi isikliku maitse ja kogemuste põhjal, kuna vastavate tarkvaraarenduse tööriistadega töötamine võib eeldada. MySQL on tavaline valik lugemisintensiivsete rakenduste jaoks. Paljud arendajad otsivad usaldusväärseteks intensiivseteks rakendusteks andmebaase, nagu PostgreSQL. Me arendame oma kalduvusi selliste oluliste tööriistade poole hoolika uurimistöö ja üldise tarkvaraarenduse tööstuse kogemuste kogumile tuginedes. Kulutusi saab üldiselt vältida, sest saadaval on väga heade tööriistade tasuta juurutamine. Otsime jõudlust nii lugemis- kui ka kirjutamisintensiivsetes keskkondades, töökindlust, halduse lihtsust ja minimeerimist ning valmis integreerimist tulevaste tarkvaraarendustööriistadega.
2
Valige oma tarkvaraarenduse tööriistad. Tarkvaraarendustööriistade valimisel tuleb arvestada kahe mudeliga. Väidetavalt “lihtsad” tööriistad on harva tegelikult lihtsad, kui projekt paratamatult rikub arendus- ja funktsionaalsusmustreid, millega “lihtsad” tööriistad üldiselt piirduvad. Kui soovite teha midagi peale “lihtsate” tööriistade, näiteks lisada keele või tõlkeparameetri dünaamiliselt loodud URL-idesse, võib seda “lihtsate” tööriistade abil teha palju keerulisem, et selleks võib vaja minna väga keerukaid programmeerimisoskusi. samavõrd kui petta lihtsat mustrit keerulisemate asjade tegemiseks. Heade projektide loomiseks peame valdama oma tööriistu. See ei muuda lihtsaid tööriistu parimaks valikuks ega kõige keerukamaid tööriistu keeruliseks ettepanekuks. “Lihtsa” arenduse lõks sisaldab üldiselt piiranguid, mille ületamine projektide vältimatu arengu käigus muutub väga kulukaks. Selliseid tööriistu on üldiselt tohutult palju, mis näiliselt vastavad sellistele vajadustele. Kuid tööriistade püsivuse muster reedab näilist tõsiasja, et see eesmärk on saavutatud; ja üldiselt leiame, et kõige keerukamad ja võimsamad tööriistad, järgides häid mustreid (või objektide ja teekide kättesaadavust), mitte ainult ei leevenda lihtsate tööriistade praktiliselt vältimatuid takistusi, vaid muudavad ka “sinna jõudmise” palju lihtsamaks protsessiks. Kui uurida olemasolevate tööriistade ulatust, siis üldiselt esitatakse esialgsetes arenduskontseptsioonides vähem terviklikke mudeleid ja paremaid kontseptsioone pakuvad hiljem tekkivad tööriistad (muidu pole neil võimalust ellu jääda juba võidetud turgudel). Kui me valime väidetavalt lihtsa tööriista, siis otsime arendusmustrit, mis on ühtaegu kohmakas ja ilma takistusteta. Algaja paradoks seisneb siis selles, et on raske näha nii kaugele, et suudaksime tajuda antud tööriistakomplekti programmeerimistakistusi. Mõned inimesed usuvad, et parimad tööriistad on kõige võimsamad ja kõige vähem piiravad projekti lähenemisviisi. Vabadus arendada seda, mida tahad ja vajad, tähendab sageli näiliselt lihtsate tööriistade üldise mudeli murdmist, mille väljakutsed võivad praktiliselt murda kõige kogenuma ja kogenuma tarkvarainseneri aju, sest sellise objekti edu saavutamine tähendab “lihtsa” muutmist. mudel teeb midagi, mida tal ei pruugi olla suutlikkust toetada. Kas näiteks “Ruby” on tõesti lihtsam tööriist kui põhiline C++ või C#? Ei. Tegelikult mitte, eriti kui peate elutähtsate funktsioonide pakkumiseks purustama Ruby lihtsa mudeli. Nagu Ruby, on GCC Linuxi ja OSX-i jaoks tasuta. Ruby on saadaval ka OSX-is – peate selle lihtsalt oma süsteemis avastama. Väidetavalt lihtsamatest tööriistadest on minu isiklik valik Ruby. Tõeliselt keerukatest tööriistadest domineerivad C++ ja C# veel kaua tulevikus; ja tõde on see, et need on ainsad takistusteta arenguvahendid. Nii et istuge sirgelt ja valmistuge tõsiseks õppimiseks, sest olenemata valitud teest ei pea te valdama mitte ainult oma tööriistu, vaid ka potentsiaalselt piiravaid mudeleid, millega need tööriistad teid lõpuks koormavad. Ruby on ilmselt palju puhtam kui peaaegu kõik tema “lihtsad” kaaslased. C++ on koormamata tipptaseme tööriist; ja tegelikult toovad kogenud gurud välja võrratuid projekte tõenäoliselt palju väiksemate raskustega, kui nad võiksid saavutada samu eesmärke väidetavalt lihtsa tööriistaga. Lõppkokkuvõttes maksavad arendajad, kes sellest tähelepanekust kõrvale kalduvad, teatavat hinda: kas valivad kõige soodsama “lihtsa” tööriista või muretsevad vähem kõige keerukama tööriista koormamisvabaduse pärast. Viimasel juhul valdad Fast CGI objekte, võtad palli ja jooksed. Hiiglaslikke kontseptsioone rakendatakse sageli vähese koodiga. Jah, lihtsad tööriistad väidavad sama, kuid näilise raskuse eemaldamisega meist nii, et nende tavaliselt ainsast mustrist kõrvalekaldumine tekitab lisaks jõudlusprobleemidele, mida C++ lahendab, väga raskeid inseneriprobleeme.
3
Nende küsimuste lahendamise käigus peame paratamatult uurima selliste projektide arendamise põhimudeleid või mustreid, mida soovime välja tuua. See tähendab võrreldavate tööriistade jaoks parima kirjanduse hankimist ja vähemalt oma kontseptsioonile sellise vormi andmist, milles see võib teatud tööriistade komplektis võrreldes teistega võtta. Enne kui valite näiteks Ruby, võite hankida olulised raamatud, nagu “Ruby programmeerimiskeel” ja “Agile Web Development with Rails”. Teie esialgne uuring ei pea mitte ainult tööriistu piisavalt valdama, vaid nägema ette, kuidas saate selleni jõuda – kuidas saate soovitud tööriistaga pakkuda soovitud funktsioone. See on algataja jaoks hirmutav ülesanne. Kui kavatsete võrrelda väidetavalt lihtsat arenduskeskkonda parimatest parimatega, peate hindama ka parimaid C-tööriistu. Kui soovite tõesti olla kogenud insener, valite C, kuna see on piirangutevaba. Kas C on tõesti raskem? Ei. Süntaks on süntaks. Lõpuks peate valdama sama funktsiooni väljendamist; ja tegelikult on C-keelte perekond suurepärane. Keeruline asi C++-s otse väljapaistmise juures on panna käed mudelite peale, millele võib tekkida vajadus tugineda. Suurepärane algus praktiliselt 15 aasta tagusest ajast oli algsed FastCGI komponendid, mis olid saadaval Borlandi CPPBuilderis – ilmselt endiselt parim C++ Windowsi jaoks. Isegi C-initsiaatorid võivad selliste objektorienteeritud lähenemisviisidega kaugele jõuda, sest funktsionaalsuse säilitamise üldine mudel on sisse ehitatud just nendesse asjadesse, millega töötate. Teie töö on palju vabam kui näiteks Ruby puhul, kui võite oma lähenemisviisis Ruby mudelit rikkuda või ületada. Teisest küljest kiirendavad Railsi tellingute tehnikad algaja jaoks palju tööd, kui ja ainult siis, kui projekt sobib Ruby ja Railsi üldise vormiga. Tutvustage näiteks elementaarseid turvasätteid, mida tuntakse kõigis teie Ruby liidestes, ja järgmise asjana kirjutate uuesti tuhat rida automaatselt genereeritud Ruby koodi iga tabeli jaoks, mille üle teie rakendus läbi räägib. Kas see on lihtne? Noh, ma teen seda Windowsi redaktoriga NoteTab Pro, mis töötab OSX-süsteemis asuvate Ruby projektidega; ja keerukad makrod teevad mu redaktsioonid ehk sekundiga, kohandades tuhat koodirida peaaegu kahekordseks. Siiski on see seotud suhteliselt lihtsate põhifunktsioonidega, millega projekt piirdub. Fakt on see, et C++-s saame kirjutada oma objekte, mis saavad nende ülesannetega tõeliselt universaalselt hakkama – te ei peaks seda protsessi kunagi isegi kordama. Nii et need on kompromissid. Lõpuks on objektorienteeritud C kõige võimsam ja tõhusam. Mis tähendab, et see on ka kõige vähem töö.
4
Olenemata programmeerimistööriistade valikust ei saa kuidagi vältida sõltuvust HTML-i ja CSS-i mõistlikust valdamisest. Üldiselt loodavad kogenud arendajad olulise materjali jaoks saidile W3C.org. veebileht