[Design] Hoe een social network op te zetten?

[Alex)]

Onlangs kreeg ik een idee wat ik wel de moeite waard vind om me verder in te verdiepen, maar waar ik me nog niet goed echt raad mee weet. Het idee is een social network (ja, nog eentje ja) gericht op een bepaalde doelgroep. Je hebt LinkedIn voor professionals, Hyves voor vrienden, mijn idee sluit weer op een ander punt aan.

Ik weet echter niet goed, wat nou de beste manier is om mijn idee uit te werken. Het heeft zeker potentie, maar ik heb geen ervaring met het goed uitwerken van grote projecten. In het verleden ben ik vooral maar gewoon gaan programmeren, maar dat waren voor veel kleinere dingen.

Ik wil nu een ander traject gaan volgen, omdat ik weet dat mijn idee groot kan worden, heel groot, en ik dan zoveel mogelijk een Hyves-situatie wil voorkomen: een basis opzetten, die blijven uitbreiden, en er maar servers bij blijven proppen i.p.v. de basis structureel te verbeteren.

Het lijkt me niet dat ik zomaar een kant-en-klaar "Social Network Building Blocks"-pakket kan aanschaffen, de software zal ik zelf moeten ontwikkelen. Ik ben een student, met kennis van PHP en MySQL, dus het lijkt me voor de hand liggend dat ik verder ga bouwen met de kennis die ik al heb - i.p.v. eerst een nieuwe taal te leren zoals Python of ASP.NET.

Maar wat is nou de beste manier om dit van een plannetje in mijn hoofd om te zetten naar een goedfunctionerende website? Alle adviezen worden op prijs gesteld

[CodeCaster]

Programmeertechnisch zal het allemaal wel lukken, natuurlijk kun je dat gruwelijk verminken, maar er zijn zat communitysites die op brakke PHP-code toch duizenden gelijktijdige bezoekers aankunnen. Op een dedicated server, dat wel.

Het lijkt me interessanter om voor jezelf (of voor geldschieters) af te wegen of je bezoekers gaat halen, waar deze vandaan moeten komen, waarom ze op jouw site zullen blijven en waarmee je uiteindelijk geld gaat verdienen.

[Noork]

Als het echt 'groot' gaat worden, dan kun je er beter maar niet eens aan gaan beginnen in je eentje. Zoek wat gelijkgestemden tegen in je kennissenkring of internet en probeer samen te brainstormen en verder te komen.

Er zijn gewoonweg geen complete pakketten om Hyves 'effe' na te maken. Je zal hiervoor toch echt gedegen kennis van webservers, databases en scripting moeten hebben. Het is vrijwel ondoenlijk om ditzelf tot in de puntjes te beheersen. En mocht dit al lukken, dan moet je nog voldoende tijd ervoor zien vrij te maken.

Beste plannetje lijkt mij een bedrijfsplan (met daarin hoe je aangeeft wat geld met de site te verdienen, en hoe je mensen naar de site trekt en daar ook blijven komen!) en een functioneel ontwerp. Eventueel met daarin een tijdsplanning/timeboxes e.d.

Mocht je er dan nog mee doorgaan zou je nog even kijken naar de zachte aspecten van sociale software. Programmeren is 1 ding, maar het moet natuurlijk wel sociaal gezien ook werken. Leuk spul om even naar te kijken is dit:
Social building blocks
Engestrom over 'social objects'

Wellicht kun je hier nog wat inspiratie uit halen: Concept voor website, welke provider voldoet daar aan? Het topic eindigt wel als een vergaarbak van apache/php vraagjes, maar in het begin staan er wel nuttige reacties.

[ Voor 32% gewijzigd door Noork op 23-05-2008 16:57 ]

[Vunzz]

Tja, wat heb je allemaal nodig:

-pakket van eisen
-functioneel ontwerp
-technisch ontwerp
-bedrijfsplan
-hoop technische kennis

[Verwijderd]

Als het groot kan worden, kun je je beter meteen richten op het mogelijke maken een cluster in te zetten, en te focussen op het zo geod mogelijk uitbreidbaar maken van je systeem.
Denk bij het ontwikkelen van de software goed na over het uitrollen van bijvoorbeeld versieupgrades. Op een complex systeem kan dit best weleens tegenvallen om goed uit te voeren, dus zorg ervoor dat er vanalles geautomatiseerd is, en dat je zonder teveel problemen servers erbij kunt plaatsen.

