Osad mõtted siit on suurem töö, ent panen kõik kirja lihtsalt, eks siis saab valida ja hinnata kasu ja kulu :)
Lehe mahu paremini kasutamine
Usun, et praegune avalehe formaat ei ole just parim. Sellel on rida ilmselgeid puudusi:
- Külgpaneelil on korraga vähem postitusi, kui poole päeva jooksul postitatakse. See tähendab - kes ei vaata sinna mitu korda päevas, magab kindlasti midagi maha (ja eelmistele lehekülgedele minna viitsib inimene ju harva).
- Avalehe esile tõstetud postitusi on vähe ja need võtavad palju ruumi.
- Puudu on võimalus liikuda päevade kaupa esile tõstetud postituste ajaloos - see tähendab, tegelikult on korraga näha ainult tänane päev.
- Külgpaneel kõrgemaks - see võiks ära täita vähemalt selle ruumi ülevalt alla, mille täidavad ära esile tõstetud postitused.
- Külgpaneel intelligentsemaks - see võiks näidata mitte lineaarset nimekirja viimastest uudistest, vaid vähem klikitud uudised võiksid ära kaduda kiiremini, kui ülejäänud (sama idee kehtib sisuosa kohta, aga pikemas ajaperspektiivis).
- Sisuosa mahutab kümneid, kui mitte sadu, kordi vähem uudiseviitasid, kui näiteks delfi.ee keskkond; samuti palju vähem, kui epl.ee keskkond. See tuleb sellest, et kõik uudised on esile tõstetud ühte moodi ning erinevalt teistest kahest on blog.tr.ee keskkonnas kolme tulba asemel kaks tulpa.
- Huvitavad blogilistid on toodud ära linkidena. Tegelikult peaks neist igaühel olema juures ka neli-viis või rohkem postitust ja need võiks olla esitatud, nagu delfi.ee's teemad.
- Esimene blokk koondaks kõikidest teemadest enimloetud uudised ülemisse serva, seal võiks olla ka kordusi.
- Kaks uudist oleks esile tõstetud väga selgelt, need oleks viimase kuue tunni loetuimad.
- Enne uudiste sinna blokki liikumist peaks süsteem paar tundi ootama ja mõõtma nende loetavust nii, et need ei ole esile tõstetud.
- Nende kahe all võiks olla sobivalt järjestatud kolm või neli viimase 24h loetuimat pealkirja; kolm või neli viimase 3p loetuimat pealkirja ja kolm või neli viimase 7p loetuimat pealkirja. See oleks vastutulek lugejatele, kes iga päev ei loe.
- Edasi tuleks erinevad temaatilised blokid. Igas blokis oleks ajaliselt järjestatud 10 viimase 24h loetuimat; 5 viimase 3p loetuimat ja 5 viimase 7p loetuimat; kui need kattuvad, siis võib andmebaasist võtta rohkem kirjeid.
Võiksin saada oma kasutajakontos vaadet enda käe järgi muuta.
- Eemaldada autorid, keda ma kindlasti kunagi ei loe - muudab uute postituste jälgimise oluliselt lihtsamaks. Selliseid autoreid võiks eraldi kaustast vaadata saada, kui vahel on huvi - nö. junkmaili kaust.
- Lisada vaatlemiseks uusi blogisid või kategooriaid avalehele, näiteks inglise keelsetest feedidest. Saaks kohe lisaväärtuse feedikliendina.
- Anda artiklitele punkte, mis oleks statistiliselt suurema väärtusega, kui lihtsalt asjaolu, et ma neid loen.
- Kui siduda konto enda isikuga - ID kaart, mobiilivalideerimine -, siis võiks iga kuu saada teatud koguse krediiti mõningate postituste soovitamiseks (avalehele paigutamiseks).
Lihtne klikikounter on halb. See peaks arvestama ka erinevate kasutajagruppidega - eri IP'dega näiteks. Sisuliselt nii, et kui on 100 eri IP'd, millest 90 pealt loetakse artikleid kokku 10 korda päevas ja 10 pealt 1000 korda päevas, siis esile saaks tõstetud iga IP pealt loetuimad uudised eraldi; so. mitte kõige suurema klikitamiste arvuga kasutajad ei otsustaks üksi, mis uudised on esile toodud, vaid süsteem püüaks esile tuua mõned uudised kõikidele sihtgruppidele. Mida parem statistiline meetod, seda kindlam, et igaüks leiab endale olulised uudised üles.
Süsteem peaks kindlasti ka jälgima, et kõige loetuimad asjad püsiks saidil pikka aega - tegelikult seni, kuni neid enam pea üldse ei loeta (kõik on asjaga tutvunud). See, kui aktiivne peab olema lugemine, et uudis püsiks veel 3, 6 või 20 päeva peale kirjutamist, sõltuks ka ajast - mida aeg edasi, seda suurem peab olema huvi, et suuta seda uudist veel seal hoida. See kõrvaldaks ka reedete ja pühade aegsete vähemlugemiste mõju - keegi ei pea ju vaatama, et kirjutada kõige aktiivsemal tunnil.
Kui keegi tahab, võin pakkuda algoritme selle kõige jaoks :)
Parem ärimudel
Hetkel on näha 25 krooniga uudise üheks päevaks esile tõstmise võimalust. Kuna arhiivi ei ole, kaob see mõju kohe; teiseks on küsitav, kas see on 25 krooni väärt, et üks uudis saaks esile toodud.
Parem mudel oleks see, kui saaks koguda endale krediiti; tasuta konto (kui see on isikuga seotud) saaks iga kuu vähese koguse krediiti - et saaks tasuta aru, mida sellega üldse teha saab - ning tasuline konto saaks seda rohkem. Alati saaks krediiti juurde osta. Krediiti saaks taskukohase hinnaga piisavalt, et tõsta esile mitu kuu parimat uudist - ühe uudise esile tõstmise hind kasvaks vastavalt enampakkumise statistikale; hind oleks alati selline, et uudiseid ei tõstetaks esile rohkem, kui lehepind võimaldab. Iga esiletõstja saaks maksta talle sobiva summa, mis ületab alampiiri. Eeskuju võiks võtta Google AdSensest.
Visioon
Visioon võiks olla paremini kirjeldatud eraldi lehel - et mida selle keskkonna olemasolu annab, kuhu viib - ja olemas võiks olla juhtlause või slogan, mis seda väärtust rõhutaks. Sellisel juhul tekiks kasutajatel ka mingi huvi keskkona suhtes rohkem, kui suvalise vahendina, mis kuskil vedeleb. Kasvõi 20 kasutajat, kes on veendunud, et blog.tr.ee keskkond edendab elu või riiki või sotsiaalvõrgustikke muudaks kogu keskkonna oluliselt elavamaks ja arenguvõimelisemaks.
Foorum
Igasugune keskkond, kus inimesed koos käivad, muutub rohkem keskkonnaks ja kohaks, kus käia, kui selle kasutajad saavad üksteisega suhelda ja kontakti. Blog.tr.ee keskkond võidaks sellest palju, kui seal oleks foorum. Kõik ei jõua endale blogisid teha.
Kuigi ma praeguseks pole enam Blog.tr.ee-ga seotud, siis portaali ülevalolev versioon on veel minu tehtud (2008/2009 hooajast) ja olen seega teemaga kokku puutunud.
VastaKustutaKõik siin postituses kirjeldatud ideed on väga head, kuid alati tasub idee teostuse eel kaaluda, kas selle teostamine on mõistlik või mitte. Näiteks popimate postituste esiletõstmine võiks olla tunduvalt parem, kuid kui selle parema lahenduse arendus on väga keeruline ja aeganõudev, kas see siis ikka annaks võrrelduna arenduse panusega piisavalt hea tulemuse? Praegune väga lihtne variant töötab tegelikult täiesti rahuldavalt, aga kui lahenduse 10% parendamise hinnaks on 100 töötundi, siis tõenäoliselt puudub arendusel point (välja arvatud muidugi siis, kui aeg on tasuta käes ja muud niikuinii teha pole).
Blog.tr.ee mureks on suured läbivad mahud. Näiteks arhiiv muutub üsna kiirelt päris koormavaks, kuna aastas lisandub baasi pool- kuni miljon postitust, mis teeb koos indeksitega päris mitu gigabaiti. Blog.tr.ee on aga üleval olnud juba ligi viis aastat ning kuigi esimestel aastatel olid mahud teised, on kogu selle info majandamine ikkagi rohkem kui keeruline.
Samas eksisteerivad ju konkurendid BlogEye ja Blog Station, mis on pealegi veel tehniliselt mitmest küljest paremad kui Blog.tr.ee. Kuid minu teada on nende portaalide külastatavus siiski kõvasti väiksem kui Blog.tr.ee-l ja see ei saa olla ainult selles, et Blog.tr.ee oli varem olemas. Küllap Blog.tr.ee on lihtsalt ikkagi parem.
Muidu, niisama meenus ka konkreetne probleem - kui kustutada postitus või muuta selle pealkirja, siis info blog.tr.ee keskkonnas ei uuene.
VastaKustutaSuuri läbivaid mahtusid imho see minu tekst väga ei puuduta; võib-olla ainult eelmiste päevade seisu vaatamine, arhiivis surfamine. See arhiiv võib ulatuda ka ainult paar nädalat või kuud ajas tagasi, ent võiks igaljuhul olemas olla.
Minu meelest on blog.tr.ee ka kõige parem, sest ta on lihtne ja töötab. Samas - kui suuta anda avalehel edasi suurem kogus infot, laiem valik artikleid ning filtreerida dünaamiliselt (arvestades kasutajaga, kes külastab x perioodiga, näiteks kolm korda päevas või korra kuus), siis see läheb veel paremaks. Delfis näiteks on võimatu mingit uudist maha magada - külastades seda isegi korra nädalas, on näha, mis on vahepeal juurde kirjutatud; samas on uued asjad alati esile tõstetud. See on psühholoogia ja tähelepanuga seotud ülesanne - kuidas pakkuda minimalistlikul kujul maksimaalne kogus relevantset infot.
Muidu, palju sellest on isegi pigem kujundaja, kui programmeerija ülesanne. Kui vaatad delfi avalehte - sinna on mahutatud väga suur kogus infot.
Seda on tehtud mitmel moel, loetlen neist mõned ilmselged...
Artiklite klassifitseerimine avalehel; erinevate klasside eristamine taustavärviga (eriti allpool) - parem, kui kategooriatele linkidega viitamine, sest võimaldab scrollida üle lehe; navigeerimine lingid-next-back on alati tüütum. Oluline info on mahutatud ühtsesse 2D ruumi.
Avalehele on mahutatud 36 pilti, paarsada-kolmsada pealkirja (sõltub, mida pealkirjaks lugeda ja kui esile see peab olema tõstetud).
Paigutuse efektiivsust võib mõõta kahe parameetriga - lehe pind, kasutatud avalehe kuupsentimeetrid uudise pealkirja kohta; oluliste uudiste esiletõstetus - kui palju ruumi on antud pildile ja sissejuhatusele kõige olulisemate uudiste puhul. Need on konkreetsed kvantitatiivsed parameetrid; kui suurele kogusele infole pääseb ligi avalehelt.
Blog.tr.ee avalehel on 17 pilti ja see moodustabki päevauudiste/päevapostituste koguhulga. Küljepaneelil on pealkirju rohkem, ent need on viimase mõne tunni kohta käivad - see tähendab, korra päevas külastaja jaoks ei ole see pind enam optimaalselt kaetud.
Delfi.ee's tuleb rohkem scrollida, ent see ei olegi halb - scrollimine ei ole väga keerukas tegevus. Pealegi mingil määral tuleb scrollida mõlemas.
Kui oleks võimalik sama blogi postitused siltide põhjal klassifitseerida blog.tr.ee keskkonnas, siis oleks parim - mind häirib, et minu postitused, mis kõik ei ole seotud teemaga, kus on blog.tr.ee's vähe postitusi (ja teadupärast vähendab spämmimine loetavust), aga kõik mu postitused ei sobigi sellesse teemasse, lähevad sinna ...tahaks administreerida ühe sildiga postitused ühte, teisega teise teemasse. Tunneks ennast kohe paremini. Ja muusika jms. postitused tahaks üldse välja administreerida sealt :)
Aga infovoo optimeerimine erinevate kasutamisharjumuste (sagedusega ennekõike) ja erineva info vastuvõtu kiirusega inimestele (et oleks selgelt nähtavaid postitusi vähem, ent neile, kes vaatavadki ühe hooga 300 pealkirja üle, oleks ka need väikses kirjas olemas) ning lõpuks erinevate filtritega - et need avalehe postitused oleks kuidagi jaotunud, äkki isegi avatavates-suletavates paneelides siis registreerunud kasutajale.
Muidu ma pean ütlema, et hea töö - ent arendada tuleks seda kindlasti, jõuliselt ja pidevalt, sest seal on ikka väga suur arenguruum. See ei konkureeri praegu päevalehtedega eriti - ja loetavusnäitajad näitavad seda ka, tegelikult ei ole konkurendid ju ainult teised blogikanalid, vaid ka portaalid ja päevalehed. Ideaalis võistleks see epl-i või delfi kümnete tuhandete lugejatega päevas.
Enamus küsimusi just suurtele mahtudele taandubki. Näiteks kui inimesed saaksid sorteerida, mis blogisid nad esilehel näevad ja mida mitte, siis ei ole sugugi lihtne teha süsteemi, kus 5000 inimest tahavad korraga näha mingit pidevalt muutuvat alamhulka miljonist andmebaasi kirjest. Iga kasutaja jaoks tuleb eraldi ja pidevalt arvutada välja miljoni kirje hulgast viimase aja parimad postitused, sorteerida need veel teemade kaupa jne.
VastaKustutaJuba kõige lihtsam hetke klikitavamate postituste leidminegi on suhteliselt keerukas - kuidas teha kindlaks millised postitused andmebaasis olevast miljonist on just need mida näitama peaks? Võibolla kaks aastat tagasi klikiti mingit postitust 10 000 korda - kas seda peakski endiselt esilehel näitama või mitte, kuna ühtki teist postitust nii palju klikitud pole? Tõenäoliselt mitte. Järelikult tuleb mängu tuua ka ajaline faktor. Mis aga on "praegune hetk", kuidas andmebaasist küsida just praeguse hetke kõige klikitumaid postitusi ja need ka järjestada?
100 kirje puhul on suvaline algoritm täiesti okei, andmebaas leiab suhteliselt kiirelt kõik vajaliku info üles. Aga miljoniga on lood tunduvalt keerukamad. Ma kutsuksingi siinkohal sind üles tõesti proovima luua midagi Blog.tr.ee laadset, nagu postituse alguses vihjasid. Ma olen kindel, et õpiksid sellest päris pälju - mina vähemalt õppisin küll.
Võtame 5000 inimest, kes on bänninud enda külgpaneelist (uusimad postitused) näiteks keskmiselt 100 autorit. See teeb andmebaasi mahuks 5000x100x100=50 megabaiti. See ei ole väga suur maht.
VastaKustutaTeiseks, ajalise faktori sissetoomine. Usun, et hetkel kehtiva avalehega seotud päringud puudutavad umbes viimast max. kuud aega postitusi. See tähendab seda, et on eraldi tabel viimase kuu aja kohta ning päringud tehakse ainult sellesse - sellest tabelist võib kõik vanemad asjad südamerahus kustutada.
Ma olen teinud mõned analoogsed süsteemid, mis puudutab tehnilist lahendust (aga need ei ole püüdnud hõlmata kogu veebi ja andmebaasid on olnud väiksed) - veebiajakirju, mõned üsna portaalilaadsed lahendused jms. Tegelikult selliseid asju, kus on mingid kirjed (uudised, artiklid või muud tekstid) ja neid tuleb kuidagi esilehel kuvada, olen ma kahtlemata teinud kümneid - märgatava osa veebipõhistest lahendustest moodustavad just need. Blog.tr.ee laadset süsteemi ei ole mul mõtet teha, omamata just selle jaoks suurt kogust vaba aega - eriti, kuna sellelaadne on ka olemas. Ma olen teinud muud laadi süsteeme ja komponente, millele on suur koormus või kus on väga suured andmemahud.
Aga ühesõnaga, andmebaasiprobleemid...
Võib vaadata üle järgnevad küsimused:
* Milline osa päris vanadest andmetest on üldse vajalik, kas seda peab hoidma - kas siis artiklite pildid, igat laadi täiendav info vms.
* Kas ei ole andmeid, mida saaks kokku pakkida erinevatel viisidel? Näiteks asendada mõni string numbriga jne..?
* Kui andmemahud on seotud päringute tegemise aja ja koormusega - uusimad, enim kasutatud andmed tasub alati panna eraldi tabelitesse; näiteks, kui ainult 3% uusimat infot mõnest suuremast postituste tabelist on 99% ajast vajalik, ülejäänu on vajalik 1% päringutele vastamiseks, siis on vaja eraldi tabelit, mis sisaldaks seda pidevalt kasutusel olevat infot - või siis väga head indeksite süsteemi, mida vähemalt MySQL kerge vaevaga saavutada ei võimalda.
Vastates neile küsimustele võib jääda järgi väike alamhulk andmeid, mille kasutust saab optimeerida.
Tundub, kui kasutajate puhul on piirang andmemahtudes - et nende privaatsed andmed koormavad süsteemi -, et bännitud kasutajate arvule võib panna kasutaja kohta max hulga ja teha selle hulga ületamine kuutasuliseks. Igal koormaval asjal on ju kasulik aspekt - kui millegi haldamine kõikidele kasutajatele on kallis, siis on sellel perspektiivi pakkuda ka mingit sissetulekut.
See kas bännide tabel on 5 või 50 MB ei mängi mitte mingit rolli (rolli ei mängi mitte kirjete suurus, vaid nende arv). Kõige olulisem on lisanduv keerukus - esilehe genereerimisel tuleb täiendavalt arvestada veel ühe tabeliga. Iga lisanduv element aga tõstab süsteemi keerukust eksponentsiaalselt. Seega tuleb jooksvalt luua kogu aeg uuesti 5000 erinevat esilehte, arvestades terve hulga eri tabelite jms.
VastaKustutaKui sa teed lehe, mida kasutab väike arv inimesi või mis sisaldab väikest arvu kirjeid, ei ilme veel pooligi nendest probleemidest, mis saabuvad koos suuremate kasutajate hulkade ja suuremate andmete arvuga.
Mis aga mainitud optimeerimisse puutub, siis kõik need sammud ja palju muud on ammu kasutusel - nagu näha toimib Blog.tr.ee koormusest hoolimata väga kiirelt. Kusjuures tegu on veel täiesti ise-hooldava süsteemiga - Blog.tr.ee'd pole varsti juba ligi aasta mitte keegi näpugagi puutunud ega hooldanud, sait on kogu selle aja jooksnud autopiloodi peal. Ja jookseb tõenäoliselt samamoodi veel aastaid.
Mina olen blog.tr.ee-s pettunud. Sellesmõttes, et ma olen üldmeilile vist oma 10 korda nüüdseks oma probleemist kirjutanud.. pole vastuseks saanud isegi, et "ei oska öelda" vms, okei lõpuks kui ma kõikvõimalikele blog.tr.ee-ga seotud isikutele kirja saatsin, siis Rain Rannu kirjutas, aga see probleemi sellegipoolest ei lahendanud.
VastaKustutaMa ei saa nimelt enda blogi http://kuno.noortele.ee ja ka firma blogi http://www.n-grupp.ee kumbagi blog.tr.ee loendisse lisada. Enda blogi puhul proovisin kõikvõimalikke viise, isegi süsteemi lasin täiesti 0-st peale ning proovisin blog.tr.ee-s teha teise konto ja sealt alt lisada, ikka mitte midagi.
N-grupp.ee see on suht alles loodud ning seda samuti ei saa lisada loendisse.
Kas keegi, kunagi, lõpuks, viimaks ütleks mulle kasvõi vihje, mida ma peaksin tegema selleks, et mu blogi(d) uuesti nähtavaks muutuksid.
Blogi(sid) lisades tuleb kiri alati, et "kinnituskoodi BLABLABLA ei leitud"
Andris, alati saab need bännimata kirjed külgpaneelile filtreerida näiteks viimasest kolmesajast sada - ei pea seda tegema miljonist. Need viimased kolmsada võivad olla juba ellkalkuleeritud. Seljuhul ei ole keerukuse eksponentsiaalne kasv midagi fataalset :)
VastaKustutastAb:
VastaKustutausun, et lisasin Su blogid nüüd, aga veel ei ole ilmunud (mingit veateadet ei tulnud). Kasutasin linke, mis avanevad browseri RSS nupule vajutades:
http://kuno.noortele.ee/?feed=rss2
http://www.n-grupp.ee/?feed=rss2
Need on RSS2 feedid, mida kasutada siis, kui blog.tr.ee ühel või teisel põhjusel neid ise ei leia (mida küll vist ei tohiks juhtudagi, kui FF leiab) - sest blog.tr.ee kasutab feedi tegelikult ja see on lõplik link, mida ta vajab, mitte avalehe url.
Noh, minul on omapärane lugu oma yksik-uitaja.blogspoti kontoga. Wordpressi postitused ilmuvad blog.tr.ee'sse, kuid blogspoti omad mitte. Tegin ka kõik täiesti otsast peale - kustutasin vana konto, tegin uue, panin kinnituskoodi, lisasin blog.tr.ee'sse - endiselt ei mingeid postitusi. Nagu oleks ära blokeeritud.
VastaKustutaheh ma ei ole nende kasutajatugi ka, ei tea ...kuni 24h muidu vist tuleb oodata sellega, minu blogspoti asjad on sinna väga hästi läinud. Kui Sul on väga kustomiseeritud layout, siis proovi RSS feedi lisada otse - äkki on viide sellele lehe HTMList kadunud? Muul juhul - ma ei tea. Andris äkki satub siia tagasi veel :)
VastaKustutaMa ei tea, mul endiselt ei toimi...
VastaKustutaBlogi lisab küll ära jah, kuid kinnitama hakates ütleb ikka, et "kinnituskoodi antud blogist ei leitud", kuigi kinnituskood on blogis olemas postituse näol.
Tjah, ütleks küll, et ega see blog.tr.ee veel ei tööta. Kõik järele proovitud, kuid postitused ei ilmu.
VastaKustutaKui ta veel ei tööta ja teda ei arendata ka, siis on lugu suht halb - öeldakse, et ei ole olemas *valmis* infosüsteeme, vaid on olemas elusad ja surnud infosüsteemid.
VastaKustutaSee suurendas pisut mu tahtmist ise üks selline asi teha, et nendest vigadest juttu on olnud :) Kuigi esialgu ei ole see eriti võimalik, eeldab ikkagi korralikku ajavaru ja suuremat süvenemist, et tõesti oluliselt paremini teha.
Heelium, aga paku ennast parem blog.tr.ee-sse arendajaks vms. :) Milleks teha asja, mis on põhimõtteliselt olemas ja toimiv, kuid mis vajaks ehk täiustamist...
VastaKustutaNoh, siin on tegelikult terve rida küsimusi, mis sellise asja ära otsustaks.
VastaKustutaEsiteks, et kui kritiseeritakse mingeid vigu - mis võivad siis olemas olla -, kas mul on lihtsam neid võõrast koodist otsida või ise uus kood teha. Vastus sõltub üldiselt konkreetsest juhust.
Teiseks, et kas see süsteem, mida mina arendaks, oleks ikka päris sama süsteem - praegu blog.tr.ee programmeerijal oleks ehk mugav viia blog.tr.ee'sse sisse just need muudatused, millest ma kirjutasin, aga minu jaoks tähendaks see ikkagi kogu blog.tr.ee koodipuu läbi uurimist ja võiks lõppeda siiski enam-vähem kõige ümber kirjutamisega. So. kui ma teeksin ise algusest peale, võiks see olla üsnagi erinev süsteem igas mõttes - ja kindlasti on sellise otsast kirjutamine targem, kui olemasoleva arendamine selliseks, sest juba põhiarhitektuur võib erineda.
See on asi, mis on küllaltki programmeerimisspetsiifika, aga kokkuvõtlikult - iga süsteem on ehitatud teatud vundamendi peale ja vundamendile, mis on rajatud ühesuguse süsteemi jaoks, on teistsugust väga keeruline rajada (kui mitte võimatu - eeldaks vundamendi ümber kirjutamist ja iga muudatus vundamenti eeldab kõikide kohtade muutmist, mis selle vundamendi osaga seotud on).
Selles mõttes see tundub esialgu hea idee, et hakka sama asja arendama - seda siis, kui mõtled asjast kui abstraktsest "tööst", umbes nagu üks süsteem oleks sajast tellisest koosnev müür ja teine oleks kahesajast koosnev teistsugune müür. Siiski on tegu kahe erineva süsteemiga - blog.tr.ee muutmiseks võin ma välja käia kindla rea asju, mida saaks selle baasile (loodetavasti) suhteliselt kerge vaevaga sisse viia, samas kui sellest nimekirjast mõni asi koodi eripära tõttu ei sobi. Näiteks ütles Andris sisuliselt, et andmebaasikood on kirjutatud selliselt, et tema tehtud vundament ei arvesta võimalusega, et tulevad need optimisatsioonid, millest mina rääkisin - kui nii on, siis eeldaks nende sisseviimine suuremaid muudatusi mitmes kohas jne...
Raske seletada, aga kujutle seda nii:
* Hea autotuunija võib teha viletsast sõiduautost üsna hea sõiduauto - aga siiski mitte igasugusest igasugust ilma suurema tööta.
* Samuti võib teha koledast ja viletsast bussist üsna korraliku bussi.
* Selleks, et teha sõiduautost korralikku bussi, on vaja teha juba nii palju asju ringi ja teisiti, et üldiselt oleks see ilmselt palju kallim, ajakulukam ja keerukam, kui kaks eelnevat; lisaks ei tasuks see ajaliselt-rahaliselt ilmselt ära.
Üldiselt on infosüsteemidega sama asi - kui mina üldse hakkaks tegema, töötaks mingid plaanid läbi ja mõtleks asjale, taotleks kvaliteeti ja kiiret valmimist, siis ei pruugiks olemasoleva süsteemi muutmine olla parim tee.
VastaKustutaMuidugi võib seda vaadata - kui selle kvaliteet, nagu laiendatavus, modulaarsus, minu ideega sobivad alused jne... oleks perfektsed, siis oleks kõik väga hästi. Samas saan ma aru, et selle süsteemi arendamine oli Andrisele suuremat sorti õppimine - mis tähendab, et selle ajalugu ei ole triviaalne (ja tõenäoliselt pole kellelgi aega olnud, et see lõpus kvaliteetseks viimistleda seestpoolt, isegi kui see kasutaja jaoks on kvaliteetne). Seal on tehtud ilmselt hacke-patche igat laadi jne...
Ühesõnaga on asju, mis tähendavad, et kui mul on paar kuud aega selle jaoks (mida mul ei ole), siis võib olla mõistlikum kulutada need paar kuud uuele süsteemile, kasutades mu enda arendusmetoodikat, töövõtteid ja arhitektuurilahendust, kui tuvuda Andri omaga (mille kohta ta on juba öelnud, et minu muudatuste sisseviimine oleks väga keeruline) ja siis võib-olla avastada, et sinna nende muudatuste sisse viimine oleks mulle ka keeruline. So kindlasti ei oleks see lihtsalt koodi _juurde_ kirjutamine - see on esimene asi, mida kliendid peaks programmeerijate juures mõistma, et kui ka välises mõttes tehakse midagi juurde, siis sisemises mõttes siiski reeglina muudetakse ja arendatakse, mitte ei lisata uusi tükke.
Ja viimane argument, et Andris ise on soovitanud mul ise teha lisaks mainimisele, et mitmed minu poolt soovitatud muudatused tähendaks tema andmebaasimudeli puhul eksponentsiaalselt kasvavat koormust - ja andmebaasimudeli muutmine tähendab poole süsteemi koodi ümber kirjutamist, kui see ei ole eriti paindlik kood (mida antud juhul ilmselt ei ole, arvestades Andrise enda lahkumist dialoogist). Nii et kaudsete vihjete põhjal võib oletada, et pigem uus süsteem, kui üldse midagi :) Aga mul on eelnevalt puhvris vähemalt üks muu süsteem, mida ka vabast ajast tahan arendada ja mida ma ka praegu aktiivselt ei arenda - nii on raske öelda, millal ma selleni jõuaks.
Nii et esialgu on mul tahtmine midagi teha - see muidugi parem, kui mitte midagi, aga ei pruugi väga lähiajal millegi tegemiseni ikka viia.