[jnt]

tonis, optimeeritus core'is on vajalik, kuna meil on kohutavalt palju kliente 24/7 online. Praegune core sisaldab peamiselt factory-pattern'is activeRecord'it ja on ses suhtes ehk valmis, et kõik toimib kiiresti, konkreetselt, efektiivselt ja võimekalt.

Küll aga ei ole meil hetkel pea-aegu, et isegi mitte mõistlikku controlleri ülesehitust. See teema siin ongi kõige rohkem siiski selle suunaga tehtud, et kuidas ehitada admin paneeli ja seda hästi.

Me ei saagi endale lubada kehvemat kood, kui ideaalset. Vastasel juhul kukub asi kokku.

[Fukiku]

Kas tänapäeval ei ole üldiselt arvutusvõimsuse juurde ostmine ja ülalpidamine odavam, kui nanosekundite optimeerimiseks inimtundide kulutamine?

[jnt]

Fukiku, on on, kuid kui sa kulutad päeva millegi optimeerimisele, mis annab iga kliendi puhul natuke aega juurde, siis rääkides suurtest kogustest klientidest, see väike aeg on summana väga suur.

[Fukiku]

Sa ju ei räägi optimeerimisest - sa räägid oma raamistiku tegemisest praktiliselt. Tulemuseks on tavaliselt see, et sul on raamistik, mille kogu know-how terves maailmas on sinu kontoris, halval juhul koguni ainult ühe inimese peas. Sul ei ole elu sees võimalik turult kogemustega arendajaid sinna leida ja sul ei ole võimalik probleemide korral suurelt community'lt nõu küsida, sest seda lihtsalt ei eksisteeri. Minu arvates on need üsnagi suured miinused, mis varem või hiljem lähevad kalliks maksma (arhitekt jääb auto alla - what do?). Ei tahaks uskuda, et olemasolevad raamistikud on nii ulmeaaeglased, et neid ei saaks kasutada suurte süsteemide jooksutamiseks eriti, kui nad toetavad klasterdamist.

Sa räägid igatahes sellist juttu, nagu teil oleks tohutu koormus koguaeg taga - mina lahendaks selle mure igatahes pigem võimsama(te) serveri(tega) ja populaarse raamistikuga, kui nanosekundite tagaajamisega in-house frameworki džunglis mässates ja säästurauda kasutades. See tuleb igal juhul odavam - sa ei pea kulutama kõigepealt mitut inimkuud (või aastat) raamistiku arendamiseks, vaid saad hakata kohe oma äriloogikat realiseerima - kulub vähem raha, jõuad varem turule, kiisud oksendavad vikerkaari su toote peale.

Oleks nagu ka meelde jäänud, et ikkagi sellel kümnendil väärtustatakse ka arvamusliidrite poolt arendamise lihtsust, kiirust ja programmeerija närvikava stabiilsust rohkem, kui nanosekundeid, sest arvutusvõimsus on odav, inimene aga mitte.

[tonis]

Tegelikult saaksid sa siit asjalikumaid vastuseid kui küsimus oleks mingi konkreetse asja kohta. Praegune küsimus on väga ebamäärane, midagi nagu "kuidas teha head CRMi?".
Sellele saab ka väga hägusaid vastuseid. Kui on konkreetne lahendamist vajav probleem siis saad ka paremaid vastuseid.

Fukiku argumendid on väga head. Kui ma oleks selle asutuse juht või omanik ja saaks teada et keegi leiutab mingit oma frameworki.. siis ma saaks veidi kurjaks sest selle normaalselt tööle saamine võtab aega, kulub palju raha ja mõne aasta pärast ei oska mitte keegi sellega midagi peale hakata kuna kõik teadmised on paari inimese peas.

Mitmed aastad tööd programmeerijana (mitte, et mingi vana kala vms) on õpetanud, et parem on teha asi veidi lihtsa ja lollina, vähemalt on hiljem koodist võimalik aru saada.. mitte teha mingit keerulist optimeerimist või imelisi kõiki keele/frameworki peidetud featuure kasutavaid elegantseid lahendusi. Muidu seda asjandust hiljem nii kolleegid kui sa ise ka.
Sinu jutu järgi vähemalt tundub, et tahad midagi eriti keerulist teha... mingid patternid jne, factoryd, ei tea mis imeasjad.