Verder kun je denk ik toch het best het project opdelen in stukken. Wat zijn de basisvereisten voor zo'n systeem, en op welke manier denk je het zo te kunnen maken dat uitbreidingen niet teveel impact meer hebben op "de basis".

Ik zou wat performancetests doen met beschikbare frameworks. Als deze niet voldoen kun je zelf een lightweight framework ontwikkelen, welke je uiteraard goed moet profilen. Alles wat enigszins te cachen is, zul je dan moeten cachen, om snelheid te kunnen garanderen.

Je zou iets kunnen bedenken met "authoritive servers" voor profielen. De profielen en bijbehorende koppelingen per profiel worden dan door één of enkele servers bijgehouden. Andere servers mogen natuurlijk wel voor slave spelen en cachen. Dat cachen zou deels in bijvoorbeeld shared memory kunnen, of iets als tpmfs.

Denk ook goed na over bijvoorbeeld URL's binnen zo'n systeem. Zorg er bij voorkeur voor dat de informatie die op een pagina staat zoveel mogelijk voor iedereen gelijk is. Probeer de pagina's per blok op te bouwen, welke je eventueel afzonderlijk kunt cachen. Zo kun je veel sneller gegevens "inladen" op het moment dat je moet bepalen of een bepaald deel van een profiel wel zichtbaar is voor een bepaalde gebruiker.
En boven alles: beperk het aantal queries zoveel mogelijk!

Ik moet eerlijk zeggen dat ik denk dat met een klein beetje brainstormen je heel veel van de mogelijke knelpunten moet kunnen bedenken, en dat je goed moet nadenken over de requirements en een functioneel ontwerp. Wat verwachten de gebruikers? Hoe gaan ze het gebruiken? Zou het kunnen dat ze het ook voor andere doeleinden gaan gebruiken (of misbruiken?)

[Muscrerior]

offtopic:
Lees Getting real (37signals). Een boek dat veel indruk op mij heeft gemaakt. Het beschrijft een (alternatieve) methode om webapplicaties op te zetten. Geen technisch verhaal, alleen (project)management

[synctext]

Alex) schreef op vrijdag 23 mei 2008 @ 16:43:
Ik wil nu een ander traject gaan volgen, omdat ik weet dat mijn idee groot kan worden, heel groot, en ik dan zoveel mogelijk een Hyves-situatie wil voorkomen: een basis opzetten, die blijven uitbreiden, en er maar servers bij blijven proppen i.p.v. de basis structureel te verbeteren.

Helemaal mee eens. Kan heeel groot worden.

Myspace, Facebook, Hyves, Linkedin zijn allemaal geisoleerde implementaties
van hetzelfde concept. Eigenlijk wil je een schaalbare en user-controlled generieke
implementatie die als "building block" kan dienen. Zo kunnen Skype, MSN, etc
allemaal een shared social network+lib gebruiken.

Met 18 mensen zijn wij bezig op de TUDelft om ons P2P uit te breiden
met steeds meer "social network" features. Details van zero-server social network in P2P:
http://www.tribler.org/VirtualCommunities
Operational Python code:
http://www.tribler.org/br...ribler/Core/SocialNetwork
Ons doel is generieke P2P implementatie van
Bittorrent + Facebook/Hyves + MSN met DC++ closed communities & sharing.

Je bent meer dan welkom om mee te helpen met dit Open Source
project. Oja, de klasieke aanpak met functioneel ontwerp, technisch ontwerp, etc
werkt niet bij dit soort world-first code. De methode die goed werkt is
om een werkend prototype incrementeel uit te breiden naar een goed
gedefinieerde visie.

[Noork]

synctext schreef op vrijdag 23 mei 2008 @ 18:00:
Oja, de klasieke aanpak met functioneel ontwerp, technisch ontwerp, etc werkt niet bij dit soort world-first code. De methode die goed werkt is om een werkend prototype incrementeel uit te breiden naar een goed gedefinieerde visie.

