[Fotoboek] In java?

[Raven]

eeh .. miss gewaagt maar is het niet een goed idee om echt JAVA te gebruiken ipv php en javascript..

ow en ik heb nog zo'n mooi dik toverboek

Thinking in JAVA van Bruce Eckel

heb het idee dat dat ook ietsje sneller gaat want dan kan de CODE lokaal draaien

[Enlightenment]

Dat wil je toch niet? Bovendien wat is het voordeel? De images en data moet nog steeds van s.com server komen hoor. En niet iedereen heeft java geinstalleerd, waaronder ik. Trage crapzooi, vooral bij het opstarten.

Zie het voordeel niet. Bovendien denk je dat hij het hele fotoboek gaat herschrijven?

[Paperz]

Enlightenment schreef op 06-08-2004 @ 21:23 :
Bovendien denk je dat hij het hele fotoboek gaat herschrijven?

Nou Zweepje heeft een boek, dus laten we het hem doen...
Zweepje maak even eene testversie (natuurlijk wel die werk met je test-server en niet die van scholieren) die er ongeveer uit ziet als het huidige fotoboek..
als je 't afhebt post een link en wie weet

[Raven]

Enlightenment schreef op 06-08-2004 @ 21:23 :
Dat wil je toch niet? Bovendien wat is het voordeel? De images en data moet nog steeds van s.com server komen hoor. En niet iedereen heeft java geinstalleerd, waaronder ik. Trage crapzooi, vooral bij het opstarten.

Zie het voordeel niet. Bovendien denk je dat hij het hele fotoboek gaat herschrijven?

heu dat hoeft ie dan echt niet alleen te doen

voordeel .. hmmja miss dat ie dan wat sneller laad en stabieler is
normaal ben ik geen voorstander van java hoor ( C++ RULES )

[Koen]

Paperz schreef op 06-08-2004 @ 21:29 :
als je 't afhebt post een link en wie weet

Ja en wie weet spoel ik dan honderden uren werk door de plee om maar eens een Java versie te bouwen zeker. Dacht 't ook.

Daarnaast ben ik 't met Enlightenment eens, ik zie geen voordelen. Community sites als het fotoboek zijn ideale projecten om júist met PHP/MySQL te doen.

[Raven]

Koen schreef op 06-08-2004 @ 21:40 :
Ja en wie weet spoel ik dan honderden uren werk door de plee om maar eens een Java versie te bouwen zeker. Dacht 't ook.

Daarnaast ben ik 't met Enlightenment eens, ik zie geen voordelen. Community sites als het fotoboek zijn ideale projecten om júist met PHP/MySQL te doen.

if you say so

noujaah ik heb ook wel es een programma ik 3 verschillende talen gebouwt gewoon om te kijken wat het beste werkt

was ook maar 'n idee .. het laden duurt nl soms ERRUG lang.

ik heb trouwens gemerkt dat als je niet ingelogd bent en je klikt op info & foto's dan krijg je weer de zelfde pagina ..

[Paperz]

Koen schreef op 06-08-2004 @ 21:40 :
Ja en wie weet spoel ik dan honderden uren werk door de plee om maar eens een Java versie te bouwen zeker. Dacht 't ook.

Als 't werkt als het huidige kan je zo een groot aantal uren schrappen...
en dan kan de java versie gewoon als desktop programma gebruikt worden, naast 't php ding

[Raven]

Paperz schreef op 06-08-2004 @ 21:56 :
Als 't werkt als het huidige kan je zo een groot aantal uren schrappen...
en dan kan de java versie gewoon als desktop programma gebruikt worden, naast 't php ding

is miss wat voor te zeggen om de foto's dan eerst te comprimeren dan te versturen en dan weer te inflaten .. dan zou het laden toch sneller moeten gaan ?

moet nog ergens een stuk LWZ achtige compressie code hebben .. is wel C++

[Lorelei]

Goed.. even de mening van een leek. Het klinkt als een heleboel werk en wat mij betreft is het fotoboek (en zijn snelheid) prima zo.

[Paperz]

grl schreef op 06-08-2004 @ 22:30 :
Goed.. even de mening van een leek. Het klinkt als een heleboel werk en wat mij betreft is het fotoboek (en zijn snelheid) prima zo.

De snelheid zal idd voornamelijk liggen aan de verbinding van de bezoeker en de drukte op het moment van het bezoek...
De snelheden zouden pas uitmaken bij veel meer gebruikers (en dan ook tegelijke tijd) volgens mij

[Lorelei]

Paperz schreef op 06-08-2004 @ 23:25 :
De snelheid zal idd voornamelijk liggen aan de verbinding van de bezoeker en de drukte op het moment van het bezoek...
De snelheden zouden pas uitmaken bij veel meer gebruikers (en dan ook tegelijke tijd) volgens mij

