| Dragi Tata |
22. 09. 2006. 16:06 |
Citat:
Originalno napisao ivanhoe
pa dobro red je onda da se pomene i mod_rewrite i gzipovanje sadrzaja strana, mod_proxy, mod_security i druge stvari koje lamp ima vec jako dugo, a IIS tek od nedavno (i nepotpuno..). To su sve daleko potrebnije svakodnevne stvari od distribuiranih transakcija, zar ne?
|
Sve zavisi čime se baviš. Iskreno, nisam nikad ni čuo za te mod-ove koje pominješ, a middleware mi je biti ili ne biti, makar morao da koristim in-house varijante istog (grrrr...).
Uglavnom, slažem se: alat prema potrebi, a ne obrnuto. LAMP očigledno lepo radi na većini web aplikacija a za distribuirane ćemo da tražimo nešto drugo ;) |
| ivanhoe |
22. 09. 2006. 20:57 |
Citat:
Originalno napisao Dragi Tata
Sve zavisi čime se baviš. Iskreno, nisam nikad ni čuo za te mod-ove koje pominješ, a middleware mi je biti ili ne biti, makar morao da koristim in-house varijante istog (grrrr...).
|
WORD. To je sustina cele ove price, a malo ko od nas ima dovoljno iskustva sa ostalim resenjima, i onda ispadne da svaki ciga svoga konja hvali.
Ti recimo nisi cuo za mod_rewrite, a ja bez njega ne mogu da zamislim ozbiljniji SE optimizovan sajt, a opet ja za distribuirane transakcije znam samo iz knjiga, nikad mi nisu zatrebale za 12 godina desktop i web programiranja.
A zapravo su i .Net i LAMP razvijani tako da udovolje potrebama svoje ciljne grupe, koje su tek nedavno sa rastom popularnosti weba pocele da imaju zajednicki presek trzista.
@caboom: mozes da drzis sessione kao fajlove, u bazi ili u shared memoriji, handlere za to ne moras da pises sam jer postoje gotova resenja da se skinu sa PEAR-a. Ako nesto pukne, desi ti se isto kao sto se desi kad u .Netu nesto pukne, ako si osmislio redundatnost sve je ok, inace si se zeznuo :)
S tim sto su realno pod windows serverima vece sanse da nesto pukne, freeBSD i vecina linuxa imaju u proseku veci uptime od windows servera (mada je kazu 2003-ka bolja po tom pitanju). |
| ppavlovic |
22. 09. 2006. 21:01 |
|
| degojs |
22. 09. 2006. 21:25 |
Off Topic:
Citat:
ivanhoe:
S tim sto su realno pod windows serverima vece sanse da nesto pukne, freeBSD i vecina linuxa imaju u proseku veci uptime od windows servera (mada je kazu 2003-ka bolja po tom pitanju).
|
Ajd ivanhoe molim te prestani da trolujes stalno, ozbiljno.. ;)
Te koliko znate milionskih web sajtova pod ASP.NETom (nisam te cuo posle kad si dobio listu?), te Windows puca, te IIS ovo, jos samo fali da pomenes BSOD.
A sam kazes da ne radis nista tipa Win Server/IIS/ASP, po otkud onda znas..
Na kraju, ako je potrebno da celi sistem bude stalno dostupan, neces ni imati 1 server - jer sta ako crkne hardver? Ako je potrebno da servis bude dostupan celo vreme, onda pucanje pojedinacnih servera ne rusi ceo sistem, tako da.. uptime pojedinacno i nije strasno bitna stvar.
Uzeo si da branis LAMP, a da ga niko nije ni "napao." Niti mod_rewrite ima veze sa onim sto je Tata samo pitao..Be cool :) |
| caboom |
22. 09. 2006. 21:31 |
Citat:
Originalno napisao ivanhoe
@caboom: mozes da drzis sessione kao fajlove, u bazi ili u shared memoriji, handlere za to ne moras da pises sam jer postoje gotova resenja da se skinu sa PEAR-a. Ako nesto pukne, desi ti se isto kao sto se desi kad u .Netu nesto pukne, ako si osmislio redundatnost sve je ok, inace si se zeznuo :)
|
da, postoji jos mnogo drugih boljih resenja, ali nema puta ka prostoj skalabilnosti. :) btw. nemam dobra iskustva sa PEAR-om, osim ako se nesto nije drasticno promenilo u prethodne 2 godine.
Citat:
Originalno napisao ivanhoe
S tim sto su realno pod windows serverima vece sanse da nesto pukne, freeBSD i vecina linuxa imaju u proseku veci uptime od windows servera (mada je kazu 2003-ka bolja po tom pitanju).
|
well, sada prelazimo u domen spekulacije kada ljudi pocinju da povlace statistike sa netcraft-a. :) |
| misk0 |
22. 09. 2006. 21:56 |
Citat:
Originalno napisao Dragi Tata
Problem sa kojim se non stop srećem je da za C++ postoje mnoge gotove middleware komponente (naravno, nije sve tako kompletno i lepo integrisano kao u .NETu ili Javi) ali ljudi vole da pišu sve iz početka iz razloga koje nikako ne mogu da shvatim. Rezultat je obično gomila bagova i probijanje rokova. Još pre 5 godina sam se zarekao da ću da koristim gotove komponente kad god je to moguće, ali priča se ponavlja - većina smatra da je "lako" to isprogramirati iz početka.
|
Ja cu ti reci zasto ja to smatram, ne znam za ostale i vecinu.
Ukoliko neka komponenta nije 'maturirala' tj odlezala svoje, ispravljeno tonu bagova i nije u incijalnim podverzijama (tipa 5.0.0.3 ili 4.0.0.1b) onda ima sanse da radi kako treba i nesto je u sta bih se pouzdao. U suprotnom, kad se pocnu pojavljivati 'slucajne' i 'nepojmljive' greske, prvo svoj kod istresas, preturas, optimizujes. I kad izgubis sve to vrijeme i skontas da je bug u komponenti i zoves support i oni ti kazu 'da, skontali smo, ispravicemo u sledecoj verziji' ti ostanes ko popisan.
Kad pishes svoje rjesenje, poprilicno sam sigurniji da ce da radi a i ako ne radi, skontacu gdje je greska. Lakse je trejsati i dibagovati kad imam kod nego kad trejsing radi do odredjene granice a onda dobijes 'poruku o gresci'.
Mene je zajebavala nekad jedna Delphi komponenta, sa klasicnom porukom tipa 'prekoracenje niza' i slicno, ali mi je trebalo vremena da skontam da nije moja greska.
btw, da se vratim malo na distr. trans....
Kako bi to bilo izvodljivo u PHPu? Mislim, ne kazem da je jednostavno, ali ako vecina baza ima taj XA mehanizam, zar ne bi bilo teoretski lako napisati klasu koja uspostavi konekcije sa bazama, kreira transakcije ili na neki drugi nacin obavjesti baze o query-ima i upita za potvrdu. Kad dobije potvrdu, commit-uje sve i to je to? Ili izostavljam nesto veoma vazno?
Da li bi to za PHP trebalo biti pisano kao biblioteka u C++u ili necem drugom ili bi mogla biti samo klasicna PHP klasa?
cisto na glas razmisljam, moguce je da lupam opasno :) |
| Dragi Tata |
23. 09. 2006. 03:42 |
Citat:
Originalno napisao misk0
Ja cu ti reci zasto ja to smatram, ne znam za ostale i vecinu.
Ukoliko neka komponenta nije 'maturirala' tj odlezala svoje, ispravljeno tonu bagova i nije u incijalnim podverzijama (tipa 5.0.0.3 ili 4.0.0.1b) onda ima sanse da radi kako treba i nesto je u sta bih se pouzdao. U suprotnom, kad se pocnu pojavljivati 'slucajne' i 'nepojmljive' greske, prvo svoj kod istresas, preturas, optimizujes. I kad izgubis sve to vrijeme i skontas da je bug u komponenti i zoves support i oni ti kazu 'da, skontali smo, ispravicemo u sledecoj verziji' ti ostanes ko popisan.
Kad pishes svoje rjesenje, poprilicno sam sigurniji da ce da radi a i ako ne radi, skontacu gdje je greska. Lakse je trejsati i dibagovati kad imam kod nego kad trejsing radi do odredjene granice a onda dobijes 'poruku o gresci'.
|
Čuo sam takva obrazloženja milion puta, a najkociznije se izrazio moj šef koji kaže (prevod sa lošeg engleskog sa jakim nemačkim naglaskom): "Ako nešto ne radi, ovako mogu da krivim samo sebe". Elem, takva pristup je prosto-naprosto pogrešan, a evo i osnovnih razloga zašto:
1) Najpre, danas je praktično nemoguće dosledno se pridržavati tog principa: tvoja aplikacija trči na operativnom sistemu koji su napisali drugi, koristiš kompajler (ili interpreter) koji su napisali drugi, često imaš web server koji su napisali drugi, DBMS koji su napisali drugi, itd, itd. Jednostavno je pitanje gde ćeš povući crtu. Npr, neki vole da sami parsiraju XML fajlove, ili da pišu svoje komunikacione protokole, ili ne žele da koriste GUI biblioteke nego čist Win32 API, ali niko ne kreće da piše C kompajler u mašinskom kodu, pa onda njime da pravi svoj OS, pa biblioteke, DBMS, web server...
2) "Sam svoj majstor" varijanta donekle i prolazi za male projekte koje radi jedan čovek, ali čim pređeš na timski rad eto problema: da li ćeš da lakše nađeš čoveka koji zna npr Xerces, ili tvoj kućni XML parser koji nikad nikom nisi ni pokazao? Čak i pod pretpostavkom da niko od potencijalnih radnika ne zna ni Xerces, možeš lepo da mu daš link sa tutorijalom i dokumentacijom i naučiće ga sam. Tvoj parser moraš da mu sam pokazuješ i gubiš dragoceno vreme na to. A i da ne pominjem situaciju kad neki majstor koji je napravio takav kućni parser napusti firmu.
3) Ako naletiš na problem sa Xercesom, postoji lepa verovatnoća da nisi prvi i da su ljudi već našli rešenje za to. Ubaciš par ključnih reči u Google i uživaš. Svoje bagove (ili bagove tvog kolege) moraš da rešavaš sam.
4) Xerces su pisali ljudi koji jako dobro znaju XML i koji su uložili godine u taj proizvod. Pretpostavka da možeš da se takmičiš sa njima je jako labava, osim u nekim jako specifičnim slučajevima, a i tada je pravilo da prvo probaš Xerces, pa ako se baš uveriš da ti ne vrši posao onda praviš svoj parser. |
| misk0 |
23. 09. 2006. 10:12 |
Citat:
Originalno napisao Dragi Tata
1) Najpre, danas je praktično nemoguće dosledno se pridržavati tog principa: tvoja aplikacija trči na operativnom sistemu koji su napisali drugi, koristiš kompajler (ili interpreter) koji su napisali drugi, često imaš web server koji su napisali drugi, DBMS koji su napisali drugi, itd, itd. Jednostavno je pitanje gde ćeš povući crtu. Npr, neki vole da sami parsiraju XML fajlove, ili da pišu svoje komunikacione protokole, ili ne žele da koriste GUI biblioteke nego čist Win32 API, ali niko ne kreće da piše C kompajler u mašinskom kodu, pa onda njime da pravi svoj OS, pa biblioteke, DBMS, web server...
|
Mislim da je oznaceni dio kljucna recenica svega. Operativni sistem, kompajler, web server koriste milioni. Tu komponentu koju ti odlucis da koristis - koristi mnogo manji broj ljudi. Da li je komponenta free pa imas source (mada je debagovanje tudjeg koda cjedjenje jaja) ili je komercijalna (pa joj ne mozes nista) ne mjenja bog zna sta. Najgore je ako koristis komponentu, dodjes do odredjenog nivoa, vec izgradis dobar dio aplikacije zasnovan na njoj, onda se pojavi greska koja se desava povremeno ili stalno koju ne mozes da otklonis. To je jako velik gubitak vremena i resursa.
Kazem da ne postoji generalna odluka vec da ona treba da zavisi od vrste komponente kao i njene 'starosti' na trzistu. Ako je to krucijalna komponenta za tvoju aplikaciju i sve buduce tvoje aplikacije mislim da je daleko isplativije da je napishes sam nego da zavisis od nekoga drugog ma koliko ona komplexna bila (naravno, opet ne treba pretjerivati i pisati svoj kompajler). Opet ako je koristis jednom i nikad vishe, daleko ti je isplatnije kupiti nesto sto ce odradjivati posao. |
| ivanhoe |
23. 09. 2006. 16:07 |
Off Topic:
Citat:
Originalno napisao degojs
Ajd ivanhoe molim te prestani da trolujes stalno, ozbiljno.. ;)
|
:) A ne do sada sam FLEJMOVAO, a sad cu da krenem da trolujem, to jest ima da ignorisem sve ovakve rasprave... posto cenjena publika ne deli moje misljenje, jeli..:D
A za myspace sam se zeznuo, sto jest jest... sajt je velik i radi na asp-u.. neki bi rekli da je to samo jedan sajt u moru kontra-primera, ali... Salim se, samo se salim... :D
|
| caboom |
23. 09. 2006. 22:46 |
Citat:
Originalno napisao misk0
Mislim da je oznaceni dio kljucna recenica svega. Operativni sistem, kompajler, web server koriste milioni. Tu komponentu koju ti odlucis da koristis - koristi mnogo manji broj ljudi. Da li je komponenta free pa imas source (mada je debagovanje tudjeg koda cjedjenje jaja) ili je komercijalna (pa joj ne mozes nista) ne mjenja bog zna sta. Najgore je ako koristis komponentu, dodjes do odredjenog nivoa, vec izgradis dobar dio aplikacije zasnovan na njoj, onda se pojavi greska koja se desava povremeno ili stalno koju ne mozes da otklonis. To je jako velik gubitak vremena i resursa.
Kazem da ne postoji generalna odluka vec da ona treba da zavisi od vrste komponente kao i njene 'starosti' na trzistu. Ako je to krucijalna komponenta za tvoju aplikaciju i sve buduce tvoje aplikacije mislim da je daleko isplativije da je napishes sam nego da zavisis od nekoga drugog ma koliko ona komplexna bila (naravno, opet ne treba pretjerivati i pisati svoj kompajler). Opet ako je koristis jednom i nikad vishe, daleko ti je isplatnije kupiti nesto sto ce odradjivati posao.
|
mislim da je middleware dovoljno slozena "komponenta" da ovako nesto nema mnogo smisla, ukoliko nemas veoma uske prohteve koje je moguce napisati i debagovati brzo. jednostavno mnogo stvari moze da podje naopako i postoji mnogo slucajeva koje treba pokriti, pogotovo za "nosecu" komponentu.
sto se isplativosti tice, gledaj to sa ove strane, probijanje rokova najvise kosta - glavni razlog zasto ljudi vole da prave in-house middleware komponente, osim ukoliko na trzistu ne postoji dovoljno dobar proizvod, ili je dovoljno dobar proizvod previse skup (hint tibco rendezvous), je krajnje iracionalan - naprosto je zabavno. there, i've said it, iskreno receno i ja bih posegnuo za tako necim da mi je na tanjiru.
ono sto si takodje zaboravio je cena odrzavanja, svako prosirivanje tvoje komponente, ili svako fiksiranje na njoj kosta tvog vremena, a vreme je jedinica koja se relativno lako mapira na novac.
ono cime bih zavrsio ovu, vec totalno offtopic, diskusiju je ono sto sam primetio tokom svojeg stresnog IT polu-zivota:
1) pocetnici imaju tendenciju da pisu sve ispocetka
2) prosecni imaju tendenciju da koriste nedovoljno proverene komponente ("keyword guys") |
| Dragi Tata |
24. 09. 2006. 02:42 |
Citat:
Originalno napisao caboom
glavni razlog zasto ljudi vole da prave in-house middleware komponente, osim ukoliko na trzistu ne postoji dovoljno dobar proizvod, ili je dovoljno dobar proizvod previse skup (hint tibco rendezvous), je krajnje iracionalan - naprosto je zabavno.
|
Upravo! Drugi razlog koji sam primetio da navode kad su iskreni je: "trebaće nam više vremena da ukapiramo kako radi npr CORBA nego da sami napišemo prost UDP-based protokol".
Ekstrem ekstrema u tom pogledu je moj sadašnji šef, kome se učinilo da je previše komplikovano pisati Apache module, pa je seo i napisao svoj Web server!!! Posle je naravno smislio i svoj server-side skripting jezik. Sad se čudi koliko vremena treba da novi članovi tima postanu produktivni i samostalni. |
| bojan_bozovic |
24. 09. 2006. 03:24 |
kako bas begin..commit(rollback) ne mozes vrsiti sa konekcijom na dve baze, mozes napraviti sopstveni log kverija koje si izvrsio, pa je rollback opet moguc. To je i najjednostavnije resenje.
$result1=false;
$result2=false;
$result1=$link1->query($query);
if ($result1) { $result2=$link2->query($query); }
if ($result1 and $result2) { $link1->query("COMMIT;");$link2->query("COMMIT;"); $log->log($query);}
elseif ($result1 and (!result2)) { $link1->query("ROLLBACK;") }
Naravno, ovo je malo previse jednostavno, jer ima problema ako link1 pukne a link2 query ne prodje, ali se to resava dodatnim logovanjem.
|
| misk0 |
24. 09. 2006. 10:28 |
Oki, vjerovatno ja ne shvatam sta vi mislite pod 'middleware' komponentom. Mislim da je ludost pisati vlastiti web server pored tolike ponude na trzistu i pored tolike upotrebe i skalabilnosti apacha.
@caboom: a sta je sa dodatnom funkcionalnoscu te komponente za koju se pojavi potreba kad je tvoj proizvod vec u zavrsnoj fazi ili je vec neki period na trzistu, a originalni proizvodjaci nisu predvidjeli tu mogucnost? Sta onda mozes uciniti? Koliko u tom slucaju kosta 'narucena nadogradjanja tebi potrebne funkcionalnosti'?
|
| caboom |
24. 09. 2006. 12:30 |
Citat:
Originalno napisao misk0
Oki, vjerovatno ja ne shvatam sta vi mislite pod 'middleware' komponentom. Mislim da je ludost pisati vlastiti web server pored tolike ponude na trzistu i pored tolike upotrebe i skalabilnosti apacha.
@caboom: a sta je sa dodatnom funkcionalnoscu te komponente za koju se pojavi potreba kad je tvoj proizvod vec u zavrsnoj fazi ili je vec neki period na trzistu, a originalni proizvodjaci nisu predvidjeli tu mogucnost? Sta onda mozes uciniti? Koliko u tom slucaju kosta 'narucena nadogradjanja tebi potrebne funkcionalnosti'?
|
pa, pre svega to je situacija do koje ne bi trebalo ni da dodje, sa druge strane - ako je u pitanju tolika fundamentalna razlika da ti treba nesto vise od bugfix-a od proizvodjaca, ili ne postoji nikakav API za pisanje ekstenzija, verovatno ne bi prosao ni dobro sa svojom komponentom ako je dovoljno slozena (a u ovom slucaju pretpostavljamo da je dovoljno slozena da bi mozda bilo racionalno zaobici pisanje iste), ili si napravio pogresnu procenu u startu - fundamentalni problemi i iznenadjenja ne smeju da se pojavljuju u kasnim fazama, u svakom slucaju tu ti pomaze samo hack-workaround i dobijas 1000 exp poena iz "don'ts" oblasti. sa druge strane, pre nego sto odlucis da kupis neki proizvod, ili uzmes neki opensource projekat, pretpostavljam da ces proveriti da li je funkcionalan po svim stavkama koje ti trebaju i u slucaju da ti trebaju neke ekstenzije, proverices da li proizvodjac nudi neki API ili mogucnost prosirivanja, u slucaju da je opensource projekat u pitanju, postoji odredjena sansa, u zavisnosti od iskustva i vremena, da se eventualno i sam snadjes i "dodas" potrebnu funkcionalnost, mada je to opcija koju treba izbegavati ako je moguce.
sto se tice middleware komponenti, rekao bih da u ovom konkretnom slucaju mislimo na object brokere (CORBA) i MoM (message oriented middleware - JMS npr.), koji su dovoljno slozeni da implementacija istih predstavlja preveliki effort s obzirom da su specifikacije dovoljno slozene i temeljne i precizne da znas sta bi mogao da ocekujes - ovo ostalo zavisi od implementacije i svodi se na stavku 2, testiranje je majka dobrog sna.
Citat:
Originalno napisao Dragi Tata
Upravo! Drugi razlog koji sam primetio da navode kad su iskreni je: "trebaće nam više vremena da ukapiramo kako radi npr CORBA nego da sami napišemo prost UDP-based protokol".
|
ako je moguce, ovo je zapravo ponekada mnogo racionalnije nego uzimati heavy-weight resenja - pogotovo ako uzimas opensource komponente. imam jako losa iskustva sa npr. opensource JMS implementacijama (ActiveMQ i OpenJMS, ostali su jos problematicniji). |
| Dragi Tata |
24. 09. 2006. 15:18 |
@ misk0: Web server naravno nije middleware (pristojna definicija za middleware: http://computing-dictionary.thefreed...com/middleware ), samo sam dao ovaj primer dokle može da ide "not invented here" psihologija.
@caboom: Ja još nisam video "uprošćeno" rešenje koji stvarno radi kako treba. Sve to izgleda prosto i jednostavno na početku, ali vremenom naletiš na iste probleme koje su ljudi već rešili 100 puta i onda sve to ispadne još gore i zamršenije.
U principu, pokušavam da se držim pravila da pokušam prvo sa gotovim komponentama, makar i lošeg kvaliteta a onda da ih zamenim nečim boljim ili čak napišem sam ako se uverim da ne radi. Naravno, bitno je dizajnirati sistem tako da je lako menjati interne implementacije. |
| caboom |
24. 09. 2006. 16:44 |
Citat:
Originalno napisao Dragi Tata
@caboom: Ja još nisam video "uprošćeno" rešenje koji stvarno radi kako treba. Sve to izgleda prosto i jednostavno na početku, ali vremenom naletiš na iste probleme koje su ljudi već rešili 100 puta i onda sve to ispadne još gore i zamršenije.
U principu, pokušavam da se držim pravila da pokušam prvo sa gotovim komponentama, makar i lošeg kvaliteta a onda da ih zamenim nečim boljim ili čak napišem sam ako se uverim da ne radi. Naravno, bitno je dizajnirati sistem tako da je lako menjati interne implementacije.
|
slazem se, ali ja sa druge strane nisam video mnogo dobrih middleware komponenti koje su dovoljno robusne a da ne kostaju robusno mnogo i to ponajvise zato sto se veliki broj proizvoda pumpa da pokrije sto veci opseg keyworda, sto je deo trzisne utakmice, i onda stradaju osnovne funkcionalnosti - ovo govorim najvise sa stanovista MoM komponenti, posto imam relativno sveza (i losa) iskustva sa jeftinim (do $1k po procesoru) i besplatnim resenjima, dok sa ORBovima nemam skorasnja iskustva. naravno, sve zavisi od problema, samo sam hteo da naglasim da se cesto uzimaju daleko kompleksnija resenja bez preteranog udubljivanja u problem posto je na grafiku veoma lako ucrtati "JMS Broker" i povezati komponente. karikiram, ali znas na sta ciljam.
u sustini, mislim da je najprostije resenje otvoriti novcanik za najbolje ili zaista dobro resenje, ukoliko to nije moguce onda se treba zapitati da li je to zaista potrebno (citaj isplativo), ili "sta ja zapravo radim ovde"... |
| Vreme je GMT +2. Trenutno vreme je 11:08. |
|
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.