Ben je dan niet maar wat aan het aanrommelen? Als je de techneuten de vrije loop laat, dan krijg je echt iets waar helemaal niemand op zit te wachten. Of bedoel je meer bij de implementatie ervan? Ik bedoel een functioneel ontwerp is 'functioneel'. Of worden de functionaliteiten ook door de techneuten opgesteld?

[Verwijderd]

synctext schreef op vrijdag 23 mei 2008 @ 18:00:
Oja, de klasieke aanpak met functioneel ontwerp, technisch ontwerp, etc
werkt niet bij dit soort world-first code. De methode die goed werkt is
om een werkend prototype incrementeel uit te breiden naar een goed
gedefinieerde visie.

Dit geloof ik niet. Het is altijd mogelijk van tevoren te bepalen wat er ongeveer moet gebeuren, wat het doel is, wat mensen verwachten, etcetera. Gewoon maar beginnen met een prototype is echt ene beetje te kort door de bocht.

[Verwijderd]

synctext schreef op vrijdag 23 mei 2008 @ 18:00:
[...]


Helemaal mee eens. Kan heeel groot worden.

Myspace, Facebook, Hyves, Linkedin zijn allemaal geisoleerde implementaties
van hetzelfde concept. Eigenlijk wil je een schaalbare en user-controlled generieke
implementatie die als "building block" kan dienen. Zo kunnen Skype, MSN, etc
allemaal een shared social network+lib gebruiken.

Met 18 mensen zijn wij bezig op de TUDelft om ons P2P uit te breiden
met steeds meer "social network" features.

Een soort van 'studenten social network' waarbij mensen met dezelfde opleiding registreren, mensen uit het bedrijfsleven van een bepaalde sector, etc etc (soort hyves/schoolbank kloon) kan wel nuttig zijn voor zowel bedrijven als (aankomend) studenten. Verder vraag ik me af of een kleine beginner uit Nederland zal kunnen concurreren met hyves of de andere engelstalige sites waar het ooit mee is begonnen

[Orphix]

Kijk naar de mogelijkheden van Cloud Computing. Technische afhankelijkheid, maar enorme (flexibele) schaalmogelijkheden.

[synctext]

Verwijderd schreef op vrijdag 23 mei 2008 @ 18:12:
[...]

Dit geloof ik niet. Het is altijd mogelijk van tevoren te bepalen wat er ongeveer moet gebeuren, wat het doel is, wat mensen verwachten, etcetera. Gewoon maar beginnen met een prototype is echt ene beetje te kort door de bocht.

Inderdaad, was beetje kort door de bocht.

Je moet weten wat er ongeveer moet gebeuren, dan functionele decompositie doen
en mensen verantwoordelijk maken voor een paar blokjes, en dan moet het
ook allemaal nog werkend worden gemaakt. Handig op core te maken en dan blokjes
eraan te hangen. Daarna elk blokje uitbreiden en interface stabiel proberen te houden.
Tot zover de theorie, die weinig rekening houd met weggaan van mensen en
dat sommige programmeurs ontslag nemen als ze bepaalde klussen moeten doen.
Vergeet ik nog wat?

Alle details uitwerken voordat je begint is niet altijd handig...
Maar er zijn genoeg smaakjes om dit aan te pakken:
http://www.google.com/search?q=software+methodologies

[MoBi]

Ik denk dat het denken over je backend belangrijker is dan je frontend. Frontend is meestal makkelijk te schalen, das gewoon dozen stampen. Dingen als een DB backend ben je afhankelijk wat de db software als mogelijkheden heeft om te schalen. Maar ook dingen als file uploads voor foto albums moet over na worden gedacht. Hoe ga je dat opslaan en hoe zorg je ervoor dat ook bij schaling dit nog snel blijft. Grootste probleem bij hyves is dat de DB servers tegen de software beperkingen aan gaan lopen.
Ook dingen als ssl login zul je moeten bedenken. Gebruik je het ja of nee. Neem je daar aparte servers voor enz?
Ga je gebruik maken van LDAP of SQL voor je user backend? Authenticeer je via LDAP of SQL?

[ Voor 17% gewijzigd door MoBi op 23-05-2008 20:58 ]

[djc]

Er zijn op internet best veel presentaties te vinden van over het schalen van grote sites...