Ja, en je moet je dan afvragen of het de moeite waard is. Zoals ik al zei: ik ben een leek. Ik heb geen flauw idee hoeveel moeite het is en ik heb geen flauw idee hoeveel dit uitmaakt in snelheden. Maar ik heb het idee dat de snelheid van het fotoboek voor de meesten prima is zo. En dan kan je *bla* uren tijd steken in het sneller maken van iets wat op zich al goed werkt. Of je kan diezelfde uren steken in iets nuttigers.

Denk ik.

[Paperz]

grl schreef op 06-08-2004 @ 23:33 :
Ja, en je moet je dan afvragen of het de moeite waard is. Zoals ik al zei: ik ben een leek. Ik heb geen flauw idee hoeveel moeite het is en ik heb geen flauw idee hoeveel dit uitmaakt in snelheden. Maar ik heb het idee dat de snelheid van het fotoboek voor de meesten prima is zo.

Mja m'n eerste post was een beetje sarcastisch... imo is het niet de moeite waard... ik zie net in de statestieken dat er 505 bezoekers per uur waren op een gegeven moment... Koen weet de exacte nummers... en ook hoeveel serverload het met zich meeneemt... zolang deze binnen een gestelde grens is (en daar heeft Koen vast ook over nagedacht) is er geen probleem...
Daarnaast zal er geen geld/levens verloren als 't fotoboek niet snel/goed werkt... dus zullen de kleine snelheid verhogingen er niet toe doen...
bij transacties op een database met duizenden klanten en honderden gebruikers zijn het zeker afwegingen om te maken... (maar goed, die zullen niet zo omslachtig werken) want tijd is geld en geld moet rollen (ofzo) :>

grl schreef op 06-08-2004 @ 23:33 :
En dan kan je *bla* uren tijd steken in het sneller maken van iets wat op zich al goed werkt. Of je kan diezelfde uren steken in iets nuttigers.

Denk ik.

't werk voor bijv. het fotoboek is zover ik weet vrijwillig en onbetaald dus als iemand er tijd in wil steken... waarom niet...
maar de vraag is eerder is 't nuttig voor de site, wat voegt 't toe, wat wordt er beter van?

[Enlightenment]

Zweepje schreef op 06-08-2004 @ 22:00 :
is miss wat voor te zeggen om de foto's dan eerst te comprimeren dan te versturen en dan weer te inflaten .. dan zou het laden toch sneller moeten gaan ?

moet nog ergens een stuk LWZ achtige compressie code hebben .. is wel C++

JPEG laat zien vrijwel niet meer comprimeren, zelfs 7zip, verreweg de beste compressiemethode, weet er nauwelijks iets af te snoepen. GIF is gebaseerd op LZW-compressie, ik denk dat je dit bedoelt. JPEG is weer op een andere/eigen compressiemethode gebaseerd, waar ik te weinig vanaf weet. Maar mijn dir met g**l* foto's RARen heeft bijvoorbeeld weinig zin.

[Chimera]

Zweepje schreef op 06-08-2004 @ 22:00 :
moet nog ergens een stuk LWZ achtige compressie code hebben .. is wel C++

Nee. LZW heeft ook erg veel nut op plaatjes met JPG compressie

Weet jij absoluut zeker dat jij iets informatica-achtigs gestudeerd hebt?

[Chimera]

Enlightenment schreef op 07-08-2004 @ 01:11 :
JPEG is weer op een andere/eigen compressiemethode gebaseerd, waar ik te weinig vanaf weet.

Je was me iets te snel af, maargoed. JPEG is lossy, GIF (LZW) niet. JPEG valt simpelweg niet verder te comprimeren daar het min of meer 'random' data is.

Wat betreft dat Java verhaal: complete onzin. Je creeert een hoop problemen (niet iedereen heeft een (up-to-date) Java-VM), terwijl het geen oplossing biedt voor hetr 'probleem' (lage transferrate vanaf de s.com server).

[Raven]

Chimera schreef op 07-08-2004 @ 02:34 :
Nee. LZW heeft ook erg veel nut op plaatjes met JPG compressie

Weet jij absoluut zeker dat jij iets informatica-achtigs gestudeerd hebt?

eeh ja maar C++ AI, en OpenGL zijn mijn specialiteiten ..
servers en databases niet zo .. was ook maar 'n wild ideee

[ExVaal]

Wat een bullshit, JAVA is echt een klotetaal om dit in te schrijven. Het mag duidelijk zijn dat PHP/MySQL de toekomst is voor server/client toepassingen zoals dit fotoboek.

[Raven]

Vaal schreef op 07-08-2004 @ 11:14 :
Wat een bullshit, JAVA is echt een klotetaal om dit in te schrijven. Het mag duidelijk zijn dat PHP/MySQL de toekomst is voor server/client toepassingen zoals dit fotoboek.

hmm ja kijk voor stand alone applicaties en spellen is het nl helemaal om te huilen .. maar mij hebben ze dus wijs gemaakt dat als je snelle dingen op internet wil .. nu ja het zal wel ..
maar als 't hier voor ook niet werkt .....

wat moet je DAN met java ???

ook goed ik ga een RTS bouwen in C++ wie doet er mee

