ForumFree Chat - Blog tecnico

FFIRCd 1.0 nasceva dall'idea di creare un server di chat che permettesse di sistemare tutti i vari problemi che la mia esperienza su un network di IRC dava gestendo il canale #ForumFree

Account, forum e blog di ForumFree, ForumCommunity e BlogFree integrati nella chat
Semplificare i gradi di op ed eliminare channel mode ritenuti obsoleti
Rendere il meno necessario possibile ricorrere ai service per fare modifiche (è tutt'ora un processo che si vuole mandare avanti)
L'esistenza di un canale /staff per ogni forum e blog
La possibilità di settare channel mode e topic permanenti senza dover ricorrere a ChanServ
Il cambio di prospettiva dell'akick, vista come una seconda banlist dove inserire ban permanenti e senza il tipico flood creato da ChanServ (notifica agli op, kick pubblico, set di un nuovo ban)
La gestione dei ban privata esattamente come lo sono gli akick
Eliminazione del ghost automatica

Questo è l'inizio e come tutti i punti di partenza, aiuta a capire cosa si è fatto male

Abbiamo passato un brutto periodo su FFIRCd 1.0 a causa dell'aumento dell'utenza, arrivando a quota 380/430 utenti online nei momenti di punta FFIRCd iniziava a mostrare i suoi limiti tecnici con comandi che fallivano o nel peggiore dei casi con un crash del demone
Voglio dire che io come ogni utente, perchè mi considero un utente, ho odiato questa situazione

Il buon senso mi portò dopo alcuni mesi dal completamento di FFIRCd 1.0 a rendermi conto degli errori fatti, dei problemi che ho avuto con Python, della architettura della chat che non avrebbe permesso di aggiungere funzionalità che vorremmo offrire (più o meno a breve termine) senza rendere il codice illeggibile.

La decisione che presi fu quella che fa parte della vita di ogni software, partendo dalla esperienza della prima versione riscrivere tutto

Questa volta però volevo un linguaggio staticamente tipato. E' stata una scelta che ha influenzato molto, in maniera positiva FFIRCd 2
Passare a un linguaggio staticamente tipato da uno dinamico come Python mi ha permesso di riscrivere il demone molto più velocemente (grazie all'autocompletamento), di avere trovare errori già alla fase di compilazione e sopratutto di effettuare refactoring del codice senza avere una enorme batteria di unit test dietro
E' stata la scelta forse migliore fatta per FFIRCd 2.0 - oggi non tornerei mai indietro ad un linguaggio dinamico per progetti mediamente complessi (FFIRCd 2.0 conta circa 7.000 righe di codice effettivo)

La scelta in quale linguaggio riscrivere FFIRCd non fu una scelta facile. In un primo momento la strada da prendere sembrava quella di un linguaggio funzionale (Haskell oppure F#) ma dover imparare un nuovo paradigma di programmazione ne avrebbe rallentato troppo l'opera di riscrittura
Volevo però un linguaggio orientato agli oggetti (quindi non C), che gestisse lui la memoria e che non sia troppo ...

Read the whole post...

Ci siamo, gli utenti chiedono a gran voce che sia possibile vedere il loro stato su irc.forumfree.it senza dovver usare BNC o bot appositi ed il team di chat.forumfree.it si mette al lavoro

La proposta viene passata su #chat.ff/staff per poi essere discussa tra i vari op. In questa fase viene discussa in maniera più precisa come dovrà funzionare la visualizzazione dello stato di un utente, dei possibili problemi e dei tempi e priorità rispetto alle altre cose da farsi
E' una delle fasi più interessanti (capita spesso di parlare di più cose insieme in maniera deltutto naturale ) e si conclude con il parere di Vash SD al riguardo
Se negativo, non si vedrà mai questa funzionalità integrata in FFIRCd

Se la proposta è piaciuta, chi si dedica dello sviluppo decide a seconda degli impegni a chi affidare lo sviluppo di questa nuova funzionalità
Abbiamo milestone, ma non abbiamo tabelle di marcia.

FFIRCd per tutto il ciclo di vita della 1.0 ha fatto uso del (magnifico) Git e Github (account commerciale per repository privati)

Git è un file system che permette di tenere traccia di ogni modifica fatta ad un file a cui viene associato un commento,
condividere il suo contenuto al di fuori del proprio pc e gestire quasi autonomamente le modifiche apportate dai vari sviluppatori in modo che
vengano fuse (merge) tra di loro

Non abbiamo mai usato funzionalità avanzate (e possibilmente dannose) di Git come rebase, ma abbiamo fatto di tutto con neanche 6 comandi di Git
Git è facile per chi sa usarlo

Il workflow di FFIRCd è il seguente

Repository principale:
nico159/FFIRCd-1
Rami di sviluppo fissi:
|->master (stabile)
|->integration (dove finiscono le modifiche da apportare prima di master)
Rami di sviluppo on-demand:
|->next (sviluppo)
|->novità-gestione-ban (sviluppo singola funzionalità)
|->...

Repository altri sviluppatori:
LightStyle/FFIRCd-1
Rami di sviluppo fissi:
|->master (che equivale alla next di nico159/FFIRCd-1)
Rami di sviluppo on-demand:
|->webstatus
|->bug-cloni
|->...

Ogni ramo di sviluppo (branch) non è altro che una copia esatta del repository principale (ramo master) risalente alla data
di creazione del branch

Ogni sviluppatore ha due copie (fork) di nico159/FFIRCd-1
Una pubblica accessibile a tutti i membri del team su Github del tipo LightStyle/FFIRCd-1 più una copia privata nel proprio
pc con i vari branch creati da LightStyle a seconda di quello a cui sta lavorando (tipo un ipotentico branch webstatus)

Le modifiche (commit) fatte nel fork situato ne...

Read the whole post...

Hypnotize su FFMagazine ha scritto un articolo (bello a mio parere) dove viene paragonata la chat di ForumFree al network IRC Azzurra: http://ffmagazine.forumfree.it/?t=50769482

Una delle cose che mi va di chiarire è il perchè FFIRCd non prevede alcun concetto di network IRC

Cosa significa che FFIRCd non è un network IRC mentre Azzurra sì?
Azzurra è composta da più server IRC sparsi per l'Italia collegati tra di loro, ogni utente può scegliere a quale server del network collegarsi oppure farsene assegnare uno in maniera casuale. Al contrario la chat di ForumFree è composta da un unico server IRC che serve tutti gli utenti

Immagino già determinate persone blaterale buzzword come High availability! Web scalable! The network is the computer!
La mia risposta è YAGNI

"Always implement things when you actually need them, never when you just foresee that you need them."

Abbiamo circa 150 utenti online negli orari serali, un singolo server IRC con buona connettività ed un ottimo demone IRC può gestire anche 30.000 utenti, molti di più degli utenti che Azzurra ha mai avuto online.
irc.forumfree.it potrebbe gestire senza problemi, sul suo unico server, tutta l'utenza formata da 1.500/2.000 utenti online della rete Azzurra

Sul lato economico, la chat è un servizio che ha i suoi costi mensili di mantenimento e che viene offerto agli utenti Di ForumFree.it, ForumCommunity.net e BlogFree.net senza alcuna forma di pubblicità. Avere più server senza un reale motivo è insensato.
Anche Azzurra è offerto senza alcuna forma di pubblicità, come fanno?
Il server irc.forumfree.it è un server di proprietà di ForumFree.it, Azzurra al contrario non è proprietaria dei server IRC che compongono la sua rete, sono server donati a scopo pubblicitario da compagnie telefoniche come Telecom e chi fornisce servizi di hosting come Seeweb

Azzurra garantisce tramite la rete distribuita che non ci saranno mai down?
La risposta è no
Avete una rete distribuita porta ad altri problemi che noi usando un singolo server non abbiamo: i netsplit
Inoltre in caso di aggiornamento del server, gli utenti di quel server cadranno esattamente come quando noi mettiamo giù il server per circa 40s per gli aggiornamenti.
A mio avviso avere un singolo server porta a meno downtime

La rete è debole sotto attacchi DoS?
Purtroppo ancora sì, e sto buttando giù alcune idee su co...

Read the whole post...

Ripeti con me: "Il backup e' Bello, Il Backup e' Buono, Il Backup mi fa dormire sereno alla notte..."

A seconda delle proprie necessità i database offrono varie soluzioni di backup, le principali sono: backup della directory che contiene il database, usare un tool di esportazione oppure la classica configurazione Master/Slave.

Noi non abbiamo un secondo server da destinare come slave e non usiamo alcun tool di esportazione

Quindi qual'è la nostra strategia di backup? Mettere il database in read only ed effettuare il backup solo della directory dbpath, ovvero dove sono contenuti i file del database

Perchè non usiamo mongodumps?

In poche parole, è inutile

Di seguito una piccola guida

Mettere in modalità read only il database:

Copiare la dbpath sul vostro nastro di backup/NFS/FTP/Rysync
Se non conoscete qual'è il vostro dbpath, aprite il file /etc/mongo.conf e cercate

Di default è:

Se avete avviato mongod senza specificare il file di configurazione, il dbpath predefinito è:

In questo blog verrà trattato da me, e forse qualche altro, del lato tecnico della Chat di ForumFree.


E' una occasione per parlare del dietro la quinte dello sviluppo, condividere informazioni utili, discutere in che direzione di evolverà la chat

Edited by Hannibal_Smith - 8/9/2010, 11:00