http://www.danga.com/word...inuxfest_nw/linuxfest.pdf (LiveJournal)
http://www.slideshare.net...ng-twitter-railsconf-2007 (Twitter)
http://www.iamcal.com/talks/ (o.a. Flickr)

[orf]

Toch vraag ik mij af of een simpele en snelle opzet niet beter werkt. Ik heb genoeg plannen en ideëen gezien die allemaal 'erg groot' zouden worden. Veel investeringen gedaan en uiteindelijk bedroevende bezoekersaantallen. Daar tegenover zie je brakke sites die juist enorm gegroeid zijn. Jij hebt dat niet in de hand, maar juist de bezoekers / community.

Hoe erg is het om (tijdig) het systeem alsnog anders op te bouwen? Als je enige tijd draait en je ziet een goede lijn in je bezoekersaantallen, dan kun je parallel een nieuw systeem (laten) ontwikkelen.

[Alex)]

Hartelijk dank voor alle reacties hier, dat zal me zeker helpen

Het idee wat ik heb is misschien niet nieuw, maar voor de doelgroep waar ik op mik is een soortgelijk iets nog nietbestaand. Misschien als onderdeel van een andere site, maar zeker niet op een zelfstandige manier zoals ik het voor me zie.

Veel caching en weinig queries zijn dingen waar ik ook al aan dacht, aangezien juist dat het verschil kan betekenen tussen een goed en een slecht bereikbare site. Hoe ik het cachen precies wil gaan aanpakken weet ik nog niet, dit komt mede doordat ik nog geen vastomlijnde plannen heb, maar nog in de verkenningsfase zit

Ik heb het boek van 37signals in één ruk uitgelezen, en vind het eigenlijk een behoorlijk goed boek, hun visie sluit aan bij mijn visie over het lanceren van een webapplicatie.

De programmeertaal op zich hoeft geen probleem te zijn, in de startfase gewoon PHP en MySQL (wat ik al ken), mochten er naderhand echt problemen optreden die niet zijn op te lossen door servers bij te blijven plaatsen, dan kan er altijd nog gekeken worden naar een heropbouw van het systeem, eventueel zelfs in een andere taal.

Ik ben van plan om het CodeIgniter-framework te gebruiken, aangezien dit redelijk lightweight is, en me precies de functies biedt die ik zoek, gecombineerd met een vrij uitgebreide documentatie (unlike Zend Framework).

Opslag van gegevens wil ik zoveel mogelijk in SQL-db's doen, m.u.v. zaken zoals foto's en video's aangezien het onnodig veel overhead veroorzaakt door dat in een DB op te slaan - de DB kan betere dingen doen. Om te voorkomen dat foto's en video's die door de gebruiker als private gemarkeerd zijn, wel door iedereen kan worden opgevraagd door de URL te raden, wil ik er wel een soort script voor schrijven wat de nodige access checks uitvoert. Private moet immers private zijn. Cloud Computing klinkt interessant, maar als het al gebruikt zou worden, denk ik dat het vooral beperkt zal blijven tot het opslaan van foto's en video's (bijvoorbeeld in Amazon's S3).

Over de database-backend heb ik nog niet uitvoerig nagedacht, maar het gebruik van een SQL-DB lijkt me voor de hand liggend aangezien ik daar het beste mee kan omgaan - i.t.t. LDAP. SSL wil ik, indien technisch mogelijk, gebruiken voor inloggen, registreren en password wijzigen.

@Denniswerf: ik wil ook geen directe concurrent worden van Hyves, omdat ik daarvoor zo'n 3 jaar te laat ben. Als ik nu een Hyves-kloon opzet, komt niemand daarheen, juist omdat Hyves al zo groot is. Ik richt me echter op een specifieke markt waar nog niet een dergelijk iets bestaat, maar waar denk ik wel interesse in zal zijn.

@orf: Goed punt. Misschien wordt het niets, en heb ik daar dan zoveel tijd en moeite in geïnvesteerd. Een simpele, snelle opzet is sneller in elkaar gezet, en kan zeker in de aanlooptijd goed functioneren. Mocht het echt groter worden, dan kan er altijd nog herschreven worden.

Zoals 37signals al schreef: "denk pas aan schaalbaarheid wanneer je schaalbaarheid nodig hebt"