[Chimera]

Vaal schreef op 07-08-2004 @ 11:14 :
Het mag duidelijk zijn dat PHP/MySQL de toekomst is voor server/client toepassingen zoals dit fotoboek.

Heheheh.

Het spijt me, maar de meeste ECHTE wepabbplicaties zijn toch echt JSP/Oracle of ASP/SQLServer systemen. Er zijn bijzonder weinig grote bedrijven die hun spul in PHP afleveren.

[Chimera]

Zweepje schreef op 07-08-2004 @ 11:30 :
wat moet je DAN met java ???

JSP for teh win.

[Raven]

Chimera schreef op 07-08-2004 @ 12:07 :
Heheheh.

Het spijt me, maar de meeste ECHTE wepabbplicaties zijn toch echt JSP/Oracle of ASP/SQLServer systemen. Er zijn bijzonder weinig grote bedrijven die hun spul in PHP afleveren.

maar die doen HET dus ook niet met java ?

Zweepje schreef op 06-08-2004 @ 20:47 :
eeh .. miss gewaagt maar is het niet een goed idee om echt JAVA te gebruiken ipv php en javascript..

ow en ik heb nog zo'n mooi dik toverboek

Thinking in JAVA van Bruce Eckel

heb het idee dat dat ook ietsje sneller gaat want dan kan de CODE lokaal draaien

En die code moet je ook downloaden, en is meer dan gewoon html en javascript..

Dit is wel echt het slechtse idee wat ik tot nu toe heb gehoord :X

[Chimera]

Zweepje schreef op 07-08-2004 @ 12:09 :
maar die doen HET dus ook niet met java ?

JSP = Java Server Pages.

[Chimera]

********** schreef op 07-08-2004 @ 12:23 :
En die code moet je ook downloaden, en is meer dan gewoon html en javascript..

Applets worden net zo goed gecached, dus dat is geen argument.

[ExVaal]

Chimera schreef op 07-08-2004 @ 12:07 :
Heheheh.

Het spijt me, maar de meeste ECHTE wepabbplicaties zijn toch echt JSP/Oracle of ASP/SQLServer systemen. Er zijn bijzonder weinig grote bedrijven die hun spul in PHP afleveren.

Ik heb het dan ook niet over bedrijven maar over kleinschalige projecten zoals het fotoboek

[Enlightenment]

Chimera schreef op 07-08-2004 @ 12:07 :
Het spijt me, maar de meeste ECHTE wepabbplicaties zijn toch echt JSP/Oracle of ASP/SQLServer systemen. Er zijn bijzonder weinig grote bedrijven die hun spul in PHP afleveren.

Vrijwel alle fora zijn geschreven in PHP, althans die ik ken. PHP/MySQL is een zeer populaire combinatie voor webbased dynamische omgevingen. Grote bedrijven vind ik niet zo interessant. Scholieren.com is ook geen groot bedrijf. Dat betekent niet dat PHP niet ook populair zou zijn in de toekomst, niet alleen de 'grote bedrijven' bepalen die met hun bloated proprietary apps.

[Raven]

Enlightenment schreef op 07-08-2004 @ 22:54 :
Vrijwel alle fora zijn geschreven in PHP, althans die ik ken. PHP/MySQL is een zeer populaire combinatie voor webbased dynamische omgevingen. Grote bedrijven vind ik niet zo interessant. Scholieren.com is ook geen groot bedrijf. Dat betekent niet dat PHP niet ook populair zou zijn in de toekomst, niet alleen de 'grote bedrijven' bepalen die met hun bloated proprietary apps.

...en da's een meisje

heej post eens een foto

[Chimera]

Enlightenment schreef op 07-08-2004 @ 22:54 :
Grote bedrijven vind ik niet zo interessant.

Ik wel, en ik had het statement van Vaal verkeerd begrepen. En dat de meeste fora op PHP en MySQL draaien: beetje duh verhaal he?

[Chimera]

Zweepje schreef op 08-08-2004 @ 11:26 :
...en da's een meisje

heej post eens een foto

[Raven]

Chimera schreef op 08-08-2004 @ 11:36 :

*PROEST*

... ook lid van de rolleye fanclub ?

[Chimera]

Zweepje schreef op 08-08-2004 @ 11:40 :
*PROEST*

... ook lid van de rolleye fanclub ?

Dat niet zozeer, maar bij sommige leden is het nou eenmaal de enige reactie die je kunt geven.

[M@rco]

Enlightenment schreef op 07-08-2004 @ 22:54 :
Dat betekent niet dat PHP niet ook populair zou zijn in de toekomst, niet alleen de 'grote bedrijven' bepalen die met hun bloated proprietary apps.

Wat heb jij toch met het woord "bloated"?

Chimera schreef op 07-08-2004 @ 17:21 :
Applets worden net zo goed gecached, dus dat is geen argument.

Dat snap ik,
maar een zelfde soort pagina laden in java duurt langer dan zo'n agina in html/css volgens mij.