Tundub, et pigem on sul vaja teada kuidas on mõistlik rakendust üles ehitada, sest 'admin paneel' ei ole iseenesest mingi väga eriline rakenduse liik.
Vaata näiteks Ruby on Railsi rakenduste struktuuri. On modelid, viewd ja controllerid. urlidest leitakse controller ja action route-de järgi ja kõik on REST. REST struktuuri peale surumine on Railsi puhul üks paremaid asju.. sest siis ei saa keegi ise midagi liiga imelikku tegema hakata. Enamus uuemaid veebiframeworke on mingil viisil maha viksitud Railsi pealt naguinii, mõni päris kehvasti.

[jnt]

Fukiku, tonis, muidugi on mõistlik üks hetk võtta 3rd party framework kasutusse, kuid praegu on küsimus tegelikult olnud teooreetilise materjali kohta. Siin jutt läks muidugi asja enda ehitamise peale, kuid algusest peale on mu peamine soov olnud lugeda, kuidas peaks kapotialune töötama või millised erinevad patternid ja algoritmid on olemas ning kus mida kasutada.

[kullar]

Peale tonise postitutse lugemist tuli kohe meelde selline framework nagu symfony, kus esimeses versioonis oli kõik loogiline, kuid kui välja tuli versioon 2, siis see oli juba liiga keeruline ja ei näinud mõtet sinna süveneda.

[serk]

Sa väga tugevalt keskendud hetkel tehnilisele lahendusele, aga oled sa ka mingisugust analüüsi teinud, et mis asi ikkagi pudelikaelaks jääb? Kas andmebaas? Rak. Server? Või midagi muud? Mina ei tea andmebaasi suurust ja andmemudelit, aga sõnad hibernate ja activerecord 99% juhtudel tähendavad mitte just parimaid andmebaasi praktikaid ja seda, et äriloogika koondub veebiossa, mis lisab oluliselt koormust rak. serverile. Ja ära sa loodagi, et vähegi suuremate andmemahtude puhul päringud kiirelt ja efektiivselt käivad. Loomulikult on erandeid, aga seal on ka aastate pikkused arendused taga. Okey, osad inimesed mingipärast tahavad sellist patternit kasutada, fine, aga topi siis lihtsalt rak. serverid clustrisse ja thats it. Kasutusse mõni ennast tõestanud PHP või Java framework ja anna tuld.

Kui sul ei ole seljataga just suur ja väga kogenud arendajate team, siis sa ei suuda eales ise midagi paremat üllitada kui ennast juba aastaid tõestanud frameworkid. Ning ma võin mürki võtta, et kokkuvõttes uue frameworki arenduskulud tulevad oluliselt suuremad kui kasutada ennast tõestand lahendusi ja lihtsalt lükata servereid clustrisse.
Ning nagu eelnevate kaasvõitlejate poolt mainitud, sa pead ikka kõva müügimees olema, et müüa maha idee kirjutada oma raamistik. Kujutad sa ikka reaalselt ette mida see tähendab? Arendus, testimine, dokumentatsioon, koolitused, bugide batchimine - see on hea mitme aasta töö.

[jnt]

serk, kui rääkida müügitööst, siis praegu on vaja pigem pingutust, et mõni fw maha müüa.

Aga point pole üldse olnud selles siin teemas. Mida ma otsin ja tegelikult küsin, on ikkagi in-depth kirjandus patternide, loogikate jmt kohta.

Andmebaasi kohta võin öelda, et hetkel on suurus 40GB kanti ja see suureneb eksponentsiaalselt.

[Fukiku]

Sa räägid kohati iseendale vastu - ühest küljest üritad rõhuda, et sind huvitab ainult teoreetiline teadmine .. aga samas kaldud kohe jälle oma projekti tehnilistesse detailidesse ning esined arvamusega, et sa suudaksid kodukootud lahendusega paremini kui sissetöötatud ja üldtunnustatud lahendusega. Samuti su viimase postituse väide, et on vaja pingutada, et sulle raamistikku maha müüa, et sa seda kasutama hakkaks. Siit jääb kangesti mulje, et sa ikkagi kujutad endale ette, et sa loed mingit teooriat natuke ja siis lased puusalt täpsemini, kui teised mehed optilise sihikuga pärast aastatepikkust treeningut.

See ikkagi taandub kõik ju rahale - kas sa oled pannud kõrvuti rahanumbrid, mis kulub sul oma raamistiku ja rakenduse ehitamisele vs rakenduse ehitamine olemasoleva hästi toetatud raamistiku baasil? On sul selline raha? Ja kas sa oled valmis kõigi nende riskide jaoks, mida siin eelpool on välja toodud?

Mis puutub teoreetilisse käsitlusse - kas sa oled minu soovitatud kahe allika poole vaadanud? Raamistike lähtekood/developer meililistid ja teaduspublikatsioonid (kui sul on mõne ülikooli kaudu äkki võimalik neile ligi pääseda, siis Web of Knowledge peaks näiteks olema mingi koht, kust alustada otsingutega).