Hartelijk bedankt voor het meedenken

[prototype]

Code-igniter lightweight? Moet je eens even aan Spockz vragen of hij het met je eens is

Verder zou ik je aanraden om je niet al teveel te focussen op de techniek in deze fase: de techniek is niet de doorslaggevende factor bij de succes van een social networking site en kan LATER altijd nog geoptimaliseerd worden. In deze fase wil je je vooral focussen dus op premature optimization is the root of all evil en YAGNI (you ain't gonna need it). Bepaal wat voor features je wil en wat je niet wil, maar doe dat vooral in termen die voor de end-user ertoe doen.

"Sociale psychologie voor managers" is een leuk boek voor je denk ik, die ook uitlegt waarom de principes die ik net heb genoemd ertoe doen

[Spockz]

Alex). Als je CodeIgniter overweegt... Drop it. Het is uiteindelijk helemaal niet zo light-weight als ze publiceren. Met het grootste gemak zit je aan een mem. usage van 2MB. Dit komt volgensmij vooral door de manier waarop de code zichzelf bootstrapt.

Kohana is een PHP5 fork van CI en biedt bovendien nog betere ORM ook.

[djc]

Heb je trouwens ook bekeken of je Ning kon gebruiken in plaats van alles zelf doen?

[Alex)]

prototype schreef op zaterdag 24 mei 2008 @ 17:42:
Code-igniter lightweight? Moet je eens even aan Spockz vragen of hij het met je eens is

Verder zou ik je aanraden om je niet al teveel te focussen op de techniek in deze fase: de techniek is niet de doorslaggevende factor bij de succes van een social networking site en kan LATER altijd nog geoptimaliseerd worden. In deze fase wil je je vooral focussen dus op premature optimization is the root of all evil en YAGNI (you ain't gonna need it). Bepaal wat voor features je wil en wat je niet wil, maar doe dat vooral in termen die voor de end-user ertoe doen.

Je hebt gelijk. Techniek is zeker in deze fase nog helemaal niet belangrijk, het eerste wat ertoe doet is een goed plan uitwerken.

"Sociale psychologie voor managers" is een leuk boek voor je denk ik, die ook uitlegt waarom de principes die ik net heb genoemd ertoe doen

Ik zal 'm onthouden

Spockz schreef op zaterdag 24 mei 2008 @ 17:54:
Alex). Als je CodeIgniter overweegt... Drop it. Het is uiteindelijk helemaal niet zo light-weight als ze publiceren. Met het grootste gemak zit je aan een mem. usage van 2MB. Dit komt volgensmij vooral door de manier waarop de code zichzelf bootstrapt.

Kohana is een PHP5 fork van CI en biedt bovendien nog betere ORM ook.

Ok, thanks - heb gisteren Kohana eens gedownload en dat ziet er ook wel nice uit.

Manuzhai schreef op zondag 25 mei 2008 @ 10:43:
Heb je trouwens ook bekeken of je Ning kon gebruiken in plaats van alles zelf doen?

Ik heb net even gekeken, maar ik heb wat ideeën in m'n hoofd die echt custom werk vereisen, en het lijkt me praktischer om alles zelf te doen... dan ben ik ook minder afhankelijk van een derde partij, en ben ik ook niet aan hun voorwaarden gebonden.

[Muscrerior]

Spockz schreef op zaterdag 24 mei 2008 @ 17:54:
Alex). Als je CodeIgniter overweegt... Drop it. Het is uiteindelijk helemaal niet zo light-weight als ze publiceren. Met het grootste gemak zit je aan een mem. usage van 2MB. Dit komt volgensmij vooral door de manier waarop de code zichzelf bootstrapt.

Uit verschillende onderzoeken (een, en nog een) komt CodeIgniter toch als snelste/efficiëntste naar voren. Wat is er erg aan 2MB memory als anderen het nog slechter doen?

Spockz schreef op zaterdag 24 mei 2008 @ 17:54:
Kohana is een PHP5 fork van CI en biedt bovendien nog betere ORM ook.

Wikipedia: Object-Relational mapping
Worse, the translation layer can be slow and inefficient (notably in terms of the SQL it writes), resulting in programs that are slower and use more memory than code written "by hand."

