Zopár rýchlych poznámok o mne:
- nežijem pre prácu, ale napriek tomu ma baví :).
- moju aktuálnu profesijnú fázu pravdepodobne najlepšie vystihuje veta: "Rád robím veci dobre a nemienim sa predávať pod cenu".
- mám rád hudbu, ľudí a verím, že život je o niečom viac ako len o tom, čo vidíme očami...
V čom sa vyznám:
HTML+CSS, MySQL, PHP, Zend Framework, jQuery, project leader
Overený používateľ, členom od 29.7.2011
(zatiaľ žiadne)
- nenapísal žiadne články/novinky
- napísal 190 komentárov
0
0
-
2012-10-13 17:01:37
@Peter Širka "si veľmi tvrdohlavý" - vidím, že ma "poznáš". Aj keby si mal mať tento dojem z diskusie, je to odbočka od témy k nabúravaniu sa do niekoho (samo, to isté teraz robím aj ja a aj preto nebudem pokračovať v debate). Čo sa týka ďaľšej konverzácie, končím, ja si myslím, že som svoje dôvody dostatočne opísal nižšie, ak to nie je z toho pochopiteľné, buď to neviem lepšie vysvetliť alebo niečo bráni pochopeniu, neviem, nechcem sa do niekoho navážať.
Ide o konkrétny príklad, kde sa to používa často a je relatívne nízky počet LIKE/DISLIKE (rádovo ako je tomu teraz). Myslím, že počet dopytov je jednoduchá matematika a aj záťaž, ktorá s tým ide ruka v ruke. Ba dokonca som nižšie uvidol príklad, kedy je vhodnejšie riešenie s AJAXom. Viac už nemám čo dodať (a ani sa mi nechce).
@Peter Širka "si veľmi tvrdohlavý" - vidím, že ma "poznáš". Aj keby si mal mať tento dojem z diskusie, je to odbočka od témy k nabúravaniu sa do niekoho (samo, to isté teraz robím aj ja a aj preto nebudem pokračovať v debate). Čo sa týka ďaľšej konverzácie, končím, ja si myslím, že som svoje dôvody dostatočne opísal nižšie, ak to nie je z toho pochopiteľné, buď to neviem lepšie vysvetliť alebo niečo bráni pochopeniu, neviem, nechcem sa do niekoho navážať.
Ide o konkrétny príklad, kde sa to používa často a je relatívne nízky počet LIKE/DISLIKE (rádovo ako je tomu teraz). Myslím, že počet dopytov je jednoduchá matematika a aj záťaž, ktorá s tým ide ruka v ruke. Ba dokonca som nižšie uvidol príklad, kedy je vhodnejšie riešenie s AJAXom. Viac už nemám čo dodať (a ani sa mi nechce).
0
0
-
2012-10-13 11:55:25
@Peter Širka zda sa mi, ze si mozete podat ruku s @Peter Payter Gašparík , lebo pri vrcholeni diskusie ste obaja isli k podryvaniu druhej strany/urazani namiesto venovaniu sa problemu a uvedeniu prednosti svojho riesenia pre konkretny priklad.
@Peter Širka zda sa mi, ze si mozete podat ruku s @Peter Payter Gašparík , lebo pri vrcholeni diskusie ste obaja isli k podryvaniu druhej strany/urazani namiesto venovaniu sa problemu a uvedeniu prednosti svojho riesenia pre konkretny priklad.
0
0
-
2012-10-13 11:49:09
@Peter Širka hej, v mojom svete je zatial menej requestov menej zatazujucich, za tym si stojim ;).
@Peter Širka hej, v mojom svete je zatial menej requestov menej zatazujucich, za tym si stojim ;).
1
0
-
2012-10-12 12:54:53
sry, nechce sa mi to komlpet citat, len moj dojem z toho, co som preletel: mne sa zda, ze sa moc necita/neuvazuje v tom, z coho vychadzame. riesenie je prirodzene odlisne pre 500 like/dislike - tam ani nema zmysel vypisovat mena, takze tento smer uvazovania mozeme komplet zahodit. riesime situaciu: bude sa to pouzivat casto a ide o objem like/dislike podobne ako je tomu teraz. nema zmysel riesit 500 like/dislike, ani situaciu, ze sa to nepouziva, leda ze by sme sa chceli dohadovat.
ja vychadzam z nasledovnej situacie (ako som pisal nizsie): snazim sa riesit hrdlo flase za predpokladu, ze problemom je db, co sa stava pri vacsich projektoch, ked moze byt db napr. na inom servery (aj ked pochybujem, ze je to pripad zajtra.sk, ale o to ide pri takejto uvahe o rieseni - riesenie za urcitych predpokladov, pretoze pre rozne situacie je vhodnejsie ine riesenie). ak budem robit X requests, pricom pokazde potrebujem spravit ten isty JOIN, je to zbytocne zatazujuce. ako spravne niekto poznamenal nizsie, pri nacitavani stranky prebehne beztak tolko dopytov, ze tento je prakticky zanedbatelny a zatazajucejsie je X postupnych dalsich posielani dat.
teda, ked sa pozriete spat, vseobecne vznika nesuhlas v komentaroch, pretoze sa vychadza z inych predpokladov (moj dojem). niekto to chce optimalizovat na 500 likes, ktore pozrie malo kto, niekto pre objem, pri ktorom to ma este zmysel a za predpokladu, ze je to casto vyuzivana feature. kto ma pravdu? zalezi, co sa riesi. a prave o tom to je, navrhnut vhodne riesenie pre konkretnu situaciu.
moj postreh: nema zmysel optimalizovat na 500 likes, ked taka navstevnost a citatelnost je momentalne v nedohladne. IMO by malo technicke riesenie rast ruka v ruke s projektom, ako niekto poznamenal uz skor, predcasna optimalizacia je zdrojom zla a premrhanych hodin klienta, ktory to casto nevyuzije, nakolko sa vyuzitia projekt ani nedozije. najjednoduchsie riesenia casto (najma na zaciatku jednoducheho projektu ako zajtra.sk) byvaju tie najlepsie...
sry, nechce sa mi to komlpet citat, len moj dojem z toho, co som preletel: mne sa zda, ze sa moc necita/neuvazuje v tom, z coho vychadzame. riesenie je prirodzene odlisne pre 500 like/dislike - tam ani nema zmysel vypisovat mena, takze tento smer uvazovania mozeme komplet zahodit. riesime situaciu: bude sa to pouzivat casto a ide o objem like/dislike podobne ako je tomu teraz. nema zmysel riesit 500 like/dislike, ani situaciu, ze sa to nepouziva, leda ze by sme sa chceli dohadovat.
ja vychadzam z nasledovnej situacie (ako som pisal nizsie): snazim sa riesit hrdlo flase za predpokladu, ze problemom je db, co sa stava pri vacsich projektoch, ked moze byt db napr. na inom servery (aj ked pochybujem, ze je to pripad zajtra.sk, ale o to ide pri takejto uvahe o rieseni - riesenie za urcitych predpokladov, pretoze pre rozne situacie je vhodnejsie ine riesenie). ak budem robit X requests, pricom pokazde potrebujem spravit ten isty JOIN, je to zbytocne zatazujuce. ako spravne niekto poznamenal nizsie, pri nacitavani stranky prebehne beztak tolko dopytov, ze tento je prakticky zanedbatelny a zatazajucejsie je X postupnych dalsich posielani dat.
teda, ked sa pozriete spat, vseobecne vznika nesuhlas v komentaroch, pretoze sa vychadza z inych predpokladov (moj dojem). niekto to chce optimalizovat na 500 likes, ktore pozrie malo kto, niekto pre objem, pri ktorom to ma este zmysel a za predpokladu, ze je to casto vyuzivana feature. kto ma pravdu? zalezi, co sa riesi. a prave o tom to je, navrhnut vhodne riesenie pre konkretnu situaciu.
moj postreh: nema zmysel optimalizovat na 500 likes, ked taka navstevnost a citatelnost je momentalne v nedohladne. IMO by malo technicke riesenie rast ruka v ruke s projektom, ako niekto poznamenal uz skor, predcasna optimalizacia je zdrojom zla a premrhanych hodin klienta, ktory to casto nevyuzije, nakolko sa vyuzitia projekt ani nedozije. najjednoduchsie riesenia casto (najma na zaciatku jednoducheho projektu ako zajtra.sk) byvaju tie najlepsie...
1
0
-
2012-10-09 22:41:14
@Peter Payter Gašparík hej, asi sa nezhodneme, ale neva, aspon sme podiskutovali :)
@Peter Payter Gašparík hej, asi sa nezhodneme, ale neva, aspon sme podiskutovali :)
1
0
-
2012-10-09 21:53:52
@Peter Payter Gašparík myslim, ze o tomto je nas nesuhlas v tejto veci: usudzujem, ze ty vychadzas z predpokladu, ze sa to pouzivat prilis nebude - v tom pripade to naozaj nema zmysel. ja vychadzam z predpokladu, ze sa to bude vyuzivat a casto.
samozrejme, ze tam budu data naviac, ale navysenie objemu prenesenych dat v tomto pripade podla mna je zanedbatelne, skor by ma trapili query do db. nehovoriac o tom, ze pri kazdom AJAX requeste nielen robis db query, ale taktiez mas datovy prenos.
@Peter Payter Gašparík myslim, ze o tomto je nas nesuhlas v tejto veci: usudzujem, ze ty vychadzas z predpokladu, ze sa to pouzivat prilis nebude - v tom pripade to naozaj nema zmysel. ja vychadzam z predpokladu, ze sa to bude vyuzivat a casto.
samozrejme, ze tam budu data naviac, ale navysenie objemu prenesenych dat v tomto pripade podla mna je zanedbatelne, skor by ma trapili query do db. nehovoriac o tom, ze pri kazdom AJAX requeste nielen robis db query, ale taktiez mas datovy prenos.
0
0
-
2012-10-09 16:15:33
@Peter Payter Gašparík este mimochodom, JOIN medzi tabulkami comments, likes, users by bol skutocne v tomto pripade zbytocny a ani som o nom nepisal, co mi zas potvrdzuje, ze si si asi necital celkom pozorne moj komentar. + Preco by malo pocitanie v PHP byt blbost? Pri aplikaciach orientovanych na vykon je bezne, ze nechas PHP spravit "heavy lifting" a nezatazujes db a to z dovodov, ktore som uz uviedol. Inac skode, ze tato diskusia zklzla do tejto urovne, na zaciatku mala podla mna celkom potencial, bez ohladu na to, kto by vysiel ako "vitaz". Ale ako som pisal, nech sa ti dari...
@Peter Payter Gašparík este mimochodom, JOIN medzi tabulkami comments, likes, users by bol skutocne v tomto pripade zbytocny a ani som o nom nepisal, co mi zas potvrdzuje, ze si si asi necital celkom pozorne moj komentar. + Preco by malo pocitanie v PHP byt blbost? Pri aplikaciach orientovanych na vykon je bezne, ze nechas PHP spravit "heavy lifting" a nezatazujes db a to z dovodov, ktore som uz uviedol. Inac skode, ze tato diskusia zklzla do tejto urovne, na zaciatku mala podla mna celkom potencial, bez ohladu na to, kto by vysiel ako "vitaz". Ale ako som pisal, nech sa ti dari...
0
0
-
2012-10-09 16:11:47
@Peter Payter Gašparík mne sa zda, ze necitas, co pisem. Nic sa tu netykalo ORM, sam pouzivam a ked sa uchylujes k neopodstatnenym utokom na moje vedomosti miesto toho, aby si cital, vidim, ze tato diskusia nema zmysel. Nech sa ti dari...
@Peter Payter Gašparík mne sa zda, ze necitas, co pisem. Nic sa tu netykalo ORM, sam pouzivam a ked sa uchylujes k neopodstatnenym utokom na moje vedomosti miesto toho, aby si cital, vidim, ze tato diskusia nema zmysel. Nech sa ti dari...
0
0
-
2012-10-09 15:39:27
@Peter Payter Gašparík bol som v tom, ze hovorime o vykone, nie o programatorskej narocnosti (trochu ina tema, pricom musim dodat, ze tu narocnost tam nevidim v takej velkej miere). Neviem, ako to je realizovane, ci COUNT() alebo poctom like/dislike, to bol priklad, ako vec realizovat a priznam sa, nevidim prilis dovod to rozoberat, kedze 1 query vs. 10, ked si chcem pozriet kto dal like, je stale efektivnejsie.
Takisto, priklad s asychronnym request je priklad a nema nic spolocne s ORM - jednoduchsie (zo skusenosti) sa odladi chyba priamo v PHP, komfortnejsie sa mi posuvaju data z 1 action do 1 view v 1 kroku, v pripade, ze je v kode chyba dostanem okamzite PHP error etc.... Jednoducho, napisem menej a lahsie odladitelneho kodu (z hladiska mojho komfortu) + Minimalizacia poctu query je ziaduca, najma ak ide o vacsie aplikacie, kde je napr. databaza na inom servery (kedze sa rozpravame o vykone).
Ale OK, nemam problem, napisem 1 action a 1 view, prebehne 1 query a menej JS, kedze nic viac netaham z db, len dam napr. .toggle() (jQuery). Ty teda chces napisat napr. 2 action, pisat dalsiu funkcionalitu pre AJAX request a nasledne zobrazenie a robit X dalsich query pre zobrazenie bubliniek, cim pravdepodobne zaneprazdnis opakovane system aj db. Mne to vychadza tak, ze som napisal menej kodu, ktory je menej zatazujuci pre system.
@Peter Payter Gašparík bol som v tom, ze hovorime o vykone, nie o programatorskej narocnosti (trochu ina tema, pricom musim dodat, ze tu narocnost tam nevidim v takej velkej miere). Neviem, ako to je realizovane, ci COUNT() alebo poctom like/dislike, to bol priklad, ako vec realizovat a priznam sa, nevidim prilis dovod to rozoberat, kedze 1 query vs. 10, ked si chcem pozriet kto dal like, je stale efektivnejsie.
Takisto, priklad s asychronnym request je priklad a nema nic spolocne s ORM - jednoduchsie (zo skusenosti) sa odladi chyba priamo v PHP, komfortnejsie sa mi posuvaju data z 1 action do 1 view v 1 kroku, v pripade, ze je v kode chyba dostanem okamzite PHP error etc.... Jednoducho, napisem menej a lahsie odladitelneho kodu (z hladiska mojho komfortu) + Minimalizacia poctu query je ziaduca, najma ak ide o vacsie aplikacie, kde je napr. databaza na inom servery (kedze sa rozpravame o vykone).
Ale OK, nemam problem, napisem 1 action a 1 view, prebehne 1 query a menej JS, kedze nic viac netaham z db, len dam napr. .toggle() (jQuery). Ty teda chces napisat napr. 2 action, pisat dalsiu funkcionalitu pre AJAX request a nasledne zobrazenie a robit X dalsich query pre zobrazenie bubliniek, cim pravdepodobne zaneprazdnis opakovane system aj db. Mne to vychadza tak, ze som napisal menej kodu, ktory je menej zatazujuci pre system.
0
0
-
2012-10-09 12:20:45
@Peter Payter Gašparík Vidim, co si mal na mysli, ale na ziskanie vsetkych ludi, ktory daju like/dislike ti staci 1 query, ktory nasledne jednorazovo spracujes v PHP (napriklad) a mozes ju rovno pouzit aj na urcenie poctu like/dislike (cize mas vsetko vyriesene s 1 query). Teda si vytiahnem z db vsetky like/dislike napr. pre ID clanku, v PHP roztriedim podla ID komentaru a zobrazim do skryteho kontajneru a pocet komentrarov mozem dat napr. ako PHP count() uz roztriedenych like/dislike.
Ak by si to chcel robit live, mal by si pri kadzom hover novu query, co je neefektivnejsie. Priestor na chybu: ked mi nieco vracia PHP, je to komfortnejsie ako riesit AJAX requests. Napr. sa mi stalo, ze som urobil zmenu v db a neuvedomil si dopad na nejaku takuto funkcionalitu. Ked to priamo embedujem ako PHP, neriesim...
@Peter Payter Gašparík Vidim, co si mal na mysli, ale na ziskanie vsetkych ludi, ktory daju like/dislike ti staci 1 query, ktory nasledne jednorazovo spracujes v PHP (napriklad) a mozes ju rovno pouzit aj na urcenie poctu like/dislike (cize mas vsetko vyriesene s 1 query). Teda si vytiahnem z db vsetky like/dislike napr. pre ID clanku, v PHP roztriedim podla ID komentaru a zobrazim do skryteho kontajneru a pocet komentrarov mozem dat napr. ako PHP count() uz roztriedenych like/dislike.
Ak by si to chcel robit live, mal by si pri kadzom hover novu query, co je neefektivnejsie. Priestor na chybu: ked mi nieco vracia PHP, je to komfortnejsie ako riesit AJAX requests. Napr. sa mi stalo, ze som urobil zmenu v db a neuvedomil si dopad na nejaku takuto funkcionalitu. Ked to priamo embedujem ako PHP, neriesim...
0
0
-
2012-10-09 11:59:33
@Peter Payter Gašparík aha, ja by som to asi riešil tak, že by sa to načítalo jednorazovo pri načítaní stránky. Pravdepodobne menšia zátaž a priestor na chybu. Čo ty na to?
@Peter Payter Gašparík aha, ja by som to asi riešil tak, že by sa to načítalo jednorazovo pri načítaní stránky. Pravdepodobne menšia zátaž a priestor na chybu. Čo ty na to?
1
0
-
2012-10-09 00:45:12
@Peter Payter Gašparík vychadzajuc z predpokladu, ze mas uzivatelov a hodnotenia v oddelenych tabulkach: ak chces len pocet like/dislike, urobis len napr. COUNT() pre hodnotenia.
Pre zobrazenie mien uzivatelov ich potrebujes vytiahnut z tabulky s uzivatelmi, takze by si potreboval ten JOIN.
@Peter Payter Gašparík vychadzajuc z predpokladu, ze mas uzivatelov a hodnotenia v oddelenych tabulkach: ak chces len pocet like/dislike, urobis len napr. COUNT() pre hodnotenia.
Pre zobrazenie mien uzivatelov ich potrebujes vytiahnut z tabulky s uzivatelmi, takze by si potreboval ten JOIN.
0
0
-
2012-10-05 16:55:28
@Damián Imrich tak pár rýchlych tipov/kritiky, ak môžem: menu je úplne nečitateľné, top bar je zbytočný, z tmavých obrázkov na tmavom pozadí bolia oči, ak sa sústredíš na detaily, čitateľnosť by mohla byť podľa mňa lepšia. + Prečo to ide tak pomaly? Načítanie 1 stránky trvá okolo 5,5s.
Nemáš aj nejaký projekt, kde by si robil niečo od základu, napr. svoje CMSko, nejakú app na mieru, mashup alebo tak? To by mohlo napovedať viac o tvojich schopnostiach, resp. ťa prezentovať v lepšom svetle.
@Damián Imrich tak pár rýchlych tipov/kritiky, ak môžem: menu je úplne nečitateľné, top bar je zbytočný, z tmavých obrázkov na tmavom pozadí bolia oči, ak sa sústredíš na detaily, čitateľnosť by mohla byť podľa mňa lepšia. + Prečo to ide tak pomaly? Načítanie 1 stránky trvá okolo 5,5s.
Nemáš aj nejaký projekt, kde by si robil niečo od základu, napr. svoje CMSko, nejakú app na mieru, mashup alebo tak? To by mohlo napovedať viac o tvojich schopnostiach, resp. ťa prezentovať v lepšom svetle.
0
1
-
2012-10-05 12:49:24
@Shaggy: ten JOIN by pravdepodobne naozaj nebol nic extra, nakolko sa pre scitanie hlasov paci/nepaci tak ci tak pravdepodobne spravi query. Myslim, ze prehladnost nie je problem, ak to bude len pri hover nad "palcami".
je fakt, ze mi to moze byt jedno, ale z programatorskeho hladiska by to mala byt docela "malina", tak rozmyslam, ze preco nie?
@Shaggy: ten JOIN by pravdepodobne naozaj nebol nic extra, nakolko sa pre scitanie hlasov paci/nepaci tak ci tak pravdepodobne spravi query. Myslim, ze prehladnost nie je problem, ak to bude len pri hover nad "palcami".
je fakt, ze mi to moze byt jedno, ale z programatorskeho hladiska by to mala byt docela "malina", tak rozmyslam, ze preco nie?
0
0
-
2012-10-05 09:46:38
@Michal Obeda díky, +1
@Damián Imrich napr. zajtra je malá komunita, nikto ťa nebude viesť za ruku a dávať celé svoje know-how, od toho ale komunity ani nie sú. Nemôžeš nahradiť čas strávený učením a skúšaním. A tu je aj pes zakopaný, prečo 13 ročný programátor nie je zväčša dobrá voľba pre vývoj väčšiny projektov. Bez skúseností, s obmedzenými znalosťami, so slabou časovou dostupnosťou a detinským správaním (čo je normálne - deti sú deti) zostáva užšia skupina potenciálnych projektov (teda pokiaľ potenciálny vypracovávateľ nezavádza ohľadom seba). Z druhej strany, vybuduj si silné portfólio a ak si v 13-tich naozaj taký dobrý, oslovíš tým niekoho.
Inak, pre utovrenie obrazu a ak to nie je "top-secret": môžeš dať prosím odkaz na nejaký online projekt s pár vysvetľujúcimi slovami, aby sa dalo usúdiť, aké máš vlastne skúsenosti, čo vieš spraviť?
@Michal Obeda díky, +1
@Damián Imrich napr. zajtra je malá komunita, nikto ťa nebude viesť za ruku a dávať celé svoje know-how, od toho ale komunity ani nie sú. Nemôžeš nahradiť čas strávený učením a skúšaním. A tu je aj pes zakopaný, prečo 13 ročný programátor nie je zväčša dobrá voľba pre vývoj väčšiny projektov. Bez skúseností, s obmedzenými znalosťami, so slabou časovou dostupnosťou a detinským správaním (čo je normálne - deti sú deti) zostáva užšia skupina potenciálnych projektov (teda pokiaľ potenciálny vypracovávateľ nezavádza ohľadom seba). Z druhej strany, vybuduj si silné portfólio a ak si v 13-tich naozaj taký dobrý, oslovíš tým niekoho.
Inak, pre utovrenie obrazu a ak to nie je "top-secret": môžeš dať prosím odkaz na nejaký online projekt s pár vysvetľujúcimi slovami, aby sa dalo usúdiť, aké máš vlastne skúsenosti, čo vieš spraviť?
0
1
-
2012-10-03 12:18:21
@Monča Holečkovánie asi som sa zle vyjadril - mám na mysli užívateľské mená, teda napr. "Monča Holečková", "mhp", "Jozef Hruška", etc... I keď, myslím, že sa to dalo pochopiť z kontextu toho komentáru, ale ak to bolo nejasné, ospravedlňujem sa a ďakujem za pripomienku.
@Monča Holečkovánie asi som sa zle vyjadril - mám na mysli užívateľské mená, teda napr. "Monča Holečková", "mhp", "Jozef Hruška", etc... I keď, myslím, že sa to dalo pochopiť z kontextu toho komentáru, ale ak to bolo nejasné, ospravedlňujem sa a ďakujem za pripomienku.
Páčilo sa mi...
Článok
Zajtra.sk aplikácia v iPhone
Projekt
Bicykel
Projekt
Polepy Green Apple
Článok
Nokia Lumia 710
Článok
Portfólio vs. odporúčania?
Článok
Interakcia a Fittov zákon
Projekt
Zetor
Projekt
Coffee drinker
Portfólio používateľa
Martin Kušpál
Projekt
Berndorf
Portfólio používateľa
Kubo Rosypal
- je tiež tu:
· E-MAIL
Skrytý
@Milan Dvorský evidentne nechápeš, ako funguje biznis: ponúkaš niečo, o čo je záujem a odmenou za to záskavaš niečo iné, čo má pre teba hodnotu. v tomto prípade by to boli návštevy, ktoré následne speňažíš (napr. predajom reklamy). tak to chodí.
čo považujem za nehorázne je otvoriť si kvázi "obchod" (v tomto prípade web, z ktorého chceš zarábať) a potom sa sťažovať, že iní ľudia nevyužívajú svoj vlastný čas (hodnotu) na to, aby ti ten biznis pohnali. načo prosím ťa?
ak chce niekto pomôcť, je na to X iných spôsobov a teba je do toho fuk, ako to kto robí.
problémom zajtra.sk sa stalo, že ho prevzal (nie založil) niekto, kto si naivne myslel, že to tu bude rásť samé, len tak, lebo sa rozhodol a hotovo. neponúka pri tom žiadnu hodnotu prispievateľom, ktorí, ako som už spomenul majú X iných spôsobov, ako sa zdieľať s myšlienkami alebo vedomosťami (ak chcú). a takisto neponúka hodnotu ani čitateľom - články sú často nízkej úrovne, nepravideľné, obsahujú chyby.
tak zajtra dopadlo tak, ako dopadlo - portál bez cieľu, zmyslu, je to ako keby si spravil holú miestnosť a povedal: "poďte do nej investovať!", načo ti však ľudia povedia: "načo? máme predsa 1000 takých miestností, lepších, krajších, bližších, zariadených, etc, etc...". jednoducho - neprišiel zo strany zajtra.sk žiaden ROZUMNÝ input.
očakával som dávnejšie, že sa tak stane, takže nebudem klamať, potešilo ma, že nemám až tak zlý odhad, aj keď mi je mierne ľúto, ako to dopadlo, bol som tu od začiatku.