[jnt]

Fukiku, huvitabki teoreetiline teadmine. Ma olen alati siin rääkinud, et ei välista mõne fw kasutamist ja võib-olla ongi mõne fw peale üleminek. Kuid praegune esimene step on mul on teada saada täpsemalt, kuidas kõike teha. Selle järgi vaatan ka fw sortsu, kuna ma ei hakka valima fw'd mingite video tutorialide järgi. Praegust projekti olen kasutanud näitena, kui täpsemalt mu postid uuesti läbi loed.

Ärge hakake mulle sõnu suhu panema vaid lugege ka, mida räägin. Tahan teoreetilist materjali ja kui rääkida konkreetsest projektist siis see, kas sinna tuleb mõnid 3rd-party fw või mitte, on lahtine ja üldse teine teema.

Saage aru, ma ei hakka praegu midagi ehitama, ma tahan vaid infot, kuidas ehitada.

[Fukiku]

Selge, siis ma olen öelnud kõik, mis ma oskan öelda antud teema kohta.

Huvipärast proovisin ise - MVC web framework otsingu peale tuli Web of Knowledge kaudu 62 publikatsiooni, millest ehk õnnestuks mõni tera välja sõeluda .. ja siis loota, et ka täistekstile ligipääsu saab.

[serk]

Sry, viimane postitus non topic teemal, aga loodan, et sa ei pahanda

Läbi on käinud vestlus teemal java või php - üldiselt kui on tõsiselt suur infosüsteem, siis tasuks siiski mõelda java peale.
Enterprise tasemel lahendus omab kolme kihti - andmebaas, middle tier(no ei tule eesti keelne mõiste meelde) ja frontend. Middle tier'it PHPs ei tee, kui siis ainult mingi käsitsi nikerdatud värk. PHP kood üldjuhul on mingisugune mega monstrum makaron.

Siit tuleneb ka küsimus, et mis kihti planeerid sa panna äriloogika? Kirjutades PHPs on sul sisuliselt kaks võimalust: frontendi või andmebaasi. Kuna tihedalt on läbikäinud activerecord, siis oletan, et enamus loogikast topid frontendi. 40+ ja expo. kasvav DB saab sul väga kiiresti probleemiks, ehk patterni otsimisel pead kindlasti skoopi lisama ka andmebaasi. Mulle on samuti natuke see teema segane. Sa oled väga detailides, sa oleks juba nagu ära otsustanud sisuliselt tehnilise lahenduse - activerecord ja hibernate. Ehk sisuliselt oled sa juba ära piiranud oma valikud. Või kui need tehnoloogiad pole "must be used", siis mina alustaks kõrgemalt, võtaks näiteks EA ja hakkaks joonistama, alustades andmemudelist ja lõpetades UI ja andmete liikumise skeemidega. Selle pealt juba saab rohkem infot planeerimiseks ja soovitamiseks.

Amazonis on ka väga palju selle teemalisi raamatuid, osta sealt mõned.

Rohkem ei postita non topic teemasi , sry

[jnt]

serk, ei, ei pahanda.

Praegu on olemas activerecord cache'ide ja värkidega ja controlleris käib suhtlus factory'te ja activerecord objektidega. Factory'd on staatilised klassid, kus sees on põhimõtteliselt hunnik staatilisi funktsioone, mis annavad ühe või mitu activerecord objekti. Factory'd on põhimõtteliselt nagu prefilled filtrid objektide otsimiseks. Äriloogika funktsionaalsus istub iga konkreetse activerecord objekti sees. (nt "Client extends ActiveRecord" ja loogika on Client klassis) Äriloogika niiöelda käivitamine on kontrolleri teha. View osa on hetkel vaid smarty template'i osa, kuid kohati tekib tunne, et võiks vaja minna mingitsugust view-controller'it ka.

Et selline on hetkel ülesehitus. Ideeliselt ei ole sel häda midagi, kuid praegune admin paneel, mis kaugemas tulevikus tuleks normaalseks saada, on suurel määral väga vana kood, kus siiani tehakse nii mõneski kohas otse päringuid andmebaasi jne. (admin paneel kui selline koosneb hetkel siis kontrolleritest ja template'idest.)

Aga see on see, kuidas asi praegu on. Tuleviku suhtes pole veel ühtegi vaia maha löödud.

Amazon'ist juba otsin ja siin mainitud raamat ka üle vaadatud ja arvatavasti tellitakse üht-teist nüüd varsti ära.