[Spockz]

Muscrerior schreef op zondag 25 mei 2008 @ 21:07:
[...]

Uit verschillende onderzoeken (een, en nog een) komt CodeIgniter toch als snelste/efficiëntste naar voren. Wat is er erg aan 2MB memory als anderen het nog slechter doen?

Wat je in de eerste link laat zien is een snelle test van iemand die er weinig tijd in heeft gestoken (zegt hij zelf). Vervolgens laatje een topic zien dat over je eerste link gaat waarin die beweringen die daar worden gedaan worden tegengesproken. Dus ik vind dat je een leuke conclusie trekt.

Muscrerior schreef op zondag 25 mei 2008 @ 21:07:
[...]


[...]

Ja, en dus?

[Pete]

Spockz schreef op maandag 26 mei 2008 @ 10:10:
[...]

Wat je in de eerste link laat zien is een snelle test van iemand die er weinig tijd in heeft gestoken (zegt hij zelf). Vervolgens laatje een topic zien dat over je eerste link gaat waarin die beweringen die daar worden gedaan worden tegengesproken. Dus ik vind dat je een leuke conclusie trekt.

[...]

Spockz schreef op zaterdag 24 mei 2008 @ 17:54:
Alex). Als je CodeIgniter overweegt... Drop it. Het is uiteindelijk helemaal niet zo light-weight als ze publiceren. Met het grootste gemak zit je aan een mem. usage van 2MB. Dit komt volgensmij vooral door de manier waarop de code zichzelf bootstrapt.

Kohana is een PHP5 fork van CI en biedt bovendien nog betere ORM ook.

We zijn uiteraard blij dat jij even verwijst naar een artikel waar wel een goede test is uitgevoerd . Het is namelijk erg gemakkelijk te roepen "je zit zo aan een mem. usage van 2MB". Omdat je geen argumenten/bewijzen/vergelijkingen met andere frameworks geeft heeft dit totaal geen waarde.

[Muscrerior]

Spockz schreef op maandag 26 mei 2008 @ 10:10:
Vervolgens laatje een topic zien dat over je eerste link gaat waarin die beweringen die daar worden gedaan worden tegengesproken. Dus ik vind dat je een leuke conclusie trekt.

In het topic posten anderen (Kohana-gebruikers!) hun cijfers. Deze tonen een voordeel van CodeIgniter aan.

Voor verdere discussie ben ik allicht beschikbaar; maar liever niet in dit topic.

[ Voor 11% gewijzigd door Muscrerior op 26-05-2008 13:31 . Reden: onnodige quote verwijderd ]

[Spockz]

phsmit schreef op maandag 26 mei 2008 @ 10:21:
[...]


[...]


We zijn uiteraard blij dat jij even verwijst naar een artikel waar wel een goede test is uitgevoerd . Het is namelijk erg gemakkelijk te roepen "je zit zo aan een mem. usage van 2MB". Omdat je geen argumenten/bewijzen/vergelijkingen met andere frameworks geeft heeft dit totaal geen waarde.

Dat snap ik. Voor school heb ik een site gemaakt op basis van CodeIgniter. Zodra je de database autoload, komt er 400kB bij. Zo ook met de sessies module.

Ik zal kijken of ik die site binnenkort ook publiek kan zetten.

[ruuds]

Ik ben samen met nog twee anderen ook bezig om een communitysite op te zetten. Zelf zijn we in oktober 2007, nog naast onze studies en eigen bedrijfjes, begonnen aan het uitdenken van het concept.

We hebben ongeveer tot maart in de conceptfase gezeten om het concept zover mogelijk uit te denken, en vooral ook te her-uitdenken, fijnslijpen en evalueren met de doelgroep. Op dat moment hadden we alle op te leveren functionaliteit (uiteraard in grote lijnen) op papier uitgeschreven. Deze zijn we om gaan zetten naar wireframes en interactiemodellen, zodat we op papier uiteindelijk de hele community voor ons hadden liggen.

Nadat we het daar over eens waren is onze vormgever aan de slag gegaan om er een grafisch sausje omheen te gieten.

Ikzelf ben begonnen met de daadwerkelijke technische realisatie van het systeem, en heb er specifiek voor gekozen om per onderdeel te ontwikkelen. In principe is het nu dus al mogelijk om een beperkt deel van de website te draaien (daar waar het bij ons daadwerkelijk om gaat), ook al is het pas de bedoeling dat het geheel in juli de testfase ingaat.

Mijn beperkte kennis van bijvoorbeeld UML hebben me wel heel erg geholpen om de documenten uit de conceptfase om te zetten in een technisch ontwerp, zodat ik het geheel voor mezelf kon structureren.

Ik heb zelf het 'Getting things done' boek ook gelezen en ben het deels eens dat je pas naar schaalbaarheid moet kijken wanneer dit nodig is. We hebben er, juist wel met het oog op schaalbaarheid, specifiek voor gekozen om dataverwerking (de community is nogal data-intensief, maar ook het versturen van mails) los van HTTP requests uit te voeren dmv een soort queue. Hiervoor kunnen we dus, wanneer het nodig mocht zijn, eenvoudig extra machines bijschakelen om de data te verwerken, terwijl het frontend gewoon snel blijft draaien.

--

Aangezien het om een communitysite gaat, een website die in principe geen bestaansrecht heeft zonder haar bezoekers, zou ik vanaf die manier ook in het project gaan.

1. Doelgroep -> 2. Wat wil mijn doelgroep -> 3. Hoe biedt ik hen dat aan -> 4. Hoe realiseer ik dat technisch -> 5. Doe het! (en wanneer je stap 5 afgerond hebt, begin je weer bij 2)

[djc]

Hier is nog een leuke presentatie over LinkedIn. Daar bewaren ze hun Social Graph van 12 GB in RAM!

Deruud schreef op woensdag 04 juni 2008 @ 21:10:
1. Doelgroep -> 2. Wat wil mijn doelgroep -> 3. Hoe biedt ik hen dat aan -> 4. Hoe realiseer ik dat technisch -> 5. Doe het! (en wanneer je stap 5 afgerond hebt, begin je weer bij 2)

Dit wel een beetje alsof je een oplossing op zoek naar vraag bent.

[MisterBlue]

Als het over infrastructuur en zo gaat heeft Netlog (35 miljoen gebruikers in 20 landen) een blikje in de keuken gegeven op kingsofcode:
http://www.slideshare.net...-high-availability-430211

[Alex)]

Wederom erg bedankt, ook dit is erg nuttig.

Ook over LinkedIn en Netlog, dat soort zaken (architectuur) interesseert me sowieso

[ruuds]

Manuzhai schreef op vrijdag 06 juni 2008 @ 10:34:
Dit wel een beetje alsof je een oplossing op zoek naar vraag bent.

Is in principe ook. We begonnen met een wild idee voor een community, en dan zoek je natuurlijk eerst uit of er markt voor is. Die markt wil je zo goed mogelijk bedienen, dus moet je je oplossing daar zo goed op laten aansluiten.

[eghie]

Lees ook deze site eens door. Dit helpt een hoop om je te richten op schaalbaarheid: http://highscalability.com

[mocean]

Facebook heeft hun platform ook opensource gemaakt, zie http://developers.facebook.com/opensource.php/
Als alles open source is gemaakt wat facebook aanbiedt, dan is het zeker de moeite waard om ernaar te kijken denk ik!

[Verwijderd]

Jeff Atwood van Coding Horror heeft pas geleden ook een aardig blogje geschreven over de valkuilen van social software => http://www.codinghorror.com/blog/archives/001122.html

Hier in verwijst hij naar ene Clay Shirky, die blijkbaar een autoriteit is op dit gebied (?).

Heeft misschien niet alles met de techniek te maken, maar is wellicht handig bij dit onderwerp.

[djc]

Verwijderd schreef op maandag 09 juni 2008 @ 09:57:
Hier in verwijst hij naar ene Clay Shirky, die blijkbaar een autoriteit is op dit gebied (?).

Dat klopt wel redelijk.

[Verwijderd]

Manuzhai schreef op maandag 09 juni 2008 @ 15:29:
[...]
Dat klopt wel redelijk.

Gelukkig maar ;-) Ik bedoelde 't ook niet om hem in twijfel te trekken, meer dat ik er zelf niet genoeg vanaf weet om het te bevestigen/te ontkrachten